ALOHA and UMI Data Collection for Enterprise Teams: Platform Specs, Data Formats, and Managed Programs (2026)

ALOHA (A Low-cost Open-source Hardware System for Bimanual Teleoperation) was released by Stanford in 2023 and has since been adopted by more enterprise robotics teams and academic labs than any other bimanual teleoperation platform. The combination of low hardware cost relative to industrial alternatives, open-source software stack, and direct compatibility with the ACT policy architecture from Stanford made ALOHA the default platform for imitation learning research.

UMI (Universal Manipulation Interface) solves a different problem: it allows demonstration data to be collected using standard robot grippers with wrist-mounted cameras, without requiring a full bilateral leader-follower system. UMI programs collect demonstration data by having a human hold and manipulate the gripper directly, capturing egocentric wrist video and end-effector trajectory. The data is collected in human-operated mode and retargeted to robot execution.

The practical result is that most enterprise teams starting a new imitation learning program are choosing between ALOHA-style collection (higher setup cost, higher data quality for bimanual tasks), UMI collection (lower setup cost, faster deployment, lower data quality for contact-sensitive tasks), or a combination of both for different task families within the same program.

Understanding the specific data requirements, format specifications, and quality standards for each platform is essential for enterprise teams evaluating managed collection programs. Vendors who cannot speak to platform-specific data formats, synchronization requirements, and format compatibility with downstream training pipelines are unlikely to deliver production-ready data.

The ALOHA system consists of two leader arms (operated by a human demonstrator) and two follower arms (ViperX 300s or equivalent) that mirror the leader arm motions. The follower arms execute the actual task while recording joint states, end-effector poses, and wrist camera feeds synchronized at the hardware level.

Hardware requirements for a production-scale ALOHA collection facility: four robot arms (two leader, two follower) with precision encoders that achieve < 0.5mm repeatability, hardware synchronization trigger across all arms and cameras operating at 50Hz joint state sampling and 30fps video, two wrist-mounted cameras (one per follower arm) at minimum 720p resolution with global shutter to eliminate motion blur during fast movements, and one overhead scene camera at minimum 1080p/30fps.

The ALOHA data format for ACT (Action Chunking with Transformers) training stores demonstrations in HDF5 files with the following structure: joint position arrays at 50Hz, task completion flag, episode metadata (operator ID, date, environment configuration), and synchronized camera frames. Programs delivering for pi0 or OpenVLA training should use RLDS (Reinforcement Learning Datasets) format with the corresponding data schema.

Operator requirements for ALOHA programs: operators must complete a minimum 10-hour training period on the leader-follower interface before qualifying for production data collection. Initial training produces demonstrations with high variance and systematic operator-specific artifacts. Qualified operators should achieve a demonstration acceptance rate above 80% for standard tasks before being approved for production programs.

Episode length for ALOHA programs should be specified in advance: episodes that are too short (< 30 seconds for multi-step tasks) may indicate incomplete task execution, while episodes that are too long (> 5 minutes for tasks expected to complete in 2 minutes) indicate operator difficulty that will produce low-quality demonstrations. QA should flag episodes outside the expected duration range for human review.

UMI uses a handheld gripper with wrist-mounted cameras that a human operator holds and moves through the target task. The operator is not controlling a robot - they are performing the task directly with the UMI gripper, while the system records wrist camera video and end-effector trajectory. The recorded data is then used to train robot policies, with the assumption that the robot's wrist camera view during deployment matches the UMI wrist camera view during data collection.

The UMI hardware configuration requires: a gripper with a GoPro or equivalent wrist-mounted camera in a specific mounting configuration that matches the deployment robot's wrist camera position, mirror-mounted cameras on both sides of the gripper to provide binocular depth cues, and an IMU for end-effector trajectory recording. The camera configuration must be held constant across all operators in a program for viewpoint consistency.

UMI data format uses RLDS with end-effector pose (6-DOF position and orientation) rather than joint positions as the action representation. This makes UMI data retargetable to different robot platforms with different kinematic configurations, as long as their end-effectors can follow the recorded Cartesian trajectory. Programs delivering for Diffusion Policy training should verify that the action representation and normalization match the Diffusion Policy data pipeline expectations.

UMI programs are faster to deploy than ALOHA programs because setup requires only the handheld gripper, not four robot arms. Operator training is also shorter - operators can perform tasks with the UMI gripper within 2-4 hours rather than the 10+ hours required for ALOHA leader-follower operation. The trade-off is lower fidelity for bimanual tasks (UMI is inherently single-arm) and retargeting error that grows for tasks requiring precise contact geometry.

Teams training pi0, OpenVLA, or Octo models may have specific hardware requirements that differ from standard ALOHA or UMI configurations. Pi0 in particular has been trained on data from a diverse hardware fleet including Mobile ALOHA, custom manipulation platforms, and specialized end-effectors - and fine-tuning on custom data requires matching the data format and sensor configuration of the pre-training data.

Pi0 data requirements: multi-camera RGB at 30fps (minimum two cameras - overhead and wrist), end-effector state (7-DOF for standard arm configurations: 6 joint angles + gripper width), language instruction strings per episode, and RLDS format with the specific pi0 data schema. Programs delivering for pi0 fine-tuning should confirm that the collection platform's camera configuration can produce data in the pi0 RLDS schema before beginning collection.

OpenVLA data requirements: action representation as 7-DOF delta actions (change in end-effector position, orientation, and gripper state), images from a single wrist camera or multiple cameras depending on the specific OpenVLA checkpoint being fine-tuned, and RLDS format. OpenVLA fine-tuning is more sensitive to action normalization than pi0 - incorrect action normalization produces policies that fail immediately at deployment despite passing offline evaluation metrics.

Octo data requirements: flexible camera configuration (1-3 cameras supported), proprioceptive state, language task description, and RLDS format. Octo is the most flexible of the three models on data format but requires that the task language descriptions match the distribution of descriptions used in Octo pre-training. Programs delivering for Octo fine-tuning should verify task description format against the Octo training data schema.

Enterprise teams outsourcing ALOHA or UMI collection to a managed vendor should verify six things before signing a contract.

First: does the vendor own the specific hardware version that matches your downstream training pipeline? ALOHA v2 hardware has different joint specifications from ALOHA v1, and data collected on one version may not be directly compatible with policies trained on the other. Ask to see the specific hardware serial numbers and firmware versions.

Second: what is the vendor's demonstrated episode acceptance rate for programs comparable to yours? Ask for QA reports from previous programs showing episode count, rejection rate, and rejection reasons. A vendor who cannot provide this data has not run production-scale programs with rigorous QA.

Third: how are operators trained and qualified? Ask for the operator certification protocol: minimum training hours, qualification test design, ongoing quality monitoring during production. Operators who are certified once and never reviewed will drift in quality over long programs.

Fourth: what is the data pipeline from collection to delivery? Ask to see a sample episode in the delivery format before collection begins. Format mismatches discovered after a 5,000-episode program has completed are expensive to correct.

Fifth: how are hardware failures handled? ALOHA arms have well-documented failure modes (encoder drift, joint lockups, cable routing failures). Ask what the backup hardware plan is and what happens to the day's collection if hardware fails mid-session.

Sixth: what are the program milestones and delivery schedule? A vendor who cannot commit to specific milestones with episode counts and dates is unlikely to reliably produce a large-scale dataset on schedule.