How to make move_base more stable?

asked 2018-08-11 23:28:38 -0600

asabet gravatar image

updated 2018-08-13 17:16:02 -0600

I'm using move_base with costmap_2d and gmapping to navigate a jackal robot. It's motion is somewhat erratic at times and it takes the long way round sometimes when rotating in place. What parameters can I modify to smoothen its trajectory?


  # Robot Configuration Parameters
  acc_lim_x: 2.0
  acc_lim_theta:  1.5

  max_vel_x: 0.13
  min_vel_x: 0.1

  max_vel_theta: 1.0
  min_vel_theta: -1.0
  min_in_place_vel_theta: 0.15

  holonomic_robot: false
  escape_vel: -0.3

  # Goal Tolerance Parameters
  yaw_goal_tolerance: 0.2
  xy_goal_tolerance: 0.3
  latch_xy_goal_tolerance: false

  # Forward Simulation Parameters
  sim_time: 2.0
  sim_granularity: 0.02
  angular_sim_granularity: 0.02
  vx_samples: 6
  vtheta_samples: 20
  controller_frequency: 20.0

  # Trajectory scoring parameters
  meter_scoring: true # Whether the gdist_scale and pdist_scale parameters should assume that goal_distance and path_distance are expressed in units of meters or cells. Cells are assumed by default (false).
  occdist_scale:  0.1 #The weighting for how much the controller should attempt to avoid obstacles. default 0.01
  pdist_scale: 0.6  #     The weighting for how much the controller should stay close to the path it was given . default 0.6
  gdist_scale: 0.8 #     The weighting for how much the controller should attempt to reach its local goal, also controls speed  default 0.8

  heading_lookahead: 0.6  #How far to look ahead in meters when scoring different in-place-rotation trajectories
  heading_scoring: false  #Whether to score based on the robot's heading to the path or its distance from the path. default false
  heading_scoring_timestep: 1.0   #How far to look ahead in time in seconds along the simulated trajectory when using heading scoring (double, default: 0.8)
  dwa: true #Whether to use the Dynamic Window Approach (DWA)_ or whether to use Trajectory Rollout
  simple_attractor: false
  publish_cost_grid_pc: true

  #Oscillation Prevention Parameters
  oscillation_reset_dist: 0.05 #How far the robot must travel in meters before oscillation flags are reset (double, default: 0.05)
  escape_reset_dist: 0.1
  escape_reset_theta: 0.1


map_type: costmap
origin_z: 0.0
z_resolution: 1
z_voxels: 2

obstacle_range: 1.0
raytrace_range: 3.0

publish_voxel_map: false
transform_tolerance: 0.5
meter_scoring: true

footprint: [[-0.21, -0.165], [-0.21, 0.165], [0.21, 0.165], [0.21, -0.165]]
footprint_padding: 0.05

- {name: obstacles_layer, type: "costmap_2d::ObstacleLayer"}
- {name: inflater_layer, type: "costmap_2d::InflationLayer"}

  observation_sources: scan
  scan: {sensor_frame: front_laser, data_type: LaserScan, topic: /scan, marking: true, clearing: true, min_obstacle_height: -2.0, max_obstacle_height: 2.0, obstacle_range: 2.5, raytrace_range: 3.0}

 inflation_radius: 0.10

move_base_params.yaml: shutdown_costmaps: false

controller_frequency: 20.0
controller_patience: 15.0

planner_frequency: 20.0
planner_patience: 5.0

oscillation_timeout: 0.0
oscillation_distance: 0.5

recovery_behavior_enabled: true


   global_frame: map
   robot_base_frame: base_link
   update_frequency: 20.0
   publish_frequency: 5.0
   width: 40.0
   height: 40.0
   resolution: 0.05
   origin_x: 0.0
   origin_y: 0.0
   static_map: true
   rolling_window: false

   - {name: static_layer, type: "costmap_2d::StaticLayer"}
   - {name: obstacles_layer, type: "costmap_2d::ObstacleLayer"}
   - {name: inflater_layer, type: "costmap_2d::InflationLayer"}


   global_frame: map
   robot_base_frame: base_link
   update_frequency: 20.0
   publish_frequency: 5.0
   width: 10.0
   height: 10.0
   resolution: 0.05
   static_map: false
   rolling_window: true
edit retag flag offensive close merge delete



May I suggest a topic change? Your question is about how to improve (perceived) quality of plans and their execution. When you ask "how to make X more stable", it sounds like you're asking how to make X more robust against failures, or to make it crash less often. That would be something else.

gvdhoorn gravatar image gvdhoorn  ( 2018-08-12 01:38:37 -0600 )edit

It's movement is very jerky and non-sensical, how do I improve it?

asabet gravatar image asabet  ( 2018-08-12 07:53:43 -0600 )edit

What local planner are you using? Have you tried tuning the parameters of your local planner?

stevejp gravatar image stevejp  ( 2018-08-12 15:44:34 -0600 )edit

Post your move_base.launch file here. It will be easier for us to see which parameters and planners are you using.

pavel92 gravatar image pavel92  ( 2018-08-13 01:29:05 -0600 )edit

Edited my post to include move_base parameters. I call move_base with that configuration.

asabet gravatar image asabet  ( 2018-08-13 17:17:01 -0600 )edit

by "long way" you mean it does not rotate in the shortest direction of the path or it goes around obstacle but not in the most optimal way?

pavel92 gravatar image pavel92  ( 2018-08-14 01:17:59 -0600 )edit

you can definitely increase the max_vel_x of the jackal since 0.13 seems to be pretty low (2.0 m/s is the max limit the Jackal can go)

pavel92 gravatar image pavel92  ( 2018-08-14 01:19:56 -0600 )edit

I mean when it has to make a rotation to adjust its path, or to align with a nav goal pose, it rotates the long way instead of the short way. Also, I think it misbehaves when it gets caught in the costmap of an object while trying to reach its goal.

asabet gravatar image asabet  ( 2018-08-14 08:03:28 -0600 )edit