Using GPS with KITTI dataset

[Pallav1299]

I am facing problems while setting LIO-SAM with GPS for the KITTI dataset. I am getting a lot of sudden jumps in the output .

The package works fairly well without GPS. I think it's an issue with improper configuration. I seek some help regarding the same.

[TixiaoShan]

There are still some unsolved problems in LIO-SAM when a loop is closed or a GPS measurement is received. Any inputs are welcome from the community.

[Pallav1299]

@TixiaoShan, my use-case requires creating globally correct point cloud maps. I haven't read the code thoroughly. Can you please list down the issues with including GPS measurements and loop closure, so as to keep track of the required changes and improvements?

[Pallav1299]

Initial misalignment causes the /lio_sam/mapping/path to drift away from /odometry/gps. Further, when GPS data should be added to the pose graph, there is sudden jump in the pose. Hence leading to imperfect global poses.
I am trying with the default params on the Kitti_raw_data "2011_10_03_drive_0042 (4.5 GB)" dataset while it doesn't have position covariance in the /gps/fix data. Am I doing something wrong here?

[TixiaoShan]

You should tune the function that adds GPS factor in mapOptimization.cpp carefully. KITTI dataset doesn't give GPS covariance, so you have to change the threshold to figure out the best settings. When a GPS factor is added, imuPreintegration will be reset and cause a loss of initial guess in updateInitialGuess(). If the vehicle is moving very fast, the scan-matching may fail. You can disable these lines to help this problem. But it's not perfect. I am still trying to figure out solving matching failure when a GPS factor is added.

[Pallav1299]

1. I tried with the above mentioned changes. I noticed that at points where positionCovariance is greater than the threshold, most of the GPS values though being correct, are neglected due to being relatively old or new w.r.t the pointcloud timestamp. This leads to error accumulation.
   Later when a new GPS factor is added, heavy ISAM optimization takes place on a large number of nodes. During this time the imuPreintegration gets reset.
   I tried on the kitti dataset. Please correct me if I am wrong.

2. I tried with and without GPS elevation integrated on KITTI dataset and tested with the ground truth data from Odometry sequences(I've less no. of keyposes so the data is scaled down, but the trend is almost same for X and Y axes)

• Without using elevation from GPS, the Z axis has following results:
  

• With GPS elevation, the following result is obtained for elevation in the final trajectory as compared to groundtruth :
  

Dotted line is ground truth

Should we use elevation from GPS or not?

[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.

[ghost]

1. I tried with the above mentioned changes. I noticed that at points where positionCovariance is greater than the threshold, most of the GPS values though being correct, are neglected due to being relatively old or new w.r.t the pointcloud timestamp. This leads to error accumulation.
   Later when a new GPS factor is added, heavy ISAM optimization takes place on a large number of nodes. During this time the imuPreintegration gets reset.
   I tried on the kitti dataset. Please correct me if I am wrong.
2. I tried with and without GPS elevation integrated on KITTI dataset and tested with the ground truth data from Odometry sequences(I've less no. of keyposes so the data is scaled down, but the trend is almost same for X and Y axes)

• Without using elevation from GPS, the Z axis has following results:
  
• With GPS elevation, the following result is obtained for elevation in the final trajectory as compared to groundtruth :
  

Dotted line is ground truth

Should we use elevation from GPS or not?

@Pallav1299 You mentioned that the number of keyframes was different from the KITTI's ground truth.
I actually have the same problem. Did you evaluate the results using tum format for the trajectories?

[Pallav1299]

@polbolso I didn't try visualizing in TUM or EUROC formats using EVO. I used KITTI format data. With KITTI format you would have to maintain the same number of poses to evaluate relative and absolute pose errors. This issue is solved by using timestamps in TUM format if I am not wrong. I'd suggest converting KITTI format poses to TUM for evaluation
in EVO.

[ghost]

Thanks @Pallav1299, I managed to combine the produced results with KITTI ground truth through TUM format. However, it seems that there is a clear misalignment issue. Have you experienced something similar?

[berkaysahinaskar]

Thanks @Pallav1299, I managed to combine the produced results with KITTI ground truth through TUM format. However, it seems that there is a clear misalignment issue. Have you experienced something similar?

I experienced same issue. There is a difference between vehicle axis and yours. You need to change the x y z poses reference to KITTI vehicle setup.