Re: problem with setting velocity commands

Hi, 
In the Pioneer manual, which provides details of the P2OS microcontroller
etc.,  the P2OS firmware apparently runs on a 300ms update loop, so
reading/sending data more often than this will just overun the
microcontroller. I have found that on a P3DX if i try to send or recieve
(using ARIA) data to the P2DX base  more often than every 300ms or so , the
microcontroller just spends all its time servicing serial interupts and the
system stalls. It may be therefore that you do not want to update your
velocity commands so often. Possibly the Player driver is just ignoring too
frequent calls to the robot P2OS to avoid this problem?
Mick 
 

Toby Collett-3 wrote:
> 
> 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.
> 
> Toby
> 
> 2009/2/24 marija seder <[email protected]>
> 
>> Hello,
>>
>> 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
>> same.
>> 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);
>>        playerc_client_set_transport(client,PLAYERC_TRANSPORT_UDP);
>>        if (0 != playerc_client_connect(client))
>>        {
>>                fprintf(stderr, "error: %s\n", playerc_error_str());
>>                return -1;
>>        }
>>        printf("client->transport=%d\n",client->transport);
>>  // 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:
>>
>> driver
>> (
>>  name "p2os"
>>  provides ["odometry:::position2d:0"
>>            "sonar:0"
>>            "power:0"
>>            "bumper: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.
>>
>> Thanks,
>>
>> Marija
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> Playerstage-developers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>>
>>
> 
> 
> -- 
> This email is intended for the addressee only and may contain privileged
> and/or confidential information
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> Playerstage-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
> 
> 

-- 
View this message in context: http://old.nabble.com/problem-with-setting-velocity-commands-tp22164791p28793187.html
Sent from the playerstage-developers mailing list archive at Nabble.com.


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo