rsasaki0109 / lidarslam_ros2

ROS 2 package of 3D lidar slam using ndt/gicp registration and pose-optimization
BSD 2-Clause "Simplified" License
507 stars 121 forks source link

Dense map representation? #94

Open wxyLuna2024 opened 2 months ago

wxyLuna2024 commented 2 months ago

Hi, First of all, thank you so much for creating a clean lidar-based SLAM feature that does not rely on IMU dependencies. I am runing lidar slam on a campus driving dataset. There are two things I found that leads to mapping error, therefore I am posting this and looking for suggestions"

  1. Loop closure modified map ended at the first intersection, possibly leading to failure in detecting loop closure globally Screenshot from 2024-07-03 14-19-34 Screenshot from 2024-07-01 16-44-16 The blue path is the gt trajectory obtained from lio_sam. As seen from the screenshot, the green modified map ended at the first loop closure, while it's just halfway from finishing the whole route. I wonder which parameters I can adjust this by changing up the .yaml file or launch.py file to ensure modified mapping span through the entire bag file. I tried to adjust range of searching loop closure but does not seem to be very effective.

    1. Missing a lot of points in the generated point cloud map

Screenshot from 2024-07-02 14-13-49

The accumulated point cloud from the right are from lio_sam. image

The accumulated point cloud from the left are from lio_sam.

Since loop closure detection ended at the first route intersection, the mapping is incomplete. Also I recognize that the dense map representation is incomplete, as the road texture and height of building are all missing compare to those generated by lio_sam. Is there any parameters I could adjust to get a dense map representation?

I am looking for suggestions to solve these problem. Any help will be appreciated. PS: I would appreciate it if you can provide a citation for reference!

rsasaki0109 commented 1 month ago

Apologies for the late reply.

This package struggles with loop detection over long distances. This is because, at the time of this package's implementation, there were no non-GPL open-source software (OSS) available for place recognition. Now, however, you can find the following, but there are no plans to integrate it at the moment: https://github.com/KOKIAOKI/3d_bbs

Alternatively, adjusting the parameters for scan matching might improve the performance of lidar odometry, potentially closing the loop. If you could share the parameters you are using, I might be able to offer some advice. For outdoor use, I recommend an ndt_resolution of 2.0 and a vg_size_for_input of about 0.5~1.0.

The fact that some road textures and building heights are missing might indicate that the scan matching has failed in those areas. It would be good to display the trajectory along with the map point cloud to check if the trajectory is stable.

As for references, the following packages come to mind: https://github.com/RobustFieldAutonomyLab/LeGO-LOAM https://github.com/koide3/hdl_graph_slam https://github.com/autowarefoundation/autoware_ai_perception/tree/master/lidar_localizer

wxyLuna2024 commented 1 month ago

Apologies for the late reply.

This package struggles with loop detection over long distances. This is because, at the time of this package's implementation, there were no non-GPL open-source software (OSS) available for place recognition. Now, however, you can find the following, but there are no plans to integrate it at the moment: https://github.com/KOKIAOKI/3d_bbs

Alternatively, adjusting the parameters for scan matching might improve the performance of lidar odometry, potentially closing the loop. If you could share the parameters you are using, I might be able to offer some advice. For outdoor use, I recommend an ndt_resolution of 2.0 and a vg_size_for_input of about 0.5~1.0.

The fact that some road textures and building heights are missing might indicate that the scan matching has failed in those areas. It would be good to display the trajectory along with the map point cloud to check if the trajectory is stable.

As for references, the following packages come to mind: https://github.com/RobustFieldAutonomyLab/LeGO-LOAM https://github.com/koide3/hdl_graph_slam https://github.com/autowarefoundation/autoware_ai_perception/tree/master/lidar_localizer

Hello Sasaki San, thank you so much for your reply. I am now using li_slam_ros2, which I believe is much more robust and is able to produce dense map representation. I have posted a new issue here https://github.com/rsasaki0109/li_slam_ros2/issues/35. Help will be greatly appreciated.