Re: [Playerstage-developers] Player single-port work done

[ahoward <ah...@po...>]

Hi folks:

I have updated libplayerc, pyplayerc and playerv to be compatible with
Brian's new single-port stuff.  The API has changed a little, with proxy
creation functions now taking an additional argument to specify which
robot to talk to.  E.g.

  laser = playerc_laser_create(client, index);

becomes

  laser = playerc_laser_create(client, robot, index);

And similarly for pyplayerc.  playerv has aquired an additional command
line argument to specify the robot.  E.g.

  playerv -h localhost -p 6665

becomes

  playerv -h localhost -p 6665 -r 0

You can only talk to one robot at a time, since it makes no sense to
connect to multiple robots in playerv.

	Andrew


On Tue, 4 Feb 2003, brian gerkey wrote:

> Hi everybody,
>
> I've just checked in a slew of changes to Player (and a few changes to
> Stage), in order to get all robot control on one TCP port.
>
> To recap, Player now listens on just one port, even when running in Stage.
> Each device is identified by the triple: {robot,interface,index}.   Thus,
> with one TCP connection, you can control multiple devices on multiple
> robots, treating them (if you wish) as one large sensor-actuator network.
>
> This change might also prove beneficial with physical robots when combined
> with the passthrough driver: you can use an auxillary Player server, full
> of passthrough drivers, to aggregate in one place the data and control
> for all the robots' devices.
>
> It's done, I've tested it a bit, and it seems to work fine.
>
> Important changes and notes are below.
>
> Let me know if you have problems.
>
> Remember that you can check out the tag 'pre-single-port' if you don't want
> to deal with these changes right now.
>
>         brian.
>
> ------------------------------------------------------------------------------
> Player
> ------------------------------------------------------------------------------
> I ended up changing the Player message protocol in the following ways:
>
>   - The message header now has a 2-byte 'robot' field that specifies to which
>     robot the message pertains (the header is still 32 bytes; I took two
>     bytes out of the 4-byte 'reserved' field).
>
>   - The device subscription message payload now contains an extra field, to
>     identify the robot to subscribe to.
> ------------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Stage
> ------------------------------------------------------------------------------
> I changed the semantics of the Stage .world file in the following way:
>
>   - The 'port' keyword for a Player entity now sets the robot id for that
>     entity, *not* the port.  This is a temporary situation, as the whole
>     config file setup will change substantially when Richard merges his
>     Stage changes back into HEAD.
>
> I add a command-line argument to Stage:
>
>   - To specify the single port on which Player should listen, pass
>     '-pp <port>' to Stage.
> ------------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> C++ Client library
> ------------------------------------------------------------------------------
> I've updated the C++ client (and the underlying C client) to support the
> protocol changes.  I've also add the ability to take advantage of the new
> robot id mechanism:
>
>   - When creating a proxy, such as for a position device, you can select
>     the robot id by passing it as the 4th argument to the constructor, e.g.:
>
>        PositionProxy pp(&playerclient, 0, 'a', 1);
>
>     If you don't pass the 4th arg, then it's assumed to be 0.  I know this
>     is not a great API; I'll polish it later.
> ------------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> libplayerc
> ------------------------------------------------------------------------------
> I've updated libplayerc to support the protocol changes, but have *not*
> added the ability to take advantage of the new robot id mechanism.  In
> particular, this means that libplayerc is currently only capable of
> controlling the robot (if any) with id 0.
>
> playerv works, but gets a little confused by the list of available devices,
> whose names only differ by robot id.
> ------------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Tclplayer
> ------------------------------------------------------------------------------
> I haven't updated Tclplayer yet.
> ------------------------------------------------------------------------------
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Playerstage-developers mailing list
> Pla...@li...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>

Andrew Howard                           email: ah...@po...
Department of Computer Science          http:  www-robotics.usc.edu/~ahoward
University of Southern California       phone: 1 (213) 740 6416
Los Angeles, CA, U.S.A. 90089-0781      fax:   1 (213) 821 5696
    << Insert pithy saying here >>>