On Mon, 18 Oct 2004, Andrew Lynch wrote:
> I am using a Rabbit 3000 from Z-world on our Robocup Robot. Do I need to
> write a client to communicate to player or just simply create a driver that
> talks through the serial port (over some protocol ...UDP, TCP...etc.) Rabbit
> uses Dynamic C and has its own specially configured TCP.lib file which can
> easily be modified to connect to certain IP's. I am not sure exactly what
> else needs to be specified between the player server and our basic TCP
> BYU uses a similar setup for the Robocup Class and they might also be
> intersested in getting a player Dynamic C client working.
> For more info about the University of Texas Robotics group go here
> For further reference on Dynamic C libraries look here:
Player is normally used on robots that carry general-purpose computers
(e.g., laptops, SBCs that can run Linux). Player runs on this computer,
and uses drivers to talk to robot hardware, usually over serial lines.
Then client programs control the robot by talking to Player either from
the same machine, or over a network.
If I understand your setup correctly, you have a non-standard embedded
computer, with its own special development environment? This is rather
different from Player's normal usage case.
If you want to use Player, you have a couple of options:
(1) Port Player to run on the Rabbit 3000, and write Player drivers to
access your robot's hardware.
(2) Run some kind of socket daemon on the Rabbit 3000 that forwards
data/commands from/to the robot hardware, and write a Player driver
that talks to this daemon. Then you'd run Player offboard somewhere
(e.g., a Linux desktop/laptop) and your client control programs would
talk to it.
Neither option is that great. Player really needs a POSIX environment and
gcc/g++, which could make option (1) arbitrarily difficult. Option (2)
is ok, but you should carefully consider what the added value is of using
Player in this setting. You'll suffer at least some additional latency in
the control loop, which I'm guessing is a big deal in a robocup setting.
That would have to be offset by the benefits of generality and portability
provided by Player's abstract device interface and associated simulators
Brian P. Gerkey gerkey@...
Stanford AI Lab http://ai.stanford.edu/~gerkey