Unitree G1 Humanoid¶

Introduction¶

The Unitree G1 is a full-size bipedal humanoid research platform from Unitree Robotics, the same manufacturer as the lab's Go1 quadrupeds. Where the Go1 is used for legged locomotion and mobile-base HRI work, the G1 is intended for research that needs a humanoid form factor: bipedal locomotion and balance, whole-body manipulation, dexterous hand control, and HRI studies where a human-like body plan, gaze, and gesture channel matter (proxemics, handover tasks, social navigation, teleoperation studies).

The G1 ships in several configurations (Standard, EDU, EDU Ultimate) that differ mainly in waist degrees of freedom, dexterous hand options, and onboard compute. Check the packing list and invoice for the lab's unit against the specs below and correct this page once confirmed.

Because the G1 walks, balances, and has a much larger reachable workspace around people than the lab's existing platforms, read the Safety section below before anyone powers it on, even if you are already checked out on the Go1 or the KUKA arm.

Specifications¶

Values below are from Unitree's public specification sheets and third-party listings for the G1 EDU line; treat them as provisional until verified against the lab's actual unit and its included manual.

Spec	Value	Notes
Height (standing / folded)	approx. 1.32 m / 0.69 m	Folds down for transport/storage
Weight	approx. 35 kg with battery	Varies slightly by configuration
Degrees of freedom	23 (Standard) up to 43 (EDU Ultimate)	6 DOF/leg, 5-7 DOF/arm, 1-3 DOF waist, optional 7-DOF Dex3-1 hands add more
Actuators	Low-inertia, high-speed internal-rotor PMSM motors, crossed-roller bearings at joints	Knee joint peak torque approx. 90-120 N·m depending on configuration
Battery	13S Li-ion, 9,000 mAh, hot-swappable	Approx. 2 hours typical runtime; 54 V / 5 A charger
Onboard compute	8-core CPU; EDU/Ultimate variants add an NVIDIA Jetson Orin module	Sufficient for onboard perception/RL policies; heavier training still done off-board
Sensors	Depth camera, 3D LiDAR, 4-mic array, speaker, IMU, joint encoders	Exact sensor suite depends on configuration
Connectivity	Wi-Fi 6, Bluetooth 5.2, wired Ethernet	Use wired Ethernet for low-latency control, same as Go1
Manipulation payload	approx. 2-3 kg per arm	Dex3-1 three-fingered hand optional
Control interfaces	Wireless controller, `unitree_sdk2` (C++), `unitree_sdk2_python`, partial ROS 2 support	See Getting Started below

Sources: Unitree G1 product page, RoboStore — G1 EDU Ultimate technical specifications, QVIRO — Unitree G1 specifications.

Getting Started¶

The G1 uses the same general Unitree SDK ecosystem as the Go1, but publishes and subscribes on a different message namespace (unitree_hg for the humanoid line, versus unitree_go for Go1/Go2). Do not assume Go1 example code ports over unmodified.

Network setup¶

Connect over wired Ethernet, same pattern as the Go1. Set your machine's IP to the 192.168.123.x subnet the robot expects, on the interface connected to the robot:

sudo ip addr add 192.168.123.99/24 dev <your-ethernet-interface>
ping 192.168.123.161   # adjust to the G1's documented IP if different

Install the C++ SDK (`unitree_sdk2`)¶

git clone https://github.com/unitreerobotics/unitree_sdk2.git
cd unitree_sdk2
mkdir build && cd build
cmake ..
make

Repo: github.com/unitreerobotics/unitree_sdk2. Official developer docs: support.unitree.com/home/en/developer.

Install the Python SDK (`unitree_sdk2_python`)¶

sudo apt install python3-pip
git clone https://github.com/unitreerobotics/unitree_sdk2_python.git
cd unitree_sdk2_python
pip3 install -e .

This pulls in CycloneDDS, numpy, and opencv-python. If the CycloneDDS install fails, build it from source, export CYCLONEDDS_HOME=<install path>, then retry. Repo: github.com/unitreerobotics/unitree_sdk2_python.

ROS 2¶

Unitree's ROS 2 bridge is github.com/unitreerobotics/unitree_ros2, built primarily around Go2/B2/H1; G1 support shows up mainly as example nodes rather than a fully first-class integration. Confirm current support level before planning a project around it. Tested distros are Ubuntu 20.04/ROS 2 Foxy and Ubuntu 22.04/ROS 2 Humble (Humble recommended), using CycloneDDS as the RMW implementation. For direct control without ROS 2, the Python or C++ SDK talking DDS directly to the robot is the more mature path today.

