How to Budget a Robot Pretraining Data Collection

Custom robot pretraining data has no fixed price list, because the work a spec describes varies more than a rate card can capture: a single-stream RGB collection is a materially different job from ten synchronized streams with hand and body pose, and a task with deep existing contributor coverage is a different job from one that needs recruiting in a new region. Instead of a price list, the drivers below are the actual levers that move cost and timeline, and understanding them is what lets a team scope a spec that fits a budget rather than guess at one.

This page describes cost drivers only — the factors that move a quote up or down — not prices, rates, or budget ranges. Every custom collection is billed per validated hour and quoted against a written spec before capture starts, so the way to get an actual number is to write the spec and request a quote.

For the billing model itself — per-validated-hour billing, who bears the cost of a rejected take, and how a Spec Pilot works — see how much custom robotics training data costs.

A pretraining spec names task categories, scene and environment types, the object set, and participant diversity, and each of those axes is a separate budget lever rather than one combined "hours needed" number. A dataset that hits an hour target but repeats the same room, the same few objects, and the same handful of contributors is cheaper to capture but generalizes worse — which is the same tradeoff GEN-0’s official write-up frames as diversity mattering as much as sheer volume.

Coverage depth for a spec also changes cost independent of scope: environments, tasks, and geographies with active existing contributor coverage move faster and cost less, while a spec that asks for a condition or region with little standing coverage takes longer to recruit for, which shows up mostly in timeline rather than a per-hour markup.

Stream count per episode is one of the largest cost drivers: a single RGB clip needs less equipment and fewer QA passes than an episode syncing multiple streams — 4K video, depth, IMU, 3D hand and body pose, segmentation, and action labels — hardware-triggered off a shared clock using PTP (IEEE 1588) to hold sync error low. More streams means more equipment per rig, more QA passes per hour, and more storage per validated hour.

Calibration and sync are recurring costs across a collection, not a one-time setup fee. Cameras can shift between sessions and a clock source can drift if it is not re-checked, so re-calibration is part of the ongoing capture cost for the life of a program, not something paid once before capture begins.

Hand pose, contact events, and action segments captured live during recording — rather than estimated afterward from raw footage — add annotation cost at capture time but avoid a separate downstream labeling pass. This is the same distinction EgoScale draws between its own SLAM-plus-hand-pose-estimation pseudo-labeling pipeline and directly captured labels: pseudo-labeling shifts the cost from capture to a modeling step instead of removing it, and can carry more noise into training as a result.

QA is what turns raw footage into a validated, billable hour: every hour is checked against the sync-error ceiling and the capture spec, and footage that fails is rejected and recaptured. Billing is per validated hour, not raw hours submitted, so a spec with a high reject rate on unfamiliar tasks means more raw capture is needed to reach the same validated-hour target — a timeline and recruiting cost, not a line item passed to the buyer as a per-hour markup.

Every participant’s consent is recorded and tied to the specific footage they appear in, and faces, license plates, and screens are detected and blurred as part of the pipeline. Pretraining collections tend to involve more participants and more locations than a narrow task-specific collection, simply because the diversity plan calls for it, which makes consent record-keeping a bigger part of the operational cost on a large program than on a small one, even though it is not billed as a separate line item.

Delivered data carries a perpetual, buyer-owned commercial license backed by a documented consent chain, so a model trained on it can ship in a product. That license and consent chain ships with every batch by default, rather than being an add-on a buyer has to negotiate separately.

A Spec Pilot — a small, fast first batch captured and validated against the spec — is the standard way to see real cost drivers before committing to scale. It surfaces where the reject rate is high, where coverage is thin, and whether the stream count in the spec is actually necessary for the model being trained, all while the cost of adjusting the spec is still small.

From there, the levers available to fit a budget are the same ones described above: drop a stream that is not strictly needed, widen the tolerance on an edge case, or phase geography instead of launching every region at once. Each of those moves changes cost and timeline together, and a Spec Pilot is what lets a team see that tradeoff on real, small-scale data before approving a larger volume.

Because there is no catalog price, comparing providers means comparing what each one is actually quoting against — the spec, not a headline number. A lower quote against a looser spec (fewer streams, thinner diversity coverage, less QA rigor) is not a cheaper version of the same dataset; it is a different, smaller scope.