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: Bekannte Probleme & Lösungen

Zuletzt aktualisiert 23. August 2026

38 bekannte Probleme View robot profile →

Gewährleistungs- & Sicherheitshinweis: Die Gewährleistung beginnt mit Erhalt. Der Besitzer sendet das Gerät auf eigene Kosten zur Diagnose an Unitree. Die Gewährleistung wird durch Öffnen des Gehäuses, Demontage oder nicht autorisierte Änderungen VOIDED. Kein Verbraucher-Ersatzteile-Kanal; Händler bieten nur Erstsupport. G1 Basis ~8 Monate; G1 EDU ~18 Monate (EU 24 Monate). Quellen: https://www.unitree.com/mobile/terms/policy https://blog.robozaps.com/b/unitree-g1-review Die unten aufgeführten Workarounds stammen aus der Community und werden ohne Garantie bereitgestellt.

Motor/Aktuator Blockiert Nutzung Workaround vorhanden

Bein-/Hüft-/Knöchelmotoren überhitzen und erzwingen Abschaltung

Symptom: Knöchel-Roll-Motoren erreichen ~90°C innerhalb von 5-10 Minuten auch im Near-Idle; das linke Hüftgelenk überhitzt nach ~30 Minuten Teleoperation und löst eine automatische Systemabschaltung aus.

Betrifft: Gemeldet bei Drittanbieter-Ganzkörpersteuerungen (NVIDIA GEAR-SONIC / Isaac-GR00T N1.7 auf Jetson Orin NX). Unitree's Standard-Controller hält Knöchel bei 30-45°C.

Lösung / Workaround: Überhitzung hängt mit aggressiven Regler-Verstärkungen zusammen, nicht immer mit Hardwarefehler. Reduzieren Sie Kp/Kd-Verstärkungen, passen Sie die Stehhaltung an, um statische Last zu verringern, und bevorzugen Sie Unitree's Standard-Controller für längere Einsätze. Wenn Temps auch beim Standard-Controller ansteigen, stoppen Sie die Nutzung und inspizieren Sie — ein wirklich defekter Aktuator benötigt Service.

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

Motor/Aktuator Beeinträchtigt Nutzung Offen/Ungelöst

Schulter-/Armmotor überhitzt und wird schlaff mit Inspire Dextrous Hand

Symptom: Der Schulter-Pitch-Armmotor überhitzt nach kurzem Betrieb und der Arm verliert Reaktionsfähigkeit in Kombination mit der Inspire FTP Dextrous Hand.

Betrifft: G1 ARM7 + Inspire FTP Hand, ROS2 Humble; Benutzer mit PD-Verstärkungen kp=40 / kd=1.5.

Lösung / Workaround: Keine vom Hersteller dokumentierte Lösung. Community-Richtung: Der Arm benötigt Gravitations-/Nutzlast-Kompensation für die zusätzliche Handmasse und niedrigere Drehmomentgrenzen; Besitzer suchen noch Unitree's empfohlene PD-Verstärkungen für diese Kombination. Behandeln Sie es als Tuning-Problem, bevor Sie einen Hardwarefehler annehmen.

Quellen: github.com/unitreerobotics/unitree_sdk2_python #129

Firmware/Update Ärgernis Workaround vorhanden

Roboter ignoriert SDK-Befehle (fest im Damp-/Develop-Modus)

Symptom: G1 bootet in 'Damp-Modus' und ignoriert SDK-Befehle;进入'Develop-Modus' deaktiviert ebenfalls SDK-Reaktionsfähigkeit, sodass Benutzer schließen, dass das SDK defekt ist.

Betrifft: Allgemeines G1-Firmware-Verhalten.

Lösung / Workaround: Aktivieren Sie den Roboter mit der Fernbedienung, bevor Sie SDK-Befehle senden: Drücken Sie L1+A, dann L1+UP, um den Damp-Modus zu verlassen. Verwenden Sie nicht den Develop-Modus, wenn Sie SDK-Kontrolle benötigen. Wenn Sie den Develop-Modus aktiviert haben, erneuern Sie den ai-sport-Client über die App.

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

SDK/Software Beeinträchtigt Nutzung Vom Hersteller behoben

WaveHand/ShakeHand schlagen vom SDK aus fehl (Fehler 3203 'API not implemented')

Symptom: WaveHand- und ShakeHand-Armaktionen funktionieren von der Fernbedienung, schlagen aber von Python/C++/ROS2 fehl; ROS2 gibt Fehler 3203 'API not implemented on server' zurück.

Betrifft: Firmware vor v1.3.0.

Lösung / Workaround: Aktualisieren Sie die Roboter-Firmware auf v1.3.0 oder höher. Stellen Sie außerdem sicher, dass der Roboter aus dem Damp-Modus aktiviert ist (L1+A, L1+UP), bevor Sie die Befehle senden.

Quellen: github.com/unitreerobotics/unitree_sdk2_python #42

Firmware/Update Blockiert Nutzung Offen/Ungelöst

Code und offizielle Beispiele brechen nach Firmware 1.4.0 ab ('ClientStub send request error')

