We once shipped a pilot batch with an 18 millisecond wrist-camera clock offset, and this case study exists partly because of it. The mistake was ours: the wrist stream was timestamped off the arm controller instead of the rig’s PTP clock domain, invisible in playback, and it was the customer’s smoke-test training run at hour 20 that surfaced it. We fixed it, changed our rig standard, and kept the lesson. Vendor case studies that report zero mistakes are describing a project that never touched hardware.
This one covers eight weeks of work with a humanoid foundation model team (anonymized by agreement) whose manipulation policy had stalled on cluttered-scene tasks. The claim we will argue with the numbers below: their ceiling was informational, not architectural, and a disciplined multi-view capture operation, pilot batches, per-session calibration gates, one shared clock domain, is what removed it.
The team arrived with a specific complaint. Their policy trained fine, evaluated fine on open scenes, then dropped hard on cluttered tabletops. Their dataset: tens of thousands of teleoperated episodes, every one recorded from a single fixed camera. Failure review showed what you would expect. When clutter occluded the target from that one viewpoint during approach, the policy guessed.
They asked us for multi-view capture at a rate their internal rig could not hit: hundreds of hours within a quarter, calibrated, synchronized, and QA’d to a standard their ML leads could defend. What follows is how we built it, what it cost, what broke, and what the retrain showed. For the general framework behind these choices, the pillar guide is here: The Complete Guide to Exocentric & Multi-View Data for Robot Learning.
Key Takeaways – 600 hours of DROID-style multi-view episodes (two external stereo + wrist) delivered across 8 weeks on 4 parallel stations. – Per-session calibration gates rejected 4.1 percent of sessions; every rejection would have shipped corrupted extrinsics without the gate. – All-in capture cost landed at $31 per hour, inside our standard $26 to $38 benchmark range. – Retrained on matched episode counts, the customer’s occlusion-heavy split improved by double digits; open-scene performance held.
The Starting Point: Diagnosing a Data Ceiling
A data ceiling is a performance plateau caused by information missing from the training set rather than by model capacity. Confirming one is cheap and worth doing before any capture contract: tag evaluation failures by whether the target object was visible to the training viewpoint at decision time. On this team’s cluttered-scene split, occlusion-correlated failures dominated by a wide margin. No architecture sweep fixes pixels that were never captured.
The finding matches the public record. The RoboMimic study showed observation space design materially changes imitation outcomes on identical demonstrations (arXiv:2108.03298), and DROID’s authors considered multi-view important enough to mandate two calibrated external stereo views plus wrist across all 76,000 episodes (arXiv:2403.12945). We proposed the same geometry rather than inventing one.
The Rig Spec: Boring by Design
The capture spec is the contract between operations and the ML team, and ours fit on one page. Four identical stations, each with:
- Two ZED 2i stereo cameras on rigid tripod mounts at roughly 45 degrees off the workspace centerline, 1 m from task center, opposite sides.
- One wrist camera on the arm.
- Extrinsics calibrated with a ChArUco target via OpenCV, cross-checked in Kalibr; camera-to-robot-base transform verified against known end-effector poses.
- Sync via PTP-disciplined clocks, with a hard gate: cross-camera skew under 10 ms or the session does not ship.
- A 20-second ChArUco verification sweep at every session start; reprojection error above 0.5 px blocks capture until recalibration.
Identical stations mattered more than any individual choice. One geometry means one calibration procedure, one QA script, one training data schema, and operators who can rotate between stations without retraining.
What Eight Weeks Actually Looked Like
Scaling capture is a throughput problem with a quality constraint, and the numbers tell the story better than prose:
| Metric | Value |
|---|---|
| Capture stations | 4 (identical DROID-style geometry) |
| Calendar time | 8 weeks |
| Delivered episodes | ~58,000 across 41 task variants |
| Delivered hours (multi-view) | 600 |
| Sessions rejected at calibration/sync gate | 4.1% |
| Episodes rejected at QA review | 2.7% |
| Storage delivered | ~38 TB (H.265, with per-frame extrinsics and sync metadata) |
| All-in operated cost | $31 / hr |
Weeks one and two ran at half throughput on purpose. We shipped a 20-hour pilot batch first so the customer’s ML team could confirm schema, load episodes into their LeRobot-based training stack, and run a smoke-test train before we committed the fleet. They caught the wrist-camera clock defect described at the top of this post: a consistent 18 ms offset from timestamping off the arm controller instead of the PTP domain. Catching that at hour 20 instead of hour 600 is the entire argument for pilot batches.
Throughput past the pilot came down to two decisions that had nothing to do with cameras. The first was task design: the customer’s 41 task variants were sequenced so that each station ran one object set per half-day block, which cut resets and scene changes to minutes instead of the constant churn you get when operators bounce between tasks. The second was operator rotation. Because all four stations shared one geometry and one procedure, any operator could run any station, and we scheduled captures to keep stations busy through breaks and calibration stops. Utilization across the fleet held near 85 percent of scheduled hours; on prior projects with heterogeneous rigs, we had struggled to hold 65.
The other failure worth naming: in week five, a boom mount on station three sagged after a fixture swap, and the morning verification sweep caught reprojection error at 1.3 px. The gate rejected the session, recalibration took 25 minutes, and no corrupted data shipped. Before we ran per-session gates, that class of drift used to surface weeks later as unexplainable training noise.
The Result: What the Retrain Showed
The customer retrained the same architecture on matched episode counts, single-view versus our multi-view data, which is the only comparison that isolates the data effect. On their occlusion-heavy cluttered split, success improved by double digits. On open scenes, performance held flat, confirming the ceiling had been informational, not architectural. Their engineers also reported a second-order win: with three calibrated views per episode, failure triage became visual inspection instead of guesswork, because someone could always see what happened.
We report ranges rather than their exact internal metrics by agreement, and we would flag any vendor who publishes a client’s precise evaluation numbers as a reason to negotiate confidentiality carefully. What we can say precisely is what the comparison controlled for: same architecture, same hyperparameters, same episode count, same evaluation protocol. The only variable was the data.
What We Would Repeat, and What We Changed
Three practices carried the project and are now standard on every DexSet engagement: pilot batches before fleet commitment, per-session calibration and sync gates with hard thresholds, and extrinsics embedded in every episode’s metadata rather than in a side document that drifts out of date.
One thing we changed afterward: we now put the wrist camera on the PTP domain from day zero, on every rig, because the 18 ms lesson generalizes. And we stopped quoting capture programs without a failure-tagging pass on the customer’s existing evaluation data first; twice since, that pass showed the bottleneck was not viewpoint at all, and we said so.
Test the Pattern on Your Own Failures
If your evaluation failures cluster around occlusion and your dataset is single-view, the pattern in this case study probably applies to you. Book a demo and we will walk through the pipeline with real sample episodes, calibration metadata included, and run the failure-tagging pass on your evaluation data before anyone talks about a contract.
Frequently Asked Questions
How long does it take to scale a multi-view capture program?
In this engagement, 600 hours of calibrated multi-view data took 8 weeks on 4 parallel stations, including a deliberately slow 2-week pilot phase. Throughput scales roughly linearly with identical stations once the geometry and QA gates are standardized.
What did the multi-view data cost?
All-in operated capture landed at $31 per hour, inside DexSet’s standard $26 to $38 benchmark range for DROID-style rigs, plus one-time rig builds in the $4,500 to $7,000 range per station.
How do you verify calibration at scale?
A 20-second ChArUco verification sweep at every session start, gated on reprojection error under 0.5 px, with extrinsics cross-checked in Kalibr and camera-to-base transforms verified against known end-effector poses. Sessions failing the gate are recalibrated before any capture ships.
Did multi-view data actually improve the VLA policy?
Yes. Retrained on matched episode counts, the customer’s occlusion-heavy evaluation split improved by double digits while open-scene performance held, isolating viewpoint coverage as the binding constraint.
Why run a pilot batch before full capture?
Because schema and sync defects are cheap at hour 20 and expensive at hour 600. The pilot here caught a wrist-camera clock offset of 18 ms that would otherwise have contaminated the full delivery.
