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.

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: المشاكل المعروفة والإصلاحات

آخر تحديث August 23, 2026

38 مشكلة معروفة View robot profile →

إشعار الضمان والسلامة: يبدأ الضمان من تاريخ الاستلام. يقوم المالك بشحن الوحدة إلى Unitree على نفقته الخاصة للتشخيص. يتم إبطال الضمان بفتح الهيكل أو التفكيك أو التعديل غير المصرح به. لا يوجد قناة قطع غيار للمستهلكين؛ يقدم الوكلاء الدعم من المستوى الأول فقط. G1 الأساسي ~8 أشهر؛ G1 EDU ~18 شهرًا (الاتحاد الأوروبي 24 شهرًا). المصادر: https://www.unitree.com/mobile/terms/policy https://blog.robozaps.com/b/unitree-g1-review الحلول البديلة المذكورة أدناه مصدرها المجتمع ويتم تقديمها دون ضمان.

المحرك/المشغل يمنع الاستخدام يوجد حل بديل

محركات الساق/الورك/الكاحل ترتفع حرارتها وتتسبب في الإغلاق

العرض: تصل محركات الكاحل الدوامية إلى ~90 درجة مئوية خلال 5-10 دقائق حتى في حالة الخمول القريب؛ يسخن مفصل الورك الأيسر بعد ~30 دقيقة من التشغيل عن بُعد ويتسبب في إيقاف تلقائي للنظام.

متأثر: تم الإبلاغ عنه مع وحدات التحكم للجسم بالكامل من أطراف ثالثة (NVIDIA GEAR-SONIC / Isaac-GR00T N1.7 على Jetson Orin NX). تحافظ وحدة التحكم الأصلية من Unitree على درجة حرارة الكاحل عند 30-45 درجة مئوية.

الإصلاح / الحل البديل: ترتبط مشكلة ارتفاع الحرارة بمكاسب المتحكم العدوانية، وليست دائمًا عطلًا في الأجهزة. قلل من مكاسب Kp/Kd، واضبط وضعية الوقوف لتقليل الحمل الساكن، وفضل استخدام وحدة التحكم الأصلية من Unitree للعمليات الممتدة. إذا ارتفعت درجات الحرارة على وحدة التحكم الأصلية أيضًا، توقف عن الاستخدام وافحص — المحرك المعطل يحتاج إلى صيانة.

المصادر: github.com/NVlabs/GR00T-WholeBodyControl #174 github.com/NVlabs/GR00T-WholeBodyControl #71

المحرك/المشغل يقلل من الاستخدام مفتوح / غير محلول

محرك الكتف/الذراع يسخن过度 ويتحول إلى حالة رخوة مع يد Inspire الماهرة

العرض: يسخن محرك ذراع كتف-الرفع بعد فترة قصيرة من التشغيل ويفقد الذراع استجابته عند إقرانه بيد Inspire FTP الماهرة.

متأثر: G1 ARM7 + يد Inspire FTP، ROS2 Humble؛ المستخدمون الذين يشغلون مكاسب PD kp=40 / kd=1.5.

الإصلاح / الحل البديل: لم يتم توثيق إصلاح من المورد. الاتجاه من المجتمع: يحتاج الذراع إلى تعويض الجاذبية/الحمولة للكتلة الإضافية لليد وحدود عزم الدوران المنخفضة؛ لا يزال المالكون يبحثون عن مكاسب PD الموصى بها من Unitree لهذا الإقران. عالجها كمشكلة في الضبط قبل افتراض فشل الأجهزة.

المصادر: github.com/unitreerobotics/unitree_sdk2_python #129

البرامج الثابتة/التحديث إزعاج يوجد حل بديل

الروبوت يتجاهل أوامر SDK (عالق في وضع التخميد / وضع التطوير)

العرض: يتم تمهيد G1 في "وضع التخميد" ويتجاهل أوامر SDK؛ يؤدي إدخال "وضع التطوير" أيضًا إلى تعطيل استجابة SDK، لذلك يستنتج المستخدمون أن SDK معطل.

متأثر: سلوك البرامج الثابتة العام لـ G1.

الإصلاح / الحل البديل: قم بتنشيط الروبوت باستخدام جهاز التحكم عن بُعد قبل إرسال أوامر SDK: اضغط على L1+A، ثم L1+UP للخروج من وضع التخميد. لا تجلس في وضع التطوير إذا كنت بحاجة إلى تحكم SDK. إذا دخلت وضع التطوير، قم بتجديد برنامج ai-sport عبر التطبيق.

المصادر: github.com/unitreerobotics/unitree_sdk2_python #42 github.com/unitreerobotics/unitree_sdk2_python #43

SDK/البرمجيات يقلل من الاستخدام تم الإصلاح من قبل المورد

WaveHand / ShakeHand تفشل من SDK (خطأ 3203 "API غير مطبق")

العرض: تعمل إجراءات ذراع WaveHand و ShakeHand من جهاز التحكم عن بُعد ولكن تفشل من Python/C++/ROS2؛ يُرجع ROS2 الخطأ 3203 "API غير مطبق على الخادم".

متأثر: البرامج الثابتة قبل v1.3.0.

الإصلاح / الحل البديل: قم بتحديث البرامج الثابتة للروبوت إلى v1.3.0 أو أحدث. تأكد أيضًا من تنشيط الروبوت خارج وضع التخميد (L1+A، L1+UP) قبل إصدار الأوامر.