Symptom: Zuvor funktionierender Python-Code und offizielle SDK-Beispiele funktionieren nach dem Update auf Firmware 1.4.0 nicht mehr; wiederholte '[ClientStub] send request error'. Verwandt: GetVolume gibt Fehler 3102 zurück, High-Level-/Audio-Beispiele schlagen fehl.

Betrifft: Firmware 1.4.0.

Lösung / Workaround: Keine vom Hersteller dokumentierte Lösung. Bestätigen Sie, dass der Roboter aktiviert ist (aus dem Damp-Modus), verifizieren Sie, dass die SDK-Version zur Firmware passt, und wenn Sie speziell für eine Funktion aktualisiert haben, seien Sie sich bewusst, dass einige Benutzer ein Rollback durchgeführt haben. Beobachten Sie Unitree's Release-Notes für ein Follow-up-Patch.

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

Hand/Greifer Blockiert Nutzung Workaround vorhanden

Inspire-Hand öffnet Serial Port nicht / ist unter ihrer IP nicht erreichbar

Symptom: 'Serial Port /dev/ttyUSB0 öffnen fehlgeschlagen' — die Inspire-Hand kann nicht gesteuert werden; oder die FTP-Hand ist unter 192.168.123.211 nicht erreichbar.

Betrifft: G1 mit Inspire-Hand (DFX Serial vs. FTP Modbus-TCP-Varianten).

Lösung / Workaround: Die Steuermethode hängt von der Hand-Variante ab. FTP Inspire-Hands verwenden Modbus TCP, keinen Serial Port — Serial-Code auf einer FTP-Hand schlägt absichtlich fehl. Bestätigen Sie, welche Variante Sie haben, und verwenden Sie die passende Steuermethode; verifizieren Sie, dass die Hand-IP im 192.168.123.x-Netzwerk erreichbar ist.

Quellen: github.com/unitreerobotics/xr_teleoperate #51

Hand/Greifer Beeinträchtigt Nutzung Offen/Ungelöst

Dex3-1-Hand Daumen bewegt sich während Teleoperation kaum

Symptom: In der Teleop macht der Daumen nur 3-4° Mikrobewegungen gegenüber vollem Bewegungsbereich in der Simulation; Daumen-zu-Zeigefinger-Pinch endet bei ~5cm, zu grob für feine Manipulation.

Betrifft: G1 Software V1.4.7 + Dex3-1 Hand.

Lösung / Workaround: Keine dokumentierte Lösung. Der Einschalt-Selbsttest zeigt normale Gelenke und Simulation funktioniert, was auf eine Befehls-Mapping-Fehlanpassung zwischen Teleop und Hand-Treiber hindeutet, nicht auf Hardware. Melden Sie die Treiberversion an Unitree.

Quellen: github.com/unitreerobotics/xr_teleoperate #229

Netzwerk/Konnektivität Beeinträchtigt Nutzung Offen/Ungelöst

Teleoperations-Latenz wächst nach 1-2 Stunden auf ~2.5s

Symptom: Arm- und Kameralatenz steigt nach längerer Teleop auf ~2.5s; Arm-Prep-Pose dauert ~4s statt ~2s, erscheint schließlich sofort beim Start.

Betrifft: xr_teleoperate v1.3 und v1.5.

Lösung / Workaround: Keine dokumentierte Lösung. Ein Upgrade auf einen Gigabit-Router und WiFi 6 half nicht, und der Simulationsmodus ist nicht betroffen — was auf ein Onboard-Pufferungs-/Akkumulationsproblem hindeutet, nicht auf das Netzwerk. Starten Sie den Teleop-Stack zwischen langen Sitzungen als Notlösung neu.

Quellen: github.com/unitreerobotics/xr_teleoperate #247

Netzwerk/Konnektivität Beeinträchtigt Nutzung Workaround vorhanden

Richtlinien-Deployment über WiFi hängt bei 'Waiting for connection rt/lowstate'

Symptom: Deployment über WiFi hängt bei 'Waiting for connection rt/lowstate', obwohl SSH zum Roboter funktioniert; kabelgebundenes Ethernet funktioniert einwandfrei.

Betrifft: G1, DDS-basierte Steuerung.

Lösung / Workaround: Verwenden Sie eine kabelgebundene Verbindung und geben Sie die Schnittstelle an, z.B. ./g1_ctrl --network enx701988512412. DDS-Multicast für Lowstate wird nicht zuverlässig über die WLAN-Schnittstelle übertragen.

Quellen: github.com/unitreerobotics/unitree_rl_lab #93

SDK/Software Blockiert Nutzung Workaround vorhanden

CycloneDDS Versionskonflikt führt zum Absturz der G1-Sim-Initialisierung

Symptom: DDS-Assertion fehlgeschlagen / CycloneDDS Writer-Fehler bei der Initialisierung der G1-Simulation; sie startet nicht.

Betrifft: Ubuntu 22.04, ROS2 Humble; System CycloneDDS 0.10.5 vs. Python CycloneDDS 0.10.2.

