PID Controllers

PID stands for Proportional-Integral-Derivative. Each term fixes a specific failure mode of the basic proportional controller:

• P (Proportional): Acts on the current error. Big error → big correction. Provides responsiveness. Alone it leaves a steady-state offset (the motor needs some error to produce some torque).
• I (Integral): Acts on accumulated error over time. As long as any error remains, the integral term keeps growing, pushing the output until it reaches exactly the setpoint. Kills steady-state error — but can cause slow windup.
• D (Derivative): Acts on the rate of change of error. If the error is shrinking fast, D applies a brake to prevent overshoot. It damps oscillations. Think of it as predicting where the error is heading.

The three terms work together: P drives toward the setpoint, I eliminates residual bias, D smooths the approach.

The continuous-time PID control law is:

$u(t) = K_p\, e(t) \;+\; K_i \int_0^t e(\tau)\,d\tau \;+\; K_d\, \dot{e}(t)$

where $e(t) = r(t) - y(t)$ is the error, and $K_p$, $K_i$, $K_d$ are the three gains to tune.

In transfer-function form, the PID controller is:

$C(s) = K_p + \frac{K_i}{s} + K_d s$

The $1/s$ term is the Laplace-domain integrator; the $s$ term is the differentiator. Notice that pure differentiation amplifies high-frequency noise (large $s$ → large magnitude at high frequency). In practice, the D term is almost always filtered: $K_d s / (1 + s/N)$ where $N$ is the derivative filter coefficient (typically 5–20), limiting how much noise the D term amplifies.

Here is how tuning each gain shifts the step response — the core of practical PID tuning:

The table reveals the fundamental tension: everything that speeds up the response (higher $K_p$, $K_i$) also reduces stability margins. $K_d$ is the one gain that both damps overshoot and improves stability — but only if the sensor is clean. With noisy encoders, a large $K_d$ amplifies noise into the actuator and causes chatter.

Integral windup is the most common PID failure in real hardware. It occurs when the actuator saturates — e.g., the motor hits its maximum voltage — but the integral keeps accumulating error. By the time the output finally reaches the setpoint, the integrator is enormous, causing a massive overshoot that takes a long time to unwind.

Example: a robot arm overshoots a target by 40° and then slowly creeps back, ringing for 10 seconds. Windup is usually the culprit.

Anti-windup strategies:

1. Clamping: Stop integrating when the output saturates (if abs(u) >= u_max: don't integrate).
2. Back-calculation: Feed the saturation error back into the integrator at a rate $1/T_t$, actively unwinding it.
3. Conditional integration: Only integrate when $|e| <$ threshold (near the setpoint).

Every production PID implementation should have anti-windup. Without it, actuator saturation will cause overshoots that look mysterious until you trace the integrator state.

Real controllers run at fixed sample rate $T_s$ (e.g., 1 ms). The integral becomes a running sum; the derivative becomes a finite difference:

class PID:
    def __init__(self, Kp, Ki, Kd, dt, u_max=float('inf'), N=10):
        self.Kp, self.Ki, self.Kd = Kp, Ki, Kd
        self.dt = dt
        self.u_max = u_max      # actuator limit for anti-windup
        self.N = N              # derivative filter coefficient
        self._integral = 0.0
        self._prev_e = 0.0
        self._d_filt = 0.0      # filtered derivative state

    def step(self, r, y):
        e = r - y
        # Anti-windup: only integrate if not saturated
        if abs(self._prev_u if hasattr(self, '_prev_u') else 0) < self.u_max:
            self._integral += e * self.dt
        # Filtered derivative: d/dt filtered via first-order IIR
        raw_d = (e - self._prev_e) / self.dt
        self._d_filt += self.dt * self.N * (raw_d - self._d_filt)
        u = self.Kp * e + self.Ki * self._integral + self.Kd * self._d_filt
        u = max(-self.u_max, min(self.u_max, u))  # clamp
        self._prev_e = e
        self._prev_u = u
        return u

This 20-line class is the skeleton of every PID loop you will ever deploy. The key choices: sample period $T_s$, actuator limits, and the derivative filter bandwidth $N/T_s$ Hz.

When you have a real plant and no model, Ziegler-Nichols gives starting gains in under 10 minutes:

Step 1 — Ultimate gain $K_u$: Disable I and D, ramp up $K_p$ until the output oscillates continuously (barely unstable). That gain is $K_u$; measure the oscillation period $T_u$.

Step 2 — Apply the table:

Ziegler-Nichols deliberately targets ~25 % overshoot — that is not a bug, it is the design intent. For lower overshoot, scale $K_p$ down to 0.3–0.4 $K_u$. For slow, non-oscillatory processes (chemical reactors, temperature loops), the step-response / reaction-curve variant is safer than forcing oscillations. ZN is a starting point, not an endpoint.

A pure feedback PID corrects errors after they occur. A feedforward term predicts the required control effort and applies it proactively — before the error builds up.

For a robot joint, gravity torque is predictable from kinematics:

$u(t) = \underbrace{K_p e + K_i \int e\,dt + K_d \dot{e}}_{\text{feedback}} + \underbrace{\hat{G}(q)}_{\text{gravity feedforward}}$

With a good gravity model $\hat{G}$, the feedback terms only need to correct model errors — they can be tuned to small, safe gains. This is the architecture used in almost every high-performance robot arm: a physics-based feedforward handles the bulk of the control effort, and a lightweight PID closes the remaining gap.

The pattern extends beyond gravity: velocity feedforward for tracking moving setpoints, friction compensation, inertia decoupling. Feedforward and feedback are complementary, not competing strategies.

After tuning thousands of loops, experienced engineers recognise these signatures:

Slow oscillation at steady state — $K_i$ too high or sample rate too low. Reduce $K_i$ by half and check.

Fast, high-frequency chatter — $K_d$ is amplifying encoder quantization noise. Add derivative filter or reduce $K_d$.

Large overshoot that takes forever to settle — integral windup. Verify anti-windup is active and the integrator is clamped during saturation.

Sluggish response that doesn't improve with more $K_p$ — you may be fighting friction. Add a small deadband near zero error, or add a friction compensator.

Response changes with operating point — the plant is nonlinear (most real plants are). Consider gain scheduling (different PID gains at different speeds/loads) or switch to a model-based approach like state-space with state feedback.