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

A Careful Control Loop

This section develops the technical contract for Open-loop vs. closed-loop control 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 Open-loop vs. closed-loop control 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 Open-loop vs. closed-loop control, 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 it sees the consequences: $a_{0:T-1}=g(r_{0:T-1}, \hat s_0)$. This works when the plant model, initial state, and disturbances are predictable enough that the planned sequence remains valid. A closed-loop controller instead computes $a_t=\pi(\hat s_t,r_t)$ after each new estimate, so perception and state estimation can correct drift, slip, delay, and contact surprises.

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 PID law, \(u(t)=K_p e(t)+K_i\!\int e\,dt+K_d\,\dot e(t)\), with an anti-windup clamp so the integral term stops accumulating while the actuator is saturated. 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

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

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.

Open-loop plans need disturbance assumptions, while closed-loop controllers need measurement and timing contracts. 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 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.