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.

'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

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

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

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

Symptom: When accessing the teleoperation interface via the local IP address (https:// :8012?ws=wss:// :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'. Fix: 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.

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 Conocidos y Soluciones

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

Última actualización 23 de agosto de 2026

38 problemas conocidos View robot profile →

Aviso de Garantía y Seguridad: La garantía comienza al recibir el producto. El propietario envía la unidad a Unitree por su cuenta para el diagnóstico. La garantía se ANULA al abrir la carcasa, desarmar o modificar sin autorización. No hay canal de repuestos para consumidores; los distribuidores proporcionan soporte de primer nivel únicamente. G1 base ~8 meses; G1 EDU ~18 meses (UE 24 meses). Fuentes: https://www.unitree.com/mobile/terms/policy https://blog.robozaps.com/b/unitree-g1-review Las soluciones alternativas listadas son proporcionadas por la comunidad sin garantía.

motor/actuador Bloquea el Uso Solución Alternativa Existe

Motores de pierna/cadera/tobillo se sobrecalientan y forz ... nte en modo damp / develop)

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

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

Corrección / Solución alternativa: El sobrecalentamiento está relacionado con ganancias agresivas del controlador, no siempre es un fallo de hardware. Reduce las ganancias Kp/Kd, ajusta la postura de pie para disminuir la carga estática, y utiliza el controlador de serie de Unitree para sesiones prolongadas. Si las temperaturas también aumentan con el controlador de serie, deja de usarlo e inspecciona — un actuador que realmente falla necesita servicio.

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

motor/actuador Uso degradado Abiertos / Sin resolver

El motor del hombro/brazo se sobrecalienta y pierde fuerza con la Inspire dexterous hand

Symptom: El motor del brazo shoulder-pitch se sobrecalienta tras un funcionamiento breve y el brazo pierde capacidad de respuesta cuando se combina con la mano diestra Inspire FTP.

Affected: G1 ARM7 + Inspire FTP hand, ROS2 Humble; usuarios ejecutando ganancias PD kp=40 / kd=1.5.

Corrección / Solución alternativa: No hay corrección documentada por el proveedor. Dirección de la comunidad: el brazo necesita compensación de gravedad/carga útil para la masa adicional de la mano y límites de torque más bajos; los propietarios aún buscan las ganancias PD recomendadas por Unitree para esta combinación. Tratar como un problema de ajuste antes de asumir una falla de hardware.

Fuentes: github.com/unitreerobotics/unitree_sdk2_python #129

firmware/actualización Molestia Solución Alternativa Existe

El robot ignora los comandos del SDK (atascado en modo damp / develop)

Symptom: G1 arranca en 'modo damp' e ignora comandos SDK; entrar en 'modo develop' también deshabilita la respuesta del SDK, por lo que los usuarios concluyen que el SDK está roto.

Affected: Comportamiento general del firmware G1.

Corrección / Solución alternativa: Activa el robot con el control remoto antes de enviar comandos SDK: presiona L1+A, luego L1+UP para salir del modo damp. No permanezcas en modo develop si necesitas control SDK. Si entraste en modo develop, renueva el cliente ai-sport vía la app.

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

SDK/software Uso degradado Corregido por Vendor

WaveHand / ShakeHand fallan desde SDK (error 3203 'API no implementada')

Symptom: Las acciones de brazos WaveHand y ShakeHand funcionan desde el control remoto pero fallan desde Python/C++/ROS2; ROS2 devuelve error 3203 'API no implementada en servidor'.

Affected: Firmware anterior a v1.3.0.

Corrección / Solución alternativa: Actualiza el firmware del robot a v1.3.0 o posterior. También asegúrate de que el robot esté activado fuera del modo damp (L1+A, L1+UP) antes de issuing los comandos.

Fuentes: github.com/unitreerobotics/unitree_sdk2_python #42

firmware/actualización Bloquea el Uso Abiertos / Sin resolver

Código y ejemplos oficiales fallan después de firmware 1.4.0 ('ClientStub send request error')

Symptom: Código Python previamente funcional y ejemplos oficiales del SDK dejan de funcionar después de actualizar a firmware 1.4.0; '[ClientStub] send request error' repetido. Relacionado: GetVolume devuelve error 3102, ejemplos de audio/alto nivel fallan.

