Hiring and Training Robot Teleoperators

You have an SO-100 on the bench, a task worth automating, and a policy that needs 30 to 50 episodes before it is useful. The bottleneck is not the GPU or the model. It is the person driving the arm. Every frame of a LeRobot dataset records one human's motor habits, and imitation learning copies them faithfully, bad ones included.

This covers the human side of teleoperation: what to look for in an operator, how long training takes, and which numbers in the finished dataset tell you whether they were any good. The published evidence is thin but consistent.

The evidence: operator skill moves policy success by tens of points

The cleanest study is What Matters in Learning from Offline Human Demonstrations for Robot Manipulation (Mandlekar et al., CoRL 2021). Six operators recorded through RoboTurk in three tiers: two experienced ("better"), two adequate ("okay"), two inexperienced ("worse"), each providing 50 demonstrations per single-arm task. The tiers are size-matched, so the comparison isolates skill from volume. The success rates below are the paper's low-dimensional results, Table 2 for the operator mixtures and Table 1 for the single proficient operator; image observations are reported separately in its Table 3.

On the harder task (Square, where the arm picks a square nut and places it on a rod) the gap between best and worst tier is 36.7 points for plain behavioral cloning. A stronger algorithm absorbs some of it: BC-RNN nearly closes the gap on Can, and leaves 26.7 points open on Square. And 200 demonstrations from one proficient operator (84.0%) beat every 200-demonstration mixture containing a weak one.

The earlier Scaling Robot Supervision to Hundreds of Hours with RoboTurk (IROS 2019) hit the same wall from the other side: 111 hours across 54 users on three Sawyer arms in one week. Behavioral cloning on the full Laundry Layout set failed outright, and partial success came only after restricting training to the segments where the arm moves to a corner of the towel and lifts. Fifty-four people solving an open task in fifty-four ways produced a dataset close to untrainable as one policy. More in our RoboTurk write-up.

How operator skill shows up in the data

You do not need a supervisor at the operator's shoulder. The signal is in the dataset. The robomimic authors published average trajectory lengths per tier, and the pattern is blunt enough to use as a screening rule.

The weaker tier takes roughly twice as long, but the standard deviation is the sharper signal: on Can it goes from 29 frames to 148. A good operator does the same thing every time. A weak one improvises, and improvisation is the multimodality that makes a policy hesitate at the grasp. Compute one number per operator, and make it the coefficient of variation of episode length.

# Rank operators by episode-length consistency across per-operator datasets.
# Verified against lerobot 0.6.2 (LeRobotDatasetMetadata.episodes has a "length" column).
import statistics
from lerobot.datasets import LeRobotDatasetMetadata

REPOS = {
    "anna":  "my-org/pick-cube-anna",
    "bruno": "my-org/pick-cube-bruno",
    "chen":  "my-org/pick-cube-chen",
}

for operator, repo_id in REPOS.items():
    meta = LeRobotDatasetMetadata(repo_id)
    lengths = list(meta.episodes["length"])
    median = statistics.median(lengths)
    sd = statistics.pstdev(lengths)
    print(f"{operator:6s} n={len(lengths):3d} "
          f"median={median:6.1f} frames ({median / meta.fps:5.1f} s) "
          f"sd={sd:6.1f} cv={sd / median:.2f}")

An honest limitation: none of these separate a slow operator from a hard task instance. A 300-frame episode might be a fumbled grasp, or the one initialisation where the cube started at the far edge. Use the statistics to pick who to watch, then watch the video.

What to look for when you hire an operator

The list below is short because the published evidence supports very little. The original RoboTurk user study reports only that its 8 participants were university students aged 18 to 30; no aptitude screening is described. What it did measure, across those 8 participants and four interfaces, is that the interface dominates: the phone (mean 89.97 seconds on the picking task) and the VR controller (79.36 seconds) were statistically indistinguishable, and both were significantly faster than the 3D mouse (112.57 seconds) and the keyboard (151.45 seconds). Fix the interface before screening people. On an SO-100 that means a calibrated leader-follower pair, not an on-screen pad.

