Teleoperation is not a new idea. Decades before anyone trained a policy on it, technicians were already standing behind lead-lined walls moving a mechanical arm to handle radioactive material they could never touch directly. The core idea hasn't changed: a human drives a machine in real time, from a safe or convenient distance, and the machine does the physical work.
What changed is what happens to the recording afterward. In 2023, a Stanford, Berkeley, and Meta team built a bimanual teleoperation rig for about $20,000 in parts and used it to collect a small number of demonstrations per task, in some cases around ten minutes of data, then trained a policy that hit high success rates on six fine manipulation tasks. The system is called ALOHA, and the paper's real contribution wasn't the robot. It was proving that a relatively cheap, human-driven rig could produce data precise enough to teach contact-rich skills that had resisted other training approaches for years.
That's the thread this guide follows: not demonstration methods broadly, which we cover across teleoperation, kinesthetic teaching, handheld grippers, and video in human demonstrations for robot training, but teleoperation specifically. What it is, the hardware tiers that actually exist, what makes the data it produces unusually trustworthy, and the costs and throughput limits that come with that.
The short version
Teleoperation data collection is the recording of robot demonstrations while a human operator drives the real target robot through an interface such as a leader arm, VR headset, 3D mouse, or haptic device, with the robot's own joint states, camera streams, and commanded actions logged as the episode. Because the action space is the robot's own, there is no retargeting step between a human body and a machine. That single fact is why teleoperation remains the default source for the highest-fidelity manipulation data, even as it stays the slowest and most expensive layer to scale.
Why a human driving the real robot produces different data than everything else
Most data sources for robot learning have to solve a translation problem somewhere. Human video shows a hand closing around a mug, but a policy needs to know what joint torques and gripper widths produced that motion on its own hardware, not a human hand's. Simulation generates trajectories cheaply, but transfer depends on how closely the simulated contact physics match the real object.
Teleoperation skips that translation step entirely. The operator is moving the actual robot, through its actual joints, with its actual gripper, so the recorded action is already in the exact space the policy will output at inference. That is also why DROID's comparison of major open manipulation datasets shows that BridgeData, RT-1, and DROID itself were all collected by human teleoperators rather than any other method. When the goal is fidelity to a specific robot, teleoperation is still where most serious programs start.
It isn't free of its own problems. A separate design goal driving recent teleoperation research is viewpoint. Open-TeleVision, a system from UC San Diego and MIT researchers, was built specifically because a fixed third-person or first-person camera view causes real occlusion problems during fine manipulation, making it hard for an operator to see closely enough to place something precisely. Its solution, a stereoscopic view that follows the robot's own head movement, is a reminder that teleoperation fidelity isn't just about the arm. What the operator can actually see matters just as much as what they can move.
Four rig tiers, and what each one actually buys you
Teleoperation hardware spans a wide range of cost, precision, and throughput. Framing it as a set of tiers makes the trade-off explicit: cheaper interfaces move faster per episode but lose precision on dynamic, contact-rich motion, while higher-fidelity rigs are slower and more expensive to run.
Fidelity and throughput move in opposite directions as you climb the tiers. Most programs don't need the top tier for most tasks, but they do need to know which tier their task actually requires.
3D mouse and joystick
The cheapest entry point, controlling the robot's end effector through velocity commands from a six-degree-of-freedom input device. Good for slow, precise positioning tasks and low-cost pilot programs. It struggles with fast or dynamic motion, since velocity control tends to produce stop-start trajectories unless carefully smoothed.
VR headset and controllers
The DROID dataset was collected using a VR headset setup, and it remains a popular middle tier because consumer headsets are inexpensive relative to a dedicated robotics rig. End-effector pose control is strong; finger-level dexterity is weaker without additional hand tracking. Latency and the mismatch between a human's natural workspace and the robot's reachable space are the main things to budget for.
Leader-follower kinematic twins
Systems like ALOHA and GELLO, where the operator moves a smaller kinematically matched "leader" arm that the real robot mirrors joint for joint. This is the tier that produced the ALOHA results above, and it's the strongest option for bimanual work and fast, dexterous motion, because the operator's whole arm movement maps directly onto the robot's. The cost is a leader rig built for every robot model you support, which doesn't transfer across different arms the way a VR headset does.
Haptic and force-feedback rigs
The top of the fidelity range, where the operator feels resistance and contact force through the controller itself, not just sees it on camera. This matters for insertion, polishing, and other tasks where force, not just position, is the skill being demonstrated. It is also the slowest and most expensive tier to build and operate, which is why it tends to get reserved for the specific tasks that actually need force information in the data.
Operator fatigue is a data quality problem, not just an HR one
The hardware tier gets most of the attention in planning conversations, but the person driving it changes the data just as much. A fresh operator's first hour of episodes on a given task tends to be noticeably smoother than their fourth, as small corrective motions, hesitations, and re-aims creep in with fatigue. None of that shows up in a success-rate metric, because the task still gets completed. It shows up later, in a policy that has quietly learned to hesitate the same way its tired operators did.
This is a real operational tension, not a hypothetical one, because longer sessions are also what makes a rig economical to run. The honest answer is that session length has a ceiling before the data degrades faster than the throughput gain is worth, and that ceiling is worth finding deliberately rather than discovering it in a policy evaluation months later. Capping sessions and rotating operators through a task is the simplest lever available, and it costs nothing but a bit of scheduling discipline.
What actually drives the cost, and it usually isn't the robot
Reset time between episodes
On many tabletop tasks, resetting the scene for the next demonstration takes longer than the demonstration itself. Reset time is a real, recurring cost that rarely shows up in a per-hour hardware quote.
Operator qualification
A new operator needs real training time before their episodes are consistent enough to trust. That ramp-up is a cost every time an operator leaves and a replacement starts.
Latency, not just the interface price
Round-trip delay between operator input and robot motion degrades both speed and smoothness. A cheaper interface with poor latency can produce worse data than a pricier one that responds instantly.
Calibration maintenance over time
Cameras and kinematic mappings drift with use. Without a logged baseline at setup, that drift is nearly impossible to catch after the fact, and it degrades data quietly rather than obviously.
The real throughput limit
Operator time, not compute, is what caps how fast teleoperation data accumulates, and that cap is lower than it looks on paper. A 2026 study on contact-rich manipulation data collection measured traditional teleoperation at roughly 112 seconds per demonstration on a dexterous task, a pace that adds up slowly across a working day. That's a meaningfully different economics problem than simulation, where generating another thousand trajectories is a compute decision rather than a staffing one. Research into policy-assisted teleoperation exists specifically to push against this limit, letting one operator oversee multiple robots at once instead of driving each one by hand.
Latency deserves a specific callout here, because it quietly degrades data in a way that's easy to miss on a quick review. When round-trip delay between an operator's input and the robot's motion climbs much past the range where a person stops perceiving the control loop as instantaneous, operators unconsciously adapt by slowing down, pausing to confirm the robot caught up, and overshooting less confidently. A policy trained on that data doesn't just inherit slower motion. It inherits a slightly different, more hesitant strategy than the one the operator would have used with a tighter loop, and that strategy gets attributed to the task rather than to the connection.
Matching the tier to the task
| If your task is... | What you actually need | Start with |
|---|---|---|
| Slow, precise single-arm positioning on a budget | Low cost, acceptable throughput | 3D mouse or joystick |
| Single-arm manipulation across varied scenes | Cheap hardware, easy multi-site deployment | VR headset and controllers |
| Bimanual, fast, or highly dexterous manipulation | The highest joint-space fidelity available | Leader-follower kinematic twins |
| Insertion, polishing, or other force-sensitive contact work | Force information the camera can't capture | Haptic or exoskeleton rigs |
| Validating an approach before committing to a rig | A pilot batch and a baseline training run first | Whatever interface is already on hand |
Where to start if you're scoping a program
The honest first question isn't which interface is objectively best. It's what your task actually needs to see in the data, precision, speed, bimanual coordination, or force, and then choosing the cheapest tier that provides it. Most teams overbuild on tier before they've even confirmed the task is learnable from a small pilot batch.
What matters more than the interface, over the life of a program, is the discipline around it: logged calibration, qualified operators, and a reset protocol that doesn't quietly dominate your cost per episode. The data that comes out of a teleoperation program is only as trustworthy as the structure, labeling, and validation applied to it afterward, which is the deeper subject of robot training data collection and what actually ends up stored inside each recorded episode, covered in robot demonstration data. If you'd rather hand the operational side to a team that already runs calibrated rigs and qualified operators, our teleoperation data collection service is built around exactly this problem.