Affected: Firmware 1.4.0.

Corrección / Solución alternativa: Sin corrección documentada por el proveedor. Confirma que el robot esté activado (fuera del modo damp), verifica que la versión del SDK coincida con el firmware, y si actualizaste específicamente por una función, ten en cuenta que algunos usuarios revertieron. Observa las notas de lanzamiento de Unitree para un parche siguiente.

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

mano/garra Bloquea el Uso Solución Alternativa Existe

Mano Inspire no abre puerto serial / es inalcanzable en su IP

Symptom: 'Open Serial port /dev/ttyUSB0 failed' — la mano Inspire no puede ser controlada; o la mano FTP es inalcanzable en 192.168.123.211.

Affected: G1 con mano Inspire (variantes serial DFX vs FTP modbus-TCP).

Corrección / Solución alternativa: El método de control depende de la variante de la mano. Las manos Inspire FTP usan Modbus TCP, no un puerto serial — usar código serial en una mano FTP falla por diseño. Confirma qué variante tienes y usa el método de control correspondiente; verifica que la IP de la mano sea alcanzable en la red 192.168.123.x.

Fuentes: github.com/unitreerobotics/xr_teleoperate #51

mano/garra Uso degradado Abiertos / Sin resolver

Pulgar de mano Dex3-1 apenas se mueve durante teleoperación

Symptom: En teleop el pulgar solo hace micro-movimientos de 3-4° versus rango completo en simulación; pellizco pulgar-índice se bottom out en ~5cm, demasiado burdo para manipulación fina.

Affected: Software G1 V1.4.7 + mano Dex3-1.

Corrección / Solución alternativa: Sin corrección documentada. La auto-revisión al encender muestra articulaciones normales y la simulación funciona, lo que apunta a una discordancia de mapeo de comandos entre teleop y el driver de la mano en lugar de hardware. Reporta la versión del driver a Unitree.

Fuentes: github.com/unitreerobotics/xr_teleoperate #229

red/conectividad Uso degradado Abiertos / Sin resolver

Latencia de teleoperación crece a ~2.5s después de 1-2 horas

Symptom: Latencia de brazo y cámara sube a ~2.5s después de teleop prolongado; pose de preparación del brazo toma ~4s en lugar de ~2s, eventualmente apareciendo inmediatamente al encender.

Affected: xr_teleoperate v1.3 y v1.5.

Corrección / Solución alternativa: Sin corrección documentada. Actualizar a router gigabit y WiFi 6 no ayudó, y el modo simulación no está afectado — sugiriendo un problema de buffering/acumulación en la placa en lugar de la red. Reinicia el stack de teleop entre sesiones largas como solución temporal.

Fuentes: github.com/unitreerobotics/xr_teleoperate #247

red/conectividad Uso degradado Solución Alternativa Existe

Despliegue de políticas por WiFi se cuelga en 'Waiting for connection rt/lowstate'

Symptom: Desplegar por WiFi se cuelga en 'Waiting for connection rt/lowstate' aunque SSH al robot funciona; ethernet cableado funciona bien.

Affected: G1, control basado en DDS.

Corrección / Solución alternativa: 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.

Fuentes: github.com/unitreerobotics/unitree_rl_lab #93

SDK/software Bloquea el Uso Solución Alternativa Existe

CycloneDDS version mismatch crashes G1 sim init

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

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

Corrección / Solución alternativa: 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.

Fuentes: github.com/unitreerobotics/unitree_mujoco #60

SDK/software Bloquea el Uso Solución Alternativa Existe

'Tipo de robot no coincidente' al conectar por Ethernet (23 vs 29 DOF)

Symptom: El controlador se conecta a través de Ethernet y luego falla inmediatamente con 'Unmatched robot type' durante la implementación de sim-to-real.

Affected: Variantes G1 23-DoF y 29-DoF (incl. configs de cintura bloqueada/manos ficticias).

