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

Ghost obstacles on local costmap [closed]

asked 2015-10-14 07:11:44 -0500

Nomiros gravatar image

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 :


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 base_link 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 move_base 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 move_base says it is as a recovery behaviour. Calling /move_base/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:


<?xml version="1.0" encoding="utf-8"?>
    <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"/>


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

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

  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

  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


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
- [-0.2, -0.2]
- [-0.2, 0.2]
- [0.2, 0.2]
- [0.2, -0.2]

    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}
edit retag flag offensive reopen merge delete

Closed for the following reason the question is answered, right answer was accepted by Nomiros
close date 2015-10-20 04:29:42.066466

1 Answer

Sort by » oldest newest most voted

answered 2015-10-20 04:29:06 -0500

Nomiros gravatar image

Looks like I found the source of the problem

    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.

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2015-10-14 04:45:30 -0500

Seen: 1,533 times

Last updated: Oct 20 '15