# base_local_planner does not follow the global plan accurately

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):

base_local_planner_params.yaml

TrajectoryPlannerROS:
#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

#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


local_costmap_params.yaml

local_costmap:

#Set the global and robot frames for the costmap
global_frame: odom_combined
#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
plugins:
- {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
obstacle_layer:
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 ...

edit retag 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?

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

Sort by » oldest newest most voted

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

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.

( 2015-05-18 15:19:04 -0500 )edit
1

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

( 2015-05-18 21:59:56 -0500 )edit

how did you solve ? @Naman

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

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!

more