Line Follower Simulator: Tune a Robot in Your Browser

Controls

Use the track presets to establish a baseline, or pause the run and draw directly on the course. Robot speed controls how far the chassis advances per update. Sensor count and spacing change the field of view. The P, I, and D controls change steering response; Step advances one deterministic update while paused.

Start with a moderate speed, five sensors, and the default gains. Change one variable at a time and compare the error, lap time, and time-on-track metrics.

Theory

The sensor bar samples reflectance across the front of the robot. Each active sensor contributes its signed position to a weighted average. The center of the bar is error zero; readings left or right of center produce negative or positive error.

The controller combines three terms:

$$u(t) = K_p e(t) + K_i \int e(t)dt + K_d \frac{de(t)}{dt}$$

The correction $u(t)$ speeds one wheel and slows the other. Proportional control reacts to the current offset, integral control corrects persistent bias, and derivative control damps rapid changes.

Algorithm

1. Sample every sensor at a fixed interval.
2. Compute a weighted line position and normalize it around the center.
3. Reuse the last observed line direction when every sensor loses the track.
4. Update integral and derivative terms using the same fixed time step.
5. Clamp the correction, calculate left and right motor commands, and integrate the robot pose.

Tune proportional gain until the robot follows gentle turns, add derivative gain until oscillation settles, and introduce only enough integral gain to remove a repeatable offset.

Source code

The browser simulator and a microcontroller use the same control shape. A compact Arduino-style loop looks like this:

float integral = 0.0f;
float previousError = 0.0f;

void controlStep(float dt) {
  float error = readWeightedLinePosition();
  integral = constrain(integral + error * dt, -2.0f, 2.0f);
  float derivative = (error - previousError) / dt;
  float correction = kp * error + ki * integral + kd * derivative;

  setMotorSpeeds(baseSpeed - correction, baseSpeed + correction);
  previousError = error;
}

Keep the real control interval stable. A variable delay changes the derivative and integral terms even when the gains stay the same.

Assumptions and hardware differences

This is a teaching model, not a hardware replica. The track is a flat, high-contrast binary mask with no ambient light variation, so the sensor bar sees perfect black and white — on real tape, room lighting, surface gloss and sensor height change the readings and you must calibrate per the steps in the wiring notes. Timing is ideal: the controller runs at a fixed interval with no delay() jitter, whereas a physical Arduino loop varies with other work and that jitter reshapes the PID response. The chassis is kinematic: wheels never slip, motors respond instantly and the battery never sags. Treat gains found here as a close starting point, then re-tune on the real robot after calibration.

Circuit diagram

Connect the sensor outputs to analog-capable inputs, share ground between every module, and drive motors through an H-bridge rather than from controller pins.

Verify the motor supply rating and add local decoupling near the controller and driver. Never route motor current through a development board’s logic regulator.

Guided experiments

Each of these isolates one variable, which is the thing that is genuinely hard to do on real hardware where everything changes at once.

1. Find the ultimate gain, then halve it

Set the integral and derivative gains to zero and raise the proportional gain until the robot oscillates steadily along a straight section — weaving at a constant amplitude rather than a growing or shrinking one. Halve that value.

You now have a starting Kp derived from a measurement instead of a guess, and it will be close. Add derivative from there until the weave damps out.

2. Prove that gains are speed-dependent

Tune the robot until it tracks cleanly at a low base speed. Now raise the speed by half and run the same gains without changing anything.

It will weave, cut corners, or lose the line. Nothing about the controller changed — but the same steering correction now produces a larger change in heading per unit of track, so the effective gain went up with the speed. Every tune is a tune at a particular speed, which is why a competition robot slows for corners rather than running one gain everywhere.

3. Watch the sensor count change what is possible

Run the same track and the same gains with three, five and eight sensors.

The interesting result is that more sensors raise the ceiling rather than improving the floor. At low speed three sensors are fine. The extra resolution only starts paying at the speeds where the coarse error signal becomes the limiting factor.

4. Break it on purpose at a sharp corner

Raise the speed until the robot loses the line on the tightest corner. Watch what it does next. Then think about what the real robot should do: driving straight ahead is the worst option, because the line was curving away.

That is the reasoning behind holding the last error on line loss rather than zeroing it — zero means “centred”, which commands full speed straight on. Holding the last error keeps the robot turning the way it was already turning, which is where the line went.

What you should observe

Taking it to hardware

Gains found here transfer as a close starting point, and the tuning procedure transfers completely. Expect to re-tune on your own tape — and expect the biggest single improvement on hardware to come not from the gains but from the loop rate, since a first build often runs at 20–50 Hz and can reach several hundred simply by removing blocking calls. The full build is in build a line-following robot.