Robotics StackExchange | Archived questions

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:

image description

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

Asked by AlexandrosNic on 2021-06-03 06:09:21 UTC

Comments

clear_costmaps service clears the obstacles in the costmap being used by move_base. I do not see any obstavle in the map image attached in the question.

Asked by skpro19 on 2021-06-03 12:58:20 UTC

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?

Asked by AlexandrosNic on 2021-06-07 03:55:43 UTC

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 map are not updated?

Asked by skpro19 on 2021-06-07 10:01:05 UTC

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).

Asked by AlexandrosNic on 2021-06-07 10:53:33 UTC

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.

Asked by skpro19 on 2021-06-09 04:13:00 UTC

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_range parameter.

Asked by skpro19 on 2021-06-09 04:17:48 UTC

Also, it seems that you dragged the bot 2 times. Which of the three pink lines represent the lastest laser scan?

Asked by skpro19 on 2021-06-09 04:25:34 UTC

  • 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.

Asked by AlexandrosNic on 2021-06-09 09:32:10 UTC

Regarding your first point, please see the discussion on this question.

Asked by skpro19 on 2021-06-09 09:39:58 UTC

I don't really understand the theoretical underpinnings of SLAM at the moment.

Having said that, why don't you verify the value being published on the odom topic in both the cases - before and after dragging?

It would be really interesting to know if that's the case.

Asked by skpro19 on 2021-06-09 09:48:49 UTC

Indeed is very similar to your attached question - the so-called kidnapped robot problem. No solution though. The odom values change before and after dragging since the corresponding SLAM algorithm tries to fix odom values (by fusing them with the laser scan values). However I would just want to forget the previous built maps and focus on new ones whenever I teleport the robot in Gazebo.

Thank you anyway for your time

Asked by AlexandrosNic on 2021-06-09 10:10:49 UTC

Glad to help.

Asked by skpro19 on 2021-06-09 10:12:43 UTC

Answers