Leg/hip/ankle motors overheat and force a shutdown

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. Fix: 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

Symptom: The shoulder-pitch arm motor overheats after short operation and the arm loses responsiveness when paired with the Inspire FTP dexterous hand. Fix: 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)

Symptom: G1 boots into 'damp mode' and ignores SDK commands; entering 'develop mode' also disables SDK responsiveness, so users conclude the SDK is broken. Fix: 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')

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'. Fix: 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')

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. Fix: 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

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. Fix: 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

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. Fix: 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

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. Fix: 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'

Symptom: Deploying over WiFi hangs on 'Waiting for connection rt/lowstate' even though SSH to the robot works; wired ethernet works fine. Fix: 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

Symptom: DDS assertion failure / CycloneDDS writer error when initializing the G1 simulation; it won't start. Fix: 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)

Symptom: The controller connects over Ethernet then immediately fails with 'Unmatched robot type' during sim-to-real deployment. Fix: 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

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. Fix: 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

Symptom: In MuJoCo simulation the G1 has no default stabilization and falls over when run without controls. Fix: 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)

Symptom: The 9,000 mAh battery gives only about 2 hours per charge, and drains faster under dynamic movement. Fix: 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

Symptom: Buyers of the ~$13,500 base G1 discover it's a demo/showcase unit with no SDK and cannot be programmed. Fix: 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)

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. Fix: 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)

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. Fix: 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

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. Fix: 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

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: 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

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: 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

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. Fix: 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

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: no confirmed fix

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

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. Fix: 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

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: 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

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. Fix: 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.

G1 joints do not move after teleoperation program starts and 'r' is pressed

Symptom: The teleoperation program starts without errors, DDS appears to connect, and the AVP displays the live camera feed with arm tracking, but the G1 robot does not move when the program is running and after pressing 'r' to start. Joint position output is absent from the log, unlike expected behaviour. Entering debug mode from the program is reported as inconsistent. Fix: no confirmed fix

VR headset shows only blue grid, robot not visible in XR teleoperation sim

Symptom: When running XR teleoperation in simulation with a Meta Quest 3, the user successfully enters VR mode but sees only blue grids instead of the robot. The simulation terminal also shows '[DDSManager] object g1 not found' and 'g1_robot_dds is not initialized'. Fix: no confirmed fix

G1 sim2sim policy causes robot to drift left and shake arms uncontrollably in MuJoCo

Symptom: When deploying a trained RL policy (or the provided v0 policy) from unitree_rl_lab into MuJoCo via simulate_python, the G1 robot drifts to the left side, shakes its arms with high frequency and low amplitude, and is nearly impossible to control with the joystick. The robot also jitters immediately after pressing the movement activation button sequence. Fix: Community suggestion: increase the arm and wrist armature value in the MuJoCo g1_29dof.xml to reduce arm shaking. No confirmed fix for the overall drift/instability.

RuntimeError 'list index out of range' in unitree_mujoco when running G1 with hand configuration

Symptom: Running unitree_mujoco.py for G1 (or H1 with Inspire hands) raises '[RecurrentThread] target func raise exception: name=IndexError, args=("list index out of range",)' at runtime. The error occurs when attempting to simulate the robot with hand attachments. Fix: Community workaround: use scene_29dof.xml instead of scene_29dof_with_hand.xml. Separately, ensure the ROBOT name in config.py is exactly one of the supported names (e.g. 'g1') and not a variant like 'g1_23dof'.

High-level SDK commands return 'send request error' on G1; low-level commands work

Symptom: When running high-level SDK commands (e.g. g1_loco_client_example.py), the client prints '[ClientStub] send request error. id: ' and the command is not executed. Low-level scripts (g1_low_level_example.py) work correctly. Fix: no confirmed fix

G1 overheats and shuts down after a few minutes running sonic_release policy, causing falls

Symptom: Via the community GR00T-WholeBodyControl driver: When deploying the sonic_release policy on a real 29-DoF G1 robot equipped with Dex3 hands, the robot issues an overheating warning after a few minutes even while standing idle, then Sonic shuts down automatically, causing the robot to fall multiple times. Fix: no confirmed fix

WebSocket session drops and VR view goes black when entering Virtual Reality mode on Quest 3

Symptom: After successfully connecting Quest 3 to the teleoperation page (vuer interface loads but shows a black screen), clicking 'Virtual Reality' causes the WebSocket session to disconnect. The terminal shows the connection dropped. A community contributor traced this to a bug in Meta Quest 3's browser where RTCPeerConnection.createOffer() never resolves its Promise, breaking the default client-initiated WebRTC flow. Fix: Community contributor proposed reversing the WebRTC negotiation to a server-initiated flow (server creates offer, browser calls createAnswer()) as a workaround. No confirmed upstream fix.

DDS communication fails when host PC connects to G1 over Wi-Fi instead of Ethernet

Symptom: Teleoperation works correctly when the laptop is connected to the robot via Ethernet cable, but fails with DDS errors when attempting to operate wirelessly over Wi-Fi. Additionally, when running everything on the robot's PC2 (Jetson), connection problems appear after approximately 10 minutes. Fix: Maintainer suggests using a DDS forwarding proxy at the application layer, or mounting a router to the back of the G1 (subnet 192.168.123.*/24) powered from the G1's power interface. No single confirmed complete fix.

