Why a Foundation Model Cannot Close a Humanoid Balance Loop

One robot already publishes three different clocks

Dynamic balance is not one program running at one rate. Kim and colleagues, on the Mini-Cheetah quadruped, split the work in print. Joint PD feedback runs at 40 kHz. Whole-body impulse control runs at 500 Hz. The model-predictive layer that chooses ground reaction forces runs at 30 Hz. They also note that a simpler MPC they had used updated at 40 Hz, and that even optimized full-body MPC solvers barely fit inside 200 Hz. The fast loop is two orders of magnitude above the planning loop, on the same machine. [1]

Those numbers are quadruped measurements. A humanoid has a smaller support polygon and a different mass distribution. This page does not pretend the 40 kHz figure was taken on a humanoid ankle. It uses the split because the split is the result: force-level rejection of a disturbance cannot wait for the optimizer, and the optimizer cannot wait for a still slower model. A humanoid that collapses those clocks into one network has to show its own rates. It does not inherit Mini-Cheetah’s. [1]

Contact duration makes the split physical. Wensing and colleagues, on the MIT Cheetah, report bounding contacts as short as 85 ms, with peak forces over 450 N. An 85 ms contact is over before a 6 Hz policy has produced its next token. The Cheetah is not a humanoid either. The comparison is a time scale. Events that decide whether a foot sticks or slips are shorter than the interval between outputs of a large vision-language model measured on a desktop GPU. [2] [3]

About 6 Hz is a goal layer, not a reflex

OpenVLA’s published inference, about 6 Hz on one RTX 4090 in bfloat16, and 3 Hz or 1.2 Hz for the quantized A5000 cases, predicts a 7-dimensional manipulation action. It is not a joint-torque law. Placing that network in the loop that must hold a humanoid upright asks it to do a job its outputs do not describe, at a period of roughly 170 ms to 800 ms depending on the reported configuration. Mini-Cheetah’s whole-body layer has already cycled dozens of times in the shorter of those periods. The joint layer has cycled thousands of times. [3] [1]

The onboard computer makes the gap wider, not narrower. The 6 Hz figure is not a claim about a humanoid’s battery-powered computer. Kim’s MPC at 30 Hz and whole-body loop at 500 Hz were on the Mini-Cheetah’s own low-power computer. A foundation model that needs a 4090 to approach 6 Hz does not fit in that sentence. Running a smaller copy slower does not move it into the 500 Hz slot. It moves it further away. [3] [1]

The mechanics of support and angular momentum are already explained. How humanoid balance is framed on this siteThis page adds only the timing split.

A slow model can pick a contact target, then it has to get out of the way

There is still a job at 30 Hz and below. Kim’s MPC does not servo the motor. It proposes forces and contact information that the 500 Hz whole-body layer tracks, while 40 kHz PD holds the joints. A foundation model can sit even further outside: choose which object to approach, or which footstep region is acceptable, and hand a reference to the MPC. The handoff has a deadline. If the reference arrives after the foot has already been placed, it is a command for the next contact, not a correction of this one. [1]

Reflex, the catching policy discussed elsewhere on this site, commands a research G1 at 50 Hz from vision. Fifty hertz is faster than OpenVLA’s 6 Hz and slower than Mini-Cheetah’s 500 Hz whole-body loop. It is a task policy for a catch, not a proof that language-scale models belong inside balance. The useful comparison is the opposite. Even a specialized visuomotor policy that was trained for one contact-rich skill does not replace the inner loops. A general instruction model is slower than that specialized policy in the numbers published for OpenVLA. [3] [1]

[1] [2] [3]

Convert the rates to periods before comparing them

A frequency is easier to abuse than a period. Mini-Cheetah’s 40 kHz joint loop is a period of 25 microseconds. The 500 Hz whole-body loop is 2 ms. The 30 Hz MPC is about 33 ms. OpenVLA at about 6 Hz is about 170 ms, and the 1.2 Hz quantized case is a bit more than 800 ms. An 85 ms Cheetah contact, from the other paper, is shorter than one slow token and longer than several whole-body cycles. The contact can be tracked by the inner loops and still be invisible to the foundation model until it is over. [1] [3] [2]

Sharing a computer couples the periods. If the large model and the whole-body loop share a CPU, a 170 ms inference can stall the 2 ms loop unless the model is on another device or is preempted. Kim’s 500 Hz figure was measured on the robot’s computer for that controller, not while a 15 GB network occupied the same silicon. A humanoid architecture diagram that draws both boxes without a measured rate, taken while both are running, has not shown the split. It has shown a hope that the boxes do not interfere. [1] [3]

The command that is still useful at 170 ms is a contact plan for a later step: which region is acceptable, which object the hands should face, whether to stop walking. That command must be queued behind the current stance, not written into the joint targets of the stance in progress. Reflex’s 50 Hz catch policy, already discussed on this site, is a reminder that even a specialized visual policy publishes its own rate. Fifty hertz is 20 ms, close to the Mini-Cheetah MPC period and far from 40 kHz. It belongs with planning, not with the motor servo, and it was not a language model. [1]

A humanoid log can check the queue with three timestamps on each footfall. Touch down, liftoff, and the arrival time of the last external reference. If the reference arrives between touch down and liftoff, it missed this contact. Counting those misses, rather than averaging model loss, tells you whether the slow layer is actually outside the balance loop or is only drawn that way. [1] [2]

What to measure before you quote a loop rate

A datasheet that prints one frequency is not a timing budget. Ask which signal is sampled at that rate, which signal is only estimated, and which signal is a reference that a slower planner may rewrite. On Mini Cheetah the joint current loop, the body controller, and the model-predictive planner are three different clocks. A humanoid lab that quotes only the policy rate has not yet said what the motor sees.

• Sample time of joint position and joint velocity, not the camera frame rate.
• Age of the newest foot-contact bit when the body controller runs.
• Age of the torso reference when it arrives at that controller.
• Whether a language or vision model shares the CPU that runs the body loop.
• The longest stall observed, not the mean period.
• What the robot does if the reference is late: hold the last command, or fall through to a local reflex.

The last item is the one a foundation model cannot answer from a benchmark table. Holding the last command for 30 ms is a different machine from holding it for 800 ms. The first may be inside the body controller's own period on a quadruped. The second is several gait events on a biped if the step time is a few hundred milliseconds. Neither number is a humanoid specification. Both are reasons to log time, not to paste a model name into a stability claim.

Do not paste the quadruped rates onto a humanoid product

A humanoid vendor can run faster or slower than Mini-Cheetah at every layer. Nothing in these papers forbids a 1 kHz whole-body loop or a 100 Hz model on a humanoid. Nothing in them grants it either. The design error is to quote a foundation model’s language score, then assume the balance stack has the Cheetah’s inner rates because both machines have legs. The rates are properties of a controller on a named computer. They are measured, or they are absent. [1]

The failure that follows from mixing the clocks is specific. The slow layer commands a new foot target while the fast layer is already in contact. If the contact is shorter than the slow period, the command cannot change the force of this step. It can only disturb the next one. On a humanoid, the next step may be the one that had to recover the lean. A late recovery command is not a milder version of a fast one. It is a command about a stance that is already over. [2] [1]

• Publish the joint, whole-body and planning rates on the humanoid’s own computer, under the load of the model you claim is in the loop.
• State whether the large model can block the inner loops. If it shares the computer, measure the inner rate with the model running.
• Keep contact-timed logs: when the foot touched, when the slow command was issued, and whether the command landed inside that contact.
• Do not cite Mini-Cheetah’s 40 kHz as the humanoid’s servo rate.

[1] [3]