search

zijiechenrobotics / ig_lio

iG-LIO: An Incremental GICP-based Tightly-coupled LiDAR-inertial Odometry
GNU General Public License v2.0
355 stars 48 forks source link

Drift in z using Livox MID-360 #20

Open LotfiZ opened 4 months ago

LotfiZ commented 4 months ago

Hello dear,

First, what an amazing work that pushes the LIO state of art further !

I started to play a little bit with the package using a LIVOX mid-360 on a grounded robot and i observed that in x-y the estimation is quite good, however there is a significant drift in Z, as you can see in the following picture : image

What do you think about this behaviour ? i can also provide the bag file if its necessary ! EDIT : To prevent that, is it possible to add a constraint regarding the flatness of the world ?

Thank you !

satyajitghana commented 4 months ago

same here! i've observed this with other LIO/LO algorithms also, fastlio, pointlio, voxelmapping, fasterlio.

aditdoshi333 commented 4 months ago

Same here!

schablonmassig commented 3 months ago

Hey fellow mid-360 users. Might this be due to the fact that the imu values are normalized in the topic, and has to be multiplied by gravity constant in order to be useful. I have yet to find a documented value which livox use internally, and we all have to guess. Which gravity values are you using? Do you see the same error when increasing/lowering the constant?

LotfiZ commented 3 months ago

Hi @schablonmassig, do you mean increasing/decreasing the 9.8 value in the ig_node ? And yes, i observed the same drift in all the SOTA LIO algorithms even without using IMU.

satyajitghana commented 3 months ago

@LotfiZ tried that, didn't work

i thought since imu gyr values are normalized, we would need to multiply the gravity factor to make it right, but that is not the case.

satyajitghana commented 3 months ago

maybe try this

enable_acc_correct: true
satyajitghana commented 3 months ago

tried fiddling with the gravity values, it drifts.

enable_acc_correct denormalizes the acceleration values by multiplying with 9.80665. But that also doesn't help.