← Back to Write-ups
Which Controller Should You Use?
By David Nash ·
Total Sparks: 0
Enjoyed this write-up? Charge it with sparks
An interactive version of the decision tree I use when a new control problem lands on my desk. Follow it down to one of ten recommendations, each with why it fits, where it tends to break, what it costs you to build, and a few places you'd really see it used.
Click any box in the diagram to pull up its full explanation right there, without losing your place in the tree. Drag to pan, scroll or pinch to zoom. Or skip the diagram entirely and click your way through the same tree as a plain list below.
Walk It As A List
Same as the diagram above, just as a step-through menu, pick an answer at each step and keep going.
Is the system single-loop, or genuinely coupled across multiple inputs?
Other axes on the machine don't automatically make it MIMO. What matters is whether they meaningfully interact with the one you're controlling. Underactuated systems (fewer actuators than degrees of freedom, like an inverted pendulum) count as coupled.
SISO — one loop, decoupled from the rest of the machine Do you have an explicit dynamic model you trust?
An equation of motion or transfer function you already trust enough to design against.
No — empirical data only Recommendation: Classical PID (with feedforward)
Classical PID (with feedforward)
The default for a reason: something like 90% of industry control loops are exactly this.
- Why this one
- You don't have a model, so you're tuning by watching the response; nobody's computing gains from first principles here. PID is the controller every tuning heuristic targets, Ziegler-Nichols and relay tuning chief among them. It's one loop, three terms, and every commercial control system already knows how to run it. Adding a feedforward term, one that reacts to the setpoint or a known disturbance directly instead of only the error, usually buys most of the improvement people reach for exotic controllers to get.
- Where it breaks
- It has no notion of states it can't measure, so anything genuinely coupled to another loop will fight your tuning instead of resolving it. Large delay or strong nonlinearity, stiction or backlash, shows up as oscillation you can't tune out, or sluggishness you're leaving on the table.
- What it costs you
- Nothing to build up front, but no guarantees. You verify stability empirically on the real hardware; the math doesn't promise it in advance. Retuning is manual work every time the plant changes.
- Where this shows up
- A 3D printer's hotend or bed temperature loop
- A wheeled robot's wheel-speed or motor-current loop
- A drone's individual motor RPM controller, underneath the outer attitude loop
Yes — I have a trustworthy model Do you need precise frequency-domain shaping or explicit pole/zero placement?
A named bandwidth, phase margin, or a specific pole you need to relocate: a number you could hand to a test engineer.
Yes — the spec is stated in frequency-domain terms Recommendation: Lead-Lag Compensator / Root Locus
Lead-Lag Compensator / Root Locus
For when the spec is stated in the frequency domain and a generic PID won't hit it precisely.
- Why this one
- You have a model, and the requirement is frequency-domain language: a bandwidth, a phase margin, a specific pole you need to relocate. Lead-lag compensation and root-locus design let you place closed-loop poles and shape the frequency response directly, which PID's three generic terms don't give you precise control over.
- Where it breaks
- It's still a SISO, linear technique. The moment you're fighting real coupling between loops, or the plant moves outside the region the linear model was fit to, the pole placement you designed stops meaning what you designed it to mean.
- What it costs you
- More design time than PID: Bode or root-locus work in a tool, or by hand, instead of turning three knobs on a bench. It pays off in a controller whose margins you can certify on paper, something a step response alone can't give you.
- Where this shows up
- A disk-drive read/write head servo, where the bandwidth spec is handed to you in Hz
- An analog op-amp control loop designed straight off a Bode plot
- Retrofitting a legacy SISO loop where the plant transfer function is already characterized on paper
No — I just want the response tightened up Recommendation: Model-Tuned PID / Internal Model Control
Model-Tuned PID / Internal Model Control
Same three-term controller, but the gains come from the model instead of trial and error.
- Why this one
- You have a model but don't need frequency-domain precision. Internal Model Control, or a model-based PID tuning rule, computes gains directly from the model's time constants instead of hand-tuning by trial and error. It's faster to get right, on the exact same three-term controller everyone already knows how to run.
- Where it breaks
- The same ceiling as plain PID once you hit it: no real handling of hard constraints, and accuracy degrades as the real plant drifts from the model you tuned against.
- What it costs you
- Cheap. You already have the model, so this is arithmetic on top of it, not new machinery. Worth revisiting the tuning any time the model gets re-identified.
- Where this shows up
- A motor speed loop where you've identified the electrical and mechanical time constants
- A thermal loop with a first-order-plus-dead-time model from a step test
- Re-tuning a PID after a system-identification pass instead of by hand
MIMO — coupled, or underactuated Does the machine stay near one operating point, or move through large excursions?
Small deviations around a single point (a hovering drone, a balanced pendulum) can be linearized. A full swing-up or a trajectory that visits very different configurations usually can't be, honestly.
Localized — small deviations around one point Are there hard constraints you need respected exactly?
An actuator saturation limit, a rail that ends, a state you're not allowed to leave. It has to hold every single time.
Yes — hard input or state constraints Recommendation: Linear Model Predictive Control (MPC)
Linear Model Predictive Control (MPC)
The one controller on this list that puts hard constraints directly into the optimization.
- Why this one
- You're near one operating point, coupled across axes, and the limits are hard: a torque ceiling, a travel limit, a state the machine can't be allowed into. Those have to hold exactly, every cycle, and linear MPC is the standard answer because it builds them straight into the optimization; a controller that merely hopes to honor them isn't good enough.
- Where it breaks
- The optimization runs online, every tick, which means your control loop now has a solve-time budget to hit. Push the horizon out, or the constraint set up, and you can blow that budget before you blow the model's small-signal validity.
- What it costs you
- Real implementation cost: a QP solver in the loop, and tuning of the prediction horizon, control horizon, and weight matrices.
- Where this shows up
- A robot arm respecting joint torque and travel limits while tracking a path
- Adaptive cruise control that must never violate a following-distance limit
- A battery charger that can't exceed a current or temperature ceiling
No meaningful hard constraints Is the model uncertain, or are disturbances severe?
This means real uncertainty: mass, friction, or disturbances you can't pin down, or a machine that gets hit hard and often.
Yes — significant uncertainty or disturbance Recommendation: Sliding Mode Control / H-Infinity
Sliding Mode Control / H-Infinity
Assumes the model is wrong within bounds, and designs for the bounds.
- Why this one
- No hard constraints to enforce directly, but the model itself isn't trustworthy enough: mass, friction, or disturbance uncertain enough that a controller tuned to the nominal model would drift or fail against the real one. Sliding mode and H-infinity are both explicitly designed against a range of plants; LQR is designed against a single exact one.
- Where it breaks
- Sliding mode's robustness comes from a discontinuous switching term, which in practice chatters against real actuators and unmodeled high-frequency dynamics unless you smooth it, and smoothing it gives some of the robustness back. H-infinity's guarantees are only as good as the uncertainty bound you designed against.
- What it costs you
- Meaningfully harder to design and tune than LQR. You're now choosing an uncertainty model, not a cost function. Reach for this once you've confirmed LQR fails against your real plant, not because it sounds more rigorous.
- Where this shows up
- A manipulator handling an unknown or changing payload mass
- A marine vessel controller designed against wave disturbances that are hard to model precisely
- An aircraft controller that must stay stable across a range of airspeeds and CG positions
No — the model is reasonably trustworthy Recommendation: Linear Quadratic Regulator (LQR)
Linear Quadratic Regulator (LQR)
Globally optimal state feedback, computed once, offline, from a linearized model.
- Why this one
- Coupled system, close to one operating point, no hard constraints to enforce exactly, and reasonable confidence in the model. This is the textbook case for LQR: it converts an accuracy-versus-effort tradeoff, the Q and R matrices, into globally optimal state feedback gains, solved once from the linearized model.
- Where it breaks
- The guarantees are only as good as the linearization. Push the state far enough from the operating point and the gains that were optimal near it stop being anywhere close to optimal, or even stabilizing.
- What it costs you
- One offline Riccati solve, then it's a matrix multiply at runtime, about as cheap as a real optimal controller gets.
- Where this shows up
- A hovering multirotor holding altitude and attitude near setpoint
- A two-wheeled balancing robot near its upright equilibrium
- The balance phase of this site's own double-pendulum write-up, catching the swing-up at the top
Global — large, genuinely nonlinear motion Do you have an accurate first-principles model of the full nonlinear system?
This means the full nonlinear equations of motion, valid everywhere the system goes.
Yes — a trustworthy nonlinear model Do you need to replan online while respecting strict limits, rather than commit to one offline plan?
"Online" means recomputed every tick, from wherever the machine is right now.
Yes — replan online, under strict limits Recommendation: Nonlinear Model Predictive Control (NMPC)
Nonlinear Model Predictive Control (NMPC)
Every tick, it re-solves the real trajectory problem from wherever the system currently is.
- Why this one
- Global, highly nonlinear motion, a first-principles model you trust, and constraints that have to hold while the system is still moving, mid-swing or mid-turn, the same as they would at rest. NMPC re-solves the actual, non-linearized trajectory optimization from wherever the machine currently is, every tick. It's simultaneously your planner and your constraint handler.
- Where it breaks
- This is the most expensive controller on this list to run in real time. Miss your solve-time budget and the plant gets fed a stale plan instead of a gracefully degraded one. Most of the engineering effort in an NMPC project goes into making the solve fast and well warm-started; the control theory itself is the easy part.
- What it costs you
- High: a nonlinear solver in a hard real-time loop, careful warm-starting, and a cost function that has to encode the objective and every constraint at once.
- Where this shows up
- A legged robot replanning footsteps mid-stride around obstacles
- An autonomous vehicle re-planning its trajectory every control cycle around moving traffic
- This site's own NMPC write-up, replanning a pendulum's full swing-up from scratch, live, at 200Hz
No — a single well-designed controller is enough Recommendation: Feedback Linearization / Backstepping / Lyapunov-Based Control
Feedback Linearization / Backstepping / Lyapunov-Based Control
A stabilizing controller derived analytically, with the proof built in.
- Why this one
- Global nonlinear motion with a trusted first-principles model, but without the need for NMPC's online replanning and constraint handling. Feedback linearization cancels the nonlinearity algebraically and controls what's left with linear tools; backstepping and Lyapunov-based design build a stabilizing controller directly from an energy-like function, with the stability proof falling straight out of the construction.
- Where it breaks
- Feedback linearization needs the model to be exactly, or very nearly, right. It's canceling terms it computed from that model, so model error shows up directly as uncancelled dynamics. None of these handle hard state or input constraints natively; if one shows up later, you're back to MPC.
- What it costs you
- Design effort is mostly analytical: working through the algebra, or choosing a Lyapunov candidate, rather than computational. Once designed, it typically runs as cheaply as any linear controller.
- Where this shows up
- A robot arm's computed-torque control, canceling known joint dynamics directly
- A quadrotor attitude controller built via backstepping on the rigid-body equations
- An underwater vehicle depth controller derived from a Lyapunov energy function
No — the true dynamics aren't well known Can you run large-scale training simulation, or gather a large real-world dataset?
Hours to days of simulated experience, or a real fleet logging enough trials to learn from.
Yes — simulation or data at scale is available Recommendation: Reinforcement Learning / Data-Driven Control
Reinforcement Learning / Data-Driven Control
Learns the equivalent of a model implicitly, through simulated or real experience.
- Why this one
- No trustworthy first-principles model, but enough simulation or real-world data to learn from. Reinforcement learning doesn't need the dynamics written down. It needs a simulator or enough logged trials, plus a reward function, and it discovers a policy by trial and error at scale.
- Where it breaks
- The policy is only as good as the distribution it trained on, and it doesn't explain why it did something. It works well as a fallback when no model is available and simulation is cheap, though it's a poor substitute for one you could have written down.
- What it costs you
- The most upfront-expensive option here: hours to days of training compute, reward shaping that usually takes several iterations to get right, and typically a sim-to-real gap you still have to close afterward. Cheap to run once trained; expensive to arrive there.
- Where this shows up
- A legged robot's locomotion policy trained in simulation across millions of steps, then transferred to hardware
- A dexterous manipulation policy learned from teleoperated demonstrations plus RL fine-tuning
- A warehouse robot's navigation policy trained against a large logged fleet dataset
No — neither is practical here Recommendation: Adaptive Control / Fuzzy Logic / Neural Control
Adaptive Control / Fuzzy Logic / Neural Control
Learns on the fly, updating its estimate of what it doesn't know as the system runs.
- Why this one
- No trustworthy model, and no practical way to run the large-scale simulation or data collection RL needs. Adaptive control estimates the unknown parameters online, while it's running, and updates the controller as its estimate improves; fuzzy and neural controllers substitute a learned or rule-based mapping for the model you don't have, updated from whatever data you can get in real time.
- Where it breaks
- Adaptation takes time to converge, and during that window performance is only as good as the initial guess, a rough place to be near a real machine that can be damaged. None of these carry LQR or MPC's clean stability guarantees; you're leaning on empirical tuning and monitoring more than proof.
- What it costs you
- Lower upfront cost than RL, since there's no offline training phase, but usually more ongoing engineering: monitoring the adaptation and guarding against it wandering somewhere unsafe.
- Where this shows up
- A robot picking up objects of unknown, varying mass with an online mass estimator
- A ship's autopilot adapting its gains as it burns fuel and handling changes
- A fuzzy-logic controller for a process with no clean equations but a lot of operator intuition to encode
This tree covers stabilization and regulation problems. It assumes you already know what state you want the system to hold or track. Two of the ten answers, LQR and NMPC, are worked through end to end in the double pendulum write-ups. If your system doesn't fit cleanly into any of these ten boxes, that's usually a sign it's worth talking it through.