Odometry Failure

[youwyu]

Unfortunately, SLICT fails with my self-recorded dataset. For some reason, I cannot share the dataset, but it's a simple industrial environment. I guess the reason for odometry failure is FRONT END. However, the direct method FASTER-LIO, and feature points method LIO-SAM, both succeed in the whole run. I share the configure file and recorded opt_stat rosbag below.
Please rename the "ls.txt" to "ls.yaml", "opt-state.txt" to "opt-state.rosbag".
ls.txt
opt-state.txt

[brytsknguyen]

Hi Fisher,

I have checked the opt_stat topic and found very few factors so I guess you must be working in a constrained space. Could you try reducing the assoc_spacing parameter to something like 0.2m to see if the number of factors increases. This is in the field surfFactors of the /opt_stat msg. It is also printed out in the terminal here:

Other params that can be considered are:

ds_rate, setting this to 1 means we will keep all points. ds_rate > 1 is meant to reduce the computational load.

max_lidar_factors: is the maximum number of factors to use for solving, also to reduce the computation load.

May be you can include a screenshot or screen recording of the terminal output when the algorithm is running?

[youwyu]

Appreciate for your time.
The space is about 100x400 m^2 with rich landmarks. I changed the following params.
assoc_spacing: 0.8 -> 0.2
ds_rate: 4 -> 1
max_lidar_factor: 4000 -> 40,000
In the first minutes, the odometry is normal cause the vehicle does not move. Please check the terminal log from the end,
I only recorded few minutes of odometry "flying" when the vehicle starts to move.
terminal.txt

[youwyu]

To be specific, I use lslidar ch 16 and 3DM-GX3-25. I also tested on an easy dataset in a campus environment. Unfortunately, the odometry "flies" at the very beginning.
Update:: I tested on the handheld.bag from LIO-SAM. The result is quite good in the beginning, but it also drifts. I use the same params as above.

[brytsknguyen]

Hi,

I notice that the initial cost for the IMU factor is very large in your run. This indicates that the imu is badly intialized. Is your data captured in the middle of movement instead of from static condition?

SLICT uses a simple initialization of IMU. It just averages the IMU samples in a short period at the beginning, assuming the setup is relatively still, to initialize the IMU biases, if you start out in the middle of an agressive motion, the bias can be errornous and cause the algorithm to diverge.

I cannot find a handheld.bag in LIO-SAM public folder. But I have tried the campus_small_dataset.bag with the following setting.

liosam_data.txt

One important change is to shorten imu_init_time from 1.0 s to 0.1 s since the dataset also starts out with an agressive motion.

[youwyu]

Thank you for your patience. I successfully run compus_small_dataset by limit imu_init_time to 0.1 seconds. However, I still cannot run on my dataset. The initial cost for IMU is relatively large. I checked the dataset and found that the vehicle starts from static condition, but a little bit inclined with gravity.