Corrección / Solución alternativa: El DOF/config del robot debe coincidir con el tipo esperado del controlador. Establece el DOF correcto en tu config y verifica si hay instalaciones de SDK en conflicto en /usr/local frente a tu ruta de proyecto — reconstruir unitree_sdk2 correctamente (build de despliegue con -DBUILD_EXAMPLES=OFF, build de sim con un CMAKE_INSTALL_PREFIX separado) resuelve el caso relacionado del modo-velocidad-no-responde.

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

SDK/software Uso degradado Abiertos / Sin resolver

Mover brazos vía SDK mientras camina desestabiliza el equilibrio

Symptom: Controlar los brazos vía SDK mientras camina (gamepad) hace que el robot se incline hacia adelante o pierda el equilibrio; elevar los brazos mientras camina produce una marcha inestable y pesada.

Affected: G1 con cintura de 3-DoF

Corrección / Solución alternativa: No hay solución documentada. Se probaron varias soluciones sin éxito: poner a cero los ejes de la cintura, mantener los valores iniciales y dejarlos sin modificar — el controlador del SDK del brazo y el controlador de equilibrio de locomoción entran en conflicto. Evite movimientos amplios del brazo durante la locomoción hasta que una actualización de firmware lo solucione.

Fuentes: github.com/unitreerobotics/unitree_sdk2_python #146

SDK/software Uso degradado Solución Alternativa Existe

Simulado G1 colapsa sin estabilización por defecto

Symptom: En la simulación de MuJoCo, el G1 no tiene estabilización por defecto y se cae cuando se ejecuta sin controles.

Affected: unitree_mujoco

Corrección / Solución alternativa: Habilitar la banda elástica: establece enable_elastic_band: 1 en unitree_mujoco/simulate/config.yaml (o ENABLE_ELASTIC_BAND=True). Nota: el controlador de movimiento de fábrica no está disponible en sim, y la banda puede ser difícil de deshabilitar al cambiar al control con joystick

Fuentes: github.com/unitreerobotics/unitree_mujoco #57

batería/energía Molestia Poco claro

Duración de batería corta (~2 horas)

Symptom: La batería de 9,000 mAh solo ofrece aproximadamente 2 horas por carga, y se descarga más rápido bajo movimiento dinámico.

Affected: Modelo base, batería de 9,000 mAh.

Corrección / Solución alternativa: Esta es una limitación de capacidad, no un defecto. Ten baterías de repuesto cargadas para intercambio en caliente entre sesiones; planifica una autonomía de ~2 horas de uso activo.

Fuentes: blog.robozaps.com/b/…

otro Bloquea el Uso Poco claro

Base G1 no se puede programar — sin SDK

Symptom: Los compradores del G1 base de ~$13,500 descubren que es una unidad de demostración/presentación sin SDK y no se puede programar.

Affected: G1 base (23 DOF) vs G1 EDU (hasta 43 DOF)

Corrección / Solución alternativa: Esta es una limitación de nivel de producto. El acceso a SDK, mayor torque y más DOF requieren la plataforma G1 EDU / desarrollador (~$44k-$74k). Confirma el nivel antes de la compra si tienes intención de desarrollar.

Fuentes: blog.robozaps.com/b/…

mecánico/estructural Bloquea el Uso Solución Alternativa Existe

LED rojo sólido / lista de verificación de fallas físicas (caídas, cables, batería)

Symptom: LED rojo fijo que indica un error de software/hardware; además de fallas de campo — grietas/mellas por caídas, degradación del sensor por polvo o desalineación, componentes sin respuesta por cables sueltos o pelados, inflamación o deformación de la batería.

Affected: General

Corrección / Solución alternativa: Inspeccione visualmente si hay daños por impacto; limpie los sensores y confirme el montaje; vuelva a insertar los cables y conectores; verifique la ubicación de la batería y reemplácela si está hinchada o con fugas. Si el LED permanece en rojo fijo, ejecute los diagnósticos de la aplicación móvil y grabe un video de cualquier falla intermitente antes de contactar al soporte. Nota: abrir la carcasa anula la garantía.

Fuentes: docs.westonrobot.com/tutorial/…

seguridad/privacidad Bloquea el Uso Abiertos / Sin resolver

Seguridad crítica: Inyección de comandos BLE con claves hardcoded (UniPwn)

