It's 2 AM. Race day is under 12 hours away. Your line follower was tracking perfectly last week. Tonight it drifts off on the same turn, every single lap. You haven't changed a line of code.

Here's the uncomfortable truth: "it just stopped working" is never actually true. Something changed: the lighting, the track surface, the speed you're running at, or an assumption from three weeks ago that never got tested under these conditions. This is a fast, honest diagnostic for the five real reasons a working line follower starts losing the line, in the order you should actually check them.

Run the 60-second triage below, find your symptom, jump straight to the fix. No re-explaining PID from scratch here. If your issue really is tuning, we've already written the deep-dive for that.

The 60-second triage

Fix 1: Recalibrate for today's track, not last week's

What's happening: Your IR array doesn't actually "see" a line. It reads raw reflectance values, and your firmware decides what counts as "line" vs "floor" using min/max thresholds captured during calibration. Change the lighting, the track surface, or even the sensor's mounting height, and those thresholds are suddenly wrong.

Why it happens: Competition hall lighting is not your garage. Track paint, vinyl, and matte tape all reflect IR differently. A robot calibrated once, three weeks ago, on a different surface, is running on stale numbers. It doesn't matter how good your PID values are if the input data is already lying to the controller.

How to fix it: Recalibrate on the actual track surface immediately before every run, not just once during initial setup. A simple sweep-and-store routine does this in seconds:

int minVal[8], maxVal[8];

void calibrateSensors() {
  for (int i = 0; i < 8; i++) {
    minVal[i] = 1023;
    maxVal[i] = 0;
  }

  unsigned long start = millis();
  while (millis() - start < 3000) {   // sweep the sensor across the line for 3 seconds
    for (int i = 0; i < 8; i++) {
      int reading = analogRead(A0 + i);
      if (reading < minVal[i]) minVal[i] = reading;
      if (reading > maxVal[i]) maxVal[i] = reading;
    }
  }
}

int normalize(int raw, int i) {
  return map(raw, minVal[i], maxVal[i], 0, 1000);
}

int minVal[8], maxVal[8];

void calibrateSensors() {
  for (int i = 0; i < 8; i++) {
    minVal[i] = 1023;
    maxVal[i] = 0;
  }

  unsigned long start = millis();
  while (millis() - start < 3000) {   // sweep the sensor across the line for 3 seconds
    for (int i = 0; i < 8; i++) {
      int reading = analogRead(A0 + i);
      if (reading < minVal[i]) minVal[i] = reading;
      if (reading > maxVal[i]) maxVal[i] = reading;
    }
  }
}

int normalize(int raw, int i) {
  return map(raw, minVal[i], maxVal[i], 0, 1000);
}

Store this as a callable routine, not a one-time setup block, and trigger it on the actual competition surface before your first official run. For sensor height, spacing, and mounting geometry specifically, we've already covered that in how to place an IR sensor array without guessing. Worth a quick check if you haven't touched your mount in a while.

Fix 2: The sensor can't see what you need it to see

What's happening: At sharp turns, T-junctions, acute angles, or line breaks, an 8-channel array spaced for straight-line tracking can run out of field of view before your firmware even has a chance to react. This isn't a tuning bug. It's a hardware ceiling.

Why it happens: Standard 8-channel arrays give you line position: enough for continuous straight and gently curved tracking. They weren't built to resolve junctions, loops, or asymmetric branching. A 16-channel array in a 2D MUX layout, like the ARC-16, exists specifically to give firmware line geometry instead: enough resolution to tell a 90° turn apart from a T-junction apart from a line break, and act accordingly.

How to fix it: Confirm your sensor height and spacing are correct first (see the placement guide above). Most "the line just disappeared" cases are a mounting issue, not a resolution issue. But if your track genuinely includes junctions, acute-angle turns, or loops and your robot consistently loses the line at the same geometry feature every lap, no amount of Kp/Kd tweaking fixes that: it's a sensing problem. The ARC-8 is the right call for simple line-following; step up to the ARC-16 only when the track geometry demands it.

Fix 3: Your control loop is reacting to old news

What's happening: Even a perfectly tuned PID controller fails if it reads sensors, computes a correction, and drives the motors slower than the robot is physically moving. At competition speed, the drift outruns the correction.

Why it happens: We've already broken down the full PID tuning process in PID Control Explained Like You're Actually a Beginner, including why a loop slower than ~10ms makes your derivative term react to stale, laggy error values. That's not a tuning fix, it's a timing fix, and it's worth diagnosing on its own before you touch a single gain value.

