clear costmap where a laser beam does not exist

Question

My current setup involves a single LiDAR sensor that covers only a limited 220-degree arc of the robot's surroundings. As the robot moves, any obstacles seen by the LiDAR previously and not in the LiDAR coverage remain on the costmap since the costmap can not raytraces them, as there are no laser beams that can be traced in that region. This creates a challenge as the costmap, responsible for guiding the robot's path planning, cannot effectively update and clear regions where the LiDAR doesn't provide data. Consequently, the costmap becomes cluttered with numerous false obstacles, significantly affecting the map's accuracy and usability.

What would be the best technique to tackle this?

(Edit)

Actually, I have identified the source of the issue. It is not originating from the costmap; instead, it is stemming from the AMCL (Adaptive Monte Carlo Localization) module. The robot is encountering difficulties in localizing itself accurately, particularly during rotational movements. This problem arises because the laser scan data moves along with the robot, rather than staying aligned with the static map. As a result, the costmap is becoming distorted, leading to inaccurate localization.

The current question revolves around whether a 220-degree field of view for the laser scan will provide sufficient features for AMCL to achieve proper robot localization. I am confident that the problem does not stem from the odometry, wheel separation, or wheel radius, as I have conducted tests using the same setup and AMCL parameters with two lidars providing a 360-degree view, yielding impeccable results.

Answer 1

Can you provide an image of what you're talking about?

Obstacle persistence is one of the most important parts of perception so you don't end up in oscillatory behavior. For example, once a blocked route leaves your current viewpoint, replanning might bring you right back down that same path and so on indefinitely.

If you're saying that you have "false obstacles" then you have another problem altogether with your perception pipeline not removing noise or other non-physical artifacts. You should resolve that.

What you describe with persisting of obstacles that are not currently visible is an important feature.

Edit: First, please don't edit questions to change them to different questions once the original question is answered. Open a new question instead - it makes it difficult for future readers to understand / follow a solution to learn from.

With that out of the way... its less likely that it has to do with AMCL (unless you've configured AMCL particularly poorly) and more likely to have to do with your odometry while turning which is throwing off the state estimate going into AMCL. What you describe is pretty textbook issues with either the URDF accuracy or the odometry computation being incorrect.

BTW, 220 is plenty. More is better, but 220 should be fine.

Answer 2

I agree with Steve about not clearing an area of costmap just because you can't see it. That said, Steve provides some info in the following on how to do what I think you're aksing. https://answers.ros.org/question/395524/how-to-clear-the-costmap-from-other-nodes-navigation2/

EDIT after OP followup:

I have used AMCL in situations where there was significantly less that 220 degrees of useful informtion (in a large space where 360 lidar can't see anything in most directions) and it still worked, at least in my use case.

Given you say the false defects move with the robot, I can think of only two explanations:

1 - these are repeating fake data somehow caughtup in a matrix somewhere. In this case maybe as a test you should publish 360 degrees of data with the 140 degrees outside of your scanner set off the limits(near or far) so it gets written into data but ignored by AMCL and the cost maps.
2 - one of your cost maps is following the robot in which case I have no idea what to tell you. Do you know which cost map the fake defects show up on?

I have not seen either of those 2 happen. YMMV.

Answer 3

This problem arises because the laser scan data moves along with the robot, rather than staying aligned with the static map. As a result, the costmap is becoming distorted, leading to inaccurate localization.

This is typically a problem with your odometry or synchronization between your odometry and laser scan readings or bad alignment. It will cause failures of localization as well because of the lack of synchronization too, but that's the result of the same lower level issues not the cause.

The best thing to do to debug this is to render the laser in the odom frame and spin it and make small movements in a static environment and make sure that all obstacles stay still in your display.