Inspect and compare recorded data

A recording looks mistimed. Is the display hiding a problem in the data? This example changes one display setting, then compares the results. It uses four synthetic frames, not a physical robot trial. No retraining is needed.

Before you start

Use a repository checkout with Python and uv from the quickstart. The offline command below writes local files; it does not upload data or contact a robot. Private review requires sign-in, a namespace, and a deployment with evidence storage configured.

The LeRobot adapter supports a bounded numeric subset of local v2.1 episodes: states, actions, frame indices, and timestamps. It does not import camera/video files or live streams. See the SDK guide for capture, supported inputs, and limits.

Generate two recordings

From the repository root, use a new output directory under an existing private parent:

PYTHONPATH=sdk/py uv run --locked --package tinyrobot \
  --extra recording --extra lerobot \
  python -m examples.reprocess_evidence ./timing-review

This writes the synthetic source, two evidence bundles, and two import requests. Protect the request files like the recordings: they contain the evidence data. Read the pinned example source.

The baseline displays frames at nominal 10 FPS. The candidate uses timestamp_policy="source" instead of "nominal_fps". Source bytes, frame IDs, state/action values, and missing samples stay the same. No policy, checkpoint, or controller changes.

Inspect the timing

Both recordings refer to the same four frames. Rounded timestamps in seconds:

| Frame | Source | Baseline: nominal FPS | Candidate: source time | | ----- | ------ | --------------------- | ---------------------- | | 0 | 0.00 | 0.00 | 0.00 | | 1 | 0.10 | 0.10 | 0.10 | | 2 | 0.35 | 0.20 | 0.35 | | 3 | 0.30 | 0.30 | 0.30 |

Frame 2 appears at 0.20 s in the baseline, but its source timestamp is 0.35 s. The source also goes backward at frame 3. The candidate preserves that defect rather than smoothing it away.

Compare privately

1. Open the evidence workspace, sign in, and select your namespace.
2. Import baseline.request.json, then candidate.request.json. The workspace assigns your selected namespace; the request's namespace ID is a placeholder.
3. Select the two records and describe the intended display-timing change.
4. Choose frame_index alignment, using each record's frame_index clock.
5. Save the comparison. Its URL can be reopened for review.

Both records remain imported evidence, not attested tinyrobot executions. Matching frame IDs are an assertion for this same-source example, not proof of sensor synchronization. Without compatible alignment, metric deltas are suppressed. Native Rerun recordings open independently; they are not synchronized playback.

What the result means

The maximum absolute display/source timestamp error falls from approximately 0.15 s to 0 s. Keep the source-time display for inspection and investigate the nonmonotonic source clock separately. Source hashes and missing samples are retained.

Zero display error does not repair the source clock or prove sensor synchronization, command execution, or robot/task success. Generic action values do not prove which commands reached a robot. New actions still require a simulator rollout or a controlled physical trial; replay is not a test of what different actions would do.

A useful decision note: Keep the source-time display. Investigate the source clock next. Task outcome remains unknown.