Robot and its previous positions are counted as obstacles

Question

I am trying to use a SLAM package along with the ROS navigation stack and a package called explore_lite, which automatically directs the robot towards unexplored areas. I have most of this working, but I've noticed that the robot's initial position, as well as certain locations it has been in, will be marked as obstacles in the costmap, even though the only thing which has been in the location marked is the robot itself. This can be seen in the below image, where the red circles are made around 'obstacles' placed at previous positions of the robot.

Does anyone know why this is happening? I've tried changing my costmap parameters, and I've even set footprint_clearing_enabled to true for my global costmap, but I can't figure this out.

rqt graph

costmap_common_params.yaml

obstacle_range: 2.5
raytrace_range: 3

# found using https://answers.ros.org/question/385798/how-can-i-find-the-appropriate-robot-footprint + jackal dimensions
footprint: [[-0.215, -0.254], [0.215, -0.254], [0.215, 0.254], [-0.215, 0.254]]

inflation_radius: 0.5
transform_tolerance: 1

controller_patience: 2.0

NavfnROS:
    allow_unknown: true

recovery_behaviors: [
    {name: conservative_clear, type: clear_costmap_recovery/ClearCostmapRecovery},
    {name: aggressive_clear, type: clear_costmap_recovery/ClearCostmapRecovery}
]

conservative_clear: 
    reset_distance: 3.00
    
aggressive_clear:
    reset_distance: 1.84

observation_sources: laser_scan_sensor
laser_scan_sensor: {sensor_frame: front_laser, data_type: LaserScan, topic: front/scan, marking: true, clearing: true}

global_costmap_params.yaml

global_costmap:

  # world? -> odom now, see tf issue fix
  global_frame: map
  
  # check this on Jackal tf
  robot_base_frame: base_link
  
  update_frequency: 5.0
  publish_frequency: 2.0
  
  map_type: costmap
  
  # false since even though the map is from map_server it's on a topic and not already saved -> rtab says true?
  static_map: true
  
  plugins:
  - {name: static,               type: "costmap_2d::StaticLayer"}
  - {name: obstacles,            type: "costmap_2d::ObstacleLayer"}
  - {name: inflation,            type: "costmap_2d::InflationLayer"}
  
  obstacles:
   
    track_unknown_space: true
    footprint_clearing_enabled: true

local_costmap_params.yaml

local_costmap:

  # (not map, see https://robotics.stackexchange.com/questions/44925/running-move-base-for-navigation-via-gmapping)
  global_frame: odom
  robot_base_frame: base_link
  
  update_frequency: 5.0
  publish_frequency: 2.0
  
  static_map: false
  rolling_window: true
  
  width: 6.0
  height: 6.0
  resolution: 0.025
  
  # ?
  origin_x: 0.0
  origin_y: 0.0
  
  map_type: costmap
  
  observation_sources: laser_scan_sensor
  laser_scan_sensor: {sensor_frame: front_laser, data_type: LaserScan, topic: front/scan, marking: true, clearing: true}

EDIT 1- I don't know if this changes anything, but this is the pipeline I am using- I am using a semantic SLAM package (https://github.com/floatlazer/semantic_slam) which builds an Octomap using input from an RGB-D camera. The robot is localized using ORB-SLAM2. I then use a projection of the Octomap as an occupancy grid, which I feed into the navigation stack to create the costmaps.

However, even though the 'obstacles' show up in the global costmap, they are not present in the occupancy grid used to make the costmap or the local costmap.

EDIT 2- Here is a video of the robot- https://streamable.com/jeag6e. I am simulating it in Gazebo, and I have both an occupancy grid and the global costmap turned on. The shapes seen in the black of the costmap are shapes in the environment from the occupancy grid, and the robot is being directed by explore_lite as previously mentioned.

Answer 1

You should check if the sensor msg you are using (probably LaserScan) is working properly, and also check if it steps into the structure of your robot. These are typical cases why that "shadows" appears. You could use some filter to make sure there's no points detected in your footprint area.

Edit 1:

EDIT 1- I don't know if this changes anything, but this is the pipeline I am using- I am using a semantic SLAM package (https://github.com/floatlazer/semantic_slam) which builds an Octomap using input from an RGB-D camera. The robot is localized using ORB-SLAM2. I then use a projection of the Octomap as an occupancy grid, which I feed into the navigation stack to create the costmaps.

This changes a lot, at least for me, since I have no experience of using that pipeline. I have checked the pipeline and I can't help you with that, I have seen that it seems it is deprecated as its GitHub hasn't had any commits since five years. For instance, in:

local_costmap.yaml

observation_sources: laser_scan_sensor
  laser_scan_sensor: {sensor_frame: front_laser, data_type: LaserScan, topic: front/scan, marking: true, clearing: true}

From which sensor is being published this information? Because this is the one that is used in order to create those obstacles in the local_costmap. If you want your localcostmap to use another OccupancyGridMap I suppose you would have to use a plugin or pass it in some other way.

Sorry for not being able to solve your problem, I supposed we were in a SLAM typical usecase.