# Groovy navigation setup fails under Hydro

I have a set of navigation parameters that works perfectly under Groovy but when I switch to Hydro on the same machine and try to use the same parameters in backward-compatibility mode (i.e. by making no changes at all to my YAML files), I run into two problems:

1. The (simulated) robot now has a lot of trouble getting to a goal even in an obstacle-free environment. It tends to overshoot the goal location and do a lot of rotation around the goal.

2. While this is happening, I get a fairly constant stream of messages in the move_base terminal window similar to the following:

[ WARN] [1384802549.335952797]: Map update loop missed its desired rate of 3.0000Hz... the loop actually took 0.7676 seconds

[ WARN] [1384802549.336363131]: Control loop missed its desired rate of 3.0000Hz... the loop actually took 0.8910 seconds

[ WARN] [1384802550.183853582]: Map update loop missed its desired rate of 3.0000Hz... the loop actually took 0.5146 seconds

[ WARN] [1384802550.184482242]: Control loop missed its desired rate of 3.0000Hz... the loop actually took 0.8481 seconds

etc.

I have posted this as an issue on the ros-planning/navigation Github but so far without solution.

My setup is Ubuntu 12.04 with both Groovy and Hydro Debian installations. I am running a "fake TurtleBot" using the Arbotix package which basically assumes that the robot's odometry is perfect so it's a nice way to test the navigation parameters in an ideal enviroment.

My navigation parameters and move_base launch file can be found at the following links:

And my blank map is defined by the two files:

Any ideas on how to get his working in Hydro would be greatly appreciated!

--patrick

UPDATE 1: To reproduce the problem, follow these steps:

First install the arbotix package and the rbx1 stack:

$sudo apt-get install ros-hydro-arbotix$ cd ~/ros_workspace (or wherever your rosbuild workspace lives)
$git clone <a href="https://github.com/pirobot/rbx1">https://github.com/pirobot/rbx1</a>$ cd rbx1
$git checkout hydro-experimental$ rosmake rbx1
$rospack profile  Now test moving the fake Turtlebot around the four corners of a square: $ roscore
$roslaunch rbx1_bringup fake_turtlebot.launch$ roslaunch rbx1_nav fake_move_base_blank_map.launch
$rosrun rviz rviz -d rospack find rbx1_nav/nav.rviz$ rosrun rbx1_nav move_base_square.py

edit retag close merge delete

Can you link to the fake turtlebot package so I can try this?

( 2013-11-26 08:49:15 -0500 )edit

Hi @David Lu - I have posted details on how to reproduce as an Update above. Regarding the mangled "git clone" line in the update, I don't know how to escape the tags. It should be 'git clone https://github.com/pirobot/rbx1'

( 2013-11-26 14:39:26 -0500 )edit

Is there data coming from anywhere? It seems that the costmap update should take almost no time if there is no data...

( 2013-11-26 15:23:13 -0500 )edit

@fergs - No data that I'm aware of. The blank map is static and I'm not simulating any sensor data. What topic should I check to see if there is some weird data coming from somewhere?

( 2013-11-26 15:54:28 -0500 )edit

I forgot to push a commit to the hydro-experimental branch of rbx1 after posting Update 1 above. Please do a git pull in rbx1 to get the proper files if you cloned it before the time stamp on this comment.

( 2013-11-26 15:59:29 -0500 )edit

I have replicated the error and am puzzled. So far I am content to blame the bad driving on the update rate problems, but that's just conjecture. I'm not sure yet why the update rates are so problematic either. Will look into it more.

( 2013-11-27 06:10:49 -0500 )edit

Thanks for taking the time to replicate. I'm glad to know it's not just me! I'm curious to see what the problem turns out to be.

( 2013-11-27 06:50:49 -0500 )edit

For reference, I made a chart with the command velocities in the two scenarios. http://imgur.com/s2lY3Qu

( 2013-11-27 09:00:16 -0500 )edit

Sort by » oldest newest most voted

So it looks like the problem all along was I had set vx_samples and vtheta_samples too high. In Groovy, setting these parameters to 50 and 200 in base_local_planner_params.yaml worked well in the case of the fake TurtleBot. In Hydro, values this high appear to cause the update rate problems and the erratic robot behavior. Setting vx_samples=8 and vtheta_samples=20 like I do for the real TurtleBot seems to have solved the problem. Sorry for the wild goose chase.

more

The problem is that your local_costmap has a higher resolution than usual. The PR2 has a 6x6m local map with 2.5 cm resolution. Your turtle has 5x5m with 1cm resolution, which ends up being 4x bigger in memory.

When the turtle moves, the costmap has to recenter, which ends up taking a long while. My test shows that setting the resolution to 2.5 results in the correct behavior.

There's still the question of why this problem didn't come up in Groovy. That's a question for another day.

more

Thanks @David Lu. Unfortunately, this did not fix the problem for me. I changed the resolution to 2.5cm (0.025) in both the local and global costmap YAML files. I also changed the blank_map.yaml resolution to 2.5cm and shrunk the blank_map.pgm image to 240x240 pixels (to make it 6mx6m) and finally changed the width and height to 6.0 (instead of 5.0) in local_costmap_params.yam.

( 2013-12-05 11:54:22 -0500 )edit

OK, hold on a minute. It looks like the problem might have been my high values for vx_samples (50) and vtheta_samples (200). I just changed them to 8 and 20 respectively (the same as I use on a real robot) and I think I might have it working. Will do some more testing to be sure.

( 2013-12-05 12:00:28 -0500 )edit

I could have sworn that I checked that all the parameter values were the same, but perhaps I missed something. Glad your problem is resolved.

( 2013-12-06 05:51:29 -0500 )edit