Skip to content
matthewcm.dev

    ↑ ↓ move · ↵ open · tab scopeopen graph →

    Balance Is a Control Loop

    A handstand is a feedback loop with a sensor, a delay and an actuator. So are autoscalers, rate limiters and a real-time UI under load — and they fail the same way.

    Growingmetaphortended planted 4 min read
    On this page

    When I finally held a freestanding handstand for longer than a few seconds, it didn’t feel like holding still. It felt like running a very fast, very small feedback loop: notice the lean, press the fingers, notice the overcorrection, ease off. The research agrees, and the model turns out to be one I already use at work.

    What the biomechanics says

    Two studies from Loughborough are the classic reference here.

    • Kerwin and Trewartha (2001) filmed gymnasts holding handstands and found that balance in the front-to-back direction is maintained mainly at the wrist. The shoulders and hips help, but the hands do most of the work.
    • Yeadon and Trewartha (2003) went further. They modelled the balance and found that wrist torque could be described as a simple function of where the body’s centre of mass was, and how fast it was moving, a short time earlier. In their four gymnasts that delay ranged from about 160 to 240 ms, consistent with long-latency reflexes rather than conscious decisions.
    • Later work (Blenkinsop, Pain and Hiley, 2017) found the same “wrist strategy” in use for most of the time in balance, with hip and shoulder strategies taking over for bigger disturbances.

    A sample of four is small, and lab gymnasts aren’t hobbyists like me. But the shape of the result is the useful bit: a handstand is a closed loop with sensors (pressure in the hands, the vestibular system, vision), latency (a couple of hundred milliseconds), and an actuator (finger and wrist torque).

    Why the delay matters

    A loop with a delay is always correcting for where you were, not where you are. That has consequences anyone who has tuned an autoscaler will recognise:

    • Correct too hard and you oscillate. Big finger presses throw you back past vertical, so you heel-press, so you go forwards again. The wobble grows until you fall.
    • Correct too late and you saturate. Once the lean is too large, the fingers simply can’t produce enough torque. No amount of effort saves it. You need a different strategy (bend the hips, walk the hands) or you bail.
    • Small, early corrections win. Quiet hands are the sign of a good handstand, not because nothing is happening but because everything is happening early.

    Don’t overshoot the kick-up

    My biggest handstand breakthrough was learning to kick up gently. A big kick spends the whole correction budget just stopping the overshoot. That’s the same failure as a deploy that sends all traffic to a new version at once, or a client that retries instantly and in sync with every other client. Arrive near the set point and let the loop do fine work.

    The same loop in software

    HandstandSystem
    Pressure in the hands, inner earMetrics: queue depth, latency, CPU, frame time
    ~200 ms neural delayScrape interval, aggregation window, cold starts
    Finger brake, heel acceleratorScale in/out, throttle, shed load
    Saturation: lean too far to saveMax replicas reached, queue full
    Oscillation from over-correctionAutoscaler flapping, retry storms
    Kick-up overshootBig-bang rollouts, thundering herds

    Backpressure in a real-time UI

    I build interfaces that render high-frequency market data. When a feed sends updates faster than the browser can paint them, you need a balance strategy, just like the hands:

    • Coalesce: keep only the latest value per key and render once per animation frame. The finger brake.
    • Drop: skip intermediate states that nobody could see anyway.
    • Slow the producer: tell the server to send less, if the protocol allows it. Proper backpressure.

    The worst option is the one that feels most responsive: render every message immediately. It’s the over-correcting handstand. Frame times climb, the main thread saturates, and the UI falls over in exactly the moment people are watching it most.

    What transfers back

    1. Measure early, act small. Short feedback intervals plus gentle corrections beat big reactive swings.
    2. Know your saturation point. Every loop has a lean it can’t recover from. Design the bail before you need it, like falling on one leg.
    3. Account for the delay. If your signal is a minute old, a hard correction is a guess about the past.
    4. Practise at the edges. End-range save drills in handstands are game days for systems.

    Sources

    • Kerwin, D. G. & Trewartha, G. (2001). Strategies for maintaining a handstand in the anterior-posterior direction. Medicine & Science in Sports & Exercise, 33(7).
    • Yeadon, M. R. & Trewartha, G. (2003). Control strategy for a hand balance. Motor Control, 7(4).
    • Blenkinsop, G. M., Pain, M. T. G. & Hiley, M. J. (2017). Balance control strategies during perturbed and unperturbed balance in standing and handstand. Royal Society Open Science, 4(7).
    • Åström, K. J. & Murray, R. M. (2008). Feedback Systems: An Introduction for Scientists and Engineers. Princeton University Press.
    • Reactive Streams specification (reactive-streams.org), for backpressure as a protocol concern.
    • #control-loops
    • #backpressure
    • #feedback
    • #handstand
    • #observability

    ↪ Links to (1)