Unitree G1 is where a lot of teams' first humanoid data collection program runs into a category error: it looks like "an arm, but with legs," and the control problem is not that. A G1 configuration ranges from 23 body degrees of freedom in the standard unit to 29 or more in EDU variants, before you even add hand DoF, and every one of those joints is coupled through a balance controller that has to keep the robot standing while a human is asking it to do something else. Collecting clean manipulation data on a humanoid means designing around that coupling, not around it.
The upside is that G1 is comparatively accessible as humanoids go — Unitree publishes an open SDK, a documented ROS 2 path, and (through the EDU line) low-level joint control, which is why it shows up across a wide range of open humanoid manipulation research rather than staying locked inside one lab's custom stack.
Control interfaces that matter for data collection
G1's control stack is built on unitree_sdk2 (C++) and unitree_sdk2_python, communicating over Cyclone DDS as the transport. Because Cyclone DDS is also an officially supported ROS 2 middleware implementation, Unitree's unitree_ros2 package does not need to wrap the SDK in a translation layer — ROS 2 messages can talk to the robot's native DDS topics directly, which keeps the ROS integration close to native SDK performance rather than paying a bridging tax.
DoF varies meaningfully by configuration, and getting this wrong is the fastest way to misdescribe a dataset:
- Standard G1
- 23 body DoF (6/leg, waist, 5/arm)
- EDU (extended)
- ~29 body DoF (6/leg, 3-DoF waist, 7/arm)
- Dex3-1 hand
- 3-finger, force-position hybrid control, per EDU arm
- Low-level access
- Full joint control on EDU configurations
The EDU line is the one that matters for serious data collection: it is the configuration that unlocks full low-level joint control rather than the higher-level motion commands the standard unit exposes, and it is the one third-party retargeting and teleoperation stacks — including Unitree's own open-source xr_teleoperate project and NVIDIA Isaac Lab's G1 teleoperation support — target.
Teleoperation options
Arm-only leader-follower puppeteering does not transfer cleanly to a humanoid, because there is no equivalent leader for the legs and waist that keep the robot balanced — a human cannot backdrive a robot's balance controller the way they backdrive a WidowX leader arm. The realistic options all route through some form of whole-body retargeting:
- VR headset or hand-tracking teleoperation, where wrist and finger keypoints (from something like an Apple Vision Pro or similar tracker) are retargeted onto the robot's hand joints, and wrist poses are converted into upper-body joint commands through inverse kinematics — Unitree's own
xr_teleoperateproject is the reference open-source implementation of this pattern. - Motion-capture-driven whole-body control, where a human's full-body motion is retargeted onto a humanoid reference trajectory that a learned or model-based whole-body controller then tracks, keeping balance as a first-class constraint rather than an afterthought.
- Simulation-in-the-loop retargeting, as in NVIDIA Isaac Lab's teleoperation support for G1, which includes dexterous retargeting for both Unitree's own three-finger hand and third-party five-finger options, letting teams validate a retargeting pipeline before it ever touches the physical robot.
In every case, a balance controller stays in the loop underneath the operator's input. The operator is not driving raw joint targets; they are driving a whole-body reference that the robot's own controller reconciles against staying upright. This is the load-bearing fact that distinguishes humanoid teleoperation from arm teleoperation, and it is worth stating plainly because it is easy to miss coming from arm-only experience.
What a clean dataset looks like on this platform
Humanoid demonstration data needs everything an arm dataset needs — synchronized joint state, action, and camera streams — plus signals an arm never has to record: base/torso pose and, if the balance controller exposes it, contact or ground-reaction-force state, because "how the robot stayed upright while doing the task" is part of what a whole-body policy has to learn.
LeRobot has native support for the G1 as hardware, and Unitree's own unitree_lerobot project adapts the LeRobot framework specifically for data collected with G1's dual-arm dexterous hands; public dataset examples on the Hugging Face Hub (from the unitreerobotics org) follow the standard LeRobot shape — synchronized MP4 per camera, Parquet for state and action — with observation.state fields named per joint (shoulder pitch, roll, yaw, elbow, wrist, and so on per arm).
# Representative shape of a G1 LeRobot recording session — verify exact
# flags against your unitree_lerobot / lerobot version before running.
lerobot-record \
--robot.type=unitree_g1 \
--robot.cameras='{"head": {"type": "opencv", "index_or_path": 0, "fps": 30}}' \
--dataset.repo_id=your-org/g1-pick-place \
--dataset.num_episodes=50 \
--dataset.single_task="Pick up the bottle and place it in the bin"Common pitfalls
Treating G1 like a bimanual arm rig with a mobile base bolted on. The balance controller changes the nature of the control problem; whole-body retargeting pipelines and arm-only leader-follower pipelines are not interchangeable, and porting an ALOHA-style workflow onto a humanoid without redesigning the teleoperation interface will not work. It is a different problem even from a legged mobile-manipulation platform like Boston Dynamics Spot: Spot's onboard controller keeps a four-legged base balanced under a body that stays level while an arm reaches from it, but that base never has to solve bipedal balance the way G1's whole-body controller does while it walks and manipulates at the same time.
Not verifying which DoF configuration a dataset or paper used. "G1" alone underspecifies the robot — 23-DoF standard, ~29-DoF EDU, with or without Dex3-1 hands are meaningfully different action spaces. State the exact configuration in your own dataset's metadata.
Underestimating the ROS 2 learning curve despite Cyclone DDS compatibility. Native DDS compatibility means ROS 2 messages can reach the robot without a bridge, but it does not mean the whole-body control stack — balance, retargeting, safety limits — is exposed as simple ROS 2 topics out of the box; expect real integration work beyond "point rclpy at the robot."
Skipping teleoperation safety review for a machine that can fall over. A humanoid failure mode includes the robot losing balance, which is a materially different safety envelope than a stationary arm's — review stop conditions and physical clearance specifically for whole-body motion, not just end-effector motion.
If G1 is one platform in a broader program that also includes arms or mobile bases, the underlying discipline — one clock across every signal, explicit configuration metadata, reviewed rather than auto-discarded edge cases — is exactly what bring your own rig is designed to keep consistent across very different hardware, humanoid included.