Introduction to Control Systems

Tell a motor to rotate to 90 degrees.

You work out how much voltage it needs and for how long, you send the command, and you cut the power at what should be exactly the right moment.

It stops at 84.

So you nudge the voltage up and try again. This time it stops at 96.

There's nothing wrong with your math. The problem is that at no point did you check where the shaft actually was. You made a prediction about the physical world and then committed to it. The bearing had a bit more drag, the supply sagged under load. None of that was in your calculation, and nothing was watching.

Now put a sensor on the shaft and let the controller read it while the motor is still turning. You're no longer predicting. You're reacting, continuously, to what's actually happening. You can be wrong and still recover.

This series is about understanding, designing, and eventually writing a control loop yourself. We'll work through the major control techniques, the vocabulary, and the tools you'll need. No controls background needed, just enough curiosity and willingness to learn control theory.

This first post has no math in it. By the end you'll be able to read a control block diagram end to end, tell open loop from closed loop, linear from nonlinear system, and understand why feedback alone can take something that wants to fall over and hold it upright.

1. Why learn control now?

Robotics is moving faster than ever.

Tesla's Optimus robots are learning everyday tasks. Figure's Helix humanoid robot loads a dishwasher on camera. Unitree sells a human-sized robot for less than a used car. Zipline's drones are delivering food and groceries across multiple cities.

A walking robot and a hovering drone have the same two jobs to do. From the outside those jobs look like one. The first is deciding what to do: work out where the foot should land, or which way the wind just pushed you. Deep learning has done the heavy lifting there. The second is making that decision real: turning "put the foot there, now" into a foot that actually gets there, through a body with friction, flex, and delay, driven by motors that never pull quite as hard as commanded. That's control.

Getting a robot to do something impressive once is a good afternoon. Getting it to do the same thing ten thousand times, on a cold morning, with a worn bearing, environmental disturbances, and noisy sensors that have drifted since calibration, is control engineering.

2. Control is everywhere you look, and everywhere you don't

Control loops are all around you. Some are easy to spot. Others are hiding in places you'd never think to check.

Control shows up in nearly every branch of engineering, usually uncredited.

Cooking is control: you taste, adjust the heat, taste again.

Riding a bicycle is control, with your inner ear sensing tilt and your hands steering to correct it.

Walking is a controlled fall, where every step tips your body forward on purpose and then catches it.

What we will teach in this series is give you the math behind things you already do by instinct, and then show you how to make a machine do them faster and more precisely than you can.

3. What is a system?

Before we can talk about controlling a system, we need to be clear about what "system" means.

A system is anything that takes inputs and produces outputs. That's the whole definition.

A car is a system: you give it a gas pedal, a brake, and a steering wheel, and you get back speed and position.

A room with a heater in it is a system, taking heater power in and giving temperature out.

Even a bank account qualifies, with deposits in and balance out.

A system reduced to a box: what you can change, what you can measure, and what the world does to it anyway.

Three things go on that diagram.

The inputs, written u(t), are the things you're allowed to change: a voltage, a force, a throttle opening.

The outputs, y(t), are the things you can measure: a position, a temperature, a speed.

And then there are disturbances, d(t), which are things the world does to your system that you never asked for. Wind. Friction. A hill. Someone loading luggage into the trunk.

That third one deserves more credit than it usually gets. If disturbances didn't exist, and if our models were perfect, this field would be a much shorter course. Most of what makes control hard is the gap between the system you designed for and the system you actually got.

Systems come in two flavors, and it's worth learning to tell them apart early.

• A static system has no memory. Its output right now depends only on its input right now. A bathroom scale is static: you step on, it reads your weight, you step off, and it remembers nothing about it.
• A dynamic system has memory. Its output depends on the history of its inputs, not just the current one. A pot of water on a stove is dynamic, because how hot it is right now depends on how long the burner's been running. If you're looking at the math and you see a derivative anywhere, a rate of change, you're looking at a dynamic system.

This series is about dynamic systems. Static ones are easy, since you just invert the input-output relationship and you're done. Anything that moves, heats up, spins, swings, or takes time to respond is dynamic, which covers essentially everything worth controlling.

