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

[Matt Bergsma]

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 aren’t 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 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 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 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
>
>
>
>
>
> _______________________________________________
>
> ros-users mailing list
>
> ros-users at code.ros.org
>
> https://code.ros.org/mailman/listinfo/ros-users