Arduino Robotics in the Classroom: From First LED to Voice-Controlled Car

The classroom context

This is a Computer Science and Robotics course at secondary school level. Students arrive with zero electronics experience — most have never held a soldering iron or connected a breadboard. By the end of the semester they have built, wired and programmed a working robot car. The photos in this guide are from that course: real students, real lab, real hardware.

The lab before a session. The round central table is where finished robots are collected for review. The wall stations are for programming and simulation.

The course uses Arduino Uno-compatible boards because they are cheap, well-documented and survive the abuse of being handled by thirty students per day. We don't use shields — students wire everything manually on a breadboard first, then solder the final version to a proto-board. That constraint is deliberate: if you only ever plug in a shield, you don't learn what's actually happening electrically.

The three sketches below are the actual files from the course, in the order students work through them. I've left the Spanish-language comments as-is — they were written for Spanish-speaking students and translating them after the fact would introduce errors that nobody ever ran and checked.

Stage 1 — single LED blink

Every student's first Arduino program. The goal isn't the LED — it's getting the IDE installed, finding the right COM port, and successfully uploading a sketch without panicking when the first attempt fails (and it always does, usually because of a driver issue on Windows).

Pin 9 was chosen instead of the built-in pin 13 LED so students are forced to wire an external LED with a resistor from the start. Pin 13's built-in LED is a crutch that hides the wiring step.

const int ledPIN = 9;

void setup() {
  Serial.begin(9600);         // iniciar puerto serie
  pinMode(ledPIN, OUTPUT);    // definir pin como salida
}

void loop() {
  digitalWrite(ledPIN, HIGH); // poner el Pin en HIGH
  delay(1000);                // esperar un segundo
  digitalWrite(ledPIN, LOW);  // poner el Pin en LOW
  delay(1000);                // esperar un segundo
}

The resistor value matters. We use 220 Ω with standard red 5 mm LEDs powered from Arduino's 5 V output. At that value the LED draws about 15 mA — well within the 40 mA per-pin limit of the Uno. Several students per class will try to connect the LED directly without a resistor; the LED glows briefly and then dies, which is actually a useful teaching moment about current limiting.

Stage 2 — six-LED sequence

The second exercise extends the first to six LEDs on pins 2 through 7, lighting each one in sequence with a 1-second pause. The point here is repetition and pattern: students see that the same digitalWrite / delay pattern repeats six times, which leads naturally to the discussion of loops and arrays in the next class.

int led_Dos   = 2;
int led_Tres  = 3;
int led_Cuatro = 4;
int led_Cinco  = 5;
int led_Seis   = 6;
int led_Siete  = 7;

void setup() {
  Serial.begin(9600);
  pinMode(led_Dos,    OUTPUT);
  pinMode(led_Tres,   OUTPUT);
  pinMode(led_Cuatro, OUTPUT);
  pinMode(led_Cinco,  OUTPUT);
  pinMode(led_Seis,   OUTPUT);
  pinMode(led_Siete,  OUTPUT);
}

void loop() {
  digitalWrite(led_Dos,    HIGH); delay(1000); digitalWrite(led_Dos,    LOW); delay(1000);
  digitalWrite(led_Tres,   HIGH); delay(1000); digitalWrite(led_Tres,   LOW); delay(1000);
  digitalWrite(led_Cuatro, HIGH); delay(1000); digitalWrite(led_Cuatro, LOW); delay(1000);
  digitalWrite(led_Cinco,  HIGH); delay(1000); digitalWrite(led_Cinco,  LOW); delay(1000);
  digitalWrite(led_Seis,   HIGH); delay(1000); digitalWrite(led_Seis,   LOW); delay(1000);
  digitalWrite(led_Siete,  HIGH); delay(1000); digitalWrite(led_Siete,  LOW); delay(1000);
}

The deliberate redundancy in this sketch — six nearly identical pairs of lines — is intentional pedagogy. Students copy it out, it works, and then you ask: "What would happen if we needed 50 LEDs?" The answer leads directly to for loops and arrays, which is the next topic. Starting with the verbose version makes the improvement obvious.

Stage 3 — voice-controlled robot car

The final project. Students build a 4WD chassis, wire a motor driver (L298N-style board with IN1–IN4 control pins), connect an HC-05 Bluetooth module on pins 10/11 via SoftwareSerial, and add an HC-SR04 ultrasonic sensor for automatic obstacle avoidance. The phone app sends Spanish voice commands over Bluetooth: avanzar, detener, atrás, derecha, izquierda, and automático.

