scan_ground_filter may sometimes fail to remove point clouds at the origin of base_link

[atusuda]

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I'm convinced that this is not my fault but a bug.

Description

I’m using a slightly older version of Autoware, “2024.07,” and I’m encountering an issue where the number of predicted objects becomes 0.
After investigating, I found that the detection results stop due to the following behavior, which causes the number of predicted objects to become 0.
What I would like to ask about is item 2 below. If possible, I would appreciate it if you could let me know where the likely cause might be. Alternatively, if this has already been fixed, I would appreciate it if you could share the relevant link.

1. Due to a known issue in ring_ground_filter, a large number of point clouds are added at the origin of base_link.
2. In scan_ground_filter, the point clouds from item 1 are supposed to be removed, but in rare cases they are not.
3. In occupancy_grid_map_outlier_filter, the filter process is skipped when the number of lower_confidence_pc points exceeds max_filter_points_nb, but a similar issue to item 1 occurs, causing point clouds to be added at the origin of the map.
4. When the point clouds from item 3 are input, euclidean_cluster takes several tens of seconds to process it, which causes the detection results to stop.

Expected behavior

In item 2 above, the point clouds at the origin of base_link should always be removed.

Actual behavior

In item 2 above, the point clouds at the origin of base_link are sometimes not removed, which leads to the issue described in item 4.

Steps to reproduce

I believe it can be reproduced if ring_outlier_filter is used in sensor_kit's lidar.launch.xml. However, it has only been reproduced in specific locations.

Versions

• Ubuntu 22.04.5 LTS
• ROS2 humble
• Autoware 2024.07

Possible causes

No response

Additional context

No response