Replay Timeline

Regression runs must present LiDAR packets, twist, and camera frames on one sensor timeline. Publishing each topic on its own clock changes ordering enough to hide or invent regressions relative to the car.

replay_node uses the native LiDAR packet stream as the master clock. Generic (passthrough) streams are opened and peeked first. On each packet:

1. Read the next packet and its timestamp
2. Publish every pending generic record with timestamp $\le$ that packet time
3. Sleep for the packet-to-packet delta divided by replay_rate
4. Apply packet-stream perturbations if configured
5. Feed the packet into the live driver (process_packet)
6. Publish /cones when the driver frame callback fires

At EOF: flush any partial driver frame, then publish remaining generic records.

Passthrough-only scenarios (no packet stream) are rejected: there is no master clock and no driver callback to drive the pipeline.

replay_rate

rate: 1.0 preserves recorded time. Higher values shorten sleeps and accelerate wall-clock replay. ROS nodes still see stamped messages; the reference pins replay rate because node behavior (deques, timeouts, history) can change with wall time.

Ordering

• Generic records at or before the current packet time publish before that packet is processed.
• The first timestamp across packet + generic streams anchors recording-relative time for time_blackout perturbations.
• await_subscribers avoids dropping the first messages during DDS discovery.

Perturbations

Hook	When
message_drop / time_blackout on generic streams	Before generic publish
Same on packets	Before driver processing
point_dropout	On the completed frame just before /cones publish

Perturbations are part of the test definition pinned into references when used.

Harness overview: regression harness. Implementation: replay_node.cpp.