Leg/hip/ankle motors overheat and force a shutdown

Symptom: Ankle-roll motors reach ~90°C within 5-10 min even near-idle; the left hip joint overheats after ~30 min of teleoperation and triggers an automatic system shutdown. Fix: Overheating is tied to aggressive controller gains, not always a hardware fault. Reduce Kp/Kd gains, adjust standing posture to lower static load, and prefer Unitree's stock controller for extended runs. If temps spike on the stock controller too, stop use and inspect — a genuinely failing actuator needs service.

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

Symptom: The shoulder-pitch arm motor overheats after short operation and the arm loses responsiveness when paired with the Inspire FTP dexterous hand. Fix: No vendor fix documented. Community direction: the arm needs gravity/payload compensation for the added hand mass and lower torque limits; owners are still seeking Unitree's recommended PD gains for this pairing. Treat as a tuning problem before assuming hardware failure.

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

Symptom: G1 boots into 'damp mode' and ignores SDK commands; entering 'develop mode' also disables SDK responsiveness, so users conclude the SDK is broken. Fix: Activate the robot with the remote before sending SDK commands: press L1+A, then L1+UP to leave damp mode. Do not sit in develop mode if you need SDK control. If you entered develop mode, renew the ai-sport client via the app.

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

Symptom: WaveHand and ShakeHand arm actions work from the remote but fail from Python/C++/ROS2; ROS2 returns error 3203 'API not implemented on server'. Fix: Update robot firmware to v1.3.0 or later. Also make sure the robot is activated out of damp mode (L1+A, L1+UP) before issuing the commands.

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

Symptom: Previously working Python code and official SDK examples stop working after updating to firmware 1.4.0; repeated '[ClientStub] send request error'. Related: GetVolume returns error 3102, high-level/audio examples fail. Fix: No vendor fix documented. Confirm the robot is activated (out of damp mode), verify the SDK version matches the firmware, and if you upgraded specifically for a feature, be aware some users rolled back. Watch Unitree release notes for a follow-up patch.

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

Symptom: 'Open Serial port /dev/ttyUSB0 failed' — the Inspire hand can't be controlled; or the FTP hand is unreachable at 192.168.123.211. Fix: The control method depends on the hand variant. FTP Inspire hands use Modbus TCP, not a serial port — using serial code on an FTP hand fails by design. Confirm which variant you have and use the matching control method; verify the hand's IP is reachable on the 192.168.123.x network.

Dex3-1 hand thumb barely moves during teleoperation

Symptom: In teleop the thumb only makes 3-4° micro-movements versus full range in simulation; thumb-to-index pinch bottoms out at ~5cm, too coarse for fine manipulation. Fix: No fix documented. Power-up self-check shows joints normal and simulation works, which points to a command-mapping mismatch between teleop and the hand driver rather than hardware. Report the driver version to Unitree.

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

Symptom: Arm and camera latency climbs to ~2.5s after prolonged teleop; arm prep pose takes ~4s instead of ~2s, eventually appearing immediately on startup. Fix: No fix documented. Upgrading to a gigabit router and WiFi 6 did not help, and simulation mode is unaffected — suggesting an onboard buffering/accumulation issue rather than the network. Restart the teleop stack between long sessions as a stopgap.

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

Symptom: Deploying over WiFi hangs on 'Waiting for connection rt/lowstate' even though SSH to the robot works; wired ethernet works fine. Fix: Use a wired connection and specify the interface, e.g. ./g1_ctrl --network enx701988512412. DDS multicast for lowstate does not traverse the wireless interface reliably.

CycloneDDS version mismatch crashes G1 sim init

