Is there a way to receive the generation and tramission ticks?

[Kaju-Bubanja]

Is there a way to receive the generation and transmission ticks described here: https://github.com/SICKAG/sick_scan_xd/blob/0c35a36cc4cf40d2a04325e2145112c27623acd1/doc/timing.md in the pointcloud ros2 message?

We have a problem with following assumption:

The time required for the transmission of data over the network is assumed to be short and constant and is therefore neglected

It doesn't seem to hold, because the timestamps we are receiving in ros2, don't neatly add up to 75hz for the LMS511. And for our application it would be better if we could work with the ticks directly to monitor that the sensor is really running with the specified Hz. We would than take the average from the generation and transmission ticks for the whole pointcloud, does that make sense?

[rostest]

The task of the software PLL is to provide a consistent system time stamp. The ticks are used for this according to the documentation. Most lidars only provide the transmission time stamp. In order to provide the information about the ticks to the outside world, we can install a mode that uses the following procedure:

• Read the first transmission timestamp and time-stamp it with the PC's system time. We call this system time START_TRANSMISSION_TS.
• We save the first transmission tick value in START_TRANSMISSION_TICKS.
• In each subsequent transmission i, we read ticks from the transmission timestamp.
• We calculate the difference in ticks to START_TRANSMISSION_TICKS.
• From this we calculate a timestamp for scan i according to the following logic. TS_i = (Ticks_i - START_TRANSMISSION_TICKS) * 1E-6 + START_TRANSMISSION_TS
• This time stamp is used.

You can use (TSi - TS(i-1))*1E6 to calculate the tick difference between two scans in microseconds.

Note that with this approach, the timestamp of the point cloud will deviate from the system time if the runtime is longer.

Would this approach solve your problem?

[Kaju-Bubanja]

This approach would solve our problem. This would be an ideal approach, a simpler approach which would already help us with our problem is to add the tick time additionally to the synced time in the /cloud ros2 msg

header:
  stamp1:
    sec: 1712674993
    nanosec: 892498970
  stamp2:
    sec: 157
    nanosec: 295397000
  frame_id: cloud
height: 1
width: 361
fields:
- name: x
  offset: 0
  datatype: 7
  count: 1
- name: y
  offset: 4
  datatype: 7
  count: 1
- name: z
  offset: 8
  datatype: 7
  count: 1
- name: intensity
  offset: 12
  datatype: 7
  count: 1
is_bigendian: false
point_step: 16
row_step: 5776
data:

with the stamp2:

  stamp2:
    sec: 157
    nanosec: 295397000

Is this a feasable solution? If you could give me a rough overview of the steps needed to achieve this I can implement it.

I guess it involves changing creating a custom sensor_msgs/msg/PointCloud2 message, which would be a subtype of the unmodified sensor_msgs/msg/PointCloud2, I'm not sure if this would work then with tools like rviz?

Because ideally we would have both timestamps one for synchronization and the other for more accurate measurements

[rostest]

Thank you for your reply. Changing the default header in a customised PointCloud2 message may cause compatibility issues with standard tools such as rviz. We are therefore planning to implement the above solution with a configurable timestamp mode.

[Kaju-Bubanja]

Ok, makes sense.

For clarification in the approach you propose above would it be possible to have both the synced time and the tick time in a message or would the two modes be incompatible and one would have to chose which one to use?

[rostest]

The ROS sensor_msgs/msg/PointCloud2 messages have one time stamp in the header. We will implement a configurable option to choose between "system time stamps" and "tick time stamps".

[rostest]

@Kaju-Bubanja We implemented an additional option "tick_to_timestamp_mode" to switch between "system time stamps" (default) and "tick time stamps". This option can be set in the launchfile:

<!-- 
Optional mode to convert lidar ticks to ros- resp. system-timestamps:
tick_to_timestamp_mode = 0 (default): convert lidar ticks in microseconds to system timestamp by software-pll
tick_to_timestamp_mode = 1 (optional tick-mode): convert lidar ticks in microseconds to timestamp by 1.0e-6 * (curtick - START_TRANSMISSION_TICKS) + START_TRANSMISSION_TS
-->
<param name="tick_to_timestamp_mode" type="int" value="1"/>

Please use the update in branch feature/lms5xx_ticks to calculate the number of ticks in microseconds between 2 timestamps TS_i and TS_j by ticks = 1.0e6 * (TS_i - TS_j)

[Kaju-Bubanja]

Thank you for the quick implementation :)