[ros-users] Inconsistant timing issues with powerbot-sh running P2OS

Wed Dec 15 00:18:06 UTC 2010

David;

Sorry for the delay in getting back to you here. I've run your tests and
the robot worked fine. It appears that the problem was in my code, I
believe I was sending too many stop/disable messages which was bogging
down the p2os node itself (max rate for either would be around 28/100mS)
or causing problems with the queue system in ROS is my guess. I've
changed the code so it will only send one stop and one disable command
without the condition being acknowledged from an external source.

Thanks for the help;
Matt

On Thu, 2010-12-09 at 13:15 -0800, David Feil-Seifer wrote:
> Matt-
> 
> I just double-checked both stopping by using the e-stop and by setting
> velocity to 0,0 and they both worked almost instantly. Do me a favor
> so that I can help you isolate where the delay is:
> 
> 1.) Install the 0.2.1 version of the driver (or the trunk version is
> fine as well)
> 2.) Run a roscore node on your non-pioneer computer
> 3.) run `roslaunch p2os_launch p2os_driver.launch` on the pioneer
> 4.) run `rosrun p2os_dashboard p2os_dashboard` on the non-pioneer computer
> 5.) set the pioneer to move forward using teleop_keyboard.launch
> 
> now stop the robot using either the spacebar in the
> teleop_keyboard.launch window or by using the `motors halt` button on
> p2os_dashboard, both should stop instantly. If they do, I'd wager the
> problem is in your code somewhere. If they do not, I would check your
> wireless connection between the computers.
> 
> Hope things go well.
> 
> -Dave
> 
> On Wed, Dec 8, 2010 at 2:01 PM, Matt Bergsma <mjb4 at sfu.ca> wrote:
> > Dave -
> >
> > Thanks that'd be appreciated, hopefully that will allow me to pinpoint the
> > delay a bit better.
> >
> > A quick aside, that may or may not be applicable to my problem, but to my
> > understanding with ros, if both the core and some node(s) are running on the
> > same physical machine, but arent configured to use the local loopback in
> > the hosts file (127.0.0.1) they will still communicate via the network card
> > itself. Or am I incorrect in that assumption?
> >
> > Matt
> >
> > Matt-
> >
> > I'll take a look at the p2os driver to see if I can pin down the
> > problems that you're having. The earliest that I will be able to do
> > this is tomorrow, however.
> >
> > -Dave
> >
> > On Wed, Dec 8, 2010 at 12:37 PM, Matt B <fooloftherandom at gmail.com> wrote:
> >> 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 Im 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 at 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 hasnt been
> >> significantly modified, except to talk using the ROS framework to the
> >> applicable channels. So I would expect it isnt the issue.
> >>
> >>
> >>
> >> Hopefully someone can shed some light on the issues encountered.
> >>
> >>
> >>
> >> Thanks, Matt Bergsma
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >>
> >> ros-users mailing list
> >>
> >> ros-users at code.ros.org
> >>
> >> https://code.ros.org/mailman/listinfo/ros-users
> >
> > _______________________________________________
> > ros-users mailing list
> > ros-users at code.ros.org
> > https://code.ros.org/mailman/listinfo/ros-users
> >
> 