Unitree G1 : Problèmes Connus & Solutions

Dernière mise à jour 23 août 2026

38 problèmes connus View robot profile →

Avertissement Garantie & Sécurité : La garantie commence à réception. Le propriétaire expédie l'unité à Unitree à ses frais pour diagnostic. La garantie est ANNULÉE en cas d'ouverture du boîtier, de démontage ou de modification non autorisée. Aucun canal de pièces de rechange pour le consommateur ; les revendeurs assurent uniquement le support de premier niveau. G1 base ~8 mois ; G1 EDU ~18 mois (UE 24 mois). Sources : https://www.unitree.com/mobile/terms/policy https://blog.robozaps.com/b/unitree-g1-review Les contournementslisted below are community-sourced and provided without guarantee.

moteur/actionneur Bloque l'Utilisation Contournement Disponible

Les moteurs de jambe/hanche/cheville surchauffent et forcent un arrêt

Symptôme: Les moteurs de rotation de cheville atteignent ~90°C en 5-10 min même au ralenti ; l'articulation de hanche gauche surchauffe après ~30 min de téléopération et déclenche un arrêt automatique du système.

Touché: Signalé avec des contrôleurs corps entier tiers (NVIDIA GEAR-SONIC / Isaac-GR00T N1.7 sur Jetson Orin NX). Le contrôleur d'origine Unitree maintient les chevilles à 30-45°C.

Solution / Contournement: La surchauffe est liée à des gains de contrôleur agressifs, pas toujours un défaut matériel. Réduisez les gains Kp/Kd, ajustez la posture debout pour réduire la charge statique, et préférez le contrôleur d'origine Unitree pour les runs prolongés. Si les températures grimpent aussi sur le contrôleur d'origine, cessez l'utilisation et inspectez — un actionneur réellement défaillant nécessite une intervention.

Sources : github.com/NVlabs/GR00T-WholeBodyControl #174 github.com/NVlabs/GR00T-WholeBodyControl #71

moteur/actionneur Dégrade l'Utilisation Ouvert / Non Résolu

Le moteur d'épaule/bras surchauffe et devient mou avec la main dextre Inspire

Symptôme: Le moteur de bras pitch d'épaule surchauffe après une courte opération et le bras perd en réactivité lorsqu'il est associé à la main dextre Inspire FTP.

Touché: G1 ARM7 + main Inspire FTP, ROS2 Humble ; utilisateurs avec gains PD kp=40 / kd=1.5.

Solution / Contournement: Aucune correction fournisseur documentée. Direction communautaire : le bras nécessite une compensation gravité/charge pour la masse ajoutée de la main et des limites de couple inférieures ; les propriétaires cherchent encore les gains PD recommandés par Unitree pour cet appairage. Traitez comme un problème de tuning avant de supposer une défaillance matérielle.

Sources : github.com/unitreerobotics/unitree_sdk2_python #129

firmware/mise à jour Gêne Contournement Disponible

Le robot ignore les commandes SDK (bloqué en mode damp / develop)

Symptôme: Le G1 démarre en 'mode damp' et ignore les commandes SDK ; entrer en 'mode develop' désactive aussi la réactivité SDK, donc les utilisateurs concluent que le SDK est cassé.

Touché: Comportement général du firmware G1.

Solution / Contournement: Activez le robot avec la télécommande avant d'envoyer des commandes SDK : appuyez sur L1+A, puis L1+UP pour quitter le mode damp. Ne restez pas en mode develop si vous avez besoin du contrôle SDK. Si vous êtes entré en mode develop, renouvelez le client ai-sport via l'application.

Sources : github.com/unitreerobotics/unitree_sdk2_python #42 github.com/unitreerobotics/unitree_sdk2_python #43

SDK/logiciel Dégrade l'Utilisation Corrigé par le Fournisseur

WaveHand / ShakeHand échouent depuis le SDK (erreur 3203 'API non implémentée')

Symptôme: Les actions bras WaveHand et ShakeHand fonctionnent depuis la télécommande mais échouent depuis Python/C++/ROS2 ; ROS2 retourne l'erreur 3203 'API non implémentée sur le serveur'.

Touché: Firmware avant v1.3.0.

Solution / Contournement: Mettez à jour le firmware du robot vers v1.3.0 ou ultérieur. Assurez-vous aussi que le robot est activé hors du mode damp (L1+A, L1+UP) avant d'émettre les commandes.

Sources : github.com/unitreerobotics/unitree_sdk2_python #42

firmware/mise à jour Bloque l'Utilisation Ouvert / Non Résolu

Le code et exemples officiels cassent après firmware 1.4.0 ('ClientStub send request error')

Symptôme: Le code Python précédemment fonctionnel et les exemples SDK officiels cessent de fonctionner après mise à jour vers firmware 1.4.0 ; '[ClientStub] send request error' répété. Lié : GetVolume retourne erreur 3102, exemples audio/haut niveau échouent.

Touché: Firmware 1.4.0.

