Trajectory diverges while testing on KITTI sequence 00 (2011_10_03_drive_0027)

[zzodo]

Thank you for your work and also the extension to test in KITTI raw dataset.

Unfortunately, an issue came in front while testing LIO-SAM in KITTI benchmark sequence 00. (which corresponds to 2011_10_03_drive_0027, as far as I know) I followed the documentation you wrote for KITTI dataset and convert both raw velodyne point clouds from the synced set and IMU data from the unsynced set. The extrinsic calibration between imu and velodyne also applied to params.yaml

The KITTI rosbag file provided by LIO-SAM which contains data from 2011_09_30_drive_0028 performs properly, other rosbag files converted from raw KITTI dataset works fine.

And then I moved on to 2011_10_03_drive_0027 to evaluate the estimated trajectory with ground truth, but the system diverges after a few whiles like a screenshot below.

The estimated poses also tend to vibrate in sharp corners. Is this behavior due to IMU measurements in the certain sequence are poor? I have experienced a similar tendency when external calibration between IMU and base_link is invalid though.

Any ideas?

[stale[bot]]

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.

[FishInWave]

Have you tried raw data named 2011-09-30-0016? It failed in my PC, which looks like your figure. So do you fix the problem or know what happened on these bad sequence?

[zzodo]

Hi,

I was able to fix the issue that I commented above, but I cannot remember what was the problem. It was nearly half of year ago...

Have you tried to debug LIO-SAM with the sequence which you experienced a divergence?

As I remember from my debugging result, I found out that Lidar odometry transformation matrix was strange. It was not related to IMU intrinsic/extrinsic parameters, but Lidar pointcloud. The different (bad) behavior was due to the failure while finding correspondences in calculating Lidar odometry.

So my suggestion to solve this problem is,

1. Make sure that the generated rosbag file from kitti2bag.py has an appropriate pointcloud2 messages and IMU messages by visualizing on RViz.
2. In particular, check the ring field in the point clouds by coloring the points with ring field values.
3. Then, open your params.yaml and double-check your parameters are set to use velodyne configuration including number of channels, FOV, etc.
4. Try again sequence 2011_09_30_drive_0016
5. If the problem remains, tweak the source code to 'cout' transformation matrix estimated from Lidar odometry and debug why this happens.

Sorry for not sharing my solution at the time I reached on to. Hope you find the issues and solve them, also share for the other users!

[zhuzy-2018]

I also encountered the same problem, sequence 00 trembled during LIO-SAM testing and showed IMU based Abnormal twisting of the base_link frame during car turning. I suspect there are two possibilities:

1. There is a deviation in the timestamp of the IMU, which causes the IMU to record the time earlier or later when the vehicle turns.
2. The extrinsic for IMU and LiDAR in the day 2011_10_03 is incorrect.

if you figure out the reason, I'd like to know.

[zzodo]

Hi @zhuzy-2018,

I suppose that your second guess was the reason and how I solved this issue.

Is it possible to debug the extrinsic between lidar frame and imu frame in your rosbag file? If you can, visualize them while playing the roabag file and compare with the extrinsic you inserted in LIO-SAM configuration yaml file.

Since it has been a while that I experienced this issue, there's nothing much to share. Sorry 😢

[zhuzy-2018]

Thank you for replying to my comment.

From what you say, it seems that you have solved the problem. Is it solved by extrinsic calibration?

There's one more thing I don't understand. I don't know if you know. Yeah, well, The data of KITTI is so confusing and problematic that it's not through time synchronized. So why do so many of the SLAM methods use KITTI dataset? And like ct-icp, they're in every sequence Have achieved good results.

	zzy

@.*** |

