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