Symptom: Una vulnerabilidad de inyección de comandos en el aprovisionamiento Wi-Fi BLE que utiliza claves AES hardcodeadas compartidas entre todas las unidades permite acceso root y es potencialmente auto-propagable. Investigaciones separadas encontraron telemetría transmitida a servidores externos cada ~5 minutos.

Affected: G1 (investigadores señalan que Go2/H1 comparten rutas de código). Exploit público 'UniPwn' publicado.

Corrección / Solución alternativa: No existe parche de proveedor confirmado documentado al momento de escribir este artículo. Mitigar a nivel de red: aísle el robot en una red segmentada o con firewall, restrinja el acceso a su interfaz interna (192.168.123.0/24) y bloquee el tráfico saliente inesperado. Esté atento a un aviso de firmware de Unitree.

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

otro Molestia Poco claro

Las habilidades en demos virales están coreografiadas, no son autónomas

Symptom: Los clips de kung-fu y backflip son exhibiciones entrenadas; el robot no tiene autonomía doméstica de fábrica y falla en tareas simples como abrir una puerta.

Affected: General

Corrección / Solución alternativa: Establecimiento de expectativas, no una falla. La ejecución autónoma de tareas requiere un desarrollo significativo en la plataforma EDU; la experiencia base son movimientos remotos/preprogramados.

Fuentes: blog.robozaps.com/b/…

SDK/software Bloquea el Uso Corregido por Vendor

El robot G1 23-DoF se mueve erráticamente en Sim2Sim de MuJoCo

Symptom: Al ejecutar Sim2Sim en MuJoCo con una política entrenada en Isaac Lab para la configuración G1 23-DoF, el robot no camina correctamente y se mueve erráticamente. La causa sospechosa reportada en el hilo es que los ID de los motores no fueron adaptados para la versión 23-DoF.

Corrección / Solución alternativa: El proveedor (Agnel-Wang) agregó código de despliegue 23-DoF al repositorio; el reportero confirmó Sim2Real exitoso después de usar el código actualizado.

Fuentes: github.com/unitreerobotics/unitree_rl_lab #27

red/conectividad Bloquea el Uso Abiertos / Sin resolver

G1_29_ArmController imprime repetidamente 'Waiting to subscribe dds' y la app del robot reporta falla de comunicación de firmware

Symptom: Al ejecutar el script de teleoperación, el controlador se cicla indefinidamente mostrando '[G1_29_ArmController] Waiting to subscribe dds...' y la app móvil reporta '底层固件通信故障' (falla de comunicación de firmware subyacente). La comunicación DDS entre el dispositivo host y el robot no se establece aunque los dispositivos estén en la misma red.

Corrección / Solución alternativa: El mantenedor sugiere verificar la conectividad de red con 'cyclonedds ps' y 'cyclonedds subscribe rt/lowstate'; si no se resuelve, enviar un ticket de soporte. Un comentarista reportó que los ejemplos de bajo nivel funcionaron pero los ejemplos de brazo de alto nivel no produjeron movimiento del robot ni solicitudes de envío.

Fuentes: github.com/unitreerobotics/xr_teleoperate #57

red/conectividad Bloquea el Uso Abiertos / Sin resolver

WebSocket de Apple Vision Pro se desconecta inmediatamente en cada carga de página en configuración de teleoperación

Symptom: Al acceder al servidor de teleoperación desde Safari de Apple Vision Pro, el WebSocket se conecta pero se desconecta inmediatamente en cada carga de página, produciendo 'AssertionError: Websocket session is missing.' en el servidor. Actualizar la página repite el ciclo de conexión/desconexión; las únicas soluciones alternativas encontradas son quitar el visor AVP o cerrar completamente Safari y esperar unos segundos.

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

Corrección / Solución alternativa: Conexión temporalmente estable lograda quitando el AVP o cerrando Safari completamente por unos segundos. El mantenedor sugirió probar 'https://vuer.ai/?ws=wss://host ip:8012' pero no se proporcionó solución confirmada.

Fuentes: github.com/unitreerobotics/xr_teleoperate #271

SDK/software Bloquea el Uso Abiertos / Sin resolver

La política WBC transmite valores pero el G1 real no se mueve después de la calibración de manos

