FixTheRobot Explore Robotics / Systems Engineering / Design & Selection / Module 07

Design & Selection · Module 07

Hardware vs software time synchronization

A timestamp should say when the sensor measured, not when the computer heard about it. Hardware support gets you closer; arrival stamps add the whole transport jitter.

  • Intermediate
  • Module 07: Sensor Time Synchronization & Latency Engineering
  • Written for ROS 2 Jazzy where ROS 2 is used
  • Sources checked 2026-11-06

Assumptions: Numbers in the examples are illustrative and the code is executed by the site’s tests. Facts taken from a cited source are marked; other statements are general engineering knowledge and must be confirmed on the datasheet of the part you use.

1. Engineering problem

Fusion algorithms assume the timestamp is the time of measurement. If a driver stamps at arrival, the stamp includes transport, driver and scheduling delays that vary from message to message. That variation becomes noise in the estimator and the delay becomes a bias.

2. When is this needed?

  • Choosing sensors for LiDAR-inertial or visual-inertial fusion.
  • Deciding whether a PPS or PTP infrastructure is worth the effort.
  • Diagnosing jitter in message periods.

3. Selection and design decisions

Sourced: PPS is an electrical signal with a sharply defined edge that repeats once per second; PTP (IEEE 1588) is a protocol for synchronising clocks across a network with higher precision than earlier network protocols (Wikipedia, read 2026-11-06). chrony can use a PPS device as a reference clock through its PPS refclock driver; linuxptp’s ptp4l implements PTP.

ApproachWhat it givesLimits
Stamp at arrival (software)Zero setupIncludes transport and scheduling jitter; delay is a bias
Device capture time converted with a measured offsetRemoves jitter if the device clock is stableOffset and drift must be estimated and tracked
PPS-disciplined host clock plus device timestampsCommon time base from GNSS to hostNeeds a PPS output and wiring
PTP with hardware timestamping on network sensorsNetwork-wide common clockNeeds sensor and switch support, tuning
Hardware trigger (a shared signal fires all sensors)Samples at the same instantNeeds sensors with trigger inputs

4. Advantages and disadvantages

  • Simplicity vs accuracy: arrival stamps are free and good enough for slow robots; fast motion or fusion needs capture times.
  • Trigger vs timestamp: a trigger aligns the samples; timestamps let the estimator compensate any offset.
  • Infrastructure (GNSS PPS, PTP switches) costs setup and maintenance.

5. Requirements and constraints

  • The requirement stated as a maximum timing error (for example in ms) is derived from speed and spatial tolerance.
  • The driver publishes the capture time where the sensor supports it.
  • Time sources are monitored for loss.

6. Architecture

sensor clock ──(PPS | PTP | trigger)── host clock ──▶ driver stamps with capture time ──▶ ROS 2 header.stamp

7. Implementation

  1. Derive the allowed timing error: speed × error should be well below the spatial tolerance.
  2. Record device capture time and host arrival time for each sensor (below).
  3. Measure latency mean, jitter and maximum.
  4. Choose the cheapest approach that meets the requirement.
  5. Monitor the offset in operation.
import statistics as st
hw = [10.000, 10.100, 10.200, 10.300, 10.400, 10.500]          # sensor (hardware) capture times, s
arrival = [10.012, 10.131, 10.208, 10.305, 10.441, 10.514]      # host time when the driver received each message, s
lat = [a - h for a, h in zip(arrival, hw)]
print("latency ms: mean %.1f, std %.1f, max %.1f" % (st.mean(lat) * 1e3, st.stdev(lat) * 1e3, max(lat) * 1e3))
print("period error if stamped at arrival (ms):", [round((b - a - 0.1) * 1e3, 1) for a, b in zip(arrival, arrival[1:])])
print("period error if stamped at capture (ms):", [round((b - a - 0.1) * 1e3, 1) + 0.0 for a, b in zip(hw, hw[1:])])

Printed (checked by the site’s tests):

latency ms: mean 18.5, std 14.3, max 41.0
period error if stamped at arrival (ms): [19.0, -23.0, -3.0, 36.0, -27.0]
period error if stamped at capture (ms): [0.0, 0.0, 0.0, 0.0, 0.0]

Reading it: with arrival stamps the 10 Hz stream shows period errors of up to ±36 ms, and the latency is 18.5 ms on average and 41 ms at worst. Using the capture time makes the period error zero, but only if the sensor clock and the host clock agree (which is what PPS or PTP provide). A robot moving at 1 m/s moves 18.5 mm in the mean latency. The timestamps are illustrative.

8. Real examples

  • LiDAR-inertial odometry: LiDAR and IMU stamped from one PPS-disciplined clock.

9. Failure scenarios

  • Stamping at arrival and treating the stamp as a measurement time.
  • A PPS signal connected but never used by the host clock.
  • A trigger signal that drifts when the sensor boots.

10. Troubleshooting

  1. Plot arrival minus capture time over a run: spikes show scheduling or transport problems.
  2. Check that the host clock is actually disciplined.
  3. Compare stamps from two sensors observing the same event.

11. Validation

  • The example prints the lines shown (executed by the site tests).
  • The measured timing error between sensors is below the derived requirement over the whole mission.

12. Engineering checklist

13. Further references

Related on FixTheRobot