Introduction

Your car's cruise control never "knows" the road, the wind or the hill ahead. All it ever sees is one number: how far off you are from the speed you asked for. And yet, second after second, it nudges the throttle until that number goes to zero. The same trick keeps ovens at temperature, drones hovering in place, and chemical plants from boiling over.

The trick is called PID control — proportional, integral, derivative — and it may be the single most deployed algorithm in the physical world. No model of the car, the oven or the drone is required. Just one signal, the error, and three simple ways of reacting to it.

The hard part was never writing the formula. It's tuning it: push too hard and the system overshoots and oscillates: too gently and it crawls toward the target forever. Where that boundary sits is a genuinely rich problem in control theory.

Tune the Gains

Below is a simulated mass on a spring-damper track. Click Step setpoint to ask it to move, and watch the controller chase it. Each gain does one job:

<p class="hint">A simulated mass on a spring-and-damper track must reach the dashed setpoint line. Drag the sliders to change the P, I and D gains, then press <b>Step setpoint</b> to move the target and watch the blue trace chase it.</p>
<canvas id="scope" class="scope" width="640" height="220"></canvas>
<div class="readout" id="readout">Adjust the gains, then step the setpoint.</div>
<div class="sliders">
  <label>P (proportional) <span id="pVal">4.0</span>
    <input id="pSlider" type="range" min="0" max="12" step="0.1" value="4">
  </label>
  <label>I (integral) <span id="iVal">0.0</span>
    <input id="iSlider" type="range" min="0" max="10" step="0.1" value="0">
  </label>
  <label>D (derivative) <span id="dVal">0.0</span>
    <input id="dSlider" type="range" min="0" max="5" step="0.1" value="0">
  </label>
</div>
<div class="btns">
  <button id="step" type="button">Step setpoint</button>
  <button id="reset" type="button" class="ghost">Reset</button>
</div>

