Move_base only send null velocities (robot it's stuck)

asked 2022-01-22 10:39:06 -0500

updated 2022-01-25 03:09:25 -0500

Hi, I have a problem using the navigation stack. Everything is set up but I noticed that move_base only send velocities that have all zeroes as values for some time and then abort the plan because it says the robot appears stuck. This is the error I get:

[ WARN] [1642850369.065890614, 1625.003000000]: Clearing both costmaps to unstuck robot (1.84m).
[ WARN] [1642850369.468946798, 1625.153000000]: Rotate recovery behavior started.
[ERROR] [1642850369.469160023, 1625.153000000]: Rotate recovery can't rotate in place because there is a potential collision. Cost: -1.00
[ERROR] [1642850369.978050469, 1625.302000000]: Aborting because a valid control could not be found. Even after executing all recovery behaviors

The problem appear with every goal I send, the only movement I get is when the robot execute the escape route and apply a negative velocity.

These are my parameters files:

Base local planner:

  max_vel_x: 1.0
  min_vel_x: 0.5
  max_vel_theta: 1.0
  min_in_place_vel_theta: 0.4

  acc_lim_theta: 2
  acc_lim_x: 1

  escape_vel: -0.305

  holonomic_robot: false

  xy_goal_tolerance:  0.20
  yaw_goal_tolerance: 0.20

  sim_time: 3.0
  sim_granularity: 0.07
  vx_samples: 3
  vtheta_samples: 3
  vtheta_samples: 20

  goal_distance_bias: 0.3
  path_distance_bias: 0.5
  occdist_scale: 0.01
  heading_lookahead: 0.325
  dwa: true

  oscillation_reset_dist: 0.05
  meter_scoring: true

Costmap common params

obstacle_range: 2.5
raytrace_range: 5.0
footprint: [[0.21, 0.22], [0.21, -0.22], [-0.21, -0.22], [-0.21, 0.22]]
#robot_radius: ir_of_robot
inflation_radius: 0.55

transform_tolerance: 0.5

controller_patience: 2.0

    allow_unknown: true

recovery_behaviors: [
    {name: conservative_clear, type: clear_costmap_recovery/ClearCostmapRecovery},
    {name: aggressive_clear, type: clear_costmap_recovery/ClearCostmapRecovery}


    reset_distance: 3.00
    reset_distance: 1.84

Global costmap

  global_frame: map
  robot_base_frame: base_footprint
  update_frequency: 0.5
  publish_frequency: 0.5
  static_map: true

Local costmap params

  global_frame: map
  robot_base_frame: base_footprint
  update_frequency: 2.0
  publish_frequency: 2.0
  static_map: false
  rolling_window: true
  width: 3.0
  height: 3.0
  resolution: 0.05

  transform_tolerance: 0.5

  observation_sources: point_cloud_sensor

  point_cloud_sensor: {
    sensor_frame: zed2_camera_center,
    data_type: PointCloud2, 
    topic: pointCloud_topic, 
    expected_update_rate: 0.5, 
    marking: true, 
    clearing: true,
    min_obstacle_height: -99999.0,
    max_obstacle_height: 50,

I am using the simulated environment provided by leo Rtabmap is used to get the an occupancyGrid map from the camera images and it looks quite right by looking at it from rviz.

Looking at the maps the robot doesn't look stuck, in the following image the global costmap is represented as circles around the obstacles, while the local costmap is the cone in front of the robot.

Local and global costmap

edit retag flag offensive close merge delete



The image shows that the robot is supposed to be inside the obstacle. Therefore, we believe that it is stuck.

I think point_cloud_sensor is the relevant sensor. Why don't you comment observation_sources: point_cloud_sensor for once and try to move it?

miura gravatar image miura  ( 2022-01-25 16:38:47 -0500 )edit

Thank you for answering @miura! I commented that part and now the robot moves, it doesn't move perfectly but it's a start.

I think that my error is to pass the entire point cloud generated by the stereo camera to the local costmap but in this way it could consider also the ground as obstacle.

A package that could help me is obstacle_detection from rtabmap that generate obstacles from the point cloud, I'll try to use that package and use an approach similar to this page rtabmap/tutorial/StereoOutdoorNavigation.

AlessioParmeggiani gravatar image AlessioParmeggiani  ( 2022-01-26 03:23:22 -0500 )edit

I'm glad to hear that you've made progress.

miura gravatar image miura  ( 2022-01-26 16:53:55 -0500 )edit