---- Replied Message ---- | From | Dohoon @.> | | Date | 05/02/2023 01:43 | | To | @.> | | Cc | @.>@.> | | Subject | Re: [TixiaoShan/LIO-SAM] Trajectory diverges while testing on KITTI sequence 00 (2011_10_03_drive_0027) (#240) |

Hi @zhuzy-2018,

I suppose that your second guess was the reason and how I solved this issue.

Is it possible to debug the extrinsic between lidar frame and imu frame in your rosbag file? If you can, visualize them while playing the roabag file and compare with the extrinsic you inserted in LIO-SAM configuration yaml file.

Since it has been a while that I experienced this issue, there's nothing much to share. Sorry 😢

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[zzodo]

Yes, I solve the issue about 2 years ago, and I remember that the issue came from the mismatch of lidar-to-imu extrinsic parameter calibration between KITTI dataset and default LIO-SAM extrinsic parameter. (I am not 100 percent sure about this)

But you don't have to re-calibrate the extrinsic parameter of KITTI dataset. It is already tested by tons of users. You have to change extrinsic parameters in params.yaml, as the author said. The most simple way is to test your configuration with the rosbag file provided by the author.

And more, as you already mentioned, synchronized KITTI dataset has not enough IMU data. You have to use unsynchronized raw dataset to achieve the appropriate estimation results. I also don't know why they organized the dataset like this, but perhaps, they didn't expect the tightly-coupling manner of IMU aided algorithms back in the time.

Many open-sourced SLAM methods have their published papers, and they need to evaluate the performance of their algorithm comparing with the legacy papers. I guess this might be the reason some of recent papers still use KITTI dataset to show how much their systems outperform.

Last, I don't know about the ct-icp but I guess ct-icp and LIO-SAM have different approaches to utilize IMU data in their system.

[zhuzy-2018]

Yes, I solve the issue about 2 years ago, and I remember that the issue came from the mismatch of lidar-to-imu extrinsic parameter calibration between KITTI dataset and default LIO-SAM extrinsic parameter. (I am not 100 percent sure about this)

But you don't have to re-calibrate the extrinsic parameter of KITTI dataset. It is already tested by tons of users. You have to change extrinsic parameters in params.yaml, as the author said. The most simple way is to test your configuration with the rosbag file provided by the author.

And more, as you already mentioned, synchronized KITTI dataset has not enough IMU data. You have to use unsynchronized raw dataset to achieve the appropriate estimation results. I also don't know why they organized the dataset like this, but perhaps, they didn't expect the tightly-coupling manner of IMU aided algorithms back in the time.

Many open-sourced SLAM methods have their published papers, and they need to evaluate the performance of their algorithm comparing with the legacy papers. I guess this might be the reason some of recent papers still use KITTI dataset to show how much their systems outperform.

Last, I don't know about the ct-icp but I guess ct-icp and LIO-SAM have different approaches to utilize IMU data in their system.

thanks for tell me above information. But through the files downloaded from the official webpage kitti raw data 2011_09_26_calib.zip 2011_10_03_calib.zip, they have the same extrinsic param of T_lb (lidar -> imu) which is shown in kitti.yaml in this repo. I’ve searched the whole internet a lot of times, but haven't seen the right extrinsic for 2011_10_03.

Can you offer the right extrinsic param of T_lb (lidar -> imu) for kitti 2011_10_03? Thank you again for your reply!!!

[zzodo]

Can you offer the right extrinsic param of T_lb (lidar -> imu) for kitti 2011_10_03? Thank you again for your reply!!!

Sure, can you give me some time to catch up this issue? I have been busy these days and need to figure out what was happened during weekends.

[zzodo]

Did you solved this issue? It seems to be a problem due to misgiving IMU orientation in the bag file. Can you debug IMU heading in your bag file with respect to world frame?

[harisbinyousaf24]

Can you offer the right extrinsic param of T_lb (lidar -> imu) for kitti 2011_10_03? Thank you again for your reply!!!

Sure, can you give me some time to catch up this issue? I have been busy these days and need to figure out what was happened during weekends.

Hi @zzodo can you provide me with the extrinsics you used to solve this issue. Currently i am experiencing a little drift in the readings. this is the result as i viewed my slam trajectory on satellite map. Would appreciate your response if you could tell me what extrinsics i need to change in params.yaml file?

[zzodo]

Hi @harisbinyousaf24 I think your estimated trajectory seems good enough. If you provided the wrong extrinsic parameters, you can experience immediate divergence as my picture(on the first issue post).

What is your concern? In the case that you want to improve pose accuracy, you should debug and tune some parameters. (e.g. threshold parameters or optimization settings) My first intuition is to find out why LIO-SAM suffered in this area

[harisbinyousaf24]

@zzodo

Hi @harisbinyousaf24 I think your estimated trajectory seems good enough. If you provided the wrong extrinsic parameters, you can experience immediate divergence as my picture(on the first issue post).

What is your concern? In the case that you want to improve pose accuracy, you should debug and tune some parameters. (e.g. threshold parameters or optimization settings) My first intuition is to find out why LIO-SAM suffered in this area

Actually the thing is red trajectory is GPS one and blue/purple one is SLAm trajectory which is shifted counter clockwise wrt GPS trajectory. SLAM trajectory is pretty much straight where GPS data is wrong but it is off the road as you can see. I want to put that on road so that it somehow overlaps gps trajectory. Is there any solution to debug this. I tweaked the intrinsics of IMU (bias Noise etc..) but it didn't help. And can you tell me where i need to make such changes? like optimization cuz apparently i guess i can't tweak codes (.cpp files) I can only make changes to params.yaml file.