imuPreintegration node problem

[oym1994]

Hi, thanks for your great job! I have tested the code with my own data and dig into the code details. The picture shown above was the topic relationship with the related nodes. As can be seen that, the output of the imuPreintegration node influenced only the imageProjection node, where the /odometry/imu_incremental is only used to in odomDeskewInfo . From the data flow, it seems that the imuPreintegration and related constraints have little influence on the final map and trajectory.

Some tests on my own dataset:

Test1: run with imuPreintegration node

Test2: run without imuPreintegration node

Test3: run with imuPreintegration node, but the odomDeskewInfo function is disabled in imageProjection.

Result: My own dataset1: rmse of the trajectories between Test1, Test2 and Test3 is very close (about 3mm);

My own dataset2: rmse of the trajectories between Test2, Test3 is about 0.2m, Test1 always failed and print "large velocity, reset imuPreintegration";

So does the imuPreintegration node really have little influence on the final result except that it provides /odometry/imu_incremental to help deskew the pointcloud? What is the really influence of imuPreintegration?

Thanks for your attention and I am keeping always forward to your kind response?

[JaySlamer]

What a great observation. Since the imu-preintegrations do not appear in the final global optimization, I do believe it is of little use. However, at least theoretically, it does help to predict the initial x y z of a scan better. So I guess when the vehicle is moving fast, maybe it help the problem to converge better.

[oym1994]

What a great observation. Since the imu-preintegrations do not appear in the final global optimization, I do believe it is of little use. However, at least theoretically, it does help to predict the initial x y z of a scan better. So I guess when the vehicle is moving fast, maybe it help the problem to converge better.

Yeah, thanks for your kind response. If just for a better initial guess, just use imu raw data to propagate may be enough.

[oym1994]

In my own dataset testing, here are some results: 1, Sometimes it will map failed in an i7 cpu while suceess in i9 cpu, which shows that this algorithm needs pretty heavy calculating resources; 2, It will sometimes fail when theres exits rotation and turning back; 3, If turning off imuPreintegration, it will always success.

It seems to be more stable without imuPreintegration . So my point of view is to replace imuPreintegration with another reliable
method to give a good initial and finally get a comparative precision, such as fusing other sensor, or executing ndt before icp.

Whether anyone else also have such view?

[oym1994]

Above pictures show the mapping results. Test platform is a laptop with i9 CPU and 32G memory. The first one is using imuPreintegration and mapping failed, the second one is without imuPreintegration and mapping successfully. It seems that the imuPreintegration can't hold such turning around.

[pauldeee]

@oym1994 out of curioscity did you confirm that your IMU transformations are completely correct?

Following these inscructions: IMU debug. It's strongly recommended that the user uncomment the debug lines in "imuHandler()" of "imageProjection.cpp" and test the output of the transformed IMU data. The user can rotate the sensor suite to check whether the readings correspond to the sensor's movement. A YouTube video that shows the corrected IMU data can be found here (link to YouTube).

In general LIO-SAM has performed flawlessly for me (Ouster w/ GX4). I've found that ensuring your IMU transformations are completely correct is vital. However, I have noticed that LIO-SAM can run OK without completely correct IMU transformations.

[oym1994]

@oym1994 out of curioscity did you confirm that your IMU transformations are completely correct?

Following these inscructions: IMU debug. It's strongly recommended that the user uncomment the debug lines in "imuHandler()" of "imageProjection.cpp" and test the output of the transformed IMU data. The user can rotate the sensor suite to check whether the readings correspond to the sensor's movement. A YouTube video that shows the corrected IMU data can be found here (link to YouTube).

In general LIO-SAM has performed flawlessly for me (Ouster w/ GX4). I've found that ensuring your IMU transformations are completely correct is vital. However, I have noticed that LIO-SAM can run OK without completely correct IMU transformations.

Thanks for your kind response. I believe the IMU transformations are correct. I have conducted many tests and it will fail only if it has such a turning around(but sometimes it may also success even with a turning around). The IMU is Xsens with 9 axises. Maybe is it not robust enough to such turning around?

[oym1994]

Test platform and sensor laptop with 32g memory and i9 cpu; robosense 16 lidar with 270 FOV xense 9 axies IMU

More successful cases:

other failed with imuPreintergration but success without : failed success

failed

success

[wienans]

Hi @oym1994 You say that you turned of imuPreintegration.

3, If turning off imuPreintegration, it will always success. Did you do more than not starting the imuPreintegration? As if i only don't start imuPreintegration it will not start to map at all

If you made changes maybe you can share them. Thank you in advance.

[oym1994]

Not any change, just comment the the _imuPreintegration related line in module_loam.launch. And the set "odom" as the fixed_frame in rviz. Then you can see the map.

It seems that only imu and lidar are in ideal conditions, the imuPreintegration can provide good performance.

[msgTwan]

Hi @oym1994 promising results.

I am using xsens hardware as well and looking to improve robustness. Do you mind sharing your IMU transformations or the full params file to compare results.