Re: [Playerstage-users] What needs to be implemented of the position2d interface?

[Geoffrey B. <g....@au...>]

You can support as much or as little of the position2d interface as you 
want in your driver. The only limitation is that if you don't support 
something another driver needs then your driver won't be able to be used 
in conjunction with another driver. For example the wavefront navigation 
driver. So you probably can get away with not providing geometry.

If you just want translation speed and turning angle then probably the 
PLAYER_POSITION2D_CMD_CAR command is what you should use. When your 
driver receives this command it should use the velocity parameter to set 
the robot's wheel speed and the angle parameter to set its turning 
angle. Your client program can send these values using the position2d 
proxy command playerc_position2d_set_cmd_car().

For sending data back to clients from the driver, use the 
PLAYER_POSITION2D_DATA_STATE data message with the 
player_position2d_data_t structure. Fill in the values you want to send 
back and zero the ones you're not interested in. Take a look at the 
roomba driver to see how this is done.

You can allow clients to find out what message types are supported by 
using the HANDLE_CAPABILITY_REQUEST macro at the start of your driver's 
ProcessMessage() function. There is documentation on how to use this in 
player.h. It's a relatively new thing so not many drivers use it yet, 
but you can find examples in the mixed/p2os (not complete) and 
audio/alsa drivers.

Having said all that, if you want your driver to be useful outside of 
your individual needs, then once you have what you need done you should 
consider implementing support for as much of the robot's functionality 
as you can.

Geoff

Fred Labrosse wrote:
> I'm currently writing a driver for my new (soon to arrive I hope) robot (a
> robuCarTT) and am wondering what I need to implement of the position2d
> interface (the only interface I really need from the robot, I think).
> 
> I'm only interested in sending translation speed and turning angle (it is
> a 4 wheel steering robot) and probably reading the actual speed and
> turning angle back.  I'm not too interested in odometry (given where I
> want to drive the robot it will be crap anyway ;-).
> 
> I'm not too sure if I can get away with not updating odometry (and if it
> is the case, how can I tell possible users that this is not supported). 
> Also, I don't quite understand how to use the carlike command.
> 
> Any pointers to all that in the code?


-- 
Robotics research group, University of Auckland
http://www.ece.auckland.ac.nz/~gbig005/