Robot gets 'stuck' in object's costmap?

asked 2018-08-17 18:01:32 -0500

asabet gravatar image

I'm navigating a jackal robot with the move_base stack, and am experiencing an issue where the robot will veer too close to the boundary of the costmap of an obstacle when executing curved trajectories, and gets stuck oscillating back and forth trying to escape once stuck. How can I avoid this behaviour?

All my move_base parameters:


  # Robot Configuration Parameters
  acc_lim_x: 2.0
  acc_lim_theta:  1.0

  max_vel_x: 0.2
  min_vel_x: 0.08

  max_vel_theta: 1.57
  min_vel_theta: -1.57
  min_in_place_vel_theta: 0.314

  holonomic_robot: false
  escape_vel: -0.25

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

  # Forward Simulation Parameters
  sim_time: 6.5
  sim_granularity: 0.03
  angular_sim_granularity: 0.05
  vx_samples: 10
  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.01 #The weighting for how much the controller should attempt to avoid obstacles. default 0.01
  pdist_scale: 0.5  #     The weighting for how much the controller should stay close to the path it was given . default 0.6
  gdist_scale: 0.6 #     The weighting for how much the controller should attempt to reach its local goal, also controls speed  default 0.8

  heading_lookahead: 0.5  #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: 0.8   #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.2
  escape_reset_theta: 0.2
map_type: costmap
origin_z: 0.0
z_resolution: 1
z_voxels: 2

obstacle_range: 2.5 #2.5
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.1

- {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.1
shutdown_costmaps: false

controller_frequency: 10.0
controller_patience: 5.0

planner_frequency: 20.0
planner_patience: 5.0

oscillation_timeout: 5.0
oscillation_distance: 0.5

recovery_behavior_enabled: true
clearing_rotation_allowed: true
   global_frame: map
   robot_base_frame: base_link
   update_frequency: 10.0
   publish_frequency: 5.0
   width: 40.0
   height: 40.0
   resolution: 0.02
   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: 10.0
   publish_frequency: 5.0
   width: 10.0
   height: 10.0
   resolution: 0.02
   static_map: false
   rolling_window: true
edit retag flag offensive close merge delete


Is this a duplicate of #q300890? If so, please close this one.

gvdhoorn gravatar image gvdhoorn  ( 2018-08-18 03:33:36 -0500 )edit