M7-T3 — Sensor Topics and Message Timing

Learning objectives

After this lesson, you should be able to:

• State what a header stamp must represent and estimate the error caused by a wrong stamp.
• Apply the QoS compatibility rules for sensor and map topics and predict whether a connection forms.
• Explain transform lookup, the buffer, and the causes of extrapolation errors.
• Measure rate, jitter and delay of a topic and recognise the signatures of timing faults.

The problem and the intuition

A photograph of a speeding car is useful only if you know when it was taken. If the label says the photo was taken a tenth of a second later than it really was, you will place the car a tenth of a second too far along. A lidar scan is the same: it is a photograph of the surroundings from the robot’s pose at the moment of the scan. SLAM asks TF “where was the robot when this scan was taken?”. With the right stamp the answer is right; with a stamp that is late by the transport latency, it is the pose where the robot was when the message arrived.

The second half of the story is delivery. ROS 2 decides which publishers and subscribers connect using quality-of-service (QoS) profiles. If they are incompatible, the connection is simply not made, and (in some versions) the only trace is a warning. A sensor driver that publishes with best effort and a node that subscribes with reliable never exchange a single message.

Two questions decide whether a message is used: does the data connect (topic, type, QoS), and does it make sense in time (stamp, frame, buffer)?

The rules: stamps, QoS, filters, lookups

Problem. Deliver sensor data to the SLAM node so that every message is received, stamped with the time of measurement, in a frame whose transform to the map is available at that time.

Assumptions. The system has one clock (wall time on hardware; /clock in simulation); drivers can report the measurement time; transforms are published at a steady rate; the buffer is long enough for the processing latency.

What the stamp must be

header.stamp is the time at which the data was measured. For a camera, the middle of the exposure; for a spinning lidar, the start (or in some drivers the end) of the sweep, with per-point times for deskewing (M5-T2). It is not the time the driver received the packet, nor the time the message was published. If a driver only knows the arrival time, the stamp is late by the unknown latency L, and the SLAM node projects the scan from the pose at t + L. The resulting error is:

Clock and simulated time

In simulation, Gazebo publishes /clock and every node must have use_sim_time: true. Mixing wall time and sim time gives stamps that differ by decades, or time that jumps when the simulation is paused or reset. On hardware, all computers must share a clock (chrony, NTP or PTP), otherwise stamps from different machines disagree by seconds.

Quality of service

Each endpoint declares reliability (RELIABLE or BEST_EFFORT), durability (VOLATILE or TRANSIENT_LOCAL), and history (KEEP_LAST with a depth). The rules for a publisher P and a subscriber S:

The conventions of REP 2003 (and the qos_profile_sensor_data preset) are: sensor streams (scans, images, IMU) use BEST_EFFORT, VOLATILE, a small depth, so that a slow consumer drops old data instead of building a queue; maps and static transforms use RELIABLE, TRANSIENT_LOCAL so that a node that starts late still receives the last map. The map topic is thus the classic late-joiner case: an RViz display or Nav2 costmap that subscribes with VOLATILE misses a map published once before it started.

Synchronising and looking up

• message_filters. ApproximateTime and ExactTime synchronisers match messages from different topics by stamp (for example camera and lidar, or two cameras). A slop that is too small drops pairs; too large mixes frames.
• tf2 buffer. Stores transforms for a duration (10 s by default; SLAM Toolbox lets you set tf_buffer_duration). lookupTransform(target, source, time) interpolates between samples that bracket time. If time is newer than the newest sample, it must extrapolate, which is refused.
• tf2 message filter. Holds a message until the transform for its stamp is available (up to a timeout), so that short transform latency does not drop scans; a long delay does.

stamp

header time: when the data was measured.

L

latency between measurement and the stamp (zero when the driver stamps correctly).

jitter

variation of the interval between consecutive messages around its mean.

extrapolation

looking up a transform at a time outside the buffered samples; refused by tf2.

Measuring timing

ros2 topic hz /scan        # rate, min/max/std of the interval
ros2 topic delay /scan     # now minus header.stamp (needs a header)
ros2 topic bw /scan        # bandwidth
ros2 topic info /scan -v   # QoS of every publisher and subscriber

Signatures of timing faults

A worked example: the size of a stamp delay, and the arithmetic of a jitter log