The fix used by DROID is worth copying at any scale: a shared written protocol. Collectors chose their own scenes, but a GUI prompted them with a randomly sampled task per episode so collection would not drift toward the easy objects, periodically demanded scene augmentations such as moving a camera or changing the lighting, and recorded a data collector ID per trajectory. Collectors marked each episode successful or not: the release holds 76k successful episodes plus roughly 16k labelled unsuccessful. See the DROID article for the rest.

How long training an operator actually takes

Shorter than most people assume. RoboTurk's 54 participants got a 5 minute tutorial plus one supervised hour, then collected unsupervised. The learning curve backs that up: completion time fell steadily with previous trials, while measured effort, the squared L2 norm of their phone translations, stayed flat and the orientation change they commanded went up. Operators got faster by rotating the controller more, not by moving it faster.

Here is a curriculum for an SO-100 that mirrors those findings: two hours, ending in a dataset you can train on. Commands are LeRobot 0.6.2 entry points, and the same ground is covered in the operator guide.

1. 1
   Calibrate both arms first, once, together

   A first session should not be spent fighting a bad calibration. Run this with the operator watching, so they know what a correct range of motion looks like. See calibration for what the file holds.

   bash

   lerobot-calibrate --teleop.type=so100_leader --teleop.port=/dev/ttyACM0 --teleop.id=leader_a
   lerobot-calibrate --robot.type=so100_follower --robot.port=/dev/ttyACM1 --robot.id=follower_a

2. 2
   Fifteen minutes of free teleoperation, nothing recorded

   No task, no target, no dataset. Let them find the workspace limits and discover that the gripper closes slower than they expect. The highest-return part of the curriculum.

   bash

   lerobot-teleoperate \
     --robot.type=so100_follower --robot.port=/dev/ttyACM1 --robot.id=follower_a \
     --teleop.type=so100_leader --teleop.port=/dev/ttyACM0 --teleop.id=leader_a

3. 3
   Fifteen minutes driving from the camera view only

   Turn on the visualiser and have them turn their chair away from the robot. The LeRobot docs put it well: you should be able to do the task yourself by only looking at the camera images. If they cannot, the camera placement is wrong, not the operator.

   bash

   lerobot-teleoperate \
     --robot.type=so100_follower --robot.port=/dev/ttyACM1 --robot.id=follower_a \
     --robot.cameras="{ front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}, wrist: {type: opencv, index_or_path: 2, width: 640, height: 480, fps: 30} }" \
     --teleop.type=so100_leader --teleop.port=/dev/ttyACM0 --teleop.id=leader_a \
     --display_data=true

4. 4
   Five throwaway episodes that never reach the Hub

   The point is the control flow, not the data. Right arrow or n ends an episode early, left arrow or r cancels and re-records it, Escape or q stops the session. Make them use all three.

   bash

   lerobot-record \
     --robot.type=so100_follower --robot.port=/dev/ttyACM1 --robot.id=follower_a \
     --robot.cameras="{ front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}, wrist: {type: opencv, index_or_path: 2, width: 640, height: 480, fps: 30} }" \
     --teleop.type=so100_leader --teleop.port=/dev/ttyACM0 --teleop.id=leader_a \
     --display_data=true \
     --dataset.repo_id=my-org/warmup-anna \
     --dataset.single_task="Pick up the red cube and put it in the bin" \
     --dataset.num_episodes=5 \
     --dataset.episode_time_s=25 \
     --dataset.reset_time_s=15 \
     --dataset.push_to_hub=false

5. 5
   Read the cadence report out loud

   lerobot-record prints an achieved-rate line after every episode and a session summary. If the effective cadence is below the fps target, fix it before recording anything real.

   text

   Cadence (episode 0): 29.88 Hz vs 30 Hz target - 600 ticks, 20.0 s measured
     8/599 ticks over the 33.3 ms budget (work mean 18.4 ms, worst 45.1 ms)

