Did you have any more luck with the UDP transport layer? It is far less popular than the TCP one and so it gets less testing/usage.


2009/2/24 marija seder <marija.seder@gmail.com>

We have the p3dx-sh mobile robot and we have tried the player release
2.1.2 and also several latest svn versions (rev. 7345, 7325) and we
detected the same problem of setting velocity commands:
We detected that the velocity command given by a client program (c or
c++) is not sent every robot cycle (sip) to the p2os device. We are
logging the time when the velocity command is handled in the p2os.cc
(at the end of the HandlePositionCommand function). We tried the
experiment with the examples/libplayerc/simple.c program. We set
velocity command every cycle (after a blocking read with
playerc_position2d_set_cmd_vel()). Comparing the logged data from
p2os.cc with the logged data from simple.c (or from the writelog
driver) all the velocity commands are late for approx. 300 ms and only
every third velocity command is handled. We also tried the experiment
with the examples/libplayerc++/wander.cc client program where the
velocity commands are late for approx. 200 ms and every second
velocity command is handled. We also tried callback functions and got
similar velocity response. We even try the vfh driver and added few
lines for logging the time of commands in the function
VFH_Class::PutCommand(,), tested it with playerv and the result is the
We suppose that the problem has something to do with the TCP transport
protocol type. We tried to change the transport type to UDP but
unsuccessfully. It says that the UDP client is accepted but the error
is at subscribing to position2d interface. Here is the code we are
using to change the transport protocol type to UDP:

 // Create a client and connect it to the server.
       client = playerc_client_create(NULL, "localhost", 6665);
       if (0 != playerc_client_connect(client))
               fprintf(stderr, "error: %s\n", playerc_error_str());
               return -1;
 // Create and subscribe to a position2d device.
       position2d = playerc_position2d_create(client, 0);
       if (playerc_position2d_subscribe(position2d, PLAYER_OPEN_MODE)){
               fprintf(stderr, "error: %s\n", playerc_error_str());
               return -1;

The output message:
playerc error   : decoding failed on message from player:0 with type resp_ack:3
playerc error   : failed to get response
error: failed to get response

This is the cfg file we are using:

 name "p2os"
 provides ["odometry:::position2d:0"
          direct_wheel_vel_control 0
 port "/dev/ttyUSB0"
       max_xspeed 0.6
       max_yawspeed 100
       max_xaccel 0.3
       max_xdecel -0.3
       max_yawaccel 100
       max_yawdecel -100
       rot_kp 40
       rot_kv 20
       rot_ki 0
       trans_kp 40
       trans_kv 30
       trans_ki 0

Can you please help us with this response delays and UDP transport.
Velocity profile png-image is also attached. cmd.vel.vx is velocity
command set in the client program, p2os.cmd.vx is velocity command
logged in HandlePositionCommand function in p2os.cc and position2d->vx
is read velocity in the client program.



Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
Playerstage-developers mailing list

This email is intended for the addressee only and may contain privileged and/or confidential information