If you've built a line-follower robot, you've probably done this: found a tutorial, copied its Kp = 0.8, Ki = 0.02, Kd = 4.5, pasted them into your code, and watched your robot immediately drive off the track.

Then you changed one number at random. Then another. Eventually it worked, sort of — and you had no idea why.

That's not tuning. That's guessing with extra steps. And it happens because most PID tutorials teach you the formula before they teach you the idea. This post does it backwards, on purpose: idea first, formula second, numbers last — using your line follower as the running example the whole way through.

The 20-second version: PID control is just three reactions added together — how far off you are right now (P), how long you've been off (I), and how fast you're closing the gap (D). A line follower uses all three to decide how hard to steer back toward the black line. Once you understand what each one is reacting to, tuning stops being trial-by-luck and starts being a short, logical process.

The problem PID actually solves

A line follower has one job: stay centered on a line. It does this thousands of times a second by asking one question — am I off to the left or the right, and by how much? — and correcting for it.

The crude way to solve this is bang-bang control: if the sensor sees the line has drifted left, turn right, full stop. If it's drifted right, turn left, full stop. It works, technically, but it looks like a robot having a seizure — constant hard left-right snapping instead of a smooth glide.

PID exists to replace that twitch with something closer to how a human actually drives: gentle correction when you're barely off, firmer correction when you're way off, and anticipation so you don't overcorrect and swerve the other way. That smoothness is the entire point.

First, how does the robot even know it's off the line?

Before P, I, or D can do anything, the robot needs a single number that says how far off center am I, and in which direction. This number is called the error.

Most line followers use a row of infrared sensors (three, five, or more) under the front of the chassis. Each sensor reports whether it sees dark line or light floor. Instead of treating each sensor separately, you combine all of them into one weighted position — sensors on the far left count as strongly negative, the center sensor counts as zero, sensors on the far right count as strongly positive.

For a 5-sensor array, a simple weighting looks like this:

// Sensor positions, left to right: -2, -1, 0, 1, 2
int sensorWeights[5] = {-2, -1, 0, 1, 2};
int sensorValues[5];   // 1 = sees line, 0 = sees floor (after calibration)

float getError() {
  long weightedSum = 0;
  int activeSensors = 0;

  for (int i = 0; i < 5; i++) {
    if (sensorValues[i]) {
      weightedSum += sensorWeights[i];
      activeSensors++;
    }
  }

  if (activeSensors == 0) return 0; // line lost — handle separately
  return (float)weightedSum / activeSensors;
}

// Sensor positions, left to right: -2, -1, 0, 1, 2
int sensorWeights[5] = {-2, -1, 0, 1, 2};
int sensorValues[5];   // 1 = sees line, 0 = sees floor (after calibration)

float getError() {
  long weightedSum = 0;
  int activeSensors = 0;

  for (int i = 0; i < 5; i++) {
    if (sensorValues[i]) {
      weightedSum += sensorWeights[i];
      activeSensors++;
    }
  }

  if (activeSensors == 0) return 0; // line lost — handle separately
  return (float)weightedSum / activeSensors;
}

If the line is dead-center, error comes out to 0. If it drifts left, error goes negative. Drift right, it goes positive. Every part of PID that follows is just different ways of reacting to this one number.

P — reacting to how far off you are, right now

Proportional is the simplest and most important of the three terms. It says: the further off the line you are, the harder you steer back.

float P = Kp * error

float P = Kp * error

Think about steering a car back into your lane. A slight drift gets a slight nudge on the wheel. Drifting hard toward the shoulder gets a hard, immediate correction. That's proportional response — the correction scales with the size of the mistake.

Kp alone can actually drive a line follower reasonably well. The problem is that P has no memory and no foresight — it only ever reacts to this instant. That creates two predictable failure modes:

• Kp too low: the robot corrects too gently, drifts wide on turns, and can wander off the track entirely on a sharp curve.

• Kp too high: the robot overcorrects every single time, snapping past center in the other direction, then back again — a fast left-right wobble that looks a lot like the bang-bang problem you were trying to avoid.

This is why almost every tuning guide tells you to start with P alone, Ki = Kd = 0, before touching anything else.

I — reacting to how long you've been off

