Publishing rate of the /veloydne_points topic may affect the KITTI Dataset odometry results

[claydergc]

I've been testing LOAM with the sequence 00 of Raw KITTI Dataset and I obtained wrong results as can be seen in this figure:

Then, I decided to use the code written by J. Zhang and tried the distortion free sequence 00 of the KITTI Dataset with a publishing rate of 10 Hz and this is what I obtained:

Finally, I decided to publish the point clouds with a rate equal to 2 Hz and it seems that it is producing good results, as can be seen in the following figure:

I was looking at the code and tracking the messages and I realized that when running at 10 Hz, the laserMapping node was not publishing its topics at the frequency it is supposed to do. This produced that this node dropped some messages from the topic /laser_odom_to_init, which seems to be a similar case to the issue #108

My computer is an Intel Core i7-7500U CPU @ 2.70GHz × 4 and I ran the code in Ubuntu 18.04 with ROS Melodic

[michaelczhou]

@claydergc hello，can you tell me how to plot the results of loam and how to calculate the RMSE ? I run the program in ROS.thx!

[claydergc]

Hello @michaelczhou I just updated the code I used to plot the last trajectory of the sequence 00 of the KITTI Dataset to https://github.com/claydergc/loam_velodyne_kitti_ros/. To calculate de errors you have to download the odometry development kit on the KITTI website and extract the transform matrix between scans. I plan to do that later, but now I don't have much time. I am also interested in reproducing LOAM's originai results in the KITTI Dataset. Let me know if you success on that.

[sume-cn]

@claydergc I think I've found the reason why KITTI raw does not run well. The data arrangement in velodyne pcap frame is according to the scan sequence. But the data in KITTI raw bin is according to the ring sequence, so the transformToEnd() and transformToStart() will not work correctly. You can visualize the points in a frame one by one, the former has only one rotation, the later has multiple rotations.

[claydergc]

@sume-cn the velodyne pcap is the format the data comes when using the physical lidar?

[jlblancoc]

@sume-cn the velodyne pcap is the format the data comes when using the physical lidar?

pcap is this format, it's used to keep an exact copy of IP network packets.

So: yes. Replaying a .pcap file emulates almost 100% having a live sensor online.

[jlblancoc]

sume-cn the velodyne pcap is the format the data comes when using the physical lidar?

The data arrangement in velodyne pcap frame is according to the scan sequence.

@claydergc so @sume-cn meant here that the actual network packets represent the Velodyne scans not as a whole 360 deg. scan, but only the range from all lasers for a handful of directions at once, as the sensor rotates. Refer to the sources of the velodyne driver node for more details...

[claydergc]

@sume-cn @jlblancoc so, you mean that transformToEnd() and transformToStart() only work correctly when the data arrangement is in pcap format?

[sume-cn]

@sume-cn @jlblancoc so, you mean that transformToEnd() and transformToStart() only work correctly when the data arrangement is in pcap format?

Yes, exactly

[jingyibo123]

@sume-cn Where did you download the raw KITTI dataset with velodyne data in pcap format? How to download the raw data for a specific KITTI odometry sequence?

Thanks

[wangx1996]

@jingyibo123 Did you solve it?

[jingyibo123]

@jingyibo123 Did you solve it?

I have not found the link to download raw KITTI dataset in pcap format, but I found the correspondence between KITTI Odometry an KITTI raw data in the readme.txt of devkit_odometry.zip

Nr.     Sequence name     Start   End
---------------------------------------
00: 2011_10_03_drive_0027 000000 004540
01: 2011_10_03_drive_0042 000000 001100
02: 2011_10_03_drive_0034 000000 004660
03: 2011_09_26_drive_0067 000000 000800
04: 2011_09_30_drive_0016 000000 000270
05: 2011_09_30_drive_0018 000000 002760
06: 2011_09_30_drive_0020 000000 001100
07: 2011_09_30_drive_0027 000000 001100
08: 2011_09_30_drive_0028 001100 005170
09: 2011_09_30_drive_0033 000000 001590
10: 2011_09_30_drive_0034 000000 001200