Ask Your Question

Using move_base for navigation, obstacle cannot be cleared timely

asked 2015-11-17 06:24:15 -0600

somebodyus gravatar image

updated 2015-11-18 02:11:44 -0600

Dear all,

I am using move_base for navigation with a SICK laser scanner. I have set the local cost map update frequency to 30Hz. However, the obstacle cannot be cleared timely when the obstacle such as a walking person moved away. The costmap will not be updated until the robot move.

For example, in the attached figure. The walking person in the green axis has moved away, but the costmap cannot clear the obstacle timely. Thus, the robot will be stuck in the virtual corner. The red axis is the robot heading direction.

image description

The parameter settings are:

obstacle_range: 2.5
raytrace_range: 3.0
robot_radius: 0.165
inflation_radius: 0.30
max_obstacle_height: 0.6
min_obstacle_height: 0.0
observation_sources: scan
scan: {sensor_frame: /laser, expected_update_rate: 30, data_type: LaserScan, topic: /scan, marking: true, clearing: true}   

  global_frame: /map
  robot_base_frame: /base_link
  update_frequency: 5.0
  publish_frequency: 0.0
  rolling_window: false
  static_map: true
  resolution: 0.05
  transform_tolerance: 2.0
  map_type: costmap

  global_frame: /odom
  robot_base_frame: /base_link
  update_frequency: 30.0 
  publish_frequency: 10.0  
  static_map: false
  rolling_window: true
  width: 6.0
  height: 6.0
  resolution: 0.05
  transform_tolerance: 2.0
  map_type: costmap
    observation_sources: laser_scan_sensor
    laser_scan_sensor: {sensor_frame: laser_link, data_type: LaserScan, topic: /scan, marking: true, clearing: true, observation_persistence: 0.0, expected_update_rate: 0.0, max_obstacle_height: 2.0, min_obstacle_height: -2.0, obstacle_range: 4.0, raytrace_range: 5.0, inf_is_valid: false}
    max_obstacle_height: 2.0
    obstacle_range: 4.0
    raytrace_range: 5.0
    track_unknown_space: false

move_base parameters:

controller_frequency: 3.0
recovery_behavior_enabled: false
clearing_rotation_allowed: false

   max_vel_x: 0.5
   min_vel_x: 0.03
   max_vel_y: 0.0   
   min_vel_y: 0.0
   min_in_place_vel_theta: 0.5
   max_vel_theta: 0.25
   min_vel_theta: -0.25
   escape_vel: -0.1
   acc_lim_x: 2.5
   acc_lim_y: 0.0 
   acc_lim_theta: 3.2

   holonomic_robot: false
   yaw_goal_tolerance: 0.15  
   xy_goal_tolerance: 0.15  
   latch_xy_goal_tolerance: false
   pdist_scale: 1.2
   gdist_scale: 0.6
   meter_scoring: true

   heading_lookahead: 0.5  
   heading_scoring: false
   heading_scoring_timestep: 0.8
   occdist_scale: 0.2 
   oscillation_reset_dist: 0.05
   publish_cost_grid_pc: false
   prune_plan: true

   sim_time: 1.0
   sim_granularity: 0.025
   angular_sim_granularity: 0.025
   vx_samples: 8
   vy_samples: 0 
   vtheta_samples: 20
   dwa: true
   simple_attractor: false

Thank you very much, Jack

edit retag flag offensive close merge delete


Can you provide more information like your move_base parameters?

Akif gravatar image Akif  ( 2015-11-17 07:40:20 -0600 )edit

The parameters are posted.

somebodyus gravatar image somebodyus  ( 2015-11-18 02:12:09 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2015-11-18 04:14:04 -0600

donmrsir gravatar image


If you have time problems with the obstacle upate in your costmap, i think you should increase the publish frequency in your local_costmap params, since this is the frequency at the map the robot uses is updated. If this doesnt help maybe there is a problem with the sensor.

Hope this helps!

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-11-17 06:24:15 -0600

Seen: 1,219 times

Last updated: Nov 18 '15