Robotics StackExchange | Archived questions

Ghost obstacles on local costmap

Hello. I'm trying to use move_base to make a robot navigate autonomously, but I'm having issues with the local costmap. Basically, the robot has a laser scanner / LIDAR panning 240°, and sometimes obstacles appear inside the 120° blind zone behind the robot (not sure how), like here :

screenshot

As you can see here, there's an obstacle on the local costmap where I've tried to set the navigation goal, and because it believes there's something, it can't find a path and just gives up. Now, these ghost obstacles actually follow the robot as they are relative to its baselink frame, thus if the robot turned around, it would see that there's no obstacle, but said obstacle would have rotated with it and still be there. So they never really go away. And that isn't even the worst case scenario, which is when a ghost obstacles appears right behind the robot, close enough that movebase believes the robot is stuck, and from there it'll just give up any order it receives.

I don't really understand why the local costmap isn't ever actually cleared when movebase says it is as a recovery behaviour. Calling /movebase/clear_costmap manually seems to work, but I don't understand why ClearCostmapRecovery isn't doing it.

I'm on ROS Jade. Here are my config files:

move_base.launch

<?xml version="1.0" encoding="utf-8"?>
<launch>
    <node pkg="move_base" type="move_base" respawn="false" name="move_base" output="screen">
        <!--<remap from="laser_scan_sensor" to="base_scan" />-->
        <rosparam file="/home/nomiros/tmp/stage_files/params/costmap_common.yaml" command="load" ns="global_costmap"/>
        <rosparam file="/home/nomiros/tmp/stage_files/params/costmap_common.yaml" command="load" ns="local_costmap"/>
        <rosparam file="/home/nomiros/tmp/stage_files/params/costmap.yaml" command="load"/>
    </node>
</launch>

costmap.yaml

controller_frequency: 5
recovery_behaviors:
- {'name': 'conservative_reset', 'type': 'clear_costmap_recovery/ClearCostmapRecovery'}
- {'name': 'aggressive_reset', 'type': 'clear_costmap_recovery/ClearCostmapRecovery'}

global_costmap:
  global_frame: /map
  robot_base_frame: base_link
  update_frequency: 0.25
  publish_frequency: 0.25
  static_map: true

local_costmap:
  global_frame: /base_footprint
  robot_base_frame: base_link
  update_frequency: 5.0
  publish_frequency: 5.0
  static_map: false
  rolling_window: true
  width: 6.0
  height: 6.0
  resolution: 0.05

TrajectoryPlannerROS:
  max_vel_x: 0.49
  min_vel_x: 0.1
  min_vel_y: 0
  max_vel_y: 0
  min_vel_z: 0
  max_vel_z: 0
  max_rotational_vel: 1.0
  min_in_place_rotational_vel: 0.1
  dwa: true
  heading_scoring: false

  acc_lim_th: 3.2
  acc_lim_x: 2.5
  acc_lim_y: 0
  acc_lim_z: 0

  holonomic_robot: false

costmap_common.yaml:

obstacle_range: 2.5
raytrace_range: 3.0
robot_radius: 0.30
inflation_radius: 0.65
origin_x: 4
origin_y: 4
width: 8
height: 8
footprint:
- [-0.2, -0.2]
- [-0.2, 0.2]
- [0.2, 0.2]
- [0.2, -0.2]

obstacle_layer:
    max_obstacle_height: 8.0

observation_sources: laser_scan_sensor

laser_scan_sensor: {sensor_frame: base_laser_link, data_type: LaserScan, topic: /scan, marking: true, clearing: true}

Asked by Nomiros on 2015-10-14 04:45:30 UTC

Comments

Answers

Looks like I found the source of the problem

local_costmap:
    global_frame: /base_footprint
    robot_base_frame: base_link

Obviously global_frame should be /map. I'm not sure how that value ended up there. I think I thought this was necessary for the local map to be centered on the robot or something. Anyway, with /map, obstacles actually stay in place relatively to the global frame and it solves the problem.

Asked by Nomiros on 2015-10-20 04:29:06 UTC

Comments