Both the robot, and my laptop are running the latest version of Cturtle, along with the latest version of the p2os node, and have run a few more tests, while watching the output (the failsafe node, reports to ros_out when either mode is activated or configuration changes are made)
And what I’m seeing is my code sending the commands as expected, when expected based on the sonar data itself (both sonar data and the times of activation, agree with the previous performance under ARIA libraries) but especially in the case of the disable command being sent since an audible response from the brakes on the powerbot engaging can be heard, a lag of up to ½ a second or so can be heard, between when the failsafe algorithm sends the disable command to /cmd_motor_state and when the motor brakes engage. I do expect a less noticeable lag on occasion of up to 100mS due to the way the ARCOS controller itself works, but this is well beyond that.
As for more specific information on each computer, the powerbot is currently running ubuntu 9.10 and my laptop is running ubuntu 10.04x64. Without modifying the p2os node itself, theres no way I can think of to be able to tell whether the lag is coming from our network, the p2os node, or the ARCOS controller communication itself.
Matt
From: Tully Foote [mailto:tfoote@willowgarage.com]
Sent: Tuesday, December 07, 2010 9:53 PM
To: User discussions
Subject: Re: [ros-users] Inconsistant timing issues with powerbot-sh running P2OS
Hi Matt,
Without a lot more information we can't help you much. Please see http://www.ros.org/wiki/Support#Guidelines_for_mailing_list_messages
I would suggest that you put in some debugging statements to make sure that the obstacles is being detected. If you can track down more specifically where you think there is a problem and provide a way for us to reproduce the problem that would allow us to help you.
Tully
On 12/07/2010 09:20 PM, Matt Bergsma wrote:
Hello;
Currently working on a Sonar Based ‘failsafe’ object avoidance code, which was originally developed and tested in Aria, and since porting it from Aria to ros – p2os I have found its gone from behaving as expected to being very inconsistent at best, even after increasing its internal parameters so both stop and stop/disable zones are significantly larger. I would expect part of this would be lag in the subnet the robot and my laptop are connected into, but even moving the code onto the powerbot these same issues are occurring. Eg. The robot is hitting our test object.
Note – The first set of tests had only the p2os node on the powerbot, and roscore, my failsafe code, and a modified version of the teleop_keyboard base code from the p2os package running on an hp tm2-2050 laptop, and when the code was moved to the powerbot everything except for the teleop code was moved to run on the powerbot but not utilizing the local loopback.
When this code was developed and tested in aria, it behaved as expected, and its very light weight (running a simple profile in aria was giving run times of around 28s for 1,000,000 sets of readings and decision on all the sonar sensors) which ran on the powerbot itself, and the code hasn’t been significantly modified, except to talk using the ROS framework to the applicable channels. So I would expect it isn’t the issue.
Hopefully someone can shed some light on the issues encountered.
Thanks, Matt Bergsma