المصادر: github.com/unitreerobotics/unitree_sdk2_python #42

البرامج الثابتة/التحديث يمنع الاستخدام مفتوح / غير محلول

الكود والأمثلة الرسمية تتعطل بعد البرامج الثابتة 1.4.0 ("خطأ في إرسال طلب ClientStub")

العرض: يتوقف كود Python الذي كان يعمل سابقًا والأمثلة الرسمية لـ SDK عن العمل بعد التحديث إلى البرامج الثابتة 1.4.0؛ "[ClientStub] إرسال طلب خطأ" متكرر. ذو صلة: GetVolume يرجع الخطأ 3102، تفشل أمثلة الصوت/عالية المستوى.

متأثر: البرامج الثابتة 1.4.0.

الإصلاح / الحل البديل: لم يتم توثيق إصلاح من المورد. تأكد من تنشيط الروبوت (خارج وضع التخميد)، تحقق من تطابق إصدار SDK مع البرامج الثابتة، وإذا قمت بالترقية خصيصًا لميزة ما، فتعلم أن بعض المستخدمين تراجعوا. راقب ملاحظات إصدار Unitree للحصول على تصحيح متابعة.

المصادر: github.com/unitreerobotics/unitree_sdk2_python #78 github.com/unitreerobotics/unitree_sdk2_python #33

اليد/الماسك يمنع الاستخدام يوجد حل بديل

يد Inspire لا تفتح منفذ التسلسل التسلسلي / لا يمكن الوصول إليها عبر IP الخاص بها

العرض: "فشل فتح منفذ التسلسل التسلسلي /dev/ttyUSB0" — لا يمكن التحكم في يد Inspire؛ أو لا يمكن الوصول إلى يد FTP على 192.168.123.211.

متأثر: G1 مع يد Inspire (متغيرات التسلسل التسلسلي DFX مقابل FTP modbus-TCP).

الإصلاح / الحل البديل: تعتمد طريقة التحكم على متغير اليد. تستخدم أيدي Inspire FTP بروتوكول Modbus TCP، وليس منفذًا تسلسليًا — استخدام كود تسلسلي على يد FTP يفشل بتصميم. تأكد من المتغير الذي لديك واستخدم طريقة التحكم المطابقة؛ تحقق من إمكانية الوصول إلى IP اليد على شبكة 192.168.123.x.

المصادر: github.com/unitreerobotics/xr_teleoperate #51

اليد/الماسك يقلل من الاستخدام مفتوح / غير محلول

إبهام يد Dex3-1 يتحرك بالكاد أثناء التشغيل عن بُعد

العرض: في التشغيل عن بُعد، يقوم الإبهام فقط بحركات دقيقة 3-4 درجات مقابل النطاق الكامل في المحاكاة؛ يصل القرص بين الإبهام والسبابة إلى ~5 سم، وهو خشن جدًا للمناورة الدقيقة.

متأثر: برنامج G1 V1.4.7 + يد Dex3-1.

الإصلاح / الحل البديل: لم يتم توثيق إصلاح. يُظهر فحص الذات عند التشغيل أن المفاصل طبيعية والمحاكاة تعمل، مما يشير إلى عدم تطابق في تعيين الأوامر بين التشغيل عن بُعد وبرنامج تشغيل اليد وليس الأجهزة. قم بالإبلاغ عن إصدار برنامج التشغيل إلى Unitree.

المصادر: github.com/unitreerobotics/xr_teleoperate #229

الشبكة/الاتصال يقلل من الاستخدام مفتوح / غير محلول

تتزايد latency التشغيل عن بُعد إلى ~2.5 ثانية بعد 1-2 ساعة

العرض: ترتفع latency الذراع والكاميرا إلى ~2.5 ثانية بعد التشغيل عن بُعد المطول؛ يستغرق وضع تحضير الذراع ~4 ثوانٍ بدلاً من ~2 ثانية، وفي النهاية يظهر فورًا عند بدء التشغيل.

متأثر: xr_teleoperate v1.3 و v1.5.

الإصلاح / الحل البديل: لم يتم توثيق إصلاح. لم تساعد الترقية إلى موجه جيجابت و WiFi 6، ولم تتأثر وضع المحاكاة — مما يشير إلى مشكلة تراكم/تخزين مؤقت على متن الطائرة بدلاً من الشبكة. أعد تشغيل حزمة التشغيل عن بُعد بين الجلسات الطويلة كحل مؤقت.

المصادر: github.com/unitreerobotics/xr_teleoperate #247

الشبكة/الاتصال يقلل من الاستخدام يوجد حل بديل

نشر السياسة عبر WiFi يتوقف عند "في انتظار الاتصال rt/lowstate"

العرض: يتوقف النشر عبر WiFi عند "في انتظار الاتصال rt/lowstate" على الرغم من أن SSH إلى الروبوت يعمل؛ يعمل الإيثرنت السلكي بشكل طبيعي.

متأثر: G1، تحكم قائم على DDS.

الإصلاح / الحل البديل: استخدم اتصالاً سلكياً وحدد الواجهة، مثلاً ./g1_ctrl --network enx701988512412. لا تنتقل تقنية DDS multicast الخاصة بـ lowstate عبر الواجهة اللاسلكية بشكل موثوق.

المصادر: github.com/unitreerobotics/unitree_rl_lab #93

SDK/البرمجيات يمنع الاستخدام يوجد حل بديل

عدم تطابق إصدار CycloneDDS يتسبب في تعطل تهيئة محاكاة G1

