Local planner is not able to reach a goal in free space

asked 2019-07-22 22:06:33 -0500


I'm having some problems in tuning up the local planner for a custom skid-steer wheeled robot to be able to navigate to waypoints in free space. I'm using the gazebo skid_steer_drive_controller to simulate it. I still don't understand why the local planner is not turning in place in order to reach the desired goal orientation instead of moving forward and turn to reach it. This is the video of what is happening:


,as you can see in the video, the robot is not able to reach the goal. Similar robots, like Husky, are able to reach goals by turning in place. For example, this video:


. In fact, I'm using the same configuration params for the common, local and global costmap and the local planner as in the simulated Husky in the video. For reference, I'm posting these configuration params.

By the way, this is a similar question but I'm my case, I'm not dealing with obstacles at the moment:


Please let me know any other information that could be useful.


map_type: costmap
origin_z: 0.0
z_resolution: 1 # The z resolution of the map in meters/cell.
z_voxels: 2  # The number of voxels to in each vertical column, the height of the grid is z resolution * z voxels.

obstacle_range: 2.5
raytrace_range: 5.5

publish_voxel_map: false

footprint: [ [0.23, 0.23], [0.23, -0.23], [-0.23, -0.23], [-0.23, 0.23] ]
inflation_radius: 0.35
cost_scaling_factor: 1 # slope of the cost decay curve with respect to distance from the object. lower makes robot stay further from obstacles

# transform_tolerance: 5

robot_radius: 0.25
footprint_padding: 0.2

observation_sources: laser_scan_sensor

laser_scan_sensor: {sensor_frame: hokuyo, data_type: LaserScan, topic: /skid_steer_bot/laser/scan, marking: true, clearing: true}


  global_frame: odom
  robot_base_frame: robot_footprint
  update_frequency: 20.0
  publish_frequency: 5.0
  width: 30.0
  height: 30.0
  # resolution: 0.05
  rolling_window: true
  static_map: false  
  track_unknown_space: true
  # plugins:
  #   - {name: obstacles_laser,           type: "costmap_2d::ObstacleLayer"}
  #   - {name: inflation,                 type: "costmap_2d::InflationLayer"}


  global_frame: odom
  robot_base_frame: robot_footprint
  update_frequency: 1.0
  publish_frequency: 2.0
  static_map: false
  rolling_window: true
  width: 10.0
  height: 10.0
  resolution: 0.05


  max_vel_x: 0.6
  # min_vel_x: 0.15
  min_vel_x: 0.15 # Allowing velocities too low will will stop the obstacle avoidance because low velocities won't actually be high enough to move the robot
  max_vel_theta: 1.0
  min_vel_theta: -1.0
  min_in_place_vel_theta: 0.4

  acc_lim_theta: 1.0
  acc_lim_x: 1.0
  acc_lim_y: 0.0

  holonomic_robot: false

  # New Stuff

  escape_vel: -0.2

  # Goal Tolerance Parameters
  yaw_goal_tolerance: 0.1  # in rads
  xy_goal_tolerance: 0.2  # in meters
  latch_xy_goal_tolerance: false

  # Forward Simulation Parameters
    # these parameters change how the planner simulates trajectories at each update and therefore changes the optimal trajectory that is chosen
    # These should be adjusted based on your computer performance
  sim_time: 2.0   # setting time of each simulation that it must evaluate. Higher will create longer curves but too low can limit performance (<2)
  sim_granularity: 0.02 # the step size ...
edit retag flag offensive close merge delete


im not sure how different is your custom skid-steer wheeled robot from the husky. As I can see from the video maybe you can try increasing the angular velocities and angular acceleration. This will force the robot to start turning earlier.

pavel92 gravatar image pavel92  ( 2019-07-24 06:12:17 -0500 )edit