Robot Data Collection as a Business: Pay, Buyers, Reality

Somebody is paying for robot demonstrations. In April 2026 MIT Technology Review followed gig workers in Nigeria and India who strap an iPhone to their forehead and film themselves folding laundry for micro1, a Palo Alto company that resells the footage to robotics labs. Its chief executive estimated that robotics companies spend more than 100 million USD a year buying real-world data from micro1 and firms like it. In June 2026 TechCrunch covered XDOF, a data company with roughly 60 employees and 20 customers that had raised 70 million USD. In August 2026 TechCrunch reported micro1 going from a 100 million USD gross annual run rate to 500 million USD in eight months, though that figure covers its whole AI training data business and not robot data alone. This is a real market with real invoices in it.

Who is buying, and what they are buying

The buyer side splits into three groups that pay differently. Frontier robotics labs want data on the exact robot they are shipping, and mostly build that in house or buy it as a managed program. Data vendors sit between those labs and the people holding cameras: Scale AI wrote in September 2025 that it had passed 100,000 production hours at its San Francisco prototyping laboratory and with contributors globally, for customers including Physical Intelligence, Generalist AI and Cobot. Then there is the state-funded tier, which barely behaves like a market.

Rest of World reported in January 2026 that more than 40 state-backed robot data collection centres had been announced across China by December, with about two dozen already running, according to the analyst firm Interact Analysis. One camp near Beijing, built by the Shijingshan government with the humanoid company Leju, covers more than 10,000 square metres and offers 16 scripted scenarios. In one Hubei facility close to 100 humanoids are driven through folding, ironing and wiping hundreds of times a day. UBTech sold 566 million yuan, about 80 million USD, of humanoids into three such centres. That is a lot of capacity that does not need to earn its money back this quarter.

What the work pays in 2026

Published rates are thin because most of this is priced per project behind an NDA, but there are enough real datapoints to draw a range. One rate below comes from named reporting and one from a live job listing; the other two rows are there to mark where no published price exists.

The gap between the top and bottom of that table is not skill, it is capital. The on-site teleoperator earns twice to more than three times the at-home recorder because someone else bought the robot, the cameras, the network and the shift supervisor. If you own an SO-100 you have bought yourself into the middle of that range and taken on the equipment risk. Whether that pays depends entirely on how many recorded minutes you can actually deliver per hour of your life, which is the number almost nobody quotes.

The arithmetic of one operator

Take the best documented data collection effort in the open literature and divide. DROID, published at RSS 2024, contains 76,000 demonstration trajectories or 350 hours of interaction, collected across 564 scenes and 84 tasks by 50 data collectors in North America, Asia and Europe over 12 months. That is about 16.6 seconds of robot motion per trajectory, 1,520 trajectories per collector for the year, and roughly 7 hours of actual recorded interaction per collector across an entire year. RoboTurk's follow-up work is the other anchor: 111 hours from 54 remote users on three tasks in one week, which is about two recorded hours per person for the week.

Neither number means those people worked seven hours a year. It means recorded motion is a small fraction of the clock. Everything else is setup, resets, calibration, re-recording the take where the gripper missed, and moving the props. The defaults in LeRobot say the same thing in a config file rather than a paper.

# 50 episodes, one task, leader-follower on an SO-101 follower
lerobot-record \
    --robot.type=so101_follower \
    --robot.port=/dev/ttyACM0 \
    --robot.id=my_follower_arm \
    --robot.cameras="{ front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}, wrist: {type: opencv, index_or_path: 1, width: 640, height: 480, fps: 30} }" \
    --teleop.type=so101_leader \
    --teleop.port=/dev/ttyACM1 \
    --teleop.id=my_leader_arm \
    --dataset.repo_id=${HF_USER}/pick-cube-kitchen-01 \
    --dataset.num_episodes=50 \
    --dataset.single_task="Grab the black cube" \
    --dataset.episode_time_s=30 \
    --dataset.reset_time_s=15 \
    --display_data=true

# during the run:
#   n or right arrow  -> end this episode early, move on
#   r or left arrow   -> throw this episode away and re-record it
#   q or ESC          -> stop, encode the videos, upload

Cutting the episode to 30 seconds and the reset to 15 seconds takes the ceiling from 30 episodes per hour to 80. Whether you can actually hit it depends on how long it takes to put the cube back and how often you press r. Track that ratio for a week before you quote anyone a price. If you are new to this, the record your first dataset walkthrough and the episode glossary entry are the places to start, and the SO-100 data collection page covers the rig side.

What buyers actually check

The single most useful published result for anyone selling demonstrations is the Data Scaling Laws paper (ICLR 2025). The authors collected more than 40,000 demonstrations and ran over 15,000 real robot rollouts to answer one question: what do you get for another demonstration? The answer is that generalisation follows roughly a power law in the number of environments and objects, and that once you pass about 50 demonstrations per environment-object pair, more demonstrations in that pair do almost nothing. Their recommended recipe is 32 diverse environments, each with its own object and 50 demonstrations, which reached around 90 percent success in unseen environments with unseen objects.

