ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
2

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


local_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
obstacle_layer:
    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

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

Comments

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
1

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

donmrsir gravatar image

Hi!

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

Question Tools

1 follower

Stats

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

Seen: 1,509 times

Last updated: Nov 18 '15