Short answer
Robotics data procurement covers choosing a sourcing route, specifying the data, checking supply, licensing it and accepting the delivery. For humanoid programs it also covers robot-specific data, such as teleoperation, trajectories, motion capture, tactile and force/torque, that only robots and specialist rigs produce. This hub routes procurement, legal and data leads to the pages for each of those decisions.
The problem this cluster solves
A research team asks procurement for "a few hundred hours of warehouse handling video with hand labels, plus some teleop data." That sentence hides at least four decisions: which route can supply each part, what exactly counts as acceptable, who holds the rights, and how the delivery will be checked before anyone pays. Get one wrong and the data arrives unusable, unlicensable for the intended use, or contaminated with the evaluation set.
This cluster is where those decisions live, and it has two halves. The first is general procurement for any physical-world data: specifications, samples, provenance, consent, confidentiality, license terms, delivery and acceptance. The second is the small set of robot-specific data types that a humanoid's control stack needs and that business archives cannot provide. The section overview at the humanoid training data guide explains how the two halves fit the rest of the stack.
What procurement can settle, and what it cannot
Good procurement can make a suitable asset usable and safe to use. It can fix scope (which tasks, sites and people), terms (permitted uses, derivatives, retention, deletion), evidence (provenance records, consent documentation, samples) and acceptance (tests that a delivery must pass).
It cannot make an unsuitable asset suitable. No license clause adds missing robot actions to human video, restores hands hidden by a fixed ceiling camera, or turns a single-site archive into a diverse one. Redaction and blurring do not, by themselves, resolve whether the people recorded agreed to AI training.
Procurement pages are diligence aids, not legal conclusions. This is not legal advice.
Robot-specific data has its own limits. It supports control learning on a defined embodiment with a defined action space, but it rarely carries the business-process context that workplace footage and procedures provide. Data from other robots transfers only partly: Open X-Embodiment pooled data from 22 embodiments and reports positive transfer across platforms (Open X-Embodiment Collaboration, 2023), which is a reason to check cross-embodiment robot datasets before commissioning your own, not a reason to skip data on your own hardware.
Illustrative procurement sequence
| Stage | Output | Typical owner | Page |
|---|---|---|---|
| 1. Route | Which layers come from existing assets, new collection or specialists | Data-program lead | Choosing a sourcing route |
| 2. Specification | Tasks, modalities, coverage, labels, holdouts, permitted uses | Research plus procurement | Requirements specification template |
| 3. Supply check | Candidate suppliers and samples | Procurement | Requesting and reviewing samples |
| 4. Diligence | Provenance, consent, confidentiality, third-party content | Legal plus data | Provenance and chain of custody |
| 5. License | Signed terms covering uses, derivatives, retention | Legal | Licensing terms for robotics data |
| 6. Delivery and acceptance | Transfer, format checks, acceptance report | Data engineering | Acceptance testing for deliveries |
The order matters. Writing the specification before reviewing samples avoids anchoring on whatever a supplier happens to hold, and agreeing acceptance tests before the license is signed avoids arguing about quality after money has moved.
Specialist robot data: what you must specify
Archives of human work do not contain joint states, commanded actions or contact forces. When a program needs them, the request becomes an engineering specification, and the data comes from robots, teleoperation rigs, handheld capture devices or instrumented setups. Buyers typically need to fix:
- Embodiment and sensors. The robot or capture device, its cameras and their mounting. DROID replicated the same rig at 13 institutions and recorded camera calibration, depth and a language instruction with each episode (Khazatsky et al., 2024).
- Action space and control rate. Joint or end-effector, absolute or delta, and the frequency at which actions are logged; DROID controlled at 15 Hz. See action spaces and control frequency.
- Episode structure and format. RLDS stores each episode as steps holding observation, action, reward, discount and first/last/terminal flags (Ramos et al., 2021); other teams use LeRobot, MCAP, HDF5 or Zarr. See robot learning data formats.
- Calibration and synchronization. Intrinsics, extrinsics, hand-eye transforms and a shared clock across streams.
- Collection protocol. Operators, resets, task variation and how failures are kept. Mobile ALOHA used whole-body teleoperation with 50 demonstrations per task and reports that co-training with existing static ALOHA data raised success by up to 90% (Fu et al., 2024).
Specialist sensing has its own trade-offs. Marker-based motion capture is mature enough that AMASS unified 15 separate mocap datasets on one body model (Mahmood et al., 2019), but human motion still has to be retargeted to the humanoid. Portable hand capture such as DexCap records no force and runs in power-limited sessions (Wang et al., 2024). Contact-rich datasets such as RH20T log force, audio and actions with every robot sequence (Fang et al., 2023).
Where SourceX fits: its role is sourcing, rights review, licensing and delivery coordination; it can also arrange annotation and engage specialist capture partners, scoped case by case.
Key pages in this cluster
| Group | Page | What it answers |
|---|---|---|
| Decide and specify | Existing assets, new collection or specialist partners | Which route fits each part of the requirement |
| Decide and specify | Requirements specification template | The document you send suppliers, mapped to the request form |
| Decide and specify | Training vs evaluation datasets | Why evaluation data is a separate purchase with its own split rules |
| Decide and specify | Real-world vs synthetic and simulation data | When real data is needed and when simulation carries the load |
| Decide and specify | Cross-embodiment robot datasets | When other robots' data helps before you buy your own |
| Evaluate and accept | Robotics dataset evaluation checklist | Master pass/fail checklist for any offer |
| Evaluate and accept | Requesting and reviewing samples | What a useful sample of an existing dataset looks like |
| Evaluate and accept | Provenance and chain of custody | Records that show where recorded physical work came from |
| Evaluate and accept | Public dataset commercial license checks | Whether public robot and egocentric datasets allow commercial use |
| Evaluate and accept | Acceptance testing for deliveries | Checks a delivery must pass before it is accepted |
| Evaluate and accept | Real-world policy evaluation protocols | Testing policies on hardware, distinct from testing a dataset |
| Rights and permissions | Licensing terms for robotics training data | Clause topics specific to robotics data |
| Rights and permissions | Worker consent and identifiable people | Consent diligence for workers and bystanders on camera |
| Rights and permissions | Biometric privacy and workplace video | Biometric laws and body-centric data |
| Rights and permissions | Confidential business information in footage | Screens, processes and customers visible on camera |
| Rights and permissions | Third-party content in recordings | Material owned by others that appears in recordings |
| Rights and permissions | Model weights, derivatives and redistribution | What you may do with weights, outputs and derived data |
| Rights and permissions | Exclusivity and field-of-use terms | Trade-offs of exclusive or field-limited licenses |
| Rights and permissions | EU AI Act and GDPR considerations | Documentation and lawful-basis questions for EU buyers |
| Delivery | Delivery and transfer of large datasets | Moving multi-terabyte deliveries |
| Delivery | Robot learning data formats | RLDS, LeRobot, MCAP, HDF5 and Zarr compared |
| Specialist robot data | Teleoperation data collection requirements | What to specify for teleoperated demonstrations |
| Specialist robot data | Robot trajectory dataset specification | Observations, actions and episode structure |
| Specialist robot data | Action spaces and control frequency | Joint vs end-effector, absolute vs delta, control rate |
| Specialist robot data | Calibration requirements | Intrinsics, extrinsics and hand-eye metadata |
| Specialist robot data | Sensor synchronization requirements | Time alignment across streams and how to verify it |
| Specialist robot data | Handheld gripper demonstrations | A middle route between human video and teleoperation |
| Specialist robot data | Motion capture for humanoid motion | Whole-body motion data and retargeting |
| Specialist robot data | Tactile sensing data | A scarce modality for in-hand manipulation |
| Specialist robot data | Force/torque data for contact-rich tasks | Wrist and tool forces for insertion and fastening |
Diligence themes that recur across clusters
Three issues come up on almost every physical-world purchase, so they are handled once here and referenced from task pages.
People on camera. Workplace recordings show employees, contractors, customers and bystanders, so the questions are what notice or consent existed when recording happened, whether it covers AI training and transfer to a buyer, and how withdrawal is handled. EU buyers should note that the GDPR treats biometric data processed to uniquely identify a person as a special category under Article 9(1), and that Article 88(1) lets Member States set more specific rules for employee data (European Parliament and Council of the EU, 2016). Start with worker consent and identifiable people.
Who can grant the rights. The business that holds a file is not always the business that owns it. Vendor-produced training courses, client-owned goods in 3PL footage, equipment-maker manuals and photographer-owned product images all need a separate answer. The general training data due diligence checklist covers the basics; the pages above cover the robotics-specific cases.
Train/test separation. Evaluation sets must be held out by site, operator, object or time and kept out of training. Put the split rule in the specification and the license, not just in a research notebook.
How to evaluate supply before you commit
- Ask what the asset was created for, and read its limits from that purpose.
- Request counts by site, operator, object and condition rather than a single total.
- Inspect a sample against your acceptance tests, not against the supplier's description.
- Confirm who signed what: recording notices, consent forms, vendor and client contracts.
- Agree derivative rights for annotations, pose estimates and retargeted trajectories you will create.
- Fix the holdout before delivery, so evaluation data never touches training storage.
Other clusters
Procurement pages are referenced from every cluster. For the data itself, go to workplace task demonstrations, SOPs and procedural data, product and object data, inspection and failure data, maintenance and tool use, warehouse and fulfillment or manufacturing and assembly. The boundary between business-sourced human data and specialist robot data is set out in human demonstrations vs teleoperated robot demonstrations.
Discuss your requirements
When the specification is drafted, send it to SourceX through the buyers page. SourceX looks for US businesses that hold the data you describe, checks the data and the supplier's licensing permissions, agrees pricing and allowed uses in a license, and coordinates delivery and payment. Nothing is contracted until a supplier agrees, and a request does not guarantee a match; SourceX reviews the requirement and follows up about potential sources. SourceX's licensing terms glossary defines the common terms.
Explore sourcing and licensing options with SourceX
Sources
- Open X-Embodiment: Robotic Learning Datasets and RT-X Models — pooled multi-embodiment data and positive transfer.
- DROID: A Large-Scale In-The-Wild Robot Manipulation Dataset — replicated rig, control rate and per-episode calibration.
- Mobile ALOHA: Learning Bimanual Mobile Manipulation with Low-Cost Whole-Body Teleoperation — whole-body teleoperation protocol and co-training result.
- DexCap: Scalable and Portable Mocap Data Collection System for Dexterous Manipulation — limits of portable hand capture.
- AMASS: Archive of Motion Capture as Surface Shapes — unified marker-based motion capture.
- RH20T: A Comprehensive Robotic Dataset for Learning Diverse Skills in One-Shot — force, audio and action data in contact-rich sequences.
- RLDS: an Ecosystem to Generate, Share and Use Datasets in Reinforcement Learning — episode and step structure.
- Regulation (EU) 2016/679 (General Data Protection Regulation) — biometric special category and employee-data provisions.