R1: what blocks motion mode? SetVelocity returns 127 in all states on ai_sport 1.0.2.154

[JacoBezuidenhout]

Hello, and thanks for the work on this repo.

I am developing on an R1 EDU and I cannot get LocoClient::SetVelocity to be accepted at all. I noticed commit bc55c3f, "[fix] Prevent motion mode for R1_A5 and R1_A7 arm configurations", which adds:

if args.arm in ("R1_A5", "R1_A7") and args.motion:
    parser.error(f"{args.arm} does not support motion mode (--motion).")

The motion_mode implementation is still present in R1_A5_ArmController, so this reads as a deliberate hold rather than a removal. That matches what I see on the robot, so my main question is simply:

Is SDK driven locomotion on R1 currently disabled in firmware, and is it planned to be enabled? If there is a precondition I am missing, I would be very glad to be told what it is.

Observations

R1 EDU, ai_sport 1.0.2.154, service sport, api version 1.0.0.0, DDS on eth10, domain 0.

Working:

• 7001 GetFsmId returns 0 and reports correct states (0, 1, 4, 811, 816).
• 7101 SetFsmId works. Real transitions return 0. I drove 811 to 4 to 811 to 1 to 0 successfully. It returns 1001 when already in the requested state, and 1003 for an invalid id such as 9999.

Not implemented on this build:

• 7002 GetFsmMode returns 3203.
• 7107 SetSpeedMode returns 3203.

The problem:

• 7105 SetVelocity always returns 127. It never varies.

127 is not in r1_loco_error.hpp (7301 to 7304) nor in internal_error.hpp (3001 to 3107, 3201 to 3207), so I assume it is an ai_sport application level code.

Ruled out by measurement

• Payload shape. {"velocity":[vx,vy,omega],"duration":d} returns 127, while any malformed variant returns 3202, so the JSON parses correctly.
• Parameter values. 0 m/s, 0.1 m/s and 99 m/s all return 127. Durations of 0, 1, -1 and 864000 all return 127. It appears not to validate parameters at all.
• Robot state. 127 in FSM 0, 1, 811 and 816, and while hanging, while on a stand, and while free standing and balancing unaided on its own feet.
• Client code. Reproduced with a byte for byte copy of example/r1/high_level/r1_loco_client_example.cpp, including its Init() then SetTimeout() ordering.
• Api version. Same result at 1.0.0.0 and 1.0.0.14.
• Service name. sport answers. loco and ai_sport return 3104.
• Lease. There is no sport_lease service.
• The physical remote holding authority. Same 127 with the remote powered on and powered off.
• Service state. Restarting ai_sport via robot_state ServiceSwitch did not change it, and stopping r1_arm_example did not change it either.
• motion_switcher reports {"form":"0","name":"ai"} and {"silent":false}.

Two smaller questions

1. Publishing to rt/arm_sdk transitions the FSM from 811 to 816, and in 816 the robot will not walk from the physical remote either. Stopping r1_arm_example does not prevent this, so I assume 816 is enforced by ai_sport. Is 816 documented anywhere, and is arm overlay together with locomotion intended to be possible on R1 at all?

2. Is there an FSM id between Stance (4) and Start (811) that is required before velocity is accepted? I have seen an undocumented id 200 mentioned in an issue on unitree_sdk2_python but cannot find it in any published source.

Thanks very much.