The problem PID solves
Many machines need to hold something at a target: a motor at a steady speed, a robot upright, a heater at a set temperature. The controller measures the actual value, compares it with the target, and decides how hard to push. The difference between target and actual is called the error. PID control is a very common recipe for turning that error into a sensible push, and it takes its name from its three parts: proportional, integral and derivative.
You do not need equations to understand them. You need only the picture of someone correcting a mistake over time.
Proportional: react to how wrong you are now
Imagine steering a car back toward the middle of a lane. If you are far off, you turn the wheel firmly. If you are slightly off, you turn gently. That is proportional correction: the push is in proportion to the current error.
It works well, with limits:
- Too little and the correction is lazy. The system takes a long time to reach the target and may never quite get there.
- Too much and it overshoots, then overcorrects the other way, swinging back and forth.
- A steady shortfall can remain. If a motor needs a constant push to overcome friction or a heavy arm needs constant effort against gravity, the proportional part alone may settle slightly off target, because as the error shrinks so does the push, until the push is only just enough to hold a small leftover error.
A proportional-only controller is often a decent starting point, and the line follower that steers harder the farther it drifts is a simple example.
Integral: remember the past
Return to the shower. The water is a bit cooler than you want. You turn the tap a little, but the water is still slightly cool, so you keep nudging it until it is right. The longer the shortfall lasts, the more you add. That is the integral part: it adds up the error over time, so a small error that persists gradually builds into a bigger push.
This is what removes the steady shortfall left by the proportional part. When the system finally sits exactly on target, the accumulated push is just what is needed to hold it there.
The risks:
- Windup. If the output is stuck, for example a motor already at full power but still far from the target, the accumulated total keeps growing. When the situation finally changes, that huge stored value causes a large overshoot. Controllers usually cap the accumulated amount to prevent this.
- Slow oscillation. Too much integral action makes the system swing slowly around the target.
- Not always needed. Plenty of small robots work well with only the other two parts.
Derivative: anticipate where things are heading
Think of braking a car toward a stop sign. You do not wait until you have reached the line to brake. You ease off earlier because you can see how quickly you are closing in. That is the derivative part: it looks at how fast the error is changing and pushes against rapid movement, acting as a damper.
It helps in two ways:
- It reduces overshoot, since a fast approach to the target leads to an early easing off.
- It calms oscillation.
But there are costs:
- It amplifies noise. A jittery sensor makes the rate of change look wild, and the derivative term reacts to that jitter. Light filtering of the sensor reading is a common fix.
- It is sensitive to timing. A loop that runs at irregular intervals gives uneven rate estimates.
- Too much leads to a twitchy, buzzing output.
Putting the three together
The controller adds the three pushes together. Each part has a gain, a number that sets how strongly it counts. Roughly:
| Part | Looks at | Helps with | Overdone causes |
|---|---|---|---|
| Proportional | Current error | Speed of response | Overshoot, oscillation |
| Integral | Error over time | Steady leftover error | Windup, slow swinging |
| Derivative | Rate of change | Overshoot, damping | Noise sensitivity, twitching |
A sensible tuning approach
Tuning means choosing the three gains. There are formal methods, but a cautious hands-on routine is common:
- Start with all gains at zero and make sure the machine is safe to test, with the load secured and a way to cut power.
- Raise the proportional gain until the system responds briskly. Go no further than where it starts to oscillate noticeably, then back off a bit.
- Add derivative gradually to damp the overshoot, watching for jitter.
- Add a little integral only if a steady error remains, and keep it small.
- Test with real disturbances, such as a push, a change of load or a low battery, because a controller tuned only on a bench can behave differently in use.
Change one gain at a time and record what happens; clear gain names in the code help, as does some automated testing of any filtering. This is a good example of a patient debugging strategy. The right values depend on the specific motor, load, sensor and loop speed, so numbers copied from another project are only a starting point.
Where PID shows up in hobby builds
- Motor speed, using an encoder to measure actual speed.
- Balancing robots, where inertial sensors supply the tilt and the controller pushes the wheels to keep it upright.
- Line following, where the error is the line’s offset from centre.
- Temperature control, for example a heated bed or a small oven.
- Drone stabilisation, as in DIY drone builds, where several loops run together. Drones carry real safety and legal considerations, so follow manufacturer guidance and the rules where you fly.
Things PID does not do
PID needs a trustworthy measurement. Noisy or delayed sensors limit what any tuning can achieve. It also cannot fix mechanical problems such as a sloppy gearbox with backlash, or a motor that is too weak for the job. And it is a means of staying on target, not a safety system: if a loop misbehaves, the machine still needs an independent way to cut power. Tuning, like all hands-on robotics, is partly experiment, and results vary between builds.