Simulation¶

Unitree provides a MuJoCo-based simulator, unitree_mujoco, useful for testing control code before touching the physical robot. Prefer sim-testing new control code before running it on the physical unit, the same policy as with the Go1.

Wireless controller basics¶

L2 + UP — Ready mode (motors engage, robot prepares to stand; approx. 5 s)
L2 + Y — Zero-torque mode (motors go passive, no damping)
L2 + B — Damping mode, the closest thing the G1 has to a manual "kill" input; the robot stops active motion and controlled-falls or settles to the ground rather than holding posture. Every operator must know this before power-on.

See the Unitree G1 controls reference (community-maintained) and the manufacturer's manual for the full control map.

Troubleshooting¶

Can't reach the robot over Ethernet: confirm your host IP is on the 192.168.123.x subnet and the interface is up; confirm you're using the interface name the SDK examples expect; a stale ARP/DDS discovery cache after a reboot can hide the robot, try ip neigh flush all or re-plug the cable.

CycloneDDS fails to build/install: build CycloneDDS from source, export CYCLONEDDS_HOME=<install path>, then retry pip3 install -e ..

Robot won't leave damping mode or won't stand: confirm it's actually in Ready mode (L2 + UP) before commanding motion; check battery charge, since low battery can prevent the stand-up sequence.

Example code references unitree_go messages and doesn't work on the G1: the G1 (and H1) use the unitree_hg namespace, not unitree_go (used by Go1/Go2). Use the g1/ examples, not the quadruped ones.

ROS 2 topics/services for G1 missing or incomplete: unitree_ros2 is developed primarily against Go2/B2/H1; fall back to the native SDK for anything the ROS 2 wrapper doesn't yet expose.

(Expand this section with lab-specific gotchas as they come up.)

Safety¶

The G1 is not the Go1, and it is not the KUKA arm; treat it as its own risk category. A bipedal humanoid introduces failure modes the lab's existing platforms do not have:

Balance/fall risk. At roughly 1.3 m and 35 kg, a fall is a real impact and drop-object hazard to the robot and to anything or anyone nearby.
Larger, less predictable range of motion, with up to 43 DOF including a mobile waist and dexterous hands, compared to the KUKA arm's fixed, well-characterized workspace or the Go1's low-slung legs.
It can walk toward people. A bipedal platform executing an autonomous or teleoperated locomotion policy can approach a person unexpectedly, including a bystander who is not the operator. Maintain a clear, deliberately enforced perimeter during any walking trial.
No dedicated hardware e-stop button on the robot itself. Per NVIDIA's G1 safety guidance for the Isaac GR00T workflow, the practical equivalents are L2 + B on the wireless controller to force damping mode, and killing power or network connectivity as a last resort. This is materially weaker than a physical e-stop and must be planned around explicitly.

Required practice for the lab, adapting the same discipline already used for the KUKA arm:

Never operate the G1 alone; a minimum of two people, one operating and one solely responsible for safety and observation, ready to trigger a stop.
Every person in the room should know L2 + B (damping/controlled fall), where the power button is, and where the network disconnect is, briefed at the start of every session.
Keep bystanders outside the robot's reach, drawn generously to cover its stride and arm reach, and re-drawn per task since the G1 is mobile.
Clear the workspace of obstacles, loose cables, and trip/impact hazards before any locomotion trial.
Test new control code in unitree_mujoco before running it on the physical unit.
Start slow: run new policies at reduced speed or limited motion range first, with the safety operator ready to trigger damping mode at the first sign of unexpected behaviour. Do not attempt to physically restrain the robot if it misbehaves; stop it, do not wrestle it.
Log any fall, near-miss, or unexpected behaviour the same way arm incidents are logged.

These are a starting point based on public manufacturer and partner documentation, not a substitute for a lab-specific risk assessment.

Migration note: this page was newly authored from public Unitree Robotics manufacturer documentation and related third-party sources, not migrated from prior lab material, since the lab acquired the G1 after the original wiki migration. Specs and setup steps should be verified and expanded by lab members against the actual unit and any manual shipped with it. The Safety section in particular must be reviewed and finalized by Prof. Pan before anyone operates the G1, including confirming the operator/observer protocol, the perimeter size, and the stop procedure against the specific unit and lab space.