#33 Position model: position control, accel, decel, max speeds

Reed Hedges

OK, this is the *really* big one, it reworks much of
the position model's update function. It includes two
seperate features, which at the moment overlap.

One is to implement relative-position control, and
reimplement velocity and position control so that you
can do different kinds of control on heading and

The other is to accelerate and decelerate according to
parameters given in the world file, or given by the
SPEED_PROF player config request, and to limit speeds
to parameters from the world file or the SPEED_PROF
request. It also uses those max speeds for position

Translating in Y (for a non-differential robot) is not
really tested much.

There may be a few bugs in position control.

I can seperate out the latter from the former if you
want, that just takes some time, and we are discussing
a new kind of position interface for player, so all of
this migth change soon.

But I wanted to put the patch here in case anyone
needed it (and ActivMedia's version of modified-Stage
will include it).



  • Reed Hedges

    Reed Hedges - 2005-05-20

    Logged In: YES

    Note, this code has... issues :)
    I'll post a new one soon (but that one will change the
    stg_position_cmd_t struct).

  • Reed Hedges

    Reed Hedges - 2005-06-01

    Logged In: YES

    An updated patch has been posted, with restructuring. Works
    much better. To use in Player, you need to add some fields
    to the command and speed config request structs. But since
    Player's data storage is being rewritten, the player
    interface will also need to be rewritten, and perhaps
    position and relative-position control can be seperated out
    even more (if there are different Player commands, there can
    be different Stage commands).

  • Reed Hedges

    Reed Hedges - 2005-06-08

    Logged In: YES

    Ok, adding a new version of this patch. Putting 'static'
    variables in the position_update was pretty stupid for a
    *multi*-robot simulator...

  • Reed Hedges

    Reed Hedges - 2005-06-27

    Logged In: YES

    Sorry, here's a new one. The previous position control
    implementation determined when a new position control
    command was recieved by comparing command argument values
    (e.g. new xpos), which of course would not start the new
    movement if a new position command with the same values
    happened during or immediately after a previous command.

    This revised patch works around that by adding a "nonce" to
    the postion command struct, an integer which must be
    incremented for each new command set.

    This isn't implemented for the Player driver; there really
    isn't a way to do that I don't think. We might want to do
    something more general though to signal a "new" command,
    that can be used by all models.

  • Reed Hedges

    Reed Hedges - 2005-06-27

    Patch against Stage 2005-06-01 (like the previous ones), but fixes bug with position control and "new" commands.

  • Jeremy Asher

    Jeremy Asher - 2008-08-01
    • milestone: --> 829871
  • Toby Collett

    Toby Collett - 2009-07-23

    Moving to feature requests as some of the described functionality might still be wanted, but the patch certainly wont apply to stage 3

  • Toby Collett

    Toby Collett - 2009-07-23
    • labels: 382482 -->
    • milestone: 829871 -->

Log in to post a comment.