Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dense map representation? #94

Open
wxyLuna2024 opened this issue Jul 2, 2024 · 2 comments
Open

Dense map representation? #94

wxyLuna2024 opened this issue Jul 2, 2024 · 2 comments
Assignees
Labels
question Further information is requested

Comments

@wxyLuna2024
Copy link

wxyLuna2024 commented Jul 2, 2024

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.

  2. 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!

@wxyLuna2024 wxyLuna2024 changed the title Modified_map ended too early for loop closure detection Dense map representation? Jul 4, 2024
@rsasaki0109
Copy link
Owner

rsasaki0109 commented Jul 17, 2024

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

@rsasaki0109 rsasaki0109 self-assigned this Jul 17, 2024
@rsasaki0109 rsasaki0109 added the question Further information is requested label Jul 17, 2024
@wxyLuna2024
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants