ROS2 driver: Lidar Packet timestamps

[kavishmshah]

Hey all!
We are working with the ouster ROS2 driver and had a few questions about the packet timestamp and packet collection. The questions are as below:

1. Are the relative timestamps for each column always referenced to 0 degrees?
2. Do packets start being sent from whatever angle the lidar is at when after initialization is complete? Or do the packets always start from 0.
3. How does ScanBatcher determine a full scan has been received?

Thanks in advance!

[Samahu]

Are the relative timestamps for each column always referenced to 0 degrees

For packet timestamps you can not make this assumption since UDP packet are subject to coming out of order. The packet timestamps is recorded when the packet is received by the host machine. You probably want to check the measurement timestamps which uses the sensor clock and the time corresponds to the actual time of the measurement regardless of the order of packet arrival.

Do packets start being sent from whatever angle the lidar is at when after initialization is complete? Or do the packets always start from 0.

I don't know exactly but I am not sure why exactly this is important. During the initializing you may get a partial frame but that could be to other factor within the network (some packet drops) and not necessarily tied to way the sensor operates.

How does ScanBatcher determine a full scan has been received?

The question should be: when ScanBatcher yield a scan (i.e it returns true on accumulation, this is important as ScanBatcher does not necessarily always return a full scan)

In a nutshell, The ScanBatcher will yield a lidarscan the moment the it receives a packet from the following frame (i.e. new_packet.frame_id == current_scan.frame_id + 1), when this condition is met ScanBatcher will move the new_packet to an internal cache, finalize the current scan and retruns true, this means if for whatever reason a packet from the next frame shows up earlier in the network than the remaining packets of the current scan being accumulated, it will signal a scan finalization event and yield the current scan.

Please note in a future update, this logic will be slightly changed to return immediately once all packets from current scan have arrived.

Best

[kavishmshah]

Hi @Samahu ,
Thanks for the response.

What we are interested in getting is the measurement time at a certain angle.And, hence what we are trying to understand is if we can add the measurement timestamp from that angle to the time that already goes out in header.stamp.
For example, if we are using an azimuth range of [90, 270], we want that frame to have a timestamp associated to angle 180.

In addition to this, can you also explain what is the purpose of having compute_scan_ts_0 and compute_scan_ts_n
in lidar_packet_handler.h?

[Samahu]

we are trying to understand is if we can add the measurement timestamp from that angle to the time that already goes out in header.stamp

Every point in the PointCloud object has a timestamp (t) which represents the measurement timestamp; this timestamp correlates with the capture angle. Refer to this thread for more details: #206

The compute_scan_ts_0 and compute_scan_ts_n are the same thing but compute_scan_ts_0 is handling the initialization before switching to compute_scan_ts_n. They provide an estimate of the scan/message timestamp when the leading measurements (first columns) are missing from the accumulated scan due to a packet drop or reduced azimuth window.

Hope this helps!

[kavishmshah]

So in a scenario, where my azimuth range is [90,270], and lets say the LiDAR when powered up, the motor is starting from an angle 45 degrees. What happens to the to the packets for points between 45 to 90 degrees. Are the packets created immediately or are the packets created once the encoder indicates the 90 degree(azimuth start)?

I'm a little confused about this since in the below image, its mentioned "Data frames start with the azimuth angle equal to 0".

[Samahu]

Every packet holds 16 measurement, so at least 16 measurements will have to be collected before the packet is created and put on the network immediately, delay should be less than 10 microsecond between last measurement time and when the packet is sent.

Also note since the sensor can vary in horizontal resolution you can't talk about the angles and packet in absolute numbers .. as the number of degrees scanned by an a packet will vary by the resolution.

In any case, this discussions board is more geared towards the ROS driver, if you have general sensor questions it would be better to post these question on Ouster community forum https://community.ouster.com

[kavishmshah]

Oh okay, that makes sense. Thanks!

also I was trying to output
info.beam_azimuth_angles

and I see the output something as below:
os_driver-1] Azimuth: -4.86
[os_driver-1] Azimuth: -12.21
[os_driver-1] Azimuth: 0
[os_driver-1] Azimuth: 1.74405e-321
[os_driver-1] Azimuth: 1.46877e-303
[os_driver-1] Azimuth: 9.61627e-129
[os_driver-1] Azimuth: 4.93473e-320
[os_driver-1] Azimuth: 2.538e-191

I glanced through Ouster's documentation, but wasn't sure if the azimuth angle here is in radians or something else?

[Samahu]

The azimuth and elevation data are in degrees

[kavishmshah]

do you know what range of azimuth is?
Because I see some extremely large and small values in the output.