the yaw offset between gnss odom and lidar odom

[zouyajing]

Hi, thanks for your work. I have tested your codes using my own datasets. The problem is that there is a yaw offset between gnss odometer and lidar-inertial odometer. Also, in the backend optimization part, the gps constraint is not used.

For my understanding, gnss odometer is under the ENU coordinate system, and there is a yaw offset between ENU and LIO system. How to compute or reduce the yaw offset?

Thanks in advance.

[JokerJohn]

Hi, thanks for your work. I have tested your codes using my own datasets. The problem is that there is a yaw offset between gnss odometer and lidar-inertial odometer. Also, in the backend optimization part, the gps constraint is not used.

For my understanding, gnss odometer is under the ENU coordinate system, and there is a yaw offset between ENU and LIO system. How to compute or reduce the yaw offset?

Thanks in advance.

From your picture we can see that the GNSS trajectory is not very smooth, so your GPS data quality is not very good. As for the reason for the offset of the LIO trajectory and the GPS trajectory, if you set the option useGPS to true in the yaml file, the system needs to use the GNSS odom orientation data to initialize the initial yaw of LIO, otherwise the LIO system will not continue, Until the required GNSS odom data appears. Then You can check the following issues:

1. In line 987 of the mapOptmizationGps.cpp file, when synchronizing GPS odom timestamp and LIO timestamp , I set a rough offset of 0.5s to ensure that GNSS odom data can be obtained here, otherwise the system will not be initialized.
2. You set the GNSS covariance threshold, that is, the gpsCovThreshold value in the yaml file. Only GPS points that meet the threshold will be added to the pose graph for optimization. When a sufficient number of GPS points are added to the optimization, the two trajectories will gradually align. To determine an empirical value, you can use plotjugger to look at the value of the GPS covariance in your bag and set an appropriate threshold.(You can refer to the demo data video I provide. The previous system is also a relatively poor initialization result. With the continuous addition of GPS constraints, the two trajectories will gradually align)

[zouyajing]

Hi, thanks for your work. I have tested your codes using my own datasets. The problem is that there is a yaw offset between gnss odometer and lidar-inertial odometer. Also, in the backend optimization part, the gps constraint is not used. For my understanding, gnss odometer is under the ENU coordinate system, and there is a yaw offset between ENU and LIO system. How to compute or reduce the yaw offset? Thanks in advance.

From your picture we can see that the GNSS trajectory is not very smooth, so your GPS data quality is not very good. As for the reason for the offset of the LIO trajectory and the GPS trajectory, if you set the option useGPS to true in the yaml file, the system needs to use the GNSS odom orientation data to initialize the initial yaw of LIO, otherwise the LIO system will not continue, Until the required GNSS odom data appears. Then You can check the following issues:

1. In line 987 of the **mapOptmizationGps.cpp** file, when synchronizing GPS odom timestamp and LIO timestamp , I set a rough offset of **0.5s** to ensure that GNSS odom data can be obtained here, otherwise the system will not be initialized.

2. You set the GNSS covariance threshold, that is, the **gpsCovThreshold** value in the yaml file. Only GPS points that meet the threshold will be added to the pose graph for optimization. When a sufficient number of GPS points are added to the optimization, the two trajectories will gradually align. To determine an empirical value, you can use plotjugger to look at the value of the GPS covariance in your bag and set an appropriate threshold.(You can refer to the demo data video I provide. The previous system is also a relatively poor initialization result. With the continuous addition of GPS constraints, the two trajectories will gradually align)

Hi, John. Thanks for your quick reply. I have followed your advice and get the two odometer aligned. But the alignment is not good and always changes. Do you optimize the yaw offset in the backend or just use the yaw provided by GNSS odom or IMU odom?

Thanks again in advance.

[JokerJohn]

Actually I did not optimize the yaw provided by GNSS odom in the backend, the only role of this yaw angle is to help provide a rough global orientation in the LIO initialization module. In the back-end optimization, the system will select the ENU points in the GNSS odom whose covariance is less than the threshold for optimization. As for what you said, the alignment is not good and always changes. My guess is that you have not set the appropriate Gp position covariance threshold. This requires empirical adjustment of your GPS data. For example, you can observe your bag. The distribution of GPS covariance data, select the location where you think the GPS data is good, set the corresponding threshold, and add these points to the optimization. As long as the number of points is sufficient, the alignment will be relatively stable. In addition, I think your data, GPS data quality is relatively general, and the overall distance is too short, there may be fewer GPS points that meet the requirements.

[zouyajing]

@JokerJohn thanks for you detailed reply. I will try to tune the threshold and also try to use RTK GPS instead of SPP for later tests.

[JokerJohn]

@JokerJohn thanks for you detailed reply. I will try to tune the threshold and also try to use RTK GPS instead of SPP for later tests.

Without RTK, it can only be adjusted by experience. With RTK, the performance will be much more stable. I strongly recommend that you use plotjugger to observe the change of GNSS covariance before adjusting the threshold.

[JokerJohn]

@zouyajing I just updated the GPS time synchronization code, you only need to set the GPS frequency in the yaml file.