Biasing move base for pivot turns when stopped

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

Bradley Powers
422 ●15 ●17 ●32

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?

Comments

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 ( 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 ( 2015-03-12 19:18:52 -0600 )edit

add a comment

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

Rick Armstrong
567 ●27 ●34 ●43

Bradley,

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

We had acc_lim_th set too low.
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

Comments

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 ( 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 ( 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 ( 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 ( 2017-05-18 10:40:04 -0600 )edit

add a comment

Biasing move base for pivot turns when stopped

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

Biasing move base for pivot turns when stopped edit

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

Biasing move base for pivot turns when stopped