How to fix it: Measure it instead of guessing. Drop this around your existing sense-compute-drive block and watch the numbers over serial:

unsigned long loopStart = micros();

// ... your existing sense + compute + drive code goes here ...

unsigned long loopTime = micros() - loopStart;
Serial.println(loopTime);   // should stay comfortably under 10000 (10ms)

unsigned long loopStart = micros();

// ... your existing sense + compute + drive code goes here ...

unsigned long loopTime = micros() - loopStart;
Serial.println(loopTime);   // should stay comfortably under 10000 (10ms)

If the number is creeping up, look for delay() calls, Serial.print() calls left in from debugging, or a slow sequential sweep across every sensor channel. This is worth budgeting for deliberately if you're scanning a 16-channel MUX array, since more channels means more scan time per loop.

Fix 4: You're not losing the line, you're losing grip

Ask a cricket bowler what "losing your line" means and they won't mention sensors. They mean a ball drifting off the exact channel it needs to hit, over and over, not because of bad luck but because something in the mechanics broke down. Your robot has the same tell: when it wanders off on the same corner every single lap, the wheel isn't gripping the way it should. It's worth the detour because it's the fix builders skip the longest: everyone assumes it's the tune.

What's happening: At higher cornering speeds, momentum overtakes available tire friction, and the wheel slides before the correction ever gets a chance to act. Your sensor position calculation and PID output can both be completely correct. The robot still slides off because the fix isn't in the code.

Why it happens: No PID value fixes a physical traction limit. This is exactly why Techgeeks' own N20 High-Traction Wheels use a rubber grip layer modeled on professional cricket bat grip material. Same idea, same reason: maximum surface contact when the load gets serious.

How to fix it: Check wheel condition and grip first: worn or smooth rubber loses contact area fast. Then check the chassis itself: as covered in choosing a chassis when speed starts mattering, a chassis upgrade only helps if it's solving a measured problem (sensor height shifting under impact, motor mounts flexing under acceleration, or asymmetric cornering), not a tuning issue in disguise. If cornering speed is genuinely your ceiling and the mechanics check out, active downforce is the real fix: the Advanced Suction Chassis uses an 8520 coreless impeller to generate 600g+ of continuous downforce, the same ground-effect principle F1 cars use to corner faster than grip alone would allow.

Fix 5: Power delivery quietly falling apart mid-run

What's happening: Your robot runs clean for the first two laps, then gets inconsistent, not from a bug but from the electrical system struggling to keep up with itself.

Why it happens: Acceleration, braking, and correction all pull current spikes through your motor driver, and those spikes add up to real heat over a full practice session, not just one short test run. Motor torque also drops as a battery discharges, which quietly shifts how your robot responds to identical PID values over the course of a single day of testing. Both effects look exactly like "random" failure because they only show up once the robot's been running for a while. See motor driver heat and current basics for the full picture.

How to fix it: Touch the driver after a full session, not one lap. If it's hot, that's a reliability signal, not a footnote. Clean, short motor wiring and a board with proper on-board regulation (the Blueprint 01 controller board includes a dedicated 5V regulator and decoupling caps specifically to isolate this from breadboard noise) removes an entire category of "it worked an hour ago" failures before they start.

FAQ

Is losing the line always a PID problem?
No. That's the point of this post. Tuning is one of five possible causes, and usually not the first one to check. Run the triage table above before touching a gain value.

How often should I actually recalibrate?
Every session, on the actual surface you're about to run on, not just once during setup. Lighting and track material both shift your thresholds more than most builders expect.

My robot only loses the line on one specific turn. Is that different?
Yes. A single repeatable failure point is almost always Fix 2 (sensor geometry) or Fix 4 (grip), not a random tuning issue: random issues tend to show up inconsistently, not at the same spot every lap.

Should I upgrade my sensor or my chassis first?
Depends on the symptom, not on what looks more impressive. Use the triage table: if the failure is tied to a track feature, it's sensing. If it's tied to a speed threshold, it's grip.

Conclusion

Five things can make a working line follower stop working: stale calibration, sensor resolution that can't see what the track is asking, a control loop reacting to old data, wheels that can't grip hard enough for the speed you're asking of them, or a power system quietly falling apart mid-run. None of them are fixed by guessing. All five are fixed by testing the right thing first.

So, which of these five is yours: sensor, speed, grip, power, or timing? Drop it in the comments; the trickiest ones are usually worth their own teardown.

If grip turned out to be your answer, the N20 High-Traction Wheels and the Advanced Suction Chassis are the two fastest fixes on this list. Join the community so the next teardown lands in your inbox before your next race day does.