Unitree eng: is a whole-body rt/lowcmd motion policy supported on the 23-DOF G1 EDU?

[armwaheed]

Question for Unitree engineering: is a whole-body motion policy achievable on the 23-DOF G1 EDU?

While deploying a sim-trained reach policy on our 23-DOF G1 EDU (Type F, 1-DOF waist), we hit a wall
on running a custom whole-body (CoM-shifting / squatting) motion policy via rt/lowcmd, and want to
confirm with Unitree whether it is supported on this variant at all.

What we found (verified live + against the SDK source and the developer forums)

• MotionSwitcher.CheckMode() reports the configured mode, not the active controller. It returns
  {'name':'ai','form':'0'} in both normal AI-Sport mode and a freshly-entered low-level Develop
  mode (confirmed across a full power-cycle). rt/sportmodestate is not published on this variant.
  So neither indicates whether the balancer thread is actually running.
• The only reliable software signal we found is high-level service liveness: a read-only loco
  GET_FSM_ID RPC (id 7001) answers (code 0) in AI-Sport and errors/times out in Develop
  (Develop → code 3102).
• rt/lowcmd driving all joints against the live AI controller jitters/oscillates rather than
  cleanly taking over (consistent with unitree_sdk2_python#43/#108). Our working path for arm tasks
  is the rt/arm_sdk overlay (it blends with the balancer) + LocoClient.Move for locomotion.

The questions

1. On the 23-DOF G1 EDU, is there a supported way to run a custom whole-body rt/lowcmd policy
   that drives the legs (squat / CoM shift), with the factory AI controller fully released so it does
   not fight the commands? If so, what is the exact, supported sequence?
2. Does handheld Develop mode (L2+R2) fully release the legs for rt/lowcmd, or does the AI/balance
   policy keep running? (We observe the robot is damped in Develop mode, suggesting the AI policy is
   off — but CheckMode still says 'ai'.)
3. Is there an SDK call that authoritatively reports whether the high-level balance service is running
   vs released (beyond the loco-RPC liveness probe we are using)?
4. Is whole-body rt/lowcmd intended/recommended on the 23-DOF EDU at all, or is this variant meant
   for rt/arm_sdk-over-balancer + LocoClient only (with whole-body reserved for the 29-DOF G1)?

Any guidance on (1) and (4) directly determines whether our bed-making demo on the 23-DOF EDU can use a
whole-body reach or must stay upper-body-only.

[armwaheed]

Context. Unitree G1 EDU, 23-DOF (12 legs + waist_yaw + 10 arms; no waist roll/pitch, no wrist pitch/yaw), Brainco hands. We're evaluating a custom whole-body RL policy driven over rt/lowcmd in low-level Develop mode (operator: suspend → L2+B → L2+R2), on a slack gantry. (Full write-up: #3 §10.5.)

What works. A scripted, gain-ramped move to a default stance (damping-first kp ramp) under rt/lowcmd holds a commanded whole-body stance cleanly — feet bearing load, no instability, repeatable across runs.

Where it breaks. Engaging the custom balancing policy, it holds for ~300 ms then diverges into a limit-cycle oscillation (feet "kicking"). Our feet were under-loaded on the gantry at that point (off-distribution), so this is partly expected — but it surfaces the core questions below.

Questions

1. Coexistence. Is there a sanctioned way to run a custom whole-body rt/lowcmd policy that coexists with the vendor balancer / locomotion on the 23-DOF EDU — or must custom whole-body fully replace the vendor controller (i.e. Develop-only, and therefore incompatible with walking)? We find rt/lowcmd against an active controller jitters/oscillates (cf. unitree_sdk2_python fix: LeRobot 0.5+ policy resolution and dependency updates strands-labs/robots#43 / Benchmark adapter: Meta-World (MetaWorldAdapter) strands-labs/robots#108), so we only run it with the controller off (Develop), which is gantry-only.
2. Stand procedure + sim matching. For a custom whole-body stand in Develop mode, what is the recommended foot-loading / gantry procedure, and what are the rt/lowcmd control-loop latency and the joint PD-gain conventions, so we can match them in simulation? (The limit cycle looks like a latency/gain mismatch.)
3. Mode signal. MotionSwitcher.CheckMode returns name='ai' in both AI-Sport and a freshly-entered Develop mode (we also observe code=3104), so it cannot gate a takeover. We currently rely on the loco GET_FSM_ID (7001) liveness (answers when the balancer runs; errors 3102/3104 in Develop). Is there a supported, reliable signal to distinguish "vendor balancer active" from "low-level Develop"?
4. Recommended path. Is rt/arm_sdk overlay (blends with the running balancer) + LocoClient.Move the recommended path for custom upper-body + vendor locomotion on the 23-DOF EDU? That is our working assumption for the task (arm reach over the vendor balancer, decline if out of envelope).

[armwaheed]

Follow-up leads (2026-06-17, updated) — and we resolved the variant ourselves.

Two findings — one from stepping through the g1_description URDF the Unitree engineer pointed us to, one from an operator observation — both pointing at sim-asset / safety-layer gaps rather than the policy itself:

1. We trained on the wrong asset — and we've now pinned the exact variant. We read our unit's mode_machine live from rt/lowstate: mode_machine = 4 → g1_23dof_rev_1_0 (hip gear {14.3, 22.5}) — not g1_23dof_mode_10 (mode 10, {22.5, 22.5}) as we'd assumed. Our Isaac Lab policy trained on the 29-DOF Inspire-hand mobile USD, whose mass/CoM and gear ratios differ from this real 23-DOF EDU — plausibly explaining both the forward-CoM lean and part of the limit cycle (wrong effective hip-pitch gear ratio, 14.3 vs the assumed 22.5). Fix, if whole-body is ever revisited: rebuild the sim asset from g1_23dof_rev_1_0 with matching inertials + gear ratios. (We've corrected the robot descriptor accordingly — and this answers the support ticket's variant question ourselves.)

2. The factory controller clamps motion off-ground; ours didn't. In factory Regular mode, when a foot leaves the ground the leg motion becomes markedly gentler (reduced velocity + range); our custom policy flailed violently. This is a ground-contact-gated safety layer (a motion clamp, or a switch to a damped/hold mode — mechanism unconfirmed). Important distinction: replicating it would make our failure safer, not make the policy balance — a safety clamp ≠ a balance fix. The deeper point: the vendor balancer already has this protection, which is precisely why delegating balance to it (the arm-overlay path) is the right call.

Both are folded into the Unitree support ticket (the rt/lowcmd loop rate / latency + leg PD-gain conventions to match in sim, and whether the off-ground behaviour is a documented safety layer). This stays the academic branch — the bed-making demo path is arm-overlay + vendor LocoClient, unchanged.