4. What is a control system?

A control system measures what's happening, compares it to what you want, and adjusts itself to close the gap.

Strictly speaking that's the definition of feedback control, sometimes called closed-loop control.

There's also open-loop control, which skips the measuring entirely, and we'll draw that line properly in the next section. But sense, compare, adjust is the idea that matters, and it's worth internalizing now.

You already do this all day without thinking about it.

• Take a shower. You feel the water temperature, compare it to what you want, twist the knob, feel again, twist again. You just closed a control loop about once every two seconds. Your skin was the sensor, your hand was the actuator, your brain was the controller.
• Drive on a straight road. You see the lane lines, compare them to where your wheels are, correct the steering, and repeat a few times a second for hours. Your brain solves that problem so effortlessly that taking it out of human hands has consumed two decades of engineering so far.
• Reach for a coffee cup with your eyes open. Your hand doesn't fly straight at it. It curves, slows near the end, and makes small corrections the whole way. That's a closed-loop trajectory controller.

Control systems aren't an invention of 21st-century robotics. They're how anything that does something purposeful in the physical world manages to keep doing it. What changed over the last sixty years is that we learned to build them out of silicon instead of muscle, and to run them far faster than any human can.

5. Open loop versus closed loop

Open loop means acting without checking. You do the thing and hope. Your microwave is a good example: you ask for two minutes, it gives you two minutes, and it has no idea whether the food inside is frozen solid or already hot. The controller decides what to do based only on what you asked for, and it never looks at the result.

Open loop: the command goes out, and nothing comes back.

People use open loop because it's cheap and simple. No sensor, no feedback wiring, no risk of the loop misbehaving. When you genuinely know what's going to happen, it works fine.

It breaks for three reasons, and they're the reasons the motor at the top of this post landed at 84 degrees.

First, your model of the system is always a little off, so errors creep in and nothing ever removes them. Second, unexpected things happen, and the controller can't even see them, because it isn't watching the output at all. Third, if the system is unstable to begin with — a pencil balanced on its tip, say — no pre-planned sequence of inputs will save it, because the smallest error grows on its own.

Open loop is simpler and breaks when anything unexpected happens.

Closed loop means measuring what actually happened and changing what you're doing based on what you saw.

Closed loop: the sensor's reading finds its way back to the front of the loop, where it changes the next command.

Let's put a car on this, because we're going to keep the car for the rest of the post.

Set the throttle to a fixed opening on a flat road and you'll settle at, say, 60 mph. That's open loop, and it works right up until the road changes. Hit a hill and you slow down, because the throttle doesn't know about the hill. Pick up a headwind and you slow down again. Load four passengers and luggage into the car and you'll never see 60 mph on that same throttle setting.

Now switch on cruise control. It reads the speedometer, sees 55 mph when you asked for 60 mph, and opens the throttle a little more. On the hill it opens further. On the way down it backs off. It doesn't know the hill exists, it doesn't know how heavy your car is, and it doesn't need to. It only knows the gap between what you wanted and what it's got, and it keeps working to shrink it.

Closed loop is more work and handles surprises. Since the real world is mostly surprises, nearly everything interesting is closed loop.

6. What kind of system are you dealing with?

Two questions come up about any system before you design anything for it.

The first is whether the system is linear. A system is linear if doubling the input doubles the output, and if combining two inputs gives you the sum of their separate results. A spring is the classic example: pull with one newton and it stretches a centimeter, pull with two and it stretches two. Everything scales neatly, nothing surprises you.

Nonlinear just means that neat scaling breaks down somewhere.

The three curves below show a linear system next to the two nonlinearities you'll meet most often.

Linear, saturation, and hysteresis — the straight line and the two ways it stops being straight.

The first is that ideal spring, a straight line through the center. Double the input, the output doubles. Reverse the input, the output reverses by the same amount. This is the easy case, and it's the one where the clean math works.