Integral adds up the error over time. It's the term that notices: "I haven't been drifting by much, but I've been drifting in the same direction for a while now — that's not random noise, that's a real bias, and P alone isn't fixing it."

integralSum += error;
float I = Ki * integralSum

integralSum += error;
float I = Ki * integralSum

Picture cruise control on a highway that starts climbing a hill. A steady throttle position that held 100 km/h on flat ground starts losing speed — a small, constant, three-km/h shortfall that proportional correction alone would just tolerate forever. Integral is what pushes the throttle a little further, because it's been "owed" that correction for a while.

On a line follower, small persistent offsets like this usually come from an uneven motor (one wheel slightly weaker than the other) or a slightly miscalibrated sensor array — nothing dramatic, just a steady lean in one direction. Integral quietly corrects for it.

The catch: integral has no brakes of its own. If left unchecked, it keeps accumulating even while the robot is stuck on one side (a state called integral windup), and then overcorrects hard once the error finally clears. That's why real code clamps it:

integralSum += error;
if (integralSum > MAX_INTEGRAL) integralSum = MAX_INTEGRAL;
if (integralSum < -MAX_INTEGRAL) integralSum = -MAX_INTEGRAL

integralSum += error;
if (integralSum > MAX_INTEGRAL) integralSum = MAX_INTEGRAL;
if (integralSum < -MAX_INTEGRAL) integralSum = -MAX_INTEGRAL

Most line followers barely need integral at all — many competitive builds run with Ki at zero or close to it. It's a fine-tuning term, not a foundation. Add it last, and add it small.

D — reacting to how fast you're closing the gap

Derivative looks at how quickly the error is changing and reacts to the trend, not just the current number.

float D = Kd * (error - previousError);
previousError = error

float D = Kd * (error - previousError);
previousError = error

This is the anticipation term. Think about approaching a red light: you don't wait until you're at the bumper of the car in front to brake — you ease off earlier because you can see how fast you're closing the distance. React to the rate, not just the distance, and you never even need a hard stop.

On a line follower, derivative is what stops P from overshooting. As the robot swings back toward center, the error is shrinking fast — derivative notices that and starts easing the correction before the robot actually reaches center, instead of slamming past it and needing another correction back. This is exactly what tames the wobble that a P-only controller produces at higher Kp values.

Derivative is also the twitchiest term. Because it reacts to change, it's extremely sensitive to sensor noise — a single flickery reading can spike the derivative term and jerk the motors for no real reason. That's why it's usually smoothed slightly in practice, and why control loops need to run fast and consistently (a loop that's too slow makes the derivative math work on stale, laggy data).

Putting all three together

The full output your motors actually respond to is just these three terms added up:

float error = getError();

float P = Kp * error;

integralSum += error;
integralSum = constrain(integralSum, -MAX_INTEGRAL, MAX_INTEGRAL);
float I = Ki * integralSum;

float D = Kd * (error - previousError);
previousError = error;

float correction = P + I + D;

int leftSpeed  = constrain(baseSpeed + correction, 0, maxSpeed);
int rightSpeed = constrain(baseSpeed - correction, 0, maxSpeed)

float error = getError();

float P = Kp * error;

integralSum += error;
integralSum = constrain(integralSum, -MAX_INTEGRAL, MAX_INTEGRAL);
float I = Ki * integralSum;

float D = Kd * (error - previousError);
previousError = error;

float correction = P + I + D;

int leftSpeed  = constrain(baseSpeed + correction, 0, maxSpeed);
int rightSpeed = constrain(baseSpeed - correction, 0, maxSpeed)

That's genuinely the whole algorithm. correction is added to one wheel's speed and subtracted from the other, so a positive correction steers left, a negative one steers right, and the size of the number decides how sharply.

Three plain-language reactions — now, lately, and how fast — added into a single steering signal, running many times per second. That's PID. Everything else is tuning.

How to actually tune it (instead of copy-pasting)

Here's the part that gets skipped in most tutorials, and it's the part that actually matters: your Kp, Ki, and Kd will never match someone else's, because your robot's weight, motor torque, wheelbase, sensor spacing, and speed are all different. A value that's perfectly tuned on a light, fast robot with wide-set sensors can be wildly unstable on a heavier one — same code, same math, different hardware, different numbers.