Symptom: Via el driver comunitario GR00T-WholeBodyControl: después de que el robot entra en modo debug y las manos se calibran exitosamente, el G1 no se mueve en absoluto a pesar de que la terminal muestra que la política transmite valores al robot. No se reportan errores y la simulación en paralelo funciona correctamente.

Corrección / Solución alternativa: Sin solución confirmada

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

SDK/software Uso degradado Abiertos / Sin resolver

La alimentación de imagen de Vuer se congela en el primer frame en Quest 3 durante teleoperación con robot real

Symptom: Al ejecutar la tubería de teleoperación con un visor Quest 3, la pantalla de Vuer muestra solo el primer frame capturado y luego se congela, mientras que el cliente de imagen en la PC confirma que la alimentación de cámara en vivo funciona correctamente. El problema se reprodujo tanto en la rama principal como con la rama teleimager.

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

Corrección / Solución alternativa: El mantenedor sugirió cambiar a la rama teleimager (streaming WebRTC); el reportero aplicó la rama pero noted que no soporta despliegue en simulación. Sin solución completamente confirmada para el problema del frame congelado.

Fuentes: github.com/unitreerobotics/xr_teleoperate #172

red/conectividad Bloquea el Uso Abiertos / Sin resolver

La página de teleoperación se vuelve negra y WebSocket se desconecta al entrar en modo VR en Apple Vision Pro

Symptom: Después de que Vision Pro muestra exitosamente la alimentación de cámara binocular, al hacer clic en 'realidad virtual' y otorgar permiso de seguimiento de manos, la pantalla se vuelve negra y el WebSocket se desconecta inmediatamente, generando 'AssertionError: Websocket session is missing.' El traceback del error se origina en vuer/server.py.

Corrección / Solución alternativa: El mantenedor sugirió usar solo Wi-Fi de 5 GHz, monitorear la latencia de ping al AVP (debe ser menor a 50 ms), probar con el script televuer directamente, y probar vuer versión 0.0.32rc7. No se reportó solución confirmada.

Fuentes: github.com/unitreerobotics/xr_teleoperate #115

SDK/software Bloquea el Uso Solución Alternativa Existe

G1 no camina cuando se emite comando de locomoción vía controlador de teleoperación; entrada de joystick ignorada

Symptom: Al usar el modo controlador del script de teleoperación con el flag --motion, el control de brazos funciona correctamente pero el robot no responde a los comandos del joystick para caminar. Incluso después de salir del programa, el control remoto físico tampoco puede hacer caminar al robot, aunque los gestos de brazos continúan funcionando normalmente.

Affected: ai_sport versión no especificada; xr_teleoperate, G1_29

Corrección / Solución alternativa: El mantenedor identificó que el nombre del servicio de locomoción de ai_sport cambió en la versión 8.2.0.0 (LOCO_SERVICE_NAME debe ser 'sport' para >=8.2.0.0, 'loco' para versiones anteriores). También recomendó especificar el nombre correcto de la interfaz de red en el código si se ejecuta en un dispositivo con múltiples NIC. El mantenedor confirmó que la locomoción funcionó en su robot con la versión 8.4.0.0 después de una actualización con git pull.

Fuentes: github.com/unitreerobotics/xr_teleoperate #77

Show all 38 issues

SDK/software Bloquea el Uso Abiertos / Sin resolver

Las articulaciones del G1 no se mueven después de iniciar el programa de teleoperación y presionar 'r'

Symptom: El programa de teleoperación se inicia sin errores, DDS parece conectar, y el AVP muestra la alimentación de cámara en vivo con seguimiento de brazos, pero el robot G1 no se mueve cuando el programa está ejecutándose y después de presionar 'r' para iniciar. La salida de posición de articulaciones está ausente en el log, a diferencia del comportamiento esperado. Entrar en modo debug desde el programa se reporta como inconsistente.

Affected: G1 29-DoF con manos Inspire dftp, AVP

Corrección / Solución alternativa: Sin solución confirmada

Fuentes: github.com/unitreerobotics/xr_teleoperate #189

SDK/software Bloquea el Uso Abiertos / Sin resolver

El visor VR muestra solo una cuadrícula azul, robot no visible en simulación de teleoperación XR

