How to Build a Line-Following Robot With Arduino: A Beginner's Guide

Almost nobody's first line-following robot fails because of a bad idea. It fails because of one of about four specific, well-known mistakes, made in a predictable order, that nobody warned them about before they started soldering. A line-following robot is genuinely a great first real robotics build — it needs actual sensor reading, actual motor control, and an actual feedback loop, all on a weekend budget — but it punishes exactly the shortcuts a first-timer is tempted to take.

The parts, and why each one is what it is

The brain is almost always an Arduino Uno rather than something smaller and cheaper, and the reason isn't performance — it's the full-size USB-B port. A Nano's Mini-USB connector is genuinely fragile, and "the board stopped uploading code" partway through a build is one of the most common and most misdiagnosed failures in beginner robotics; people burn hours suspecting their code before anyone suspects the cable. Same chip, same pins, sturdier connector — pay the extra board size.

A dual motor driver — a TB6612FNG or an L298N — sits between the Arduino's low-power logic pins and the actual current your drive motors need, because an Arduino pin cannot drive a DC motor directly without frying itself trying. Two geared DC motors with wheels, a caster or skid plate for the third contact point, and a reflectance sensor setup round out the core build.

The sensor choice matters more than beginners expect, and it's worth being deliberate here: a multi-channel array like a QTR-8RC gives you eight readings across the line's width, which is what lets you compute smooth, proportional steering. A pair of simple two-sensor IR modules is cheaper and easier to wire, but gives you only a binary "on the line or not" per side — enough to drive straight and detect a stop marker, not enough for smooth cornering. Decide which robot you're actually building before you buy sensors, because retrofitting proportional steering onto a two-sensor build later means replacing the sensors, not just changing code.

The chassis decision nobody thinks about until it's a problem

A surprising amount of first-build frustration traces back to the chassis, not the electronics — a wobbly, warped, or poorly-balanced base makes even perfect code look broken, because the robot physically can't execute the motion the code is asking for. A few things are worth deciding deliberately rather than by accident. Weight distribution matters: motors and battery, which are the heaviest components, should sit low and centered, not perched up top where they make the robot tip forward under acceleration or lean into turns. The caster or skid at the back needs low enough friction that it doesn't fight the drive wheels — a caster that drags will make the robot pull to one side even with identical motor speeds on both sides, and that asymmetry is easy to mistake for a sensor or gain problem when it's actually a hardware one.

If you're 3D printing or laser-cutting your own chassis rather than buying a kit, leave more room than you think you need for wiring — first-build chassis designs are almost always too tight, and cramming a motor driver, an Arduino, a sensor array, and a battery pack into a snug enclosure turns every wiring fix into a full disassembly. A little wasted space early saves real time later.

The two wiring mistakes that eat the most first-build time

A TB6612FNG has two separate power pins that look interchangeable to someone reading the datasheet at 11pm and are not: VM, which feeds the motors directly and can be 6 to 12 volts, and VCC, which feeds only the driver's internal logic and is strictly 5 volts. Feed 12 volts into VCC and you don't get a robot that doesn't work — you get a driver chip that's permanently dead, sometimes without any visible sign until you go looking for why nothing moves. Read the pinout twice, out loud if you have to, before power touches the board.

The second mistake is more of a planning failure than a wiring one: not budgeting pins before you start. A motor driver alone claims six-plus digital pins for direction and PWM control. If you wire your sensors first because they're more exciting, you will very often find, motor driver in hand, that the pins you assumed were free are already spoken for — and now you're re-wiring sensors mid-build instead of once. Map the entire pin assignment on paper before the first jumper wire goes in.

The control loop, and why it's simpler than it sounds

For an array-based build, each of the eight sensors gets a position weight based on how far it sits from center — the outer sensors count for more than the inner ones. Reading all eight and computing a weighted average gives you a single error value: how far off-center the line currently is, and in which direction. Feed that error into a simple proportional controller, and you have working steering.

int error = readLinePosition();      // negative = left of center, positive = right
int correction = error * Kp;          // proportional gain — this is the number you'll tune by hand
leftSpeed  = BASE_SPEED - correction;
rightSpeed = BASE_SPEED + correction;

