Policy Hz vs. control Hz

What I expected

The textbook set my prior: a threshold near 100 Hz. The textbook says to sample ten to twenty times faster than the loop that you close. The guess of Chapter 28 put this loop near 5 to 8 Hz. I expected that 50 to 160 Hz would be sufficient. Before the run, I wrote 'up' next to 1000 and 200 and 'falls' next to 100 and below.

I also expected that the Hz of the would be the important number today. It was the least interesting number on the page.

The theory

A zero-order hold is a delay of half a period, so Day 28 already predicted today

Zoh as delay (arithmetic)

T = 1 / f;  1 / Hz = s
effective delay = T / 2 on average
1000 Hz: 0.5 ms    200 Hz: 2.5 ms
20 Hz: 25 ms   10 Hz: 50 ms   2 Hz: 250 ms
= Day 28 fell at 30 ms: 10 Hz (50 ms) and below must fall; 20 Hz, 25 ms, is under it and open

The two clocks (Day 26 + today)

inner: 1 kHz = 1,000 torque writes per s
outer: one 3B action step = 2,617 ms (Day 26, 640x360 image)
= 0.38 Hz at 640x360;  the 500M: 409 + 213 = 622 ms = 1.6 Hz
ratio: 1,000 / 0.38 = 2,600 ticks per intent
= one intent is 2,600 torque writes wide

The textbook rule is to sample at 10 to 20x the loop bandwidth. With the Chapter 28 guess of 5 to 8 Hz, the rule says 50 to 160 Hz is enough. The sim did not read the textbook: every rate under 1 kHz fell.

The sweep, three rows (sim, measured, 8 s window)

1000 Hz: 1.19 m walked
200 Hz: fell at 2.46 s
20 Hz: fell at 0.72 s

200: the row I had marked 'up'. It stood for 2.46 s, longer than any other fall, then went down. The floor is between 200 Hz and 1 kHz, on the grid I fixed before the run.

The setup

Render + sweep (Mac, ~6 min)

cd ~/Documents/workspace/Walker-CAD/Something
python3 walking/render_two_clocks.py --vla-hz 2
cat output/day29/rate_sweep.json

The measurement

What	Expected	Measured	Note
controller at 1000 Hz	up	walked 1.19 m	sim, ZOH between calls
controller at 200 Hz	up	fell at 2.46 s	sim, ZOH between calls
controller at 100 Hz	falls	fell at 1.38 s	sim, ZOH between calls
controller at 50 Hz	falls	fell at 1.16 s	sim, ZOH between calls
controller at 20 Hz	falls	fell at 0.72 s	sim, ZOH between calls
controller at 10 Hz	falls	fell at 0.73 s	sim, ZOH between calls
controller at 5 Hz	falls	fell at 1.10 s	sim, ZOH between calls
controller at 2 Hz	falls	fell at 1.40 s	sim, ZOH between calls
outer loop rate	a few Hz	Day 26 action JSON timing	sets intents

Measured in the MuJoCo sim unless the row says estimate or predicted. The outer-loop row is the Chapter 26 board timing.

Fig 29.1Controller call rate vs time to fall, MuJoCo biped, zero-order hold between calls (8 s window).

Token to torque: three queues, and no torque in the outer loop

Outer loopJSON action, 0.4 Hz at 640x360
Mailboxlatest wins
Intent layerfootstep target
Inner loop1 kHz torque

After the last box: torque, CAN, the motor's own MCU. Three queues sit between a token and a torque and each one drops the stale on purpose. The inner loop reads its target on its own clock and never waits for the outer one.

rate Hz	T/2 ms (arith.)	prior	fell at (s)	x at fall (m)
1000	0.5	up	-	1.19 at 8 s
200	2.5	up	2.46	0.13
100	5	falls	1.38	-0.09
50	10	falls	1.16	-0.01
20	25	falls	0.72	-0.10
10	50	falls	0.73	0.19
5	100	falls	1.10	0.02
2	250	falls	1.40	-0.35
real inner loop	-	1 kHz target	not measured yet	-

Measured: MuJoCo, same controller, hold between calls, 8 s window. The last row is the one that matters, and the inner loop runs in sim only. The loop on the real motors measures it: a timestamp on every torque write, and the p99 of the period (Chapter 20's lens) next to the mean.

Where it broke

200 Hz fell, and 2.5 ms of effective delay is a tenth of the 30 ms that caused the fall on Chapter 28. A is not only a delay. A held torque is also a staircase, where the body continues to move between calls and the torque does not. The next call then sees a larger error than the gains were tuned for. Either my crossover guess is low, or this controller depends on something that the textbook rule does not count.

The second result is that the two sweeps have one shape. Chapter 28 fell fastest at 60 ms of pure delay. Today the fastest falls were at 20 and 10 Hz, which is 25 and 50 ms of effective delay. The worst spot is in the same few tens of milliseconds both times. One controller, two knobs, one story. A zero-order-hold sweep cannot measure the sway frequency. The chirp test on Chapter 28's list still has to.

Summary

The right side of the clip shows the result of "just run the policy slower". The result is not a slower walk. The result is a fall.
The floor of this controller is between 200 Hz and 1 kHz. I fixed the grid of rates before the run.
One 3B action step takes 2,617 ms (Chapter 26, at 640x360). In that time, the 1 kHz inner loop of the sim writes 2,600 torques.

Sources

These sources are not mine. Measured numbers came off my own board; specs, estimates and paper figures are labeled as such.

LiteVLA-Edge (~150 ms / ~6.6 Hz on Orin-class)
Jetson-PI foresight-aligned async inference
Any locomotion stack (Isaac / cheap PD) on a 100 Hz dt