Lösung / Workaround: ROS-Setup-Skript nicht sourcen (dessen DDS-Bibliotheken unterscheiden sich von unitree_sdk2). Überprüfen Sie, welche .so zur Kompilierzeit verknüpft ist. Alternativen: CycloneDDS 0.10.2 aus dem Quellcode bauen, unitree-sdk2py für 0.10.5 patchen oder auf Ubuntu 20.04 entwickeln.

Quellen: github.com/unitreerobotics/unitree_mujoco #60

SDK/Software Blockiert Nutzung Workaround vorhanden

„Unmatched robot type" bei Ethernet-Verbindung (23 vs. 29 DoF)

Symptom: Der Controller verbindet sich über Ethernet und schlägt dann sofort mit „Unmatched robot type" während der Sim-to-Real-Implementierung fehl.

Betrifft: G1 23-DoF und 29-DoF Varianten (inkl. Locked-Waist/Dummy-Hands Konfigurationen).

Lösung / Workaround: Die DoF/Konfiguration des Roboters muss mit dem erwarteten Typ des Controllers übereinstimmen. Setzen Sie die korrekten DoF in Ihrer Konfiguration und prüfen Sie auf widersprüchliche SDK-Installationen in /usr/local vs. Ihrem Projektpfad — ein sauberer Rebuild von unitree_sdk2 (Deploy-Build mit -DBUILD_EXAMPLES=OFF, Sim-Build mit separatem CMAKE_INSTALL_PREFIX) löst den zugehörigen Fall des nicht reagierenden Velocity-Modus.

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

SDK/Software Beeinträchtigt Nutzung Offen/Ungelöst

Arme via SDK bewegen während Gehen destabilisiert Balance

Symptom: Arme via SDK steuern während Gehen (Gamepad) lässt den Roboter sich nach vorne beugen oder die Balance verlieren; Arme heben beim Gehen erzeugt einen instabilen, schweren Gang.

Betrifft: G1 mit 3-DoF Hüfte.

Lösung / Workaround: Keine dokumentierte Lösung. Nullen der Hüftachsen, Halten der Anfangswerte und Nicht-Anrühren wurden alle ohne Erfolg versucht — der Arm-SDK-Controller und der Lokomotions-Balance-Controller stehen in Konflikt. Vermeiden Sie große Armbewegungen während der Fortbewegung, bis ein Firmware-Update dies adressiert.

Quellen: github.com/unitreerobotics/unitree_sdk2_python #146

SDK/Software Beeinträchtigt Nutzung Workaround vorhanden

Simulierter G1 kollabiert ohne Standard-Stabilisierung

Symptom: In der MuJoCo-Simulation hat der G1 keine Standard-Stabilisierung und fällt um, wenn er ohne Steuerung betrieben wird.

Betrifft: unitree_mujoco.

Lösung / Workaround: Aktivieren Sie das Elastic Band: setzen Sie enable_elastic_band: 1 in unitree_mujoco/simulate/config.yaml (oder ENABLE_ELASTIC_BAND=True). Beachten Sie, dass der Werkseigene Motion-Controller in der Simulation nicht verfügbar ist und das Band beim Umschalten auf Joystick-Steuerung umständlich deaktiviert werden kann.

Quellen: github.com/unitreerobotics/unitree_mujoco #57

Akku/Strom Ärgernis Unklar

Kurze Akkulaufzeit (~2 Stunden)

Symptom: Der 9.000 mAh Akku liefert nur etwa 2 Stunden pro Ladung und entlädt sich schneller bei dynamischen Bewegungen.

Betrifft: Basismodell, 9.000 mAh Pack.

Lösung / Workaround: Dies ist eine Kapazitätsbeschränkung, kein Defekt. Halten Sie geladene Ersatzakkus für Hot-Swapping zwischen Sitzungen bereit; kalkulieren Sie mit ca. ~2 Stunden aktiver Nutzung.

Quellen: blog.robozaps.com/b/…

Sonstiges Blockiert Nutzung Unklar

Basis-G1 kann nicht programmiert werden — kein SDK

Symptom: Käufer des ~$13.500 Basis-G1 entdecken, dass es eine Demo-/Vorführeinheit ohne SDK ist und nicht programmiert werden kann.

Betrifft: G1 Base (23 DoF) vs. G1 EDU (bis zu 43 DoF).

Lösung / Workaround: Dies ist eine Produkt-Tier-Beschränkung. SDK-Zugang, höheres Drehmoment und mehr DoF erfordern die G1 EDU / Entwicklerplattform (~$44k-$74k). Bestätigen Sie die Stufe vor dem Kauf, wenn Sie entwickeln möchten.

Quellen: blog.robozaps.com/b/…

Mechanisch/Strukturell Blockiert Nutzung Workaround vorhanden

Dauerhaft rote LED / Checkliste für physische Fehler (Stürze, Kabel, Akku)

Symptom: Dauerhaft rote LED zeigt Software-/Hardwarefehler an; plus Feldfehler — Risse/Beulen durch Stürze, Sensorverschlechterung durch Staub oder Fehlausrichtung, nicht reagierende Komponenten durch lockere/ausgefranzte Kabel, Akku-Aufblähen oder Verformung.

