Ask Your Question

base_local_planner does not follow the global plan accurately

asked 2015-05-15 10:34:39 -0500

Naman gravatar image

updated 2015-05-18 14:30:19 -0500

Hi all,

I have a mobile robot which is navigating around a room, I already have the map of the room. I am using rotary encoders for odometry. I am fusing the data from Rotary encoders and IMU using robot_pose_ekf. I am using amcl for localization and move_base for planning with default global planner (A*) and Trajectory Planner as the local planner. The global planner gives the correct path to the goal but the problem is that the local planner is not able to follow that path properly. It tries to follow the path but overshoots and then again tries to come back and overshoots and so on. I recorded the data in a bag file and here is the link to the video showing what exactly is the problem (the last case is really bad):


  #Set the acceleration limits of the robot
  acc_lim_th: 3.2
  acc_lim_x: 2.0
  acc_lim_y: 0

  #Set the velocity limits of the robot
  max_vel_x: 1.0
  min_vel_x: 0.1
  max_vel_theta: 1.5
  min_vel_theta: -1.5
  min_in_place_vel_theta: 0.8

  #The velocity the robot will command when trying to escape from a stuck situation
  escape_vel: -0.1

  #For this example, we'll use a holonomic robot
  holonomic_robot: false

  #Set the tolerance on achieving a goal
  xy_goal_tolerance: 0.15
  yaw_goal_tolerance: 0.15
  latch_xy_goal_tolerance: false

  #We'll configure how long and with what granularity we'll forward simulate trajectories
  sim_time: 1.5
  sim_granularity: 0.025
  angular_sim_granularity: 0.025
  vx_samples: 5
  vtheta_samples: 20

  #Parameters for scoring trajectories
  goal_distance_bias: 0.8
  path_distance_bias: 1.0
  gdist_scale: 0.8
  pdist_scale: 1.0
  occdist_scale: 0.01
  heading_lookahead: 0.325

 #We'll use the Trajectory Rollout to control instead of Dynamic Window Approach for this example
 dwa: false

  #How far the robot must travel before oscillation flags are reset
  oscillation_reset_dist: 0.05

  #Eat up the plan as the robot moves along it
  prune_plan: false

  # Global Frame id
  global_frame_id: odom_combined



  #Set the global and robot frames for the costmap
  global_frame: odom_combined
  robot_base_frame: base_link
  #Set the update and publish frequency of the costmap
  update_frequency: 5.0
  publish_frequency: 2.0
  #We'll configure this costmap to be a rolling window... meaning it is always
  #centered at the robot
  static_map: false
  rolling_window: true
  width: 3.0
  height: 3.0
  resolution: 0.025
  origin_x: 0.0
  origin_y: 0.0
  - {name: obstacle_layer, type: "costmap_2d::ObstacleLayer"}
  - {name: inflation_layer, type: "costmap_2d::InflationLayer"}
  #Configuration for the sensors that the costmap will use to update a map
    observation_sources: laser_scan_sensor
    laser_scan_sensor: {data_type: LaserScan, sensor_frame: /laser, topic: /scan, expected_update_rate: 0.4,
      observation_persistence: 0.0, marking: true, clearing: true, max_obstacle_height: 2.0, min_obstacle_height: 0.0, inf_is_valid: true}

I reduced the size of the local costmap but that also did not improve results by much. I feel its a very common problem, so if anyone has faced similar issues before, any help will be appreciated from them. Please let me know if you need more information from my side.

Update: After modifying the parameters ... (more)

edit retag flag offensive close merge delete


I see you uploaded a new video which seems to follow the plan much better, was it the sim_time that made the difference?

miguel gravatar image miguel  ( 2015-07-23 12:17:32 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2015-05-17 20:46:22 -0500

I had a similar problem and the cause was slow hardware running the local planner. Slow hardware + high robot speed = disaster

I had to relax the forward simulation constrains, specially the control_frequency parameter (in my case I set it to 10Hz instead of the default 20Hz) and reduce the max linear and angular speed of the robot.

I hope this helps

edit flag offensive delete link more


Thanks @Martin, that helped but still it is not close to desired.. I have updated the original question with modified parameters and the new video..Do you have any more suggestions on how to further improve it or what parameters to change? Thanks in advance.

Naman gravatar image Naman  ( 2015-05-18 15:19:04 -0500 )edit

Hi @Naman, you can still reduce the forward sim_time from 1.5 to 1 second. Also, to confirm that your hardware is struggling executing the local planner, you can check how much CPU the move_base is taking during autonomous navigation. If it is close to 100% you are in trouble

Martin Peris gravatar image Martin Peris  ( 2015-05-18 21:59:56 -0500 )edit

how did you solve ? @Naman

osmancns gravatar image osmancns  ( 2015-09-16 07:22:00 -0500 )edit

answered 2015-05-19 22:05:33 -0500

Yijia gravatar image

Hi,Naman, martin have pointed some good tips. But, map's resolution is a unnoticed point, I solved the similar problem by changing the costmap's resolution. The costmap's resolution must be equal or greater than the gmapping's map resolution. Hope it helps you out. GOOD LUCK!

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

1 follower


Asked: 2015-05-15 10:34:39 -0500

Seen: 3,525 times

Last updated: May 19 '15