العرض: فشل تأكيد DDS / خطأ كاتب CycloneDDS عند تهيئة محاكاة G1؛ لن تبدأ.

متأثر: Ubuntu 22.04, ROS2 Humble؛ CycloneDDS النظام 0.10.5 مقابل CycloneDDS Python 0.10.2.

الإصلاح / الحل البديل: لا تقم بتنفيذ سكريبت إعداد ROS (مكتبات DDS الخاصة به تختلف عن unitree_sdk2). تحقق من أي .so مرتبط وقت التجميع. البدائل: بناء CycloneDDS 0.10.2 من الكود المصدري، أو تعديل unitree-sdk2py للإصدار 0.10.5، أو التطوير على Ubuntu 20.04.

المصادر: github.com/unitreerobotics/unitree_mujoco #60

SDK/البرمجيات يمنع الاستخدام يوجد حل بديل

'نوع روبوت غير متطابق' عند الاتصال عبر Ethernet (23 مقابل 29 DoF)

العرض: يتحكم الاتصال عبر Ethernet ثم يفشل فوراً مع 'نوع روبوت غير متطابق' أثناء النشر من المحاكاة إلى الواقع.

متأثر: إصدارات G1 بـ 23 DoF و 29 DoF (بما في ذلك تكوينات الخصر المقفل والأيدي الوهمية).

الإصلاح / الحل البديل: يجب أن يتطابق DoF/تكوين الروبوت مع النوع المتوقع بواسطة وحدة التحكم. اضبط DoF الصحيح في التكوين الخاص بك، وتحقق من وجود عمليات تثبيت SDK متعارضة في /usr/local مقابل مسار مشروعك — إعادة بناء unitree_sdk2 بشكل نظيف (بناء النشر مع -DBUILD_EXAMPLES=OFF، بناء المحاكاة مع CMAKE_INSTALL_PREFIX منفصل) يحل حالة وضع السرعة غير المستجيب المرتبطة.

المصادر: github.com/unitreerobotics/unitree_rl_lab #114 github.com/unitreerobotics/unitree_rl_lab #44

SDK/البرمجيات يقلل من الاستخدام مفتوح / غير محلول

تحريك الأذرع عبر SDK أثناء المشي يزعزع التوازن

العرض: التحكم في الأذرع عبر SDK أثناء المشي (ذراع التحكم) يجعل الروبوت ينحني للأمام أو يفقد التوازن؛ رفع الأذرع أثناء المشي ينتج مشياً غير مستقر وثقيل.

متأثر: G1 مع خصر 3 DoF.

الإصلاح / الحل البديل: لا يوجد حل موثق. تم تجربة تعيين محاور الخصر إلى الصفر، والاحتفاظ بالقيم الأولية، وتركها دون لمس دون نجاح — يتعارض متحكم ذراع SDK مع متحكم توازن الحركة. تجنب الحركات الكبيرة للأذرع أثناء الحركة حتى يعالج تحديث البرامج الثابتة هذا.

المصادر: github.com/unitreerobotics/unitree_sdk2_python #146

SDK/البرمجيات يقلل من الاستخدام يوجد حل بديل

ينهار G1 المحاكى بدون استقرار افتراضي

العرض: في محاكاة MuJoCo، لا يحتوي G1 على استقرار افتراضي ويسقط عند التشغيل بدون ضوابط.

متأثر: unitree_mujoco.

الإصلاح / الحل البديل: فعّل الشريط المرن: اضبط enable_elastic_band: 1 في unitree_mujoco/simulate/config.yaml (أو ENABLE_ELASTIC_BAND=True). ملاحظة: متحكم الحركة الافتراضي غير متوفر في المحاكاة، ويمكن أن يكون الشريط صعب الإزالة عند التبديل إلى التحكم بذراع التحكم.

المصادر: github.com/unitreerobotics/unitree_mujoco #57

البطارية/الطاقة إزعاج غير واضح

وقت تشغيل قصير للبطارية (~ساعتان)

العرض: توفر بطارية 9,000 mAh فقط حوالي ساعتين لكل شحنة، وتستنزف أسرع أثناء الحركة الديناميكية.

متأثر: الطراز الأساسي، حزمة 9,000 mAh.

الإصلاح / الحل البديل: هذا قيود في السعة، وليس عطلاً. احتفظ ببطاريات احتياطية مشحونة للتبديل السريع بين الجلسات؛ خطط لوقت تشغيل يبلغ حوالي ~ساعتين من الاستخدام النشط.

المصادر: blog.robozaps.com/b/…

أخرى يمنع الاستخدام غير واضح

لا يمكن برمجة G1 الأساسي — لا يوجد SDK

العرض: يكتشف مشترو G1 الأساسي بسعر ~$13,500 أنه وحدة عرض/عرض توضيحي بدون SDK ولا يمكن برمجته.

متأثر: G1 الأساسي (23 DoF) مقابل G1 EDU (حتى 43 DoF).

الإصلاح / الحل البديل: هذا قيود في فئة المنتج. يتطلب الوصول إلى SDK وعزم دوران أعلى وDoF أكثر الحصول على G1 EDU / منصة المطور (~$44k-$74k). تأكد من الفئة قبل الشراء إذا كنت تنوي التطوير.

المصادر: blog.robozaps.com/b/…

ميكانيكية/هيكلية يمنع الاستخدام يوجد حل بديل

