ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

When move_base goal is set in a certain direction, dwa_local_planner plans less stably and the robot is moving slower

asked 2016-07-26 09:50:17 -0600

zkytony gravatar image

updated 2021-04-24 02:51:20 -0600

miura gravatar image

I found some interesting behavior in dwa_local_planner, not sure if it is a bug, or if it can be resolved by setting parameters differently.

The behavior is that, when the goal is set in the -x direction with respect to TF origin, dwa local planner plans less stably (the local planned trajectory jumps around) and the robot moves really slowly. But when the goal is set in the +x direction, dwa local planner is much more stable, and the robot can move faster.

I demonstrated this inconsistency in the following two videos (on youtube):

In these videos, the local trajectory planned by dwa local planner is colored blue. The red line is the global path used by dwa local planner. The green line (in the second video) is the global path produced by global_planner. The dwa parameters I used are:

# Robot Configuration Parameters
max_trans_vel: 0.7
min_trans_vel: 0.1

max_vel_x: 0.7
min_vel_x: -0.05

max_rot_vel: 1.2
min_rot_vel: 0.2

acc_lim_x: 1.0
acc_lim_theta: 2.0
acc_limit_trans: 2.0

# Differential-drive robot configuration
holonomic_robot: false
acc_lim_y: 0.0
min_vel_y: 0.0
max_vel_y: 0.0
vy_samples: 0

# Goal Tolerance Parameters
yaw_goal_tolerance: 0.2
xy_goal_tolerance: 0.2
latch_xy_goal_tolerance: true

# Minimum velocity for the robot to be considered not stop
trans_stopped_vel: 0.1
rot_stopped_vel: 0.1

# Forward Simulation Parameters
sim_time: 2.0
vx_samples: 20
vy_samples: 0
vth_samples: 40
penalize_negative_x: false #no longer used

# Trajectory Scoring Parameters
path_distance_bias: 32.0
goal_distance_bias: 9.0
occdist_scale: 0.020
stop_time_buffer: 0.5

# Oscillation Prevention Parameters
oscillation_reset_dist: 0.05

# Global Plan Parameters
prune_plan: true

Can anyone reproduce such behavior? If so, should we consider this a bug?

If any clarification is helpful, please point out.

I opened a github issue about this question ( ). But since nobody responded yet on github, I though I may get some replies here. Any help is sincerely appreciated!

edit retag flag offensive close merge delete


I might have seen this issue (or something very related). I'll follow up next time I experience it.

spmaniato gravatar image spmaniato  ( 2016-07-26 11:54:49 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2020-05-20 17:13:36 -0600

Ahmed Osman gravatar image

solved by davidteixeira @ github

Alright, I found the problem: it was my odometry calculation. Specifically (if anyone runs into this issue), the velocity was being published in the 'base_link' frame, but calculated in the 'odom' frame, i.e., for this robot, which is non-holonomic, the velocity of the robot should be the same as vx; vy should always equal 0. I got the idea from the differential-drive package.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2016-07-26 09:50:17 -0600

Seen: 839 times

Last updated: May 20 '20