Tune it yourself with this sequence:

1. Isolate P. Set Ki = 0 and Kd = 0. Start with a small Kp (many builders start around 0.5–1.0) and run the robot on a straight section at low speed.

2. Push Kp up until it wobbles. Increase Kp in small steps until the robot starts to oscillate left-right on a straight line. That oscillation point is useful information, not a failure — it tells you the ceiling.

3. Back off. Drop Kp to roughly 70% of the value where the wobble started. That's your working P value.

4. Add D to kill overshoot. Start Kd somewhere around 5–10× your Kp value and increase it gradually. You should see the wobble smooth out and turns get cleaner, without the response turning jittery or noisy.

5. Add a small Ki only if you see a steady drift — the robot consistently leaning to one side even on a straight line. Start tiny (think 0.001–0.01) and increase in small steps; too much Ki shows up as a slow zig-zag that keeps growing.

6. Re-tune at speed. PID behavior changes with speed. Values that feel great at a crawl often need retuning once you increase baseSpeed, especially Kd.

7. Keep a log. Write down every Kp/Ki/Kd combination you try alongside what happened. It turns tuning from a foggy memory exercise into a pattern you can actually see.

Change one variable at a time. If you adjust Kp and Kd together and the behavior changes, you've just lost the ability to know which one caused it — and you're back to guessing.

Mistakes that quietly wreck a line follower's PID

• Copy-pasting values from someone else's robot. Covered above, but worth repeating: it's the single most common reason "the code doesn't work" even when the code is correct.

• Tuning more than one term at a time. You can't isolate cause and effect if two variables are moving at once.

• A control loop that's too slow. If your sensor-read-and-correct loop takes more than roughly 10 ms, your derivative term is reacting to old, stale error values — which can cause the exact oscillation you're trying to fix. Strip out blocking delay() calls and measure your actual loop time.

• Ignoring integral windup. An unclamped integral term that keeps accumulating while the robot is stuck off-line will overcorrect hard once the error clears.

• Tuning at one speed and racing at another. A perfectly smooth low-speed run can fall apart at competition speed because the timing between "sensing off-line" and "reacting" gets tighter as the robot moves faster.

• Forgetting the battery matters. Motor torque drops as a battery discharges, which quietly shifts how your robot responds to the same PID values over the course of a day of testing.

Quick reference

Frequently asked questions

Do I really need all three terms — P, I, and D? No, and most line followers don't use all three. A well-tuned PD controller (P and D, with Ki = 0) handles the vast majority of line-following tracks perfectly well. Integral is a fine-tuning fix for a specific symptom — a steady, one-directional drift — and if you're not seeing that symptom, you probably don't need it.

How many line sensors do I actually need? Three can technically work, but five is where most builders land — enough resolution to handle sharp turns without the extra weight and wiring complexity of eight or more. More sensors mean smoother position readings, but also a slower loop if your microcontroller has to read all of them every cycle.

My robot works fine at low speed but falls apart at competition speed — why? PID values aren't speed-independent. At higher speed, the same physical drift happens in less time, so your correction has less time to respond — which usually means Kd needs to go up as baseSpeed goes up. Retune incrementally: raise speed a little, retune, raise again, rather than jumping straight to race pace.

What's the single biggest beginner mistake? Changing more than one gain at a time. It feels faster, but it destroys the one thing tuning depends on — knowing which change caused which result. Isolate P first, always.

Where to go from here

The formula was never the hard part — output = Kp·error + Ki·∫error + Kd·(Δerror) fits in one line. The hard part is knowing what each piece is actually reacting to, which is exactly what makes tuning by feel possible instead of tuning by luck.

So here's the real test: open your line follower's code, set Ki and Kd to zero, and just tune Kp by itself this week. Notice the wobble point. That single exercise will teach you more about your specific robot than any list of "recommended values" ever could.

What's your Kp sitting at right now, and is your robot wobbling or drifting wide? Drop it in the comments — it's usually possible to tell which one you need to touch next just from that.

If this cleared PID up for you, the next post in this series digs into what happens when your robot hits a corner too sharp for a straight PID loop to handle. Join the community so it lands in your inbox the moment it's up.