6. 6
   Record the first real block under their own name

   One dataset per operator, named after the operator. This is the workaround for the missing operator field, and it is free on day one. lerobot-record appends a date-time tag to the repo id unless you pass --dataset.no_stamp=true, and the merge step below expects the name you actually typed.

   bash

   lerobot-record \
     --robot.type=so100_follower --robot.port=/dev/ttyACM1 --robot.id=follower_a \
     --robot.cameras="{ front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}, wrist: {type: opencv, index_or_path: 2, width: 640, height: 480, fps: 30} }" \
     --teleop.type=so100_leader --teleop.port=/dev/ttyACM0 --teleop.id=leader_a \
     --dataset.repo_id=my-org/pick-cube-anna \
     --dataset.no_stamp=true \
     --dataset.single_task="Pick up the red cube and put it in the bin" \
     --dataset.num_episodes=30 \
     --dataset.tags='["operator:anna","session:2026-08-24"]'

LeRobot has no operator field, so build one out of repo ids

This surprises people, so state it plainly. In the LeRobot v3.0 format, meta/episodes holds per-episode records with fields such as episode_index, task_index, length, from_timestamp and to_timestamp. There is no demonstrator identity. DROID stores a collector ID per trajectory; LeRobot does not. Record five operators into one repo id and their data is mixed permanently.

1. Give every operator their own --dataset.repo_id, for example my-org/pick-cube-anna, with --dataset.no_stamp=true so the name survives verbatim.
2. Add --dataset.tags with an operator tag so the provenance survives a push to the Hub.
3. Score each dataset separately with the length statistics above, and watch the three longest episodes of each.
4. Delete the episodes that fail review: lerobot-edit-dataset --repo_id my-org/pick-cube-anna --operation.type delete_episodes --operation.episode_indices "[3, 11, 27]"
5. Merge only the datasets that survived: lerobot-edit-dataset --new_repo_id my-org/pick-cube-merged --operation.type merge --operation.repo_ids "['my-org/pick-cube-anna','my-org/pick-cube-chen']"
6. Keep the rejected datasets. They are how you check that your review process does anything.

If manual review does not scale, Demo-SCORE (Chen et al., 2025) automates the same decision: train an initial policy on everything, roll it out, train a classifier separating successful rollouts from failed ones, then filter the demonstrations with it. The paper reports over 15 to 35 percent higher absolute success rate than training on all the data, at the cost of robot time for the rollouts.

Getting from an untrained operator to a trained policy

lerobot-train \
  --dataset.repo_id=my-org/pick-cube-merged \
  --policy.type=act \
  --policy.device=cuda \
  --output_dir=outputs/train/act_pick_cube \
  --job_name=act_pick_cube

The per-operator training run is the honest version of all of this. Length statistics are a proxy; a trained policy evaluated on the real arm is the answer. At the prices on the 24 GB tier, running ACT on SO-100 once per operator is a rounding error against the recording time.

The other job: correcting a policy instead of demonstrating from scratch

Once a first policy exists, the job changes. BC-Z (Jang et al., CoRL 2021) ran this at scale: 7 operators across 12 robots collected 25,877 demonstrations, 125 hours of robot time. Of those, 11,108 were expert-only demonstrations seeding the initial policies and 14,769 were shared-autonomy episodes over 16 rounds, where the policy attempted the task and the human gripped an override switch to correct it. At equal episode count, the correction data helped.

BC-Z also produced the most useful operator metric in the literature: the intervention rate, the average takeovers per episode, correlates negatively with policy success rate. It is a live evaluation signal that costs nothing, because the operator is already there. LeRobot exposes the same mode through lerobot-rollout --strategy.type=dagger.

Where remote operators and this platform do not help

Three limits, stated plainly, because pretending otherwise wastes money.

• No amount of GPU fixes a bad demonstration. Fine-tuning reproduces what is in the data. If the operator missed the grasp 40% of the time, the policy will too.
• The platform does not judge your operators. There is no per-operator quality score in the product. The repo-id-per-operator discipline above is manual, and it is the part you cannot outsource.
• Diversity has to be deliberate. One operator in one room produces a policy that works in one room. DROID needed 50 collectors in 52 buildings for scene diversity, and no cloud service substitutes for that.

Still choosing a model for the dataset? The policy comparison puts the five trainable options side by side with parameters, GPU tier and minimum episodes, and the arena holds 85 VLA models with 332 benchmark results. On collection specifically, our data-collection guide and the record your first dataset walkthrough go deeper.