A buyer asking “How much does robot training data cost?” is usually asking several questions at once. What is being recorded? How much of it will be usable? Does it match the task and environment where the robot will operate? Are actions, language, calibration or annotations included? Can the buyer use the data for commercial training? Those details matter more than a headline rate. Public figures are difficult to compare because providers quote different units, collection methods and scopes. A price attached to raw video is not directly comparable with a price for validated robot trajectories or a fully annotated dataset. This guide explains how to evaluate the scope and evidence behind a quote without treating a vendor benchmark as a market rate.

Start by defining the data product

“Robot training data” can describe materially different things. Before comparing proposals, specify which signal the model needs and what the delivered unit represents.

Egocentric human video records a person performing a task from a first-person viewpoint. It can support visual representation learning, activity understanding and some forms of human-to-robot transfer. By itself, ordinary video does not provide the robot’s action commands or guarantee a mapping from human motion to a particular robot.
Wearable or handheld manipulation demonstrations add interaction signals, such as gripper motion or tracked hand pose, to the human demonstration. The exact value depends on what is sensed, how it is calibrated and how the signal maps to the target robot.
Robot teleoperation records observations and robot actions while a human controls the robot. It is closer to the target embodiment and control interface, but collection depends on access to the robot, a working teleoperation setup, trained operators and safe operating conditions.
Autonomous or self-supervised experience is collected while a robot acts without a human supplying every action. It can reduce direct demonstration effort in some settings, but real-world collection still requires robust task setup, resets, success detection and safe handling of failures.

The Open X-Embodiment project illustrates why the data format and signal matter: it brings together datasets from different robot embodiments and standardises their representation to support cross-robot research. EgoVerse, by contrast, studies a shared framework for egocentric human data in robot learning. These are related data strategies, but they answer different modelling needs.

Compare the delivered unit, not the headline

Providers may quote per recording hour, accepted hour, episode, task, annotation pass or project. A project quote can be perfectly clear, but only if the scope states what will be delivered and how completion will be judged. Ask the provider to define:

Raw recording: all material captured before quality review.
Accepted recording: material that passes the agreed technical and task criteria.
Episode or demonstration: a bounded attempt at a task, with explicit start and end rules.
Annotated unit: an episode or time span with specified labels, events, tracks or metadata.
Project deliverable: the complete agreed package, including data, schema, documentation, quality report and rights.

A useful commercial comparison is the total project fee divided by the amount of accepted, in-scope data delivered. But that calculation is only meaningful when acceptance is defined consistently. “Accepted” should specify what happens when a file is corrupt, the camera is obstructed, the task is incomplete, a required sensor stream is missing, or an annotation is disputed. Avoid vague promises such as “hours of data” unless the proposal also states whether those are raw or accepted hours, how episodes are segmented and what happens to rejected material. Agree the acceptance rules before recording begins.

What research says about the value of data

More data is not automatically better data

Robot-learning papers commonly report benefits from larger and more varied datasets, but the useful lesson is not simply to maximise volume. In Data Scaling Laws in Imitation Learning for Robotic Manipulation, the authors examine how performance changes with the number of objects and environments represented in the demonstrations. Their work supports evaluating coverage—not just counting recordings—when designing a collection. The large-scale DROID dataset paper describes the operational challenge directly: collecting robot interactions across diverse real environments requires hardware and human labour, alongside logistics and safety planning. The authors report improvements in policy performance, robustness and generalisation from training with the dataset. This is evidence that environment and task coverage can be valuable; it is not a universal guarantee that any additional diversity will improve any model.

Diversity needs a target

Useful variation should resemble the variation the deployed system must handle: different objects, layouts, lighting, viewpoints, workflows, operators or recovery situations. A collection can be large and still miss the conditions that cause failures in production. At the same time, uncontrolled variation can introduce inconsistent demonstrations. The recent study Is Diversity All You Need for Scalable Robotic Manipulation? examines task, embodiment and expert diversity, and reports that these dimensions do not have identical effects. In particular, variations in how people perform a task can complicate learning. The practical implication is to define which variation is intentional, record the relevant metadata and avoid mixing incompatible procedures without a reason.

Quality is about what the policy will encounter

Data Quality in Imitation Learning frames data quality in terms of distribution shift: high-quality demonstrations help a learned policy remain within states represented by its training data. This is a more useful lens than treating quality as a single score. A perfectly sharp video may still be poor training data if the task state, action signal or recovery behaviour the model needs is absent. This is why quality review should test both technical integrity and task coverage. Technical checks can catch missing frames, timestamps, calibration, sensor streams or metadata. Task review can check whether the required objects and steps are visible, whether attempts reach meaningful outcomes and whether interruptions or failures are labelled consistently.

What drives the project scope

Capture method and instrumentation

A first-person camera setup is generally simpler to deploy than a robot-specific teleoperation rig, but it captures different information. Teleoperation can provide robot observations and action labels, while adding setup, maintenance and operator requirements. Wearable or handheld systems sit between these approaches, depending on the sensors and action representation they provide. Compare the full data schema: camera views, frame rates, timestamps, calibration, robot state, action channels, audio, annotations and file format. Missing or unsynchronised streams can make otherwise usable footage unsuitable for a particular training pipeline.

Access to real sites

Workplace collection introduces coordination beyond the recording equipment: site approval, worker consent, safety rules, shift timing, privacy restrictions and operational disruption. The DROID project is a useful example of a research collection whose authors explicitly identify logistical and safety demands in diverse environments. A vendor should explain where collection will happen, who controls site access, how filming is communicated to workers and visitors, and how sensitive information is handled. In industrial settings, site access and a repeatable operating process can be as important as the capture hardware.

