TFB Helm

What you are looking at. The fast loop (the physics + your hand + the β ceiling) is what would run on the ESP32-S3 in firmware; the slow loop (which target to seek) is the “deliberation,” here a simple goal-picker, on real hardware a model over Wi-Fi. The control law is one clamp: the machine’s move each tick is desired, then bounded to ±β·|your move| — so when you stop, it stops; when you move, it can add at most β of what you added. Why it helps anyway. Aligned with you, it spends the full +β toward the target, so you reach goals with ~1/(1+β) of the hand-motion you’d need alone. Why it can’t run away. Bounded by β·|yours| every tick, its cumulative contribution can never exceed β× your own path, and it cannot move the dial at all unless you are moving it. Red-team points the machine’s goal at the wrong end and lets it push as hard as it likes — the same clamp means it can at most slow you to (1−β) of your speed; it can never reverse you or seize the dial. The counter proves it, live. Verified vs. not. The ceiling math, the help factor, and the “can’t be seized” property are checked numerically; whether the assist feels like help — and how it reads on the real matrix and encoder — waits for the July hardware. Ports to firmware: the clamp is ~15 lines of Arduino.