Publish time with Azimuth window enabled and timestamping

[jdomlac]

Hi, we have some doubts about the behaviour of the driver when the azimuth window is enabled.

My first doubt is whether by activating this feature, the point cloud is published when the scan ends in the given window or it waits to physically end at the origin (0º).

The second one is regarding the time stamps, as I understand, this time stamp corresponds to the beginning of the scan, and the individual time of each point corresponds to the time since the beginning of the scan in ns. If I activate the azimuth window, does this time stamp stay at the origin (0º) or corresponds to the beginning of the azimuth window? I'm using the time stamp from ROS Time.

Thank you very much

Platform

• Ouster Sensor? OS-1
• Ouster Firmware Version? 2.5.1
• ROS version/distro? noetic
• Operating System? Ubuntu 20.04
• Machine Architecture? x64

[Samahu]

@jdomlac Thanks for contacting us, before I begin, I would have to admit that my answer won't be very complete and there is a bit of work that we may need to do on our side since I didn't experiment sufficiently with the timestamp value when azimuth window is reduced. I will however give you some insights for now

When examining timestamps you need to distinguish between two cases: TIME_FROM_ROS_TIME and time from the sensor (which includes any of the 3 options: TIME_FROM_INTERNAL_OSC, TIME_FROM_SYNC_PULSE_IN, TIME_FROM_PTP_1588).

My first doubt is whether by activating this feature, the point cloud is published when the scan ends in the given window or it waits to physically end at the origin (0º).

The second one is regarding the time stamps, as I understand, this time stamp corresponds to the beginning of the scan, and the individual time of each point corresponds to the time since the beginning of the scan in ns. If I activate the azimuth window, does this time stamp stay at the origin (0º) or corresponds to the beginning of the azimuth window? I'm using the time stamp from ROS Time

For the case when we use the time from the sensor we use the timestamp value of the first valid column in the scan as the point cloud timestamp. For the TIME_FROM_ROS_TIME option, the timestamp used for the scan (point cloud) is the host time when a packet that with new frame_id is detected, Note that this doesn't necessarily coincides with the first column of the scan since packets could come out of order.

This was the case for the majority of the time before the #67 where I have implemented a technique to infer the scan timestamp when packets might be missing at the beginning of the frame. In this case we provide an estimated value based on the last valid timestamp of last frame/scan and the first valid timestamp of current frame/scan.

What I am not mostly certain about is whether while performing scan timestamp estimation that we have fully considered the case when azimuth window is reduced. I know for example of a PR that was contributed to us by another user #73 that touches on this subject but I haven't had the time to follow through it and integrate but I think it is worth checking if that's something of a great concern to you.

I will try to get back to you by next week with greater details concerning the current behavior of the driver when azimuth window is reduced i.e not 360 and what would happen when packets are missing at the beginning of the scan or the start of the azimuth window.

[bexcite]

@jdomlac
re:

My first doubt is whether by activating this feature, the point cloud is published when the scan ends in the given window or it waits to physically end at the origin (0º).

I would guess that scan is published not earlier than the first packet of the next scan is received, i.e. it's even "worse" (i.e. even later) than reaching the origin 0 angle, because if your window is not in origin it will be only after the encoder reaches the azimuth window set and get it first 16 columns that will be send as a lidar_packet over the UDP. (that's the way how our default ScanBatcher, lidar_packet accumulator, in Ouster SDK is implemented).

[jdomlac]

Another question regarding the azimuth window I had while experimenting these last days, is that I want to use the Multipurpose I/O for triggering another sensors, preferably I would like it to trigger at 65 degrees. By using the OUTPUT_FROM_ENCODER_ANGLE I'm able to generate the necessary signal each 65 degrees, but I only need it to trigger once per scan when the angle is 65 degrees, at the moment I have only achieved to trigger it once per scan by setting the default 360º, which triggers the signal at 0º. I am missing something on the manual that would help me achieve the desired behaviour?
Many thanks,

[Samahu]

Another question regarding the azimuth window I had while experimenting these last days, is that I want to use the Multipurpose I/O for triggering another sensors, preferably I would like it to trigger at 65 degrees. By using the OUTPUT_FROM_ENCODER_ANGLE I'm able to generate the necessary signal each 65 degrees, but I only need it to trigger once per scan when the angle is 65 degrees, at the moment I have only achieved to trigger it once per scan by setting the default 360º, which triggers the signal at 0º. I am missing something on the manual that would help me achieve the desired behaviour? Many thanks,

This is rather a pure hardware question and I think you would be get better answer by contacting our customer support. I personally haven't used OUTPUT_FROM_ENCODER_ANGLE.