There is some drift in the direction of height.

[liunao123]

Hello , this is great work for LIVO. I test my device with your fantastic work recently. I meet one question : when I walk a short path about 200m, a circle, end at start position , odom is OK. even perfect. like first picture. then when I walk long distance circle, about 1000m,like above, end at start position. there is a obvious drift at height direction .like second picture. Can you give me some suggestions to improve this problem？ 3Q. ^_^.

I think IMU ( my device is HMS-MM-VRU-UM 01) may be important. I try get IMU noise parameter by https://github.com/gaowenliang/imu_utils tools . then fix cov_gyr and cov_acc parameter. I wish it will be useful.

[FPSychotic]

To IMU tools or similar works properly you need record a very long bag like 6h or more I would leave all night, just in case you didn't know, but you probably know it.

You could use GNNS only for altitud correction with robot localization, just a fast idea, I have a GNSS but it is not implemented when I used Fast LIO

By the way , are you using a 360 lidar? Can I ask you what model?

[WFram]

Sometimes, it needs to inflate IMU noise parameters by factors 10, 100, 1000 to find the best working configuration in VIO/LIVO setups. Also, if you use a camera in this setup, it may affect height drift even more than IMU. I would suggest to check camera calibration parameters as well.

[liunao123]

@FPSychotic . Yes . I test with 16-line 360 lidar. now, I collect about 3h imu static data to get IMU noise parameter. as you say, today I will collect 6h (maybe all night) imu data to do it again. you will know it if I get some better result. About GNSS ,eeeee, this sensor is not considered now for me.^_^.

@WFram . Thank you very much,^_^. I try inflate IMU noise parameters by factors 10, 100 or more .as you say, it make diffence, the odom seem be better. about camera calibration, I calibrate its Intrinsics and Extrinsics(Rcl). Sure, you may have some tips about it. Thanks for your suggestions.I'm still testing it, you will know it if I get some better result.

[xuankuzcr]

Hello , this is great work for LIVO. I test my device with your fantastic work recently. I meet one question : when I walk a short path about 200m, a circle, end at start position , odom is OK. even perfect. like first picture. then when I walk long distance circle, about 1000m,like above, end at start position. there is a obvious drift at height direction .like second picture. Can you give me some suggestions to improve this problem？ 3Q. ^_^.

I think IMU ( my device is HMS-MM-VRU-UM 01) may be important. I try get IMU noise parameter by https://github.com/gaowenliang/imu_utils tools . then fix cov_gyr and cov_acc parameter. I wish it will be useful.

Hi liunao, Thanks for your interest and feedback on our work. As for the height drift, I think there are two main reasons:

1. Because the included angle of the points on the ground is too large, the measurement is inaccurate, and the measurement obtained perpendicular to the incident plane is the most accurate.
2. The ground is a continuous feature, and drift will occur gradually. Although each local map is good, the pose gradually produces errors, which is also a common fault of odometry.

My suggestion is to select more points on the ground and give more noise. As for the imu noise, the larger the setting, the more trusting the LiDAR measurement, and the thinner the map will be, but there will still be the reason 2 I said.

[liunao123]

@xuankuzcr Thanks for your suggestions. My lidar is16-line 360 RoboSense lidar. As you say , Now I try select more points on the ground and continue testing. 3Q again. ^_^.

[liunao123]

@xuankuzcr Firstly. thank you very much, based on your suggestions, great progress has been made for me. I have continued to test my own data, I get a better result when I increase imu noise and fix it in code. ( I fix gravity too, when I start from static status .)
However .I have two questions:

1. Under the same conditions (parameters, data, and computing environment), the results of multiple runs were completely consistent in the early stages(first ~200 seconds), but as time passes, differences in the trajectories began to appear. like pictrue A, it is strange.
2. In indoor case. the trajectory is getting more and more distorted .When I test this fantastic work. at beginning, the trajectory is good. but when the odometry has been running a while, for example, from ~300s, the odometry is getting more and more distorted.like picture B. If I skip first 300s data, the trajectory is OK at the beginning, like picture C. Unfortunately, over time, the trajectory will still getting very badly distorted like picture B. The likelihood of this phenomenon occurring increases when I make a turn(pictrue D) or I set a smaller filter_size_map(0.2 , 0.3).

Can you give some suggestions to fix it? thanks you again, ^_^.

[Camilochiang]

@xuankuzcr Firstly. thank you very much, based on your suggestions, great progress has been made for me. I have continued to test my own data, I get a better result when I increase imu noise and fix it in code. ( I fix gravity too, when I start from static status .) However .I have two questions:

1. Under the same conditions (parameters, data, and computing environment), the results of multiple runs were completely consistent in the early stages(first ~200 seconds), but as time passes, differences in the trajectories began to appear. like pictrue A, it is strange.
2. In indoor case. the trajectory is getting more and more distorted .When I test this fantastic work. at beginning, the trajectory is good. but when the odometry has been running a while, for example, from ~300s, the odometry is getting more and more distorted.like picture B. If I skip first 300s data, the trajectory is OK at the beginning, like picture C. Unfortunately, over time, the trajectory will still getting very badly distorted like picture B. The likelihood of this phenomenon occurring increases when I make a turn(pictrue D) or I set a smaller filter_size_map(0.2 , 0.3).

Can you give some suggestions to fix it? thanks you again, ^_^.

Out of curiosity. What is the status of your ram memory along time ? and how many cores are you using?

[liunao123]

@Camilochiang total ram is 16G，I have 12core. use 6 core.

[Camilochiang]

@Camilochiang total ram is 16G，I have 12core. use 6 core.

And how much have you use after 390 seconds?

[liunao123]

about 50% for ram. Do you think I do not have enough computational resources?

[Camilochiang]

about 50% for ram. Do you think I do not have enough computational resources?

No. I was just asking me if it was the case but it doesn look like

[xuankuzcr]

To be honest, I also think there's not enough memory left. You can send me the bag and I'll test it @liunao123.

[satyajitghana]

i have similar issues, did compute solve it?

[satyajitghana]

can you send me your bag files? @liunao123

[liunao123]

i have similar issues, did compute solve it?

As @xuankuzcr say, I try to select more ground points. odometry get little better. My bag file , I will send one to you , just wait a montinue.

[liunao123]

https://drive.google.com/file/d/1CJaFLg4SziRWqTffU7swW15B4vGYLIJp/view?usp=sharing @xuankuzcr @satyajitghana There is my test bag(sensor: livox HORIZONAL lidar and MV-CS050-10GC camera) and parameter. the pointcloud is ok. the rgb pointcloud is not good, the color of some points does not match its position. please tell me if you test a precise pointscloud. thanks ......

[xuankuzcr]

The timestamps of your camera frame need to be shifted by +0.1 seconds, with the camera and LiDAR being offset by one frame. Additionally, the images were not in focus throughout the entire capture process, as shown in the following picture:

[liunao123]

@xuankuzcr Thank you for your reply. I'll try it later. The images were not in focus -_- , it's better after I adjusted the focus . thanks again ......