Read that as a pricing statement. A buyer who understands the literature is not paying you per episode, they are paying you per distinct scene-object pair with enough coverage to be usable. Five hundred episodes of the same cube on the same table is worth less than the same five hundred split across ten rooms with ten different objects. That is also the thing you can sell that a data factory cannot easily buy: you live somewhere they do not, and your kitchen is a scene they do not have.

The other check nobody writes into a contract but everybody applies: does a policy actually train on it. A buyer who has been burned once will ask for evidence, and the cheapest evidence is a small model trained on your own data with the loss curve and a rollout video attached. ACT at roughly 80 M parameters and SmolVLA at roughly 450 M both run on a 24 GB card, which on the AY-Robots spot tier is 2 to 5 hours at 0.30 to 0.60 USD per hour, so about 1 to 3 USD per run. Three dollars to prove your dataset is trainable is the best money in this whole business.

Two routes to the same recorded episode

Pricing a job without a market price

There is no published clearing price for a LeRobot episode, so you build one from the two numbers you control: your measured episodes per hour, and the rate you would accept for that hour doing anything else. What follows is arithmetic on your own inputs, not a market quote.

1. 1
   Measure your real throughput for one week

   Not the theoretical ceiling. Accepted episodes divided by hours at the desk, setup and re-records included. At the LeRobot defaults the ceiling is 30 per hour; most people land well under it.

   bash

   # count the episodes actually saved
   ls -R ~/.cache/huggingface/lerobot/${HF_USER}/pick-cube-kitchen-01/videos | wc -l
   # and read the episode count the dataset itself reports
   python -c "import json,os,pathlib; \
   p=pathlib.Path.home()/'.cache/huggingface/lerobot'/os.environ['HF_USER']/'pick-cube-kitchen-01/meta/info.json'; \
   i=json.load(open(p)); print(i['total_episodes'], 'episodes,', i['total_frames'], 'frames,', i['fps'], 'fps')"

2. 2
   Convert the spec into scene-object pairs

   A buyer asking for 500 episodes has not told you anything useful yet. Ask how many distinct environments and objects. The Data Scaling Laws recipe of 32 pairs at 50 demonstrations each is 1,600 episodes and 32 room resets, and the room resets are the expensive part.

3. 3
   Price the setup separately from the recording

   Moving the rig, re-fixing the cameras and re-checking calibration is fixed cost per environment. Bill it as such. Price per episode only and the diverse dataset buyers actually want is the one that loses you money.

4. 4
   Add a verification line item

   One training run and a rollout video per delivered dataset. On the 24 GB tier that is roughly 1 to 3 USD of compute, and it converts arguments about quality into a fact.

   bash

   lerobot-train --dataset.repo_id=${HF_USER}/pick-cube-kitchen-01 \
     --policy.type=act --policy.device=cuda \
     --output_dir=outputs/train/act_verify --job_name=act_verify

5. 5
   Write the format and the reject rule into the contract

   LeRobot version, camera count and resolution, frame rate, task string, who decides a take is rejected, and whether rejected takes are paid. The version clause alone will save you a day at some point.

Where this does not work

Three honest limits, none of which the vendors in this space put on their landing pages.

• Embodiment does not transfer for free at the top of the ladder. A buyer building a humanoid wants demonstrations on that humanoid. Your SO-100 data is useful for general manipulation research and for anyone training on SO-100 class arms, and that is a smaller room than the headline funding numbers suggest.
• Volume alone has no bid. With more than 72,400 LeRobot-tagged datasets already free on Hugging Face, another 200 episodes of a cube going into a bin has no scarcity value. What is scarce is a documented variation plan, consistent cameras, and evidence the policy learned.
• Remote work has a physics limit. Inference must sit next to the servos for fast tasks: the control loop is 20 ms per action step for ACT and up to 485 ms for Pi0.5, and adding public-internet round trips turns a working policy into a hesitant one. Remote inference is viable for slow pick-and-place, not for fast reactive motion. See inference latency.
• The demand curve is young. Ken Goldberg of UC Berkeley, quoted in both the Rest of World and MIT Technology Review pieces, calls the effort noble but slow: even with hundreds of people working, he says, it is going to take a long time to get enough data, and longer than people think. Plan for it taking longer than the funding cycle.

If you want to test the work before spending anything, the live arm at /live streams a physical robot with no signup, queue-based, and /try lays out the three ways to start without hardware. For the technical side of what makes a dataset trainable rather than merely large, our guide on collecting high-quality VLA training data goes deeper on the recording side, the DROID dataset write-up covers how a 50-person effort was organised, and the RoboTurk piece covers the crowdsourcing experiment that started this line of work. For the hardware, the SO-100 complete guide is the setup reference, and imitation learning and policy define the terms buyers will use in their spec. If you are still choosing which model to record for, the five trainable policies are compared side by side with their minimum episode counts.