مؤشر LED أحمر ثابت / قائمة فحص الأعطال المادية (السقوط، الكابلات، البطارية)

العرض: مؤشر LED أحمر ثابت يشير إلى خطأ في البرنامج/الأجهزة؛ بالإضافة إلى أعطال ميدانية — الشقوق/الخدوش من السقوط، تدهور المستشعرات من الغبار أو سوء المحاذاة، المكونات غير المستجيبة من الكابلات السائبة/الممتزقة، انتفاخ البطارية أو التشوه.

متأثر: عام.

الإصلاح / الحل البديل: افحص بصرياً بحثاً عن أضرار الصدمات؛ نظف المستشعرات وأكد التثبيت؛ أعد توصيل الكابلات والموصلات؛ تحقق من تركيب البطارية واستبدلها إذا كانت منتفخة أو تتسرب. عند ظهور مؤشر LED الأحمر الثابت، قم بتشغيل تشخيصات تطبيق الهاتف المحمول وسجل فيديو لأي عطل متقطع قبل الاتصال بالدعم. ملاحظة: فتح الهيكل يلغي الضمان.

المصادر: docs.westonrobot.com/tutorial/…

الأمان/الخصوصية يمنع الاستخدام مفتوح / غير محلول

أمان حرج: حقن أوامر BLE بمفاتيح مشفرة ثابتة (UniPwn)

العرض: ثغرة حقن أوامر في BLE Wi-Fi provisioning، تستخدم مفاتيح AES مشفرة ثابتة مشتركة عبر جميع الوحدات، تسمح بالوصول الجذر ويكون قابلاً للانتشار. وجدت بحث منفصل أن بيانات القياس عن بعد تنتقل إلى خوادم خارجية كل ~5 دقائق.

متأثر: G1 (يشير الباحثون إلى أن Go2/H1 تشترك في مسارات الكود). تم إصدار استغلال 'UniPwn' العام.

الإصلاح / الحل البديل: لا يوجد تأكيد على وجود تصحيح من البائع موثق في وقت الكتابة. قلّل المخاطر على مستوى الشبكة: عزل الروبوت على شبكة مقسمة/محمية بجدار حماية، تقييد الوصول إلى واجهته الداخلية (192.168.123.0/24)، وحظر حركة المرور الصادرة غير المتوقعة. راقب إعلان البرامج الثابتة من Unitree.

المصادر: arXiv:2509.14139 spectrum.ieee.org/unitree-robot-exploit/… helpnetsecurity.com/2025/…

أخرى إزعاج غير واضح

مهارات العرض الفيروسية مُؤلفة، وليست مستقلة

العرض: مقاطع الكونغ فو والقرفصاء الخلفي هي عروض مدربة؛ لا يملك الروبوت أي استقلالية منزلية جاهزة ولا يفشل في المهام البسيطة مثل فتح الباب.

متأثر: عام.

الإصلاح / الحل البديل: إدارة التوقعات، وليست عطلاً. يتطلب أداء المهام المستقلة تطويراً كبيراً على منصة EDU؛ التجربة الأساسية هي حركات عن بُعد/مبرمجة مسبقاً.

المصادر: blog.robozaps.com/b/…

SDK/البرمجيات يمنع الاستخدام تم الإصلاح من قبل المورد

روبوت G1 بـ 23-DoF يتحرك بشكل متقطع في MuJoCo Sim2Sim

العرض: عند تشغيل Sim2Sim في MuJoCo مع سياسة مدربة في Isaac Lab لتكوين G1 بـ 23-DoF، يفشل الروبوت في المشي بشكل صحيح ويتحرك بشكل متقطع. السبب المشتبه به المبلغ عنه في الموضوع هو أن معرفات المحركات لم يتم تكييفها لإصدار 23-DoF.

الإصلاح / الحل البديل: أضاف المورد (Agnel-Wang) كود النشر لـ 23-DoF إلى المستودع؛ أكد المبلغ أن Sim2Real نجح بعد استخدام الكود المحدث.

المصادر: github.com/unitreerobotics/unitree_rl_lab #27

الشبكة/الاتصال يمنع الاستخدام مفتوح / غير محلول

يطبع G1_29_ArmController بشكل متكرر 'Waiting to subscribe dds' ويبلغ تطبيق الروبوت عن خطأ اتصال البرامج الثابتة

العرض: عند تشغيل برنامج التحكم عن بُعد، تتكرر حلقة التحكمر بلا نهاية بطباعة '[G1_29_ArmController] Waiting to subscribe dds...' ويبلغ التطبيق المحمول عن '底层固件通信故障' (خطأ اتصال البرامج الثابتة منخفضة المستوى). لم يتم إنشاء اتصال DDS بين الجهاز المضيف والروبوت رغم وجود الأجهزة على نفس الشبكة.

الإصلاح / الحل البديل: يقترح المشرف التحقق من اتصال الشبكة باستخدام 'cyclonedds ps' و'cyclonedds subscribe rt/lowstate'؛ إذا لم يتم الحل، قدم تذكرة دعم. أبلغ أحد المعلقين أن الأمثلة منخفضة المستوى عملت لكن أمثلة الذراع عالية المستوى لم تنتج أي حركة من الروبوت وأرسلت أخطاء طلب.

المصادر: github.com/unitreerobotics/xr_teleoperate #57

الشبكة/الاتصال يمنع الاستخدام مفتوح / غير محلول

يفصل WebSocket من Apple Vision Pro فوراً عند كل تحميل للصفحة في إعداد التحكم عن بُعد

