Unitree G1: Known Problems & Fixes

Leg/hip/ankle motors overheat and force a shutdown

Overheating under third-party controllers is usually a gain-tuning problem; lower Kp/Kd or use the stock controller before suspecting the actuator.

Symptom

Ankle-roll motors reach ~90°C within 5-10 min even near-idle; the left hip joint overheats after ~30 min of teleoperation and triggers an automatic system shutdown.

Affected

Reported under third-party whole-body controllers (NVIDIA GEAR-SONIC / Isaac-GR00T N1.7 on Jetson Orin NX). Unitree's stock controller keeps ankles at 30-45°C.

Fix / Workaround

Overheating is tied to aggressive controller gains, not always a hardware fault. Reduce Kp/Kd gains, adjust standing posture to lower static load, and prefer Unitree's stock controller for extended runs. If temps spike on the stock controller too, stop use and inspect — a genuinely failing actuator needs service.

Shoulder/arm motor overheats and goes limp with Inspire dexterous hand

No vendor fix; treat it as a payload-compensation and gain-tuning problem for the added hand mass before assuming hardware failure.

Symptom

The shoulder-pitch arm motor overheats after short operation and the arm loses responsiveness when paired with the Inspire FTP dexterous hand.

Affected

G1 ARM7 + Inspire FTP hand, ROS2 Humble; users running PD gains kp=40 / kd=1.5.

Fix / Workaround

No vendor fix documented. Community direction: the arm needs gravity/payload compensation for the added hand mass and lower torque limits; owners are still seeking Unitree's recommended PD gains for this pairing. Treat as a tuning problem before assuming hardware failure.

Robot ignores SDK commands (stuck in damp / develop mode)

Press L1+A then L1+UP on the remote to leave damp mode before sending SDK commands, and don't stay in develop mode.

Symptom

G1 boots into 'damp mode' and ignores SDK commands; entering 'develop mode' also disables SDK responsiveness, so users conclude the SDK is broken.

Affected

General G1 firmware behavior.

Fix / Workaround

Activate the robot with the remote before sending SDK commands: press L1+A, then L1+UP to leave damp mode. Do not sit in develop mode if you need SDK control. If you entered develop mode, renew the ai-sport client via the app.

WaveHand / ShakeHand fail from SDK (error 3203 'API not implemented')

Update firmware to v1.3.0 or later and activate the robot out of damp mode first.

Symptom

WaveHand and ShakeHand arm actions work from the remote but fail from Python/C++/ROS2; ROS2 returns error 3203 'API not implemented on server'.

Affected

Firmware before v1.3.0.

Fix / Workaround

Update robot firmware to v1.3.0 or later. Also make sure the robot is activated out of damp mode (L1+A, L1+UP) before issuing the commands.

Code and official examples break after firmware 1.4.0 ('ClientStub send request error')

No vendor fix; check activation and that the SDK version matches the firmware, and note that some users rolled back from 1.4.0.

Symptom

Previously working Python code and official SDK examples stop working after updating to firmware 1.4.0; repeated '[ClientStub] send request error'. Related: GetVolume returns error 3102, high-level/audio examples fail.

Affected

Firmware 1.4.0.

Fix / Workaround

No vendor fix documented. Confirm the robot is activated (out of damp mode), verify the SDK version matches the firmware, and if you upgraded specifically for a feature, be aware some users rolled back. Watch Unitree release notes for a follow-up patch.

Inspire hand won't open serial port / is unreachable at its IP

Serial and FTP Inspire hands use different control methods; match the code to your variant and confirm the hand answers on 192.168.123.x.

Symptom

'Open Serial port /dev/ttyUSB0 failed' — the Inspire hand can't be controlled; or the FTP hand is unreachable at 192.168.123.211.

Affected

G1 with Inspire hand (DFX serial vs FTP modbus-TCP variants).

Fix / Workaround

The control method depends on the hand variant. FTP Inspire hands use Modbus TCP, not a serial port — using serial code on an FTP hand fails by design. Confirm which variant you have and use the matching control method; verify the hand's IP is reachable on the 192.168.123.x network.