Task and environment coverage

List the variations that matter to the intended deployment: objects, layouts, work surfaces, lighting, tools, task order, operator experience, normal interruptions and recovery cases. Then separate required coverage from optional exploration. This turns “diverse data” into a testable brief. The Open X-Embodiment project also highlights a practical challenge in combining datasets: sources may differ in robot embodiment, action conventions and data schema. For a buyer, that means asking whether the supplier’s delivery is consistent enough for the intended model pipeline, and whether conversion or harmonisation work is included.

Annotation and review

“Annotated” is not a complete specification. Ask what labels are included, who creates them, how disagreements are resolved and what quality evidence accompanies delivery. Depending on the task, useful labels might include task and subtask boundaries, object identity, action descriptions, success or failure, contact events, hand or body tracks, or privacy redactions. Annotation effort depends on the label definitions and the evidence needed to apply them. A short, clear schema can be more useful than an elaborate label set that annotators interpret inconsistently. Request a sample with the proposed schema before approving a full collection.

Data rights and permitted use

Confirm who owns the raw recordings and annotations, who receives the data, and whether the licence allows commercial model training, evaluation, modification and storage. Check restrictions on redistribution, sublicensing, contractors, affiliates, derived datasets and trained models. For workplace footage, also establish the process for worker consent, site permissions, personal data and retention. A technically strong dataset can still be unusable if its licence does not cover the intended deployment or if site permissions are incomplete. Make rights part of the written specification, not a final procurement detail. The dataset licensing guide covers exclusive and non-exclusive terms in more detail.

Pilot for acceptance and model utility

A pilot should answer two separate questions: can the provider reliably produce data that meets the brief, and does that data help the target model or evaluation? Agree in advance on a small, representative scope covering ordinary work and the difficult cases that matter. Review a sample delivery for technical completeness, task coverage, annotation consistency, privacy handling and licence documentation. Then run the intended training or evaluation workflow and compare the result with an agreed baseline. A pilot is most informative when it measures:

the share of submitted material that meets each acceptance criterion;
recurring reasons for rejection or re-recording;
coverage of the requested people, places, objects and task conditions;
whether the data loads cleanly into the buyer’s pipeline;
whether the collection changes a relevant model or evaluation outcome;
the time and effort required from the buyer’s own engineering and operations teams.

The goal is not to optimise a single yield number. It is to learn which parts of the brief produce useful training signal, which create avoidable collection friction and which gaps remain after evaluation.

Collect in-house or work with a provider?

In-house collection makes sense when data depends on a proprietary robot, a controlled test environment or information that cannot leave the site. It also gives the robotics team direct control over task design and instrumentation. The trade-off is that engineers and operations staff must support collection, quality review and rework alongside their other responsibilities. An external provider can bring collection operations, access to people and sites, capture equipment and a repeatable review process. It is most useful when the brief is clear and the provider can demonstrate relevant experience. Many teams use a hybrid approach: collect robot-specific action data internally, then use external collection for broader human activity, environmental coverage or repeatable tasks.

Checklist for comparing proposals

Ask every provider to answer these points in writing:

Unit: Is the proposal based on raw recordings, accepted data, episodes or a complete project deliverable?
Acceptance: What are the pass criteria, who approves them and what happens to rejected material?
Schema: Which video, audio, sensor, action, calibration and metadata fields are included?
Coverage: Which tasks, objects, people, environments and edge cases are in scope?
Collection operations: Who supplies equipment, trains collectors, obtains site access and handles safety?
Annotation: Which labels are included, how are they defined and how is consistency checked?
Quality evidence: What reports, sample files and validation checks accompany delivery?
Rights: Does the licence cover the intended commercial training, evaluation, storage and downstream use?
Privacy: How are consent, sensitive information, access control and retention handled?
Buyer effort: What must your team provide, review, integrate or maintain?
Pilot: Can you test representative data in your actual training or evaluation pipeline before expanding scope?
Change control: How are scope changes, re-recording and extra annotation handled?

Common questions

Is there a standard price for robot training data?

No single rate is meaningful across egocentric video, wearable demonstrations, teleoperation and autonomous robot experience. Quotes differ in unit, capture method, quality requirements, annotation, site access, rights and delivery scope. Compare proposals against the same brief and accepted deliverable rather than relying on a published headline figure.

Is egocentric video a substitute for teleoperation data?

Not in every application. Egocentric video can provide rich visual evidence of human activity and may support representation learning or transfer research. Teleoperation records the robot’s own observations and actions. If the model must learn a specific robot control policy, check whether human video contains the action or alignment signals the method needs. EgoVerse and Open X-Embodiment are useful examples of distinct data approaches in this research landscape.

Should we buy an existing dataset or commission a custom collection?

An existing dataset can be a good fit when its task coverage, data schema, quality and licence match your use case. Custom collection is appropriate when critical environments, objects, workflows or action signals are missing. A pilot can establish whether the gap is real before a larger commitment.

What should we measure in a pilot?

Measure acceptance against the written criteria, coverage of the required conditions, integration effort and the effect on the model or evaluation that motivated the collection. The right success measure depends on the task; recording volume alone does not establish value.

Getting started

Telepath Robotics scopes collection against a written brief covering capture method, task and environment coverage, review criteria, deliverables and rights. We recommend reviewing representative data and testing it in the intended workflow before expanding a collection. Learn how robot training data collections are scoped, or about egocentric data collection, or contact us to discuss a project brief. Research findings are task- and method-dependent. The cited papers inform how buyers can assess scope; they do not establish a universal price or guarantee performance for a particular deployment.

Robot Training Data Costs: What Buyers Should Compare