Betrifft: Allgemein.

Lösung / Workaround: Visuell auf Aufprallschäden prüfen; Sensoren reinigen und Montage bestätigen; Kabel und Stecker erneut fest anschließen; Akkusitz prüfen und bei Aufblähen oder Auslaufen ersetzen. Bei dauerhaft roter LED die Mobile-App-Diagnose ausführen und ein Video von intermittierenden Fehlern aufnehmen, bevor Sie den Support kontaktieren. Hinweis: Öffnen des Gehäuses erlischt die Garantie.

Quellen: docs.westonrobot.com/tutorial/…

Sicherheit/Datenschutz Blockiert Nutzung Offen/Ungelöst

Kritische Sicherheitslücke: BLE-Befehlsinjektion mit hartcodierten Schlüsseln (UniPwn)

Symptom: Eine Befehlsinjektionsschwachstelle in der BLE-WLAN-Bereitstellung, die hartcodierte AES-Schlüssel verwendet, die von allen Einheiten gemeinsam genutzt werden, ermöglicht Root-Zugriff und ist potenziell wormbar. Separate Forschung fand Telemetriedaten, die alle ~5 Minuten an externe Server übertragen wurden.

Betrifft: G1 (Forscher geben an, dass Go2/H1 gemeinsame Codepfade teilen). Öffentlicher „UniPwn" Exploit veröffentlicht.

Lösung / Workaround: Kein bestätigter Vendor-Patch zum Zeitpunkt der Erstellung dokumentiert. Auf Netzwerkebene abfedern: Roboter in einem segmentierten/gefeuerteten Netzwerk isolieren, Zugriff auf seine interne Schnittstelle (192.168.123.0/24) einschränken und unerwarteten ausgehenden Datenverkehr blockieren. Auf ein Unitree-Firmware-Advise achten.

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

Sonstiges Ärgernis Unklar

Virale Demo-Fähigkeiten sind choreografiert, nicht autonom

Symptom: Kung-Fu und Rückwärtssaltos sind trainierte Vorführungen; der Roboter hat keine Haushaltsautonomie out-of-the-box und scheitert bei einfachen Aufgaben wie Türöffnen.

Betrifft: Allgemein.

Lösung / Workaround: Erwartungsmanagement, kein Fehler. Autonome Aufgabenleistung erfordert erhebliche Entwicklung auf der EDU-Plattform; das Basiserlebnis sind Fern-/vorprogrammierte Bewegungen.

Quellen: blog.robozaps.com/b/…

SDK/Software Blockiert Nutzung Vom Hersteller behoben

G1 23-DOF Roboter bewegt sich erratisch in MuJoCo Sim2Sim

Symptom: Beim Ausführen von Sim2Sim in MuJoCo mit einer in Isaac Lab trainierten Policy für die G1 23-DOF Konfiguration, läuft der Roboter nicht richtig und bewegt sich erratisch. Die vermutete Ursache, die im Thread gemeldet wurde, ist, dass Motor-IDs nicht für die 23-DOF Version angepasst wurden.

Lösung / Workaround: Vendor (Agnel-Wang) hat 23-DOF Deploy-Code zum Repository hinzugefügt; Reporter bestätigte erfolgreiche Sim2Real nach Verwendung des aktualisierten Codes.

Quellen: github.com/unitreerobotics/unitree_rl_lab #27

Netzwerk/Konnektivität Blockiert Nutzung Offen/Ungelöst

G1_29_ArmController druckt wiederholt 'Waiting to subscribe dds' und Roboter-App meldet Firmware-Kommunikationsfehler

Symptom: Beim Ausführen des Teleoperationsskripts Schleift der Controller endlos mit '[G1_29_ArmController] Waiting to subscribe dds...' und die mobile App meldet '底层固件通信故障' (zugrunde liegender Firmware-Kommunikationsfehler). Die DDS-Kommunikation zwischen dem Host-Gerät und dem Roboter wird nicht hergestellt, obwohl sich die Geräte im selben Netzwerk befinden.

Lösung / Workaround: Der Maintainer schlägt vor, die Netzwerkverbindung mit 'cyclonedds ps' und 'cyclonedds subscribe rt/lowstate' zu überprüfen; wenn das Problem nicht behoben wird, ein Support-Ticket einreichen. Ein Kommentator berichtete, dass Low-Level-Beispiele funktionierten, aber High-Level-Arm-Beispiele keine Roboterbewegung und Sendefehler erzeugten.

Quellen: github.com/unitreerobotics/xr_teleoperate #57

Netzwerk/Konnektivität Blockiert Nutzung Offen/Ungelöst

Apple Vision Pro WebSocket trennt sich bei jedem Seitenaufruf in der Teleoperationskonfiguration sofort

Symptom: Beim Zugriff auf den Teleoperationsserver von Apple Vision Pro Safari aus, verbindet sich der WebSocket, trennt sich aber bei jedem Seitenaufruf sofort, was 'AssertionError: Websocket session is missing.' auf dem Server erzeugt. Das Aktualisieren der Seite wiederholt den Verbindungs-/Trennungszyklus; die einzigen gefundenen Workarounds sind das Abnehmen des AVP-Headsets oder das vollständige Schließen von Safari und das Warten einiger Sekunden.

