kitti2bag.py doesn't add timestamps to pointcloud data about lio-sam

[FishInWave]

There is no need to add timestamps for points using KITTI data. The point cloud is corrected already. You can ignore that warning.

Hi, the velodyne points in KITTI odometry folder is undistorted while the raw data is not.

• readme.txt in KITTI odometry

IMPORTANT NOTE: Note that the velodyne scanner takes depth measurements
continuously while rotating around its vertical axis (in contrast to the cameras,
which are triggered at a certain point in time). This effect has been
eliminated from this postprocessed data by compensating for the egomotion!!
Note that this is in contrast to the raw data.

• readme.txt in KITTI raw data

IMPORTANT NOTE: Note that the velodyne scanner takes depth measurements
continuously while rotating around its vertical axis (in contrast to the cameras,
which are triggered at a certain point in time). This means that when computing
point clouds you have to 'untwist' the points linearly with respect to the velo-
dyne scanner location at the beginning and the end of the 360° sweep.

And the /config/doc/kitti2bag.py use the data from the raw data, so it seems we still should do enable deskew function.

[TixiaoShan]

There is no need to add timestamps for points using KITTI data. The point cloud is corrected already. You can ignore that warning.

[Pallav1299]

Thanks @TixiaoShan

[FishInWave]

The red one is 000000.bin in KITTI 00, the white one is 0000000000.bin in 2011_10_03_drive_0027 synced raw data. They are different. So raw data does need deskew.

[LongruiDong]

The red one is 000000.bin in KITTI 00, the white one is 0000000000.bin in 2011_10_03_drive_0027 synced raw data. They are different. So raw data does need deskew.

I also meet this warning when testing kitti-raw rosbag generated by kitti2bag.py, and the lio-sam can not give a resonable result, so have you figured out how to add timestamp to kitti raw pointcloud?

Thans in advance!

[Sonne-Zhu]

@LongruiDong hi, I think there are two solutions, one is to replace the lidar data in the raw data with the lidar data in KITTI odometry folder，and then run kitti2bag.py, so that the timestamp is not required. The second is to follow the deskew method in Lego-loam. Lego-loam uses the coordinates of each point to calculate the angle to estimate the timestamp of each point.

[kefa27]

The red one is 000000.bin in KITTI 00, the white one is 0000000000.bin in 2011_10_03_drive_0027 synced raw data. They are different. So raw data does need deskew.

@FishInWave hi, in fact you are right, kitti_raw and kitti_odom are not the same. However, you're image is not showing an inconsistency for the white or the red cloud, so that is no evidence that kitti_raw needs to be undistorted.
My experience showed that (despite the provided readme's from kitti) that kitti_raw is already undistorted and kitti_odom has to be undistorted. (I know it's confusing, but check it for yourself.)

Since @TixiaoShan is using kitti_raw, in my opinion, no undistorting/deskewing is neccessary.