1. A stamp delay. A lidar driver stamps scans at arrival; the USB transport and buffering add L = 0.1 s. The robot moves at v = 0.5 m/s and rotates at ω = 1 rad/s (a brisk turn). The position error is v·L = 0.05 m. The bearing error is ω·L = 0.1 rad ≈ 5.7°. A wall point at range r = 5 m is placed r·ω·L = 0.5 m wrong. A scan matcher would see the walls smeared by tens of centimetres during every turn, and the map would show doubled walls.
2. Reading a jitter log. Six consecutive scan stamps (seconds): 10.000, 10.100, 10.201, 10.300, 10.400, 10.650. The intervals are 0.100, 0.101, 0.099, 0.100, 0.250. The median interval is 0.100 s (10 Hz). The last interval is 2.5 times the median: one or two scans were lost. If the next stamp were 10.640, an earlier time than the previous one, that would be non-monotonic and a driver or clock problem.
3. A lookup that fails. The odometry transform is published at 50 Hz; the newest sample is at t = 100.000 s. A scan stamped 100.012 s arrives. The next transform sample is due at 100.020 s, so the lookup fails with “extrapolation into the future”. The tf2 message filter holds the scan for up to the timeout (a couple of tenths of a second in SLAM Toolbox: transform_timeout) and succeeds once the 100.020 sample arrives; with a timeout of zero the scan is dropped. A scan stamped 100.5 s because the clock is half a second ahead would be dropped every time.
4. A QoS mismatch. The lidar driver publishes /scan with BEST_EFFORT (the sensor convention). A custom node subscribes with the default RELIABLE profile. ros2 topic list shows the topic, ros2 topic hz /scan from the command line (which uses a compatible profile) shows 10 Hz, and the custom node receives nothing. The log may print “New publisher discovered on topic ‘/scan’, offering incompatible QoS”. The fix is to subscribe with qos_profile_sensor_data.
5. A late joiner. The map server publishes /map once with TRANSIENT_LOCAL. RViz starts later with a VOLATILE subscription and shows nothing; changing its display to “Transient Local” durability, or republishing, fixes it. The same applies to /tf_static and Nav2’s static layer.

Engineering implications and limitations

Engineering implications

• Prefer driver hardware timestamps. If the sensor supports time synchronisation (PTP, PPS, an external trigger), use it; otherwise estimate and subtract a fixed latency, and verify by turning the robot in front of a wall.
• Synchronise clocks across machines with chrony or PTP; check offsets with chronyc tracking.
• Choose QoS deliberately. Sensors: best effort, small depth. Maps, static transforms and parameters: reliable, transient local. Mirror the publisher’s profile in your subscribers or use the presets.
• Give transforms headroom. Publish odometry TF at 30–50 Hz and set a transform timeout of a few hundred milliseconds in the SLAM node; do not make it so long that you hide real delays.
• Log timing. Record rate, jitter and delay for each sensor in every run; a change between runs is a symptom of a hardware or load problem.
• Test with a sharp turn. Timing errors show in rotation, as a smeared or doubled wall; a straight drive hides them.

Limits

These checks assume messages carry usable stamps; some drivers are wrong in ways that only physical tests reveal. DDS vendors differ in how QoS events are reported and in default behaviour under load, and the ROS 2 releases differ in tooling (for example, ros2 topic delay is available in current distributions but not in all older ones). Finally, a correct stamp does not remove motion distortion within a single scan, which needs deskewing (M5-T2).

Common misconceptions

Engineering takeaways

1. The header stamp must be the measurement time; a delay L produces errors of v·L in position and ω·L in bearing.
2. Simulation requires use_sim_time everywhere; hardware requires synchronised clocks.
3. A BEST_EFFORT publisher cannot serve a RELIABLE subscriber; a VOLATILE publisher cannot serve a TRANSIENT_LOCAL one.
4. tf2 lookups need the stamp inside the buffered range; future stamps cause extrapolation errors.
5. Measure rate, delay and jitter with ros2 topic hz and delay, and check QoS with ros2 topic info -v.

References and further reading

Primary papers and authoritative documentation.

• Open Robotics. ROS 2 documentation: About Quality of Service settings; About Time. docs.ros.org.
• REP 2003: Sensor Data and Map QoS Settings. ROS Enhancement Proposals (ros.org/reps/rep-2003.html).
• Foote, T. (2013). tf: The transform library. IEEE International Conference on Technologies for Practical Robot Applications (TePRA).
• Macenski, S., Foote, T., Gerkey, B., Lalancette, C. and Woodall, W. (2022). Robot Operating System 2: Design, architecture, and uses in the wild. Science Robotics 7(66).
• Furgale, P., Rehder, J. and Siegwart, R. (2013). Unified temporal and spatial calibration for multi-sensor systems. IEEE/RSJ IROS: on estimating sensor time offsets.

Knowledge check

Three conceptual questions. Write an answer, then reveal the explanation. Your answers stay in your browser.

What’s next

With wiring, frames and timing in order, the next lesson looks at the SLAM node itself: SLAM Toolbox, its modes, and the parameters that matter.

Related content

Nothing below is required to finish this lesson.

• Before
  M7-T2: TF Frames and Coordinate Consistency

  Apply REP 105 (map, odom, base_link) and know who publishes each transform.

• Lab
  M7-L3: Diagnose Sensor Timestamp Problems

  Find clock, stamp and QoS problems that make SLAM drop scans or jump.