How to get the begin time of each point cloud?

[gunheeShin]

Hello, @minwoo0611 Thanks for the great work.

I'm currently running LIO alogorithm using HeliPR dataset and have question about getting the begin time of each pointcloud.

When running the LIO algorithm, the exact time of a single point is necessary for deskewing. And the exact time is calculated by adding the time value from each points' field to the begin time. (Here, the time value is the difference between start time and aqusition time of each point. For example, uint32_t time_offset_ns in AevaPointXYZIRT struct) As far as I know, many LIO algorithms use the header.stamp of the msg as the begin time of pointcloud.

However, in the pointcloud msg which published by this player, the timestamp from "stamp.csv"(which is same with the name of the bin file) is stored in the header.stamp of the msg. And this timestamp is corresponds to the aqusition time of the pointcloud not the begin time of pointcloud(it might be close to the end time of pointcloud).

So i tried to calculate the begin time by substracting the time value of last point from the header.stamp of the msg. But the result of the LIO algorithm is worse compared to considering the header.stamp of the msg as the start time (default setup).

So, in summary, could you give some advice how to accurately determine the begin time of each pointcloud?

Thanks for the advices!

[minwoo0611]

Hello, @gunheeShin

Thank you for reaching out and for your interest in the HeliPR dataset. As you mentioned, many LIO algorithms use the start time for synchronizing with IMU sensors, and for undistortion, the time offset saved in each point's time_offset is also necessary.

We save the start time of each LiDAR scan in header.stamp, and we rechecked whether it is from the last point. Upon reviewing our sensor drivers for logging, we confirmed that we first subscribe to the LiDAR data, save their header.stamp directly in stamp.csv, and use it to name the bin file. This means our header.stamp comes from the start time of the point cloud, not the acquisition time.

I'm curious why you believe it to be the acquisition time. Based on my experience, I have had no issues running MA-LIO and many other algorithms such as LOAM, LeGO-LOAM, KISS-ICP, DLO, VoxelMap, LIO-SAM, FAST-LIO2, Faster-LIO, DLIO, and POINT-LIO in the Roundabout sequence (you can check here).

Best Regards, Minwoo

[gunheeShin]

Hello, @minwoo0611

Thanks for your detailed response.

According to your explanation, if the timestamp in stamp.csv is indeed the same as the header.stamp of the subscribed LiDAR message, which represents the start time of the LiDAR, then there is no issue.

The reason I believe the stamp in stamp.csv is the acquisition time is because in section 4.1 (Data Format) of the HeLiPR paper, it states, "The acquisition time of all measurements is stored in stamp.csv." I misunderstood the mean of the aqusition time to the time when the message was subscribed, rather than the actual header.stamp in the LiDAR message.

Also, thanks for recommending the reference paper.

I have one more question about the synchronization: I understand the four types of LiDAR were subscribed together using PTP (Precision Time Protocol). Then, can I assume that the synchronized pairs are in the order of the bin files in the LiDAR folder? For example, in each folder, can I consider the first bin file from each folder as a synchronized set, the second bin file from each folder as another synchronized set, and so on?

Thanks for your kind assistance!

Best regards, Gunhee

[minwoo0611]

Hello, @gunheeShin

Firstly, sorry for the late reply!

As we do not subscribe to them all together but subscribe in parallel, the synchronized pairs are not in the order of the bin files in the LiDAR folder. I recommend you use a file player and ROS message filters to combine the sets where the time difference is not large.

I hope this message will help you.

Best regards, Minwoo

[gunheeShin]

Thank you for your reply, @minwoo0611

Your response has been very helpful to me.

Best regards, Gunhee