Short answer
Multi-site collection works when you standardize what you can control and record what you cannot. Fix the capture kit, task protocol, calibration routine, file naming and metadata across sites, then document site differences rather than hiding them. Expect each site to need its own pilot, a named coordinator and a shared quality dashboard, and keep sites separable so you can hold some out for evaluation.
The buyer's problem
One site is easy to run and easy to overfit. Models trained on a single warehouse or kitchen learn its lighting, shelving and staff habits. Buyers want diversity, so they ask for several sites, and then discover that five sites produce five datasets: different camera heights, different file names, different definitions of "done", different amounts of idle time.
Standardization is an operations problem more than a research one. The goal is not identical footage; it is comparable footage with known differences. This page covers what to fix, what to leave free and how to run the program. Coverage choices (which sites, tasks and conditions you need) belong in the demonstration coverage plan; this page assumes you have chosen them.
What published programs show
DROID is a robot dataset, but its operational lessons carry over. It was collected by 50 data collectors across North America, Asia and Europe over 12 months, covering 564 scenes and 86 tasks, using the same rig replicated at 13 institutions: a Franka Panda arm, Robotiq gripper, two exterior stereo cameras and a wrist camera, with camera calibration, depth and a language instruction stored per episode (Khazatsky et al., 2024). The pattern is a fixed kit and per-episode metadata, with diversity from scenes and people rather than from hardware.
Ego4D shows the breadth possible with human video: 3,670 hours from 931 camera wearers across 74 locations in 9 countries, with consenting participants and de-identification procedures (Grauman et al., 2021). That is a general-purpose corpus; a robotics program with defined tasks usually needs a fixed kit and protocol so that differences between sites can be attributed to the sites rather than to the equipment.
What standardization can and cannot do
It makes clips comparable: the same viewpoint class, the same fields, the same naming, the same task definition. It cannot make sites identical, and you would not want it to; site variation is the diversity you are paying for. It cannot make a collector at a busy site behave like one at a quiet site, and it cannot replace a pilot at each location. It also cannot give a recording robot actions: if you need those, a robot, teleoperation or handheld device must be part of the kit. See human demonstrations vs teleoperation.
What to standardize and what to leave free
| Element | Standardize | Leave free (but record) |
|---|---|---|
| Camera model, lens, mount | Yes: same kit | Mounting location per site layout |
| Resolution, fps, codec | Yes | None |
| Calibration routine | Yes: same procedure, same cadence | Calibration pattern placement |
| Clock source and sync event | Yes | Local network details |
| Task definition and success rule | Yes, written protocol | Order of unrelated actions |
| Object set | Core set shared; site-specific extras | Local brands, packaging |
| Demonstrator instructions | Yes, script | Natural pace within bounds |
| File naming and metadata | Yes: schema | None |
| Lighting, layout, clutter | No | Record with photos and a site sheet |
| Operator mix | Target range | Actual composition |
Running the program
Site selection and contracts. Site access, recording notice and permissions are negotiated per site. Allow for a site withdrawing midway; do not build a plan that depends on every site finishing.
Kit. Ship identical, labeled kits with spare batteries, cards and a calibration board. Track kit serials against site and session IDs. Cameras that differ across sites are a confound you will have to model.
Protocol. One written document, versioned, with photos of correct camera placement, task script, timing, what to do when interrupted and when to stop. Translate site-specific terms but keep definitions fixed.
Pilot per site. Record a short pilot, review it centrally, correct, then start. This is the cheapest quality control; see pilot collection scoping.
Coordinator. One named person per site who owns schedule, privacy briefings, camera checks and escalation. Central staff cannot catch everything remotely.
Central dashboard. Daily uploads reviewed by automated checks and a human sample; see in-collection quality control.
Live-site rules. Safety and work interruptions come first; see recording protocol on live work sites.
Illustrative multi-site program sheet
# Illustrative only - all values are synthetic examples a buyer would set
program: multi_site_demo_v0
sites: [site_017, site_018, site_019, site_020, site_021]
holdout_sites_for_eval: [site_021] # decided before collection starts
kit:
head_camera: model_X, 1080p, 30 fps, fixed lens
fixed_camera: model_Y, tripod height 2.0 m, tilt 25 deg
calibration: board scan at session start and after any camera move
sync_event: clap + on-screen clock at start and end
protocol:
document: protocol_v1.3.pdf
tasks: [task_A, task_B, task_C]
success_rule: written per task, with 3 example clips
demonstrator_script: v1.1
naming: {site}_{date}_{session}_{camera}_{take}.mp4
metadata_required: [site_id, session_id, kit_serial, operator_id, protocol_version, task_id]
site_sheet: floor plan, photos, lighting note, noise note, layout changes
qc: pilot approval before production; daily automated checks; weekly review per site
change_control: any protocol change versioned; affected sessions listed
Quality and acceptance criteria
- Every clip carries site, session, kit and protocol version.
- Per-site pilot approved before production recording.
- Distribution tables per site: clips, hours, operators, tasks, camera conditions. Large gaps between sites are reported, not averaged away.
- Calibration records exist for every session and are consistent across sites.
- Protocol deviations are logged with affected sessions.
- Some sites are held out as the program designs its splits; see demonstration dataset splits.
- Rights documentation exists per site and per participant group.
Typical failure modes of multi-site programs
Programs tend to fail in predictable ways. Sites drift from the protocol after the first weeks as collectors improvise. Equipment gets replaced with whatever is available. One strong site supplies most of the data because it is easiest to record, leaving the others thin. Metadata is filled in inconsistently, with free text replacing enumerations. A privacy briefing is given at launch but not to staff who join later. Counter these with scheduled protocol refreshers, spare kits, per-site quotas visible on the dashboard, enumerated metadata with validation at upload, and a briefing log. Report contribution by site, so no single location's habits dominate what a model learns, and decide before collection which sites are reserved for testing.
Questions to ask suppliers
- How many sites and coordinators, and who is accountable for each?
- Is the kit identical across sites, and how is it tracked?
- Is there a written protocol, and how are changes controlled?
- How is each site piloted before production?
- How do you measure and report differences between sites?
- What happens if a site stops partway?
- How are privacy briefings and notices delivered at each site?
- Do the contracts at each site cover recording for AI training, and who signs them?
- Can we hold back whole sites for evaluation?
Franchise and multi-location operators may offer a head start on uniform procedures; see franchise networks as demonstration suppliers. Uniform procedures do not mean uniform permissions, so site-level consent still needs checking.
Discuss your requirements
If you are planning a recording program across locations, describe the tasks, sites and permitted uses to SourceX. The site describes a separate physical-world path for new recordings of hands-on work coordinated with businesses, where each opportunity has its own requirements. SourceX reviews the requirement and follows up about potential sources; a request does not guarantee a match. Start from the humanoid training data guide or the workplace task demonstration hub.
Discuss your humanoid training-data requirements with SourceX
Sources
- DROID: A Large-Scale In-The-Wild Robot Manipulation Dataset — replicated rig across institutions; per-episode calibration and language.
- Ego4D: Around the World in 3,000 Hours of Egocentric Video — distributed egocentric collection with consent and de-identification.