0
$\begingroup$

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.

enter image description here

rqt graph

enter image description here

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.

$\endgroup$

1 Answer 1

0
$\begingroup$

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.

$\endgroup$
6
  • $\begingroup$ Thank you for the suggestion! But, I don't think it's because of the laser scan. I commented out the lines using it as an observation source, but the problem is still there Additionally, when I visualize the laser scan, there are no markings on the robot itself. I've also noticed that the 'shadows' appear only in the global costmap- they don't appear in the occupancy grid I am using as an input or the local costmap. $\endgroup$
    – Joshua L
    Feb 20 at 22:55
  • $\begingroup$ Understood, from the first image you attached, is the actual pose of the robot being considered as an obstacle already? Despite that you didn't circle it, it seems black as the other obstacles. I suppose you are starting the SLAM with an empty map, correct? Please check if the footprint of the robot is already black at the start. Also, would you be able to publish a video to see the timing of the map being updated? $\endgroup$
    – ÁngeLoGa
    Feb 21 at 7:41
  • $\begingroup$ Yes, the pose of the robot in the image is considered as an obstacle as well, and yes, SLAM is starting with an empty map. As for when the footprint turns black, this happens very soon after I run the launch file which includes all of the costmaps/the navigation stack. I will try to publish a video and add it as an edit to the original question soon. $\endgroup$
    – Joshua L
    Feb 21 at 23:02
  • $\begingroup$ Updated my answer $\endgroup$
    – ÁngeLoGa
    Feb 22 at 12:41
  • $\begingroup$ The sensor being used is a laser mounted onto the robot model which I added for the local costmap/local planning. I used that instead of the point cloud from the RGB-D camera as I thought it would be more reliable. And it's alright, I appreciate your help. I was able to change some parameters in the navigation stack (specifically the combination_method in the obstacle_layer plugin) so that the shadows are overwritten. Although this doesn't solve the problem, it does help to bypass it so that the robot doesn't keep the shadows as obstacles when it encounters them again. $\endgroup$
    – Joshua L
    Feb 22 at 18:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.