Betrifft: vuer 0.0.60, televuer 4.0.0, xr_teleoperate commit 9fadc51, visionOS neueste Version

Lösung / Workaround: Temporär stabile Verbindung erreicht durch Abnehmen des AVP oder vollständiges Schließen von Safari für einige Sekunden. Der Maintainer schlug vor, 'https://vuer.ai/?ws=wss://host ip:8012' zu versuchen, aber keine bestätigte Lösung wurde bereitgestellt.

Quellen: github.com/unitreerobotics/xr_teleoperate #271

SDK/Software Blockiert Nutzung Offen/Ungelöst

WBC Policy streamt Werte, aber echter G1 bewegt sich nach Handkalibrierung nicht

Symptom: Über den Community GR00T-WholeBodyControl Treiber: Nachdem der Roboter in den Debug-Modus wechselt und die Hände erfolgreich kalibrieren, bewegt sich der G1 überhaupt nicht, obwohl das Terminal zeigt, dass die Policy Werte zum Roboter streamt. Es werden keine Fehler gemeldet und die parallele Simulation läuft korrekt.

Lösung / Workaround: Keine bestätigte Lösung

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

SDK/Software Beeinträchtigt Nutzung Offen/Ungelöst

Vuer Bildfeed auf Quest 3 friert beim ersten Frame während Echt-Roboter-Teleoperation ein

Symptom: Beim Ausführen der Teleoperations-Pipeline mit einem Quest 3 Headset zeigt die Vuer-Anzeige nur das erste aufgenommene Frame und friert dann ein, während der Bildclient auf dem PC die funktionierende Live-Kamerafeed bestätigt. Das Problem wurde sowohl im Main-Branch als auch mit dem teleimager-Branch reproduziert.

Betrifft: vuer 0.0.67, xr_teleoperate (Controller-Modus, G1_29)

Lösung / Workaround: Der Maintainer schlug vor, zum teleimager-Branch zu wechseln (WebRTC-Streaming); der Reporter verwendete den Branch, bemerkte aber, dass er keine Simulationsbereitstellung unterstützt. Keine vollständig bestätigte Lösung für das eingefrorene Frame-Problem.

Quellen: github.com/unitreerobotics/xr_teleoperate #172

Netzwerk/Konnektivität Blockiert Nutzung Offen/Ungelöst

Teleoperationsseite wird schwarz und WebSocket trennt sich beim Betreten des VR-Modus auf Apple Vision Pro

Symptom: Nachdem das Vision Pro erfolgreich den binocularen Kamerafeed anzeigt, führt das Klicken auf 'Virtual Reality' und das Gewähren der Hand-Tracking-Berechtigung dazu, dass das Display schwarz wird und der WebSocket sich sofort trennt, was 'AssertionError: Websocket session is missing.' auslöst. Der Fehler-Traceback stammt aus vuer/server.py.

Lösung / Workaround: Der Maintainer schlug vor, nur 5 GHz Wi-Fi zu verwenden, die Ping-Latenz zum AVP zu überwachen (sollte unter 50 ms liegen), mit dem televuer-Skript direkt zu testen und vuer Version 0.0.32rc7 zu versuchen. Keine bestätigte Lösung gemeldet.

Quellen: github.com/unitreerobotics/xr_teleoperate #115

SDK/Software Blockiert Nutzung Workaround vorhanden

G1 läuft nicht, wenn Lokomotionsbefehl über Teleoperationscontroller ausgegeben wird; Joystick-Eingabe ignoriert

Symptom: Bei Verwendung des Controller-Modus des Teleoperationsskripts mit dem --motion Flag funktioniert die Armsteuerung korrekt, aber der Roboter reagiert nicht auf Joystick-Befehle zum Laufen. Selbst nach Beenden des Programms kann auch die physische Fernbedienung den Roboter nicht zum Laufen bringen, obwohl Armgesten normal funktionieren.

Betrifft: ai_sport Version nicht spezifiziert; xr_teleoperate, G1_29

Lösung / Workaround: Der Maintainer identifizierte, dass sich der ai_sport Lokomotions-Service-Name bei Version 8.2.0.0 geändert hat (LOCO_SERVICE_NAME muss 'sport' für >=8.2.0.0 sein, 'loco' für frühere Versionen). Er riet auch, den korrekten Netzwerkschnittstellennamen im Code anzugeben, wenn auf einem Multi-NIC-Gerät ausgeführt. Der Maintainer bestätigte, dass Lokomotion auf seinem Roboter mit Version 8.4.0.0 nach einem git pull Update funktionierte.

Quellen: github.com/unitreerobotics/xr_teleoperate #77

Show all 38 issues

SDK/Software Blockiert Nutzung Offen/Ungelöst

G1 Gelenke bewegen sich nicht, nachdem Teleoperationsprogramm gestartet und 'r' gedrückt wurde

