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

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

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

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

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

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

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

Symptom: After launching the unitree_mujoco simulator binary, the program starts ('MuJoCo data is prepared') and then immediately crashes with 'free(): invalid pointer' and 'Aborted (core dumped)'. An earlier variant of the error was 'Joystick open failed'. Multiple users report this across MuJoCo versions 3.2.7 and 3.3.1. Fix: One community user traced the crash on Ubuntu 24.04 / ROS2 Jazzy to a DDS library path conflict (ROS2 Jazzy's DDS libraries and unitree_sdk2-installed DDS libraries loaded simultaneously). Resolving the path conflict fixed the crash for that user. The joystick error was fixed in a specific commit (2f5459d). No single confirmed fix for all reported variants.

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: Problemas Conhecidos & Correções

Última atualização August 23, 2026

38 problemas conhecidos View robot profile →

Aviso de Garantia & Segurança: A garantia inicia no recebimento. O proprietário envia a unidade à Unitree por sua própria conta para diagnóstico. A garantia é ANULADA ao abrir oshell, desmontar ou modificar sem autorização. Não há canal de peças de reposição para consumidores; os revendedores oferecem suporte de primeiro nível apenas. G1 base ~8 meses; G1 EDU ~18 meses (EU 24 meses). Fontes: https://www.unitree.com/mobile/terms/policy https://blog.robozaps.com/b/unitree-g1-review As alternativas listadas abaixo são contribuídas pela comunidade e fornecidas sem garantia.

motor/atuador Bloqueia o Uso Alternativa Existe

Motores da perna/quadril/tornozelo superaquecem e forçam desligamento

Sintoma: Os motores de rolagem do tornozelo atingem ~90°C em 5-10 minutos mesmo em estado quase ocioso; a articulação esquerda do quadril superaquece após ~30 minutos de teleoperação e dispara um desligamento automático do sistema.

Afetado: Relatado com controladores de corpo inteiro de terceiros (NVIDIA GEAR-SONIC / Isaac-GR00T N1.7 em Jetson Orin NX). O controlador original da Unitree mantém os tornozelos a 30-45°C.

Correção / Alternativa: O superaquecimento está ligado a ganhos agressivos do controlador, nem sempre uma falha de hardware. Reduza os ganhos Kp/Kd, ajuste a postura em pé para diminuir a carga estática e prefira o controlador original da Unitree para execuções prolongadas. Se as temperaturas dispararem também no controlador original, pare de usar e inspecione — um atuador genuinamente com falha precisa de manutenção.

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

motor/atuador Degrada o Uso Aberto / Não Resolvido

Motor do ombro/braço superaquece e fica frouxo com mão dexterous Inspire

Sintoma: O motor do braço de inclinação do ombro superaquece após operação breve e o braço perde responsividade quando pareado com a mão dexterous FTP Inspire.

Afetado: G1 ARM7 + mão Inspire FTP, ROS2 Humble; usuários executando ganhos PD kp=40 / kd=1.5.

Correção / Alternativa: Nenhuma correção do fornecedor documentada. Orientação da comunidade: o braço precisa de compensação de gravidade/carga para a massa adicional da mão e limites de torque mais baixos; os proprietários ainda buscam os ganhos PD recomendados pela Unitree para este pareamento. Trate como um problema de sintonia antes de assumir falha de hardware.

Fontes: github.com/unitreerobotics/unitree_sdk2_python #129

firmware/atualização Incômodo Alternativa Existe

Robô ignora comandos SDK (travado em modo damp / develop)

Sintoma: G1 inicia em 'modo damp' e ignora comandos SDK; entrar no 'modo develop' também desabilita a responsividade do SDK, então os usuários concluem que o SDK está quebrado.

Afetado: Comportamento geral do firmware G1.

Correção / Alternativa: Ative o robô com o controle remoto antes de enviar comandos SDK: pressione L1+A, depois L1+UP para sair do modo damp. Não fique no modo develop se precisar de controle SDK. Se entrou no modo develop, renove o cliente ai-sport pelo aplicativo.

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

SDK/software Degrada o Uso Corrigido pelo Fornecedor

WaveHand / ShakeHand falham via SDK (erro 3203 'API não implementada')

Sintoma: As ações de braço WaveHand e ShakeHand funcionam no controle remoto mas falham via Python/C++/ROS2; ROS2 retorna erro 3203 'API não implementada no servidor'.

Afetado: Firmware antes da v1.3.0.

Correção / Alternativa: Atualize o firmware do robô para v1.3.0 ou posterior. Também certifique-se de que o robô está ativado fora do modo damp (L1+A, L1+UP) antes de issuing the commands.

Fontes: github.com/unitreerobotics/unitree_sdk2_python #42

firmware/atualização Bloqueia o Uso Aberto / Não Resolvido

Código e exemplos oficiais quebram após firmware 1.4.0 ('ClientStub send request error')

Sintoma: Código Python anteriormente funcional e exemplos oficiais do SDK param de funcionar após atualização para firmware 1.4.0; '[ClientStub] send request error' repetido. Relacionado: GetVolume retorna erro 3102, exemplos de alto nível/áudio falham.

Afetado: Firmware 1.4.0.

Correção / Alternativa: Nenhuma correção do fornecedor documentada. Confirme que o robô está ativado (fora do modo damp), verifique se a versão do SDK corresponde ao firmware, e se você atualizou especificamente para um recurso, esteja ciente de que alguns usuários fizeram rollback. Acompanhe as notas de lançamento da Unitree para um patch subsequente.

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

mão/garra Bloqueia o Uso Alternativa Existe

Mão Inspire não abre porta serial / inacessível em seu IP

Sintoma: 'Falha ao abrir porta serial /dev/ttyUSB0' — a mão Inspire não pode ser controlada; ou a mão FTP é inacessível em 192.168.123.211.

Afetado: G1 com mão Inspire (variantes serial DFX vs FTP modbus-TCP).

Correção / Alternativa: O método de controle depende da variante da mão. Mãos Inspire FTP usam Modbus TCP, não porta serial — usar código serial em uma mão FTP falha por design. Confirme qual variante você tem e use o método de controle correspondente; verifique se o IP da mão está acessível na rede 192.168.123.x.

Fontes: github.com/unitreerobotics/xr_teleoperate #51

mão/garra Degrada o Uso Aberto / Não Resolvido

Polegar da mão Dex3-1 mal se move durante teleoperação

Sintoma: Em teleop o polegar faz apenas movimentos micrométricos de 3-4° versus amplitude total na simulação; o pinçamento polegar-indicador bottoms out em ~5cm, muito grosseiro para manipulação fina.

Afetado: Software G1 V1.4.7 + mão Dex3-1.

Correção / Alternativa: Nenhuma correção documentada. O auto-teste de inicialização mostra juntas normais e simulação funciona, o que aponta para uma incompatibilidade de mapeamento de comandos entre teleop e o driver da mão em vez de hardware. Reporte a versão do driver à Unitree.

Fontes: github.com/unitreerobotics/xr_teleoperate #229

rede/conectividade Degrada o Uso Aberto / Não Resolvido

Latência de teleoperação cresce para ~2.5s após 1-2 horas

Sintoma: A latência do braço e câmera sobe para ~2.5s após teleop prolongada; a pose de preparação do braço leva ~4s em vez de ~2s, eventualmente aparecendo imediatamente ao iniciar.

Afetado: xr_teleoperate v1.3 e v1.5.

Correção / Alternativa: Nenhuma correção documentada. Atualizar para roteador gigabit e WiFi 6 não ajudou, e o modo simulação não é afetado — sugerindo um problema de buffering/acumulação embarcado em vez da rede. Reinicie a stack de teleop entre sessões longas como medida temporária.

Fontes: github.com/unitreerobotics/xr_teleoperate #247

rede/conectividade Degrada o Uso Alternativa Existe

Implantação de política via WiFi trava em 'Esperando conexão rt/lowstate'

Sintoma: A implantação via WiFi trava em 'Esperando conexão rt/lowstate' mesmo que SSH ao robô funcione; ethernet com fio funciona normalmente.

Afetado: G1, controle baseado em DDS.

Correção / Alternativa: Use uma conexão com fio e especifique a interface, ex: ./g1_ctrl --network enx701988512412. O multicast DDS para lowstate não atravessa a interface wireless de forma confiável.

Fontes: github.com/unitreerobotics/unitree_rl_lab #93

SDK/software Bloqueia o Uso Alternativa Existe

Incompatibilidade de versão do CycloneDDS trava a inicialização da simulação do G1

Sintoma: Falha de assertion DDS / erro do escritor CycloneDDS ao inicializar a simulação do G1; não inicia.

Afetado: Ubuntu 22.04, ROS2 Humble; CycloneDDS do sistema 0.10.5 vs CycloneDDS Python 0.10.2.

Correção / Alternativa: Não sourcing o script de setup do ROS (suas libs DDS diferem das do unitree_sdk2). Verifique qual .so está linkado em tempo de compilação. Alternativas: compile CycloneDDS 0.10.2 do zero, faça patch do unitree-sdk2py para 0.10.5, ou desenvolva no Ubuntu 20.04.

Fontes: github.com/unitreerobotics/unitree_mujoco #60

SDK/software Bloqueia o Uso Alternativa Existe

'Tipo de robô incompatível' na conexão Ethernet (23 vs 29 DOF)

Sintoma: O controlador se conecta via Ethernet e então falha imediatamente com 'Tipo de robô incompatível' durante o deployment sim-to-real.

Afetado: Variantes G1 23-DOF e 29-DOF (incl. configurações de cintura bloqueada/mãos dummy).

Correção / Alternativa: O DOF/config do robô deve corresponder ao tipo esperado pelo controlador. Defina o DOF correto na sua configuração e verifique instalações conflitantes do SDK em /usr/local vs seu diretório de projeto — recompilar unitree_sdk2 corretamente (build deploy com -DBUILD_EXAMPLES=OFF, build sim com CMAKE_INSTALL_PREFIX separado) resolve o caso relacionado de modo de velocidade não responsivo.

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

SDK/software Degrada o Uso Aberto / Não Resolvido

Mover braços via SDK durante caminhada desestabiliza o equilíbrio

Sintoma: Controlar os braços via SDK enquanto caminha (gamepad) faz o robô curvar para frente ou perder o equilíbrio; levantar os braços durante a caminhada produz um andar instável e pesado.

Afetado: G1 com cintura 3-DOF.

Correção / Alternativa: Nenhuma correção documentada. Zerar eixos da cintura, manter valores iniciais e deixá-los intocados foram tentados sem sucesso — o controlador SDK dos braços e o controlador de equilíbrio de locomoção conflitam. Evite grandes movimentos de braços durante locomoção até uma atualização de firmware abordar isso.

Fontes: github.com/unitreerobotics/unitree_sdk2_python #146

SDK/software Degrada o Uso Alternativa Existe

G1 simulado colapsa sem estabilização padrão

Sintoma: Na simulação MuJoCo o G1 não tem estabilização padrão e cai quando executado sem controles.

Afetado: unitree_mujoco.

Correção / Alternativa: Habilite a banda elástica: defina enable_elastic_band: 1 em unitree_mujoco/simulate/config.yaml (ou ENABLE_ELASTIC_BAND=True). Note que o controlador de movimento de fábrica não está disponível na sim, e a banda pode ser difícil de desabilitar ao trocar para controle por joystick.

Fontes: github.com/unitreerobotics/unitree_mujoco #57

bateria/energia Incômodo Não claro

Autonomia curta da bateria (~2 horas)

Sintoma: A bateria de 9.000 mAh fornece apenas cerca de 2 horas por carga, e descarrega mais rápido sob movimento dinâmico.

Afetado: Modelo base, pack de 9.000 mAh.

Correção / Alternativa: Esta é uma limitação de capacidade, não um defeito. Mantenha baterias reservas carregadas para hot-swap entre sessões; budget runtime de cerca de ~2 horas de uso ativo.

Fontes: blog.robozaps.com/b/…

outro Bloqueia o Uso Não claro

G1 base não pode ser programado — sem SDK

Sintoma: Compradores do G1 base ~$13.500 descobrem que é uma unidade de demonstração/showcase sem SDK e não pode ser programada.

Afetado: G1 base (23 DOF) vs G1 EDU (até 43 DOF).

Correção / Alternativa: Esta é uma limitação de tier do produto. Acesso ao SDK, torque mais alto e mais DOF requerem a plataforma G1 EDU / desenvolvedor (~$44k-$74k). Confirme o tier antes da compra se você pretende desenvolver.

Fontes: blog.robozaps.com/b/…

mecânico/estrutural Bloqueia o Uso Alternativa Existe

LED vermelho sólido / lista de verificação de falha física (quedas, cabos, bateria)

Sintoma: LED vermelho sólido indicando erro de software/hardware; mais falhas de campo — rachaduras/amassados de quedas, degradação de sensores por poeira ou desalinhamento, componentes não responsivos por cabos soltos/desfiados, bateria inchada ou deformada.

Afetado: Geral.

Correção / Alternativa: Inspecione visualmente quanto a danos de impacto; limpe sensores e confirme montagem; reconecte cabos e conectores; verifique assentamento da bateria e substitua se inchada ou vazando. Em LED vermelho sólido, execute o diagnóstico pelo app móvil e grave um vídeo de qualquer falha intermitente antes de contatar suporte. Nota: abrir a carcaça anula a garantia.

Fontes: docs.westonrobot.com/tutorial/…

segurança/privacidade Bloqueia o Uso Aberto / Não Resolvido

Segurança crítica: injeção de comandos BLE com chaves hardcoded (UniPwn)

Sintoma: Uma falha de injeção de comandos no BLE Wi-Fi provisioning, usando chaves AES hardcoded compartilhadas entre todas as unidades, permite acesso root e é potencialmente wormable. Pesquisa separada encontrou telemetria transmitida para servidores externos a cada ~5 minutos.

Afetado: G1 (pesquisadores indicam que Go2/H1 compartilham caminhos de código). Exploit público 'UniPwn' liberado.

Correção / Alternativa: Nenhum patch de vendor confirmado documentado no momento da escrita. Mitigue em nível de rede: isole o robô em uma rede segmentada/com firewall, restrinja acesso à sua interface interna (192.168.123.0/24), e bloqueie tráfego de saída inesperado. Fique atento a um advisory de firmware da Unitree.

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

outro Incômodo Não claro

Habilidades virais são coreografadas, não autônomas

Sintoma: Clipes de kung-fu e backflip são demonstrações treinadas; o robô não tem autonomia doméstica fora da caixa e falha em tarefas simples como abrir uma porta.

Afetado: Geral.

Correção / Alternativa: Definição de expectativas, não uma falha. Desempenho de tarefas autônomas requer desenvolvimento significativo na plataforma EDU; a experiência base é de movimentos remotos/pre-programados.

Fontes: blog.robozaps.com/b/…

SDK/software Bloqueia o Uso Corrigido pelo Fornecedor

Robô G1 23-DOF move-se erraticamente em Sim2Sim no MuJoCo

Sintoma: Ao executar Sim2Sim no MuJoCo com uma política treinada no Isaac Lab para a configuração G1 23-DOF, o robô não consegue andar corretamente e move-se erraticamente. A causa suspeita relatada na discussão é que os IDs dos motores não foram adaptados para a versão 23-DOF.

Correção / Alternativa: O fornecedor (Agnel-Wang) adicionou código de deploy de 23-DOF ao repositório; o relator confirmou Sim2Real bem-sucedido após usar o código atualizado.

Fontes: github.com/unitreerobotics/unitree_rl_lab #27

rede/conectividade Bloqueia o Uso Aberto / Não Resolvido

G1_29_ArmController imprime repetidamente 'Aguardando assinatura dds' e o aplicativo do robô relata falha de comunicação de firmware

Sintoma: Ao executar o script de teleoperação, o controlador entra em loop infinito imprimindo '[G1_29_ArmController] Aguardando assinatura dds...' e o aplicativo móvel reporta '底层固件通信故障' (falha de comunicação de firmware de baixo nível). A comunicação DDS entre o dispositivo host e o robô não é estabelecida apesar dos dispositivos estarem na mesma rede.

Correção / Alternativa: O mantenedor sugere verificar a conectividade de rede com 'cyclonedds ps' e 'cyclonedds subscribe rt/lowstate'; se não resolver, envie um ticket de suporte. Um comentarista relata que exemplos de baixo nível funcionaram, mas exemplos de braço de alto nível não produziram movimento do robô e geraram erros de envio de requisição.

Fontes: github.com/unitreerobotics/xr_teleoperate #57

rede/conectividade Bloqueia o Uso Aberto / Não Resolvido

WebSocket do Apple Vision Pro desconecta imediatamente em cada carregamento de página na configuração de teleoperação

Sintoma: Ao acessar o servidor de teleoperação pelo Safari do Apple Vision Pro, o WebSocket conecta mas desconecta imediatamente em cada carregamento de página, produzindo 'AssertionError: Websocket session is missing.' no servidor. Atualizar a página repete o ciclo de conexão/desconexão; as únicas soluções alternativas encontradas são remover o headset AVP ou fechar completamente o Safari e esperar alguns segundos.

Afetado: vuer 0.0.60, televuer 4.0.0, xr_teleoperate commit 9fadc51, visionOS mais recente

Correção / Alternativa: Conexão temporariamente estável obtida ao remover o AVP ou fechar completamente o Safari por alguns segundos. O mantenedor sugeriu tentar 'https://vuer.ai/?ws=wss://host ip:8012', mas nenhuma correção confirmada foi fornecida.

Fontes: github.com/unitreerobotics/xr_teleoperate #271

SDK/software Bloqueia o Uso Aberto / Não Resolvido

Política WBC transmite valores, mas o G1 real não se move após calibração das mãos

Sintoma: Via driver comunitário GR00T-WholeBodyControl: após o robô entrar no modo de depuração e as mãos calibrararem com sucesso, o G1 não se move de forma alguma apesar do terminal mostrar a política transmitindo valores para o robô. Nenhum erro é reportado e a simulação paralela funciona corretamente.

Correção / Alternativa: Sem correção confirmada

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

SDK/software Degrada o Uso Aberto / Não Resolvido

Feed de imagem do Vuer congela no primeiro quadro no Quest 3 durante teleoperação com robô real

Sintoma: Ao executar o pipeline de teleoperação com headset Quest 3, o display Vuer mostra apenas o primeiro quadro capturado e então congela, enquanto o cliente de imagem no PC confirma que o feed de câmera ao vivo está funcionando corretamente. O problema foi reproduzido tanto na branch principal quanto com a branch teleimager.

Afetado: vuer 0.0.67, xr_teleoperate (modo controlador, G1_29)

Correção / Alternativa: O mantenedor sugeriu trocar para a branch teleimager (streaming WebRTC); o relator aplicou a branch, mas observou que ela não suporta deploy em simulação. Nenhuma correção totalmente confirmada para o problema de quadro congelado.

Fontes: github.com/unitreerobotics/xr_teleoperate #172

rede/conectividade Bloqueia o Uso Aberto / Não Resolvido

Página de teleoperação fica preta e WebSocket desconecta ao entrar no modo VR no Apple Vision Pro

Sintoma: Após o Vision Pro exibir com sucesso o feed da câmera binocular, clicar em 'realidade virtual' e conceder permissão de rastreamento de mãos faz a tela ficar preta e o WebSocket desconectar imediatamente, gerando 'AssertionError: Websocket session is missing.' O traceback do erro se origina em vuer/server.py.

Correção / Alternativa: O mantenedor sugeriu usar apenas Wi-Fi 5 GHz, monitorar a latência de ping para o AVP (deve ser inferior a 50 ms), testar com o script televuer diretamente e tentar a versão vuer 0.0.32rc7. Nenhuma correção confirmada relatada.

Fontes: github.com/unitreerobotics/xr_teleoperate #115

SDK/software Bloqueia o Uso Alternativa Existe

G1 não anda quando comando de locomoção é enviado via controlador de teleoperação; entrada do joystick ignorada

Sintoma: Ao usar o modo controlador do script de teleoperação com a flag --motion, o controle de braço funciona corretamente, mas o robô não responde aos comandos do joystick para andar. Mesmo após sair do programa, o controle remoto físico também não consegue fazer o robô andar, embora os gestos de braço continuem funcionando normalmente.

Afetado: Versão do ai_sport não especificada; xr_teleoperate, G1_29

Correção / Alternativa: O mantenedor identificou que o nome do serviço de locomoção do ai_sport mudou na versão 8.2.0.0 (LOCO_SERVICE_NAME deve ser 'sport' para >=8.2.0.0, 'loco' para versões anteriores). Também recomendou especificar o nome correto da interface de rede no código se estiver executando em um dispositivo com múltiplas NICs. O mantenedor confirmou que a locomoção funcionou em seu robô com a versão 8.4.0.0 após uma atualização via git pull.

Fontes: github.com/unitreerobotics/xr_teleoperate #77

Show all 38 issues

SDK/software Bloqueia o Uso Aberto / Não Resolvido

Juntas do G1 não se movem após o programa de teleoperação iniciar e 'r' ser pressionado

Sintoma: O programa de teleoperação inicia sem erros, DDS parece conectar e o AVP exibe o feed de câmera ao vivo com rastreamento de braço, mas o robô G1 não se move quando o programa está em execução e após pressionar 'r' para iniciar. A saída de posição das juntas está ausente do log, diferente do comportamento esperado. A entrada no modo de depuração a partir do programa é relatada como inconsistente.

Afetado: G1 29-DOF com mãos Inspire dftp, AVP

Correção / Alternativa: Sem correção confirmada

Fontes: github.com/unitreerobotics/xr_teleoperate #189

SDK/software Bloqueia o Uso Aberto / Não Resolvido

Headset VR mostra apenas grade azul, robô não visível na simulação de teleoperação XR

Sintoma: Ao executar teleoperação XR em simulação com Meta Quest 3, o usuário entra com sucesso no modo VR, mas vê apenas grades azuis em vez do robô. O terminal da simulação também mostra '[DDSManager] object g1 not found' e 'g1_robot_dds is not initialized'.

Afetado: unitree_sim_isaaclab com tarefa Isaac-PickPlace-Cylinder-G129-Dex3-Joint; xr_teleoperate teleop_hand_and_arm.py; Meta Quest 3

Correção / Alternativa: Sem correção confirmada

Fontes: github.com/unitreerobotics/xr_teleoperate #112

SDK/software Bloqueia o Uso Alternativa Existe

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

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

Afetado: unitree_rl_lab (latest); Isaac Sim + Isaac Lab; unitree_mujoco with G1 29dof; simulate_python (not simulate with C++)

Correção / Alternativa: 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.

Fontes: github.com/unitreerobotics/unitree_rl_lab #31

SDK/software Bloqueia o Uso Alternativa Existe

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

Sintoma: Executar unitree_mujoco.py para G1 (ou H1 com mãos Inspire) gera '[RecurrentThread] target func raise exception: name=IndexError, args=("list index out of range",)' em tempo de execução. O erro ocorre ao tentar simular o robô com anexos de mão.

Afetado: unitree_mujoco; G1 com mão (scene_29dof_with_hand.xml); H1 com mãos Inspire

Correção / Alternativa: Solução da comunidade: use scene_29dof.xml em vez de scene_29dof_with_hand.xml. Separadamente, certifique-se de que o nome do ROBOT em config.py seja exatamente um dos nomes suportados (ex.: 'g1') e não uma variante como 'g1_23dof'.

Fontes: github.com/unitreerobotics/unitree_mujoco #52

SDK/software Bloqueia o Uso Aberto / Não Resolvido

Comandos SDK de alto nível retornam 'send request error' no G1; comandos de baixo nível funcionam

Sintoma: Ao executar comandos SDK de alto nível (ex.: g1_loco_client_example.py), o cliente exibe '[ClientStub] send request error. id: <id>' e o comando não é executado. Scripts de baixo nível (g1_low_level_example.py) funcionam corretamente.

Afetado: unitree_sdk2_python; G1 robot; g1_loco_client_example.py; comandos de alto nível

Correção / Alternativa: Sem correção confirmada

Fontes: github.com/unitreerobotics/unitree_sdk2_python #54

SDK/software Bloqueia o Uso Alternativa Existe

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

Sintoma: Ao usar xr_teleoperate com um Meta Quest 3, a conexão WebSocket com a página Vuer na porta 8012 cai imediatamente ao clicar no botão Realidade Virtual, exibindo 'websocket is now disconnected' e 'AssertionError: Websocket session is missing.' O problema é específico do modo de entrada com rastreamento de mãos; alternar para o modo de entrada com controle mantém a conexão ativa.

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

Correção / Alternativa: Solução alternativa da comunidade: retroceder o xr_teleoperate para a v1.0 resolve a desconexão. Alternativamente, mudar para --input-mode=controller mantém o WebSocket conectado. Usar o navegador Wolvic em vez do navegador padrão do Meta Quest também previne a desconexão do WebSocket, embora problemas de streaming de câmera permaneçam.

Fontes: github.com/unitreerobotics/xr_teleoperate #296

SDK/software Bloqueia o Uso Aberto / Não Resolvido

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

Sintoma: Ao acessar a interface de teleoperação via endereço IP local (https://<host-ip>:8012?ws=wss://<host-ip>:8012), a página não carrega ou exibe uma tela preta. Ao entrar no modo VR/pass-through (WebXR), a conexão WebSocket cai e o robô para de receber dados de rastreamento, com o servidor reportando 'Websocket session is missing' e ocasionalmente aiohttp 'resume_writing() AssertionError'.

Afetado: vuer 0.0.60, televuer 4.0.0; hardware: Unitree G1 29-DoF EDU com Inspire RH56DFTP, Meta Quest 3 e Apple Vision Pro (visionOS 26.4)

Correção / Alternativa: O mantenedor sugere verificar se o IP do host está incluído no campo SAN do certificado, usar navegação anônima/privada e experimentar combinações vuer/televuer com versões fixas. Um colaborador da comunidade identificou que o RTCPeerConnection.createOffer() do Quest browser nunca resolve e propôs um fluxo WebRTC iniciado pelo servidor como solução alternativa, mas isso não foi oficialmente upstreamado. Sem correção confirmada do fornecedor.

Fontes: github.com/unitreerobotics/xr_teleoperate #297

SDK/software Bloqueia o Uso Alternativa Existe

O programa de teleoperação encerra automaticamente logo após o robô levantar os braços quando o Inspire FTP hand está habilitado

Sintoma: Ao iniciar teleop_hand_and_arm.py com a mão dexterous Inspire FTP habilitada (--ee=inspire_ftp), o robô levanta levemente ambos os braços e então o programa encerra automaticamente, abaixando os braços. O log mostra que o cliente de imagem fecha inesperadamente e o programa sai sem uma mensagem de erro clara.

Afetado: xr_teleoperate; hardware: Unitree G1 29-DoF com mãos hábeis Inspire FTP

Correção / Alternativa: 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.

Fontes: github.com/unitreerobotics/xr_teleoperate #194

mão/garra Bloqueia o Uso Corrigido pelo Fornecedor

Ambas as mãos hábeis Inspire espelham apenas o movimento da mão direita devido a configuração incorreta da porta serial

Sintoma: Durante a teleoperação com duas mãos hábeis Inspire, ambas as mãos seguem apenas o movimento da mão direita. A causa raiz identificada na discussão é que o código de exemplo envia comandos para ambas as mãos para a mesma porta serial.

Afetado: Unitree G1 com mãos habilidosas Inspire DFX / RH56DFTP; código de exemplo inspire_ctrl.cpp do pacote de exemplo do fornecedor

Correção / Alternativa: Correção identificada pela comunidade confirmada pelo mantenedor: modificar inspire_ctrl.cpp para inicializar duas portas seriais separadas (serial1 = /dev/ttyUSB1, serial2 = /dev/ttyUSB2) e associar cada mão à sua porta e ID respectivos. O fornecedor forneceu o código corrigido de inspire_ctrl.cpp nos comentários.

Fontes: github.com/unitreerobotics/xr_teleoperate #46

SDK/software Bloqueia o Uso Alternativa Existe

simulador unitree_mujoco trava com 'free(): ponteiro inválido' / 'Abortado (core dumped)' em tempo de execução

Sintoma: Após iniciar o binário do simulador unitree_mujoco, o programa inicia ('MuJoCo data is prepared') e então trava imediatamente com 'free(): invalid pointer' e 'Aborted (core dumped)'. Uma variante anterior do erro era 'Joystick open failed'. Múltiplos usuários relatam isso nas versões MuJoCo 3.2.7 e 3.3.1.

Afetado: unitree_mujoco; MuJoCo 3.2.7 e 3.3.1; Ubuntu 22.04 e Ubuntu 24.04 com ROS2 Jazzy

Correção / Alternativa: Um usuário da comunidade rastreou o crash no Ubuntu 24.04 / ROS2 Jazzy até um conflito de caminho da biblioteca DDS (bibliotecas DDS do ROS2 Jazzy e bibliotecas DDS instaladas pelo unitree_sdk2 carregadas simultaneamente). Resolver o conflito de caminho corrigiu o crash para esse usuário. O erro do joystick foi corrigido em um commit específico (2f5459d). Nenhuma correção única confirmada para todas as variantes relatadas.

Fontes: github.com/unitreerobotics/unitree_mujoco #51

bateria/energia Bloqueia o Uso Aberto / Não Resolvido

G1 superaquece e desliga após alguns minutos executando a política sonic_release, causando quedas

Sintoma: Via driver comunitario GR00T-WholeBodyControl: Ao implementar a política sonic_release em um robô G1 real de 29-DoF equipado com mãos Dex3, o robô emite um aviso de superaquecimento após alguns minutos mesmo enquanto está parado em pé, então o Sonic desliga automaticamente, causando quedas repetidas do robô.

Afetado: Unitree G1 29-DoF EDU com mãos Dex3; checkpoint sonic_release do GR00T-WholeBodyControl

Correção / Alternativa: Sem correção confirmada

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

SDK/software Bloqueia o Uso Aberto / Não Resolvido

Sessão WebSocket cai e visualização VR fica preta ao entrar no modo Realidade Virtual no Quest 3

Sintoma: Após conectar o Quest 3 com sucesso à página de teleoperação (interface vuer carrega mas mostra uma tela preta), clicar em 'Realidade Virtual' faz a sessão WebSocket desconectar. O terminal mostra que a conexão caiu. Um contribuidor da comunidade rastreou isso até um bug no navegador do Meta Quest 3 onde RTCPeerConnection.createOffer() nunca resolve sua Promise, quebrando o fluxo WebRTC padrão iniciado pelo cliente.

Afetado: xr_teleoperate; hardware: G1-EDU 29-DoF com Dex3-1, Meta Quest 3

Correção / Alternativa: Contribuidor da comunidade propôs reverter a negociação WebRTC para um fluxo iniciado pelo servidor (servidor cria offer, navegador chama createAnswer()) como solução alternativa. Nenhuma correção upstream confirmada.

Fontes: github.com/unitreerobotics/xr_teleoperate #267

rede/conectividade Bloqueia o Uso Alternativa Existe

Comunicação DDS falha quando PC host se conecta ao G1 via Wi-Fi em vez de Ethernet

Sintoma: A teleoperação funciona corretamente quando o laptop está conectado ao robô via cabo Ethernet, mas falha com erros DDS ao tentar operar sem fio via Wi-Fi. Além disso, ao executar tudo no PC2 do robô (Jetson), problemas de conexão aparecem após aproximadamente 10 minutos.

Afetado: xr_teleoperate; hardware: Unitree G1 EDU com mãos Inspire FTP e Apple Vision Pro

Correção / Alternativa: O mantenedor sugere usar um proxy de encaminhamento DDS na camada de aplicação, ou montar um roteador nas costas do G1 (sub-rede 192.168.123.*/24) alimentado pela interface de energia do G1. Nenhuma correção única e completa confirmada.

Fontes: github.com/unitreerobotics/xr_teleoperate #234

Precisa de ajuda profissional com seu Unitree G1?

Junte-se à lista de espera de reparo e nós conectaremos você com técnicos certificados e parceiros de serviço.

Join the Repair Waitlist →