Why so much spinning in place with move_base?

Hello,

I'm trying to tune move_base under fairly ideal circumstances so I did not think it would be this hard. I am using the arbotix_python base controller in "fake" mode which basically just moves the simulated robot exactly as it's told on /cmd_vel. So I am treating it as an "ideal" test case with no physics.

I then have a Python script that moves a simulated TurtleBot to the four corners of a 1 meter square on a blank map using the simple move_base action server.

I've run through the Navigation Tuning Guide and spent many hours of trial and error tweaking the various parameters using dynamic_reconfigure but I still can't figure out why the robot has such a tendency to spin in place before it gets to a goal even when there are no obstacles and I have the recovery and clearing behaviors disabled. The problem gets worse as I make the goal tolerances smaller--for example, setting the xy_goal_tolerance to 0.05 tends to guarantee spinning and often timing out before getting to the goal.

I'm wondering if others have figured out any secrets behind this spinning behavior. I'm also wondering if not having any real or simulated observation sources could be causing it?

I get the same results whether I use the latest Electric or Fuerte debian install under Ubuntu 11.10.

EDIT 1:

My navigation config files can be found here.

And the script that moves the robot in a square can be found here.

Thanks!
patrick

edit retag close merge delete

Could you post the navigation configs you are using?

( 2012-07-10 16:02:00 -0600 )edit
1

Also note that you should state in your config files which local planner to use explicitly. By default move_base will use trajectory_planner_ros, which is tweaked for the PR2 and has "hidden" recovery behaviors. Prefer to use the dwa_planner_ros.

( 2012-07-10 22:19:52 -0600 )edit

Thanks @KruseT. I just now tried using dwa_planner_ros explicitly and got some crazy results--robot going all over the place instead of just hitting the corners of the square. However, using trajectory_planner_ros with parameter dwa set to True gives really nice results.

( 2012-07-11 04:18:26 -0600 )edit

The parameters may be a bit different between trajecotry_planner_ros and dwa_planner_ros. Else both local planners are very similar (dwa_planner is something like trajectory_planner_ros 2.0).

( 2012-07-11 12:43:47 -0600 )edit

I thought I had set the parameters correctly based on the Wiki page but I'll try again when I get a chance. In the meantime, does setting the dwa parameter to True do a similar job as using the dwa_planner directly?

( 2012-07-12 04:02:20 -0600 )edit

Sort by » oldest newest most voted

Well, I think I might have found the root of most of my problems. I was getting the most spinning when I set the xy_goal_tolerance to 0.05 or less. But I just realized that my blank map only had a resolution of 0.05. When I set the map resolution to 0.01, I was able to get good behavior without all the spinning. So perhaps in the end that's all it was...

more

I had good luck turning down k_rot, max_rot_vel, and min_rot_vel in /config/planner.yaml. If you're familiar with control theory and root locus plots, this makes sense. The gain was cranked up too high so the system oscillated and became unstable.

more

@AndyZe Can you specify the original values in the planner.yaml file and what values you changed to? Thanks.

( 2017-05-07 08:30:06 -0600 )edit
1

Actually I'm not sure that answer helps at all. Found a better way:

oscillation_timeout: 5.0 (wasn't set at all, originally)

But these are my other settings: k_trans=0.5, k_rot=1. max_rot_vel no longer applies. Originally those were k_trans: 3.0 k_rot: 3.0

( 2017-05-07 11:05:47 -0600 )edit

Thanks for the response, sorry for my ignorance, but why is oscillation_timeout the better parameter to adjust? (For the time being I have decided to adjust the max_rot_vel parameter found in the dwa_local_planner_params.yaml to resolve the spinning)

( 2017-05-08 22:00:45 -0600 )edit
1

oscillation_timeout and oscillation_reset_distance force the robot to stop moving if it hasn't translated more than oscillation_reset_distance in the time determined by oscillation_timeout.

( 2017-05-09 07:40:03 -0600 )edit