Section 7.1: Open-loop vs. closed-loop control

"Open-loop trusts the plan. Closed-loop trusts the plan until the world says otherwise, then adjusts."

Section 7.1

Tape a robot's joint commands to a perfect plan, hit play, and walk away: it will reach the target only in a universe where friction, payload, and gravity match your model to the digit, which is to say never. The fix is to let the robot keep asking the world what just happened. This section turns the technical contract for open-loop versus closed-loop control into a usable mental model. It defines the object of study, connects it to the agent loop, and tests it with a compact implementation.

The key question 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

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.

An open-loop controller commits to an action sequence before observing any consequences: \(a_{0:T-1}=g(r_{0:T-1}, \hat s_0)\). It works only when the plant model, initial state, and disturbances are all predictable, where the plant is the physical system being controlled (the robot and its environment), the thing that turns a commanded action into a measured outcome. On a physical robot, small modeling errors in friction, joint compliance, or payload mass do not average out. They accumulate across every time step. A 1-degree joint-angle error at step 1 grows into a centimeter of end-effector displacement by step 50. To put that in context, an open-loop imitation policy on a real robot often needs on the order of tens of thousands of demonstration episodes to statistically average out disturbances that a simple closed-loop PID can reject within a few hundred control ticks, though the exact ratio depends heavily on the task and disturbance magnitude. The open-loop plan has no mechanism to notice or correct that drift. Contact-rich tasks fail for exactly this reason: the world pushes back in ways the pre-committed sequence cannot accommodate. The planner solves for the entire command trajectory offline, typically by inverting a dynamics model or running trajectory optimization once. At execution time it replays each \(a_k\) at the scheduled tick with no sensor read. The robot follows the tape regardless of what happened on the previous step.

A closed-loop controller takes a different approach. It computes \(a_t=\pi(\hat s_t,r_t)\) after each new state estimate, so perception and state estimation can correct drift, slip, delay, and contact surprises. This is the difference between blind execution and continuous correction. It determines whether small modeling errors stay small or compound into large failures. A controller that never reads a sensor is not controlling the robot; it is narrating a plan the robot may have already abandoned. Figure 7.1B contrasts the two architectures side by side: the open-loop path runs left to right with no return arrow, while the closed-loop path adds a sensor that feeds the measured state back into the controller on every tick.

Worked Example

The cleanest way to feel the difference between an open-loop plan and a closed-loop controller is to run both on the same plant with the same unmodeled disturbance. Code Fragment 7.1.1 simulates a 1D point mass (\(m\,\ddot x = u\)) twice. The open-loop path commits to a precomputed force profile that would reach the target under a perfect model. The closed-loop path runs a discrete Proportional-Integral-Derivative (PID) law, \(u(t)=K_p e(t)+K_i\!\int e\,dt+K_d\,\dot e(t)\), where the proportional term \(K_p e(t)\) pushes back in proportion to the current error, the integral term \(K_i\!\int e\,dt\) accumulates past error to cancel a steady-state offset, and the derivative term \(K_d\,\dot e(t)\) resists how fast the error is changing to damp overshoot; section 7.3 derives this law from first principles, this section only needs the three terms to read the code below, with an anti-windup clamp (a guard that stops the integral term from continuing to accumulate while the actuator is saturated, i.e. already commanding its maximum force). A constant 2 N disturbance enters both runs.

import numpy as np

# 1D point mass  m*xdd = u (force).  Compare an open-loop plan with a PID loop.
m, dt, T = 1.0, 0.02, 4.0
n = int(T / dt)
kp, ki, kd = 12.0, 4.0, 6.0
u_max = 8.0          # actuator force limit (saturation)
x_ref = 1.0          # step setpoint, meters

def step(x, v, u):
    a = u / m
    return x + v * dt, v + a * dt

def open_loop(dist):
    # Bang-bang plan that "should" reach x_ref if the model were exact.
    u_plan = np.where(np.arange(n) < n // 2, u_max, -u_max)
    x, v, xs = 0.0, 0.0, []
    for k in range(n):
        x, v = step(x, v, np.clip(u_plan[k] + dist, -u_max, u_max))
        xs.append(x)
    return np.array(xs)

def pid(dist):
    x, v, ei, e_prev = 0.0, 0.0, 0.0, x_ref
    xs, errs = [], []
    for k in range(n):
        e = x_ref - x
        ei_trial = ei + e * dt
        de = (e - e_prev) / dt
        u_unsat = kp * e + ki * ei_trial + kd * de
        u = np.clip(u_unsat, -u_max, u_max)
        if u == u_unsat:            # anti-windup: integrate only when not clamping
            ei = ei_trial
        x, v = step(x, v, u + dist)
        xs.append(x); errs.append(e); e_prev = e
    return np.array(xs), np.array(errs)

dist = 2.0  # unmodeled constant force disturbance (N)
xs_ol = open_loop(dist)
xs_cl, errs = pid(dist)
print(f"open-loop final pos   = {xs_ol[-1]:+.3f} m  (target {x_ref:.1f})")
print(f"closed-loop final pos = {xs_cl[-1]:+.3f} m  steady error = {errs[-1]:+.4f} m")

Practical Recipe

The worked example showed open-loop and closed-loop behavior on one toy plant; turning that intuition into a dependable workflow on real hardware means fixing the order of operations before any controller is tuned.

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

Those failure modes are not isolated bugs; they are symptoms of where this control choice sits in the larger robotics stack, which is where the production pattern begins.

Open-loop vs. closed-loop control 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.

Where this choice bites in a deployed stack

Open-loop plans stake everything on disturbance assumptions; closed-loop controllers stake everything on measurement and timing contracts. Either way the choice comes with an intuitive role, a formal interface, a runnable check, and a reproducible failure mode, so any reader can locate the exact assumption their deployment violates.

Consider a specific case. The Boston Dynamics Spot quadruped uses closed-loop leg controllers running at roughly 1 kHz. Each one reads joint encoders and Inertial Measurement Unit (IMU) data to correct foot placement within milliseconds of ground contact. An open-loop gait script replays a fixed joint trajectory, so it fails on any surface that differs from the recording surface. Unmodeled tendon compliance and ground reaction forces accumulate into a pose error, and a 1 kHz feedback loop can typically correct that error before it grows large enough to cause a fall, provided the disturbance itself does not exceed the actuator's torque limit. The same principle appears at slower timescales in robotic manipulation. OpenAI's Dactyl hand (2019) relied on randomized simulation training precisely because its open-loop policy could not assume exact finger contact geometry. The policy therefore had to internalize a distribution over disturbances rather than depend on any single model being correct.

Use this recipe when turning Open-loop vs. closed-loop control 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.

An open-loop plan can look perfect in simulation because no observation is allowed to contradict it. Test it with a pose offset, a delayed actuator command, and a small unmodeled disturbance, then compare the same trial under a closed-loop policy that re-estimates state after each action. If the two disagree, inspect sensing latency, frame conventions, actuator saturation, and the exact point where feedback re-enters the decision loop before changing the model.