Height drift when using Map Builder

[lsdta]

Thanks @hyye for the open source code, I've been running your algorithm with my own rosbags, however whenever map builder (4D) is enabled, the trajectory has a slow map height (z-axis) drift, similar to #18.

Disabling 4D (rotational constraints) removes the height drift, however the map produced (3min long dataset) has some errors in Z due to planar motion, just as #18 experienced. The extrinsic estimation step seems to be working correctly. The issue does not occur when using LOAM-only as well, as expected. The rotational constraints refinement sounds promising but I cannot get it to work without this extra height drift.

Has anyone also experienced this problem and managed to fix it? I'm stumped on what is causing this issue.

[hyye]

Hi @lsdta, thanks for pointing out. My understanding is that the rotational constraints can improve globally orientation error but not the z-axis translation, which may come from the odometry. Disabling this part makes the system almost the same as the LOAM's mapping. BTW, setting skip_count in the mapper to 1 may reduce the drift from the odometry by avoiding taking the odometry directly.

[lsdta]

Thank you for the quick reply. Am I right in that setting enable_4D=false and running processor/estimator/mapbuilder nodes is essentially running LIO (rather than LIO-mapping)? Or does enable_4D=false revert it back to your implementation of LOAM?

I will try out the rotational constraint with skip_count=1, is there any reason other than computational efficiency that pose optimization is not run every step of odometry by default?

[lsdta]

Am I right in that setting enable_4D=false and running processor/estimator/mapbuilder nodes is essentially running LIO (rather than LIO-mapping)? Or does enable_4D=false revert it back to your implementation of LOAM?

And if it does revert it to your implementation of LOAM, which part of the code needs removing to run LIO rather than LIO-mapping (as designated in your paper). That is, how to run LIO without rotational constraints but continue using IMU updates?

[hyye]

Or does enable_4D=false revert it back to your implementation of LOAM?

Yes. It will still take IMU information in the odometry node (two separated nodes).

I will try out the rotational constraint with skip_count=1, is there any reason other than computational efficiency that pose optimization is not run every step of odometry by default?

The not for efficiency, the computation time remains almost the same. It's for some tests.

[lsdta]

Yes. It will still take IMU information in the odometry node (two separated nodes).

I am finding that /predict_odom can often deviate quite far from /aft_mapped_to_init when enable_4D is off, which is what led me to believe that it was not using the IMU data at all for odometry.

[lsdta]

@hyye I also noticed that your video only showed Top-Down view when doing the car-tests, did you also experience error in Z-axis when doing planar-motion?

[hyye]

I am finding that /predict_odom can often deviate quite far from /aft_mapped_to_init when enable_4D is off, which is what led me to believe that it was not using the IMU data at all for odometry.

It does affect the mapper node only.

I also noticed that your video only showed Top-Down view when doing the car-tests, did you also experience error in Z-axis when doing planar-motion?

There is no z-axis drift in the golf-cart tests in my video.

[lsdta]

Thank you, you have cleared some things up and I believe height drift is coming from an incorrect odometry that is only mapped incorrectly when using 4D.