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

Drfiting during the mapping process #35

Open
wxyLuna2024 opened this issue Jul 31, 2024 · 4 comments
Open

Drfiting during the mapping process #35

wxyLuna2024 opened this issue Jul 31, 2024 · 4 comments
Assignees

Comments

@wxyLuna2024
Copy link

Hello Sasaki San,
Thank you for integrating the IMU Integration from LIO-SAM to Lidar_slam_ros2. Using this repo, I created the best looking map with large scale dataset by far. The method is very reliable in ROS2 system and easy to use.However, I still have a couple of questions:
Some times weird drift happens. And eventually a small drift results in accumulative error that leads to failure of loop closure, especially for large scale dataset. For me the mapping was all perfect until the mapping hit a small drift.
Screenshot from 2024-07-30 15-45-31
Screenshot from 2024-07-30 15-45-59
Loop closure failing
Also another drift happens at this U-turn
Screenshot from 2024-07-30 15-59-23
image
Eventually resulted in misalignment in the lower left area, as well as aligning the map into a tilted plane.
Screenshot from 2024-07-31 11-41-40
The pointcloud plane were not even, and different sections are slightly tiled. Although I set imu input to be true and I see no error returned by IMUPreintegration, I still wonder if IMU input really comes into place.
Screenshot from 2024-07-30 16-04-02
I am using the default lio_bigloop.yaml set up here and any help will be greatly appreciated!!

@rsasaki0109
Copy link
Owner

rsasaki0109 commented Jul 31, 2024

I think it's necessary to use a trimmed rosbag from the problematic area to visualize the imu_path and path in rviz, and to check the values before and after using the debug_flag to identify the cause.

If the accuracy of NDT is the issue, the parameters ndt_resolution, vg_size_for_input, and vg_size_for_map might need to be reduced by about half (though this requires modifying the source code, it might be better not to apply a voxel grid filter to the map).

By the way, what is the frequency of the IMU? I've heard that this IMU Preintegration may not work well if the frequency is as low as 50 Hz.

@rsasaki0109 rsasaki0109 self-assigned this Aug 1, 2024
@wxyLuna2024
Copy link
Author

Hello,

Thank you for your reply. The frequency of the IMU is 100 Hz.

Also, as I am trying to evaluate the li_slam_ros2 performance with gt poses, I wonder how to evaluate its performance in a quantitative way, as the framework outputs trajectory in .g2o format, while most of the benchmark(like evo) uses pose matrices. I was referring to https://autowarefoundation.github.io/autoware-documentation/pr-366/how-to-guides/creating-maps-for-autoware/open-source-slam/compare-slam-algorithms/ but steps and tools were not stated clearly...

@rsasaki0109
Copy link
Owner

One simple method might be to record the pose topic, and then convert it into a pose matrix using the following function:
https://github.com/rsasaki0109/li_slam_ros2/blob/develop/scanmatcher/src/scanmatcher_component.cpp#L493-L499

@wxyLuna2024
Copy link
Author

One simple method might be to record the pose topic, and then convert it into a pose matrix using the following function: https://github.com/rsasaki0109/li_slam_ros2/blob/develop/scanmatcher/src/scanmatcher_component.cpp#L493-L499

Hello,
I was able to record the current_pose/ topic and use existing evo tool to do the evaluation. Thank you!

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

No branches or pull requests

2 participants