العرض: عند الوصول إلى خادم التحكم عن بُعد من Safari على Apple Vision Pro، يتصل WebSocket لكنه يفصل فوراً عند كل تحميل للصفحة، مما ينتج عنه 'AssertionError: Websocket session is missing.' على الخادم. يؤدي تحديث الصفحة إلى تكرار دورة الاتصال/الفصل؛ الحلول المؤقتة الوحيدة هي إزالة سماعة AVP أو إغلاق Safari بالكامل وانتظار بضع ثوانٍ.

متأثر: vuer 0.0.60، televuer 4.0.0، xr_teleoperate commit 9fadc51، visionOS الأحدث

الإصلاح / الحل البديل: تم تحقيق اتصال مستقر مؤقتاً بفك سماعة AVP أو إغلاق Safari تماماً لبضع ثوانٍ. اقترح المشرف تجربة 'https://vuer.ai/?ws=wss://host ip:8012' لكن لم يتم توفير إصلاح مؤكد.

المصادر: github.com/unitreerobotics/xr_teleoperate #271

SDK/البرمجيات يمنع الاستخدام مفتوح / غير محلول

سياسة WBC تبث القيم لكن G1 الحقيقي لا يتحرك بعد معايرة اليد

العرض: عبر برنامج تشغيل GR00T-WholeBodyControl المجتمعي: بعد دخول الروبوت في وضع التصحيح ومعايرة الأيدي بنجاح، لا يتحرك G1 على الإطلاق رغم إظهار الطرف أن السياسة تبث القيم إلى الروبوت. لا يتم الإبلاغ عن أي أخطاء ويعمل المحاكاة الموازية بشكل صحيح.

الإصلاح / الحل البديل: لا يوجد إصلاح مؤكد

المصادر: github.com/NVlabs/GR00T-WholeBodyControl #21

SDK/البرمجيات يقلل من الاستخدام مفتوح / غير محلول

يتجمد تغذية صورة Vuer على Quest 3 على الإطار الأول أثناء التحكم عن بُعد بالروبوت الحقيقي

العرض: عند تشغيل خط أنابيب التحكم عن بُعد مع سماعة Quest 3، يُظهر عرض Vuer فقط الإطار الأول الملتقطة ثم يتجمد، بينما يؤكد عميل الصورة على جهاز الكمبيوتر أن تغذية الكاميرا الحية تعمل بشكل صحيح. تم إعادة إنتاج المشكلة في الفرع الرئيسي ومع فرع teleimager.

متأثر: vuer 0.0.67، xr_teleoperate (وضع المتحكم، G1_29)

الإصلاح / الحل البديل: اقترح المشرف التبديل إلى فرع teleimager (بث WebRTC)؛ طبق المبلغ الفرع لكنه أشار إلى أنه لا يدعم النشر في المحاكاة. لا يوجد إصلاح مؤكد تماماً لمشكلة الإطار المجمد.

المصادر: github.com/unitreerobotics/xr_teleoperate #172

الشبكة/الاتصال يمنع الاستخدام مفتوح / غير محلول

تصبح صفحة التحكم عن بُعد سوداء ويفصل WebSocket عند الدخول في وضع VR على Apple Vision Pro

العرض: بعد أن يعرض Vision Pro بنجاح تغذية الكاميرا المجسمة، يؤدي النقر على 'الواقع الافتراضي' ومنح إذن تتبع اليد إلى تحول الشاشة إلى اللون الأسود و فصل WebSocket فوراً، مما يثير 'AssertionError: Websocket session is missing.' نشأ تتبع الخطأ من vuer/server.py.

الإصلاح / الحل البديل: اقترح المشرف استخدام Wi-Fi 5 جيجاهرتز فقط، ومراقبة زمن انتقال ping إلى AVP (يجب أن يكون أقل من 50 مللي ثانية)، والاختبار باستخدام سكريبت televuer مباشرة، وتجربة إصدار vuer 0.0.32rc7. لم يتم الإبلاغ عن أي إصلاح مؤكد.

المصادر: github.com/unitreerobotics/xr_teleoperate #115

SDK/البرمجيات يمنع الاستخدام يوجد حل بديل

لا يمشي G1 عند إصدار أمر الحركة عبر متحكم التحكم عن بُعد؛ يتم تجاهل إدخال عصا التحكم

العرض: عند استخدام وضع المتحكم لسكريبت التحكم عن بُعد مع العلم --motion، يعمل تحكم الذراع بشكل صحيح لكن الروبوت لا يستجيب لأوامر عصا التحكم للمشي. حتى بعد الخروج من البرنامج، لا يمكن للتحكم عن بُعد الفعلي أيضاً جعل الروبوت يمشي، رغم أن إيماءات الذراع تستمر في العمل بشكل طبيعي.

متأثر: إصدار ai_sport غير محدد؛ xr_teleoperate، G1_29

الإصلاح / الحل البديل: حدد المشرف أن اسم خدمة حركة ai_sport تغير في الإصدار 8.2.0.0 (يجب أن يكون LOCO_SERVICE_NAME هو 'sport' للإصدار >=8.2.0.0، و'loco' للإصدارات السابقة). كما نصح بتحديد اسم واجهة الشبكة الصحيحة في الكود إذا كان التشغيل على جهاز متعدد NIC. أكد المشرف أن الحركة عملت على روبوتهم مع الإصدار 8.4.0.0 بعد تحديث git pull.

