Control Engineering Primer: PID Control — Working Across Three Time Scales

Contents — find the section you need

Background and reading guide

Background Basic functions, calculus and vectors; follow the definitions alongside the equations.

Fundamentals · Explanations of principles, structure and trade-offs.

PID (proportional–integral–derivative) control changes an input after comparing a reference with a measurement. It is used in heaters, drives, flow loops, robot joints, and aircraft because it can work well without a perfect plant model. Its apparent simplicity is deceptive: a controller that has no stated units, output limit, timing policy, sensor validation, or safe-stop path is not a deployable controller. It is an equation waiting to fail.

This article starts with the practical conclusion, then builds intuition, the signal flow and equations, Ziegler–Nichols tuning, constraints and safety, and current software examples. For the node, timing, and hardware boundaries around a robot controller, see ROS 2 Primer. For why localization delay and jumps are control problems too, see Visual SLAM Primer.

The PID input is the error $e=r-y$ , and its output is the command $u$ . P reacts to the present error, I removes persistent offset, and D adds damping from the rate of change.

The short conclusion

P responds to the error now; I removes error that has persisted; D supplies damping from the rate of change. Start with P, engineer the limits, add I only when a steady offset remains, and add filtered D only when it has a clear purpose.
The implementation must bound both command and command rate. Saturation without anti-windup makes an integrator store a demand the actuator cannot deliver.
Differentiate a filtered measurement in most physical systems, rather than differentiating a step-like reference error. It avoids derivative kick and reduces sensitivity to reference changes.
PID is often the best solution for a single fast loop with modest delay. More advanced optimization does not remove the need for a fast, observable, safe inner loop.

Intuition: three operators watching one error

Suppose room temperature is below its reference. The P operator says, “it is five degrees low now, so apply heat now.” The I operator says, “it has remained low for a long time, so the baseline heat is inadequate.” The D operator says, “temperature is already rising rapidly; ease off before it overshoots.” Their sum can give a quick response, rejection of a constant heat loss, and less overshoot.

The analogy omits the facts that determine whether the loop is safe: heater power is finite, a thermometer is noisy, and heat takes time to travel. A derivative can mistake noise for motion; an integrator can keep accumulating while the heater is already saturated. PID design therefore begins with what is measured and what can safely be commanded—not with gain values.

Signal flow: the controller is only one block

Diagram: Duskcoil, conceptual rather than a measured wiring diagram. Calibration, transport delay, communications, and actuator inner loops belong to the real signal path.

If the plant is $G$ and the sensor or estimator is $H$ , making only the controller $C$ more capable does not remove delay, saturation, or faults in $G$ and $H$ . For example, when a mobile robot uses SLAM localization for tracking, jumps and latency in the estimate appear to the PID as measurement noise and disturbance. The coordinate frames, time synchronization, and relocalization discussed in Visual SLAM Primer are part of the control problem around the controller.

Basic equations and units

Let $r$ be reference, $y$ measurement, $e=r-y$ , and $u_{ff}$ the feedforward command. Parallel continuous PID is

u(t)=u_{ff}(t)+K_Pe(t)+K_I\int_0^t e(\tau)d\tau+K_D\frac{d e(t)}{dt}

$K_P$ has units of $u/e$ , $K_I$ has units of $u/(e\cdot s)$ , and $K_D$ has units of $u\cdot s/e$ . They are not inherently dimensionless. Changing degrees to radians, reversing an encoder, or mixing a millisecond timestamp with a seconds-based gain changes the loop. Record units, signs, frames, and reference update policy before tuning.

With sample period $T_s$ , a basic discrete implementation keeps the integral state $I_k$ and difference derivative $D_k$ :

I_k=I_{k-1}+T_s e_k,\qquad D_k=\frac{e_k-e_{k-1}}{T_s}

The controller then computes $u_k=K_Pe_k+K_II_k+K_DD_k$ . This form already exposes critical engineering questions: is $T_s$ measured or assumed; what happens when a message is late; what is done with a stale sample; and does the controller run at a deterministic rate? A common filtered derivative on measurement uses

the coefficient $\alpha=\tau_f/(\tau_f+T_s)$ and

D_k=\alpha D_{k-1}+(1-\alpha)\frac{y_{k-1}-y_k}{T_s}

It avoids derivative kick caused by a reference step. Its filter also adds phase delay, so filtering cannot compensate for a poorly sampled or mechanically loose system.

Understanding P, I, and D one at a time

Increasing P usually improves immediate response and disturbance rejection, until delay and plant dynamics turn it into overshoot or oscillation. I removes a constant offset such as gravity, friction, or heat loss, but too much I integrates demand before the plant has responded. D can provide damping but amplifies encoder quantization, vibration, and estimator jitter. In a position–velocity cascade, tune the fast, stable velocity loop first, then the position loop. Do not put every error into one slow PID.