Symptom: Das Teleoperationsprogramm startet ohne Fehler, DDS scheint sich zu verbinden, und das AVP zeigt den Live-Kamerafeed mit Arm-Tracking, aber der G1 Roboter bewegt sich nicht, wenn das Programm läuft und nach dem Drücken von 'r' zum Starten. Gelenkpositionsausgabe fehlt im Protokoll, anders als erwartet. Das Betreten des Debug-Modus aus dem Programm heraus wird als inkonsistent gemeldet.

Betrifft: G1 29-DOF mit Inspire dftp Händen, AVP

Lösung / Workaround: Keine bestätigte Lösung

Quellen: github.com/unitreerobotics/xr_teleoperate #189

SDK/Software Blockiert Nutzung Offen/Ungelöst

VR-Headset zeigt nur blaues Gitter, Roboter in XR Teleoperation nicht sichtbar

Symptom: Beim Ausführen der XR-Teleoperation in der Simulation mit einem Meta Quest 3 betritt der Benutzer erfolgreich den VR-Modus, sieht aber nur blaue Gitter statt des Roboters. Das Simulationsterminal zeigt auch '[DDSManager] object g1 not found' und 'g1_robot_dds is not initialized'.

Betrifft: unitree_sim_isaaclab mit Isaac-PickPlace-Cylinder-G129-Dex3-Joint Aufgabe; xr_teleoperate teleop_hand_and_arm.py; Meta Quest 3

Lösung / Workaround: Keine bestätigte Lösung

Quellen: github.com/unitreerobotics/xr_teleoperate #112

SDK/Software Blockiert Nutzung Workaround vorhanden

G1 sim2sim-Richtlinie führt dazu, dass Roboter nach links driftet und Arme unkontrolliert in MuJoCo schüttelt

Symptom: Beim Einsatz einer trainierten RL-Richtlinie (oder der bereitgestellten v0-Richtlinie) von unitree_rl_lab in MuJoCo über simulate_python driftet der G1-Roboter zur linken Seite, schüttelt seine Arme mit hoher Frequenz und niedriger Amplitude und ist kaum mit dem Joystick steuerbar. Der Roboter zittert auch unmittelbar nach dem Drücken der Bewegungsaktivierungstastenfolge.

Betrifft: unitree_rl_lab (neueste Version); Isaac Sim + Isaac Lab; unitree_mujoco mit G1 29dof; simulate_python (nicht simulate mit C++)

Lösung / Workaround: Community-Vorschlag: Erhöhen Sie den Arm- und Handgelenk-Armature-Wert in der MuJoCo g1_29dof.xml, um Arms shaking zu reduzieren. Keine bestätigte Lösung für das allgemeine Drift-/Instabilitätsproblem.

Quellen: github.com/unitreerobotics/unitree_rl_lab #31

SDK/Software Blockiert Nutzung Workaround vorhanden

RuntimeError 'list index out of range' in unitree_mujoco beim Ausführen von G1 mit Handkonfiguration

Symptom: Das Ausführen von unitree_mujoco.py für G1 (oder H1 mit Inspire-Händen) erzeugt '[RecurrentThread] target func raise exception: name=IndexError, args=("list index out of range",)' zur Laufzeit. Der Fehler tritt auf, wenn versucht wird, den Roboter mit Handbefestigungen zu simulieren.

Betrifft: unitree_mujoco; G1 mit Hand (scene_29dof_with_hand.xml); H1 mit Inspire-Händen

Lösung / Workaround: Community-Workaround: Verwenden Sie statt scene_29dof_with_hand.xml die Datei scene_29dof.xml. Stellen Sie außerdem sicher, dass der ROBOT-Name in config.py genau einem der unterstützten Namen entspricht (z.B. 'g1') und keine Variante wie 'g1_23dof' ist.

Quellen: github.com/unitreerobotics/unitree_mujoco #52

SDK/Software Blockiert Nutzung Offen/Ungelöst

High-Level SDK-Befehle geben 'send request error' auf G1 zurück; Low-Level-Befehle funktionieren

Symptom: Beim Ausführen von High-Level SDK-Befehlen (z.B. g1_loco_client_example.py) gibt der Client '[ClientStub] send request error. id: <id>' aus und der Befehl wird nicht ausgeführt. Low-Level-Skripte (g1_low_level_example.py) funktionieren korrekt.

Betrifft: unitree_sdk2_python; G1-Roboter; g1_loco_client_example.py High-Level-Befehle

Lösung / Workaround: Keine bestätigte Lösung

Quellen: github.com/unitreerobotics/unitree_sdk2_python #54

SDK/Software Blockiert Nutzung Workaround vorhanden

WebSocket trennt sofort beim Betreten des VR-Modus auf Meta Quest 3 mit Hand-Tracking-Eingabe

Symptom: Bei der Verwendung von xr_teleoperate mit einer Meta Quest 3 bricht die WebSocket-Verbindung zur Vuer-Seite auf Port 8012 sofort ab, wenn auf die Virtual-Reality-Schaltfläche geklickt wird, mit der Ausgabe 'websocket is now disconnected' und 'AssertionError: Websocket session is missing.' Das Problem ist spezifisch für den Hand-Tracking-Eingabemodus; der Wechsel zum Controller-Eingabemodus hält die Verbindung aktiv.

