Meaning of the time field value

[alexsaso]

I already posted this question as an answer to #350 but only then saw it was already closed so I decided to post it here again. My question extends one of one of @narutojxl questions asked in #350 because I did not find it answered there. It is about the infromation coming from the time field every point gets by the driver.

So when I look at one lidar message, it contains some information for 24x16 points, so every single ray was fired 24 times. Each of these points now contains 6 values, the x, y, z - coordinates, intensity, ring and time.

Adding to @narutojxl question, I would like to know how I have to read the time field of each point. Is it as he suggested the negative offset from the messages timestamp or rather a positive offset? So that a points time is calculated as point.time_corrected = msg.timestamp + point.time, or rather as point.time_corrected = msg.timestamp - point.time? I could not find this part in the code linked by @JWhitleyWork.

By time_corrected I mean the actual time when that point was created. msg.timestamp refers to the the timestamp of the packet, being the time of the firing of the first or the last firing in that message, as defined by timestamp_first_packet. Lastly point.time is the value contained in the timefield of that point.

Another thing which I noticed was, that right now most of the timefields in the messages which I receive using this driver are set to zero. Only the fields of the points coming from ring 0 actually have a positive value corresponding to the time it takes for one firing sequence to complete, as defined in the Velodyne manual. So the values are 3.456e-5, 8.9856e-5, 1.45152e-4 and so on. Is this the normal behavior for the driver?

[Freddd13]

@alexsaso I also have the same issue. Do you solve it now?

[alexsaso]

Hi @Freddd13. I have sort of a solution. As mentioned in the original question above, there are two timestamps with meaning:

• message timestamp This is the time of creation of the packet, which will be timestamp of the first point if you have the driver setting to timestamp the first packet.
• point timestamp This are hard coded time offsets from the message timestamps, as defined by the Velodyne manual.

In case you want to time stamp all the points, you would have to add the message timestamp and time offset of the individual point. As the time offsets are hard coded, while message timestamps are created when driver gets points from the sensor, it can happen that the last points of the n-th packet have a time greater than n+1-th packet.

You can solve it by ignoring the time offsets (set them to 0.0; post-processing, or in driver), and accept that all the points in individual pocket have the same timestamp. To minimize the error caused by the same timestamp, you should set the npackets parameter in velodyne driver to 1. This will publish packets at ~760 Hz (packet per 0.0013 s).

[Freddd13]

@alexsaso Thank you for such a detailed explanation. I think I roughly understand it.