Initial rotation between GPS odometry and Optimized path about lio-sam

[TixiaoShan]

The EM field of lidar causes the yaw readings from IMU very unreliable. You can evaluate LIO-SAM using the evaluation method of KITTI, which calculates the drift at certain trajectory length. Or, you can evaluate the drift when returning to the same location for your dataset.

[TixiaoShan]

How well does LIO-SAM support car-like vehicles?
I tested LIO-SAM on handheld-device, ground vehicles, and boats. UAV is not tested yet.

[HaowenLai]

I have encountered the same situation as @Pallav1299 . When I tested the park dataset with GPS, wrong result was got. The following figure shows the GPS trajectory (the long coordinate) and Imu odom trajectory (the thin blue one, not fused with gps):

However, when I tested my self-recorded dataset with GPS, result seemed pretty good. Rotation misalignment was corrected automatically in the first few seconds. The following figure shows the GPS trajectory (the long coordinate) and Imu odom trajectory (the small one, not fused with gps):

It's quite strange that one can work but another cannot with similar GPS and IMU (not fused with gps) trajectories.

[Pallav1299]

I have encountered the same situation as @Pallav1299 . When I tested the park dataset with GPS, wrong result was got. The following figure shows the GPS trajectory (the long coordinate) and Imu odom trajectory (the thin blue one, not fused with gps):

@HaowenLai I think it is the desired result. What's happening here is that you have set the useImuHeadingInitialization flag to false. Since you are not using GPS, this is actually not required. Hence the result is correct.

However, when I tested my self-recorded dataset with GPS, result seemed pretty good. Rotation misalignment was corrected automatically in the first few seconds. The following figure shows the GPS trajectory (the long coordinate) and Imu odom trajectory (the small one, not fused with gps):

The GPS factors are actual GPS poses (x,y,z), converted to local map coordinates. The optimizer tries to converge to these poses upon receiving the GPS factors. Did you set the useImuHeadingInitialization to true in this case?

If you set useImuHeadingInitialization to true with proper gpsTopic, the result will be different.

[HaowenLai]

@Pallav1299 Thanks for the reply. I set useImuHeadingInitialization to true and test again the park dataset. The rotation misalignment disappears, and the trajectory looks like (GPS trajectory is with the long coordinate and Imu odom trajectory is the thin blue one, not fused with gps):

The result is acceptable. It seems that I forgot to set this parameter before. But strange thing still happens when I add GPS with mapping. As shown below, GPS and IMU trajectories match quite well in the beginning. But they diverge at a point and the mapping goes wrong. It is confusing.

[yuanguobin]

I think, In essence, there is still the problem of the coordinate system not being aligned, the local Cartesian coordinate(GPS) and the body origin coordinate. Taking into account the accuracy of imu, it is not well aligned the yaw between them.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.