Solution / Contournement: Aucune correction fournisseur documentée. Confirmez que le robot est activé (hors mode damp), vérifiez que la version SDK correspond au firmware, et si vous avez.upgradé spécifiquement pour une fonctionnalité, sachez que certains utilisateurs sont revenus en arrière. Surveillez les notes de version Unitree pour un correctif suivant.

Sources : github.com/unitreerobotics/unitree_sdk2_python #78 github.com/unitreerobotics/unitree_sdk2_python #33

main/préhenseur Bloque l'Utilisation Contournement Disponible

La main Inspire ne peut pas ouvrir le port série / est inaccessible à son IP

Symptôme: 'Échec ouverture port série /dev/ttyUSB0' — la main Inspire ne peut pas être contrôlée ; ou la main FTP est inaccessible à 192.168.123.211.

Touché: G1 avec main Inspire (variantes série DFX vs FTP modbus-TCP).

Solution / Contournement: La méthode de contrôle dépend de la variante de main. Les mains Inspire FTP utilisent Modbus TCP, pas un port série — utiliser du code série sur une main FTP échoue par conception. Confirmez quelle variante vous avez et utilisez la méthode de contrôle correspondante ; vérifiez que l'IP de la main est accessible sur le réseau 192.168.123.x.

Sources : github.com/unitreerobotics/xr_teleoperate #51

main/préhenseur Dégrade l'Utilisation Ouvert / Non Résolu

Le pouce de la main Dex3-1 bouge à peine en téléopération

Symptôme: En téléop le pouce ne fait que des micro-mouvements de 3-4° versus amplitude complète en simulation ; le pincement pouce-index s'arrête à ~5cm, trop grossier pour la manipulation fine.

Touché: Logiciel G1 V1.4.7 + main Dex3-1.

Solution / Contournement: Aucune correction documentée. L'auto-test au démarrage montre des articulations normales et la simulation fonctionne, ce qui pointe vers une incompatibilité de mapping de commandes entre la téléop et le driver de main plutôt qu'un problème matériel. Signalez la version du driver à Unitree.

Sources : github.com/unitreerobotics/xr_teleoperate #229

réseau/connectivité Dégrade l'Utilisation Ouvert / Non Résolu

La latence de téléopération monte à ~2.5s après 1-2 heures

Symptôme: La latence du bras et caméra grimpe à ~2.5s après téléop prolongée ; la pose de préparation du bras prend ~4s au lieu de ~2s, finissant par apparaître immédiatement au démarrage.

Touché: xr_teleoperate v1.3 et v1.5.

Solution / Contournement: Aucune correction documentée. Passer à un routeur gigabit et WiFi 6 n'a pas aidé, et le mode simulation n'est pas affecté — suggérant un problème de buffering/accumulation embarqué plutôt que réseau. Redémarrez la stack téléop entre les longues sessions comme solution temporaire.

Sources : github.com/unitreerobotics/xr_teleoperate #247

réseau/connectivité Dégrade l'Utilisation Contournement Disponible

Le déploiement de politique sur WiFi se bloque sur 'Waiting for connection rt/lowstate'

Symptôme: Le déploiement sur WiFi se bloque sur 'Waiting for connection rt/lowstate' même si SSH vers le robot fonctionne ; ethernet filaire fonctionne parfaitement.

Touché: G1, contrôle basé DDS.

Solution / Contournement: Utilisez une connexion filaire et spécifiez l'interface, ex. ./g1_ctrl --network enx701988512412. Le multicast DDS pour lowstate ne traverse pas l'interface wireless de manière fiable.

Sources : github.com/unitreerobotics/unitree_rl_lab #93

SDK/logiciel Bloque l'Utilisation Contournement Disponible

L'incompatibilité de version de CycloneDDS fait planter l'initialisation de la simulation G1

Symptôme: Échec d'assertion DDS / erreur du writer CycloneDDS lors de l'initialisation de la simulation G1 ; elle ne démarre pas.

Touché: Ubuntu 22.04, ROS2 Humble ; CycloneDDS système 0.10.5 vs CycloneDDS Python 0.10.2.

Solution / Contournement: Ne sourcez pas le script setup ROS (ses libs DDS diffèrent de celles de unitree_sdk2). Vérifiez quel .so est lié à la compilation. Alternatives : compilez CycloneDDS 0.10.2 depuis les sources, patchez unitree-sdk2py pour 0.10.5, ou développez sur Ubuntu 20.04.

Sources : github.com/unitreerobotics/unitree_mujoco #60

SDK/logiciel Bloque l'Utilisation Contournement Disponible

'Type de robot non correspondant' en connexion Ethernet (23 vs 29 DOF)

Symptôme: Le contrôleur se connecte via Ethernet puis échoue immédiatement avec 'Type de robot non correspondant' lors du déploiement sim-to-real.

Touché: Variantes G1 23-DOF et 29-DOF (incl. configs hanche verrouillée/mains factices).

Solution / Contournement: Le DOF/config du robot doit correspondre au type attendu par le contrôleur. Définissez le DOF correct dans votre config, et vérifiez les installations SDK conflictuelles dans /usr/local vs votre chemin de projet — recompiler unitree_sdk2 proprement (build deploy avec -DBUILD_EXAMPLES=OFF, build sim avec un CMAKE_INSTALL_PREFIX séparé) résout le cas associé du mode vitesse non réactif.

