If you are planning a bimanual manipulation program, ALOHA teleoperation data collection is probably the first setup anyone recommends. It is well documented, the hardware is obtainable, and the data format is familiar to most ML teams.
This guide covers what an ALOHA cell is, what you need to build one, where the money really goes, what each episode should record, and the mistakes that force teams into an expensive re-collection.
What ALOHA is, in one paragraph
ALOHA stands for A Low-cost Open-source Hardware system for bimanual teleoperation. It is a leader-follower rig: the operator holds two small arms, and two larger arms mirror the motion in real time. Because the operator moves the leader arms directly with their hands, the control feels close to natural and the learning curve is short compared with joystick or VR control.
Why the leader-follower principle matters for data
Every joint on the leader arm is an encoder reading. Every joint on the follower is a commanded position. That gives you a clean, dense action label at high rate without any pose estimation or retargeting step. There is no embodiment gap to close because the demonstration was performed on the exact robot you intend to deploy. This is the reason ALOHA-style rigs remain the default for bimanual manipulation programs.
What you need to build one cell
| Component | Purpose | What teams get wrong |
|---|---|---|
| Two leader arms | Operator input device | Undersized gearing makes long sessions exhausting |
| Two follower arms | Executes and records | Payload chosen for the demo task, not the production task |
| Overhead camera | Scene context | Mounted so the operator’s own arms occlude the workspace |
| Two wrist cameras | Contact and grasp detail | Left off to save bandwidth, then missed later |
| Front camera | Depth cue and object approach | Placed where it drifts between sessions |
| Workstation and storage | Sync, buffer, write | Disk throughput becomes the real frame-rate limit |
| Fixture and task set | Repeatable scene layout | Too repeatable, producing a memorizing model |
Hardware is the part everyone budgets for. It is rarely the part that decides whether the program works.
Where the money actually goes
Teams ask what a cell costs. The more useful question is what a usable trajectory costs, because hardware is a one-time line and everything below repeats every week.
| Cost line | Type | Notes |
|---|---|---|
| Arms, cameras, workstation | One-time | Amortizes fast at volume; usually a minority of year-one spend |
| Operator hours | Recurring | The dominant line by a wide margin |
| Scene reset labor | Recurring | Frequently forgotten; on some tasks it exceeds demonstration time |
| QA and review | Recurring | Scales with volume unless automated at collection time |
| Annotation | Recurring | Segment boundaries and success labels; see annotation and labeling |
| Downtime and maintenance | Recurring | Servo wear on high-duty cells is real and under-modeled |
| Storage and egress | Recurring | Multi-camera capture grows faster than most forecasts |
Our breakdown of the build versus buy decision works through the same lines against an outsourced program.
What the cell produces per episode
- Leader joint positions at high rate, which become your action labels
- Follower joint positions and velocities, which become your proprioceptive state
- Three to four synchronized camera streams
- Gripper open and close commands, usually continuous rather than binary
- Episode metadata: operator ID, task variant, object set, success flag, retry count
If your recorder writes anything less than this, expect to re-collect. The metadata in particular is what lets you diagnose a bad batch six weeks later instead of discarding it.
Seven mistakes that cost teams a re-collection
- No per-session calibration. Cameras shift. Without a calibration pass at session start, drift becomes invisible systematic error.
- Recording only successes. Failure and recovery episodes are how a policy learns to get unstuck.
- One operator, one style. A dataset that encodes one person’s habits produces a policy that only works when the world matches those habits.
- Fixed object placement. Vary position, orientation, instance, and lighting deliberately. This is the discipline behind long-tail capture.
- Ignoring gripper force. Position-only logging hides crushed and dropped objects. Contact-rich tasks need force-torque data.
- Sessions that run too long. Demonstration quality degrades with fatigue well before the operator notices.
- QA at the end of the week. By then you have five days of a repeated defect. Validate at collection time.
When ALOHA is the wrong tool
A leader-follower rig is excellent for tabletop bimanual work. It is a poor fit in three situations.
Whole-body and mobile tasks
If the task involves walking, crouching, or moving between rooms, a fixed cell cannot capture it. Headset-driven control on a mobile platform handles this better, as covered in our piece on VR headset teleoperation for everyday tasks.
Very high throughput on simple tasks
When the motion is simple and the requirement is volume, wearable human capture produces more demonstrations per hour because it is not gated by robot hardware.
Budget-constrained early exploration
If you are still deciding which tasks matter, a lighter puppeteering rig is a cheaper way to find out. See our comparison of GELLO and ALOHA.
On the outcome side of a bimanual programme, our humanoid foundation model case study reports a 3x sample-efficiency result.
Frequently asked questions
How many ALOHA cells do I need?
Work backwards from trajectories per week, minus scene reset time, minus realistic operator utilization. Most teams overestimate utilization by a wide margin on their first plan.
Can one operator run two cells?
Not simultaneously with quality. Some programs alternate an operator between two cells while a technician resets the other, which raises utilization without splitting attention.
Does ALOHA data transfer to a different robot?
Partially. Visual and task-structure learning transfers reasonably. Joint-space actions do not transfer directly and need retargeting, which is the core problem in cross-embodiment data.
Should we build in-house or use a partner?
Building makes sense when the task set is stable and volume is steady. A dedicated team makes sense when you need to scale before you have finished learning what to collect.
An ALOHA cell is easy to buy and hard to run well. The difference between a rig producing 200 usable trajectories a week and one producing 800 is almost entirely operational. If you are standing up a bimanual program and want the operating model reviewed before you order hardware, tell us what you are building.
