Egocentric stereo human-demonstration data does not arrive as “just video.” It arrives as a bundle: dual-eye frames, device-side timestamps, IMU, head pose, calibration products, and a schema that training stacks can load without a custom archaeology project. Two packaging worlds show up constantly in robot-learning procurement: LeRobot v3 (dataset-centric, training-loader friendly) and MCAP (recording-centric, robotics logging friendly). Choosing poorly creates silent cost—adapter weeks, broken timebases, or calibration stranded outside the files your trainer actually reads.
This essay is a practical buyer-facing comparison: when LeRobot v3 is the right delivery contract, when MCAP (or an MCAP-first capture path) still matters, and how to write an SOW that does not confuse a log format with a training dataset. All concrete envelope numbers below come from a public sample you can inspect: 2 episodes, 4,914 frames, 163.47 s (EP001 wiring 121.57 s; EP002 restocking 41.90 s), dual-eye 1920×1200 at 30 fps, hardware-synced stereo, timestamps recorded (not computed), published as LeRobot v3 under CC BY-NC 4.0, with tooling on GitHub and commercial context at 10K HoursData.
What each format is optimizing for
LeRobot v3 — training artifact
LeRobot v3 is designed so research and applied teams can call LeRobotDataset() and get episodes, frames, and aligned fields into imitation / VLA pipelines with minimal glue. In buyer language, it is the format you want when the primary consumer is a policy training cluster, an internal eval harness, or a sharing check such as Physical-Intelligence/pi-data-sharing.
For egocentric stereo demos, LeRobot v3 is where you expect to find:
- Episode structure (e.g., EP001 / EP002) with frame-indexed fields
- Visual streams consistent with the capture envelope (1920×1200/eye, 30 fps, hardware-synced stereo)
- Time fields that can carry device-side stamps with 100% coverage and no interpolation
- IMU / pose channels that training code can join without inventing a second clock
- A path to ship or reference calibration products (K, KB4, R1/R2, P1/P2, Q, IMU↔cam, version) next to the dataset card or manifest
The public sample is deliberately delivered this way so buyers can treat “loads in LeRobot v3” as a binary acceptance gate, not a vibe.
MCAP — robotics recording / interchange
MCAP is a recording container widely used in robotics logging: multi-topic, multi-rate, append-friendly, convenient for robot runtime, bag-like workflows, and tooling that already speaks ROS-adjacent ecosystems. In buyer language, MCAP shines when the primary consumer is a robotics platform team, a capture truck pipeline, or a lab that already standardizes on MCAP for every sensor bus.
MCAP is excellent at preserving heterogeneous streams. It is not, by itself, a guarantee that:
- Your imitation trainer knows how to load the bundle
- Stereo pairs are hardware-synced rather than merely co-logged
- Timestamps are device-recorded rather than later filled from nominal FPS
- Calibration matrices and a calibration version are attached in a training-consumable place
- pi-data-sharing-style dataset checks will pass without an export step
MCAP answers “can we store and replay the bus?” LeRobot v3 answers “can the learning stack consume the demo set?”
Decision table for procurement
| Question | Lean LeRobot v3 | Lean MCAP (or MCAP-first) |
|---|---|---|
| Primary consumer is policy / VLA training? | Yes | Secondary |
Need LeRobotDataset() as SOW gate? |
Yes | No (unless you export) |
| Need pi-data-sharing alignment? | Yes | After conversion |
| Primary consumer is robot runtime logging / multi-topic bags? | Secondary | Yes |
| Capture team already standardizes on MCAP tooling? | Export path required | Native fit |
| Buyer wants one inspectable public training sample? | Matches public sample packaging | Convert for parity |
Most egocentric human-demonstration purchase orders for foundation-model and imitation teams should specify LeRobot v3 delivery even if capture internally uses another container. Capture format ≠ delivery format.
Why LeRobot v3 is the right default for demo buying
1. Acceptance becomes a load test
“Compatible with LeRobot” is ambiguous. LeRobot v3 + successful LeRobotDataset() load is not. Pair that with a pass against Physical-Intelligence/pi-data-sharing and you have a contract engineering can run on day one. The public sample exists so that gate is not theoretical: 2 episodes / 4,914 frames / 163.47 s should load under the same expectations you write into production lots.
2. Timebase integrity is easier to enforce in the training artifact
The core claim for this category is timestamps recorded, not computed. On the public sample that means:
- Frame intervals with median = p99 = max ≈ 33.28 ms and 0 frames out of spec
- 100% device-side timestamps, no interpolation
- IMU at ~300.48 Hz, 10 samples per exposure, 18,050 continuous samples, 0 gaps >10 ms
- Per-frame 6-DoF head pose on the same timeline
Those checks belong on the artifact your trainers actually open. If you accept only MCAP and hope someone “will export later,” the timebase QA often happens too late—or never.
3. Stereo and calibration travel with the learning package
Hardware-synced stereo at 1920×1200/eye is incomplete without shipped calibration: K, KB4, R1/R2, P1/P2, Q, IMU↔cam, and a version. Residual reference figures from the sample—baseline ~60.7 mm, Sampson 0.166 px, reprojection 0.800 px, 15,811 inliers—belong in the same acceptance story. LeRobot-oriented delivery forces the question: where does the learner find these products? MCAP can store them as topics or attachments, but buyers still need an explicit mapping into the training layout.
4. Sharing and eval forks get cheaper
Internal forks, partner evals, and non-commercial research use benefit from a documented sample license (CC BY-NC 4.0 on the public set) and a schema that does not require every recipient to write an MCAP decoder. Commercial production terms remain SOW-specific; the point is schema friction, not license dogma.
When MCAP still belongs in the conversation
Choose or retain MCAP when:
- Capture ops already emit MCAP from the head-worn / robot-adjacent logging stack and changing that pipeline would create more risk than an export stage.
- Robotics platform teams need multi-topic replay beside the learning set (debug, latency analysis, non-learning consumers).
- You want a raw recording archive plus a curated LeRobot v3 release—two artifacts, two purposes.
In those cases, write the SOW as: capture may use MCAP; accepted delivery for learning is LeRobot v3; conversion must preserve device-side timestamps (no FPS backfill), hardware sync semantics, IMU continuity, and calibration version linkage. Conversion that recomputes time from nominal 30 fps is a regression, not a format upgrade.
Anti-patterns to reject in RFPs
- “Deliver MCAP or LeRobot, either is fine” with no primary consumer named.
- “LeRobot-compatible” without v3, without
LeRobotDataset(), without pi-data-sharing. - MCAP-only delivery that buries stereo calibration in a Slack thread.
- Export scripts that interpolate missing stamps to force a clean 33.3 ms grid.
- Claiming every clip in a mixed 89 clips / 8 scenes scoping library is packaged identically to EP001/EP002—only those two episodes are the our-device public reference.
Envelope checklist that either path must preserve
Regardless of container, accepted egocentric stereo demos in this class should preserve:
[ ] Dual-eye colour RGB, 1920×1200 per eye, 30 fps, hardware-synced stereo
[ ] Timestamps recorded on device: 100% coverage, no interpolation
[ ] Frame interval median = p99 = max ≈ 33.28 ms; 0 out of spec
[ ] IMU ~300.48 Hz; 10 samples/exposure; continuous stream; 0 gaps >10 ms
[ ] Per-frame 6-DoF head pose
[ ] Calibration: K, KB4, R1/R2, P1/P2, Q, IMU↔cam, version
[ ] Geometry report at reference class where applicable
(baseline ~60.7 mm; Sampson 0.166 px; reprojection 0.800 px; 15,811 inliers)
[ ] Learning delivery: LeRobot v3; LeRobotDataset(); pi-data-sharing
[ ] Public reference: EP001 121.57 s wiring; EP002 41.90 s restocking;
4,914 frames; 163.47 s total; sample license CC BY-NC 4.0
[ ] If MCAP is used in capture: conversion must not invent timestamps
Capacity planning stays separate: 10,000+ accepted hours/month refers to hours that already cleared these gates—not hours sitting only in raw logs.
Soft next step
If your team is deciding between LeRobot v3 and MCAP for an egocentric stereo demo buy, default the learning delivery to LeRobot v3, keep MCAP only where capture/runtime already depends on it, and lock the timebase claim—timestamps recorded, not computed—on both sides of any conversion.
Inspect the public LeRobot v3 sample yourself:
- Dataset: https://huggingface.co/datasets/tatezhou/ego-stereo-cn-v1
- Tools: https://github.com/TateZhouSiu/ego-stereo-cn-v1-tools
- Product: https://10khoursdata.com
- Contact: tate@10khoursdata.com
Ask for a walkthrough of LeRobotDataset() load, timing gates, and how calibration products attach to the batch. Format choice then becomes an engineering decision instead of a logo preference.
10K HoursData — egocentric stereo human-demonstration data packaged for learning (LeRobot v3) with timestamps recorded, not computed.