المصادر: github.com/unitreerobotics/xr_teleoperate #77

Show all 38 issues

SDK/البرمجيات يمنع الاستخدام مفتوح / غير محلول

لا تتحرك مفاصل G1 بعد بدء برنامج التحكم عن بُعد وضغط 'r'

العرض: يبدأ برنامج التحكم عن بُعد بدون أخطاء، يبدو أن DDS متصل، ويعرض AVP تغذية الكاميرا الحية مع تتبع الذراع، لكن روبوت G1 لا يتحرك عند تشغيل البرنامج وبعد الضغط على 'r' للبدء. إخراج موضع المفصل غائب عن السجل، على عكس السلوك المتوقع. تم الإبلاغ عن أن الدخول في وضع التصحيح من البرنامج غير متسق.

متأثر: G1 بـ 29-DoF مع يدي Inspire dftp، AVP

الإصلاح / الحل البديل: لا يوجد إصلاح مؤكد

المصادر: github.com/unitreerobotics/xr_teleoperate #189

SDK/البرمجيات يمنع الاستخدام مفتوح / غير محلول

تُظهر سماعة VR شبكة زرقاء فقط، الروبوت غير مرئي في محاكاة XR للتحكم عن بُعد

العرض: عند تشغيل التحكم عن بُعد XR في المحاكاة مع Meta Quest 3، يدخل المستخدم بنجاح في وضع VR لكنه يرى شبكات زرقاء فقط بدلاً من الروبوت. يُظهر طرف المحاكاة أيضاً '[DDSManager] object g1 not found' و'g1_robot_dds is not initialized'.

متأثر: unitree_sim_isaaclab مع مهمة Isaac-PickPlace-Cylinder-G129-Dex3-Joint؛ xr_teleoperate teleop_hand_and_arm.py؛ Meta Quest 3

الإصلاح / الحل البديل: لا يوجد إصلاح مؤكد

المصادر: github.com/unitreerobotics/xr_teleoperate #112

SDK/البرمجيات يمنع الاستخدام يوجد حل بديل

سياسة sim2sim الخاصة بـ G1 تؤدي إلى انحراف الروبوت إلى اليسار ورجفة الذراعين بشكل لا يمكن السيطرة عليه في MuJoCo

العرض: عند نشر سياسة RL المدربة (أو سياسة v0 المتوفرة) من unitree_rl_lab في MuJoCo عبر simulate_python، ينحرف روبوت G1 نحو الجانب الأيسر، ويُرجّ يديه بتردد عالٍ وسعة منخفضة، ويصبح التحكم فيه تقريبًا مستحيلًا عبر عصا التحكم. كما يعاني الروبوت من الارتجاف فورًا بعد الضغط على تسلسل أزرار تفعيل الحركة.

متأثر: unitree_rl_lab (الأحدث); Isaac Sim + Isaac Lab; unitree_mujoco مع G1 29dof; simulate_python (وليس simulate مع C++)

الإصلاح / الحل البديل: اقتراح من المجتمع: زيادة قيمة الكابح (armature) في الذراع والمعصم في ملف MuJoCo g1_29dof.xml لتقليل اهتزاز الذراع. لا يوجد حل مؤكد لمشكلة الانحراف/عدم الاستقرار العام.

المصادر: github.com/unitreerobotics/unitree_rl_lab #31

SDK/البرمجيات يمنع الاستخدام يوجد حل بديل

خطأ وقت التشغيل 'فهرس القائمة خارج النطاق' في unitree_mujoco عند تشغيل G1 بتكوين اليد

العرض: تشغيل unitree_mujoco.py للروبوت G1 (أو H1 مع أيادي Inspire) يُنتج '[RecurrentThread] target func raise exception: name=IndexError, args=("list index out of range",)' أثناء التشغيل. يحدث هذا الخطأ عند محاولة محاكاة الروبوت مع ملحقات اليد.

متأثر: unitree_mujoco; G1 مع يد (scene_29dof_with_hand.xml); H1 مع يد Inspire

الإصلاح / الحل البديل: الحل البديل من المجتمع: استخدم scene_29dof.xml بدلاً من scene_29dof_with_hand.xml. بشكل منفصل، تأكد من أن اسم ROBOT في config.py هو بالضبط أحد الأسماء المدعومة (مثل 'g1') وليس متغيراً مثل 'g1_23dof'.

المصادر: github.com/unitreerobotics/unitree_mujoco #52

SDK/البرمجيات يمنع الاستخدام مفتوح / غير محلول

أوامر SDK عالية المستوى تُرجع 'send request error' على G1; أوامر low-level تعمل بشكل صحيح

العرض: عند تشغيل أوامر SDK عالية المستوى (مثل g1_loco_client_example.py)، يطبع العميل '[ClientStub] send request error. id: <id>' ولا يتم تنفيذ الأمر. سكريبتات low-level (g1_low_level_example.py) تعمل بشكل صحيح

متأثر: unitree_sdk2_python; G1 robot; g1_loco_client_example.py أوامر عالية المستوى

الإصلاح / الحل البديل: لا يوجد إصلاح مؤكد

المصادر: github.com/unitreerobotics/unitree_sdk2_python #54

SDK/البرمجيات يمنع الاستخدام يوجد حل بديل

تنقطع WebSocket فوراً عند الدخول في وضع VR على Meta Quest 3 مع إدخال تتبع اليدين