Saturation and anti-windup

Physical commands obey $u_{min}\leq u\leq u_{max}$ . Let $u^*$ be the computed unsaturated command and $u=\operatorname{sat}(u^*)$ the command sent. If I continues accumulating while an actuator is pinned at a limit, the loop can remain pinned after the error reverses. This is integrator windup: the integrator keeps accumulating $e$ even though $u$ cannot follow it, and the integral state $I_k$ later delays recovery.

Conditional integration freezes the integrator when the output is saturated and the integral would drive farther into saturation. Back-calculation is a smoother alternative:

I_k=I_{k-1}+T_se_k+K_{aw}(u_k-u_k^*)

Here $I_k$ is the integrated error state, so $K_{aw}$ has units of error per command. Some implementations store $K_I I_k$ as the integral output and use $1/T_t$ (the inverse tracking time) instead; document the chosen units and equation. The saturation mismatch is fed back into the integrator. $K_{aw}$ sets the speed of that correction. Integrator clamps, reference ramps, and bumpless manual/automatic transfer are complementary measures. Anti-windup is not a performance embellishment; it makes recovery after an unavoidable limit predictable.

Symptom	Likely mechanism	Inspect first	Typical response
Slow response or offset	P too low, constant disturbance	signs, units, output limit	raise P gradually; add mild I if needed
Oscillation or overshoot	P/I too high, delay	loop period, delay, sensor trace	reduce P/I; use a reference ramp
Does not recover from a limit	integrator windup	command and integral logs	conditional I, clamp, back-calculation
Kick on a setpoint step	derivative of error	D input path	derivative on measurement
Chatter at low speed	friction, quantization, backlash	encoder and mechanics	inner velocity loop, compensation, filter

Tuning, including Ziegler–Nichols

The closed-loop Ziegler–Nichols procedure sets I and D to zero, raises P to a sustained-oscillation gain $K_u$ , measures period $T_u$ , then uses a classical PID starting point

K_P=0.6K_u,\quad T_i=0.5T_u,\quad T_d=0.125T_u,

where $K_I=K_P/T_i$ and $K_D=K_PT_d$ . Deliberately approaching sustained oscillation can be unacceptable on a thermal process, vehicle, pressure system, or robot near people. It is a historical heuristic, not permission to test at the stability boundary.

A safer workflow uses simulation or low-amplitude step tests to estimate static gain, delay, and time constant; enables limits and stop logic first; tunes P; adds I only to address an observed offset; then adds a filtered D only to address a measured damping need. Test reference tracking and disturbance rejection separately. Log peak current, temperature, speed, stopping distance, saturation time, and integral state for every change.

Constraints and safety live outside the PID equation

Do not make PID output the safety function. Use independent emergency stop, overcurrent/overtemperature/overpressure protection, travel limits, watchdogs, and a defined safe command when data or communication disappears. A controller tries to reach a reference; a safety function prevents entry into an unsafe state under fault assumptions that may include controller failure.

At minimum validate sample ranges, timestamps and freshness; limit references, acceleration, output and output slew; specify reset/hold behavior of the integrator; test manual takeover without a bump; and inject sensor loss, delayed samples, processor restart, and changing load. ROS 2 being alive is not a proof of deterministic timing or functional safety.

Current implementation and research examples

The ros2_control framework separates hardware interfaces, controller management, and controllers, and documents controller chaining and PID controllers. Its official documentation and PID controller page expose gains, clamps, anti-windup options, references, measured states, and published controller state. This makes interfaces and state observable; it does not tune a physical robot automatically.

Industrial controllers embody the same concerns. Siemens documents PID functionality for SIMATIC S7-1200/S7-1500 PLCs in its S7-1200 system manual. Research extends PID with friction and delay adaptation, data-driven tuning, and learned high-level reference generation, while retaining a small, inspectable low-level loop where that is the safer architecture.

Implementation checklist

Define controlled variable, command, units, positive directions, valid ranges, and loop rate.
Validate calibration, timestamps, staleness, and outliers before the control computation.
Bound $u$ and its slew rate; test independent E-stop, watchdog, and communication-loss behavior.
Tune and log P-only, PI, then PID; test commands and disturbances separately.
Log reference, measurement, real command, saturated command, integral state, and fault flags on one clock.
Test jitter, load change, restart, sensor loss, and actuator saturation deliberately.
Cross-check ROS 2 topology with the ROS 2 Primer and estimator timing with the Visual SLAM Primer.

Check your understanding

What if integration continues while output is saturated?

Stored integral action can cause later overshoot. Check anti-windup behavior rather than adjusting the integral gain alone.

References

Try it in the browser

Lab Reproduce overshoot from saturation and integral windupExperiment with PID in Python — gains, delay and saturation