Costmaps don't get cleared after calling clear_costmaps service
My costmaps don't change at all even after I call:
rosservice call /move_base/clear_costmaps "{}"
Essentially I'm trying to identify the issue for when dragging the robot using Gazebo, resulting in an overlapping map as it's shown in the image:
Below I post the local and global costmap properties for your reference:
local costmap:
local_costmap:
global_frame: odom # odom_combined
robot_base_frame: base_footprint
update_frequency: 10 # 5.0
publish_frequency: 10 # 5.0
static_map: false
rolling_window: true
width: 4.0
height: 4.0
resolution: 0.05
# transform_tolerance: 1.0
plugins:
# - {name: static_layer, type: "costmap_2d::StaticLayer"}
- {name: obstacle_layer, type: "costmap_2d::VoxelLayer"}
- {name: inflation_layer, type: "costmap_2d::InflationLayer"}
global costmap:
global_costmap:
global_frame: map #map
robot_base_frame: base_footprint
update_frequency: 20 # Set this as high as the cpu resources allow
publish_frequency: 10 #2.5
# static_map: false
static_map: true
rolling_window: false
track_unknown_space: true
width: 1024
height: 1024
origin_x: -51.25
origin_y: -51.25
resolution: 0.1
plugins:
- {name: static_layer, type: "costmap_2d::StaticLayer"}
Any help is highly appreciated
clear_costmaps
serviceclears the obstacles in thecostmapbeing used bymove_base. I do not see any obstavle in the map image attached in the question.This is true. Thank you for noticing. However, how can I clean-update the map so that it doesn't duplicate when I drag the robot with Gazebo?
I don't really understand what do you mean by this - 'when dragging the robot using Gazebo, resulting in an overlapping map'?
What do you mean by 'dragging'? What do you mean by 'overlapping map'?
Also, by 'overlapping map', are you saying that when you move the bot to a new position, the old portions of the
mapare not updated?Sorry. Difficult to find the right words. By dragging I mean moving (drag and drop) the robot using through Gazebo (not keyboard (teleop), neither autonomously (move_base)), to a new position. By overlapping map I mean that even though the new portion of the map is updated, the old ones remain there (they are not updated to a grey occupied space, but remain as free space instead), resulting in what we see on the down-right part of the image (triple walls).
I am assuming you are tinkering with the pose of the robot in Gazebo. Doing that might lead to an error in the odom data being published by Gazebo.
Do the old portions of the map lie outside laser scan range? If that's the case, you could try increasing the value of the
obstacle_rangeparameter.Also, it seems that you dragged the bot 2 times. Which of the three pink lines represent the lastest laser scan?
Yes. I am changing the position of the robot in Gazebo for testing purposes. A similar real scenario could be carrying the robot to another position, without touching the ground?!
The laser scan is 180 so anyway anything behind the robot is not live-measurements, but estimates of the map shape, based on the fusion of the previous laserscan values and odom (SLAM). However, since the odom values are zero while I'm dragging the robot in Gazebo, it creates this duplicated maps.
I only dragged it one time. I suppose the three pink lines have to do with the publish frequency of the Laserscan values. The uppermost pink line is the latest one.