distortion_corrector cannot compensate point cloud while passing over speed bump

[mebasoglu]

Checklist

• [X] I've read the contribution guidelines.
• [X] I've searched other issues and no duplicate issues were found.
• [X] I'm convinced that this is not my fault but a bug.

Description

While passing over a speed bump, the point cloud has a strange behaviour and distortion corrector cannot fix it. This causes ghost points and ground remover cannot delete them. (https://github.com/autowarefoundation/autoware.universe/issues/3673)

Here is a video of VLS-128 driving on a speed bump:

https://github.com/autowarefoundation/autoware.universe/assets/13589149/6533aa07-b2fc-41b8-badd-8b50eec7fe34

Expected behavior

Distortion corrector should compensate point cloud while driving over speed bump.

Actual behavior

Distortion corrector cannot fix point cloud on speed bump.

Steps to reproduce

Drive your vehicle on speed bump with a lidar such as VLS-128 and you will see the behaviour.

Versions

• OS: Ubuntu 22.04
• ROS 2 Humble
• Up-to-date main branch of Autoware

Possible causes

No response

Additional context

No response

[VRichardJP]

Just to make sure, are you talking about the point cloud crack at road level here:

[mebasoglu]

Just to make sure, are you talking about the point cloud crack at road level here:

Hello, yes, I am talking about that.

[VRichardJP]

Indeed, current implementation has not been designed to handle speed bumps. Distortion corrector only takes into account linear speed (twist_it->twist.linear.x) and yaw rate (imu_it->vector.z). To handle speed bumps, it would be necessary to check pitch rate as well (imu_it->vector.y).

I am not sure the math is much harder. However, while absolute linear and yaw acceleration stay usually low (i.e. speed and yaw rate are almost constant at scan level), pitch acceleration goes pretty high when the car hits a speed bump. So for the compensation to work properly, it would be necessary to have well synchronized sensors and high frequency IMU. If there is any delay in the measurement, you would end up with the wrong points being corrected, and the "corrected" result would be worse than the non-corrected one.

[stale[bot]]

This pull request has been automatically marked as stale because it has not had recent activity.