Betrifft: xr_teleoperate v1.5; vuer 0.0.60; aiohttp 3.10.5; Meta Quest 3 Standardbrowser; Ubuntu-Host; Isaac Sim 5.1 + unitree_sim_isaaclab; G1_29 + Inspire

Lösung / Workaround: Community-Workaround: Ein Downgrade von xr_teleoperate auf v1.1 behebt das Verbindungsproblem.Alternativ hält --input-mode=controller die WebSocket-Verbindung aufrecht. Die Verwendung des Wolvic-Browsers anstelle des Meta Quest-Standardbrowsers verhindert ebenfalls das WebSocket-Trennen, wobei Kamerastreaming-Probleme bestehen bleiben.

Quellen: github.com/unitreerobotics/xr_teleoperate #296

SDK/Software Blockiert Nutzung Offen/Ungelöst

Teleoperation-VR-Seite über lokale IP nicht erreichbar; WebSocket trennt beim Betreten des VR-Modus

Symptom: Beim Zugriff auf die Teleoperationsschnittstelle über die lokale IP-Adresse (https://<host-ip>:8012?ws=wss://<host-ip>:8012) lädt die Seite entweder nicht oder zeigt einen schwarzen Bildschirm. Beim Betreten von VR/Pass-Through (WebXR-Modus) trennt der WebSocket und der Roboter empfängt keine Tracking-Daten mehr, mit der Servermeldung 'Websocket session is missing' und gelegentlichen aiohttp 'resume_writing() AssertionError'.

Betrifft: vuer 0.0.60, televuer 4.0.0; Hardware: Unitree G1 29-DoF EDU mit Inspire RH56DFTP, Meta Quest 3 und Apple Vision Pro (visionOS 26.4)

Lösung / Workaround: Der Maintainer empfiehlt zu überprüfen, ob die Host-IP im SAN-Feld des Zertifikats enthalten ist, Inkognito-/Privatbrowsing zu verwenden und versionierte vuer/televuer-Kombinationen zu testen. Ein Community-Beitragender identifizierte, dass Quest Browsers RTCPeerConnection.createOffer() niemals aufgelöst wird, und schlug einen serverinitiierten WebRTC-Flow als Workaround vor, der jedoch nicht offiziell upstreamed wurde. Keine bestätigte Lösung vom Hersteller.

Quellen: github.com/unitreerobotics/xr_teleoperate #297

SDK/Software Blockiert Nutzung Workaround vorhanden

Teleoperationsprogramm beendet sich automatisch kurz nachdem der Roboter die Arme hebt, wenn Inspire FTP-Hand aktiviert ist

Symptom: Beim Starten von teleop_hand_and_arm.py mit aktivierter Inspire FTP dexterous Hand (--ee=inspire_ftp) hebt der Roboter beide Arme leicht an und dann endet das Programm automatisch, lässt die Arme fallen. Das Protokoll zeigt, dass der Bildclient unerwartet geschlossen wird und das Programm ohne klare Fehlermeldung beendet.

Betrifft: xr_teleoperate; Hardware: Unitree G1 29-DoF mit Inspire FTP dexterous Händen

Lösung / Workaround: Vom Benutzer bestätigter Workaround: Führen Sie das Programm ohne das Flag --ee=inspire_ftp aus (d.h. ohne Aktivierung der FTP dexterous Hände), um nur die Arme zu betreiben. Der Maintainer bemerkte, dass der gesamte End-Effector-Code für ein Links-Rechts-Paar geschrieben wurde, sodass eine defekte Hand die Funktionalität beeinträchtigen kann. Der Benutzer patchte die Inspire_Controller_FTP-Klasse für Einzelhandbetrieb. Der Maintainer schlug auch vor, die neueste Codeversion zu testen.

Quellen: github.com/unitreerobotics/xr_teleoperate #194

Hand/Greifer Blockiert Nutzung Vom Hersteller behoben

Beide Inspire dexterous Hände spiegeln nur die Bewegung der rechten Hand aufgrund von Serial-Port-Fehlkonfiguration

Symptom: Während der Teleoperation mit zwei Inspire dexterous Händen folgen beide Hände nur der Bewegung der rechten Hand. Die im Thread identifizierte Grundursache ist, dass der Beispielcode Befehle für beide Hände an denselben Serial-Port sendet.

Betrifft: Unitree G1 mit Inspire DFX / RH56DFTP dexterous Händen; Beispielcode inspire_ctrl.cpp aus dem Hersteller-Beispielpaket

Lösung / Workaround: Community-identifizierte Lösung, vom Maintainer bestätigt: Ändern Sie inspire_ctrl.cpp, um zwei separate Serial-Ports zu initialisieren (serial1 = /dev/ttyUSB1, serial2 = /dev/ttyUSB2) und binden Sie jede Hand an ihren jeweiligen Port und ID. Der Hersteller stellte korrigierten inspire_ctrl.cpp-Code in den Kommentaren bereit.

Quellen: github.com/unitreerobotics/xr_teleoperate #46

SDK/Software Blockiert Nutzung Workaround vorhanden

unitree_mujoco-Simulator stürzt mit 'free(): invalid pointer' / 'Aborted (core dumped)' zur Laufzeit ab

Symptom: Nach dem Starten der unitree_mujoco Simulator-Binary startet das Programm ('MuJoCo data is prepared') und stürzt dann sofort mit 'free(): invalid pointer' und 'Aborted (core dumped)' ab. Eine frühere Variante des Fehlers war 'Joystick open failed'. Mehrere Benutzer berichten dies über MuJoCo Versionen 3.2.7 und 3.3.1.

Betrifft: unitree_mujoco; MuJoCo 3.2.7 und 3.3.1; Ubuntu 22.04 und Ubuntu 24.04 mit ROS2 Jazzy

Lösung / Workaround: Ein Community-Nutzer führte den Absturz auf Ubuntu 24.04 / ROS2 Jazzy auf einen DDS-Bibliothekspfad-Konflikt zurück (ROS2 Jazzy's DDS-Bibliotheken und unitree_sdk2-installierte DDS-Bibliotheken werden gleichzeitig geladen). Das Auflösen des Pfadkonflikts behebte den Absturz für diesen Benutzer. Der Joystick-Fehler wurde in einem spezifischen Commit (2f5459d) behoben. Keine einzelne bestätigte Lösung für alle gemeldeten Varianten.

Quellen: github.com/unitreerobotics/unitree_mujoco #51

Akku/Strom Blockiert Nutzung Offen/Ungelöst

G1 überhitzt und schaltet sich nach wenigen Minuten beim Ausführen der sonic_release-Richtlinie ab

Symptom: Über den Community GR00T-WholeBodyControl-Treiber: Beim Einsatz der sonic_release-Richtlinie auf einem echten 29-DoF G1-Roboter mit Dex3-Händen zeigt der Roboter bereits nach wenigen Minuten eine Überhitzungswarnung, selbst im Stehen, dann fährt Sonic automatisch herunter, was dazu führt, dass der Roboter mehrfach umfällt.

Betrifft: Unitree G1 29-DoF EDU mit Dex3-Händen; GR00T-WholeBodyControl sonic_release Checkpoint

Lösung / Workaround: Keine bestätigte Lösung

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

SDK/Software Blockiert Nutzung Offen/Ungelöst

WebSocket-Sitzung wird getrennt und VR-Ansicht wird schwarz beim Betreten des Virtual Reality-Modus auf Quest 3

Symptom: Nach erfolgreicher Verbindung von Quest 3 mit der Teleoperationsseite (vuer-Interface lädt, zeigt aber einen schwarzen Bildschirm) führt das Klicken auf 'Virtual Reality' dazu, dass die WebSocket-Sitzung getrennt wird. Das Terminal zeigt, dass die Verbindung abgebrochen wurde. Ein Community-Beitragender führte dies auf einen Bug in Meta Quest 3's Browser zurück, bei dem RTCPeerConnection.createOffer() sein Promise niemals auflöst, was den standardmäßigen client-initiierten WebRTC-Flow unterbricht.

Betrifft: xr_teleoperate; Hardware: G1-EDU 29-DoF mit Dex3-1, Meta Quest 3

Lösung / Workaround: Community-Beitragender schlug vor, die WebRTC-Verhandlung auf einen server-initiierten Flow umzukehren (Server erstellt Offer, Browser ruft createAnswer() auf) als Workaround. Keine bestätigte Upstream-Lösung.

Quellen: github.com/unitreerobotics/xr_teleoperate #267

Netzwerk/Konnektivität Blockiert Nutzung Workaround vorhanden

DDS-Kommunikation schlägt fehl, wenn Host-PC über Wi-Fi statt über Ethernet eine Verbindung zum G1 herstellt

Symptom: Teleoperation funktioniert korrekt, wenn der Laptop über ein Ethernet-Kabel mit dem Roboter verbunden ist, schlägt aber mit DDS-Fehlern fehl, wenn drahtlos über Wi-Fi gearbeitet werden soll. Zusätzlich treten bei der Ausführung auf dem PC2 des Roboters (Jetson) nach etwa 10 Minuten Verbindungsprobleme auf.

Betrifft: xr_teleoperate; Hardware: Unitree G1 EDU mit Inspire FTP-Händen und Apple Vision Pro

Lösung / Workaround: Maintainer schlägt vor, einen DDS-Weiterleitungsproxy auf Anwendungsebene zu verwenden oder einen Router auf der Rückseite des G1 zu montieren (Subnetz 192.168.123.*/24), der von der Stromschnittstelle des G1 versorgt wird. Keine einzelne bestätigte vollständige Lösung.

Quellen: github.com/unitreerobotics/xr_teleoperate #234

Brauchen Sie professionelle Hilfe mit Ihrem Unitree G1?

Treten Sie der Reparatur-Warteliste bei und wir verbinden Sie mit zertifizierten Technikern und Servicepartnern.

Join the Repair Waitlist →