العرض: عند استخدام xr_teleoperate مع Meta Quest 3، ينقطع اتصال WebSocket بصفحة Vuer على المنفذ 8012 فوراً عند النقر على زر الواقع الافتراضي، مع طباعة 'websocket is now disconnected' و 'AssertionError: Websocket session is missing.' تكون المشكلة محددة لوضع إدخال تتبع اليد؛ حيث يؤدي التبديل إلى وضع إدخال وحدة التحكم إلى الحفاظ على الاتصال نشطاً.

متأثر: xr_teleoperate v1.5; vuer 0.0.60; aiohttp 3.10.5; المتصفح المدمج في Meta Quest 3; المضيف Ubuntu; Isaac Sim 5.1 + unitree_sim_isaaclab; G1_29 + Inspire

الإصلاح / الحل البديل: حل مجتمعي: تخفيض xr_teleoperate إلى الإصدار v1.0 يعمل على حل مشكلة الانقطاع. أو يمكن التبديل إلى --input-mode=controller للحفاظ على اتصال WebSocket. استخدام متصفح Wolvic بدلاً من متصفح Meta Quest الافتراضي يمنع أيضاً انقطاع WebSocket، على الرغم من أن مشاكل بث الكاميرا لا تزال قائمة.

المصادر: github.com/unitreerobotics/xr_teleoperate #296

SDK/البرمجيات يمنع الاستخدام مفتوح / غير محلول

صفحة VR للتحكم عن بُعد غير قابلة للوصول عبر IP المحلي؛ انقطاع WebSocket عند الدخول في وضع VR