The second is saturation, and your car has it. The line is straight in the middle and then flattens out at the top and bottom. Ask the engine for a little more and you get it, but past a certain point the throttle is wide open and there's nothing left to give, no matter what the controller asks for. On a steep enough hill, cruise control will floor it and still lose speed. The controller is still calculating a sensible command, and the car simply can't deliver it.

The third is hysteresis, and it's the least intuitive of the three. Here the output depends not only on the current input but on which direction you arrived from, so the path going up differs from the path coming down and the curve forms a loop. Your car has this too. There's a small amount of slop between the gear teeth in the drivetrain, so when you go from accelerating to coasting, the parts have to travel across that gap before anything happens on the other side. That's the clunk you feel on a rough shift. Engineers call the gap backlash, and it makes precise control genuinely hard because for a moment your commands do nothing at all.

The second question is whether the system is time-invariant, meaning it behaves the same no matter when you use it. Run the same test on Monday and Friday and you get the same answer. A pendulum is time-invariant, since its physics doesn't care what day it is.

Time-varying systems change underneath you while you're controlling them. A rocket burns fuel and gets lighter, so the same thrust buys more acceleration later in the flight than it did at liftoff. A flashlight does the same thing on a much smaller scale. Flip the switch with a fresh battery and you get a bright beam. Flip the same switch, the same way, after hours of use, and the beam is dim. The switch didn't change. The battery behind it did.

When a system is both linear and time-invariant, we call it LTI, and you'll see that abbreviation constantly. LTI systems are the ones we understand completely, with a full and mature theory behind them. Most of what we do in practice is find a way to treat a messy real system as approximately LTI over the range we care about, then stay alert for where that approximation stops being true.

7. The anatomy of a control loop

Every control loop you'll ever meet is a variation on this diagram.

Every part of a control loop has a name. This is the diagram the rest of the series keeps redrawing.

Here it is walked through with your car's cruise control:

