Every robot data program is budgeted the same way: pick a target number of trajectories, multiply by a cost per trajectory from a vendor quote, and present the total. That model breaks within a quarter, because it prices the wrong unit.
This guide sets out the seven cost lines, a simple formula for robot training data cost per trajectory that accounts for yield, the two inputs that dominate everything, and the levers that actually move the number.
The number everyone quotes is the wrong one
Ask what robot data costs and you will be given a figure per hour or per trajectory. Both are misleading, because neither accounts for the trajectories you collect and cannot use.
The only number that matters is cost per usable trajectory: total program spend divided by the episodes that survive QA and end up in a training run. On a well-run program that ratio is close to the headline figure. On a poorly instrumented one it can be several times worse, and the gap is invisible until you audit it.
The seven cost lines
| Line | Type | Commonly underestimated because |
|---|---|---|
| Hardware and rigs | One-time | It is the only line most teams model at all |
| Operator hours | Recurring | Utilization assumptions are usually optimistic |
| Scene reset and staging | Recurring | On some tasks it exceeds demonstration time |
| QA and review | Recurring | Scales with volume unless automated at capture |
| Annotation | Recurring | Segment and semantic labels are separate jobs |
| Storage and transfer | Recurring | Multi-camera capture outgrows forecasts fast |
| Downtime and maintenance | Recurring | Servo wear and calibration drift are real duty costs |
Hardware is the line teams model and the smallest one over a program’s life. Operator hours and reset time together usually dominate.
The formula
Work it out in this order rather than dividing a budget by a target.
- Cycle time per episode = demonstration time + scene reset time + inter-episode overhead.
- Episodes per operator-hour = 60 divided by cycle time in minutes, multiplied by realistic utilization.
- Collected episodes per week = episodes per hour multiplied by operator hours available.
- Usable episodes = collected episodes multiplied by your yield rate.
- Cost per usable trajectory = total weekly cost divided by usable episodes.
Two inputs decide almost everything: utilization and yield. Both are measured, not assumed, and both come from a pilot.
Yield is the lever nobody pulls
Yield is the share of collected episodes that survive QA. Teams obsess over collecting faster and rarely measure how many episodes they are throwing away.
This is backwards, because yield improvements are usually cheaper than throughput improvements. Adding operators is linear and expensive. Fixing a calibration procedure that was quietly spoiling a slice of every batch is a one-off engineering cost that lifts every future week.
Where yield is typically lost
- Sync and timestamp errors that make episodes untrainable
- Calibration drift discovered after a batch is complete
- Force spikes and destructive contact on uninstrumented rigs
- Latency breaches during a session nobody noticed, per latency budgets
- Operator drift and fatigue late in long shifts
- Ambiguous task scripts producing incomparable episodes
Every one of these is detectable at capture time if you instrument for it. The QA pipeline that catches them pays for itself in yield alone.
What actually moves cost per usable trajectory
| Lever | Effort | Typical impact |
|---|---|---|
| Automated QA at capture | Moderate engineering | High; raises yield across every future batch |
| Reducing scene reset time | Low; fixtures and staging | High on short-cycle tasks |
| Operator selection and calibration | Low | Moderate to high; variance is a yield problem |
| Session design around fatigue | Low | Moderate; see operator fatigue |
| Adding rigs | High capital | Linear throughput, no yield gain |
| Adding operators | High recurring | Linear throughput, may reduce yield |
| Offshore or nearshore delivery | Moderate setup | High on the operator-hours line |
The pattern is clear. Capital and headcount buy throughput. Process and instrumentation buy yield, and yield compounds.
The cheapest trajectories you are already paying for
One source sits outside this model entirely. If you operate a deployed fleet, every remote intervention is a demonstration you have already funded through your operations budget.
We produce this continuously for an autonomous mobility company operating sidewalk delivery robots and self-driving passenger vehicles. The marginal cost of turning those events into training data is the structured logging, not the human time, because the human time is already being spent.
Most fleets log the incident and discard the structure that would make it trainable. Adding trigger type, resolution type, and root cause fields converts a cost centre into the highest-value slice of a dataset, because these episodes sample real failures rather than your guess at them.
Build versus buy, priced properly
Compare on cost per usable trajectory at steady state, including the ramp. In-house programs carry a ramp period during which yield is poor and cost per usable trajectory is at its worst, and that period is routinely omitted from the comparison.
In-house tends to win where the task set is stable, volume is steady, and the work is genuinely proprietary. Outsourcing tends to win where you need to scale before the task definition has settled, or where geography materially changes the operator-hours line. Our build vs buy comparison and the real cost of in-house collection work through both cases.
Ramp length is a real line in any budget. Our mobile manipulation case study covers a 90-day path from cold-start to production.
Frequently asked questions
What yield rate should we plan for?
Measure it in a pilot rather than adopting a number. Programs without automated QA at capture are usually well below what they assume, and the first honest audit is often uncomfortable.
Does cost per trajectory fall with volume?
Somewhat, through hardware amortization and operator learning. It rises again if QA does not scale, since a growing backlog delays defect detection and whole batches go bad before anyone notices.
How should bimanual and dexterous work be priced?
Separately, with their own yield assumptions. Both have higher failure rates per episode, as covered in bimanual manipulation datasets.
Is synthetic data cheaper?
Per episode, dramatically. Per unit of real-world performance, it depends entirely on the task, and it substitutes poorly for contact dynamics. See our real vs synthetic vs hybrid comparison.
Most programs discover their real cost per usable trajectory a year in, when the training team asks why the dataset is smaller than the invoices suggest. If you want a model built against your task list before you commit, send us the specification.
