't' timestamp field content is not plausible

[lukasj-imar]

Describe the bug
I'm switching from community driver to this driver. In my application I use the content of the t data field for pointcloud deskewing. The value of this field by the community driver contents the relative timeshift of each point since start of frame in nanoseconds. So for a OS1-128 in 1024x20 operation mode, the timestamp of the first and each 1024th point is zero. The ofifcial driver outputs the following timestamp values for the corresponding clouds:

point[0] = 49416704
point[12] = 0
point[1024] = 49806592

I don't have any idea of the meaning of these timestamps. Please let me know if you need further information.

To Reproduce
Configure with native or original pointcloud profile.

Platform (please complete the following information):

• OS1-128 rev. 7
• Firmware v3.1.0
• Timesyc method: PPS + $GPRMC
• ROS2 humble
• Ubuntu 22.04
• arch x86
• Release ros2-v0.12.0

[Samahu]

Hi @lukasj-imar,

I want to look further into this but my gut feeling this happens when the lidar packet stream have some missing packets which means there is no proper time for these points. You can tell if this is the case by examining any of the XYZ values for any NANs.
Another occasion of when this could happen is if you are using PTP clock and a sync event causes the shift to occur mid of the lidarscan. This would definitely result in some of the timestamps being zeros. What clock do you use?

[lukasj-imar]

Hi @Samahu,

thanks for your response. We use GPS + $GPRMC for time sync. The XYZ vals are fine, without any NaN entries.

My network config should also be fine, because I'm using the same setup with the community driver, without any communication problems.

[Samahu]

Hi @lukasj-imar, thanks for the feedback. I will look into this problem.

[Samahu]

Hi @lukasj-imar, I am taking a stab at this problem and have few questions to help me better understand the situation:

For the data sample you provide:

point[0] = 49416704
point[12] = 0
point[1024] = 49806592

Are these timestamps of the same frame? the issue I see is that point[1024] is at 49806592 (nanoseconds) while point[0] = 49416704 (nanoseconds) and the difference is only 389888 nanoseconds ~ 390 microseconds .. meanwhile for a regular 1024x10 the difference should be 100000000 nanoseconds ~ 100 milliseconds..and for a 1024x20 it should be 50 ms. The end value doesn't line up well. Am reading the data correctly? If so the problem might be in the connected clock. Do you get something similar when using the sensor alone without external clock source?

[lukasj-imar]

Hi @Samahu,

yes the timestamps are from the same frame, but the sensor is in 1024x20 mode, so point[1024] is round about in the right region of 50ms.

To see the influence of the external clock, I will do the same with the internal clock only and provide these results here asap.

[Samahu]

@lukasj-imar Just for your information I do see some discrepancy in the t values even when using the internal clock, I am still digging to find out the source of it.

[Samahu]

@lukasj-imar I have merged a fix for the problem, the timestamp values were being destaggered when they shouldn't be, which made the points and their timestamps inconsistent. The values should be aligned correctly whether you choose to consume a destaggered point cloud (the default) or a staggered one.

Note if you get zero values this is usually due to no returns in that spot in which the xyz values are NaNs and you should skip these values in your pipeline or use a non-organized point cloud which would skip the NaNs from the generated point cloud (if it makes sense for your pipeline).

Please let me know if you still observe an issue related to this topic.