Imitation learning is a workflow problem as much as a hardware problem. A team needs repeatable demonstrations, synchronized observations and a way to evaluate a policy without quietly changing the task. Start with one controlled tabletop behavior, such as placing a known object into a tray, rather than promising general-purpose household autonomy.
Choose one task and one success definition
Write down the initial object positions, permitted variation, success condition and timeout. Separate training objects from evaluation objects. Count interventions and resets alongside successful trials. If a human corrects the robot during evaluation, record that correction rather than treating the attempt as fully autonomous.
Design the recording loop first
Choose camera views that show both the object and the end effector throughout the motion. Check timestamp alignment, dropped frames, units, action conventions and calibration. Save unsuccessful demonstrations separately instead of silently mixing them into the training set. Confirm that the chosen hardware driver is supported by the exact software version you will run.
Keep the first deployment narrow
Replay a short recording safely before training a large policy. Test offline data loading and a small training run, then perform supervised evaluation in a constrained workspace. An installation guide or model release does not establish safe real-world deployment. Use the same task setup when comparing policies and retain a simple baseline.
Budget for data quality, not just robot count
Include operator time, storage, annotation, maintenance and repeated calibration in the project budget. Scale the number of demonstrations only after you can explain failures in a small dataset. A second robot introduces calibration and embodiment differences; validate that transfer before assuming that more hardware will produce a better policy.
Resource shortlist
Ordered by workflow, not by measured performance. These are editorial starting points. Follow each directory entry to its official documentation and confirm the exact configuration before purchasing.
SO-101 →
A tabletop arm starting point for a small teleoperation and imitation-learning project.
Check before committing: Assembly, calibration and whether your exact hardware revision is supported by the intended driver.
ALOHA →
A bimanual option when the task actually needs coordinated two-arm demonstrations.
Check before committing: The original project is a research reference. Trossen reports its legacy ALOHA hardware line is end-of-life; distinguish a reproduced research build from current Trossen AI products and confirm parts/support.
Universal Manipulation Interface →
An alternative demonstration-collection approach to investigate when handheld collection fits the task.
Check before committing: Required camera and tracking setup, calibration assumptions and how demonstrations map to a deployment robot.
LeRobot →
A software resource for organizing robot datasets and learning workflows.
Check before committing: Supported robot drivers, dataset format, policy dependencies and reproducible environment versions.
MuJoCo →
A simulation resource for testing controlled behaviors before hardware trials.
Check before committing: Model fidelity, actuator assumptions and which failure modes simulation will not reproduce.
Turn the shortlist into a decision
Write down the task, operating conditions, success criteria and total ownership costs. Ask shortlisted suppliers to demonstrate your representative task, including failure recovery. Use the same acceptance test for each candidate.
Explore the full robotics directory →