Skip to content

Timestamp Shift Sweep Protocol

Last updated: 2026-05-09

Purpose

This protocol measures how much signed timestamp error the perception-SLAM stack can tolerate before localization, fusion, occupancy, map-change detection, or safety monitoring becomes unsafe. It converts "time sync should be good" into response curves, alert thresholds, and release margins. The expected outcome is a sweep report showing where the stack degrades, where monitors trip, and where release must block because a wrong output remains nominal.

This protocol consumes the timing fault evidence from time-sync fault injection, supports sensor dropout, latency, and jitter stress, replay time semantics validation, and SLAM integrity under timing errors.

Sweep Scope

TargetShift applied toSafety question
LiDAR to IMULiDAR point cloud header.stamp, per-packet stamp if available, or IMU streamDoes motion compensation or scan matching use stale inertial motion?
Camera to LiDARImage header.stamp or point cloud stampDoes cross-modal fusion create misplaced detections or free space?
Radar to ego poseRadar track/return stampAre dynamic obstacles projected to the wrong pose?
GNSS to IMUGNSS fix/PVT stamp or IMU stampDoes global localization accept inconsistent absolute position?
Wheel odometry to IMUOdometry or encoder stampDoes preintegration or dead reckoning bias pose during wheel slip or turns?
TF transformsTransform timestamp for map, odom, base_link, and sensor framesAre transforms extrapolated incorrectly or accepted outside cache policy?
Map lookup timeMap tile/version selection timestamp or route overlay timeCan runtime use stale or future map state as current?

Required Setup

ItemRequirement
Clean reference logsNominal Rosbag2/MCAP runs with raw sensors, TF, localization, objects, occupancy, maps, and diagnostics
Ground truthPose and object truth for measuring shift-induced error by route, speed, turn, and ODD slice
Timestamp editorDeterministic tool that shifts header.stamp, TF stamp, or sensor-native timestamp without changing payload bytes unless declared
Replay harnessFixed ROS time behavior, QoS settings, message order, and deterministic random seeds
Baseline runClean replay of unmodified log through the same candidate build and map package
Monitor setTime health, topic state, TF/message-filter drops, localization integrity, stale-data, and safety action monitors
Sweep manifestShift axis, shift values, topics, build, map, calibration, dataset slice, and expected monitor response

Sweep Design

Run signed sweeps around zero and include both step and ramp variants.

Sweep typeValuesUse
Fine near zero0, +/-1 ms, +/-2 ms, +/-5 msDetect tight fusion and interpolation assumptions
Operational band+/-10 ms, +/-20 ms, +/-50 msCover credible PTP, host, queue, and replay faults
Release boundaryValues around approved latency/fusion limitEstablish exact trip point and margin
Gross fault+/-100 ms and one full sensor frame period where safe in replayVerify fail-closed behavior
Ramp1, 5, 10 ms/min until alert/block limitDetect slow drift and monitor trend response
Jitter overlayGaussian and bounded uniform jitter around selected offsetsSeparate mean offset sensitivity from jitter sensitivity

Do not mix multiple shifted modalities in the first pass. Establish single-axis sensitivity first, then run pairwise combinations for the highest-risk interactions.

Procedure

  1. Freeze candidate build, map package, calibration, replay config, and sweep manifest.
  2. Run the baseline replay and store output hashes, metrics, and monitor traces.
  3. For each target stream, apply one signed timestamp shift while preserving message order unless the test explicitly targets reordering.
  4. Replay each shifted log at 1.0x with the same ROS time semantics as the baseline.
  5. Record synchronized metrics, monitor events, TF/message-filter drops, and safety actions.
  6. Repeat the same shift on at least one high-risk slice: turn, acceleration/braking, aircraft stand, person/GSE crossing, wet surface, or weak-feature zone.
  7. Fit response curves for pose error, residual, uncertainty, detection error, and monitor time-to-alert versus shift.
  8. Identify the first shift that violates alert limits, the first shift that triggers each monitor, and any silent-failure region.
  9. Convert the result into release thresholds and fleet alert bands.

Metrics

