Warranty & Safety Notice:
Unofficial modifications or unapproved firmware changes may void your warranty and could cause hardware damage or injury. Always consult the manufacturer or a certified technician before performing repairs.
Workarounds listed below are community-sourced and provided without guarantee.
DDS lowstate subscriber fails and SSL cert missing during teleop startup
Replace the temporary unitree_dds_wrapper with the official library, and use unitree_go message types for H1 (unitree_hg is for H1-2/G1).
Symptom
When running teleop_hand_and_arm.py on the H1, two concurrent failures occur: a FileNotFoundError for an SSL certificate file needed by the vuer server, and repeated 'lowstate_subscriber is not ok! Please check dds.' messages indicating the DDS connection to the robot cannot be established.
Community suggestion: replace the temporary unitree_dds_wrapper with the official unitree_sdk2_python library in the robot_arm.py and robot_hand.py control files. One commenter also reported success by switching the message type library from unitree_hg to unitree_go (unitree_go is for H1, unitree_hg is for H1_2/G1).
H1 teleoperation positional inaccuracy and Inspire Hand fingers fail to close fully
Update to the latest release with the Vuer-derived hand remapping that models inter-finger constraints; reported to improve the inaccuracy.
Symptom
During teleoperation of the H1 (Education Edition) with Inspire Hands and Meta Quest 3, a persistent offset exists between the operator's hand movements and the robot's arm positions such that the robot's hands cannot fully close together. The Inspire Hand fingers also fail to close completely — a gap of approximately 5 cm remains between the index finger and thumb even when the operator's fingers are touching. Overall manipulation lacks positional accuracy.
Vendor reply: the latest release switched the hand remapping algorithm from Vector to DexPilot, which accounts for constraints between all fingers and was suggested to improve pinch actions. No confirmation that this fully resolved the positional inaccuracy.
Inspire Hand serial port fails to open on /dev/ttyUSB0
Follow the thread matching your hand model: RS485 serial for the standard Inspire hand, Modbus TCP for the FTP variant.
Symptom
When launching the Inspire Hand controller with the command sudo ./inspire_hand -s /dev/ttyUSB0, the program immediately reports 'Open Serial port /dev/ttyUSB0 failed' and cannot connect to the hand.
Fix / Workaround
Vendor reply: directed user to a separate issue thread for the DFX Inspire Hand (RS485) and a separate issue thread for the FTP Inspire Hand (Modbus TCP), depending on hand model.
Training crashes with unpad_trajectories shape mismatch for H1/H1-2/G1 tasks
Update utils.py's unpad_trajectories from upstream rsl_rl — a two-line change per the linked pull request; frequent early episode terminations trigger the bug.
Symptom
RL training for the h1, h1_2, and g1 tasks crashes at or around 1000 iterations with a RuntimeError: 'shape [-1, 1044, 64] is invalid for input of size 1572864' inside the unpad_trajectories function. The go2 task does not exhibit this problem.
Affected
unitree_rl_gym; rsl_rl 1.0.2; Python 3.8
Fix / Workaround
Community fix: update utils.py in rsl_rl to a newer upstream version from the leggedrobotics/rsl_rl repository (specifically the unpad_trajectories function). One commenter also noted that too many early episode terminations can trigger the bug, and adding two lines to utils.py per a linked pull request resolved it.
H1-2 robot hands unreachable at 192.168.124.210 via network bridge configuration
No confirmed fix.
Symptom
On the H1-2, the robot hands at IP 192.168.124.210 cannot be pinged from the user's computer despite a network bridge being configured. Other devices on the 192.168.124.x subnet such as the LiDAR are reachable. A support ticket submitted through Unitree's ticket system was closed without resolution.
Sim-to-sim controller repeatedly fails to connect to simulated robot lowstate
Run the controller with the explicit network interface flag.
Symptom
When running the sim-to-sim setup with MuJoCo and the g1 configuration, the controller repeatedly prints 'Waiting for connection rt/lowstate' and never successfully connects to the simulated robot.
Affected
unitree_rl_lab; MuJoCo sim; g1 robot scene (scene_29dof.xml); domain_id: 0; interface: lo
Fix / Workaround
Community suggestion: run the controller with the explicit network interface flag, e.g. ./g1.ctrl -n lo.
H1-2 low-level SDK example raises AttributeError on NoneType lowstate objects
No confirmed fix.
Symptom
Running h1_low_level_example.py against the H1-2 robot produces repeated RecurrentThread exceptions: "AttributeError: 'NoneType' object has no attribute 'imu_state'" and "'NoneType' object has no attribute 'motor_state'", indicating the SDK is not receiving valid lowstate data from the robot.
Affected
unitree_sdk2_python; H1-2 robot; CycloneDDS with rmw_cyclonedds_cpp
Training crashes with RuntimeError: normal expects all elements of std >= 0.0
A vendor patch adds 'bad_orientation' to terminations, but the error is reported to persist even with the patch applied.
Symptom
During RL training for the Unitree-H1-Velocity task, the training run crashes after a large number of timesteps with 'RuntimeError: normal expects all elements of std >= 0.0', caused by invalid standard deviation values in the policy distribution. The same error was reproduced on the Unitree-G1-29dof-Velocity task after approximately 3 hours of training.
Affected
IsaacLab 2.1.0, isaacsim 4.5.0.0
Fix / Workaround
A vendor-side patch (commit e72a072c4db68b79a816b3b89bf3b6a0525d113e) suggested adding 'bad_orientation' to terminations, but a community report confirms the error still occurs after that patch is applied.
H1 robot with hands explodes in simulation when joint target position is set
Vendor reply: likely control-parameter instability — reduce stiffness and simulation dt, or fix the revolute hand joints.
Symptom
When importing h1_with_hands.urdf via the Isaac Sim 4.2.0 URDF Importer and setting a joint target position, the robot behaves erratically and 'blows up' in the simulation. The standard h1.urdf without hands does not exhibit this behaviour.
Affected
Isaac Sim 4.2.0
Fix / Workaround
A vendor reply suggests the instability is possibly caused by control parameters; recommended workarounds include reducing stiffness and simulation dt, or fixing the revolute joints in the hand.
H1 must be suspended to power on — wrong joint position at startup causes faults
Symptom
H1 behaves abnormally at power-on, or throws joint faults as soon as it boots.
Fix / Workaround
Cause: The current H1 only supports powering on while suspended from a stand. If the upper limbs or ankles are in the wrong position when power is applied, the robot reads an abnormal joint state and operation goes wrong from the start.
Power the H1 on only while it is hung on its stand. Before switching on, physically check that the arms and ankles sit in their correct neutral positions. Do not power on while the robot is lying down or sitting.
One or both battery packs will not power the H1, or will not insert cleanly.
Fix / Workaround
Cause: Wrong battery, a pack that isn't fully seated, or a single failing pack.
Use only genuine H1 packs — never mix in batteries from other products. Push each pack in firmly until it clicks, which confirms it is seated. If only one bay fails, swap the two packs between bays to isolate whether the fault follows the pack or the bay. If it persists, note the battery indicator-light state and contact support with that detail.
Abnormal battery communication appears in the H1 error-code table on this page.
After turning the H1 on, one or more joints report a position that is clearly wrong.
Fix / Workaround
Cause: Either the limbs weren't in the correct position at power-on, or a cable to the affected motor is damaged.
First confirm the arms and ankles were correctly positioned before power was applied, and re-boot from that position. If a specific joint still reads wrong, inspect the cabling to the motor at that position for damage or a loose connector.
Joint Starting Anomaly and motor communication faults are listed in the H1 error-code table on this page.
During high-level walking the H1 veers or drifts rather than tracking straight.
Fix / Workaround
Cause: A loosened ankle, or normal IMU drift combined with unit-to-unit hardware variation.
Check whether the ankle has worked loose; if so, tighten its screws and try again. Because the IMU drifts slightly by nature, correct the heading manually on the joystick during operation. If drift persists, power down, reset the robot to its initial pose, and restart.