G1 EDU+ (sw 1.5.3): SDK high-level locomotion accepted but not executed; `sport_lease` unreachable

[Nbot07]

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

1. 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?
2. 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?
3. 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