M7-T10: Software timestamping

Learning objectives

After this lesson, you should be able to:

• List the sources of timestamp delay between the physical event and the message header.
• Choose the stamping point (device, driver, kernel, application) appropriate to the accuracy needed.
• Reduce arrival-time jitter with a fitted period model and quantify the remaining error.
• Estimate a constant sensor-to-host delay from data and verify it.

Conceptual explanation

Established Delay sources and smoothing methods are standard in sensor integration. The size of each delay is device-specific: the example numbers are illustrative and must be replaced by measurements of your sensors.

Where each delay comes from, with who can fix it:

Sensors differ in what they offer: some provide device timestamps on a device clock (many IMUs, lidars, some cameras), which are precise but on a different clock to be related to the host; others provide nothing and the driver stamps on arrival. A device clock can be related to the host clock by fitting: collect pairs (device time, host arrival time), whose lower envelope is the true offset plus the minimum delay.

Engineering intuition

Arrival times are the true schedule plus a one-sided, positive delay with a long tail: data cannot arrive earlier than physics allows, but it can arrive late for many reasons. Because the delay is one-sided, averaging arrival times biases the answer late, and the good information is in the early arrivals. If the sensor runs at a steady rate, fit a straight line to arrival times against sample index, then pull the line down so that it sits under (almost) all the arrivals: the line is your best estimate of when the samples actually left the sensor, plus the minimum delay.

The remaining unknown is the fixed delay (readout, transfer). It is the same for every sample, so it behaves like a constant time offset that can be calibrated against another sensor (for example camera-IMU offset estimation) or measured with a hardware reference such as an LED or a sync pulse.

Mathematical formulation

For samples at nominal period $T$ indexed $k$, with arrival times $a_{k}=t_{0}+k\,T_{\text{true}}+\delta +\eta _{k}$ (η_k ≥ 0 variable delay, $\delta$ fixed delay, $T_{\text{true}}$ the sensor’s actual period, which differs from the nominal one by clock drift), the estimate of the grid is the line that minimises the sum of the residuals subject to being below all points (a linear program, solved as a lower convex hull; the “convex hull” timestamp filter), or more robustly a low quantile regression:

Remaining error: the stamp then has the jitter of the sample at the lower envelope of $\eta$ (small), plus the unmodelled fixed offset $\delta$. Clock drift matters over long durations: a 50 ppm difference between device and host clocks accumulates 50 µs per second, 3 ms per minute, which is why the slope $b_{1}$ must be estimated continuously, not set to the nominal period.

$a_{k}$

arrival time of sample $k$ at the host.

$\eta _{k}$

non-negative variable delay.

$\delta$

fixed delay (readout, transfer, driver).

$b_{0}$, $b_{1}$

fitted intercept and period.

Architecture and data flow

Sensor (device clock, optional device timestamp) → bus → driver (kernel timestamp, if supported) → driver node (stamp assignment, smoothing) → message header stamp → consumers (estimator, VIO). The clock-offset estimator (device-to-host) runs inside the driver or as a node, and its parameters and residual statistics are logged. Downstream consumers should treat the stamp as the sensor time, and handle remaining offset through an estimated camera-IMU time offset parameter where available.

Real-world UAV applications

• Stamping USB cameras and lidars that offer no trigger.
• Relating an IMU’s device clock to the host clock.
• Reducing the jitter of arrival-stamped data before feeding VIO.
• Documenting timestamp accuracy in an interface control document.

Implementation example

This runs as shown. Synthetic 30 Hz data with a fixed delay of 22 ms, a long-tailed variable delay and a 40 ppm clock rate difference. A lower-envelope line fit (a linear program via a quantile-style iteration) recovers the sample schedule far better than the raw arrival times, leaving the fixed delay as a constant offset.

import numpy as np
rng = np.random.default_rng(10)
n, T_nom = 1800, 1 / 30.0; ppm = 40e-6
T_true = T_nom * (1 + ppm); k = np.arange(n)
t_true = 5.0 + k * T_true                                      # true sample times on the host clock
delta = 0.022; eta = rng.gamma(1.5, 0.004, n); eta[rng.random(n) < 0.02] += 0.05          # fixed delay, long-tailed variable delay, rare large stalls
a = t_true + delta + eta                                       # arrival times (the only thing the driver sees)

def lower_envelope_line(k, a):
    # exact solution of: maximise sum(line) (equivalently minimise sum(a - line)) subject to line <= a.
    # The optimum passes through two points of the lower convex hull; try every hull edge and keep the best.
    hull = []
    for p in zip(k, a):
        while len(hull) >= 2 and (hull[-1][0] - hull[-2][0]) * (p[1] - hull[-2][1]) - (hull[-1][1] - hull[-2][1]) * (p[0] - hull[-2][0]) <= 0: hull.pop()
        hull.append(p)
    best = None
    for (x0, y0), (x1, y1) in zip(hull[:-1], hull[1:]):
        b1 = (y1 - y0) / (x1 - x0); b0 = y0 - b1 * x0
        obj = n * b0 + b1 * k.sum()
        if best is None or obj > best[0]: best = (obj, b0, b1)
    return np.array([best[2], best[1]])                         # (slope, intercept) like np.polyfit
b = lower_envelope_line(k.astype(float), a)
t_hat = np.polyval(b, k)
err_raw = a - t_true; err_fit = t_hat - t_true
print(f"raw arrival stamp: mean error {err_raw.mean() * 1e3:5.1f} ms, std {err_raw.std() * 1e3:5.1f} ms; fitted: mean {err_fit.mean() * 1e3:5.1f} ms (about the fixed delay), std {err_fit.std() * 1e3:5.2f} ms")
print(f"estimated period {b[0]:.7f} s (true {T_true:.7f}, nominal {T_nom:.7f})")
assert err_fit.std() < 0.2 * err_raw.std() and abs(b[0] - T_true) < 2e-7 and abs(err_fit.mean() - delta) < 0.006

Common engineering mistakes

Failure modes

Debugging approach

1. Plot arrival time minus fitted line to see the delay distribution and its tail.
2. Compare with a hardware reference (LED, sync pulse, trigger) to measure the fixed delay.
3. Check kernel and device timestamp options on the driver.
4. Log the estimated period and offset so drift can be seen.

Practical exercises

1. Change the stall probability to 10 % and see how the fitted stamp error changes.
2. Estimate the fixed delay by comparing a software-stamped camera against a hardware-triggered one.
3. Compute the accumulated offset after 10 minutes for a 100 ppm clock difference.
4. List the timestamp source and expected accuracy for each sensor on your vehicle.

Interview questions

Write an answer in your own words, then reveal the model answer. Nothing is sent anywhere.

References and further reading

Primary papers, official documentation and standards. Each claim above that is specific to a tool or version points here.

• Linux kernel: Timestamping (SO_TIMESTAMPING)
• Furgale, P., Rehder, J. & Siegwart, R. (2013). Unified temporal and spatial calibration for multi-sensor systems. IROS
• ROS 2 design: Clock and Time

What’s next