One student's finished car — top view. Arduino at top left, motor driver board beside it, battery holder at top right. Wiring is deliberately left as-built rather than tidied for the photo.

#include <SoftwareSerial.h>
#include <Servo.h>

SoftwareSerial BT(10, 11); // RX=10, TX=11
String voz;

int IN2 = 3;
int IN1 = 2;
int ENB = 1;

int BIN4 = 4;
int BIN3 = 5;
int BENB = 6;

const int Trigger = 6;
const int Echo    = 7;

void setup() {
  pinMode(ENB,  OUTPUT);
  pinMode(IN1,  OUTPUT);
  pinMode(IN2,  OUTPUT);
  pinMode(BENB, OUTPUT);
  pinMode(BIN3, OUTPUT);
  pinMode(BIN4, OUTPUT);
  Serial.begin(9600);
  pinMode(13, OUTPUT);
  BT.begin(9600);
  pinMode(Trigger, OUTPUT);
  pinMode(Echo,    INPUT);
  digitalWrite(Trigger, LOW);
}

void loop() {
  while (BT.available()) {
    delay(10);
    char c = (BT.read());
    if (c == '#') break;
    voz += c;
  }

  if (voz.length() > 0) {
    Serial.println(voz);

    if      (voz == "avanzar")    avanzar();
    else if (voz == "detener")    detener();
    else if (voz == "atrás")      atras();
    else if (voz == "derecha")    derecha();
    else if (voz == "izquierda")  izquierda();
    else if (voz == "automático") modoAuto();

    voz = "";
  }
}

void modoAuto() {
  while (true) {
    digitalWrite(Trigger, HIGH);
    delayMicroseconds(10);
    digitalWrite(Trigger, LOW);
    long t = pulseIn(Echo, HIGH);
    long d = t / 59;

    Serial.print("Distancia: "); Serial.print(d); Serial.println("cm");
    delay(100);

    if (d > 100) avanzarAUT();
    else         detener();

    // Exit auto mode if a new command arrives
    if (BT.available()) { voz = ""; break; }
  }
}

void avanzar()    { digitalWrite(13,HIGH); digitalWrite(IN1,HIGH); digitalWrite(IN2,LOW);
                    digitalWrite(BIN3,HIGH); digitalWrite(BIN4,LOW); }
void detener()    { digitalWrite(13,LOW);  analogWrite(IN1,0); analogWrite(BIN3,0); }
void atras()      { digitalWrite(IN1,LOW); digitalWrite(IN2,HIGH);
                    digitalWrite(BIN3,LOW); digitalWrite(BIN4,HIGH); }
void derecha()    { digitalWrite(IN1,LOW); digitalWrite(IN2,HIGH); }
void izquierda()  { digitalWrite(IN1,HIGH); digitalWrite(IN2,LOW); }
void avanzarAUT() { digitalWrite(13,HIGH); digitalWrite(IN1,HIGH); digitalWrite(IN2,LOW);
                    digitalWrite(BIN3,HIGH); digitalWrite(BIN4,LOW); }

Note: the sketch above has one fix compared to the original student file — the modoAuto() function replaces a recursive loop() call that was in the original. The recursive version worked in short demos but would eventually overflow the stack in a long run. In the classroom we discovered this during a 10-minute continuous autonomy test where two cars reset unexpectedly. The fix is to use a while(true) loop with a Bluetooth check for exit.

The pin-conflict problem students always hit

In the voice-control sketch, pins 6 and 7 are used for the HC-SR04 Trigger and Echo. But pin 6 is also defined as BENB (the motor driver enable for the B channel). In the original student file both were assigned without noticing the collision — it compiled and ran because the two uses didn't overlap in time during testing, but it's a latent bug that would cause unpredictable motor behavior if the autonomous mode ran while the motor enable line was being toggled elsewhere.

This is the most common class-wide bug we see every semester: students assign pins by copying example code from two different sources without checking for conflicts. The fix is simple — give each function its own pin — but finding it requires reading the whole sketch top to bottom, which students resist. We now require a pin-assignment table as part of every project submission:

Requiring this table before any code is written has cut pin-conflict bugs by roughly half in subsequent semesters.

Frequently asked questions