Unitree H1 teleoperation: turning the research-paper robot into a production data platform

The Unitree H1 became one of the standard full-size humanoids in academic teleoperation research. Groups mounted headsets, cameras and motion capture on it and published systems that the whole field now builds on. If you own an H1 or are buying one, that history is useful: there is more open code for driving it than for almost any other full-size robot. It is also a trap for companies, because some of that code is licensed for research only, and because the original H1's 4-DoF arms limit what manipulation data it can produce.

H1 or H1-2: the arm decides the data

Unitree sells two bodies under the H1 name, and they are different robots for a teleoperation program.

Every tool on this page treats them as separate robots. In xr_teleoperate they are `H1` (4-DoF arm) and `H1_2` (7-DoF arm); in unitree_rl_gym they are separate tasks. Do not pool data from the two in one dataset.

The teleoperation stacks, and what each is licensed for

This is the section commercial teams skip and regret. Research code on the H1 ranges from permissive open source to explicitly non-commercial, and the license follows the code into your product even if you only used it to collect data.

Whole-body versus upper-body data on the H1

The H1 is where the field argued about this. Most production setups decouple the body: the arms follow the operator through IK, and the legs follow a joystick through a locomotion policy. OmniH2O's authors argue the opposite, that one end-to-end policy controlling both halves gives more stable loco-manipulation, and they released a six-task whole-body dataset (catch and release, squat, rock-paper-scissors, hammer catch, boxing, basket pick-and-place) with RGBD images, motion goals and joint targets at 30 Hz.

For a data program the choice follows the task. Shelf, table and assembly work is upper-body data with a walking command attached, and xr_teleoperate on an H1-2 records it well. Tasks where the legs carry the demonstration, such as squatting to lift or bracing to push, need a whole-body controller and capture of the operator's body, and on the H1 that means either research code under its license terms or your own integration.

From a paper setup to a production pipeline

Research stacks are built to produce a result, not a dataset someone else can train on next year. Open-TeleVision's workflow is typical: recordings land in `data/recordings/`, a post-processing script prepares them, and ACT is trained with the original `imitate_episodes.py`. That is fine for one lab and one paper. A data program needs more structure around the same pieces.

Our data collection guide covers formats and the quality checks that catch bad episodes early.

Latency: the cross-country demo and the real budget

Open-TeleVision's project page shows a cross-country session with robot and operator about 3,000 miles apart. That proves the architecture works over distance. It does not mean every task is pleasant at that distance. Stereo video and hand poses tolerate a long link as long as the robot side runs balance, IK and safety limits locally. What degrades is precision: below about 100 ms round trip, hand-tracked grasping feels direct; past 200 ms operators slow down, overshoot and retry. On a 70 kg H1-2, an overshoot carries real momentum, so speed limits should tighten as delay grows. Our latency guide has the budgets by task.

Hands on the H1

Unitree lists the Dex5-1 and other dexterous hands as options; OmniH2O ran on Inspire hands; xr_teleoperate drives Dex1-1, Dex3-1, Inspire and BrainCo end effectors. On the original H1 a dexterous hand at the end of a 4-DoF arm is often wasted, because the arm cannot present the hand at the angle the task needs. On the H1-2, with three wrist joints, a five-finger hand becomes worthwhile for tool use and in-hand work. For pick and place, a simpler gripper gives operators a consistent technique faster and a higher clean-episode rate.

What a good H1 operator does

H1, H1-2 or H2?

The newer Unitree H2 is listed at $29,900 on Unitree's shop as of October 2026, a fraction of the H1's list price, and xr_teleoperate added it, with 7-DoF arms, in July 2026. The H1 family keeps two advantages: far more published research code (H1 and H1_2 are in unitree_rl_gym; the H2 is not) and years of papers to compare results against. Choose the H1-2 if your team wants to reproduce or extend that research. Choose the H2 for a new data program, and check the support status of each tool you need. Choose the original H1 only for locomotion work.

As of October 2026, foreign-produced advanced robotic devices are on the FCC Covered List under FCC public notice DA 26-786 (July 28, 2026), unless the Department of War grants them a Conditional Approval. The FCC definition covers mobile robots, including humanoids, quadrupeds and autonomous mobile robots, that weigh over 4.4 lb with any base or dock and have a sensor, network connectivity and control software, when they do not qualify as US-made under the federal Buy American test, whatever the nationality of the maker. Covered models cannot receive new FCC equipment authorizations, which most devices need before they can be imported or sold in the US, while the FCC says models it authorized earlier can still be imported, sold and used; US buyers should confirm the current status with the seller.

Takeover and fallback

Many H1s now run learned policies for demos and pilots. The operator who collected the data is the natural fallback: the robot or a monitor flags a stall, an operator takes over through the same stack, finishes the step and hands back, and the takeover becomes a labeled correction episode. Our human-in-the-loop guide covers escalation design.

How RoboPilots runs H1 teleoperation

Your robot stays in your lab. We review your stack and its licenses with you, set up the operator link through a host on your network, and train a dedicated group of operators on your unit and your task protocol, including the safety procedures for a full-size robot. Several humanoid makers have sent us robots to test our operating protocols, and that work is the base each new program builds on.