Symptom: Al ejecutar teleoperación XR en simulación con Meta Quest 3, el usuario entra exitosamente en modo VR pero ve solo cuadrículas azules en lugar del robot. La terminal de simulación también muestra '[DDSManager] object g1 not found' y 'g1_robot_dds is not initialized'.

Affected: unitree_sim_isaaclab con tarea Isaac-PickPlace-Cylinder-G129-Dex3-Joint; xr_teleoperate teleop_hand_and_arm.py; Meta Quest 3

Corrección / Solución alternativa: Sin solución confirmada

Fuentes: github.com/unitreerobotics/xr_teleoperate #112

SDK/software Bloquea el Uso Solución Alternativa Existe

La política sim2sim de G1 causa que el robot derive hacia la izquierda y sacuda los brazos sin control en MuJoCo

Symptom: Al implementar una política RL entrenada (o la política v0 proporcionada) de unitree_rl_lab en MuJoCo mediante simulate_python, el robot G1 deriva hacia el lado izquierdo, sacude sus brazos con alta frecuencia y baja amplitud, y es casi imposible de controlar con el joystick. El robot también tiembla inmediatamente después de presionar la secuencia de botones de activación de movimiento.

Affected: unitree_rl_lab (última versión); Isaac Sim + Isaac Lab; unitree_mujoco con G1 29dof; simulate_python (no simulate con C++)

Corrección / Solución alternativa: Sugerencia de la comunidad: aumentar el valor de armature del brazo y muñeca en el g1_29dof.xml de MuJoCo para reducir el temblor de los brazos. No hay solución confirmada para la deriva/inestabilidad general.

Fuentes: github.com/unitreerobotics/unitree_rl_lab #31

SDK/software Bloquea el Uso Solución Alternativa Existe

RuntimeError 'list index out of range' en unitree_mujoco al ejecutar G1 con configuración de mano

Symptom: Ejecutar unitree_mujoco.py para G1 (o H1 con manos Inspire) genera '[RecurrentThread] target func raise exception: name=IndexError, args=("list index out of range",)' en tiempo de ejecución. El error ocurre al intentar simular el robot con attachments de manos.

Affected: unitree_mujoco; G1 con mano (scene_29dof_with_hand.xml); H1 con manos Inspire

Corrección / Solución alternativa: Solución de la comunidad: usar scene_29dof.xml en lugar de scene_29dof_with_hand.xml. Por separado, asegurar que el nombre ROBOT en config.py sea exactamente uno de los nombres soportados (ej. 'g1') y no una variante como 'g1_23dof'.

Fuentes: github.com/unitreerobotics/unitree_mujoco #52

SDK/software Bloquea el Uso Abiertos / Sin resolver

Los comandos del SDK de alto nivel devuelven 'send request error' en G1; los comandos de bajo nivel funcionan

Symptom: Al ejecutar comandos del SDK de alto nivel (ej. g1_loco_client_example.py), el cliente imprime '[ClientStub] send request error. id: <id>' y el comando no se ejecuta. Los scripts de bajo nivel (g1_low_level_example.py) funcionan correctamente.

Affected: unitree_sdk2_python; Robot G1; comandos de alto nivel g1_loco_client_example.py

Corrección / Solución alternativa: Sin solución confirmada

Fuentes: github.com/unitreerobotics/unitree_sdk2_python #54

SDK/software Bloquea el Uso Solución Alternativa Existe

WebSocket se desconecta inmediatamente al entrar en modo VR en Meta Quest 3 con input de hand tracking

Symptom: Al usar xr_teleoperate con un Meta Quest 3, la conexión WebSocket a la página de Vuer en el puerto 8012 se cae inmediatamente al hacer clic en el botón de Realidad Virtual, imprimiendo 'websocket is now disconnected' y 'AssertionError: Websocket session is missing.' El problema es específico del modo de input de hand tracking; cambiar al modo de input de controller mantiene la conexión activa.

Affected: xr_teleoperate v1.5; vuer 0.0.60; aiohttp 3.10.5; navegador integrado de Meta Quest 3; Host Ubuntu; Isaac Sim 5.1 + unitree_sim_isaaclab; G1_29 + Inspire

