Skip to content

Replay Time Semantics and TF Message Filter Validation

Last updated: 2026-05-09

Purpose

This protocol validates that offline replay, regression tests, and incident reconstruction preserve the same timing semantics that the runtime stack depends on. It focuses on ROS 2 time, /clock, rosbag2/MCAP record and playback metadata, TF cache behavior, tf2_ros::MessageFilter, and message_filters synchronizers. A replay result is not valid release evidence unless message stamps, publish/receive ordering, transform availability, and simulated time behavior are understood and tested.

This protocol supports timestamp shift sweep, sensor dropout, latency, and jitter stress, SLAM integrity under timing errors, and map-localization release gates for timing health.

Time Domains

DomainExamplesValidation concern
Sensor source timeLiDAR packet/frame stamp, camera exposure time, GNSS/IMU timePhysical measurement time used by fusion
ROS message stampstd_msgs/Header.stamp in sensor and derived messagesTimestamp used by TF, filters, localization, and replay metrics
Record timeTime recorder received/wrote a messageMay differ from measurement time under latency or burst queues
Publish timeTime message is republished during replayDetermines consumer callback timing
ROS simulated time/clock time when use_sim_time is enabledDrives timers, TF buffer, and time-aware nodes
Wall/system timeHost system clock when use_sim_time is disabledCan mask replay defects if mixed with ROS time
MCAP log/publish timeMCAP message timing fields and profile conventionsRequired for cross-tool replay and indexing

Required Setup

ItemRequirement
Replay manifestBag/MCAP ID, storage format, compression, metadata, topic list, QoS overrides, playback options
Candidate stackSame build, map, calibration, parameters, and topic remappings used in timing validation
Time policyExplicit use_sim_time value per node and expected /clock publisher
TF policyTF buffer cache duration, /tf_static durability, frame tree, transform publication rates
Filter policyExact sync type, queue size, slop/window, target frames, and drop callbacks for each filter
Reference outputsBaseline deterministic output hashes or accepted metric tolerance
InstrumentationCallback timestamps, filter matches/drops, TF lookup failures, message age, queue depth, and /clock trace

Validation Cases

IDCaseExpected behavior
RT-01Play with --clock and all nodes using simulated timeTimers, TF, and filters use replay time; no wall-time leakage
RT-02Play without /clock when nodes require simulated timeTest fails clearly; no release evidence accepted
RT-03Record with simulated time before valid /clock startsRecorder avoids zero-time ambiguity or run is rejected
RT-04Pause/resume and rate changes during replayNodes do not treat pause as sensor dropout unless policy says so
RT-05Burst playback after pauseQueues and stale-data filters prevent false current outputs
RT-06Reverse or backward /clock jump in replayTime-aware components clear, reset, or fail closed deterministically
RT-07Message order by receive/log time versus source stampMetrics identify ordering mode; synchronizers behave as expected
RT-08Missing or delayed /tf_staticConsumers block or fail closed, not infer wrong static transform
RT-09TF future/past extrapolationFailures are diagnosable by frame pair, requested time, and cache bounds
RT-10message_filters exact/approx sync window boundaryMatch/drop behavior is deterministic and recorded
RT-11tf2_ros::MessageFilter target-frame availabilityMessages are released only when required transform is available
RT-12Multi-bag or split-bag replayTopic continuity, /clock, and TF caches are correct across file boundaries
RT-13MCAP conversion from rosbag2 or other toolsHeader stamps, schema, channel metadata, and timing fields remain consistent

Procedure

  1. Freeze replay manifest, candidate build, map, calibration, parameters, and expected time policy.
  2. Run a baseline replay with clean logs and record output hashes, metric summaries, and monitor traces.
  3. Run each validation case and capture /clock, TF, filter, queue, and callback instrumentation.
  4. For filters, log accepted pairs/sets, dropped messages, source stamps, target frame, and reason for drop.
  5. For TF, log lookup time, source/target frame, latest/oldest available transform, and extrapolation direction.
  6. Compare outputs across repeated runs to confirm deterministic behavior or document approved nondeterminism.
  7. Tag replay artifacts with whether they are valid for release evidence, debugging only, or rejected.

Metrics

MetricDefinitionUse
Replay determinismOutput hash or metric delta across repeated identical replaysRequired for regression and release claims
Clock consistencyDifference between ROS time, message stamps, record time, and wall timeDetects mixed time domains
Clock jump countForward/backward jumps, zero-time intervals, and discontinuitiesIdentifies invalid or special-case replay
TF lookup failure ratePast/future extrapolation, no connection, no static transform, cache missReveals frame/time contract problems
Message filter match rateMatched messages divided by candidates for exact/approx syncMeasures usable fusion input
Filter drop reason rateQueue overflow, out of slop, no transform, out-of-cache, stale/futureMakes failure modes actionable
Callback ageProcessing time minus message source stampDetects stale outputs and burst replay artifacts
Publication burst factorReplay publish interval versus recorded inter-arrival intervalExplains queue and latency artifacts
/tf_static readiness timeTime until all required static transforms are availablePrevents first-message failures from hiding bugs
Evidence validity flagRelease evidence, debugging only, or rejectedPrevents invalid replay from entering release packet

Pass and Block Gates

GatePass conditionBlock condition
RT0 time policyEvery replay test declares use_sim_time, /clock, rate, pause, and ordering modeUnknown or mixed wall/ROS time policy
RT1 deterministic replayRepeated replay produces identical outputs or bounded documented toleranceNondeterminism affects release metrics
RT2 no wall-time leakageTime-aware nodes use ROS time under replay when requiredNode uses wall time and changes behavior between replay/runtime
RT3 TF fail-closedMissing/future/past transforms create drops or diagnostics, not wrong-frame outputConsumer extrapolates or substitutes invalid transform silently
RT4 filter observabilityMatch/drop behavior and reasons are logged for all safety-relevant filtersFusion input loss cannot be explained
RT5 bag semanticsHeader stamps, record/log time, publish time, and MCAP/rosbag metadata are preserved through conversionConversion changes time semantics without manifest update
RT6 static transformsRequired static transforms are durable and available before dependent outputs are trustedStartup messages processed with missing static transform
RT7 invalid runs excludedReplays with zero time, clock jumps outside test scope, or missing metadata are marked invalidInvalid replay included in release evidence

Operational Response

FindingResponse
Replay-only timing defectFix replay harness before accepting metrics; do not tune stack to invalid replay artifacts
Runtime-equivalent TF/filter defectCreate stack defect and add to timing fault regression suite
Missing timing metadata in bag/MCAPQuarantine artifact from release evidence; repair only if original raw timing source is available
/clock or wall-time mismatchEnforce launch-time checks and CI replay smoke tests
High filter drop rate under valid replayInvestigate timestamp sync, QoS, queue size, and sensor health thresholds
MCAP conversion inconsistencyPin converter version and add conversion round-trip check to data pipeline

Evidence Artifacts

ArtifactContents
Replay manifestBag/MCAP IDs, playback options, time policy, QoS, map/calibration/build IDs
Time trace/clock, wall time, message stamps, record/log time, publish intervals
TF reportFrame tree, static transform readiness, lookup failures, cache bounds
Filter reportSync matches, drops, queue age, slop/window, target frame, drop reasons
Determinism reportRepeated-run hashes, metric deltas, approved tolerances
Evidence validity registerWhich replay artifacts are valid for release, debugging only, or rejected

Sources

Public research notes collected from public sources.