A few things here, I would try player CVS if you can and see if the problem is solved there. It definately shouldn't be a busy loop to acieve pulse, probably the best option would be to have a timeout on the SendRecieve so that pulse can resend if nothing is recieved. This should not be too hard to modify.
If you run player with valgrind (valgrind --leak-check=yes player pioneer.cfg) then you might get some more hints as to the source of the issue. This will show up any buffer overruns or other nasty memory errors/leaks.
Finally the best option (as well as tracking down the bug in the SIP class) is to repeat the commands in the client anyway. There is a reason for the watchdog, and it generally is a nice thing to have the robot stop if your client crashes or someone stops it while the robot is moving,
Hope that helps a little,
I'm currently trying to have my pioneer 3 working with Player 2.0.4, but I've run into quite a few problems, notably with the watchdog going into safety mode every 2 second, and thus canceling my commands. I finally discovered the pulse option in the p2os driver, which does solve the problem of the watchdog going into safety mode when I don't want it to, but now the player server is behaving a bit strangely.
Sometimes it just segfaults after a while, sometimes it crashes with glibc complaining about memory corruption, and sometimes it runs fine. So there's clearly some pointer weirdness at work here... I also noticed that with the pulse option, player is always using 100% of the CPU whereas without it, it hardly uses any cpu cycles at all. Which makes sense when one looks at the code of p2oc.cc, because if the pulse option is on, then the Main loops around the delay check without ever pausing, whereas if pulse is no activated, then the Main does a blocking SendReceive, waiting for input. My guess is that you have a bug in the SIP class code somewhere, that triggers while you run with the pulse option, because you end up running a lot more code, and the bug triggers a lot faster.
I tried to pinpoint the exact location of the problem, but no luck.
This is a very annoying bug, because it really crashes out of nowhere, whatever the device(s) subscribed. But if I subscribe to none, then it never crashes (or at least not for the 5mn I let it run). So the SIP class is a very likely culprit, since it's not running while there's no device subscribed.
"Pulse" is set to a reasonable amount, I tried 0.5 and 1, with the same consequences.
I thought for a while to add a nanosleep to slow down the loop when pulse is on, but I'm afraid I gonna lose packets. Another solution would be to allow the client to send a pulse command, instead of asking the server to do it.
Thanks a lot in advance!
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Playerstage-users mailing list