Symptom: DDS assertion failure / CycloneDDS writer error when initializing the G1 simulation; it won't start. Fix: Don't source the ROS setup script (its DDS libs differ from unitree_sdk2's). Verify which .so is linked at compile time. Alternatives: build CycloneDDS 0.10.2 from source, patch unitree-sdk2py for 0.10.5, or develop on Ubuntu 20.04.

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

Symptom: The controller connects over Ethernet then immediately fails with 'Unmatched robot type' during sim-to-real deployment. Fix: The robot's DOF/config must match the controller's expected type. Set the correct DOF in your config, and check for conflicting SDK installs in /usr/local vs your project path — rebuilding unitree_sdk2 cleanly (deploy build with -DBUILD_EXAMPLES=OFF, sim build with a separate CMAKE_INSTALL_PREFIX) resolves the related unresponsive-velocity-mode case.

Moving arms via SDK while walking destabilizes balance

Symptom: Controlling the arms via SDK while walking (gamepad) makes the robot bend forward or lose balance; raising arms while walking produces an unstable, heavy gait. Fix: No fix documented. Zeroing waist axes, holding initial values, and leaving them untouched were all tried without success — the arm SDK controller and the locomotion balance controller conflict. Avoid large arm motions during locomotion until a firmware update addresses it.

Simulated G1 collapses with no default stabilization

Symptom: In MuJoCo simulation the G1 has no default stabilization and falls over when run without controls. Fix: Enable the elastic band: set enable_elastic_band: 1 in unitree_mujoco/simulate/config.yaml (or ENABLE_ELASTIC_BAND=True). Note the factory motion controller isn't available in sim, and the band can be awkward to disable when switching to joystick control.

Short battery runtime (~2 hours)

Symptom: The 9,000 mAh battery gives only about 2 hours per charge, and drains faster under dynamic movement. Fix: This is a capacity limitation, not a fault. Keep charged spare batteries for hot-swapping between sessions; budget runtime around ~2 hours of active use.

Base G1 can't be programmed — no SDK

Symptom: Buyers of the ~$13,500 base G1 discover it's a demo/showcase unit with no SDK and cannot be programmed. Fix: This is a product-tier limitation. SDK access, higher torque, and more DOF require the G1 EDU / developer platform (~$44k-$74k). Confirm the tier before purchase if you intend to develop.

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

Symptom: Solid red LED indicating a software/hardware error; plus field faults — cracks/dents from falls, sensor degradation from dust or misalignment, unresponsive components from loose/frayed cables, battery swelling or deformation. Fix: Visually inspect for impact damage; clean sensors and confirm mounting; reseat cables and connectors; verify battery seating and replace if swollen or leaking. On a solid red LED, run the mobile-app diagnostics and record a video of any intermittent fault before contacting support. Note: opening the shell voids the warranty.

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

Symptom: A command-injection flaw in the BLE Wi-Fi provisioning, using hardcoded AES keys shared across all units, allows root access and is potentially wormable. Separate research found telemetry transmitted to external servers every ~5 minutes. Fix: No confirmed vendor patch documented at time of writing. Mitigate at the network level: isolate the robot on a segmented/firewalled network, restrict access to its internal interface (192.168.123.0/24), and block unexpected outbound traffic. Watch for a Unitree firmware advisory.

Viral demo skills are choreographed, not autonomous

Symptom: Kung-fu and backflip clips are trained showcases; the robot has no household autonomy out of the box and fails simple tasks like opening a door. Fix: Expectation-setting, not a fault. Autonomous task performance requires significant development on the EDU platform; the base experience is remote/pre-programmed motions.

G1 23-DOF robot moves erratically in MuJoCo Sim2Sim

Symptom: When running Sim2Sim in MuJoCo with a policy trained in Isaac Lab for the G1 23-DOF configuration, the robot fails to walk properly and moves erratically. The suspected cause reported in the thread is that motor IDs were not adapted for the 23-DOF version. Fix: Vendor (Agnel-Wang) added 23-DOF deploy code to the repository; reporter confirmed successful Sim2Real after using the updated code.

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

Symptom: When running the teleoperation script, the controller loops indefinitely printing '[G1_29_ArmController] Waiting to subscribe dds...' and the mobile app reports '底层固件通信故障' (underlying firmware communication fault). DDS communication between the host device and the robot is not established despite the devices being on the same network. Fix: Maintainer suggests verifying network connectivity with 'cyclonedds ps' and 'cyclonedds subscribe rt/lowstate'; if unresolved, submit a support ticket. One commenter reported that low-level examples worked but high-level arm examples produced no robot motion and send request errors.

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

Symptom: When accessing the teleoperation server from Apple Vision Pro Safari, the WebSocket connects but immediately disconnects on every page load, producing 'AssertionError: Websocket session is missing.' on the server. Refreshing the page repeats the connect/disconnect cycle; the only workarounds found are removing the AVP headset or fully closing Safari and waiting a few seconds. Fix: Temporarily stable connection achieved by taking off the AVP or closing Safari entirely for a few seconds. Maintainer suggested trying 'https://vuer.ai/?ws=wss://host ip:8012' but no confirmed fix was provided.

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

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

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

Symptom: When running the teleoperation pipeline with a Quest 3 headset, the Vuer display shows only the first captured frame and then freezes, while the image client on the PC confirms the live camera feed is working correctly. The issue was reproduced both in the main branch and with the teleimager branch. Fix: Maintainer suggested switching to the teleimager branch (WebRTC streaming); reporter applied the branch but noted it does not support simulation deployment. No fully confirmed fix for the frozen frame issue.

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

Symptom: After the Vision Pro successfully displays the binocular camera feed, clicking 'virtual reality' and granting hand-tracking permission causes the display to go black and the WebSocket to disconnect immediately, raising 'AssertionError: Websocket session is missing.' The error traceback originates in vuer/server.py. Fix: Maintainer suggested using only 5 GHz Wi-Fi, monitoring ping latency to the AVP (should be under 50 ms), testing with the televuer script directly, and trying vuer version 0.0.32rc7. No confirmed fix reported.

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

Symptom: When using the controller mode of the teleoperation script with the --motion flag, arm control works correctly but the robot does not respond to joystick commands for walking. Even after exiting the program, the physical remote control also cannot make the robot walk, though arm gestures continue to function normally. Fix: Maintainer identified that the ai_sport locomotion service name changed at version 8.2.0.0 (LOCO_SERVICE_NAME must be 'sport' for >=8.2.0.0, 'loco' for earlier). Also advised specifying the correct network interface name in the code if running on a multi-NIC device. Maintainer confirmed locomotion worked on their robot with version 8.4.0.0 after a git pull update.

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

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

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

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

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

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

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

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

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

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

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: Problemi Noti e Soluzioni

Ultimo aggiornamento 23 agosto 2026

38 problemi noti View robot profile →

Avviso di Garanzia e Sicurezza: La garanzia inizia alla ricezione. Il proprietario spedisce l'unità a Unitree a proprie spese per la diagnosi. La garanzia è ANNULLATA in caso di apertura della scocca, smontaggio o modifica non autorizzata. Nessun canale di ricambi per il consumatore; i rivenditori forniscono solo supporto di primo livello. G1 base ~8 mesi; G1 EDU ~18 mesi (EU 24 mesi). Fonti: https://www.unitree.com/mobile/terms/policy https://blog.robozaps.com/b/unitree-g1-review Le soluzioni temporanee elencate di seguito provengono dalla community e vengono fornite senza garanzia.

motore/attuatore Blocca l'Uso Soluzione Temporanea Disponibile

I motori di gamba/anca/caviglia si surriscaldano e causano uno spegnimento

Sintomo: I motori di roll della caviglia raggiungono ~90°C in 5-10 min anche quasi in idle; l'articolazione dell'anca sinistra si surriscalda dopo ~30 min di teleoperazione e triggers uno spegnimento automatico del sistema.

Interessati: Segnalato con controller whole-body di terze parti (NVIDIA GEAR-SONIC / Isaac-GR00T N1.7 su Jetson Orin NX). Il controller stock di Unitree mantiene le caviglie a 30-45°C.

Soluzione / Soluzione Temporanea: Il surriscaldamento è legato a guadagni aggressivi del controller, non sempre un guasto hardware. Ridurre i guadagni Kp/Kd, regolare la postura in piedi per abbassare il carico statico e preferire il controller stock di Unitree per operazioni prolungate. Se le temperature aumentano anche sul controller stock, fermare l'uso e ispezionare — un attuatore che fallisce genuinamente necessita di assistenza.

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

motore/attuatore Degrada l'Uso Aperto / Irrisolto

Il motore della spalla/braccio si surriscalda e diventa debole con mano destra Inspire

Sintomo: Il motore di pitch della spalla si surriscalda dopo brevi operazioni e il braccio perde reattività quando abbinato alla mano destra dexterous Inspire FTP.

Interessati: G1 ARM7 + mano Inspire FTP, ROS2 Humble; utenti con guadagni PD kp=40 / kd=1.5.

Soluzione / Soluzione Temporanea: Nessuna soluzione vendor documentata. Indicazione della community: il braccio necessita di compensazione di gravità/payload per la massa aggiuntiva della mano e limiti di coppia inferiori; i proprietari stanno ancora cercando i guadagni PD raccomandati da Unitree per questo abbinamento. Trattare come un problema di tuning prima di assumere un guasto hardware.

Fonti: github.com/unitreerobotics/unitree_sdk2_python #129

firmware/aggiornamento Fastidio Soluzione Temporanea Disponibile

Il robot ignora i comandi SDK (bloccato in damp / develop mode)

Sintomo: G1 si avvia in 'damp mode' e ignora i comandi SDK; entrare in 'develop mode' disabilita anche la rispondenza SDK, quindi gli utenti concludono che l'SDK è rotto.

Interessati: Comportamento generale del firmware G1.

Soluzione / Soluzione Temporanea: Attivare il robot con il telecomando prima di inviare comandi SDK: premere L1+A, poi L1+UP per uscire dalla damp mode. Non rimanere in develop mode se hai bisogno del controllo SDK. Se sei entrato in develop mode, rinnova il client ai-sport tramite l'app.

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

SDK/software Degrada l'Uso Risolto dal Vendor

WaveHand / ShakeHand falliscono da SDK (errore 3203 'API not implemented')

Sintomo: Le azioni WaveHand e ShakeHand del braccio funzionano dal telecomando ma falliscono da Python/C++/ROS2; ROS2 ritorna errore 3203 'API not implemented on server'.

Interessati: Firmware prima di v1.3.0.

Soluzione / Soluzione Temporanea: Aggiornare il firmware del robot a v1.3.0 o successivo. Assicurarsi anche che il robot sia attivato fuori dalla damp mode (L1+A, L1+UP) prima di inviare i comandi.

Fonti: github.com/unitreerobotics/unitree_sdk2_python #42

firmware/aggiornamento Blocca l'Uso Aperto / Irrisolto

Codice ed esempi ufficiali si rompono dopo firmware 1.4.0 ('ClientStub send request error')

Sintomo: Codice Python precedentemente funzionante ed esempi SDK ufficiali smettono di funzionare dopo l'aggiornamento a firmware 1.4.0; '[ClientStub] send request error' ripetuto. Correlato: GetVolume ritorna errore 3102, esempi high-level/audio falliscono.

Interessati: Firmware 1.4.0.

Soluzione / Soluzione Temporanea: Nessuna soluzione vendor documentata. Confermare che il robot sia attivato (fuori dalla damp mode), verificare che la versione SDK corrisponda al firmware e se hai aggiornato specificamente per una funzionalità, essere consapevoli che alcuni utenti hanno fatto rollback. Seguire le note di rilascio di Unitree per una patch successiva.

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

mano/gripper Blocca l'Uso Soluzione Temporanea Disponibile

Mano Inspire non apre porta seriale / irraggiungibile al suo IP

Sintomo: 'Open Serial port /dev/ttyUSB0 failed' — la mano Inspire non può essere controllata; o la mano FTP è irraggiungibile a 192.168.123.211.

Interessati: G1 con mano Inspire (varianti serial DFX vs FTP modbus-TCP).

Soluzione / Soluzione Temporanea: Il metodo di controllo dipende dalla variante della mano. Le mani Inspire FTP usano Modbus TCP, non una porta seriale — usare codice seriale su una mano FTP fallisce per design. Confermare quale variante si ha e usare il metodo di controllo corrispondente; verificare che l'IP della mano sia raggiungibile sulla rete 192.168.123.x.

Fonti: github.com/unitreerobotics/xr_teleoperate #51

mano/gripper Degrada l'Uso Aperto / Irrisolto

Pollice della mano Dex3-1 si muove appena durante teleoperazione

Sintomo: In teleop il pollice fa solo micromovimenti di 3-4° rispetto al range completo in simulazione; pinza pollice-indice si blocca a ~5cm, troppo grossolano per manipolazione fine.

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

Soluzione / Soluzione Temporanea: Nessuna soluzione documentata. Il self-check all'accensione mostra giunti normali e la simulazione funziona, il che indica una mancata corrispondenza nel mapping dei comandi tra teleop e il driver della mano piuttosto che hardware. Segnalare la versione del driver a Unitree.

Fonti: github.com/unitreerobotics/xr_teleoperate #229

rete/connettività Degrada l'Uso Aperto / Irrisolto

Latenza di teleoperazione cresce a ~2.5s dopo 1-2 ore

Sintomo: La latenza del braccio e della telecamera sale a ~2.5s dopo teleop prolungato; la pose di preparazione del braccio impiega ~4s invece di ~2s, alla fine appare immediatamente all'avvio.

Interessati: xr_teleoperate v1.3 e v1.5.

Soluzione / Soluzione Temporanea: Nessuna soluzione documentata. L'aggiornamento a un router gigabit e WiFi 6 non ha aiutato e la modalità simulazione non è interessata — suggerendo un problema di buffering/accumulo a bordo piuttosto che la rete. Riavviare lo stack di teleop tra sessioni lunghe come soluzione temporanea.

Fonti: github.com/unitreerobotics/xr_teleoperate #247

rete/connettività Degrada l'Uso Soluzione Temporanea Disponibile

Il deployment delle policy su WiFi si blocca su 'Waiting for connection rt/lowstate'

Sintomo: Il deployment su WiFi si blocca su 'Waiting for connection rt/lowstate' anche se SSH al robot funziona; ethernet cablato funziona bene.

Interessati: G1, controllo basato su DDS.

Soluzione / Soluzione Temporanea: Usa una connessione cablata e specifica l'interfaccia, es. ./g1_ctrl --network enx701988512412. Il multicast DDS per lowstate non attraversa l'interfaccia wireless in modo affidabile.

Fonti: github.com/unitreeerobotics/unitree_rl_lab #93

SDK/software Blocca l'Uso Soluzione Temporanea Disponibile

Mancata corrispondenza di versione CycloneDDS blocca l'avvio della sim G1

Sintomo: Errore di asserzione DDS / errore writer CycloneDDS durante l'inizializzazione della simulazione G1; non si avvia.

Interessati: Ubuntu 22.04, ROS2 Humble; CycloneDDS di sistema 0.10.5 vs CycloneDDS Python 0.10.2.

Soluzione / Soluzione Temporanea: Non sourciare lo script setup ROS (le sue librerie DDS differiscono da quelle di unitree_sdk2). Verifica quale .so è linkato a compile time. Alternative: compila CycloneDDS 0.10.2 da sorgente, patcha unitree-sdk2py per 0.10.5, o sviluppa su Ubuntu 20.04.

Fonti: github.com/unitreeerobotics/unitree_mujoco #60

SDK/software Blocca l'Uso Soluzione Temporanea Disponibile

'Tipo robot non corrispondente' su connessione Ethernet (23 vs 29 DOF)

Sintomo: Il controller si connette via Ethernet poi fallisce immediatamente con 'Tipo robot non corrispondente' durante il deployment sim-to-real.

Interessati: Varianti G1 a 23 DOF e 29 DOF (incl. configurazioni con vita bloccata/mano finta).

Soluzione / Soluzione Temporanea: I DOF/config del robot devono corrispondere al tipo atteso dal controller. Imposta i DOF corretti nella tua config, e controlla installazioni SDK conflittuali in /usr/local vs il percorso del tuo progetto — ricompilare unitree_sdk2 pulitamente (build deploy con -DBUILD_EXAMPLES=OFF, build sim con un CMAKE_INSTALL_PREFIX separato) risolve il caso correlato di modalità velocità non rispondente.

Fonti: github.com/unitreeerobotics/unitree_rl_lab #114 github.com/unitreeerobotics/unitree_rl_lab #44

SDK/software Degrada l'Uso Aperto / Irrisolto

Muovere le braccia via SDK mentre si cammina destabilizza l'equilibrio

Sintomo: Controllare le braccia via SDK mentre si cammina (gamepad) fa piegare il robot in avanti o perdere l'equilibrio; alzare le braccia mentre si cammina produce un'andatura instabile e pesante.

Interessati: G1 con vita a 3 DOF.

Soluzione / Soluzione Temporanea: Nessuna correzione documentata. Azzerare gli assi della vita, mantenere i valori iniziali e lasciarli stare sono state tutte provate senza successo — il controller SDK del braccio e il controller di equilibrio della locomozione confliggono. Evita grandi movimenti del braccio durante la locomozione finché un aggiornamento firmware non lo affronti.

Fonti: github.com/unitreeerobotics/unitree_sdk2_python #146

SDK/software Degrada l'Uso Soluzione Temporanea Disponibile

G1 simulato collassa senza stabilizzazione predefinita

Sintomo: In simulazione MuJoCo il G1 non ha stabilizzazione predefinita e cade quando eseguito senza controlli.

Interessati: unitree_mujoco.

Soluzione / Soluzione Temporanea: Abilita la banda elastica: imposta enable_elastic_band: 1 in unitree_mujoco/simulate/config.yaml (o ENABLE_ELASTIC_BAND=True). Nota che il controller di movimento factory non è disponibile in sim, e la banda può essere difficile da disabilitare quando si passa al controllo joystick.

Fonti: github.com/unitreeerobotics/unitree_mujoco #57

batteria/alimentazione Fastidio Non chiaro

Autonomia batteria ridotta (~2 ore)

Sintomo: La batteria da 9.000 mAh fornisce solo circa 2 ore per carica, e si consuma più velocemente sotto movimento dinamico.

Interessati: Modello base, pacco batteria 9.000 mAh.

Soluzione / Soluzione Temporanea: Questa è una limitazione di capacità, non un difetto. Tieni batterie di ricambio cariche per l'hot-swap tra sessioni; pianifica un'autonomia di circa ~2 ore di uso attivo.

Fonti: blog.robozaps.com/b/…

altro Blocca l'Uso Non chiaro

G1 base non può essere programmato — nessun SDK

Sintomo: Gli acquirenti del G1 base da ~$13.500 scoprono che è un'unità dimostrativa/da showroom senza SDK e non può essere programmata.

Interessati: G1 base (23 DOF) vs G1 EDU (fino a 43 DOF).

Soluzione / Soluzione Temporanea: Questa è una limitazione del tier del prodotto. L'accesso SDK, coppia più alta e più DOF richiedono la piattaforma G1 EDU / developer (~$44k-$74k). Conferma il tier prima dell'acquisto se intendi sviluppare.

Fonti: blog.robozaps.com/b/…

meccanico/strutturale Blocca l'Uso Soluzione Temporanea Disponibile

LED rosso fisso / checklist guasto fisico (cadute, cavi, batteria)

Sintomo: LED rosso fisso che indica errore software/hardware; più guasti sul campo — crepe/danneggiamenti da cadute, degradazione sensori da polvere o disallineamento, componenti non rispondenti da cavi allentati/sfilacciati, batteria gonfia o deformata.

Interessati: Generale.

Soluzione / Soluzione Temporanea: Ispeziona visivamente per danni da impatto; pulisci i sensori e conferma il montaggio; riattacca cavi e connettori; verifica il posizionamento della batteria e sostituiscila se gonfia o che perde. Su LED rosso fisso, esegui i diagnostici dall'app mobile e registra un video di qualsiasi guasto intermittente prima di contattare il supporto. Nota: aprire la scocca invalida la garanzia.

Fonti: docs.westonrobot.com/tutorial/…

sicurezza/privacy Blocca l'Uso Aperto / Irrisolto

Sicurezza critica: iniezione comandi BLE con chiavi hardcoded (UniPwn)

Sintomo: Una falla di iniezione comandi nel provisioning Wi-Fi BLE, che usa chiavi AES hardcoded condivise tra tutte le unità, permette accesso root ed è potenzialmente wormable. Ricerche separate hanno trovato telemetria trasmessa a server esterni ogni ~5 minuti.

Interessati: G1 (i ricercatori indicano che Go2/H1 condividono percorsi codice). Exploit pubblico 'UniPwn' rilasciato.

Soluzione / Soluzione Temporanea: Nessuna patch vendor confermata documentata al momento della scrittura. Mitiga a livello rete: isola il robot su una rete segmentata/firewall, limita l'accesso alla sua interfaccia interna (192.168.123.0/24), e blocca traffico outbound inaspettato. Attendi un advisory firmware Unitree.

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

altro Fastidio Non chiaro

Le abilità virali dei demo sono coreografate, non autonome

Sintomo: I video di kung-fu e capriole sono showcase addestrati; il robot non ha autonomia domestica out-of-the-box e fallisce compiti semplici come aprire una porta.

Interessati: Generale.

Soluzione / Soluzione Temporanea: Gestione delle aspettative, non un difetto. La performance autonoma dei task richiede sviluppo significativo sulla piattaforma EDU; l'esperienza base è movimenti remoti/pre-programmati.

Fonti: blog.robozaps.com/b/…

SDK/software Blocca l'Uso Risolto dal Vendor

Il robot G1 23-DoF si muove in modo irregolare in Sim2Sim MuJoCo

Sintomo: Quando si esegue Sim2Sim in MuJoCo con una policy addestrata in Isaac Lab per la configurazione G1 23-DoF, il robot non cammina correttamente e si muove in modo irregolare. La causa sospettata segnalata nella discussione è che gli ID dei motori non sono stati adattati per la versione 23-DoF.

Soluzione / Soluzione Temporanea: Il vendor (Agnel-Wang) ha aggiunto il codice di deploy a 23-DoF al repository; il segnalatore ha confermato il successo del Sim2Real dopo aver utilizzato il codice aggiornato.

Fonti: github.com/unitreerobotics/unitree_rl_lab #27

rete/connettività Blocca l'Uso Aperto / Irrisolto

G1_29_ArmController stampa ripetutamente 'Waiting to subscribe dds' e l'app del robot segnala errore di comunicazione firmware

Sintomo: Quando si esegue lo script di teleoperazione, il controller stampa indefinitamente '[G1_29_ArmController] Waiting to subscribe dds...' e l'app mobile segnala '底层固件通信故障' (errore di comunicazione firmware sottostante). La comunicazione DDS tra il dispositivo host e il robot non viene stabilita nonostante i dispositivi siano sulla stessa rete.

Soluzione / Soluzione Temporanea: Il manutentore consiglia di verificare la connettività di rete con 'cyclonedds ps' e 'cyclonedds subscribe rt/lowstate'; se il problema persiste, inviare un ticket di supporto. Un commentatore ha segnalato che gli esempi di basso livello funzionavano ma gli esempi di braccio di alto livello non producevano alcun movimento del robot e generavano errori di invio richiesta.

Fonti: github.com/unitreerobotics/xr_teleoperate #57

rete/connettività Blocca l'Uso Aperto / Irrisolto

Il WebSocket Apple Vision Pro si disconnette immediatamente ad ogni caricamento della pagina nella configurazione di teleoperazione

Sintomo: Quando si accede al server di teleoperazione da Safari di Apple Vision Pro, il WebSocket si connette ma si disconnette immediatamente ad ogni caricamento della pagina, producendo 'AssertionError: Websocket session is missing.' sul server. L'aggiornamento della pagina ripete il ciclo di connessione/disconnessione; gli unici workaround trovati sono rimuovere il visore AVP o chiudere completamente Safari e attendere qualche secondo.

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

Soluzione / Soluzione Temporanea: Connessione temporaneamente stabile ottenuta togliendo l'AVP o chiudendo completamente Safari per qualche secondo. Il manutentore ha suggerito di provare 'https://vuer.ai/?ws=wss://host ip:8012' ma non è stata fornita alcuna soluzione confermata.

Fonti: github.com/unitreerobotics/xr_teleoperate #271

SDK/software Blocca l'Uso Aperto / Irrisolto

La policy WBC trasmette valori ma il G1 reale non si muove dopo la calibrazione delle mani

Sintomo: Tramite il driver community GR00T-WholeBodyControl: dopo che il robot entra in modalità debug e le mani si calibrano correttamente, il G1 non si muove affatto nonostante il terminale mostri la policy che trasmette valori al robot. Nessun errore viene segnalato e la simulazione parallela funziona correttamente.

Soluzione / Soluzione Temporanea: Nessuna soluzione confermata

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

SDK/software Degrada l'Uso Aperto / Irrisolto

Il feed video Vuer su Quest 3 si blocca sul primo frame durante la teleoperazione con robot reale

Sintomo: Quando si esegue la pipeline di teleoperazione con un visore Quest 3, il display Vuer mostra solo il primo frame catturato e poi si blocca, mentre il client di immagini sul PC conferma che il feed video della telecamera in tempo reale funziona correttamente. Il problema è stato riprodotto sia nel branch principale che con il branch teleimager.

Interessati: vuer 0.0.67, xr_teleoperate (modalità controller, G1_29)

Soluzione / Soluzione Temporanea: Il manutentore ha suggerito di passare al branch teleimager (streaming WebRTC); il segnalatore ha applicato il branch ma ha notato che non supporta il deploy in simulazione. Nessuna soluzione completamente confermata per il problema del frame bloccato.

Fonti: github.com/unitreerobotics/xr_teleoperate #172

rete/connettività Blocca l'Uso Aperto / Irrisolto

La pagina di teleoperazione diventa nera e il WebSocket si disconnette quando si entra in modalità VR su Apple Vision Pro

Sintomo: Dopo che Vision Pro visualizza correttamente il feed della telecamera binoculare, cliccare su 'virtual reality' e concedere il permesso di tracciamento delle mani causa la visualizzazione di una schermata nera e la disconnessione immediata del WebSocket, sollevando 'AssertionError: Websocket session is missing.' La traccia dell'errore ha origine in vuer/server.py.

Soluzione / Soluzione Temporanea: Il manutentore ha suggerito di usare solo Wi-Fi a 5 GHz, monitorare la latenza del ping verso l'AVP (dovrebbe essere inferiore a 50 ms), testare con lo script televuer direttamente e provare la versione vuer 0.0.32rc7. Nessuna soluzione confermata segnalata.

Fonti: github.com/unitreerobotics/xr_teleoperate #115

SDK/software Blocca l'Uso Soluzione Temporanea Disponibile

G1 non cammina quando viene emesso un comando di locomozione tramite controller di teleoperazione; input del joystick ignorato

Sintomo: Quando si usa la modalità controller dello script di teleoperazione con il flag --motion, il controllo del braccio funziona correttamente ma il robot non risponde ai comandi del joystick per camminare. Anche dopo aver chiuso il programma, il telecomando fisico non riesce a far camminare il robot, sebbene i gesti del braccio continuino a funzionare normalmente.

Interessati: ai_sport versione non specificata; xr_teleoperate, G1_29

Soluzione / Soluzione Temporanea: Il manutentore ha identificato che il nome del servizio di locomozione di ai_sport è cambiato alla versione 8.2.0.0 (LOCO_SERVICE_NAME deve essere 'sport' per >=8.2.0.0, 'loco' per le versioni precedenti). Ha anche consigliato di specificare il nome corretto dell'interfaccia di rete nel codice se si esegue su un dispositivo multi-NIC. Il manutentore ha confermato che la locomozione funzionava sul loro robot con la versione 8.4.0.0 dopo un aggiornamento con git pull.

Fonti: github.com/unitreerobotics/xr_teleoperate #77

Show all 38 issues

SDK/software Blocca l'Uso Aperto / Irrisolto

Le articolazioni del G1 non si muovono dopo l'avvio del programma di teleoperazione e la pressione di 'r'

Sintomo: Il programma di teleoperazione si avvia senza errori, DDS sembra connettersi e l'AVP visualizza il feed video in tempo reale con tracciamento del braccio, ma il robot G1 non si muove quando il programma è in esecuzione e dopo aver premuto 'r' per avviare. L'output della posizione delle articolazioni è assente dal log, diversamente dal comportamento atteso. L'accesso alla modalità debug dal programma è segnalato come incoerente.

Interessati: G1 29-DoF con mani Inspire dftp, AVP

Soluzione / Soluzione Temporanea: Nessuna soluzione confermata

Fonti: github.com/unitreerobotics/xr_teleoperate #189

SDK/software Blocca l'Uso Aperto / Irrisolto

Il visore VR mostra solo una griglia blu, robot non visibile nella simulazione di teleoperazione XR

Sintomo: Quando si esegue la teleoperazione XR in simulazione con un Meta Quest 3, l'utente entra correttamente in modalità VR ma vede solo griglie blu invece del robot. Il terminale della simulazione mostra anche '[DDSManager] object g1 not found' e 'g1_robot_dds is not initialized'.

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

Soluzione / Soluzione Temporanea: Nessuna soluzione confermata

Fonti: github.com/unitreerobotics/xr_teleoperate #112

SDK/software Blocca l'Uso Soluzione Temporanea Disponibile

La policy sim2sim di G1 fa derivare il robot a sinistra e scuotere le braccia in modo incontrollabile in MuJoCo

Sintomo: Quando si distribuisce una policy RL addestrata (o la policy v0 fornita) da unitree_rl_lab in MuJoCo tramite simulate_python, il robot G1 deriva verso il lato sinistro, scuote le braccia con alta frequenza e bassa ampiezza, ed è quasi impossibile da controllare con il joystick. Il robot oscilla anche immediatamente dopo aver premuto la sequenza di pulsanti di attivazione del movimento.

Interessati: unitree_rl_lab (ultima versione); Isaac Sim + Isaac Lab; unitree_mujoco con G1 29dof; simulate_python (non simulate con C++)

Soluzione / Soluzione Temporanea: Suggerimento della community: aumentare il valore dell'armatura del braccio e del polso nel g1_29dof.xml di MuJoCo per ridurre il tremore delle braccia. Nessuna correzione confermata per la deriva/instabilità complessiva.

Fonti: github.com/unitreerobotics/unitree_rl_lab #31

SDK/software Blocca l'Uso Soluzione Temporanea Disponibile

RuntimeError 'list index out of range' in unitree_mujoco durante l'esecuzione di G1 con configurazione mano

Sintomo: L'esecuzione di unitree_mujoco.py per G1 (o H1 con mani Inspire) genera '[RecurrentThread] target func raise exception: name=IndexError, args=("list index out of range",)' in fase di esecuzione. L'errore si verifica quando si tenta di simulare il robot con attacchi mani.

Interessati: unitree_mujoco; G1 con mano (scene_29dof_with_hand.xml); H1 con mani Inspire

Soluzione / Soluzione Temporanea: Workaround della community: usare scene_29dof.xml invece di scene_29dof_with_hand.xml. Separatamente, assicurarsi che il nome ROBOT in config.py sia esattamente uno dei nomi supportati (es. 'g1') e non una variante come 'g1_23dof'.

Fonti: github.com/unitreerobotics/unitree_mujoco #52

SDK/software Blocca l'Uso Aperto / Irrisolto

I comandi SDK di alto livello restituiscono 'send request error' su G1; i comandi di basso livello funzionano

Sintomo: Quando si eseguono comandi SDK di alto livello (es. g1_loco_client_example.py), il client stampa '[ClientStub] send request error. id: <id>' e il comando non viene eseguito. Gli script di basso livello (g1_low_level_example.py) funzionano correttamente.

Interessati: unitree_sdk2_python; Robot G1; Comandi di alto livello g1_loco_client_example.py

Soluzione / Soluzione Temporanea: Nessuna soluzione confermata

Fonti: github.com/unitreerobotics/unitree_sdk2_python #54

SDK/software Blocca l'Uso Soluzione Temporanea Disponibile

WebSocket si disconnette immediatamente all'ingresso in modalità VR su Meta Quest 3 con input hand tracking

Sintomo: Quando si usa xr_teleoperate con un Meta Quest 3, la connessione WebSocket alla pagina Vuer sulla porta 8012 cade immediatamente cliccando sul pulsante Virtual Reality, stampando 'websocket is now disconnected' e 'AssertionError: Websocket session is missing.' Il problema è specifico della modalità di input hand tracking; passare alla modalità di input controller mantiene la connessione attiva.

Interessati: xr_teleoperate v1.5; vuer 0.0.60; aiohttp 3.10.5; Browser integrato Meta Quest 3; Host Ubuntu; Isaac Sim 5.1 + unitree_sim_isaaclab; G1_29 + Inspire

Soluzione / Soluzione Temporanea: Workaround della community: eseguire il downgrade di xr_teleoperate alla v1.0 risolve la disconnessione. In alternativa, passare a --input-mode=controller mantiene il WebSocket connesso. Usare il browser Wolvic invece del browser predefinito Meta Quest previene anche la disconnessione WebSocket, sebbene rimangano problemi di streaming della fotocamera.

Fonti: github.com/unitreerobotics/xr_teleoperate #296

SDK/software Blocca l'Uso Aperto / Irrisolto

Pagina VR di teleoperazione irraggiungibile tramite IP locale; WebSocket cade all'ingresso in modalità VR

Sintomo: Quando si accede all'interfaccia di teleoperazione tramite indirizzo IP locale (https://<host-ip>:8012?ws=wss://<host-ip>:8012), la pagina non carica o mostra una schermata nera. All'ingresso in VR/passthrough (modalità WebXR), il WebSocket cade e il robot smette di ricevere dati di tracking, con il server che riporta 'Websocket session is missing' e occasionali 'AssertionError' aiohttp 'resume_writing()'.

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

Soluzione / Soluzione Temporanea: Il maintainer suggerisce di verificare che l'IP host sia incluso nel campo SAN del certificato, usare navigazione in incognito/privata, e provare combinazioni di versioni fisse di vuer/televuer. Un contributor della community ha identificato che Quest browser's RTCPeerConnection.createOffer() non risolve mai e ha proposto un flusso WebRTC avviato dal server come workaround, ma non è stato ufficialmente upstreamato. Nessuna correzione confermata dal vendor.

Fonti: github.com/unitreerobotics/xr_teleoperate #297

SDK/software Blocca l'Uso Soluzione Temporanea Disponibile

Il programma di teleoperazione termina automaticamente poco dopo che il robot alza le braccia quando la mano FTP Inspire è abilitata

Sintomo: Quando si lancia teleop_hand_and_arm.py con la mano destrosa Inspire FTP abilitata (--ee=inspire_ftp), il robot alza leggermente entrambe le braccia e poi il programma termina automaticamente, abbassando le braccia. Il log mostra che il client immagine si chiude inaspettatamente e il programma esce senza un messaggio di errore chiaro.

Interessati: xr_teleoperate; hardware: Unitree G1 29-DoF con mani destrose Inspire FTP

Soluzione / Soluzione Temporanea: Workaround confermato dall'utente: eseguire senza il flag --ee=inspire_ftp (cioè senza attivare le mani destrose FTP) per operare solo le braccia. Il maintainer ha notato che tutto il codice dell'end-effector è scritto per una coppia sinistra-destra, quindi una singola mano difettosa può rompere le cose. L'utente ha patchato la classe Inspire_Controller_FTP per gestire l'operazione a mano singola. Il maintainer ha anche suggerito di provare l'ultima versione del codice.

Fonti: github.com/unitreerobotics/xr_teleoperate #194

mano/gripper Blocca l'Uso Risolto dal Vendor

Entrambe le mani destrose Inspire rispecchiano solo il movimento della mano destra a causa di una configurazione errata della porta seriale

Sintomo: Durante la teleoperazione con due mani destrose Inspire, entrambe le mani seguono solo il movimento della mano destra. La causa root identificata nel thread è che il codice di esempio invia comandi per entrambe le mani alla stessa porta seriale.

Interessati: Unitree G1 con mani destrose Inspire DFX / RH56DFTP; codice di esempio inspire_ctrl.cpp dal pacchetto di esempio del vendor

Soluzione / Soluzione Temporanea: Correzione identificata dalla community confermata dal maintainer: modificare inspire_ctrl.cpp per inizializzare due porte seriali separate (serial1 = /dev/ttyUSB1, serial2 = /dev/ttyUSB2) e associare ogni mano alla sua rispettiva porta e ID. Il vendor ha fornito il codice inspire_ctrl.cpp corretto nei commenti.

Fonti: github.com/unitreerobotics/xr_teleoperate #46

SDK/software Blocca l'Uso Soluzione Temporanea Disponibile

Il simulatore unitree_mujoco va in crash con 'free(): invalid pointer' / 'Aborted (core dumped)' a runtime

Sintomo: Dopo aver avviato il binario del simulatore unitree_mujoco, il programma si avvia ("MuJoCo data is prepared") e poi si arresta immediatamente con l'errore "free(): invalid pointer" e "Aborted (core dumped)". Una variante precedente dell'errore era "Joystick open failed". Molteplici utenti segnalano questo problema nelle versioni MuJoCo 3.2.7 e 3.3.1.

Interessati: unitree_mujoco; MuJoCo 3.2.7 e 3.3.1; Ubuntu 22.04 e Ubuntu 24.04 con ROS2 Jazzy

Soluzione / Soluzione Temporanea: Un utente della community ha rintracciato il crash su Ubuntu 24.04 / ROS2 Jazzy in un conflitto del percorso delle librerie DDS (le librerie DDS di ROS2 Jazzy e quelle installate con unitree_sdk2 caricate simultaneamente). La risoluzione del conflitto di percorso ha risolto il crash per quell'utente. L'errore del joystick è stato corretto in un commit specifico (2f5459d). Nessuna soluzione singola confermata per tutte le varianti segnalate.

Fonti: github.com/unitreerobotics/unitree_mujoco #51

batteria/alimentazione Blocca l'Uso Aperto / Irrisolto

G1 si surriscalda e si spegne dopo pochi minuti di esecuzione del policy sonic_release, causando cadute

Sintomo: Tramite il driver GR00T-WholeBodyControl della community: Quando si implementa il policy sonic_release su un robot G1 reale a 29-DoF dotato di mani Dex3, il robot emette un avviso di surriscaldamento dopo pochi minuti anche restando fermo in posizione eretta, poi Sonic si spegne automaticamente, causando la caduta del robot più volte.

Interessati: Unitree G1 29-DoF EDU con mani Dex3; checkpoint GR00T-WholeBodyControl sonic_release

Soluzione / Soluzione Temporanea: Nessuna soluzione confermata

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

SDK/software Blocca l'Uso Aperto / Irrisolto

La sessione WebSocket si interrompe e la vista VR diventa nera quando si entra in modalità Realità Virtuale su Quest 3

Sintomo: Dopo aver connesso con successo Quest 3 alla pagina di teleoperazione (l'interfaccia vuer si carica ma mostra una schermata nera), cliccare su "Realità Virtuale" causa la disconnessione della sessione WebSocket. Il terminale mostra che la connessione è caduta. Un contributor della community ha rintracciato questo problema in un bug nel browser di Meta Quest 3 dove RTCPeerConnection.createOffer() non risolve mai la sua Promise, interrompendo il flusso WebRTC predefinito avviato dal client.

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

Soluzione / Soluzione Temporanea: Un contributor della community ha proposto di invertire la negoziazione WebRTC verso un flusso avviato dal server (il server crea l'offerta, il browser chiama createAnswer()) come soluzione alternativa. Nessuna correzione upstream confermata.

Fonti: github.com/unitreerobotics/xr_teleoperate #267

rete/connettività Blocca l'Uso Soluzione Temporanea Disponibile

La comunicazione DDS fallisce quando il PC host si connette al G1 tramite Wi-Fi invece che Ethernet

Sintomo: La teleoperazione funziona correttamente quando il laptop è connesso al robot tramite cavo Ethernet, ma fallisce con errori DDS quando si tenta di operare in modalità wireless tramite Wi-Fi. Inoltre, quando si esegue tutto sul PC2 del robot (Jetson), i problemi di connessione appaiono dopo circa 10 minuti.

Interessati: xr_teleoperate; hardware: Unitree G1 EDU con mani Inspire FTP e Apple Vision Pro

Soluzione / Soluzione Temporanea: Il maintainer suggerisce di utilizzare un proxy di inoltro DDS a livello applicativo, o di montare un router sul retro del G1 (subnet 192.168.123.*/24) alimentato dall'interfaccia di alimentazione del G1. Nessuna soluzione completa singola confermata.

Fonti: github.com/unitreerobotics/xr_teleoperate #234

Hai bisogno di aiuto professionale con il tuo Unitree G1?

Unisciti alla lista d'attesa per riparazioni e ti metteremo in contatto con tecnici certificati e partner di servizio.

Join the Repair Waitlist →