Real-time control loops

"I shaved eight milliseconds off my inference time and celebrated. Then I measured the whole loop and found the operating system had been sitting on my buffer for forty milliseconds the entire time, humming to itself."

A Chastened AI Agent

This section closes the chapter by assembling the pieces built earlier into a running system. It assumes the envelope and spectral features of Section 32.2, the decoders and command mapping of Section 32.3, and the artifact rejection of Section 32.6, and it leans on the sampling, timestamping, and synchronization foundations from Chapter 3. The streaming and online-inference mechanics here are the biosignal instance of the general patterns in Chapter 60, run under the edge-deployment constraints of Chapter 59.

The loop and its latency budget

A myoelectric control loop is a fixed sequence of stages, each contributing delay. Raw samples accumulate into an analysis window; the window is turned into features; the decoder produces a label or a continuous command; a control layer smooths and rate-limits it; the command travels to the actuator; and the actuator has its own mechanical rise time. The end-to-end delay a user perceives is the sum:

The term that surprises most newcomers is \(t_{\text{win}}\). A decision made from a window of length \(L\) cannot reflect an intention until enough of that window has filled with post-intention samples, so a window contributes on the order of \(L/2\) to \(L\) of delay before inference even starts. A generous 250 millisecond window already spends most of the usable budget. The total controllable delay, the part under \(d_{\text{loop}}\) that the engineer can move, should stay below roughly 100 to 125 milliseconds, and the whole loop below about 200 to 300 milliseconds, above which users report the device as laggy and stop trusting it. That single constraint drives almost every design choice: window length trades class separability against \(t_{\text{win}}\), and heavier models buy accuracy with \(t_{\text{infer}}\) you may not have.

Engineering a deterministic loop

The loop is best structured as a fixed-rate scheduler: a decision cadence (say every 40 milliseconds, matching the window hop) that must complete each cycle before the next tick. Meeting this reliably on a wearable or embedded controller is a systems problem, not a modeling one. Sample acquisition should be interrupt or DMA driven so the CPU is never busy-waiting on the ADC; features and inference should run in a bounded-work path with no dynamic memory allocation and no unbounded loops, so worst-case execution time is predictable; and the model should be quantized and pruned (per Chapter 59) until its worst-case inference time, not its average, fits inside the cycle. A ring buffer decouples the constant-rate producer (the ADC) from the periodic consumer (the decoder) so that neither blocks the other. The code below sketches the timing skeleton and, crucially, instruments its own loop time so the tail is measurable rather than assumed.

import time, numpy as np
from collections import deque

FS, HOP, WIN = 1000, 40, 200          # Hz, hop ms, window ms
BUF = deque(maxlen=WIN * 8 // 1000 * FS // 8 or WIN * FS // 1000)  # ring of WIN samples/ch
period = HOP / 1000.0                  # target 40 ms decision cadence
loop_ms = []                           # instrumentation: measured cycle time

def step(window, decoder, controller):
    """One decision cycle: features -> inference -> rate-limited command."""
    t0 = time.perf_counter()
    feat = np.concatenate([np.mean(np.abs(window), 1),          # MAV per channel
                           np.sum(np.abs(np.diff(window, 1)), 1)])  # waveform length
    cmd  = decoder(feat)               # bounded-work model call
    cmd  = controller.rate_limit(cmd)  # slew-limit + rest-threshold gate
    loop_ms.append((time.perf_counter() - t0) * 1e3)
    return cmd

def run(source, decoder, controller):
    next_tick = time.perf_counter()
    for chunk in source:               # DMA/interrupt-fed sample chunks
        BUF.extend(chunk)
        now = time.perf_counter()
        if now >= next_tick and len(BUF) >= WIN * FS // 1000:
            win = np.array(BUF).reshape(-1, WIN * FS // 1000)  # (channels, samples)
            emit(step(win, decoder, controller))
            next_tick += period        # fixed cadence: no drift accumulation
            if now - next_tick > period:      # missed a deadline
                next_tick = now + period      # resync, and log the overrun

Two details in that skeleton matter disproportionately. First, advancing next_tick by a fixed period rather than sleeping a fixed duration prevents slow drift of the decision rate. Second, when a deadline is missed the loop resynchronizes to the present rather than firing a burst of catch-up decisions, because a backlog of stale commands is worse than a skipped one. The loop_ms list is not decoration: it is the only way to know whether the tail is safe on the actual target hardware, which never behaves like your development laptop.

from libemg.emg_predictor import OnlineEMGClassifier
oc = OnlineEMGClassifier(offline_classifier=clf, window_size=200, window_increment=40,
                         online_data_handler=odh, features=["MAV", "WL"])
oc.run(block=False)     # starts the real-time acquire->feature->predict->emit loop

The human closes the loop

The most important feedback path in a myoelectric system is not in your code; it is the person. They watch the hand and feel its contact and adjust their next contraction accordingly. This makes the controller half of a two-learner system, and it has three consequences. First, closed-loop performance can diverge sharply from open-loop, offline numbers: a person compensates for a mediocre decoder if its errors are consistent and observable, and is defeated by a good decoder whose errors are erratic. Evaluate in the loop, with a human doing a real task, not only on a held-out set. Second, adding an explicit artificial feedback channel, most often vibrotactile or electrotactile stimulation encoding grip force or aperture, gives the person information the visual channel lacks and tightens their half of the loop, which is a live topic in prosthetics because commercial hands still return almost no sensation. Third, because the person keeps adapting, the decoder can adapt too: closed-loop decoder adaptation updates the model online from the stream the user is generating, so machine and human co-adapt toward a shared control strategy. That online-learning path is exactly the streaming, non-stationary setting of Chapter 60, and its uncertainty gating draws on the calibration tools of Chapter 18.

Failing safe and staying stable

Because a human and an actuator are in the loop, the controller needs an explicit safe state and rules for entering it. A raised-threshold rest class stops motion cleanly during low effort; a slew rate limit forbids instantaneous reversals that no muscle or motor could physically command and that usually signal a decode error; a watchdog forces the safe state when a deadline is missed, a sensor drops out, or an artifact detector from Section 32.6 fires; and an uncertainty gate lets the decoder abstain into rest when its confidence is low rather than committing to a risky action. Stability is the other concern: because the person reacts to the device and the device reacts to the person, a high-gain, low-latency loop with an over-eager decoder can oscillate, the user and controller chasing each other. The classic remedies are the control engineer's, not the machine learner's: add damping through rate limiting, keep loop gain modest, and prefer a slightly slower, steadier response over a twitchy fast one. A controllable loop beats an accurate one every time it matters.

What's Next

In Chapter 33, we step back from the tight, second-by-second control loop to the opposite time scale: continuous and contactless health monitoring, where signals are sparse, irregular, and measured over weeks, where missingness is itself informative, and where the question shifts from "what does the muscle intend right now" to "how is this person's physiology drifting over time."