Dex3-1 hand thumb barely moves during teleoperation

No fix documented; hardware self-checks pass, so report the driver version to Unitree as a teleop-to-driver mapping mismatch.

Symptom

In teleop the thumb only makes 3-4° micro-movements versus full range in simulation; thumb-to-index pinch bottoms out at ~5cm, too coarse for fine manipulation.

Affected

G1 software V1.4.7 + Dex3-1 hand.

Fix / Workaround

No fix documented. Power-up self-check shows joints normal and simulation works, which points to a command-mapping mismatch between teleop and the hand driver rather than hardware. Report the driver version to Unitree.

Teleoperation latency grows to ~2.5s after 1-2 hours

No fix documented; the network is not the cause, so restart the teleop stack between long sessions.

Symptom

Arm and camera latency climbs to ~2.5s after prolonged teleop; arm prep pose takes ~4s instead of ~2s, eventually appearing immediately on startup.

Affected

xr_teleoperate v1.3 and v1.5.

Fix / Workaround

No fix documented. Upgrading to a gigabit router and WiFi 6 did not help, and simulation mode is unaffected — suggesting an onboard buffering/accumulation issue rather than the network. Restart the teleop stack between long sessions as a stopgap.

Policy deployment over WiFi hangs on 'Waiting for connection rt/lowstate'

Use a wired connection and pass the interface name explicitly; DDS multicast is unreliable over Wi-Fi.

Symptom

Deploying over WiFi hangs on 'Waiting for connection rt/lowstate' even though SSH to the robot works; wired ethernet works fine.

Affected

G1, DDS-based control.

Fix / Workaround

Use a wired connection and specify the interface, e.g. ./g1_ctrl --network enx701988512412. DDS multicast for lowstate does not traverse the wireless interface reliably.

CycloneDDS version mismatch crashes G1 sim init

Don't source the ROS setup script alongside unitree_sdk2, or pin CycloneDDS to one matching version.

Symptom

DDS assertion failure / CycloneDDS writer error when initializing the G1 simulation; it won't start.

Affected

Ubuntu 22.04, ROS2 Humble; system CycloneDDS 0.10.5 vs Python CycloneDDS 0.10.2.

Fix / Workaround

Don't source the ROS setup script (its DDS libs differ from unitree_sdk2's). Verify which .so is linked at compile time. Alternatives: build CycloneDDS 0.10.2 from source, patch unitree-sdk2py for 0.10.5, or develop on Ubuntu 20.04.

'Unmatched robot type' on Ethernet connect (23 vs 29 DOF)

Set the controller's DOF config to match the robot and rebuild unitree_sdk2 cleanly to remove conflicting installs.

Symptom

The controller connects over Ethernet then immediately fails with 'Unmatched robot type' during sim-to-real deployment.

Affected

G1 23-DOF and 29-DOF variants (incl. locked-waist/dummy-hands configs).

Fix / Workaround

The robot's DOF/config must match the controller's expected type. Set the correct DOF in your config, and check for conflicting SDK installs in /usr/local vs your project path — rebuilding unitree_sdk2 cleanly (deploy build with -DBUILD_EXAMPLES=OFF, sim build with a separate CMAKE_INSTALL_PREFIX) resolves the related unresponsive-velocity-mode case.

Moving arms via SDK while walking destabilizes balance

No fix documented; avoid large arm motions while walking until a firmware update resolves the controller conflict.

Symptom

Controlling the arms via SDK while walking (gamepad) makes the robot bend forward or lose balance; raising arms while walking produces an unstable, heavy gait.

Affected

G1 with 3-DOF waist.

Fix / Workaround

No fix documented. Zeroing waist axes, holding initial values, and leaving them untouched were all tried without success — the arm SDK controller and the locomotion balance controller conflict. Avoid large arm motions during locomotion until a firmware update addresses it.

Simulated G1 collapses with no default stabilization

Enable the elastic band in unitree_mujoco's config; the factory balance controller isn't available in sim.

Symptom

In MuJoCo simulation the G1 has no default stabilization and falls over when run without controls.