That's genuinely most of the algorithm. The part that eats real time isn't writing this loop — it's finding the right value for `Kp` and `BASE_SPEED` for your specific chassis, motors, and floor, which is a bench-testing problem, not a code problem, and it's worth budgeting real time for it rather than treating tuning as an afterthought.

Going beyond proportional: why PID gets mentioned so often

A pure proportional controller — the version above — is genuinely enough to finish a first working robot, and it's worth actually getting that far before reaching for anything fancier. But it has a known weakness: it corrects proportionally to how far off-center you currently are, with no memory of the past and no anticipation of the future, so it tends to either respond sluggishly on gentle curves or overshoot and oscillate on sharp ones, and rarely both well at once with a single gain value. PID control adds two more terms — an integral term that accounts for small, persistent error building up over time, and a derivative term that reacts to how fast the error is changing, which helps it slow its correction down as it approaches center instead of overshooting past it. It's worth learning once your proportional-only robot is reliably working and you're specifically fighting oscillation on tight turns that a lower gain alone won't fix — not before, because tuning three interacting gains instead of one is real added complexity you don't need for a first working loop.

A tuning order that actually works

Confirm every sensor individually over a serial monitor before wiring anything else — move each one by hand between the floor and the tape and watch the number change in real time. This is the single highest-leverage ten minutes in the whole build, because a sensor that's wired backward, mounted too high, or has its onboard threshold set wrong will silently sabotage every later step, and it's far easier to catch here than to debug once the whole robot is assembled and "just not following the line right."

Bench-test the motors with the wheels off the ground before the robot ever touches the track, confirming both spin the correct direction under `driveStraight()` — it is a genuinely common and entirely avoidable mistake to have the left and right motor wiring swapped and only discover it when the robot spins in a circle on its first real run. Then start with a low base speed and a conservative gain and increase both gradually. A robot that oscillates wildly, swerving hard left then hard right down a straight line, almost always has its proportional gain set too high — that's a five-minute fix, not a hardware problem, but it looks like a hardware problem if you don't know to suspect the gain first.

Finally, tune on the actual surface and under the actual lighting you'll run on for real, not just your kitchen table. Reflectance sensors are genuinely sensitive to ambient light and to how reflective the floor material is, and a threshold that works perfectly at home under one light source can fail on a stage or a competition table under different lighting — this is the failure that blindsides people who did everything else right.

Nearly every line-following robot that fails on the day it matters fails from an untuned threshold or gain, not a design flaw. Budget real bench-testing time as its own phase, separate from build time — it is not the same task.

A troubleshooting reference for the failures that come up constantly

The robot drives forward but never turns: almost always a wiring or code issue where both motors are receiving the same speed regardless of sensor readings — check that the correction value is actually being applied to each side separately, not just computed and discarded. The robot turns the wrong direction at a curve: usually a sign error in the position weighting or a swapped left/right motor wire, not a sensor fault — swap the sign on the correction term before you start pulling wires. The robot works perfectly on a straight line and falls off at every curve: almost always the base speed is too high for the gain you've set — slow down before you increase the gain, since a slower robot gives its own correction more time to act before it's already run off the line.

One sensor reads correctly and its neighbor doesn't, on an otherwise identical setup: check the physical mounting height first — reflectance sensors are distance-sensitive, and a sensor mounted even a couple of millimeters higher than its neighbor can behave completely differently over the same surface. This one especially catches people off guard because it looks exactly like a code or wiring bug and is neither.

What comes after "it follows the line"

Once straight-line following and gentle turns are solid, the natural next steps are stop-line detection — a perpendicular strip that triggers some action when both sensors cross it at once — and, if you need more compute than real-time motor control should ever share a chip with, a second board like a Raspberry Pi handling anything smarter, talking to the Arduino over a single serial connection rather than sharing its time-critical loop. Beyond that, basic obstacle avoidance with a single ultrasonic sensor mounted facing forward is a natural next weekend project, and it introduces you to a genuinely different problem than line-following — reacting to something that wasn't there in the original track design at all.