* { box-sizing: border-box; }
body { font-family: system-ui, sans-serif; color: #222; margin: 0; }
.hint { font-size: .9rem; color: #444; margin: 0 0 .7rem; line-height: 1.45; }
.scope { width: 100%; max-width: 640px; height: 180px; background: #f4f6f8; border: 1px solid #cdd9e3;
         border-radius: 8px; display: block; }
.readout { font: 600 .95rem ui-monospace, monospace; color: #1d3557; margin: .5rem 0; min-height: 1.4em; }
.sliders { display: flex; flex-direction: column; gap: .5rem; margin: .6rem 0; }
.sliders label { font-size: .85rem; font-weight: 600; color: #1d3557; display: flex; flex-direction: column; gap: .2rem; }
.sliders input[type="range"] { width: 100%; accent-color: #1d3557; }
.btns { display: flex; gap: .5rem; flex-wrap: wrap; }
button { font: 600 14px system-ui, sans-serif; padding: .45rem .9rem; border: 1px solid #1d3557;
         background: #1d3557; color: #fff; border-radius: 8px; cursor: pointer; }
button.ghost { background: #fff; color: #1d3557; }

const fmt = (s, v) => s.replace(/%(\w+)%/g, (_, k) => String(v[k] ?? ''));
// Simulated plant: a mass on a spring with damping, m*x'' + b*x' + k*x = u(t).
// The controller only ever sees the error; it never sees m, b or k directly.
const MASS = 1, DAMP = 1.2, STIFF = 2;
const DT = 0.02;          // simulation time step in seconds
const STEPS = 700;        // total simulated steps per run
const BAND = 0.02;        // "settled" tolerance band, as a fraction of the setpoint

let setpoint = 1;
let history = [];         // not used directly; each run recomputes its own path
let running = false;

const pSlider = document.getElementById('pSlider');
const iSlider = document.getElementById('iSlider');
const dSlider = document.getElementById('dSlider');
const pVal = document.getElementById('pVal');
const iVal = document.getElementById('iVal');
const dVal = document.getElementById('dVal');
const canvas = document.getElementById('scope');
const ctx = canvas.getContext('2d');
const readout = document.getElementById('readout');

function gains(){ return { Kp: parseFloat(pSlider.value), Ki: parseFloat(iSlider.value), Kd: parseFloat(dSlider.value) }; }

// Runs the discrete PID loop against the mass-spring-damper plant and records the trace.
function simulate(Kp, Ki, Kd, target){
  let x = 0, v = 0, integral = 0, prevError = null;
  let maxOvershoot = 0, settleStep = null;
  const path = [];
  for (let i = 0; i < STEPS; i++){
    const error = target - x;
    integral += error * DT;
    const derivative = prevError === null ? 0 : (error - prevError) / DT;
    prevError = error;
    const u = Kp * error + Ki * integral + Kd * derivative;
    const a = (u - DAMP * v - STIFF * x) / MASS; // Newton's second law solved for acceleration: a = (u - damping - spring)/mass.
    v += a * DT;
    x += v * DT;
    path.push(x);
    if (target !== 0){
      const overshoot = (x - target) / target;
      if (overshoot > maxOvershoot) maxOvershoot = overshoot;
    }
    if (settleStep === null && Math.abs(x - target) < BAND * Math.max(Math.abs(target), 1)){
      settleStep = i;
    }
  }
  return { path, maxOvershoot, settleStep };
}

function draw(path, target){
  const w = canvas.width, h = canvas.height;
  ctx.clearRect(0, 0, w, h);
  // light horizontal grid lines for readability
  ctx.strokeStyle = '#dbe3ea';
  ctx.lineWidth = 1;
  for (let gy = 0; gy <= 4; gy++){
    const y = (h / 4) * gy;
    ctx.beginPath(); ctx.moveTo(0, y); ctx.lineTo(w, y); ctx.stroke();
  }
  const yMax = Math.max(1.6, target * 1.6);
  const toY = (val) => h - (val / yMax) * h;

  // dashed red line marking the target the controller is chasing
  ctx.strokeStyle = '#e63946';
  ctx.setLineDash([6, 4]);
  ctx.beginPath();
  ctx.moveTo(0, toY(target));
  ctx.lineTo(w, toY(target));
  ctx.stroke();
  ctx.setLineDash([]);

  // solid blue line tracing the simulated position over time
  ctx.strokeStyle = '#1d3557';
  ctx.lineWidth = 2;
  ctx.beginPath();
  path.forEach((val, i) => {
    const px = (i / (path.length - 1)) * w;
    const py = toY(val);
    if (i === 0) ctx.moveTo(px, py); else ctx.lineTo(px, py);
  });
  ctx.stroke();
}

function run(){
  const { Kp, Ki, Kd } = gains();
  const { path, maxOvershoot, settleStep } = simulate(Kp, Ki, Kd, setpoint);
  draw(path, setpoint);
  const overshootPct = Math.max(0, maxOvershoot * 100);
  if (settleStep === null){
    readout.textContent = fmt('Did not settle within the time window (peak overshoot %overshoot%%).', { overshoot: overshootPct.toFixed(0) });
  } else {
    const settleTime = (settleStep * DT).toFixed(2);
    readout.textContent = fmt('Settled in %time% s with %overshoot%% overshoot.', { time: settleTime, overshoot: overshootPct.toFixed(0) });
  }
}

pSlider.addEventListener('input', () => { pVal.textContent = parseFloat(pSlider.value).toFixed(1); run(); });
iSlider.addEventListener('input', () => { iVal.textContent = parseFloat(iSlider.value).toFixed(1); run(); });
dSlider.addEventListener('input', () => { dVal.textContent = parseFloat(dSlider.value).toFixed(1); run(); });

document.getElementById('step').addEventListener('click', () => {
  setpoint = setpoint === 1 ? 1.6 : 1; // alternate between two setpoints so the controller has something to chase
  run();
});
document.getElementById('reset').addEventListener('click', () => {
  pSlider.value = 4; iSlider.value = 0; dSlider.value = 0;
  pVal.textContent = '4.0'; iVal.textContent = '0.0'; dVal.textContent = '0.0';
  setpoint = 1;
  run();
});

readout.textContent = 'Adjust the gains, then step the setpoint.';
run();
Result
Console

P (proportional) pushes harder the further you are from target — crank it up and the response gets fast but jittery. I (integral) remembers the accumulated past error and erases any leftover offset — push it too far and it overshoots and rings. D (derivative) reacts to how fast the error is changing, damping the swing before it happens. Try P alone first, then add I, then add D, and watch the settle time and overshoot trade off against each other.

The Real Complexity

The controller itself is almost embarrassingly simple. At every instant it measures the error e(t)=setpoint−measuremente(t) = \text{setpoint} - \text{measurement} and outputs

u(t)=Kp e(t)+Ki∫0te(τ) dτ+Kdde(t)dtu(t) = K_p\, e(t) + K_i \int_0^t e(\tau)\, d\tau + K_d \frac{de(t)}{dt}

Three multiplications, one running sum, one difference. No model of the plant is required to run it. The genuinely hard problem is choosing KpK_p, KiK_i, KdK_d so that the closed loop is even stable, let alone fast and smooth.

  • Stability is not automatic. Push KpK_p or KiK_i too high and the feedback loop can amplify its own corrections into a runaway oscillation — the same closed-loop system that converges nicely at one gain setting can diverge at another.
  • Classical control theory answers this exactly for linear models: the Routh–Hurwitz criterion checks the sign pattern of a polynomial's coefficients to certify stability without ever solving the underlying differential equation, and root-locus/Nyquist analysis maps out exactly which gains keep every pole in the stable region.
  • Tuning by ear was formalized early. In 1942, engineers John Ziegler and Nathaniel Nichols published step-by-step rules — push KpK_p until the loop just starts to oscillate, read off the period, and derive KpK_p, KiK_i, KdK_d from it — that are still taught and used today.
  • The overshoot/speed trade-off is fundamental, not a tuning mistake: for a fixed plant, no single choice of gains simultaneously minimizes settle time, overshoot and sensor-noise amplification. You are always choosing a point on a genuine trade-off curve, the same shape of compromise that shows up in controllability and observability once you leave hand-tuning for full state-space design.

So the "complexity" of PID is not computational in the P-vs-NP sense — it's analytic: a small, exactly solvable stability theory sitting underneath a controller almost anyone can implement in ten lines of code.

Where It Matters

Once you know what to look for, PID loops are everywhere a system needs to hold a target despite disturbances it cannot predict:

  • Home and industrial temperature control: thermostats, ovens and furnaces adjust heating power based on how far the reading is from the setpoint.
  • Robotics and drones: motor speed, joint angle and hover altitude are all PID loops running hundreds of times per second, often nested inside each other.
  • Automotive systems: cruise control, and the anti-lock braking and traction-control loops underneath it, are classic PID (or close variants).
  • Process industries: chemical plants, water treatment and power generation use thousands of PID loops to hold pressure, flow and level steady — control-room screens are largely dashboards of these loops.

It's also the natural bridge into deeper control theory: once a single loop isn't enough, engineers reach for full state-space models and multi-input controllers, but the same feedback idea — measure the error, correct proportionally, remember the past, anticipate the future — never goes away.

Conclusion

PID control is proof that you don't need to understand a system to control it well — you just need to watch its error and react to where that error is, where it's been, and where it's headed. The formula fits on a napkin; picking the three numbers that make it fast, smooth and stable is where the real engineering lives.

Next time your thermostat settles quietly at exactly the right temperature instead of swinging past it and back, that's not luck — it's someone's tuned KpK_p, KiK_i and KdK_d doing exactly what they were built to do.

Share this article

Pick a channel — or use your device's native share sheet.

Comments

Loading comments...

https://www.kipuhub.com/en/article/pid-control/Content licensed under CC BY-NC 4.0.