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