Sources : github.com/unitreerobotics/unitree_rl_lab #114 github.com/unitreerobotics/unitree_rl_lab #44

SDK/logiciel Dégrade l'Utilisation Ouvert / Non Résolu

Déplacer les bras via SDK pendant la marche déstabilise l'équilibre

Symptôme: Contrôler les bras via SDK pendant la marche (gamepad) fait pencher le robot vers l'avant ou perdre l'équilibre ; lever les bras en marchant produit une démarche instable et lourde.

Touché: G1 avec taille 3-DOF.

Solution / Contournement: Aucun correctif documenté. La mise à zéro des axes de taille, le maintien des valeurs initiales et leur non-manipulation ont tous été essayés sans succès — le contrôleur SDK des bras et le contrôleur d'équilibre de locomotion entrent en conflit. Évitez les grands mouvements de bras pendant la locomotion jusqu'à ce qu'une mise à jour firmware y remédiedocs.westonrobot.com/tutorial/… ;

Sources : github.com/unitreerobotics/unitree_sdk2_python #146

SDK/logiciel Dégrade l'Utilisation Contournement Disponible

Le G1 simulé s'effondre sans stabilisation par défaut

Symptôme: Dans la simulation MuJoCo, le G1 n'a pas de stabilisation par défaut et tombe lorsqu'il est exécuté sans contrôles.

Touché: unitree_mujoco.

Solution / Contournement: Activez l'elastic band : réglez enable_elastic_band: 1 dans unitree_mujoco/simulate/config.yaml (ou ENABLE_ELASTIC_BAND=True). Notez que le contrôleur de mouvement d'usine n'est pas disponible en simulation, et l'elastic band peut être difficile à désactiver lors du passage au contrôle par manette.

Sources : github.com/unitreerobotics/unitree_mujoco #57

batterie/alimentation Gêne Pas clair

Autonomie de batterie courte (~2 heures)

Symptôme: La batterie de 9 000 mAh ne donne qu'environ 2 heures par charge, et se décharge plus vite sous mouvement dynamique.

Touché: Modèle de base, pack 9 000 mAh.

Solution / Contournement: C'est une limitation de capacité, pas un défaut. Gardez des batteries de rechange chargées pour le hot-swap entre les sessions ; comptez environ ~2 heures d'utilisation active.

Sources : blog.robozaps.com/b/…

autre Bloque l'Utilisation Pas clair

Le G1 de base ne peut pas être programmé — pas de SDK

Symptôme: Les acheteurs du G1 de base à ~13 500 $ découvrent que c'est une unité de démo/showcase sans SDK et qui ne peut pas être programmée.

