unitree-loco-bug-report.tar.gz
Summary
On a Unitree G1 EDU+ running software 1.5.3, high-level SDK locomotion does not work: LocoClient.SetVelocity / SetFsmId return success (code 0) but the robot does not act on them, and the SDK cannot acquire the control lease. The R3 hardware remote walks the robot fine in the same mode. Upper-body arm teleoperation over the SDK (rt/arm_sdk) works normally. This blocks VR/Quest thumbstick locomotion in xr_teleoperate --motion.
Environment
| Item |
Value |
| Robot |
Unitree G1 EDU+, 29-DoF |
| Robot software version |
1.5.3 |
| Loco service / FSM (in R2+A) |
service sport, GetFsmId = 802 |
| Loco API version |
client 1.0.0.0 == server 1.0.0.0 (match) |
| SDK |
unitree_sdk2_python latest (commit 37116c5, 2026-07-02) |
| App |
xr_teleoperate v1.5 |
| Host |
Ubuntu 22.04 x86_64 |
| Link to robot |
wired NIC 192.168.123.222 → G1 192.168.123.161 / .164 |
What works vs what doesn't
- ✅ DDS to robot (rt/lowstate subscribed), arm teleop via rt/arm_sdk (weight-blend), R3 remote walking.
- ✅ SDK loco queries (GetFsmId returns code 0, value 802).
- ❌ SDK loco control: SetFsmId(500) and SetVelocity(...) return code 0 but have no effect.
- ❌ SDK lease acquisition on sport_lease fails with code 3102 (RPC_ERR_CLIENT_SEND).
Reproduction / evidence
Robot standing, entered motion mode via R2+A (note: R1+X is rejected on 1.5.3 — only R2+A is reachable), on a gantry. Using unitree_sdk2_python (latest) over the wired interface. Full console output in probe_outputs.txt. Key lines:
GetApiVersion: 1.0.0.0
GetServerApiVersion: (0, '1.0.0.0')
[before] GetFsmId -> code=0 fsm_id=802
SetFsmId(500) -> code = 0
[after] GetFsmId -> code=0 fsm_id=802 # FSM unchanged
SetVelocity -> code = 0 # robot does not step
# with LocoClient(enableLease=True):
[LeaseClient] lease name: sport_lease ...
[LeaseClient] apply lease error. code: 3102 # RPC_ERR_CLIENT_SEND, repeats
Unitree's own example/g1/high_level/g1_loco_client_example.py also cannot walk the robot on this firmware.
Everything ruled out (software side is exhausted)
- Loco service name (loco vs sport) — tried both; sport reaches the service (code 0).
- Mode — R2+A reached; R1+X rejected on 1.5.3.
- SDK version — updated to latest upstream.
- FSM state — SetFsmId(500) (the current SDK's Start() target) accepted but ignored.
- API version — client and server match at 1.0.0.0.
- Control lease — enabling it fails to send (3102).
Questions for Unitree
- On software 1.5.3, how does an external SDK client obtain control authority to issue high-level velocity / FSM commands (SetVelocity, SetFsmId)? A lease, a mode/FSM handoff, or a firmware version change?
- Why does SetFsmId(500) / SetVelocity return code 0 while having no effect, and why does sport_lease apply fail with 3102 (client send) — is the lease service expected to be reachable in FSM 802?
- On firmware ~1.4.x, R1+X "Regular mode" reportedly enabled SDK loco (xr_teleoperate issue #235). On 1.5.3, R1+X is rejected — what replaces it for SDK-driven locomotion?
Attached
- probe_outputs.txt — recorded outputs of the two probes
- fsm_probe.py, lease_probe.py — the read-only diagnostic scripts used
- system-info.txt — robot/host/SDK/network details + RPC error-code reference
Reactions are currently unavailable
unitree-loco-bug-report.tar.gz
Summary
On a Unitree G1 EDU+ running software 1.5.3, high-level SDK locomotion does not work: LocoClient.SetVelocity / SetFsmId return success (code 0) but the robot does not act on them, and the SDK cannot acquire the control lease. The R3 hardware remote walks the robot fine in the same mode. Upper-body arm teleoperation over the SDK (rt/arm_sdk) works normally. This blocks VR/Quest thumbstick locomotion in xr_teleoperate --motion.
Environment
What works vs what doesn't
Reproduction / evidence
Robot standing, entered motion mode via R2+A (note: R1+X is rejected on 1.5.3 — only R2+A is reachable), on a gantry. Using unitree_sdk2_python (latest) over the wired interface. Full console output in probe_outputs.txt. Key lines:
Unitree's own example/g1/high_level/g1_loco_client_example.py also cannot walk the robot on this firmware.
Everything ruled out (software side is exhausted)
Questions for Unitree
Attached