ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Biasing move base for pivot turns when stopped

asked 2015-01-14 12:06:10 -0600

Bradley Powers gravatar image

Hi all,

I am working on a robot simulated in Gazebo. Our environment has many rather narrow aisles that are ~2.5x the diameter of the robot in width. Currently, when our robot needs to turn around in an aisle, it plans "sweeping turns," that is, where vx and vtheta are both non-zero. This typically ends up with the robot moving too close to an obstacle and transitioning to recovery behaviors. Is there a way to bias move_base toward pivot turns?

edit retag flag offensive close merge delete


We have the same issue with our robot, using the DWA Planner. If the 'bot is initially facing in the direction of the global plan, navigation works nicely. If the robot is given a goal directly behind, instead of simply pivoting in place, it does a big, lazy turn. I'm wondering: bug, or feature? :)

Rick Armstrong gravatar image Rick Armstrong  ( 2015-03-12 19:17:34 -0600 )edit

In other words, is this a tuning issue, or would it be smarter to add some additional code to turn the robot in the right direction before proceeding?

Rick Armstrong gravatar image Rick Armstrong  ( 2015-03-12 19:18:52 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2015-03-27 03:46:47 -0600

Rick Armstrong gravatar image


After some more experimentation and tuning, we've found two things:

  1. We had acc_lim_th set too low.
  2. As mentioned in the Navigation Tuning Guide, sim_time matters a lot.

With these set correctly, the planner selects "turn in-place" as a valid trajectory.

Another thing that's helping with our understanding of dwa_local_planner is to visualize the trajectory cost cloud, as described here. We cut power to the robot's drive train, fire up rqt_reconfigure, then issue a nav goal in RViz. From there, we can watch the planner do its thing while tweaking the DWA-related params.

edit flag offensive delete link more


Hey Rick, you mentioned tuning sim_time helps a lot. What were your findings? Did it manage a "in-place" rotation with a high or lower sim time? I'm having the same issue and I feel like a large sim_time causes these large sweeping trajectories. However a small value has poor ability to navigate

mcarr gravatar image mcarr  ( 2017-05-17 06:21:30 -0600 )edit

It's been a while, but if I remember correctly, it was "increase". Biggest help in picking a good sim time was visualizing the trajectories in RViz, while tweaking the params in rqt_reconfigure. As soon as we did that, tuning became much easier.

Rick Armstrong gravatar image Rick Armstrong  ( 2017-05-17 11:50:22 -0600 )edit

Hi Rick, My problem was that when I set a goal directly behind the robot, the local planner failed to find a path. By viewing the trajectories, I could see my acc_lim_th was much too low (even though I had determined it experimentally). Increase this and it all works great now!

mcarr gravatar image mcarr  ( 2017-05-18 08:40:56 -0600 )edit

Glad to hear it! That trajectory visualization really lets you know what it's "thinking"; makes all the difference.

Rick Armstrong gravatar image Rick Armstrong  ( 2017-05-18 10:40:04 -0600 )edit

Question Tools

1 follower


Asked: 2015-01-14 12:06:10 -0600

Seen: 446 times

Last updated: Mar 27 '15