Affected

unitree_mujoco.

Fix / Workaround

Enable the elastic band: set enable_elastic_band: 1 in unitree_mujoco/simulate/config.yaml (or ENABLE_ELASTIC_BAND=True). Note the factory motion controller isn't available in sim, and the band can be awkward to disable when switching to joystick control.

Short battery runtime (~2 hours)

Not a fault: budget about two hours of active use and keep charged spare packs.

Symptom

The 9,000 mAh battery gives only about 2 hours per charge, and drains faster under dynamic movement.

Affected

Base model, 9,000 mAh pack.

Fix / Workaround

This is a capacity limitation, not a fault. Keep charged spare batteries for hot-swapping between sessions; budget runtime around ~2 hours of active use.

Base G1 can't be programmed — no SDK

Not a fault: SDK access requires the G1 EDU tier, so confirm the tier before buying if you intend to develop.

Symptom

Buyers of the ~$13,500 base G1 discover it's a demo/showcase unit with no SDK and cannot be programmed.

Affected

G1 base (23 DOF) vs G1 EDU (up to 43 DOF).

Fix / Workaround

This is a product-tier limitation. SDK access, higher torque, and more DOF require the G1 EDU / developer platform (~$44k-$74k). Confirm the tier before purchase if you intend to develop.

Solid red LED / physical fault checklist (falls, cables, battery)

Inspect for impact damage, reseat cables and check the battery, then run app diagnostics and record video before contacting support — don't open the shell.

Symptom

Solid red LED indicating a software/hardware error; plus field faults — cracks/dents from falls, sensor degradation from dust or misalignment, unresponsive components from loose/frayed cables, battery swelling or deformation.

Affected

General.

Fix / Workaround

Visually inspect for impact damage; clean sensors and confirm mounting; reseat cables and connectors; verify battery seating and replace if swollen or leaking. On a solid red LED, run the mobile-app diagnostics and record a video of any intermittent fault before contacting support. Note: opening the shell voids the warranty.

Critical security: BLE command injection with hardcoded keys (UniPwn)

No confirmed vendor patch documented; isolate the robot on a segmented network and block unexpected outbound traffic.

Symptom

A command-injection flaw in the BLE Wi-Fi provisioning, using hardcoded AES keys shared across all units, allows root access and is potentially wormable. Separate research found telemetry transmitted to external servers every ~5 minutes.

Affected

G1 (researchers indicate Go2/H1 share code paths). Public 'UniPwn' exploit released.

Fix / Workaround

No confirmed vendor patch documented at time of writing. Mitigate at the network level: isolate the robot on a segmented/firewalled network, restrict access to its internal interface (192.168.123.0/24), and block unexpected outbound traffic. Watch for a Unitree firmware advisory.

Viral demo skills are choreographed, not autonomous

Not a fault: out-of-the-box motions are pre-programmed, and autonomy requires development on the EDU platform.

Symptom

Kung-fu and backflip clips are trained showcases; the robot has no household autonomy out of the box and fails simple tasks like opening a door.

Affected

General.

Fix / Workaround

Expectation-setting, not a fault. Autonomous task performance requires significant development on the EDU platform; the base experience is remote/pre-programmed motions.

G1 23-DOF robot moves erratically in MuJoCo Sim2Sim

Fixed by vendor: pull the updated unitree_rl_lab, which now includes 23-DOF deploy code.

Symptom

When running Sim2Sim in MuJoCo with a policy trained in Isaac Lab for the G1 23-DOF configuration, the robot fails to walk properly and moves erratically. The suspected cause reported in the thread is that motor IDs were not adapted for the 23-DOF version.

Fix / Workaround

Vendor (Agnel-Wang) added 23-DOF deploy code to the repository; reporter confirmed successful Sim2Real after using the updated code.

G1_29_ArmController repeatedly prints 'Waiting to subscribe dds' and robot app reports firmware communication fault

Verify DDS connectivity with cyclonedds ps and subscribe rt/lowstate; if it still fails, open a Unitree support ticket.

Symptom