• Reference (r) — what you want. "Hold 60 mph."
• Sensor — how you find out what's actually happening. The speedometer.
• Output (y) — what the sensor reports, and the variable you're really controlling. "55 mph right now."
• Error (e = r − y) — the gap between them. You're 5 mph short.
• Controller — the brain. It takes the error and decides what to do about it. The cruise-control computer.
• Command (u) — what the controller sends out. "Open the throttle a bit more."
• Actuator — the muscle. It turns the command into physical action. The throttle body and the engine.
• Plant (P) — the thing being controlled. The car. (Odd word, but it's universal. It comes from process control, where the thing being controlled really was a chemical plant.)
• Disturbance (d) — a push from the outside world that nobody asked for. A headwind, a hill, luggage in the trunk.
• Noise (n) — junk sitting on top of your measurement. Speedometer jitter.
• Feedback path — the wire carrying the measurement back to the summing junction, where it gets subtracted from the reference to form the error.

One distinction here catches people out, so it's worth stating plainly: disturbance and noise are not the same thing.

A disturbance is real. The hill genuinely slowed the car down.

Noise is a lie, where the speedometer says you slowed down and you didn't. They may look similar in your data but they need completely different fixes.

Good controllers fight disturbances.

Good filters handle noise.

8. Why feedback works so well, and where it bites

Feedback does three things that nothing else in engineering quite manages.

It rejects disturbances you never modeled. Cruise control has no idea what a hill is. Nobody programmed hills into it, nobody told it your car's mass or the rolling resistance of your tires or which way the wind is blowing. It sees the speed drop and opens the throttle. The disturbance doesn't need a name for the loop to fight it.

It tolerates a wrong model of the plant. That same controller works in a loaded car and an empty one, on new tires and worn ones, at sea level and in the mountains. As long as the loop keeps closing the gap, it forgives an enormous amount of what it doesn't know. That forgiveness has limits, but the tolerance is real and it's the reason feedback is worth the trouble.

And it can make an unstable system stable. Put a pencil on a table and it falls over instantly. Balance it on your fingertip with your eyes open and it stays up. The pencil didn't change. What changed is that your eyes see it tilt, your brain works out which way to move, and your hand gets there in time. Feedback took something that wants to fall over and held it upright.

The pencil falling is one flavor of a bigger idea: equilibrium. It's worth seeing where that resting state sits among its neighbors. A ball at the bottom of a bowl is stable: knock it sideways and it rolls back down. A ball balanced on top of a hill is unstable, exactly like the pencil: knock it and it's gone, and the disturbance keeps growing on its own. A ball on a flat table is marginally stable: knock it and it just rolls to a new spot and stays there, neither returning nor running away.

A ball in a bowl returns. A ball on a hill runs away. A ball on a flat table just sits wherever you left it.

Now the other side, because feedback has failure modes and they're every bit as characteristic.

Correct too hard and the system wobbles. You overshoot the target, then overcorrect coming back, then overcorrect again, and the swings grow instead of shrinking. Some older cruise controls hunt like this on rolling hills, surging and backing off and never quite settling.

If your sensor or your actuator is slow, you're always responding to a picture of the past, and your system has a delay. The heater already caught up by the time the controller reads "too cold," so it keeps heating into a room that's now too warm. Anyone who's fought a shower with a long pipe run knows exactly this feeling.

And noise gets amplified. An aggressive controller chases every meaningless wiggle in the sensor data, working the actuator hard for nothing, wearing out hardware, and sometimes destabilizing a loop that was perfectly fine.

All three of those can come out of the same controller, tuned differently. There's one knob in the simplest possible controller, and turning it walks you from sluggish, through good, into ringing, and out the other side into instability, with no warning at the boundary.

9. A few more terms you'll run into

SISO and MIMO describe how many signals are involved. SISO is single input, single output, like a shower with one knob and one temperature. MIMO is multiple inputs and multiple outputs, like a drone using four motors to influence six degrees of freedom, where the motors are coupled — you can't move sideways without tilting to do it, and every motor affects everything.

Continuous and discrete time describe when the controller is awake. The physical world is continuous, since time never stops. A digital controller is discrete, waking up every few milliseconds, reading the sensor, computing, and going back to sleep. If it wakes up fast enough relative to the system it's controlling, you can design as though it were continuous and get away with it.

Model-based and model-free describe where the controller's knowledge comes from. A model-based design uses a mathematical description of the system to work out what to do. A model-free approach skips the model and finds a controller through trial and error instead.

There's one thing true of every model you'll ever write down. As the statistician George Box put it:

"All models are wrong, some are useful."

Whatever mathematical description you write down is a simplified picture. It leaves out friction, flex, loose bolts, sensors that drift with temperature. So every serious design asks a second question after "does this work?" It asks how wrong the model can be before the controller stops working. That question is called robustness, and it's the difference between a controller that works on your desk and one that works in the field.

There's a more basic question sitting underneath that one:

How complex should my model be?

A model isn't judged by how much of the real system it captures, it's judged by whether it captures the right part, the handful of effects that genuinely shape the behavior you're trying to control. Everything else is detail you're better off leaving out.

Take cruise control again. What decides how fast the car speeds up or slows down is basically three things: the car's mass, the engine's torque, and the slope of the road. The engine's cylinder-by-cylinder combustion timing is real, and physically it does affect torque moment to moment, but none of that detail changes how the car responds to the throttle over the second-by-second timescale cruise control operates on. A model that ignores it still tells the truth about the car's speed. That's the essential dynamics: the smallest set of effects you can keep and still have a model that's honest about what you care about.

10. To sum up

• A system just takes inputs and gives outputs, and the world pushes on it with disturbances you never asked for.
• Open loop acts and hopes. Closed loop measures, compares, and corrects.
• Linear systems scale predictably; nonlinear ones saturate or lag behind themselves.
• Every control loop shares the same anatomy: reference, error, controller, actuator, plant, sensor, feedback path.
• Feedback rejects disturbances it never modeled, forgives a wrong model of the plant, and can hold up something that wants to fall over.
• Push it too hard and you get wobble; wait too long and you get delay; listen too closely and you amplify noise.
• Every model is wrong, so the real skill is knowing what to leave in, and how wrong you can afford to be.

If you found this useful, subscribe — next week we build an open loop controller and watch it fail.