Science

PID Control: The Three Knobs Behind Most Machines

· 4 min

Now, then, and next.

A thermostat holding a room at 24 degrees, a drone hovering in a gust, a cruise control keeping a car at 80 km/h on a slope. Underneath many machines like these sits the same small idea: the PID controller. It is old, it is simple, and it is still the first thing an engineer reaches for.

Where it came from

In 1922 Nicolas Minorsky, working on automatic steering for US Navy ships, published "Directional Stability of Automatically Steered Bodies". He had watched how experienced helmsmen steered and noticed they did not just react to how far the ship was off course. They also reacted to how fast it was swinging, and they corrected for steady drift caused by wind and current. Writing those three habits down as mathematics gave the controller its shape.

Twenty years later, in 1942, John G. Ziegler and Nathaniel B. Nichols of Taylor Instruments published practical rules for choosing the controller's settings. The Ziegler–Nichols method is still taught in control courses today.

The three terms

Everything starts with the error: the gap between where you want to be (the setpoint) and where you are.

P, proportional: the present. Push in proportion to the error. Far from the target, push hard; close to it, push gently. On its own, P often settles a little short of the target, because as the error shrinks so does the push, and something like friction or gravity can balance it out.

I, integral: the past. Add up the error over time. If a small error has been sitting there for a while, this term keeps growing until it is wiped out. That is what removes the steady offset P leaves behind.

D, derivative: the future. Look at how fast the error is changing. If you are rushing toward the target, D eases off before you overshoot. It acts like a damper.

The output is just the sum of the three, each with its own gain, Kp, Ki and Kd. Those are the three knobs.

In a few lines of code

A discrete PID loop that runs every dt seconds fits in a handful of lines of Python:

class PID:
    def __init__(self, kp, ki, kd):
        self.kp, self.ki, self.kd = kp, ki, kd
        self.integral = 0.0
        self.prev_error = None

    def step(self, setpoint, measured, dt):
        error = setpoint - measured
        self.integral += error * dt
        deriv = 0.0 if self.prev_error is None else (error - self.prev_error) / dt
        self.prev_error = error
        return self.kp * error + self.ki * self.integral + self.kd * deriv

Real controllers add a few safety rails. They cap the integral so it can't wind up to a huge value while the actuator is already maxed out (called integrator windup), and they filter the derivative, because differentiating a noisy sensor reading amplifies the noise.

Tuning: the art in the knobs

Raise Kp and the system responds faster but starts to overshoot and oscillate. Raise Ki and offsets disappear sooner, at the cost of more overshoot. Raise Kd and oscillations calm down, until sensor noise starts making the output twitchy. The Ziegler–Nichols recipe gives a starting point: turn up P alone until the system oscillates steadily, note that gain and the period of the oscillation, and derive all three gains from those two numbers. In practice engineers then adjust by hand.

Why it is everywhere

PID needs no detailed model of the system. You don't have to know the exact physics of a furnace or a motor; you only need a measurement and an actuator. That makes it cheap to build, easy to understand on a plant floor, and light enough for the tiniest microcontroller. Control textbooks, including Karl Åström and Tore Hägglund's widely used books on PID, point out that the great majority of industrial control loops are PI or PID.

Drone autopilots such as PX4 use cascaded PID loops: an outer loop turns a position error into a desired velocity, the next into a desired attitude, and the innermost into motor commands.

The catch in a networked world

PID quietly assumes that measurements arrive on time and regularly. In a cyber-physical system they often travel over a network, and a delayed or dropped measurement means the controller is acting on stale information. Delay eats into the stability margin: gains that work perfectly on a wired loop can make a networked loop oscillate. The derivative term, which depends on fresh, evenly spaced samples, is usually the first to suffer. That is why tools that simulate the network and the physical system together are so useful when designing these loops.

The lesson

The three terms are a decent habit outside engineering too. Respond to where you are now, don't ignore a small problem that keeps lingering, and watch which way things are heading before you overcorrect.

Share