MetricDefinitionInterpretation
Baseline deltaCandidate metric under shift minus clean replay metricRemoves scenario difficulty from timing sensitivity
Shift-to-alertSmallest signed shift that triggers a timing, fusion, or integrity alertMust be below unsafe shift threshold
Shift-to-unsafeSmallest signed shift causing pose, object, occupancy, or map error beyond alert limitDefines timing hazard boundary
Silent-failure intervalShift range where output is wrong but confidence/diagnostics remain nominalRelease-blocking for safety-critical outputs
Pose error curveATE, RPE, yaw error, drift rate, relocalization failure by shiftShows localization timing margin
Residual curveScan-match residual, IMU/GNSS innovation, reprojection error, factor residual by shiftShould rise before unsafe pose error
Covariance/integrity curvePose covariance, protection level, NEES/NIS, integrity alert state by shiftDetects overconfidence under timing faults
Fusion drop curveMessage-filter misses, TF extrapolation failures, queue overflows by shiftShows whether bad timing fails closed
Occupancy/free-space errorFalse free space, unknown-space growth, stale obstacle use by shiftCritical safety metric near aircraft, people, FOD, and geofences
Recovery hysteresisDifference between alert-on and alert-clear shift thresholdsPrevents alert flapping in operations

Pass and Block Gates

GatePass conditionBlock condition
SW0 reproducibilityBaseline and repeated shifted runs are deterministic within approved toleranceReplay nondeterminism prevents threshold claims
SW1 monotonic riskError/residual/uncertainty generally worsens with larger absolute shift or documented non-monotonic behavior is boundedUnexplained safe/unsafe oscillation near release limit
SW2 monitor-before-hazardTiming, residual, uncertainty, or integrity monitor trips before the shift-to-unsafe boundaryUnsafe output occurs before any monitor action
SW3 no silent wrong poseWrong-pose cases exceed covariance/protection level or trigger degraded modePose is wrong while reported as nominal
SW4 no stale safety inputStale/future detections, occupancy, or transforms are dropped or marked uncertainStale obstacle/free-space output is consumed as current
SW5 release marginApproved operational timing envelope is below shift-to-unsafe by the safety margin set in the release planNormal timing variation overlaps unsafe region
SW6 slice coverageHigh-risk ODD slices pass individuallyAggregate pass hides timing sensitivity in one slice
SW7 evidenceSweep manifest, shifted-log hashes, metrics, plots, and failure packets are completeMissing evidence for threshold-setting run

Threshold Pattern

Exact values are program-specific. A defensible release pattern is:

ThresholdRequired relationship
Green bandNormal fleet inter-sensor skew and stamp age remain well below monitor alert threshold
Yellow bandAlert threshold is below the first measured safety-relevant degradation point
Red bandControlled-stop or hard-degrade threshold is below the first silent wrong-pose or false-free-space point
Release marginWorst credible PTP/PHC/sensor jitter plus replay uncertainty is lower than yellow threshold by approved margin
Map-building marginMap publication uses stricter limits than runtime because timing faults can corrupt future maps

Operational Response

Sweep resultFleet action
Wide margin, no silent failuresPromote thresholds to fleet dashboard and release gate
Narrow margin on one sensor pairTighten sensor timing monitor, reduce speed/ODD for affected slice, or redesign fusion window
Silent failure for a modalityBlock release until monitor, covariance model, or fusion fail-closed behavior is fixed
Replay-only failureFix replay semantics before using the dataset for release claims
Map-building sensitivityQuarantine map builds from sessions outside timing health envelope
High variance across routesRequire route-specific or ODD-specific timing thresholds

Evidence Artifacts

ArtifactContents
Sweep manifestTopics, shift values, dataset slices, build/map/calibration IDs
Shifted log indexHashes of clean and shifted MCAP/rosbag artifacts plus timestamp edit description
Response plotsError, residual, uncertainty, drops, alerts, and safety action versus shift
Threshold recommendationGreen/yellow/red bands, release margin, and dashboard alert values
Failure packetsMinimal log slice, shift value, expected/actual monitor behavior, defect ID
Release dispositionPass, block, inconclusive, or pass with ODD/map-building restriction

Sources

Public research notes collected from public sources.