[Costmap2d] LocalCostmap's Obstacle layer stops detecting obstacles
Hello,
I am using the move_base and costmap_2d for an autonomous navigation experiment.
I use only the obstacle_layer for the local_costmap. And I use the LaserScan topic (/scan) as the source for this layer.
As you can see in the following screenshots, from a certain moment, the obstacle layer stops to add any occupied grid even thought clearly the LaserScan topic confirms the existence of the obstacle in the local_costmap zone. this problem has been occurred several times recently.
I should mention that, previously, I have tested several times my costmap configuration in move_base and I had never had this problem. I do not know what causes this problem and I would appreciate your help.
Update: I have found the "origin" of this strange behavior of the local costmap but still I do not understand why ? I have a package called platform which computes and publishes the robot's wheel odometry. Recently, I have added the fusion of the IMU data into this package to publish the /odom/filtered topic which is the corrected odometry by the IMU data. Based on my tests, this part of the code is the origin of this problem (if I deactivate this data fusion and publishing the /odom/filtered topic, then I would not have any issues with the local costmap).
Thanks a lot.
-- Screenshot where the costmap works fine.
-- Screenshot where the obstacle layer stops to add the occupied grids to the local costmap even thought the LaserScan topic shows the existence of the obstacle in the local_costmap zone.
-- Here you can find my local_costmap configuration
local_costmap:
global_frame: map
robot_base_frame: base_link
update_frequency: 5.0
publish_frequency: 1.0
static_map: false
rolling_window: true
width: 10.0 # The width of local_costmap it was 5 meter
height: 10.0 # The hight of local_costmap it was 5 meter
resolution: 0.05
transform_tolerance: 0.5
obstacle_layer:
enabled: true
inf_is_valid: true
track_unknown_space: true
combination_method: 1
observation_sources: laser_scan_sensor
laser_scan_sensor: {sensor_frame: laser, data_type: LaserScan, topic: /scan, marking: true, clearing: true, expected_update_rate: 0.25, obstacle_range: 5.0, raytrace_range: 20.0}
# Pas d'inflation layer pour le TEB
# inflation_layer:
# enabled: true
# cost_scaling_factor: 5 # exponential rate at which the obstacle cost drops off (default: 10)
# inflation_radius: 0.2 # max. distance from an obstacle at which costs are incurred for planning paths.
# track_unknown_space: true
plugins:
- {name: obstacle_layer, type: "costmap_2d::ObstacleLayer"}
# - {name: inflation_layer, type: "costmap_2d::InflationLayer"}
It's hard to judge scale. How far away are those obstacles?
Not too far and not too close. The local costmap size is (10 10) and the red cube in the image is the *imu_frame (close to the base_link). I can say they are between 50 cm and 5 m from the footprint of the robot. Hope I answered your question.
I have also tried to "reactivate" the obstacle_layer by using rqt_reconfigure when this problems shows up, but nothing changed.
Here's a thought - costmap is using a different transform than RVIZ so RVIZ has the robot and laserscan in one location and costmap has them somewhere else so it appears when looking at RVIZ that the costmap isn't working. When you added the odom/filtered topic are you sure you accounted for the changes everywhere? <--Ha ha I just noticed this post was over a week ago...late to the party - but did you figure it out.