Corrección / Solución alternativa: Solución de la comunidad: hacer downgrade de xr_teleoperate a v1.0 resuelve la desconexión. Alternativamente, usar --input-mode=controller mantiene el WebSocket conectado. Usar el navegador Wolvic en lugar del navegador predeterminado de Quest también previene la desconexión del WebSocket, aunque persisten problemas de streaming de cámara.

Fuentes: github.com/unitreerobotics/xr_teleoperate #296

SDK/software Bloquea el Uso Abiertos / Sin resolver

Página VR de teleoperación inaccesible via IP local; WebSocket se cae al entrar en modo VR

Symptom: Al acceder a la interfaz de teleoperación via dirección IP local (https://<host-ip>:8012?ws=wss://<host-ip>:8012), la página falla al cargar o muestra una pantalla negra. Al entrar en VR/passthrough (modo WebXR), el WebSocket se cae y el robot deja de recibir datos de tracking, con el servidor reportando 'Websocket session is missing' y ocasionales 'AssertionError' de aiohttp 'resume_writing()'.

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

Corrección / Solución alternativa: El mantenedor sugiere verificar que la IP del host esté incluida en el campo SAN del certificado, usar navegación privada/incógnito, y probar combinaciones de versiones fijadas de vuer/televuer. Un colaborador de la comunidad identificó que Quest browser's RTCPeerConnection.createOffer() nunca se resuelve y propuso un flujo WebRTC iniciado por el servidor como solución alternativa, pero esto no ha sido subido oficialmente a upstream. No hay solución confirmada del proveedor.

Fuentes: github.com/unitreerobotics/xr_teleoperate #297

SDK/software Bloquea el Uso Solución Alternativa Existe

El programa de teleoperación sale automáticamente poco después de que el robot levante los brazos cuando la mano FTP Inspire está habilitada

Symptom: Al ejecutar teleop_hand_and_arm.py con la mano dexterous Inspire FTP habilitada (--ee=inspire_ftp), el robot levanta ambos brazos ligeramente y luego el programa termina automáticamente, bajando los brazos. El log muestra que el cliente de imagen se cierra inesperadamente y el programa sale sin un mensaje de error claro.

Affected: xr_teleoperate; hardware: Unitree G1 29-DoF con manos dexterous Inspire FTP

Corrección / Solución alternativa: Solución confirmada por el usuario: ejecutar sin el flag --ee=inspire_ftp (es decir, sin activar las manos dexterous FTP) para operar solo los brazos. El mantenedor noted que todo el código de end-effector está escrito para un par izquierdo-derecho, por lo que una mano defectuosa puede romper las cosas. El usuario aplicó un patch a la clase Inspire_Controller_FTP para manejar operación de mano única. El mantenedor también sugirió probar la última versión del código.

Fuentes: github.com/unitreerobotics/xr_teleoperate #194

mano/garra Bloquea el Uso Corregido por Vendor

Ambas manos dexterous Inspire replican solo el movimiento de la mano derecha debido a configuración incorrecta del puerto serial

Symptom: Durante teleoperación con dos manos dexterous Inspire, ambas manos siguen solo el movimiento de la mano derecha. La causa raíz identificada en el thread es que el código de ejemplo envía comandos para ambas manos al mismo puerto serial.

Affected: Unitree G1 con manos dexterous Inspire DFX / RH56DFTP; código de ejemplo inspire_ctrl.cpp del paquete de ejemplo del proveedor

Corrección / Solución alternativa: Solución identificada por la comunidad confirmada por el mantenedor: modificar inspire_ctrl.cpp para inicializar dos puertos serial separados (serial1 = /dev/ttyUSB1, serial2 = /dev/ttyUSB2) y vincular cada mano a su puerto e ID respectivos. El proveedor proporcionó código corregido de inspire_ctrl.cpp en los comentarios.

Fuentes: github.com/unitreerobotics/xr_teleoperate #46

SDK/software Bloquea el Uso Solución Alternativa Existe

El simulador unitree_mujoco crashea con 'free(): invalid pointer' / 'Aborted (core dumped)' en tiempo de ejecución

Symptom: Después de iniciar el binario del simulador unitree_mujoco, el programa comienza ('MuJoCo data is prepared') y luego se bloquea inmediatamente con 'free(): invalid pointer' y 'Aborted (core dumped)'. Una variante anterior del error era 'Joystick open failed'. Múltiples usuarios reportan esto en las versiones de MuJoCo 3.2.7 y 3.3.1.

Affected: unitree_mujoco; MuJoCo 3.2.7 y 3.3.1; Ubuntu 22.04 y Ubuntu 24.04 con ROS2 Jazzy

Corrección / Solución alternativa: Un usuario de la comunidad rastreó el bloqueo en Ubuntu 24.04 / ROS2 Jazzy hasta un conflicto de ruta de la biblioteca DDS (las bibliotecas DDS de ROS2 Jazzy y las bibliotecas DDS instaladas con unitree_sdk2 se cargan simultáneamente). Resolver el conflicto de rutas solucionó el bloqueo para ese usuario. El error del joystick se corrigió en un commit específico (2f5459d). No existe una única solución confirmada para todas las variantes reportadas.

Fuentes: github.com/unitreerobotics/unitree_mujoco #51

batería/energía Bloquea el Uso Abiertos / Sin resolver

G1 se sobrecalienta y se apaga después de unos minutos ejecutando la política sonic_release, causando caídas

Symptom: A través del driver GR00T-WholeBodyControl de la comunidad: Al implementar la política sonic_release en un robot G1 real de 29-DoF equipado con manos Dex3, el robot emite una advertencia de sobrecalentamiento después de unos minutos incluso mientras está parado en idle, luego Sonic se apaga automáticamente, causando que el robot caiga múltiples veces.

Affected: Unitree G1 29-DoF EDU con manos Dex3; punto de control sonic_release de GR00T-WholeBodyControl

Corrección / Solución alternativa: Sin solución confirmada

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

SDK/software Bloquea el Uso Abiertos / Sin resolver

La sesión WebSocket se cae y la vista VR se vuelve negra al entrar en modo Realidad Virtual en Quest 3

Symptom: Después de conectar exitosamente Quest 3 a la página de teleoperación (la interfaz de vuer carga pero muestra una pantalla negra), al hacer clic en 'Realidad Virtual' la sesión WebSocket se desconecta. La terminal muestra que la conexión se cayó. Un colaborador de la comunidad rastreó esto hasta un bug en el navegador de Meta Quest 3 donde RTCPeerConnection.createOffer() nunca resuelve su Promise, rompiendo el flujo WebRTC iniciado por el cliente por defecto.

Affected: xr_teleoperate; hardware: G1-EDU 29-DoF con Dex3-1, Meta Quest 3

Corrección / Solución alternativa: Un colaborador de la comunidad propuso invertir la negociación WebRTC a un flujo iniciado por el servidor (el servidor crea la oferta, el navegador llama a createAnswer()) como solución alternativa. No existe una corrección confirmada en el upstream.

Fuentes: github.com/unitreerobotics/xr_teleoperate #267

red/conectividad Bloquea el Uso Solución Alternativa Existe

La comunicación DDS falla cuando la PC host se conecta a G1 a través de Wi-Fi en lugar de Ethernet

Symptom: La teleoperación funciona correctamente cuando la laptop está conectada al robot mediante cable Ethernet, pero falla con errores DDS al intentar operar de forma inalámbrica a través de Wi-Fi. Adicionalmente, al ejecutar todo en la PC2 del robot (Jetson), aparecen problemas de conexión después de aproximadamente 10 minutos.

Affected: xr_teleoperate; hardware: Unitree G1 EDU con manos Inspire FTP y Apple Vision Pro

Corrección / Solución alternativa: El mantenedor sugiere usar un proxy de reenvío DDS en la capa de aplicación, o montar un router en la parte posterior del G1 (subred 192.168.123.*/24) alimentado desde la interfaz de poder del G1. No existe una única solución completa confirmada.

Fuentes: github.com/unitreerobotics/xr_teleoperate #234

¿Necesitas ayuda profesional con tu Unitree G1?

Únete a la lista de espera para reparaciones y te conectaremos con técnicos certificados y socios de servicio.

Join the Repair Waitlist →