Something wrong with spin lidar(ouster64)

[chengwei0427]

Hi, thanks for your interest!

To support other types of lidar, some modification works are needed:
1. You need one external IMU to publish the information. Also, extrinsic information is also needed.
2. If the point cloud pattern is different from Livox, the feature extraction block needs to de updated accordingly.
3.  The backend for LIOs with different types of lidar is similar.

Bests,

_Originally posted by @SiyuanHuang95 in https://github.com/PJLab-ADG/Livox-Mapping/issues/2#issuecomment-1047702546_

Hi, everybody

As mentioned above, I modify the "ScanRegistration.cpp and LidarFeatureExtractor.cpp" for my spin lidar--ouster,and the code is implemented based on lio_sam. Now, the feature extract module is normal. And the result is good with the IMU_Mode is 0 and 1. But there's something wrong when IMU_Mode is 2(Tightly Coupled IMU).

As the picture above, when process "Frame:4654", the trajectory starts to shift. The points and imu data record by ouster laser(OS1-64), so the transformation matrix of the laser and imu is the unit matrix. Other parameters are default. The printing parameters are as follows:

What causes this? Do you have a similar situation? Thanks again.

[SiyuanHuang95]

Hi, since I do not have access to your data and code, I would give my personal intuition directly.

There are several possible reasons:

1. The calibration issues between your LiDAR and IMU, including temporal and spatial. When setting IMU mode to 0 or 1, the IMU does not affect the performance greatly. But when in tightly-coupled mode, the calibration accuracy would impact the fusion greatly.
2. The recorded rosbag quality. Can you try another rosbag file?
3. Maybe the 4654th frame is in sharp motion, which will make the calibration and rosbag issue worse.

Bests,

[chengwei0427]

Hi, @SiyuanHuang95

Thanks for your patient response.

1. The test bag record by ouster laser(laser and imu), so the timestamp is hardware synchronous , the transformation matrix between lidar and imu may need to check .

2. Only test one bag currently, I'll test more bag.

3. The 4654th frame is in sharp motion, and the max angular velocity is around 0.35rad/s.

Thanks again.

[SiyuanHuang95]

Hi,

I would suggest you test it with more rosbags and see whether it would always fail when in sharp motion since sharp motion is always challenging for LIO and requires higher accuracy for calibration and IMU itself.

Also, you are quite welcome to make a PR when the Ouster64 part is finished.

Best.

[chengwei0427]

Hi, @SiyuanHuang95

Thanks for your response.

I've tested 3 bags recored by my ouster OS1-64 lidar. Everything is ok at the first few hundred seconds, but after a period of time(500+/1000+ second), there is a drift after a bump or rotation, it's strange.

I'll test more bag.

Last, I uploaded the modified code here

[SiyuanHuang95]

Hi,

It's a quite huge rosbag for more than 500 or 1000 seconds, which will be hard for the optimization backend. We have not tested with such large-scale collected rosbags, so no specific info could be offered.

When I have free time in the short future, I would investigate this issue more deeply.

[chengwei0427]

Hi, @SiyuanHuang95

Thanks for your response.

Maybe the problem is in the transformation matrix between lidar and imu. I'll check and update the result here.

Thanks.

[SiyuanHuang95]

Hi,

if the problem rises due to the transformation, maybe it should drift from the very beginning?

Wait for your updates.

Best

[chengwei0427]

Hi, @SiyuanHuang95

I found the problem that the timestamp about the publish /livox_full_cloud is wrong. It's my mistake, I should be more careful. Now the program is running well.

The demo about the west.bag.

Thanks again for your help, and the issue is solved, I'll close it.

[SiyuanHuang95]

Hi, glad to hear that!

And thanks for your interest!