Touché: G1 base (23 DOF) vs G1 EDU (jusqu'à 43 DOF).

Solution / Contournement: C'est une limitation de niveau produit. L'accès SDK, un couple plus élevé et plus de DOF nécessitent la plateforme développeur G1 EDU (~$44k-$74k). Confirmez le niveau avant l'achat si vous avez l'intention de développer.

Sources : blog.robozaps.com/b/…

mécanique/structurel Bloque l'Utilisation Contournement Disponible

LED rouge fixe / checklist de défauts physiques (chutes, câbles, batterie)

Symptôme: LED rouge fixe indiquant une erreur software/hardware ; plus les défauts terrain — fissures/ bosses des chutes, dégradation des capteurs due à la poussière ou au désalignement, composants non réactifs à cause de câbles desserrés/dénudés, batterie gonflée ou déformée.

Touché: Général.

Solution / Contournement: Inspectez visuellement les dommages d'impact ; nettoyez les capteurs et confirmez le montage ; reconnectez les câbles et connecteurs ; vérifiez la siège de la batterie et remplacez si gonflée ou qui fuit. Sur une LED rouge fixe, lancez les diagnostics de l'app mobile et enregistrez une vidéo de tout défaut intermittent avant de contacter le support. Note : ouvrir le boîtier annule la garantie.

Sources : docs.westonrobot.com/tutorial/…

sécurité/vie privée Bloque l'Utilisation Ouvert / Non Résolu

Sécurité critique : injection de commandes BLE avec clés hardcodées (UniPwn)

Symptôme: Une faille d'injection de commandes dans le provisionnement Wi-Fi BLE, utilisant des clés AES hardcodées partagées sur toutes les unités, permet un accès root et est potentiellement wormable. Une recherche séparée a trouvé de la télémétrie transmise à des serveurs externes toutes les ~5 minutes.

Touché: G1 (les chercheurs indiquent que Go2/H1 partagent des chemins de code). Exploit public 'UniPwn' publié.

Solution / Contournement: Aucun correctif vendor confirmé documenté au moment de l'écriture. Atténuez au niveau réseau : isolez le robot sur un réseau segmenté/pare-feu, restreignez l'accès à son interface interne (192.168.123.0/24), et bloquez le trafic sortant inattendu. Surveillez un advisory firmware Unitree.

Sources : arXiv:2509.14139 spectrum.ieee.org/unitree-robot-exploit/… helpnetsecurity.com/2025/…

autre Gêne Pas clair

Les skills des démos virales sont chorégraphiées, pas autonomes

Symptôme: Les clips de kung-fu et backflip sont des démonstrations entraînées ; le robot n'a pas d'autonomie domestique out of the box et échoue des tâches simples comme ouvrir une porte.

Touché: Général.

Solution / Contournement: Gestion des attentes, pas un défaut. La performance autonome des tâches nécessite un développement significatif sur la plateforme EDU ; l'expérience de base est des mouvements remote/pré-programmés.

Sources : blog.robozaps.com/b/…

SDK/logiciel Bloque l'Utilisation Corrigé par le Fournisseur

Le robot G1 23-DOF se déplace de manière erratique dans MuJoCo Sim2Sim

Symptôme: Lors de l'exécution de Sim2Sim dans MuJoCo avec une politique entraînée dans Isaac Lab pour la configuration G1 23-DOF, le robot ne marche pas correctement et se déplace de manière erratique. La cause présumée signalée dans le fil est que les ID des moteurs n'ont pas été adaptés pour la version 23-DOF.

Solution / Contournement: Le fournisseur (Agnel-Wang) a ajouté le code de déploiement 23-DOF au dépôt ; le rapporteur a confirmé un Sim2Real réussi après utilisation du code mis à jour.

Sources : github.com/unitreerobotics/unitree_rl_lab #27

réseau/connectivité Bloque l'Utilisation Ouvert / Non Résolu

G1_29_ArmController affiche en boucle 'Waiting to subscribe dds' et l'application robot signale une erreur de communication firmware

Symptôme: Lors de l'exécution du script de téléopération, le contrôleur boucle indéfiniment en affichant '[G1_29_ArmController] Waiting to subscribe dds...' et l'application mobile signale '底层固件通信故障' (erreur de communication firmware de bas niveau). La communication DDS entre l'appareil hôte et le robot n'est pas établie malgré le fait que les appareils soient sur le même réseau.

Solution / Contournement: Le mainteneur suggère de vérifier la connectivité réseau avec 'cyclonedds ps' et 'cyclonedds subscribe rt/lowstate' ; si non résolu, soumettre un ticket de support. Un commentateur a signalé que les exemples de bas niveau fonctionnaient mais que les exemples de bras de haut niveau ne produisaient aucun mouvement du robot et généraient des erreurs de demande d'envoi.

Sources : github.com/unitreerobotics/xr_teleoperate #57

réseau/connectivité Bloque l'Utilisation Ouvert / Non Résolu

Le WebSocket Apple Vision Pro se déconnecte immédiatement à chaque chargement de page dans la configuration de téléopération

Symptôme: Lors de l'accès au serveur de téléopération depuis Safari d'Apple Vision Pro, le WebSocket se connecte mais se déconnecte immédiatement à chaque chargement de page, produisant 'AssertionError: Websocket session is missing.' sur le serveur. L'actualisation de la page répète le cycle de connexion/déconnexion ; les seules solutions de contournement trouvées sont de retirer le casque AVP ou de fermer complètement Safari et d'attendre quelques secondes.

Touché: vuer 0.0.60, televuer 4.0.0, xr_teleoperate commit 9fadc51, visionOS latest

Solution / Contournement: Une connexion temporairement stable a été obtenue en retirant l'AVP ou en fermant complètement Safari pendant quelques secondes. Le mainteneur a suggéré d'essayer 'https://vuer.ai/?ws=wss://host ip:8012' mais aucune correction confirmée n'a été fournie.

Sources : github.com/unitreerobotics/xr_teleoperate #271

SDK/logiciel Bloque l'Utilisation Ouvert / Non Résolu

La politique WBC diffuse des valeurs mais le vrai G1 ne bouge pas après l'étalonnage des mains

Symptôme: Via le driver communautaire GR00T-WholeBodyControl : après que le robot entre en mode debug et que les mains s'étalonnent avec succès, le G1 ne bouge pas du tout malgré le terminal montrant la politique diffusant des valeurs vers le robot. Aucune erreur n'est signalée et la simulation parallèle fonctionne correctement.

Solution / Contournement: aucune correction confirmée

Sources : github.com/NVlabs/GR00T-WholeBodyControl #21

SDK/logiciel Dégrade l'Utilisation Ouvert / Non Résolu

Le flux d'image Vuer sur Quest 3 se fige sur la première image lors de la téléopération sur robot réel

Symptôme: Lors de l'exécution du pipeline de téléopération avec un casque Quest 3, l'affichage Vuer montre uniquement la première image capturée puis se fige, tandis que le client d'image sur le PC confirme que le flux de caméra en direct fonctionne correctement. Le problème a été reproduit à la fois dans la branche principale et avec la branche teleimager.

Touché: vuer 0.0.67, xr_teleoperate (mode contrôleur, G1_29)

Solution / Contournement: Le mainteneur a suggéré de passer à la branche teleimager (streaming WebRTC) ; le rapporteur a appliqué la branche mais a noté qu'elle ne prend pas en charge le déploiement en simulation. Aucune correction entièrement confirmée pour le problème d'image figée.

Sources : github.com/unitreerobotics/xr_teleoperate #172

réseau/connectivité Bloque l'Utilisation Ouvert / Non Résolu

La page de téléopération devient noire et le WebSocket se déconnecte lors de l'entrée en mode VR sur Apple Vision Pro

Symptôme: Après qu'Apple Vision Pro affiche avec succès le flux de caméra binoculaire, cliquer sur 'réalité virtuelle' et accorder l'autorisation de suivi des mains provoque l'affichage d'un écran noir et la déconnexion immédiate du WebSocket, levant 'AssertionError: Websocket session is missing.' Le traceback de l'erreur provient de vuer/server.py.

Solution / Contournement: Le mainteneur a suggéré d'utiliser uniquement le Wi-Fi 5 GHz, de surveiller la latence ping vers l'AVP (doit être inférieure à 50 ms), de tester directement avec le script televuer et d'essayer la version vuer 0.0.32rc7. Aucune correction confirmée rapportée.

Sources : github.com/unitreerobotics/xr_teleoperate #115

SDK/logiciel Bloque l'Utilisation Contournement Disponible

G1 ne marche pas quand une commande de locomotion est émise via le contrôleur de téléopération ; l'entrée du joystick ignorée

Symptôme: Lors de l'utilisation du mode contrôleur du script de téléopération avec le flag --motion, le contrôle des bras fonctionne correctement mais le robot ne répond pas aux commandes du joystick pour marcher. Même après la sortie du programme, la télécommande physique ne peut pas non plus faire marcher le robot, bien que les gestes des bras continuent de fonctionner normalement.

Touché: ai_sport version non spécifiée ; xr_teleoperate, G1_29

Solution / Contournement: Le mainteneur a identifié que le nom du service de locomotion ai_sport a changé à la version 8.2.0.0 (LOCO_SERVICE_NAME doit être 'sport' pour >=8.2.0.0, 'loco' pour les versions antérieures). Il a également conseillé de spécifier le nom correct de l'interface réseau dans le code si l'exécution se fait sur un appareil multi-NIC. Le mainteneur a confirmé que la locomotion fonctionnait sur son robot avec la version 8.4.0.0 après une mise à jour git pull.

Sources : github.com/unitreerobotics/xr_teleoperate #77

Show all 38 issues

SDK/logiciel Bloque l'Utilisation Ouvert / Non Résolu

Les articulations G1 ne bougent pas après le démarrage du programme de téléopération et l'appui sur 'r'

Symptôme: Le programme de téléopération démarre sans erreur, DDS semble se connecter et l'AVP affiche le flux de caméra en direct avec le suivi des bras, mais le robot G1 ne bouge pas lorsque le programme est en cours d'exécution et après avoir appuyé sur 'r' pour démarrer. La sortie de position des articulations est absente du journal, contrairement au comportement attendu. L'entrée en mode debug depuis le programme est signalée comme incohérente.

Touché: G1 29-DOF avec mains Inspire dftp, AVP

Solution / Contournement: aucune correction confirmée

Sources : github.com/unitreerobotics/xr_teleoperate #189

SDK/logiciel Bloque l'Utilisation Ouvert / Non Résolu

Le casque VR affiche uniquement une grille bleue, robot non visible dans la simulation de téléopération XR

Symptôme: Lors de l'exécution de la téléopération XR en simulation avec un Meta Quest 3, l'utilisateur entre avec succès en mode VR mais ne voit que des grilles bleues au lieu du robot. Le terminal de simulation affiche également '[DDSManager] object g1 not found' et 'g1_robot_dds is not initialized'.

Touché: unitree_sim_isaaclab avec la tâche Isaac-PickPlace-Cylinder-G129-Dex3-Joint ; xr_teleoperate teleop_hand_and_arm.py ; Meta Quest 3

Solution / Contournement: aucune correction confirmée

Sources : github.com/unitreerobotics/xr_teleoperate #112

SDK/logiciel Bloque l'Utilisation Contournement Disponible

La politique sim2sim G1 provoque une dérive vers la gauche et des secousses incontrôlables des bras dans MuJoCo

Symptôme: Lors du déploiement d'une politique RL entraînée (ou de la politique v0 fournie) depuis unitree_rl_lab dans MuJoCo via simulate_python, le robot G1 dérive vers la gauche, secoue ses bras avec une haute fréquence et une faible amplitude, et est presque impossible à contrôler avec le joystick. Le robot tremble également immédiatement après avoir appuyé sur la séquence de boutons d'activation du mouvement.

Touché: unitree_rl_lab (dernière version) ; Isaac Sim + Isaac Lab ; unitree_mujoco avec G1 29dof ; simulate_python (pas simulate avec C++)

Solution / Contournement: Suggestion de la communauté : augmenter la valeur d'armature du bras et du poignet dans le fichier g1_29dof.xml MuJoCo pour réduire les secousses des bras. Aucune correction confirmée pour la dérive/l'instabilité globale.

Sources : github.com/unitreerobotics/unitree_rl_lab #31

SDK/logiciel Bloque l'Utilisation Contournement Disponible

RuntimeError 'list index out of range' dans unitree_mujoco lors de l'exécution de G1 avec configuration main

Symptôme: L'exécution de unitree_mujoco.py pour G1 (ou H1 avec mains Inspire) génère '[RecurrentThread] target func raise exception: name=IndexError, args=("list index out of range",)' à l'exécution. L'erreur se produit lors de la tentative de simulation du robot avec des mains.

Touché: unitree_mujoco ; G1 avec main (scene_29dof_with_hand.xml) ; H1 avec mains Inspire

Solution / Contournement: Solution de contournement de la communauté : utiliser scene_29dof.xml au lieu de scene_29dof_with_hand.xml. Séparément, s'assurer que le nom ROBOT dans config.py est exactement l'un des noms pris en charge (par exemple 'g1') et non une variante comme 'g1_23dof'.

Sources : github.com/unitreerobotics/unitree_mujoco #52

SDK/logiciel Bloque l'Utilisation Ouvert / Non Résolu

Les commandes SDK de haut niveau retournent 'send request error' sur G1 ; les commandes de bas niveau fonctionnent

Symptôme: Lors de l'exécution de commandes SDK de haut niveau (par exemple g1_loco_client_example.py), le client affiche '[ClientStub] send request error. id: <id>' et la commande n'est pas exécutée. Les scripts de bas niveau (g1_low_level_example.py) fonctionnent correctement.

Touché: unitree_sdk2_python ; robot G1 ; g1

Solution / Contournement: aucune correction confirmée

Sources : github.com/unitreerobotics/unitree_sdk2_python #54

SDK/logiciel Bloque l'Utilisation Contournement Disponible

WebSocket disconnects immediately when entering VR mode on Meta Quest 3 with hand tracking input

Symptôme: When using xr_teleoperate with a Meta Quest 3, the WebSocket connection to the Vuer page on port 8012 drops immediately upon clicking the Virtual Reality button, printing 'websocket is now disconnected' and 'AssertionError: Websocket session is missing.' The issue is specific to hand tracking input mode; switching to controller input mode keeps the connection active.

Touché: xr_teleoperate v1.5; vuer 0.0.60; aiohttp 3.10.5; Meta Quest 3 built-in browser; Ubuntu host; Isaac Sim 5.1 + unitree_sim_isaaclab; G1_29 + Inspire

Solution / Contournement: Community workaround: downgrade xr_teleoperate to v1.0 resolves the disconnect. Alternatively, switching to --input-mode=controller keeps the WebSocket connected. Using the Wolvic browser instead of the Meta Quest default browser also prevents the WebSocket disconnect, though camera streaming issues remain.

Sources : github.com/unitreerobotics/xr_teleoperate #296

SDK/logiciel Bloque l'Utilisation Ouvert / Non Résolu

Teleoperation VR page unreachable via local IP; WebSocket drops on entering VR mode

Symptôme: When accessing the teleoperation interface via the local IP address (https://<host-ip>:8012?ws=wss://<host-ip>:8012), the page either fails to load or shows a black screen. On entering VR/pass-through (WebXR mode), the WebSocket drops and the robot stops receiving tracking data, with the server reporting 'Websocket session is missing' and occasional aiohttp 'resume_writing() AssertionError'.

Touché: vuer 0.0.60, televuer 4.0.0; hardware: Unitree G1 29-DoF EDU with Inspire RH56DFTP, Meta Quest 3 and Apple Vision Pro (visionOS 26.4)

Solution / Contournement: Maintainer suggests verifying that the host IP is included in the certificate's SAN field, using incognito/private browsing, and trying version-pinned vuer/televuer combinations. A community contributor identified that Quest browser's RTCPeerConnection.createOffer() never resolves and proposed a server-initiated WebRTC flow as a workaround, but this has not been officially upstreamed. No confirmed fix from vendor.

Sources : github.com/unitreerobotics/xr_teleoperate #297

SDK/logiciel Bloque l'Utilisation Contournement Disponible

Teleoperation program exits automatically shortly after robot raises arms when Inspire FTP hand is enabled

Symptôme: When launching teleop_hand_and_arm.py with the Inspire FTP dexterous hand enabled (--ee=inspire_ftp), the robot raises both arms slightly and then the program terminates automatically, dropping the arms. The log shows the image client closes unexpectedly and the program exits without a clear error message.

Touché: xr_teleoperate; hardware: Unitree G1 29-DoF with Inspire FTP dexterous hands

Solution / Contournement: Workaround confirmed by user: run without the --ee=inspire_ftp flag (i.e., without activating the FTP dexterous hands) to operate the arms alone. Maintainer noted all end-effector code is written for a left-and-right pair, so a single defective hand can break things. User patched the Inspire_Controller_FTP class to handle single-hand operation. Maintainer also suggested trying the latest code version.

Sources : github.com/unitreerobotics/xr_teleoperate #194

main/préhenseur Bloque l'Utilisation Corrigé par le Fournisseur

Both Inspire dexterous hands mirror only the right hand's movement due to serial port misconfiguration

Symptôme: During teleoperation with two Inspire dexterous hands, both hands follow only the movement of the right hand. The root cause identified in the thread is that the example code sends commands for both hands to the same serial port.

Touché: Unitree G1 with Inspire DFX / RH56DFTP dexterous hands; example code inspire_ctrl.cpp from vendor example package

Solution / Contournement: Community-identified fix confirmed by maintainer: modify inspire_ctrl.cpp to initialize two separate serial ports (serial1 = /dev/ttyUSB1, serial2 = /dev/ttyUSB2) and bind each hand to its respective port and ID. Vendor provided corrected inspire_ctrl.cpp code in the comments.

Sources : github.com/unitreerobotics/xr_teleoperate #46

SDK/logiciel Bloque l'Utilisation Contournement Disponible

unitree_mujoco simulator crashes with 'free(): invalid pointer' / 'Aborted (core dumped)' at runtime

Symptôme: Après le lancement du binaire du simulateur unitree_mujoco, le programme démarre (« MuJoCo data is prepared ») puis se bloque immédiatement avec « free(): invalid pointer » et « Aborted (core dumped) ». Une variante antérieure de l'erreur était « Joystick open failed ». Plusieurs utilisateurs signalent ce problème sur MuJoCo versions 3.2.7 et 3.3.1.

Touché: unitree_mujoco; MuJoCo 3.2.7 et 3.3.1; Ubuntu 22.04 et Ubuntu 24.04 avec ROS2 Jazzy

Solution / Contournement: Un utilisateur de la communauté a attribué le plantage sur Ubuntu 24.04 / ROS2 Jazzy à un conflit de chemins des bibliothèques DDS (les bibliothèques DDS de ROS2 Jazzy et celles installées par unitree_sdk2 se chargeant simultanément). La résolution du conflit de chemins a corrigé le plantage pour cet utilisateur. L'erreur de joystick a été corrigée dans un commit spécifique (2f5459d). Aucune correction unique confirmée pour toutes les variantes signalées.

Sources : github.com/unitreerobotics/unitree_mujoco #51

batterie/alimentation Bloque l'Utilisation Ouvert / Non Résolu

Le G1 surchauffe et s'éteint après quelques minutes d'exécution de la politique sonic_release, provoquant des chutes

Symptôme: Via le pilote communautaire GR00T-WholeBodyControl : lors du déploiement de la politique sonic_release sur un vrai robot G1 29-DoF équipé de mains Dex3, le robot émet un avertissement de surchauffe après quelques minutes même en restant immobile, puis Sonic s'éteint automatiquement, provoquant de multiples chutes du robot.

Touché: Unitree G1 29-DoF EDU avec mains Dex3; point de contrôle sonic_release GR00T-WholeBodyControl

Solution / Contournement: aucune correction confirmée

Sources : github.com/NVlabs/GR00T-WholeBodyControl #121

SDK/logiciel Bloque l'Utilisation Ouvert / Non Résolu

La session WebSocket se coupe et la vue VR devient noire lors de l'entrée en mode Réalité Virtuelle sur Quest 3

Symptôme: Après avoir connecté avec succès Quest 3 à la page de téléopération (l'interface vuer se charge mais affiche un écran noir), cliquer sur « Virtual Reality » provoque la déconnexion de la session WebSocket. Le terminal affiche la connexion perdue. Un contributeur de la communauté a attribué cela à un bug dans le navigateur Meta Quest 3 où RTCPeerConnection.createOffer() ne résout jamais sa Promise, rompant le flux WebRTC par défaut initié par le client.

Touché: xr_teleoperate; matériel : G1-EDU 29-DoF avec Dex3-1, Meta Quest 3

Solution / Contournement: Un contributeur de la communauté a proposé d'inverser la négociation WebRTC vers un flux initié par le serveur (le serveur crée l'offre, le navigateur appelle createAnswer()) comme solution temporaire. Aucune correction confirmée en amont.

Sources : github.com/unitreerobotics/xr_teleoperate #267

réseau/connectivité Bloque l'Utilisation Contournement Disponible

La communication DDS échoue lorsque le PC hôte se connecte au G1 via Wi-Fi au lieu d'Ethernet

Symptôme: La téléopération fonctionne correctement lorsque l'ordinateur portable est connecté au robot via un câble Ethernet, mais échoue avec des erreurs DDS lors d'une tentative d'exploitation sans fil via Wi-Fi. De plus, lors de l'exécution de tout sur le PC2 du robot (Jetson), des problèmes de connexion apparaissent après environ 10 minutes.

Touché: xr_teleoperate; matériel : Unitree G1 EDU avec mains Inspire FTP et Apple Vision Pro

Solution / Contournement: Le mainteneur suggère d'utiliser un proxy de transfert DDS au niveau application, ou de monter un routeur à l'arrière du G1 (sous-réseau 192.168.123.*/24) alimenté par l'interface d'alimentation du G1. Aucune correction complète unique confirmée.

Sources : github.com/unitreerobotics/xr_teleoperate #234

Besoin d'aide professionnelle avec votre Unitree G1 ?

Rejoignez la liste d'attente pour réparation et nous vous mettrons en contact avec des techniciens certifiés et des partenaires de service.

Join the Repair Waitlist →