the height drift

[shul-aowu]

hello ,hyye! Thanks for your brilliant work . Now i test my own dataset and there is a question . My imu installation has a transform(oritation and translation) to the lidar , and I use the out_door.yaml to test my data (outdoor) , set the initial extrinstic para. I found that the mapping result about z axis has a obvious drift . What may cause the problem ? or is there any influence about the imu installation location？

[shul-aowu]

As for driving , it always moves in the planar ,and sometimes pass through the deceleration belt .So when it is a planar motion , is there any method to constraint the z axis drift ?

[hyye]

What drift do you mean? If it is extrinsic parameters’, there is a prior_factor in the config file; it can be set to 1, when the translational extrinsic estimation is not reliable.

Note that the rviz file of outdoor test contains odometry debug outputs; uncheck the Map folder in rviz to filter out debug outputs.

If it is the drift in mapping, the causes can be accuracy of Lidar, estimation, extrinsic parameters, etc. Theoretically, I think most of the mapping method with local observations may have such drift. Loop closure may be a good solution.

[shul-aowu]

As for extrinsic parameters, the prior factor I set is 1 , and what I want to mean is the mapping drift . Now when I use my data set ,the mapping result have a height drift .So I wonder the height error in your outdoor tests. In other words, whether the lidar+imu can constraint the height drift well .

[shul-aowu]

now i want to close the imu , and test the lidar mapping result without imu to see if there is someting wrong , but i have no idea to modify the code ( when i dont use the imu_data , something wrong occurs) . Could you give some advice?

[hyye]

If it is related to IMU, the extrinsic parameter and initialization can be significant issues. To close IMU, you can use the launchs without IMU, like 16_scans_test.launch or set imu_factor in the config file to turn off the IMU factor.

[shul-aowu]

I display the topic predict_odom that imu publish in rviz, then I just find it seems that the localization result always follow the imu result , and the lidar result have no influence . What may be the reason for this ?

[shul-aowu]

1、when i set the extrinstic 0 , my localization result showed in the fig. below The axis is the lio-mapping result , the arrow is the /predict_odom published from processImu() when i set 1, the result showed below

??why there is a more rotation in picture 1. ? according to the real environment , picture 2 is better than 1.

[hyye]

Setting 0 means no online calibration, which should be worse if the extrinsic parameters are not accurate or are changing.

[shul-aowu]

sorry , something wrong about what i say. when i set 0 , i get the picture 2; and set 1 ,get picture 1. whether the calibration result is not good.

[hyye]

Maybe the initial extrinsic parameters are not good enough. predict_odom is predicted by IMU, which should have some drift. The mapping node can reduce global drift from the pure odometry (estimation) node.

[shul-aowu]

I have a question about processImu(). we can see there is a formula to calculate the cov V.block<3, 3>(0, 0) = 0.5 * delta_q.toRotationMatrix() * dt * dt;
and according to the conclusion , 0.5 should be 0.25 ,,,, is there any influence?

[hyye]

You can try and see if it will help. From my calculation, it is 0.5.

[shul-aowu]

1、when I launch the 16_scans_test.launch(without imu) and it run the lio_process、lio_maping、lio_odometry node . It's a planar motion , when move toward y axis, we find the height increase , when move toward -y axis ,the height decrease .But at last , when it come back to the origin, the height have a 2m error.

Then I launch the map_4d.lauch and test_outdoor.launch and it run the lio_process、lio_estimator、lio_map_builder , but this time the height keep increase though it increase slower. And at last ,it get a bigger height error. its the result in the picture below. Is there something with IMU? or what can be the reason?

2、another question that i find is my imu data's frequency between two pcl should be 14 , but we can see in the picture that between two pcl frame ,there is only 4 or 5 or other numbers imu_data that pub_predict_odom publish. What is wrong with it ?

[shul-aowu]

and in my test , i find that the localization result (z axis) doesn't drift when rotate ,but it drift when move forward.

[hyye]

Because (6 DoF) motion with rotating, makes the z-axis observable; while in a straight motion, the z-axis is unobservable, which will cause drift).

1. It can be related to the incorrect extrinsic parameters or IMU noise parameters. But as I said above, such drift sometimes is inevitable. Loop closure can be a solution to this issue.
2. I guess it might be related to packet loss. You may check with rostopic hz to find out the truth frequency.

[shul-aowu]

Thanks ! and in the system , there is a tranform between world and camera_init like we see below, what does it mean ? and when estimator the motion, we caculate the transform from current to init .

[hyye]

Since in the beginning, our system may not align with gravity, whose origin is the lidar's first frame (with unknown global rotation). For the world frame, with the help of IMU, it should be well aligned with gravity.

[shul-aowu]

Now In my test , when I start in one place , z axis can get only 0.25m dirft at last , it performance well. when I start in another place , z get -6.25m error. ( I have get the transform from imu to lidar and set the para 0 to keep it unchange.) So whether it's because the gravity align result is different ,and then we transform from current to init , the data get a different roll in two tests, so make it drift in one but performance well in another one?

[hyye]

Keeping the extrinsic parameters unchanged can bring the errors from extrinsic parameters into the system, which may also affect the gravity alignment. When the roll or pitch angle is incorrect, the performance will be degraded.