Section 7.2: Feedback, error, stability, overshoot, oscillation

A Careful Control Loop

This section develops the technical contract for Feedback, error, stability, overshoot, oscillation into a usable mental model. First we define the object of study, then we connect it to the agent loop, then we test it with a compact implementation.

The key question in Feedback, error, stability, overshoot, oscillation is practical: what must the agent know, what can it observe, what action is available, and what evidence shows that the action worked under the stated conditions?

Theory

For Feedback, error, stability, overshoot, oscillation, the practical design rule is to make the interface inspectable before optimization begins: inputs, outputs, units, latency, bounds, and failure labels should all be visible in the saved artifact.

Feedback begins with an error signal, $e_t=r_t-y_t$, where $r_t$ is the reference and $y_t$ is the measured output. Stability asks whether a small disturbance stays bounded or shrinks; overshoot asks how far the response passes the target; oscillation asks whether correction arrives with the wrong phase or too much gain. For an AI practitioner, these are not abstract labels. They are log columns in a step-response test.

Worked Example

Stability of a linear system is decidable by inspection of one matrix. For \(\dot x = Ax\), the equilibrium is asymptotically stable exactly when every eigenvalue of \(A\) has a strictly negative real part. The Lyapunov view gives the same answer through an energy-like function: if there is a positive-definite \(P\) with \(\dot V(x) = x^\top(A^\top P + P A)x \le 0\), the system is stable. Code Fragment 7.2.1 takes a pendulum linearized near upright (an unstable plant), closes a PD loop around it, and verifies stability both ways.

import numpy as np
from scipy.linalg import solve_lyapunov

def classify(A):
    ev = np.linalg.eigvals(A)
    mx = np.max(ev.real)
    tag = "stable" if mx < 0 else ("marginal" if np.isclose(mx, 0) else "UNSTABLE")
    return ev, mx, tag

# Pendulum near upright: gravity term gives a positive eigenvalue -> it falls.
A_open = np.array([[0.0, 1.0],
                   [16.0, -0.2]])
# Proportional-derivative feedback u = -[k1 k2] x folded into the dynamics.
k1, k2 = 30.0, 8.0
A_cl = np.array([[0.0,        1.0],
                 [16.0 - k1, -0.2 - k2]])

for name, A in [("open-loop", A_open), ("PD closed-loop", A_cl)]:
    ev, mx, tag = classify(A)
    print(f"{name:>15}: eig = {np.round(ev, 3)}  max Re = {mx:+.3f}  -> {tag}")

# Lyapunov certificate for the stable loop: solve A^T P + P A = -Q, P must be PD.
Q = np.eye(2)
P = solve_lyapunov(A_cl.T, -Q)
print(f"Lyapunov P eigenvalues = {np.round(np.linalg.eigvalsh(P), 3)}  (all > 0 proves stability)")

Practical Recipe

1. Write the observation, action, and success metric before choosing a model.
2. Build a baseline that is simple enough to debug by inspection.
3. Add the library implementation only after the baseline behavior is understood.
4. Record failures as structured cases: perception error, state error, planning error, control error, or evaluation error.
5. Run at least one perturbation test before trusting the result.

Production Pattern

Feedback, error, stability, overshoot, oscillation sits inside the Part II robotics contract: geometry defines where things are, kinematics defines what motion is possible, dynamics defines what motion costs, control defines how errors are corrected, and sensing defines what the agent can know on time.

Translate feedback behavior into measurable overshoot, settling time, steady-state error, and oscillation. This makes the section useful to students, builders, and researchers at the same time: the idea has an intuitive role, a formal interface, a runnable check, and a failure mode that can be reproduced.

Use this recipe when turning Feedback, error, stability, overshoot, oscillation into code, a simulator experiment, or a robot diagnostic. The point is not to use every library. The point is to keep the hand-built baseline and the maintained-tool path comparable.

1. Write the control objective, measured state, actuator command, update rate, and saturation policy.
2. Run a step-response test before adding learning, with overshoot, settling time, and steady-state error logged.
3. Compare the hand controller with python-control, CasADi, Drake, do-mpc, or ROS 2 control on the same plant model.
4. Record latency, missed deadlines, saturation events, constraint violations, and recovery actions.
5. Only compare controllers and policies when they share sensors, action limits, disturbance tests, and safety checks.

A learned policy can hide an unstable inner loop until the disturbance changes. Check update rate, delay, saturation, integral windup, and fallback behavior before scaling training. For this section, first reproduce one tiny step response by hand, then rerun it through python-control, CasADi, Drake, do-mpc, or ROS 2 control. If the two disagree, inspect sample time, sign convention, measurement delay, and output units before changing the model.