Repository navigation
[INTERFACE] C9 LeRobotDataset capture metadata contract acceptance #18
Description
Plan item
Workstream C9 — Whole-body capture / LeRobotDataset contract, deliverable 23 in the supplied team roster (not GitHub issue #23). Implementation proposal: #16
Contract or interface
openamrobot-interfaces/schemas/json/c9-lerobot-dataset.schema.json, documented in docs/c9-lerobot-dataset-contract.md.
Status: Accepted by the software lead for v1 contract shape; implementation PR #16 merged on 2 Oct 2026. This request records the review/acceptance gate after the initial draft was prepared; it does not claim the request preceded that implementation.
Change class
Other: new additive, version 1 dataset metadata sidecar contract. No existing ROS field, native LeRobot payload, writer or runtime behavior is changed. Review-driven revisions remain part of the unaccepted proposal.
Problem and proposed change
Native LeRobot sampling-grid timestamps do not establish physical acquisition synchronization or calibration/configuration provenance. C9 proposes an episode sidecar with native dataset/frame/task bindings, four camera streams, state/action descriptors, monotonic capture timing, per-stream host/device clock mappings, calibration/configuration identities, outcomes and intervention/recovery/safety event records.
Native LeRobot remains the primary format. Contract acceptance status belongs in documentation and this request, not in each recording. Inspected baseline: LeRobot v0.6.1; no validated project release pin or numeric synchronization threshold is claimed.
Producers and consumers
Producers: planned capture/dataset recorder and calibration/recording work package. Recorder implementation ownership/location remains an open architectural decision.
Consumers: C10 Dataset Quality Gate; capture/replay/evaluation work package; native LeRobot dataset consumers use unchanged primary payloads. Contract documentation and schema fixtures are included. No UI, telemetry-control or safety behavior is introduced.
Compatibility and migration
The sidecar is additive. Proposal revisions are not a migration of an accepted/released contract; any actual draft consumer must regenerate affected sidecars (notably removal of recording-level contract_status). Once accepted, incompatible schema changes require versioning and consumer review. Native media/state/action/task data is not rewritten. Rollback removes the optional proposed sidecar; runtime consumers must not silently treat an unaccepted proposal as accepted.
Validation and evidence
PR #16 contains exact base/head SHAs, commands and evidence. Original commit 12a6d15 passed hosted ROS 2 Jazzy and repository-quality checks. Review follow-up adds deliberately invalid timing fixtures and aligns schema/documentation semantics; updated checks will be recorded on the PR.
C9 checks structural conformance. C10 must validate temporal consistency, actual FPS/skew/drops/staleness, feature equality, ranges, artifact identities and completeness. Synthetic fixtures are not physical validation. Native LeRobot loading/writing with this sidecar is not tested.
Safety and operational boundary
Metadata only: no motion, power, actuator, safety I/O or readiness decisions. Outcomes/safety events are recorded observations, not control authority or safety acceptance.
Acceptance decisions
Software lead: accepted the v1 shared-contract shape on 30 September 2026. This is semantic contract acceptance only; PR #16 merged on 2 Oct 2026. Open items: recorder ownership and the validated LeRobot release pin.
Calibration/recording and capture/dataset owners: confirm physical camera/stereo layout, calibration residual conventions, full state/action profiles and timing evidence requirements.
Release owner: validate and pin the LeRobot release separately.
Interface review checks
- Known/planned producers and consumers are identified; unresolved runtime ownership is explicit.
- Compatibility impact is classified; accepted-contract changes will require appropriate versioning.
- Recorded telemetry/events are not authoritative safety evidence.
Generated by Claude Code
Activity
panthera-momagdii commentedon Sep 30, 2026
Software-lead decision: accept the proposed C9 v1 contract shape represented by PR #16, with the boundaries documented there. This accepts the additive episode-sidecar semantics only. It does not validate physical synchronization, calibration, recorder implementation, a LeRobot release pin, or C10 dataset-quality behavior. PR #16 must still wait for current-head hosted ROS 2 Jazzy and repository-quality checks to run and pass before merge.
panthera-momagdii commentedon Oct 1, 2026
Calibration/frame-table integration note from Vineeth's 1 Oct draft: dataset feature keys must use the accepted C9 v1 names exactly:
observation.images.base,observation.images.head,observation.images.camera_wrist_left, andobservation.images.camera_wrist_right. ROS driver topics/frame names remain a separate, implementation-specific layer and should not be treated as C9 feature-key names. Physical calibration residuals, source profiles and timing thresholds remain evidence-driven and may stay pending until measured.panthera-momagdii commentedon Oct 13, 2026
Cross-workstream C9/C10 integration check (13 Oct): I reviewed Marcus's baseline repository (
4u-79/openamrobot-c-baseline,meta/info.json, validator and README) against the merged C9 v1 contract in this repository.There are three items to reconcile before a real-episode gate, training or an additional schema freeze:
observation.images.headandobservation.images.basealongside the two wrist cameras; the baseline currently requiresobservation.images.camera_sceneandobservation.images.camera_base_nav. Please document an explicit approved profile/mapping or align the keys, with fixtures. ROS topic names are a separate layer.lerobot==0.4.1and a 30 ms threshold, while the accepted C9 contract describes an inspected v0.6.1 snapshot and explicitly leaves the validated release pin and numeric sync tolerance unapproved. Confirm these through the release/recording owners, not as accepted C9 facts.@4u-79 and the C9 owner, please compare the actual dataset-sidecar bindings and provide a short compatibility matrix plus one real episode C10 report. Existing fixture tests remain valuable but are not end-to-end recording/training evidence. This does not reopen the accepted additive C9 schema shape or authorize changing a frozen profile without approval.
panthera-momagdii commentedon Oct 24, 2026
Follow-up to my 13 Oct review of Marcus's baseline, at
4u-79/openamrobot-c-baselinemain1390ae798f300754303136fae9b3557db025ed0d(head rechecked).The camera keys now match C9, the fixed-mast 19-channel profile is separated from the lift proposal, and release/timing approval remains explicit.
python scripts/validate_dataset_contract.py --info-json meta/info.jsonpasses 26/26 metadata checks.Four current findings still block my technical acceptance recommendation:
source_profile='ROBOT'called the synthetic generator with that same ROBOT label. This was a dispatch probe with the generator mocked. Unsupported recording input should fail explicitly; fixtures must have synthetic provenance.c10_preflight_qa_gate='BLOCKED'producedBLOCKED | PASSand the acceptance statement. Derive status from validated evidence and keep blocked evidence blocked.The committed Markdown/JSON also disagree on checkpoint SHA-256 (
26703aa8...versus068fd441...), and evaluation records Torch 2.14.1+cpu against the 2.5.1 requirements pin. Regenerate one consistent evidence package.Next: a focused correction PR with regressions for the provenance/reporting failures, actual C9 sidecar bindings and one real-episode C10 report. An organisation move can be considered after that review; this comment does not approve a transfer or change the accepted C9 contract.
Preconditions: comment in
openAMRobot/openamrobot-interfaces#18, the existing C9/C10 review thread; baseline main at the SHA above; expected outcome is technical follow-up only. ChatGPT inspected exact-SHA source and ran the metadata check and focused probes. Full training/pytest, binary checkpoint integrity, native LeRobot loading, real recording, simulation and hardware were not verified. The local runtime lacks Torch/PyArrow/pytest; no hosted baseline Actions runs were found.