العرض: عند الوصول إلى واجهة التحكم عن بُعد عبر عنوان IP المحلي (https://<host-ip>:8012?ws=wss://<host-ip>:8012)، تفشل الصفحة في التحميل أو تعرض شاشة سوداء. عند الدخول في وضع الواقع الافتراضي/الواقع المختلط (وضع WebXR)، ينقطع اتصال WebSocket ويتوقف الروبوت عن استقبال بيانات التتبع، مع ظهور رسالة من الخادم "جلسة Websocket مفقودة" وخطأ عرضي في aiohttp 'resume_writing() AssertionError'.

متأثر: vuer 0.0.60، televuer 4.0.0؛ العَتاد: Unitree G1 29-DoF EDU مع Inspire RH56DFTP، Meta Quest 3 و Apple Vision Pro (visionOS 26.4)

الإصلاح / الحل البديل: يقترح المشرف التحقق من تضمين عنوان IP للمضيف في حقل SAN للشهادة، واستخدام التصفح المتخفي/الخاص، وتجرية مجموعات vuer/televuer المثبتة بالإصدار. حدّد مساهم مجتمع أن RTCPeerConnection.createOffer() في متصفح Quest لا يتم حلها أبداً واقترح تدفق WebRTC المبدوء من الخادم كحل بديل، لكن هذا لم يتم دمجه رسمياً في المنبع. لا يوجد إصلاح مؤكد من المورّد.

المصادر: github.com/unitreerobotics/xr_teleoperate #297

SDK/البرمجيات يمنع الاستخدام يوجد حل بديل

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

العرض: عند تشغيل teleop_hand_and_arm.py مع تفعيل اليد الخبيرة Inspire FTP (--ee=inspire_ftp)، يرفع الروبوت كلا الذراعين قليلاً ثم ينهي البرنامج تلقائياً، مما يؤدي إلى سقوط الذراعين. يُظهر السجل أن عميل الصور يغلق بشكل غير متوقع وينتهي البرنامج دون رسالة خطأ واضحة.

متأثر: xr_teleoperate; الأجهزة: Unitree G1 29-DoF مع Inspire FTP أيدي ماهرة

الإصلاح / الحل البديل: تم تأكيد الحل البديل بواسطة المستخدم: تشغيل بدون العلم --ee=inspire_ftp (أي بدون تفعيل أيادي FTP الماهرة) لتشغيل الأذرع فقط. أوضح المشرف أن جميع كود نهاية التأثير مكتوب لزوج يمين ويسار، لذا فإن اليد المعيبة الواحدة قد تعطّل الأمور. قام المستخدم بتطبيق رقعة على فئة Inspire_Controller_FTP لمعالجة تشغيل اليد الواحدة. كما اقترح المشرف تجربة أحدث إصدار من الكود.

المصادر: github.com/unitreerobotics/xr_teleoperate #194

اليد/الماسك يمنع الاستخدام تم الإصلاح من قبل المورد

كلتا اليدين ماهرتين Inspire تعكسان فقط حركة اليد اليمنى بسبب سوء تكوين المنفذ التسلسلي

العرض: أثناء التشغيل عن بُعد بأيدٍ ماهرة من Inspire، تتبع كلتا اليدين حركة اليد اليمنى فقط. تم تحديد السبب الجذري في المناقشة على أنه إرسال أوامر كلتا اليدين إلى نفس المنفذ التسلسلي

متأثر: Unitree G1 مع أيدٍ ماهرة من Inspire DFX / RH56DFTP; كود المثال inspire_ctrl.cpp من حزمة أمثلة المورّد

الإصلاح / الحل البديل: الإصلاح الذي حددته المجتمع تم تأكيده من المشرف: تعديل inspire_ctrl.cpp لتهيئة منفذين تسلسليين منفصلين (serial1 = /dev/ttyUSB1, serial2 = /dev/ttyUSB2) وربط كل يد بالمنفذ والمعرّف الخاص بها. المورّد قدّم كود inspire_ctrl.cpp المصحح في التعليقات

المصادر: github.com/unitreerobotics/xr_teleoperate #46

SDK/البرمجيات يمنع الاستخدام يوجد حل بديل

محاكي unitree_mujoco يتعطل مع ظهور 'free(): invalid pointer' / 'Aborted (core dumped)' أثناء التشغيل

العرض: بعد تشغيل الملف التنفيذي لمحاكي unitree_mujoco، يبدأ البرنامج ('تم تجهيز بيانات MuJoCo') ثم يتعطل فوراً مع 'free(): invalid pointer' و 'Aborted (core dumped)'. كانت هناك نسخة سابقة من الخطأ هي 'Joystick open failed'. يبلّغ مستخدمون متعددون عن هذه المشكلة عبر إصدارات MuJoCo 3.2.7 و 3.3.1.

متأثر: unitree_mujoco; MuJoCo 3.2.7 و 3.3.1; Ubuntu 22.04 و Ubuntu 24.04 مع ROS2 Jazzy

الإصلاح / الحل البديل: أرجع مستخدم من المجتمع انهيار النظام على Ubuntu 24.04 / ROS2 Jazzy إلى تعارض في مسار مكتبة DDS (تحميل مكتبات DDS الخاصة بـ ROS2 Jazzy ومكتبات DDS المثبتة من unitree_sdk2 في وقت واحد). أدى حل تعارض المسار إلى إصلاح الانهيار لهذا المستخدم. تم إصلاح خطأ عصا التحكم في commit محدد (2f5459d). لا يوجد إصلاح واحد مؤكد لجميع المتغيرات المبلغ عنها.

المصادر: github.com/unitreerobotics/unitree_mujoco #51

البطارية/الطاقة يمنع الاستخدام مفتوح / غير محلول

يتجاوز G1 حدود الحرارة ويتوقف بعد بضع دقائق من تشغيل سياسة sonic_release، مما يسبب السقوط

العرض: عبر برنامج تشغيل GR00T-WholeBodyControl من المجتمع: عند نشر سياسة sonic_release على روبوت G1 حقيقي بـ 29-DoF ومجهز بيدين Dex3، يُصدر الروبوت تحذيراً من ارتفاع الحرارة بعد بضع دقائق حتى أثناء الوقوف بلا حراك، ثم يتوقف Sonic تلقائياً، مما يسبب سقوط الروبوت عدة مرات.

متأثر: Unitree G1 29-DoF EDU مع Dex3 hands; نقطة تحقق GR00T-WholeBodyControl sonic_release

الإصلاح / الحل البديل: لا يوجد إصلاح مؤكد

المصادر: github.com/NVlabs/GR00T-WholeBodyControl #121

SDK/البرمجيات يمنع الاستخدام مفتوح / غير محلول

تنقطع جلسة WebSocket ويتحول العرض في الواقع الافتراضي إلى اللون الأسود عند الدخول في وضع Virtual Reality على Quest 3

العرض: بعد الاتصال بنجاح بـ Quest 3 بصفحة التحكم عن بُعد (تحميل واجهة vuer لكن تظهر شاشة سوداء)، يؤدي النقر على 'Virtual Reality' إلى قطع جلسة WebSocket. يُظهر الطرف أن الاتصال انقطع. أرجع مساهم من المجتمع هذا إلى خطأ في متصفح Meta Quest 3 حيث لا يحل RTCPeerConnection.createOffer() أبداً Promise، مما يكسر تدفق WebRTC الافتراضي الذي يبدأه العميل.

متأثر: xr_teleoperate; hardware: G1-EDU 29-DoF with Dex3-1, Meta Quest 3

الإصلاح / الحل البديل: اقترح مساهم من المجتمع عكس مفاوضات WebRTC لتصبح تدفقاً يبدأه الخادم (الخادم ينشئ العرض، المتصفح يستدعي createAnswer()) كحل مؤقت. لا يوجد إصلاح مؤكد من المنبع.

المصادر: github.com/unitreerobotics/xr_teleoperate #267

الشبكة/الاتصال يمنع الاستخدام يوجد حل بديل

يفشل اتصال DDS عند اتصال جهاز الاستضافة بـ G1 عبر Wi-Fi بدلاً من Ethernet

العرض: يعمل التحكم عن بُعد بشكل صحيح عند توصيل الكمبيوتر المحمول بالروبوت عبر كابل Ethernet، لكنه يفشل مع أخطاء DDS عند محاولة التشغيل لاسلكياً عبر Wi-Fi. بالإضافة إلى ذلك، عند تشغيل كل شيء على PC2 الخاص بالروبوت (Jetson)، تظهر مشاكل في الاتصال بعد حوالي 10 دقائق.

متأثر: xr_teleoperate; hardware: Unitree G1 EDU with Inspire FTP hands and Apple Vision Pro

الإصلاح / الحل البديل: يقترح المشرف استخدام وكيل إعادة توجيه DDS في طبقة التطبيق، أو تركيب راوتر على ظهر G1 (subnet 192.168.123.*/24) يعمل من واجهة طاقة G1. لا يوجد إصلاح كامل واحد مؤكد.

المصادر: github.com/unitreerobotics/xr_teleoperate #234

هل تحتاج مساعدة احترافية مع Unitree G1 الخاص بك؟

انضم إلى قائمة انتظار الإصلاح وسنربطك مع الفنيين المعتمدين وشركاء الخدمة.

انضم إلى قائمة انتظار الإصلاح ←