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

[David Feil-Seifer]

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