When running the teleoperation script, the controller loops indefinitely printing '[G1_29_ArmController] Waiting to subscribe dds...' and the mobile app reports '底层固件通信故障' (underlying firmware communication fault). DDS communication between the host device and the robot is not established despite the devices being on the same network.

Fix / Workaround

Maintainer suggests verifying network connectivity with 'cyclonedds ps' and 'cyclonedds subscribe rt/lowstate'; if unresolved, submit a support ticket. One commenter reported that low-level examples worked but high-level arm examples produced no robot motion and send request errors.

Apple Vision Pro WebSocket immediately disconnects on every page load in teleoperation setup

No confirmed fix; taking off the headset or fully closing Safari for a few seconds gives a temporarily stable connection.

Symptom

When accessing the teleoperation server from Apple Vision Pro Safari, the WebSocket connects but immediately disconnects on every page load, producing 'AssertionError: Websocket session is missing.' on the server. Refreshing the page repeats the connect/disconnect cycle; the only workarounds found are removing the AVP headset or fully closing Safari and waiting a few seconds.

Affected

vuer 0.0.60, televuer 4.0.0, xr_teleoperate commit 9fadc51, visionOS latest

Fix / Workaround

Temporarily stable connection achieved by taking off the AVP or closing Safari entirely for a few seconds. Maintainer suggested trying 'https://vuer.ai/?ws=wss://host ip:8012' but no confirmed fix was provided.

WBC policy streams values but real G1 does not move after hand calibration

No confirmed fix.

Symptom

Via the community GR00T-WholeBodyControl driver: after the robot enters debug mode and the hands calibrate successfully, the G1 does not move at all despite the terminal showing the policy streaming values to the robot. No errors are reported and the parallel simulation runs correctly.

Fix / Workaround

no confirmed fix

Vuer image feed on Quest 3 freezes on first frame during real-robot teleoperation

Try the teleimager (WebRTC) branch; note it does not support simulation deployment.

Symptom

When running the teleoperation pipeline with a Quest 3 headset, the Vuer display shows only the first captured frame and then freezes, while the image client on the PC confirms the live camera feed is working correctly. The issue was reproduced both in the main branch and with the teleimager branch.

Affected

vuer 0.0.67, xr_teleoperate (controller mode, G1_29)

Fix / Workaround

Maintainer suggested switching to the teleimager branch (WebRTC streaming); reporter applied the branch but noted it does not support simulation deployment. No fully confirmed fix for the frozen frame issue.

Teleoperation page goes black and WebSocket disconnects when entering VR mode on Apple Vision Pro

No confirmed fix; use 5 GHz Wi-Fi, keep ping under 50 ms, and try vuer 0.0.32rc7.

Symptom

After the Vision Pro successfully displays the binocular camera feed, clicking 'virtual reality' and granting hand-tracking permission causes the display to go black and the WebSocket to disconnect immediately, raising 'AssertionError: Websocket session is missing.' The error traceback originates in vuer/server.py.

Fix / Workaround

Maintainer suggested using only 5 GHz Wi-Fi, monitoring ping latency to the AVP (should be under 50 ms), testing with the televuer script directly, and trying vuer version 0.0.32rc7. No confirmed fix reported.

G1 does not walk when locomotion command issued via teleoperation controller; joystick input ignored

Set LOCO_SERVICE_NAME to 'sport' for ai_sport 8.2.0.0 or later ('loco' before), and specify the correct network interface.

Symptom

When using the controller mode of the teleoperation script with the --motion flag, arm control works correctly but the robot does not respond to joystick commands for walking. Even after exiting the program, the physical remote control also cannot make the robot walk, though arm gestures continue to function normally.

Affected

ai_sport version unspecified; xr_teleoperate, G1_29

Fix / Workaround

Maintainer identified that the ai_sport locomotion service name changed at version 8.2.0.0 (LOCO_SERVICE_NAME must be 'sport' for >=8.2.0.0, 'loco' for earlier). Also advised specifying the correct network interface name in the code if running on a multi-NIC device. Maintainer confirmed locomotion worked on their robot with version 8.4.0.0 after a git pull update.