Line Follower Robot Arduino Build (Under Rs.1,500)
Line Follower Robot Arduino Build (Under Rs.1,500)
A line follower robot uses infrared sensors to read a black line, then steers two wheels to stay on it. Ours pairs an ESP32-C3 board, a 5-channel IR array and an L298N driver — a tray Soldr, Compoden's AI build assistant, built for a college-competition brief, flagging its own hardware problems honestly instead of hiding them.
Quick answer: Soldr specs a 7-part ESP32-C3 + L298N + TCRT5000L line follower for Rs.1,331, under the Rs.1,500 target. But the stock 3.7V battery can't power the motors (0.3A supplied vs ~5,130mA needed), and the board's tight GPIO budget triggered 3 pin conflicts Soldr flagged but couldn't auto-fix. Budget extra for a real battery before wiring.
Proof of work: we built this exact project through Soldr, Compoden's AI build assistant, on 10 August 2026 — every screenshot below is from that session. Published 11 August 2026 · Last updated 11 August 2026.
What parts do you need for a line follower robot?
You need seven parts: an ESP32-C3 controller board, a 5-channel infrared line sensor, an L298N motor driver, two N20 gear motors, a 2WD chassis kit, a small LiPo battery, and hookup wire. Soldr's session priced the whole tray at Rs.1,331 — comfortably under Rs.1,500 — with every part in stock. There is no single pre-bundled "line follower kit" in the catalog for this exact combination, so the table below is the shopping list.
| Part | Qty | Price (Rs.) | Where to buy |
|---|---|---|---|
| ESP32-C3 Super Mini Development Board (HW-466AB, WiFi/BLE, RISC-V) | 1 | 290 | ESP32-C3 Super Mini Development Board |
| TCRT5000L 5-Channel Infrared Tracking Sensor Module | 1 | 190 | TCRT5000L 5-Channel Infrared Tracking Sensor Module |
| L298N Motor Driver Module | 1 | 180 | L298N Motor Driver Module |
| N20 Micro Metal Gear DC Motor 50RPM 3V | 2 | 91 each | N20 Micro Metal Gear DC Motor 50RPM 3V |
| 2WD Robot Chassis Kit (ships with its own motors — see note) | 1 | 280 | 2WD Robot Chassis Kit |
| 3.7V 320mAh Li-Po Rechargeable Battery (insufficient — see note) | 1 | 199 | 3.7V 320mAh Li-Po Rechargeable Battery |
| 23 AWG Multi-Strand Breadboard Wire | 1 | 10 | 23 AWG Multi-Strand Breadboard Wire |
| Total (as carded by Soldr) | 1,331 | Cash on delivery available across India |
Two honest notes before you order. First, the power problem: Soldr's own session math says this build draws roughly 5,130mA active current (L298N ~3,000mA + two N20 motors ~1,000mA each + sensor array ~50mA + ESP32-C3 ~80mA), and needs at least 7V at the motor driver after its internal voltage drop. The tray's 3.7V 320mAh battery outputs only 0.3A at 3.7V — both numbers are far short. We checked the catalog for a real fix: a 4×AA holder is explicitly rated "not suitable for high-current devices (e.g., motors)," and a plain 18650 holder caps out at 2A. The only catalog-verified part that actually clears the bar is the 7.4V LiPo 2000mAh 2S 20C Battery (Rs.1,180, rated for 40A continuous) — swap it in and the honest total becomes roughly Rs.2,312, not Rs.1,331. Second, the chassis: the 2WD Robot Chassis Kit already ships with its own pair of DC geared motors. Set those aside (or save them for another build) and mount the two N20 motors from this tray instead — running both pairs at once is not part of this build.
Tools: a laptop with the free Arduino IDE (2.x or 3.x) and the ESP32 board package installed, a USB-C cable, and a small screwdriver for the chassis screws.
Step 1: Describe the project to Soldr in one sentence
Open Soldr and describe the goal, not the parts. Our exact prompt was: "line follower robot for a college competition - it should be fast but reliable on tight curves." We never named a sensor, a driver, or a board — Soldr chose all of them from the requirement.
Soldr's reply explained every part in plain language and, notably, flagged its own build's weak points before we asked: the chassis kit's 6-12V rating doesn't match the 3V motors or the 3.7V battery, and the battery's stated 0.3A output is "far below the build's roughly 5130mA active draw." It also named the reasoning for the controller choice: "the lowest-cost listed part that meets the controller requirement," with other boards selectable from the parts tray.
Checkpoint: your parts tray shows 7 parts, all in stock, total Rs.1,331, with a Build profile reading "Difficulty: Easy" and "Suitable for: roughly 11+."
Step 2: Get the parts on your table (and budget for the battery fix)
Order the tray or pull the parts from a kit you already own. Before assembling anything, separate the 2WD chassis kit's stock motors from the two N20 motors in your tray — you will mount the N20 pair, not the bundled ones. If this build needs to actually finish a lap rather than just power on, order the 7.4V 2S LiPo now rather than discovering the shortfall mid-build; it is the one part Soldr's own numbers say is genuinely missing from the tray.
Checkpoint: chassis assembled with the two N20 motors mounted (bundled chassis motors set aside), sensor array and driver board on hand, battery decision made.
Step 3: Ask Soldr for the firmware
Our second prompt was three words: "give me the full code." Soldr's first build log (165 seconds) returned a complete sketch built around the actual hardware — sensor logic, motor mapping, and flash instructions — then immediately caught problems in its own output: "⚠ caught 4 hardware problems in that sketch — fixing…" It kept working rather than shipping code it already knew was wrong.
The reply also confirmed something useful for a beginner: "Library needed: No external libraries — only the built-in ESP32 Arduino core." Nothing to install beyond the ESP32 board package itself.
Checkpoint: your session shows a build log, flash instructions (Board: ESP32C3 Dev Module, Serial Monitor at 115200 baud), and a note that the sketch is being corrected.
Step 4: Read the pin-conflict warning before you wire anything
After the auto-fix, Soldr returned a corrected sketch — "no strapping pins used for sensors, UART pins free for motor driver" — and then, to its credit, flagged what it could not fix on its own: three specific GPIO conflicts on the ESP32-C3. This matters because we asked our third prompt, "show me the wiring for all of it," right after seeing this warning — you should read it before you touch a single jumper wire.
Quoted verbatim, Soldr's warning read: "⚠ Before you flash this — 3 hardware issues I could not fix automatically: ENB=GPIO20 is the UART the sketch prints on — Serial output and this pin will fight. IN3=GPIO21 is the UART the sketch prints on — Serial output and this pin will fight. IN4=GPIO8 is a STRAPPING pin on this board — driving it can stop the board booting. The sketch will compile, but these can stop the board working. Ask me to move the pins and I'll regenerate." That last sentence is not filler — it is the actual next step. Reply to Soldr in your own session and let it regenerate before you flash.
Why does this keep happening on this exact board? Because the ESP32-C3 Super Mini has very few genuinely safe GPIOs. Its own catalog spec lists GPIO2, GPIO8 and GPIO9 as strapping pins, GPIO20/21 as the default UART, and GPIO18/19 as the internal USB D-/D+ lines — which leaves only 8 clean general-purpose pins (GPIO0, 1, 3, 4, 5, 6, 7, 10) for a build that needs 5 sensor inputs plus 4 motor-driver lines. Nine signals, eight clean pins — that one-pin shortfall is exactly what Soldr's warning is about, and it is a real constraint of this specific board, not a one-off glitch.
Checkpoint: you have read the pin-conflict warning and either asked Soldr to regenerate with moved pins, or you understand which pin (see the wiring table below) needs the caution note.
Wire the sensors, driver and motors
Because the exact regenerated pin map lives in your own session's Firmware and Wiring tabs (our third prompt was sent but its answer fell outside this capture), the table below is a reference map built from the ESP32-C3's own published pin capabilities — it avoids every pin Soldr's warning named, except one flagged explicitly. Verify against the wiring your own Soldr session generates.
| From | To | Why |
|---|---|---|
| TCRT5000L VCC | ESP32-C3 3.3V pin (not 5V) | The ESP32-C3's GPIOs are 3.3V-only and "5V input will damage the board" per its own spec — power the sensor at 3.3V so its HIGH output can't exceed that |
| TCRT5000L S1–S5 | GPIO0, GPIO1, GPIO3, GPIO4, GPIO5 | Five clean, non-strapping, non-UART pins — one per sensor channel |
| L298N IN1 / IN2 | GPIO6 / GPIO7 | Left motor direction + PWM speed (OUT1/OUT2), on clean pins |
| L298N IN3 | GPIO10 | Right motor direction + PWM speed, the last fully clean pin available |
| L298N IN4 | GPIO2 (strapping pin — see caution) | Only 8 clean GPIOs exist for 9 needed signals; this is the one pin borrowed from the strapping set, safe here because it's driven as an output only after boot completes |
| L298N ENA / ENB jumpers | Left bridged (on the board) | Keeps full driver enable without spending 2 more GPIOs; speed is controlled by PWM on IN1–IN4 directly instead |
| L298N 5V / GND (logic) | ESP32-C3 5V / GND | Logic supply — only present on the Super Mini when it's powered over USB |
| L298N 12V / GND (motor) | Separate battery, +/− (NOT the stock 3.7V pack) | Needs 6-46V and real current headroom — see the power note above |
Checkpoint: all connections made, motor supply wired to a battery that is not the stock 320mAh LiPo, sensor VCC on the 3.3V rail (not 5V). Nothing should light up or spin yet — the sketch is not on the board.
Step 5: Flash the sketch and calibrate the sensors
In the Arduino IDE, select Board: ESP32C3 Dev Module (or ESP32-C3 Super Mini if listed), enable Tools → USB CDC On Boot → Enabled so Serial output uses the USB port instead of the UART pins, then upload. Open the Serial Monitor at 115200 baud — the sketch waits 2 seconds after boot, then starts following the line.
Before the first run, calibrate the TCRT5000L: its five potentiometers need adjusting so each channel reads LOW over the black line and HIGH over the light surface (the catalog lists this sensor as "calibration required" by design). Soldr's own session notes named skipped calibration as the top cause of unreliable readings.
Checkpoint: Serial Monitor prints a startup line, all 5 sensor channels flip cleanly between LOW and HIGH as you pass a dark strip under them by hand.
Step 6: Set it on the track — the proof
Place the robot on the line, power the motor supply, and it should hold position for 2 seconds, then start correcting toward the black line as the weighted sensor reading feeds the PID loop. A well-tuned build corrects smoothly through curves without overshooting into a zig-zag; an under-tuned one either drifts off tight curves or oscillates on straights. Our capture session covered the parts tray, firmware, and the moment the wiring request was sent — not a running-track video — so treat the next section's tuning guidance as the path from "wired" to "actually laps the track."
Checkpoint (success state): the robot tracks the black line through at least one full lap without losing it, correcting rather than overshooting on curves, with Serial Monitor still printing sensor and PID values for you to watch.
The full code
This is a reference sketch matching Soldr's stated logic (sensors digital, LOW on black line; left motor on OUT1/OUT2, right on OUT3/OUT4; PID with tunable Kp, Kd, Ki and BASE_SPEED; 2-second start delay; Serial at 115200) and the reference pin map above. The literal code Soldr generated lives in your own session's Firmware tab — treat this as a working starting point, not a transcript of that exact file. Library needed: none, built-in ESP32 Arduino core only, Arduino IDE 2.x/3.x with the ESP32 board package (enable USB CDC On Boot).
// Line follower robot: 5-channel IR array + L298N + 2x N20 motor, ESP32-C3.
// No external libraries - built-in ESP32 Arduino core only.
// Board: ESP32C3 Dev Module. Enable Tools -> USB CDC On Boot -> Enabled.
// Reference pin map - confirm against your own Soldr Wiring tab before use.
const int S_PIN[5] = {0, 1, 3, 4, 5}; // TCRT5000L channels, left to right
const bool LINE_IS_BLACK = LOW; // sensor reads LOW over the black line
const int IN1 = 6; // left motor (L298N OUT1/OUT2)
const int IN2 = 7;
const int IN3 = 10; // right motor (L298N OUT3/OUT4)
const int IN4 = 2; // strapping pin - output only, driven after boot completes
const int BASE_SPEED = 150; // 0-255, tune for your motors/track
float Kp = 18.0, Ki = 0.0, Kd = 8.0; // tune on your own track surface
float lastError = 0;
float integral = 0;
void setup() {
for (int i = 0; i < 5; i++) pinMode(S_PIN[i], INPUT);
pinMode(IN1, OUTPUT); pinMode(IN2, OUTPUT);
pinMode(IN3, OUTPUT); pinMode(IN4, OUTPUT);
Serial.begin(115200); // uses USB-CDC, not the UART0 pins
Serial.println("Line follower ready - starting in 2s");
delay(2000); // matches the session's stated start delay
}
int readPosition() {
// Weighted position: -2000 (line far left) .. +2000 (line far right), 0 = centred.
int weights[5] = {-2000, -1000, 0, 1000, 2000};
long weightedSum = 0;
int activeCount = 0;
for (int i = 0; i < 5; i++) {
if (digitalRead(S_PIN[i]) == LINE_IS_BLACK) {
weightedSum += weights[i];
activeCount++;
}
}
if (activeCount == 0) return (lastError > 0) ? 2000 : -2000; // line lost: keep turning last known way
return weightedSum / activeCount;
}
void driveMotor(int inA, int inB, int speed) {
speed = constrain(speed, -255, 255);
if (speed >= 0) { analogWrite(inA, speed); analogWrite(inB, 0); }
else { analogWrite(inA, 0); analogWrite(inB, -speed); }
}
void loop() {
int position = readPosition();
float error = position / 1000.0; // normalise to roughly -2..+2
integral += error;
float derivative = error - lastError;
float correction = Kp * error + Ki * integral + Kd * derivative;
lastError = error;
int leftSpeed = BASE_SPEED + correction;
int rightSpeed = BASE_SPEED - correction;
driveMotor(IN1, IN2, leftSpeed); // left motor
driveMotor(IN3, IN4, rightSpeed); // right motor
Serial.print("pos:"); Serial.print(position);
Serial.print(" err:"); Serial.print(error);
Serial.print(" corr:"); Serial.println(correction);
}How does a PID line follower actually work?
Three ideas make this robot track a curve instead of zig-zagging off it. First, weighted position: instead of treating "line detected" as one bit, the code weights each of the 5 sensors by its physical position, so reading sensors 2 and 3 active gives a different, more centred number than sensors 1 and 2 — this is what lets 5 channels out-perform 2. Second, PID correction: Kp reacts to how far off-centre the line currently is, Kd reacts to how fast that error is changing (which is what stops overshoot on tight curves — exactly the "reliable on tight curves" ask from our original prompt), and Ki corrects small steady drift. Third, differential steering: the correction is added to one wheel's speed and subtracted from the other's, so the robot turns by speeding up one side and slowing the other rather than stopping to pivot — which is what makes it fast.
What if it doesn't work? Real troubleshooting
These are the failure modes Soldr's own session surfaced, not a generic list. Work through them in order.
Why won't the motors turn at all, or turn weakly?
Almost certainly the power supply. Soldr's own math says this build draws roughly 5,130mA active current, but the tray's stock 3.7V 320mAh battery outputs only 0.3A — about a seventeenth of what is needed — and the L298N needs at least 6-7V at its motor input after its internal drop, which a single 3.7V cell cannot supply at all. Confirm you have swapped to a real motor-rated battery (the 7.4V 2S LiPo above, or equivalent) before assuming a wiring fault.
Why does the robot lose the line on tight curves?
Soldr's own build notes named this directly: "missed tight curves when the sensor position or control response is unsuitable." In practice this is a tuning problem — raise Kd before you raise Kp, since derivative gain is what dampens overshoot into a curve; if the robot still loses tight curves, lower BASE_SPEED a little rather than fighting it purely with gains.
Why are the sensor readings unreliable or inconsistent?
Skipped calibration, per Soldr's own session notes: "sensor readings that remain unreliable because calibration was skipped." The TCRT5000L is a calibration-required part (its potentiometers must be tuned per surface and lighting) — recalibrate on the actual track surface, under the actual lighting you'll compete under, not on a different floor in a different room.
Why did my board stop booting after I wired the motor driver?
Check IN4. In the reference wiring above it sits on GPIO2, one of the ESP32-C3's three strapping pins — if the L298N or its wiring pulls that pin low while the board is powering up, it can force the board into the wrong boot mode. If you hit this, ask Soldr to regenerate the sketch onto a different pin (its own warning offered exactly this) rather than continuing to fight the current pin.
Why does Soldr's own build flag problems it doesn't fix?
Because it is telling the truth about a board with a real limit: the ESP32-C3 Super Mini exposes only 8 fully clean GPIOs (avoiding strapping pins GPIO2/8/9, UART pins GPIO20/21, and the USB pins GPIO18/19), and this build's sensor array plus motor driver need 9 signal lines. Rather than silently picking a bad pin, Soldr flagged the 3 conflicts by name and asked you to confirm the trade-off — read that warning as a feature, not a bug.
What should you build next?
You now have PID control, multi-sensor weighting, and a power-budget lesson under your belt — three skills that carry into almost every mobile-robot project. If you have not built the earlier rungs of this ladder, start with your first Arduino project: a button-controlled LED, then a soil moisture monitor with OLED display, then an ESP32 temperature and humidity dashboard on your phone. The next rung after this one — an AI voice agent over Bluetooth HFP — is queued (not yet live).
Or start your own build right now: open Soldr, Compoden's AI build assistant, describe your project the way we did — one sentence, no parts named — and it specs the kit, flags what won't work, and writes the firmware for your exact hardware.
Frequently asked questions
Line follower robot banane ke liye kaunse parts chahiye?
Seven parts: an ESP32-C3 Super Mini board (Rs.290), a TCRT5000L 5-channel IR sensor (Rs.190), an L298N motor driver (Rs.180), two N20 gear motors (Rs.91 each), a 2WD chassis kit (Rs.280), a 3.7V LiPo battery (Rs.199), and hookup wire (Rs.10). Total: Rs.1,331 from Compoden, cash on delivery available — though you should budget extra for a proper motor battery (see the power note above).
How much does a line follower robot cost in India?
Rs.1,331 for the tray exactly as Soldr specced it, checked against live Compoden prices in August 2026. That figure assumes the stock 3.7V 320mAh battery, which our own testing of the numbers shows cannot actually power the motors — add the 7.4V 2S LiPo (Rs.1,180) for a build that reliably runs, bringing the honest total closer to Rs.2,312.
Can I power this line follower robot with the stock 3.7V battery?
No. Soldr's own session flagged it directly: the battery supplies 0.3A while the build's active draw is roughly 5,130mA, and the L298N needs at least 6-7V at its motor input after voltage drop, which a single 3.7V LiPo cell cannot reach. Use a 7.4V 2S LiPo or equivalent motor-rated pack instead.
Do I need to understand PID control to build this?
No — you need to be willing to turn three numbers (Kp, Kd, Ki) up or down while watching what the robot does. Raise Kp if it reacts too slowly to the line, raise Kd if it overshoots on curves, and leave Ki near zero unless you see a steady drift to one side. The code and explainer above walk through why each one matters.
Why does Soldr's line follower use an ESP32-C3 instead of an Arduino Uno?
Because Soldr picks "the lowest-cost listed part that meets the controller requirement," and for this build that was the ESP32-C3 Super Mini (Rs.290) — cheaper than an Uno-class board and with WiFi/BLE held in reserve for a future upgrade. The trade-off is real, though: the Uno's 3.3V-tolerant-and-then-some pin budget is more forgiving, while the ESP32-C3's small, mostly-strapping-and-UART pin set is exactly what caused the pin conflicts in Step 4.