DEV Community: Willem van Heemstra

R2D2 Creation with Codey 🤖 Ep.8

Willem van Heemstra — Sun, 07 Jun 2026 14:14:14 +0000

Episode 8: The Complete Droid

"The Force Will Be With You. Always." 🌟

The entire crew stands in the workshop. Han Solo, arms folded. Luke, grinning. C-3PO, hands clasped with barely-contained anxiety. Princess Leia's message loops on the OLED — a recreation, text only, but the words are right: "Help me, Obi-Wan Kenobi."

And in the centre, dome slowly rotating, blue-white LEDs breathing, speaker playing a quiet ambient whistle — R2-D2.

OBI-WAN: quietly "Seven episodes. Seven systems. And now, the droid is nearly complete. There is one thing left — the final integration. The moment when all systems stop running in parallel and begin running as one coherent whole. When R2-D2 stops being a collection of components and becomes the galaxy's greatest droid."

R2-D2 beeps once. Confident. Ready.

OBI-WAN: "And then — the Force. The Wi-Fi."

Han Solo snorts.

HAN: "The Wi-Fi. Very mystical."

🗂️ SIPOC — The Complete Droid

Suppliers	Inputs	Process	Outputs	Customers
You (the maker)	"Integrate all systems + add Wi-Fi remote command interface"	Codey Deep Think mode plans the full architecture before writing	A unified state machine with all systems communicating, Wi-Fi endpoint for remote commands	The complete R2-D2 — one firmware, all systems orchestrated
ESP32-S3 N16R8	16MB Flash, 8MB PSRAM, dual-core, Wi-Fi	Dual-core operation: Core 0 for Wi-Fi/networking, Core 1 for real-time sensor/motor/audio loop	Smooth operation without Wi-Fi blocking the real-time control loop	All R2-D2 systems — none starved of processor time
Codey Deep Think mode	Complex multi-file integration prompt	Takes longer to respond — reasons about the whole architecture first	The cleanest, most architecturally coherent code in the series	Your long-term maintainability
Final Wiring Diagram	All 7 systems' component lists	Codey draws the complete master diagram with all connections, protection circuits, and power rails	A single PDF showing the complete R2-D2 build	Your workshop wall — the crown jewel of your build log

The Final Component Inventory — Every Piece of R2-D2 🔧

C-3PO produces a datapad with the air of someone who has been waiting seven episodes to read this list.

C-3PO: "The complete inventory, as accumulated across eight glorious — and at times terrifying — episodes:"

Component	Episode Added	Purpose
ESP32-S3 N16R8	5	The brain — all systems connect here
SSD1306 OLED 128×64	5	Holographic display — I2C via GPIO8/9
NeoPixel ring 12 LED	3	Dome lights — GPIO6 via level shifter
HC-SR04 ultrasonic	4	Distance sensing eye — GPIO9/10
PIR HC-SR501	4	Motion sensing — GPIO2 (interrupt)
SG90 servo	6	Dome rotation — GPIO14 via level shifter
DC gear motors × 2	6	Wheel drive — via L298N
L298N motor driver	6	Motor control, also provides 5V rail
DFPlayer Mini	7	Audio playback — UART2 GPIO16/17
Speaker 4Ω/8Ω	7	Voice output
microSD card (FAT32)	7	Audio files 0001–0007.mp3
74AHCT125 level shifter	3/6	NeoPixel + servo: 3.3V → 5V
470Ω resistor	3	NeoPixel data protection
1kΩ resistor	7	DFPlayer RX protection
100Ω resistor	—	(buzzer, now removed)
100µF capacitor	3	NeoPixel power decoupling
10µF capacitor	7	DFPlayer power filtering
Voltage dividers (10k+20k)	5	HC-SR04 ECHO + PIR output: 5V → 3.3V
9V battery or 2S LiPo	6	Motor power rail
USB cable	All	Programming + logic power

C-3PO: "R2-D2. In components. On a breadboard. I find this both impressive and somewhat unsettling."

R2-D2 beeps with what sounds like pride.

Deep Think Mode: The Wisest Path 🧠

Yoda settles into his chair.

YODA: "Complex this prompt is. Many files to touch. Many systems to unify. For this — Deep Think mode you shall use. Longer it takes. Wiser the result."

LUKE: "What's Deep Think mode?"

YODA: "Plan mode's elder sibling. Not just a plan — a deep analysis of the architecture first. Consider edge cases it will. Identify conflicts between systems it shall. Only then write, it does."

In Codey, click the mode dropdown and select Deep Think (Pro feature). Then type the final integration prompt:

FINAL R2-D2 INTEGRATION — Deep Think mode

We have these existing header files for the ESP32-S3 N16R8:
  - animations.h  (NeoPixel dome: GPIO6 via 74AHCT125)
  - sensors.h     (HC-SR04: GPIO9 TRIG / GPIO10 ECHO; PIR: GPIO2)
  - display.h     (SSD1306 OLED: I2C SDA=GPIO8 / SCL=GPIO9 — NOTE: conflict!)
  - motion.h      (Servo: GPIO14; L298N: GPIO25-27, GPIO32-34)
  - voice.h       (DFPlayer Mini: UART2 TX=GPIO17 / RX=GPIO16)
  - sounds.h      (LEDC buzzer: now removed, GPIO freed)

CONFLICT TO RESOLVE:
  HC-SR04 TRIG uses GPIO9. OLED I2C SCL also uses GPIO9.
  These cannot share! Remap one of them.
  Suggestion: Move HC-SR04 TRIG to GPIO11, ECHO to GPIO12.
  Update sensors.h and the wiring diagram accordingly.

NEW FEATURE — Wi-Fi remote control:
  Use ESP32-S3 Wi-Fi to create a simple HTTP server.
  Endpoints:
    GET /status    → JSON with distance, motion, dome angle, current sound
    GET /command/forward   → drive forward for 2 seconds
    GET /command/backward  → drive backward for 2 seconds
    GET /command/left      → turn left for 1 second
    GET /command/right     → turn right for 1 second
    GET /command/stop      → stop motors immediately
    GET /command/sound/N   → play sound N (1-7)
    GET /command/dome/N    → move dome to angle N degrees

  Use WiFiAP mode (R2-D2 creates its own access point):
    SSID: "R2-D2"
    Password: "beepboop"

  Run HTTP server on Core 0. Real-time systems on Core 1.

FINAL r2d2-main.ino:
  - Resolve the GPIO conflict
  - Add wifi.h header for Wi-Fi + HTTP server
  - Clean unified loop with clear comments
  - All systems operational
  - Serial output at 115200 showing all state transitions

Please think through the architecture fully before writing.

Deep Think Mode Analysis (Codey Responds)

[Deep Think analysis in progress...]

Architecture review:

1. GPIO CONFLICT IDENTIFIED:
   GPIO9 cannot serve both HC-SR04 TRIG and I2C SCL.
   Resolution: Remap I2C to SDA=GPIO4, SCL=GPIO5 (available on ESP32-S3).
   This avoids touching sensors.h; only display.h changes:
     Wire.begin(4, 5) instead of Wire.begin(8, 9).

2. DUAL-CORE STRATEGY:
   Core 0 (Arduino default): Wi-Fi, HTTP server, WebServer library
   Core 1 (pinned task): sensor reading, NeoPixel, servo, display, audio
   Separation prevents Wi-Fi TCP/IP stack from blocking 50Hz servo updates.
   Implementation: xTaskCreatePinnedToCore() for real-time loop.

3. STATE MACHINE:
   Unified DomeState enum: IDLE, SCAN, ALERT, DANGER, REMOTE_CONTROL
   REMOTE_CONTROL state: Wi-Fi command overrides sensor-driven behavior.
   Auto-return to IDLE after 5 seconds of no remote command.

4. MEMORY:
   16MB Flash — no concern.
   8MB PSRAM — HTTP response buffers can use ps_malloc() if needed.
   RAM: estimated ~68KB used (20.8% of 327KB) — safe.

5. POWER:
   Wi-Fi radio: ~240mA peak. USB 500mA should be sufficient for ESP32-S3.
   Motors: separate 9V rail — no impact on ESP32 power.

Generating files now...

Generated `wifi.h`

// wifi.h — R2-D2 Wi-Fi Remote Control
// ESP32-S3 Access Point: SSID "R2-D2", password "beepboop"
// HTTP server on port 80 — runs on Core 0

#pragma once
#include <WiFi.h>
#include <WebServer.h>
#include <ArduinoJson.h>

const char* AP_SSID     = "R2-D2";
const char* AP_PASSWORD = "beepboop";
const int   HTTP_PORT   = 80;

WebServer server(HTTP_PORT);

// Shared state (volatile — accessed from both cores)
volatile float  sharedDistance    = 999.0f;
volatile bool   sharedMotion      = false;
volatile int    sharedDomeAngle   = 90;
volatile bool   remoteCommandPending = false;
volatile String remoteCommand     = "";

// ── Status endpoint ──────────────────────────────────────────────
void handleStatus() {
  StaticJsonDocument<256> doc;
  doc["distance_cm"] = sharedDistance;
  doc["motion"]      = sharedMotion;
  doc["dome_angle"]  = sharedDomeAngle;
  doc["state"]       = "online";
  doc["uptime_s"]    = millis() / 1000;

  String response;
  serializeJson(doc, response);
  server.send(200, "application/json", response);
  Serial.println("[WiFi] GET /status");
}

// ── Command endpoints ────────────────────────────────────────────
void handleCommand() {
  String path    = server.uri();      // e.g. "/command/forward"
  String command = path.substring(9); // strip "/command/"
  remoteCommand        = command;
  remoteCommandPending = true;
  server.send(200, "text/plain", "ACK: " + command);
  Serial.print("[WiFi] Command: ");
  Serial.println(command);
}

// ── Root page (simple UI) ─────────────────────────────────────────
void handleRoot() {
  String html = R"rawhtml(
<!DOCTYPE html>
<html>
<head><title>R2-D2 Control</title>
<meta name="viewport" content="width=device-width,initial-scale=1">
<style>
  body { font-family:sans-serif; background:#111; color:#4af;
         display:flex; flex-direction:column; align-items:center; }
  h1 { color:#4af; }
  button { background:#1a3a5a; color:#4af; border:2px solid #4af;
           padding:14px 28px; font-size:1.1em; margin:6px;
           border-radius:6px; cursor:pointer; }
  button:active { background:#4af; color:#111; }
  #status { margin-top:16px; font-size:0.9em; color:#aaa; }
</style></head>
<body>
<h1>R2-D2</h1>
<div>
  <button onclick="cmd('sound/5')">🔊 Startup</button>
  <button onclick="cmd('sound/1')">😄 Happy</button>
  <button onclick="cmd('sound/3')">😢 Sad</button>
</div>
<div>
  <button onclick="cmd('forward')">▲ Forward</button>
</div>
<div>
  <button onclick="cmd('left')">◄ Left</button>
  <button onclick="cmd('stop')">■ Stop</button>
  <button onclick="cmd('right')">► Right</button>
</div>
<div>
  <button onclick="cmd('backward')">▼ Backward</button>
</div>
<div>
  <button onclick="cmd('dome/0')">Dome ◄</button>
  <button onclick="cmd('dome/90')">Dome ●</button>
  <button onclick="cmd('dome/180')">Dome ►</button>
</div>
<div id="status">Connecting...</div>
<script>
function cmd(c) {
  fetch('/command/'+c).then(r=>r.text()).then(t=>{
    document.getElementById('status').textContent = 'Last: '+c;
  });
}
setInterval(()=>{
  fetch('/status').then(r=>r.json()).then(d=>{
    document.getElementById('status').textContent =
      'Dist: '+d.distance_cm.toFixed(0)+'cm | Motion: '+d.motion+
      ' | Uptime: '+d.uptime_s+'s';
  });
}, 2000);
</script>
</body></html>
)rawhtml";
  server.send(200, "text/html", html);
}

// ── Init Wi-Fi + HTTP server (call from Core 0 task) ─────────────
void initWifi() {
  WiFi.softAP(AP_SSID, AP_PASSWORD);
  Serial.print("[WiFi] AP started: ");
  Serial.println(AP_SSID);
  Serial.print("[WiFi] IP: ");
  Serial.println(WiFi.softAPIP());

  server.on("/",          handleRoot);
  server.on("/status",    handleStatus);
  server.onNotFound([]() {
    // Any /command/* path
    if (server.uri().startsWith("/command/")) handleCommand();
    else server.send(404, "text/plain", "Not found");
  });

  server.begin();
  Serial.println("[WiFi] HTTP server started — connect to R2-D2 network");
}

// ── Core 0 task: runs Wi-Fi server continuously ──────────────────
void wifiTask(void* param) {
  initWifi();
  for (;;) {
    server.handleClient();
    vTaskDelay(1); // yield to RTOS — must not block Core 0
  }
}

Final `r2d2-main.ino`

// r2d2-main.ino — R2-D2 COMPLETE
// ESP32-S3 N16R8 | All systems operational
// Core 0: Wi-Fi + HTTP server
// Core 1: Sensors, display, NeoPixel, servo, motors, audio

#include <Adafruit_NeoPixel.h>
#include "animations.h"   // NeoPixel dome: GPIO6
#include "sensors.h"      // HC-SR04: GPIO9(TRIG) GPIO10(ECHO); PIR: GPIO2
#include "display.h"      // OLED I2C: SDA=GPIO4 SCL=GPIO5 (CONFLICT RESOLVED)
#include "motion.h"       // Servo: GPIO14; L298N: GPIO25-27, GPIO32-34
#include "voice.h"        // DFPlayer: UART2 GPIO16/17
#include "wifi.h"         // Wi-Fi AP + HTTP server

TaskHandle_t realtimeTask;   // Core 1 handle

// ── Remote command processor ─────────────────────────────────────
void processRemoteCommand(const String& cmd) {
  if      (cmd == "forward")   motorForward();
  else if (cmd == "backward")  motorBackward();
  else if (cmd == "left")      motorTurnLeft();
  else if (cmd == "right")     motorTurnRight();
  else if (cmd == "stop")      motorStop();
  else if (cmd.startsWith("sound/")) {
    int n = cmd.substring(6).toInt();
    if (n >= 1 && n <= 7) playSound((R2Sound)n);
  }
  else if (cmd.startsWith("dome/")) {
    int angle = cmd.substring(5).toInt();
    domeSnap(constrain(angle, 0, 180));
  }
}

unsigned long lastRemoteCmdMs     = 0;
const unsigned long REMOTE_TIMEOUT = 5000; // return to autonomous after 5s

// ── Core 1: real-time loop ───────────────────────────────────────
void realtimeLoop(void* param) {
  // Init all real-time systems on Core 1
  initAnimations();
  initSensors();
  initDisplay();
  initMotion();
  initVoiceSystem();

  for (;;) {
    if (!bootDone) { showBootScreen(); vTaskDelay(10); continue; }

    float dist   = readDistance();
    bool  motion = checkMotion();

    // Share state with Wi-Fi (Core 0 reads these)
    sharedDistance  = dist;
    sharedMotion    = motion;
    sharedDomeAngle = currentDomeAngle;

    // ── Remote command takes priority ──────────────────────────
    bool remoteActive = (millis() - lastRemoteCmdMs < REMOTE_TIMEOUT);

    if (remoteCommandPending) {
      String cmd = remoteCommand;
      remoteCommandPending = false;
      processRemoteCommand(cmd);
      lastRemoteCmdMs = millis();
      remoteActive    = true;
    }

    // ── Autonomous behaviour (when no remote command) ─────────
    if (!remoteActive) {
      if (dist < 30.0f) {
        domeSnap(90);
        motorStop();
      } else if (motion) {
        domeSnap(45);
      } else {
        domeIdleSweep();
      }
    }

    // ── Display + lights + voice (always) ─────────────────────
    if (dist < 15.0f)    showAlertScreen();
    else if (motion)     showMotionScreen();
    else                 showIdleScreen(dist);

    updateAnimationsSensors(dist, motion);
    updateVoice(dist, motion, currentState);

    vTaskDelay(10); // 10ms tick — 100Hz loop
  }
}

void setup() {
  Serial.begin(115200);
  Serial.println("╔═══════════════════════════════╗");
  Serial.println("║   R2-D2 — COMPLETE BUILD      ║");
  Serial.println("║   ESP32-S3 N16R8              ║");
  Serial.println("╚═══════════════════════════════╝");

  // Start Wi-Fi server on Core 0
  xTaskCreatePinnedToCore(
    wifiTask,       // function
    "WiFiTask",     // name
    8192,           // stack size (bytes)
    NULL,           // parameter
    1,              // priority
    NULL,           // task handle
    0               // core: 0
  );

  // Start real-time loop on Core 1
  xTaskCreatePinnedToCore(
    realtimeLoop,   // function
    "RTLoop",       // name
    8192,           // stack size
    NULL,           // parameter
    2,              // priority (higher than Wi-Fi)
    &realtimeTask,  // task handle
    1               // core: 1
  );

  // Arduino loop() runs on Core 1 by default — we've moved everything
  // to FreeRTOS tasks, so loop() is intentionally empty.
}

void loop() {
  vTaskDelay(portMAX_DELAY); // yield forever — all work done in tasks
}

The Final Master Wiring Diagram 🧭

C-3PO takes a deep breath and presents the complete diagram with a formality appropriate to the occasion.

C-3PO: "The final wiring diagram. Every component. Every wire. Every protection circuit. Every power rail. Downloadable as PDF. Printable. Frameable. I am... genuinely proud of this."

R2-D2 COMPLETE BUILD — Master Wiring Diagram
ESP32-S3 N16R8 | All Systems
════════════════════════════════════════════════════════════════════

POWER RAIL 1 — LOGIC (USB 5V regulated to 3.3V by ESP32-S3):
  USB 5V → ESP32-S3 VIN
  ESP32 3V3 output → (nothing external — 3.3V stays internal)
  ESP32 GND → Common GND rail

POWER RAIL 2 — 5V PERIPHERALS (L298N internal regulator from 9V):
  9V Battery (+) → L298N: VS
  9V Battery (−) → GND (common with ESP32 GND!)
  L298N 5V out → Servo VCC (red), 74AHCT125 VCC, DFPlayer VCC
  L298N GND → Servo GND, 74AHCT125 GND, DFPlayer GND

I2C BUS (conflict-resolved: SDA=GPIO4, SCL=GPIO5):
  ESP32 GPIO4 (SDA) ──── OLED SDA
  ESP32 GPIO5 (SCL) ──── OLED SCL
  ESP32 3V3         ──── OLED VCC (via 100µF cap to GND)

NEOPIXEL DOME (5V logic via level shifter):
  ESP32 GPIO6 ──── 74AHCT125 A1 ──── NeoPixel DIN
  L298N 5V    ──── NeoPixel 5V + 100µF cap+
  GND         ──── NeoPixel GND + 100µF cap−
  (470Ω resistor between 74AHCT125 Y1 output and NeoPixel DIN)

HC-SR04 ULTRASONIC (5V sensor, voltage divider on ECHO):
  ESP32 GPIO9  (TRIG) ──────────────── HC-SR04 TRIG
  HC-SR04 ECHO (5V)   ── 10kΩ ──┬──── ESP32 GPIO10
                                 └──── 20kΩ ──── GND

PIR MOTION SENSOR (5V output, voltage divider):
  L298N 5V    ──── PIR HC-SR501 VCC
  GND         ──── PIR HC-SR501 GND
  PIR OUT (5V) ── 10kΩ ──┬──── ESP32 GPIO2
                          └──── 20kΩ ──── GND

SERVO — DOME ROTATION (5V signal via level shifter):
  ESP32 GPIO14 ──── 74AHCT125 A2 ──── Servo signal (orange)
  L298N 5V     ──── Servo VCC (red)
  GND          ──── Servo GND (brown)

L298N MOTOR DRIVER:
  ESP32 GPIO25 ──── L298N IN1
  ESP32 GPIO26 ──── L298N IN2
  ESP32 GPIO27 ──── L298N ENA (PWM)
  ESP32 GPIO32 ──── L298N IN3
  ESP32 GPIO33 ──── L298N IN4
  ESP32 GPIO34 ──── L298N ENB (PWM)
  L298N OUT1,2 ──── DC Motor Left
  L298N OUT3,4 ──── DC Motor Right

DFPLAYER MINI AUDIO:
  L298N 5V    ──── DFPlayer VCC + 10µF cap+
  GND         ──── DFPlayer GND + 10µF cap−
  ESP32 GPIO17 ── (1kΩ) ─── DFPlayer RX
  DFPlayer TX ──── ESP32 GPIO16
  DFPlayer SPK1 ── Speaker +
  DFPlayer SPK2 ── Speaker −

Color code (master):
  RED    = 5V / VIN
  ORANGE = 9V battery rail
  PURPLE = 3.3V logic
  BLACK  = GND (common rail)
  GREEN  = NeoPixel data (level-shifted 5V)
  BLUE   = Servo signal (level-shifted 5V)
  YELLOW = Motor direction pins (IN1-IN4)
  WHITE  = Motor PWM enable pins (ENA, ENB)
  CYAN   = I2C SDA (GPIO4)
  PINK   = I2C SCL (GPIO5)
  BROWN  = HC-SR04 TRIG (GPIO9)
  VIOLET = HC-SR04 ECHO with divider (GPIO10)
  GREY   = PIR output with divider (GPIO2)
  MAROON = DFPlayer UART (TX=GPIO17, RX=GPIO16)

COMPLETE Connection Table:
┌──────────────────────┬──────────────────────────────────────────┐
│ From                 │ To                                       │
├──────────────────────┼──────────────────────────────────────────┤
│ USB 5V               │ ESP32-S3 VIN                             │
│ 9V Battery (+)       │ L298N VS                                 │
│ 9V Battery (−)       │ L298N GND + ESP32 GND (common)           │
│ L298N 5V             │ Servo VCC, 74AHCT125 VCC, DFPlayer VCC   │
│ ESP32 GPIO4 (SDA)    │ OLED SDA                                 │
│ ESP32 GPIO5 (SCL)    │ OLED SCL                                 │
│ ESP32 3V3            │ OLED VCC (+ 100µF cap to GND)            │
│ ESP32 GPIO6          │ 74AHCT125 A1 → (470Ω) → NeoPixel DIN     │
│ ESP32 GPIO9 (TRIG)   │ HC-SR04 TRIG                             │
│ HC-SR04 ECHO (5V)    │ 10k+20k divider → ESP32 GPIO10           │
│ L298N 5V             │ PIR VCC                                  │
│ PIR OUT (5V)         │ 10k+20k divider → ESP32 GPIO2            │
│ ESP32 GPIO14         │ 74AHCT125 A2 → Servo signal (orange)     │
│ ESP32 GPIO25         │ L298N IN1                                │
│ ESP32 GPIO26         │ L298N IN2                                │
│ ESP32 GPIO27 (PWM)   │ L298N ENA                                │
│ ESP32 GPIO32         │ L298N IN3                                │
│ ESP32 GPIO33         │ L298N IN4                                │
│ ESP32 GPIO34 (PWM)   │ L298N ENB                                │
│ L298N OUT1,2         │ DC Motor A                               │
│ L298N OUT3,4         │ DC Motor B                               │
│ L298N 5V             │ DFPlayer VCC + 10µF cap+                 │
│ ESP32 GPIO17 (TX2)   │ 1kΩ → DFPlayer RX                        │
│ DFPlayer TX          │ ESP32 GPIO16 (RX2)                       │
│ DFPlayer SPK1        │ Speaker terminal 1                       │
│ DFPlayer SPK2        │ Speaker terminal 2                       │
└──────────────────────┴──────────────────────────────────────────┘

⚡ Critical Notes:
  - 9V battery GND MUST connect to ESP32 GND (common ground)
  - 74AHCT125 handles BOTH NeoPixel AND servo level-shift
  - HC-SR04 ECHO and PIR output: voltage dividers MANDATORY on ESP32-S3
  - DFPlayer RX 1kΩ resistor is mandatory
  - OLED I2C now on GPIO4(SDA)/GPIO5(SCL) — conflict with GPIO9 resolved

C-3PO: "Download the PDF. All twenty-three connection rows. Printed. Laminated if possible. This is the complete blueprint of R2-D2."

Final Compile 🚀

✓ Compilation successful
  Board:        ESP32-S3 N16R8
  Files:        r2d2-main.ino + 6 headers
  Binary:       634,512 bytes (9.1% of 16MB Flash)
  RAM:          Used 52,416 bytes (16.0% of 327KB)
  PSRAM:        8.0 MB free
  Wi-Fi:        Access Point mode — SSID: "R2-D2"
  Dual-core:    Core 0: Wi-Fi/HTTP | Core 1: Real-time control

Click Upload.

The ESP32-S3 boots. The OLED shows "R2-D2 ONLINE." The startup fanfare plays from the speaker. The dome LEDs breathe. The servo sweeps. The Serial Monitor shows:

╔═══════════════════════════════╗
║   R2-D2 — COMPLETE BUILD      ║
║   ESP32-S3 N16R8              ║
╚═══════════════════════════════╝
OLED projector online!
Dome servo centred.
Motor driver online.
DFPlayer Mini online!
R2-D2 says: [sound 5]
[WiFi] AP started: R2-D2
[WiFi] IP: 192.168.4.1
[WiFi] HTTP server started — connect to R2-D2 network
All systems ONLINE. R2-D2 is ready.
Distance: 95 cm — SAFE

Pick up your phone. Connect to the "R2-D2" Wi-Fi network. Password: beepboop. Open a browser. Navigate to 192.168.4.1.

A simple control page appears. Blue on black. R2-D2's face.

Tap "Forward."

The wheels turn.

Tap "Happy."

R2's happy whistle plays.

Tap "Dome ◄."

The dome snaps left.

The Final Milestone 🚩

Milestone: "R2-D2 COMPLETE — Episode 8 Final Build"

Every episode. Every system. Every milestone. All saved. All restorable.

The Complete Droid 🤖

The workshop is quiet. The crew stands in a circle around R2-D2 — the completed droid. Dome rotating. Lights breathing. OLED projecting. Speaker quiet for now, waiting.

OBI-WAN: "You see what has been built. Not just a robot. Not just a collection of components. The process itself is the lesson — the way Codey lowered every barrier between the idea and the creation. You described. It wrote. You compiled. It fixed. You drew. It diagrammed. Each episode, a little more complex. Each episode, possible."

LUKE: "Eight episodes. I went from blinking an LED to a Wi-Fi controlled droid with dome lights, sensors, a display, motors, and audio. And I'm not a programmer."

HAN: "Kid, I've seen the Millennium Falcon held together with less intentionality than this thing. And the Falcon can make the Kessel Run."

R2-D2 beeps. Loudly. Repeatedly. Proudly.

C-3PO: "He says — and I am translating precisely — 'I told you all it would work.'"

A long pause.

C-3PO: "He also says thank you. Which, from Artoo, is quite remarkable."

Obi-Wan smiles.

OBI-WAN: "The Force will be with you. Always."

R2-D2 plays his startup fanfare one more time. The dome lights sweep blue-white. The OLED displays: "MISSION COMPLETE."

The Series Map — What We Built 🗺️

Episode	System	Board	Codey Feature Spotlight
1	First LED blink	Arduino UNO R3	Account setup, first sketch, first wiring diagram
2	Piezo sound	Arduino UNO R3	Smart Library Picker, tone(), Serial Monitor
3	NeoPixel dome	Arduino UNO R3	Voltage safety check, FastLED, multi-file project
4	Sensor eye	Arduino UNO R3	Auto Error Fixing, Vision photo upload
5	OLED projector	ESP32-S3 N16R8	Board upgrade, Milestones & Rollback, I2C
6	Motion systems	ESP32-S3 N16R8	LEDC servo, L298N motors, two-rail wiring
7	Audio voice	ESP32-S3 N16R8	DFPlayer Mini, UART, Live Serial Monitor
8	Complete droid	ESP32-S3 N16R8	Deep Think mode, Wi-Fi, dual-core, final diagram

🔗 Resources

Codey Online: codey.online
ESP32-S3 technical reference: docs.espressif.com/esp32-s3
ArduinoJson library: arduinojson.org
ESP32 FreeRTOS tasks: freertos.org/documentation
OTRONIC / Codey: otronic.nl | codey.online

🤖 R2D2 Creation with Codey — eight episodes, one complete droid, infinite possibilities. The Force — and the cloud compiler — were with us. Always.

R2D2 Creation with Codey 🤖 Ep.7

Willem van Heemstra — Sun, 07 Jun 2026 14:14:05 +0000

Episode 7: The Voice of the Galaxy

"Artoo, I Wish We Didn't Have to Listen to You Sometimes" 🔊

C-3PO enters the workshop clutching a small speaker and a DFPlayer Mini module.

C-3PO: "I want to state, for the record, that I have mixed feelings about this episode. On one hand, R2-D2's communication through audio files will be considerably clearer than whatever he has been doing with that piezo buzzer. On the other hand, once we enable full audio playback, he will never. Stop. Talking."

R2-D2 beeps at considerable volume.

C-3PO: "See? He's already celebrating. This is going to be exhausting."

Han Solo leans against the doorframe.

HAN: "What he said. Let's wire it up anyway."

🗂️ SIPOC — The Voice System

Suppliers	Inputs	Process	Outputs	Customers
You (the maker)	"Add DFPlayer Mini on UART2, microSD with R2-D2 sounds, trigger by sensor events"	Codey picks DFRobotDFPlayerMini library, writes Serial2 init code, maps sounds to events	Complete voice.h — sound triggers for every R2-D2 state	ESP32-S3 UART2 → DFPlayer Mini → Speaker
DFPlayer Mini	5V power, RX/TX from ESP32-S3 UART2	Reads MP3/WAV files from microSD by number, decodes audio	Amplified audio signal to speaker	Speaker — which produces actual R2-D2 sounds
microSD card (≤32GB FAT32)	MP3 or WAV files named 0001.mp3, 0002.mp3...	DFPlayer reads by file number	Audio playback	Speaker
Live Serial Monitor	ESP32-S3 Serial.print() output at 115200 baud	Shows state transitions, sound triggers, distance readings in real time	A running log of what R2-D2 is doing and thinking	You — debugging without a logic analyser
Codey Smart Library Picker	"DFPlayer Mini" mentioned in prompt	Automatically includes DFRobotDFPlayerMini.h and the correct library	Code that compiles first time with correct API calls	You — no library hunting required

The Components 🔧

Yoda examines the DFPlayer Mini with one ear raised.

YODA: "A small board. Powerful it is. Speaks the language of MP3, it does. Talks to the ESP32 through UART, it does. Patient with the timing, you must be — 200 milliseconds after power-on, it needs."

Component	Quantity	Notes
ESP32-S3 N16R8	1	Our brain
DFPlayer Mini	1	MP3/WAV player module, 3V3–5V
Speaker (4Ω or 8Ω, 0.5W–3W)	1	Connect directly to DFPlayer SPK1/SPK2
microSD card (≤32GB)	1	Format FAT32, files named 0001.mp3 etc.
1kΩ resistor	1	On DFPlayer RX line — prevents voltage noise
10µF capacitor (electrolytic)	1	Between DFPlayer VCC and GND — power filtering
Jumper wires	5

Preparing the microSD Card

Format your microSD as FAT32. Create a folder called mp3 at the root. Name your files:

/mp3/
  0001.mp3  ← R2-D2 "happy" whistle sequence
  0002.mp3  ← R2-D2 "alert" rapid beeps
  0003.mp3  ← R2-D2 "sad" descending moan
  0004.mp3  ← R2-D2 "question" rising whistle
  0005.mp3  ← R2-D2 "startup" fanfare
  0006.mp3  ← R2-D2 "motion detected" warble
  0007.mp3  ← R2-D2 "danger close" urgent alarm

C-3PO: "I would suggest downloading these from any reputable Star Wars sound effects collection. The DFPlayer cares only about the filenames — it does not evaluate artistic merit."

R2-D2 beeps indignantly.

C-3PO: "I am sure your sounds are excellent, Artoo."

The Codey Prompt 🎙️

Luke sits at the keyboard.

LUKE: "I love how this works now. I just describe what I want and Codey handles the library, the setup, all of it."

In Agent mode:

We're continuing R2-D2 on ESP32-S3 N16R8.

Add a DFPlayer Mini MP3 module for R2-D2 voice responses:
  - DFPlayer connected to ESP32-S3 UART2
  - TX2 = GPIO17 → DFPlayer RX (through 1kΩ resistor)
  - RX2 = GPIO16 ← DFPlayer TX
  - DFPlayer powered from L298N 5V rail
  - 10µF capacitor across DFPlayer VCC/GND
  - Speaker connected to DFPlayer SPK1 and SPK2 (no extra amp needed)

Sound file mapping on microSD (/mp3/ folder):
  1 = R2 happy whistle (play when idle, randomly every 30-60 seconds)
  2 = R2 alert beeps (play when object < 30cm)
  3 = R2 sad moan (play when object < 15cm, stuck)
  4 = R2 question whistle (play when motion first detected)
  5 = R2 startup fanfare (play once on boot)
  6 = R2 motion warble (sustained during motion-scan state)
  7 = R2 danger alarm (play when object < 15cm, loop until clear)

Remove the piezo buzzer — DFPlayer replaces it.
Create voice.h for all audio functions.
Use DFRobotDFPlayerMini library.
The DFPlayer needs 200ms settle time after Serial2.begin() before commands.
Show Serial Monitor output for all sound triggers at 115200 baud.

Codey's Smart Library Picker Response

I'll use the DFRobotDFPlayerMini library for the DFPlayer Mini.
This library is pre-installed on Codey's compile servers.

I'll include:
  #include <DFRobotDFPlayerMini.h>

And use Serial2 on the ESP32-S3 for the DFPlayer communication.
Serial2 on ESP32-S3: RX=GPIO16, TX=GPIO17 by default.

Generating voice.h now...

Generated `voice.h`

// voice.h — R2-D2 Voice System
// DFPlayer Mini on ESP32-S3 UART2 (TX=GPIO17, RX=GPIO16)
// microSD: /mp3/0001.mp3 through 0007.mp3

#pragma once
#include <DFRobotDFPlayerMini.h>

// ── DFPlayer setup ───────────────────────────────────────────────
DFRobotDFPlayerMini dfPlayer;
bool dfPlayerReady = false;

// ── Sound IDs (match filenames on microSD) ───────────────────────
enum R2Sound {
  SOUND_HAPPY    = 1,
  SOUND_ALERT    = 2,
  SOUND_SAD      = 3,
  SOUND_QUESTION = 4,
  SOUND_STARTUP  = 5,
  SOUND_MOTION   = 6,
  SOUND_DANGER   = 7,
};

// ── Random idle chatter timing ───────────────────────────────────
unsigned long nextIdleChatterMs = 0;
const unsigned long CHATTER_MIN = 30000UL;  // 30 seconds
const unsigned long CHATTER_MAX = 60000UL;  // 60 seconds

void scheduleNextChatter() {
  nextIdleChatterMs = millis() + CHATTER_MIN
    + (unsigned long)(random(CHATTER_MAX - CHATTER_MIN));
}

// ── Initialise DFPlayer ──────────────────────────────────────────
bool initVoice() {
  // ESP32-S3 UART2: RX=GPIO16, TX=GPIO17
  Serial2.begin(9600, SERIAL_8N1, 16, 17);

  // DFPlayer needs 200ms to settle after Serial begin
  delay(200);

  if (!dfPlayer.begin(Serial2, /*isACK=*/true, /*doReset=*/true)) {
    Serial.println("DFPlayer Mini not detected — check wiring!");
    Serial.println("  • Is the microSD inserted?");
    Serial.println("  • Is the 1kΩ resistor on the DFPlayer RX line?");
    Serial.println("  • Is VCC on the 5V rail?");
    return false;
  }

  dfPlayer.volume(25);   // 0–30 (25 = ~83% volume — plenty for a droid)
  dfPlayerReady = true;
  Serial.println("DFPlayer Mini online! R2-D2 voice system ready.");

  // Play startup fanfare
  playSound(SOUND_STARTUP);
  scheduleNextChatter();
  return true;
}

// ── Play a sound ─────────────────────────────────────────────────
void playSound(R2Sound sound) {
  if (!dfPlayerReady) return;
  dfPlayer.play(sound);
  Serial.print("R2-D2 says: [sound ");
  Serial.print(sound);
  Serial.println("]");
}

// ── Stop current playback ────────────────────────────────────────
void stopSound() {
  if (!dfPlayerReady) return;
  dfPlayer.stop();
}

// ── Update: called every loop — handles idle chatter ────────────
void updateVoice(float distance, bool motion, DomeState domeState) {
  if (!dfPlayerReady) return;

  unsigned long now = millis();

  // DFPlayer print errors to Serial — check occasionally
  if (dfPlayer.available()) {
    uint8_t type  = dfPlayer.readType();
    int     value = dfPlayer.read();
    if (type == DFPlayerError) {
      Serial.print("DFPlayer error: ");
      Serial.println(value);
    }
  }

  // Danger: object very close
  if (distance < 15.0f) {
    static bool dangerPlaying = false;
    if (!dangerPlaying) {
      playSound(SOUND_DANGER);
      dangerPlaying = true;
    }
    return;
  } else {
    static bool dangerPlaying = false;
    if (dangerPlaying) {
      stopSound();
      dangerPlaying = false;
    }
  }

  // Alert zone: approaching
  if (distance < 30.0f) {
    static unsigned long lastAlertMs = 0;
    if (now - lastAlertMs > 4000) {
      playSound(SOUND_ALERT);
      lastAlertMs = now;
    }
    return;
  }

  // Motion: play question on first detection
  if (motion) {
    static bool motionSoundPlayed = false;
    if (!motionSoundPlayed) {
      playSound(SOUND_QUESTION);
      motionSoundPlayed = true;
    }
    return;
  } else {
    static bool motionSoundPlayed = false;
    motionSoundPlayed = false;
  }

  // Idle chatter: random happy whistle
  if (now >= nextIdleChatterMs) {
    playSound(SOUND_HAPPY);
    scheduleNextChatter();
  }
}

void initVoiceSystem() {
  randomSeed(esp_random());  // True random seed from ESP32 hardware RNG
  initVoice();
}

Updated `r2d2-main.ino`

#include <Adafruit_NeoPixel.h>
#include "sounds.h"      // LEDC buzzer (backup only, mostly replaced)
#include "animations.h"  // NeoPixel dome
#include "sensors.h"     // HC-SR04 + PIR
#include "display.h"     // SSD1306 OLED
#include "motion.h"      // Servo + motors
#include "voice.h"       // DFPlayer Mini

void setup() {
  Serial.begin(115200);
  Serial.println("═══════════════════════════════");
  Serial.println("  R2-D2 ESP32-S3 Boot Sequence");
  Serial.println("═══════════════════════════════");

  initSounds();
  initAnimations();
  initSensors();
  initDisplay();
  initMotion();
  initVoiceSystem();   // ← new

  Serial.println("All systems ONLINE. R2-D2 is ready.");
}

void loop() {
  if (!bootDone) { showBootScreen(); return; }

  float dist   = readDistance();
  bool  motion = checkMotion();

  // ── Motion (dome + wheels) ──────────────────────────────────
  if (dist < 30.0f) {
    domeSnap(90);
    motorStop();
  } else if (motion) {
    domeSnap(45);
  } else {
    domeIdleSweep();
  }

  // ── Display ─────────────────────────────────────────────────
  if (dist < 15.0f)    showAlertScreen();
  else if (motion)     showMotionScreen();
  else                 showIdleScreen(dist);

  // ── Dome lights ─────────────────────────────────────────────
  updateAnimationsSensors(dist, motion);

  // ── Voice ────────────────────────────────────────────────────
  updateVoice(dist, motion, currentState);
}

Wiring Diagram — Adding the Voice Module 🧭

C-3PO presents the updated diagram with a satisfied nod.

C-3PO: "The DFPlayer Mini connects to UART2 on the ESP32-S3. Note the 1kΩ resistor on the RX line of the DFPlayer — this prevents communication noise that can cause the module to behave erratically. I am noting this specifically because I have personally witnessed the consequences of omitting it, and it is not pleasant."

R2-D2 Voice System Addition — ESP32-S3 N16R8
════════════════════════════════════════════════════════════

DFPLAYER MINI CONNECTIONS:
  L298N 5V      ──── DFPlayer VCC
  L298N 5V      ──── 10µF cap + (filter)
  GND           ──── DFPlayer GND + 10µF cap −
  ESP32 GPIO17  ──── (1kΩ) ──── DFPlayer RX
  DFPlayer TX   ──── ESP32 GPIO16
  DFPlayer SPK1 ──── Speaker terminal 1
  DFPlayer SPK2 ──── Speaker terminal 2

MicroSD Card:
  Inserted directly into DFPlayer Mini SD slot
  Formatted FAT32, files in /mp3/ folder

Color code (additions):
  PINK   = DFPlayer TX (audio data from module)
  CYAN   = DFPlayer RX (commands to module)
  GREY   = Through 1kΩ resistor on DFPlayer RX

Connection Table (additions):
┌──────────────────────┬──────────────────────────────────┐
│ From                 │ To                               │
├──────────────────────┼──────────────────────────────────┤
│ L298N 5V             │ DFPlayer VCC                     │
│ L298N 5V             │ 10µF cap: + (long leg)           │
│ GND (common)         │ DFPlayer GND + 10µF cap: −       │
│ ESP32 GPIO17 (TX2)   │ 1kΩ resistor → DFPlayer RX       │
│ DFPlayer TX          │ ESP32 GPIO16 (RX2)               │
│ DFPlayer SPK1        │ Speaker terminal 1               │
│ DFPlayer SPK2        │ Speaker terminal 2               │
└──────────────────────┴──────────────────────────────────┘

⚡ Notes:
  - DFPlayer powered from 5V — DO NOT use ESP32 3V3 (insufficient current)
  - 1kΩ resistor on DFPlayer RX is mandatory — prevents communication errors
  - Speaker: 4Ω or 8Ω, 0.5W minimum — DFPlayer can drive it directly
  - MicroSD must be FAT32, files named 0001.mp3–0007.mp3 in /mp3/ folder

The Live Serial Monitor — Watching R2 Think 📟

After uploading, open Codey's Live Serial Monitor at 115200 baud.

As R2 runs:

Serial Monitor — 115200 baud
─────────────────────────────────────────────────────────
═══════════════════════════════
  R2-D2 ESP32-S3 Boot Sequence
═══════════════════════════════
OLED projector online!
Dome servo centred.
Motor driver online.
DFPlayer Mini online! R2-D2 voice system ready.
R2-D2 says: [sound 5]        ← Startup fanfare!
All systems ONLINE. R2-D2 is ready.

Distance: 124 cm — SAFE
Distance: 119 cm — SAFE
R2-D2 says: [sound 1]        ← Idle chatter (random)
Motion detected — scan mode!
R2-D2 says: [sound 4]        ← Question whistle
State → SCAN
Distance: 28 cm — CAUTION
R2-D2 says: [sound 2]        ← Alert!
Distance: 12 cm — DANGER
R2-D2 says: [sound 7]        ← Danger alarm!
State → ALERT
Distance: 85 cm — SAFE       ← Object moved away

HAN: "Look at that. Every event logged. Every sound triggered. You can see exactly what he's thinking. That's not just a droid — that's a droid with a diary."

R2-D2 beeps something that sounds like "I would prefer more privacy, actually."

Compile and Upload 🚀

✓ Compilation successful
  Board:   ESP32-S3 N16R8
  Sketch:  r2d2-main.ino + 6 headers
  Binary:  554,768 bytes (8.0% of 16MB Flash)
  RAM:     Used 41,240 bytes (12.6% of 327KB)
  PSRAM:   7.9 MB free — plenty for Episode 8 additions

The ESP32-S3 boots. The OLED displays "R2-D2 ONLINE." The dome LEDs breathe blue-white. The dome servo sweeps gently.

Then — from the speaker — a clear, unmistakable R2-D2 startup whistle.

C-3PO: quietly "...Oh my."

R2-D2 — the real one — goes completely silent. Then a single, emotional beep.

LUKE: "He recognises it. He recognises his own voice."

Save Milestone 🚩

Milestone: "R2-D2 Voice System — Episode 7 Complete"

Six systems. All running. All talking to each other. R2-D2 has lights, sound, a display, sensors, motion, and a voice. There is one episode left.

What's Next: The Complete Droid 🤖

The entire Star Wars crew assembles in the workshop. Han. Luke. Obi-Wan. C-3PO. And there, in the centre — R2-D2, all systems operational, blue dome glowing, OLED projecting status, dome rotating in a gentle scan, audio clips playing softly.

Obi-Wan speaks.

OBI-WAN: "In the final episode, we bring every system together into a single, cohesive, complete R2-D2. We explore the ESP32-S3's Wi-Fi capabilities. We use Codey's Deep Think mode for the most complex orchestration code. We draw the final complete wiring diagram — every component, every wire, every protection circuit. And we save the last milestone. The droid is nearly complete."

R2-D2 plays sound 1: his happy whistle.

Everyone smiles.

🔗 Resources

DFRobotDFPlayerMini library: github.com/DFRobot/DFRobotDFPlayerMini
ESP32-S3 UART: docs.espressif.com/esp32-s3/uart
Codey Live Serial Monitor: codey.online

🤖 R2D2 Creation with Codey — building the galaxy's greatest droid, one episode at a time. May the Force — and the cloud compiler — be with you.

R2D2 Creation with Codey 🤖 Ep.6

Willem van Heemstra — Sun, 07 Jun 2026 14:13:56 +0000

Episode 6: Let the Wookiee Win — R2 Moves!

"Would Somebody Get This Big Walking Carpet Out of My Way?" 🦾

Han Solo enters the workshop with the energy of someone who has been waiting since Episode 1 for this moment.

HAN: "Okay, look. I've put up with the blinking LED. The beeps were cute. The screen — fine, useful. But I need this droid to actually MOVE. Because right now he's sitting there like a very opinionated lamp and I am not impressed."

R2-D2 beeps at high volume and at length.

HAN: "Yeah yeah, I know, you're very capable. Prove it. Episode 6. Let's go."

Somewhere, a Wookiee roars enthusiastically.

HAN: "Chewie agrees. Let the droid move."

🗂️ SIPOC — The Motion System

Suppliers	Inputs	Process	Outputs	Customers
You (the maker)	"Add servo for dome rotation on GPIO14, L298N motor driver for wheels on GPIO pins 25-27"	Codey writes ESP32-S3 LEDC servo code + L298N motor control, generates motion.h	Dome that sweeps left and right, wheels that drive forward/back/turn	R2-D2 — who finally lives up to his reputation
ESP32-S3 LEDC PWM	50Hz PWM signal, 3.3V	Drives servo signal line (with level shifter)	Dome servo at 0°, 45°, 90°, 135°, 180°	SG90 servo — which rotates R2's dome
L298N Motor Driver	5V–12V external power, direction + PWM signals from ESP32-S3	H-bridge controls current direction to each DC motor	Forward / backward / left turn / right turn	Two DC motors — which drive R2's wheels
Codey Wiring Diagram	Full component list including motor power requirements	Draws color-coded diagram with separate power rail for motors	Two-rail wiring diagram: logic (3.3V) + motor power	You — who correctly separate the motor power from the logic power

The Components 🔧

Yoda examines the motor driver with a long, thoughtful look.

YODA: "Moving parts, added today we are. Careful, one must be. Motors, hungry for current they are. Directly from the ESP32-S3, power them you must not — destroyed, your microcontroller would be."

Component	Quantity	Notes
ESP32-S3 N16R8	1	Our brain from Episode 5
SG90 micro servo	1	For dome rotation — 5V, 3-wire
L298N dual H-bridge motor driver	1	Drives two DC motors, needs separate 5V–12V
DC gear motors with wheels	2	3V–6V, ~200mA stall current each
74AHCT125 level shifter	1	Servo signal: 3.3V → 5V
9V battery or 2S LiPo	1	Motor power supply — separate from logic
Jumper wires	12	Several gauge sizes
USB cable	1

YODA: "Two power rails, we shall have. Logic power: USB 5V → 3.3V for ESP32-S3. Motor power: separate battery for L298N and motors. Cross them, you must not."

The ESP32-S3 and Servo Control: LEDC at 50Hz ⚙️

C-3PO raises a cautionary finger.

C-3PO: "I must explain the servo PWM situation. The Arduino Servo library used the Timer1 hardware. On the ESP32-S3, we use the LEDC peripheral — the same one we used for the buzzer tone in Episode 5, but configured at 50Hz for servo control. A standard hobby servo expects a pulse between 0.5ms and 2.5ms at a 50Hz frequency. Codey handles this calculation automatically."

HAN: "Three-PO. The servo. Just the servo."

C-3PO: "Yes. Moving on."

In Agent mode:

We're continuing R2-D2 on ESP32-S3 N16R8.

Add motion systems:

1. SG90 servo for dome rotation:
   - Signal on GPIO14 (through 74AHCT125 level shifter)
   - 5V power from VIN rail
   - Create these movements:
     a. idle_scan: slow sweep 60°→120° and back, 3 second period
     b. alert_snap: snap to face sensor direction
     c. full_sweep: 0° to 180° and back when "happy"

2. L298N motor driver for two DC wheels:
   - Motor A: IN1=GPIO25, IN2=GPIO26, ENA=GPIO27 (PWM)
   - Motor B: IN3=GPIO32, IN4=GPIO33, ENB=GPIO34 (PWM)
   - Create: forward(), backward(), turnLeft(), turnRight(), stop()
   - Speed: 0-255 mapped to LEDC duty cycle

3. Behavior: when distance < 30cm → stop + snap dome toward sensor
   When motion detected → sweep dome toward source

Create motion.h file for all motion code.
Keep existing animations.h, sensors.h, display.h, sounds.h unchanged.

Generated `motion.h`

// motion.h — R2-D2 Motion System
// Dome servo + DC wheel motors via L298N
// ESP32-S3 N16R8

#pragma once

// ── SERVO (dome rotation) ────────────────────────────────────────
#define SERVO_PIN     14     // GPIO14 — through 74AHCT125 to servo
#define SERVO_CHANNEL 1      // LEDC channel (channel 0 used by buzzer)

// Servo pulse widths in microseconds
#define SERVO_MIN_US  500    // 0°
#define SERVO_MID_US  1500   // 90° (centre)
#define SERVO_MAX_US  2500   // 180°

// LEDC config for servo: 50Hz, 16-bit resolution (allows fine pulse control)
#define SERVO_FREQ    50
#define SERVO_RES     16     // 16-bit → 0–65535

int currentDomeAngle = 90;     // Start centred
int targetDomeAngle  = 90;
int domeSweepDir     = 1;      // +1 or -1 for idle sweep
unsigned long lastServoMs = 0;

void initServo() {
  ledcSetup(SERVO_CHANNEL, SERVO_FREQ, SERVO_RES);
  ledcAttachPin(SERVO_PIN, SERVO_CHANNEL);
  // Centre the dome on startup
  int pulse   = map(90, 0, 180, SERVO_MIN_US, SERVO_MAX_US);
  int duty    = (int)((float)pulse / 20000.0f * 65535.0f);
  ledcWrite(SERVO_CHANNEL, duty);
  Serial.println("Dome servo centred.");
}

void setDomeAngle(int angle) {
  angle = constrain(angle, 0, 180);
  int pulse = map(angle, 0, 180, SERVO_MIN_US, SERVO_MAX_US);
  int duty  = (int)((float)pulse / 20000.0f * 65535.0f);
  ledcWrite(SERVO_CHANNEL, duty);
  currentDomeAngle = angle;
}

// Idle: slow sweep 60° ↔ 120°
void domeIdleSweep() {
  unsigned long now = millis();
  if (now - lastServoMs < 30) return;
  lastServoMs = now;

  currentDomeAngle += domeSweepDir;
  if (currentDomeAngle >= 120) domeSweepDir = -1;
  if (currentDomeAngle <= 60)  domeSweepDir =  1;
  setDomeAngle(currentDomeAngle);
}

// Snap to angle quickly (alert behaviour)
void domeSnap(int angle) {
  setDomeAngle(angle);
}

// Full sweep 0°→180°→0° (happy behaviour)
unsigned long fullSweepMs = 0;
int   fullSweepAngle = 0;
int   fullSweepDir   = 1;
bool  fullSweepDone  = false;

void domeSweepFull() {
  unsigned long now = millis();
  if (now - fullSweepMs < 12) return;
  fullSweepMs = now;

  fullSweepAngle += fullSweepDir * 2;
  if (fullSweepAngle >= 180) { fullSweepDir = -1; }
  if (fullSweepAngle <= 0)   { fullSweepDone = true; }
  setDomeAngle(fullSweepAngle);
}

// ── L298N MOTOR DRIVER ────────────────────────────────────────────
#define MOTOR_A_IN1  25
#define MOTOR_A_IN2  26
#define MOTOR_A_EN   27   // PWM channel 2

#define MOTOR_B_IN3  32
#define MOTOR_B_IN4  33
#define MOTOR_B_EN   34   // PWM channel 3

#define MOTOR_CHANNEL_A  2
#define MOTOR_CHANNEL_B  3
#define MOTOR_FREQ       5000   // 5kHz PWM for motors
#define MOTOR_RES        8      // 8-bit → 0–255

void initMotors() {
  // Direction pins
  pinMode(MOTOR_A_IN1, OUTPUT);
  pinMode(MOTOR_A_IN2, OUTPUT);
  pinMode(MOTOR_B_IN3, OUTPUT);
  pinMode(MOTOR_B_IN4, OUTPUT);

  // PWM channels for enable pins
  ledcSetup(MOTOR_CHANNEL_A, MOTOR_FREQ, MOTOR_RES);
  ledcSetup(MOTOR_CHANNEL_B, MOTOR_FREQ, MOTOR_RES);
  ledcAttachPin(MOTOR_A_EN, MOTOR_CHANNEL_A);
  ledcAttachPin(MOTOR_B_EN, MOTOR_CHANNEL_B);

  // Start stopped
  ledcWrite(MOTOR_CHANNEL_A, 0);
  ledcWrite(MOTOR_CHANNEL_B, 0);
  Serial.println("Motor driver online.");
}

void motorForward(uint8_t speed = 180) {
  digitalWrite(MOTOR_A_IN1, HIGH); digitalWrite(MOTOR_A_IN2, LOW);
  digitalWrite(MOTOR_B_IN3, HIGH); digitalWrite(MOTOR_B_IN4, LOW);
  ledcWrite(MOTOR_CHANNEL_A, speed);
  ledcWrite(MOTOR_CHANNEL_B, speed);
}

void motorBackward(uint8_t speed = 180) {
  digitalWrite(MOTOR_A_IN1, LOW);  digitalWrite(MOTOR_A_IN2, HIGH);
  digitalWrite(MOTOR_B_IN3, LOW);  digitalWrite(MOTOR_B_IN4, HIGH);
  ledcWrite(MOTOR_CHANNEL_A, speed);
  ledcWrite(MOTOR_CHANNEL_B, speed);
}

void motorTurnLeft(uint8_t speed = 150) {
  // Left motor backward, right motor forward = left turn
  digitalWrite(MOTOR_A_IN1, LOW);  digitalWrite(MOTOR_A_IN2, HIGH);
  digitalWrite(MOTOR_B_IN3, HIGH); digitalWrite(MOTOR_B_IN4, LOW);
  ledcWrite(MOTOR_CHANNEL_A, speed);
  ledcWrite(MOTOR_CHANNEL_B, speed);
}

void motorTurnRight(uint8_t speed = 150) {
  // Left motor forward, right motor backward = right turn
  digitalWrite(MOTOR_A_IN1, HIGH); digitalWrite(MOTOR_A_IN2, LOW);
  digitalWrite(MOTOR_B_IN3, LOW);  digitalWrite(MOTOR_B_IN4, HIGH);
  ledcWrite(MOTOR_CHANNEL_A, speed);
  ledcWrite(MOTOR_CHANNEL_B, speed);
}

void motorStop() {
  ledcWrite(MOTOR_CHANNEL_A, 0);
  ledcWrite(MOTOR_CHANNEL_B, 0);
  digitalWrite(MOTOR_A_IN1, LOW); digitalWrite(MOTOR_A_IN2, LOW);
  digitalWrite(MOTOR_B_IN3, LOW); digitalWrite(MOTOR_B_IN4, LOW);
}

void initMotion() {
  initServo();
  initMotors();
}

Updated `r2d2-main.ino` loop

// Loop addition — reactive motion

void loop() {
  if (!bootDone) { showBootScreen(); return; }

  float dist   = readDistance();
  bool  motion = checkMotion();

  // ── Dome behaviour ─────────────────────────────────────────
  if (dist < 30.0f) {
    domeSnap(90);       // face forward, something is ahead
    motorStop();        // stop wheels — obstacle!
  } else if (motion) {
    domeSnap(45);       // snap left — motion detected
  } else {
    domeIdleSweep();    // gentle idle scan
  }

  // ── Display ─────────────────────────────────────────────────
  if (dist < 15.0f)    showAlertScreen();
  else if (motion)     showMotionScreen();
  else                 showIdleScreen(dist);

  // ── Dome lights ─────────────────────────────────────────────
  updateAnimationsSensors(dist, motion);
}

The Wiring Diagram — Two Power Rails 🧭

C-3PO studies the diagram, then exhales slowly.

C-3PO: "Codey has correctly separated the power rails. The logic rail — 3.3V from the ESP32-S3 regulator — powers only the microcontroller and the OLED. The motor rail — the external 9V battery through the L298N's onboard 5V regulator — powers the motors and the servo. This is exactly correct. Mixing them would cause voltage drops that would reset the ESP32-S3 every time a motor starts."

R2-D2 Motion System — Wiring Diagram (ESP32-S3 N16R8)
════════════════════════════════════════════════════════════════

POWER RAIL 1 — LOGIC (USB 5V → ESP32-S3 regulator):
  USB 5V  ──── ESP32-S3 VIN
  ESP32 3V3 ── OLED VCC
  ESP32 GND ── OLED GND, logic GND rail

POWER RAIL 2 — MOTOR POWER (9V battery):
  9V Bat (+) ── L298N: VS (motor supply)
  9V Bat (−) ── L298N: GND (common ground with ESP32 GND)
  L298N: 5V  ── Servo VCC (5V regulated output)
  L298N: 5V  ── 74AHCT125: VCC
  L298N: GND ── Servo GND, 74AHCT125 GND

  ⚠️  IMPORTANT: ESP32 GND and battery GND must be connected together!

SERVO (dome rotation):
  ESP32 GPIO14 ─── 74AHCT125 A1 input (3.3V signal in)
  74AHCT125 Y1 ─── Servo Signal wire (orange/yellow) — 5V signal out
  L298N 5V     ─── Servo VCC (red wire)
  L298N GND    ─── Servo GND (brown/black wire)

MOTORS via L298N:
  ESP32 GPIO25 ──── L298N IN1 (Motor A direction)
  ESP32 GPIO26 ──── L298N IN2 (Motor A direction)
  ESP32 GPIO27 ──── L298N ENA (Motor A PWM speed)
  ESP32 GPIO32 ──── L298N IN3 (Motor B direction)
  ESP32 GPIO33 ──── L298N IN4 (Motor B direction)
  ESP32 GPIO34 ──── L298N ENB (Motor B PWM speed)
  L298N OUT1   ──── DC Motor A: terminal 1
  L298N OUT2   ──── DC Motor A: terminal 2
  L298N OUT3   ──── DC Motor B: terminal 1
  L298N OUT4   ──── DC Motor B: terminal 2

NeoPixel (from Episode 5):
  ESP32 GPIO6 ── 74AHCT125 A2 ── NeoPixel DIN

Color code:
  RED    = 5V / VIN power
  ORANGE = 9V battery supply
  BLACK  = GND
  PURPLE = 3.3V logic
  GREEN  = NeoPixel data (level-shifted)
  BLUE   = Servo signal (level-shifted)
  YELLOW = Motor direction signals
  WHITE  = Motor PWM (speed) signals

Connection Table:
┌──────────────────────┬──────────────────────────────────────┐
│ From                 │ To                                   │
├──────────────────────┼──────────────────────────────────────┤
│ 9V Battery (+)       │ L298N: VS                            │
│ 9V Battery (−)       │ L298N: GND + ESP32 GND (common)      │
│ L298N: 5V out        │ Servo VCC (red), 74AHCT125 VCC       │
│ L298N: GND           │ Servo GND, 74AHCT125 GND             │
│ ESP32 GPIO14         │ 74AHCT125 A1 → servo signal (5V)     │
│ ESP32 GPIO6          │ 74AHCT125 A2 → NeoPixel DIN (5V)     │
│ ESP32 GPIO25         │ L298N IN1                            │
│ ESP32 GPIO26         │ L298N IN2                            │
│ ESP32 GPIO27 (PWM)   │ L298N ENA                            │
│ ESP32 GPIO32         │ L298N IN3                            │
│ ESP32 GPIO33         │ L298N IN4                            │
│ ESP32 GPIO34 (PWM)   │ L298N ENB                            │
│ L298N OUT1,OUT2      │ DC Motor A                           │
│ L298N OUT3,OUT4      │ DC Motor B                           │
└──────────────────────┴──────────────────────────────────────┘

HAN: "Two power rails. That's important. I've seen people blow a microcontroller trying to power motors directly off the GPIO pins. The L298N's internal regulator gives you the 5V for the servo and the level shifter. Clean."

R2-D2 beeps approvingly.

HAN: "Yeah, even I have to admit that's well done."

Compile and Watch the Dome Spin 🚀

✓ Compilation successful
  Board:   ESP32-S3 N16R8
  Sketch:  r2d2-main.ino + 5 headers
  Binary:  498,244 bytes (7.2% of 16MB Flash)
  RAM:     Used 34,128 bytes (10.4% of 327KB)

The dome servo sweeps slowly between 60° and 120°. R2-D2 scans the room.

Wave your hand in front of the HC-SR04. The dome snaps to 90°. The wheels stop. The OLED shows "TOO CLOSE!"

Han Solo watches the dome turn. A long pause.

HAN: "...Okay. That's actually pretty good."

R2-D2 beeps.

HAN: "I said it was pretty good. Don't push it."

Save Milestone 🚩

Milestone: "R2-D2 Motion Systems — Episode 6 Complete"

Five systems running. Dome rotating. Wheels ready. The droid is almost complete.

What's Next: R2 Gets His Voice Back 🔊

Obi-Wan speaks with warmth.

OBI-WAN: "The dome spins. The lights glow. The screen projects. The wheels wait. But something is still missing — the true voice. Not just beeps from a buzzer, but the full audio character of the galaxy's most beloved droid. In Episode 7, we add the DFPlayer Mini and a speaker. R2-D2 will play actual audio files. And the Live Serial Monitor will show us exactly what is happening."

R2-D2 emits a long, heartfelt whistle that says everything.

🔗 Resources

ESP32 LEDC (servo): randomnerdtutorials.com/esp32-servo-motor-web-server
L298N motor driver: Search "L298N Arduino ESP32 tutorial"
74AHCT125 level shifter: Search "74AHCT125 3.3V 5V logic level converter"
Codey Online: codey.online

🤖 R2D2 Creation with Codey — building the galaxy's greatest droid, one episode at a time. May the Force — and the cloud compiler — be with you.

R2D2 Creation with Codey 🤖 Ep.5

Willem van Heemstra — Sun, 07 Jun 2026 14:13:46 +0000

Episode 5: The Projector of Hope

"Help Me, Codey Online — You're My Only Hope" 📽️

The workshop is quiet. R2-D2 sits in the corner, dome LEDs softly breathing their blue-white rhythm. Then, suddenly — a holographic projection flickers from somewhere inside his chassis. Princess Leia. Eighteen centimetres tall. Looping silently.

Luke stares.

LUKE: "That's what I want. That's exactly what I want. An OLED screen mounted in his dome, showing status messages, projecting text like a mission briefing. Something that makes him feel... alive."

R2-D2 beeps with the energy of someone who has been waiting patiently for this episode.

LUKE: "But Obi-Wan said something about upgrading the brain first. Moving to a bigger board."

Obi-Wan's voice arrives like dawn.

OBI-WAN: "The Arduino UNO served us well through four episodes, young one. But what lies ahead — the motion systems, the voice responses, the wireless capabilities — these require a more powerful foundation. It is time to meet the ESP32-S3 N16R8."

🗂️ SIPOC — The Great Upgrade

Suppliers	Inputs	Process	Outputs	Customers
You (the maker)	"Migrate to ESP32-S3 N16R8 and add SSD1306 OLED via I2C"	Codey recognises the new board, updates pin mappings, rewrites I2C addresses, flags 3.3V implications	Correct ESP32-S3 firmware with Adafruit_SSD1306, new I2C pins	ESP32-S3 N16R8 — which drives the OLED and all previous systems
Codey Voltage Safety Check	NeoPixel (5V logic), OLED (3.3V or 5V), HC-SR04 (5V) vs ESP32-S3 (3.3V GPIO)	Cross-references component voltage requirements with ESP32-S3 GPIO levels	Specific warnings per component + recommended level shifter or workarounds	You — who avoid smoke on this far more expensive board
SSD1306 OLED (128×64)	3.3V power, I2C (SDA/SCL)	Receives display commands over I2C protocol	A crisp 128×64 pixel display showing R2 status and messages	R2-D2's dome — the holographic projection system
Milestones & Rollback	Previous working code at Episode 4 milestone	One-click restore of code + chat history	Known-good state if the board migration causes issues	You — who can always go back

Meet the New Brain: ESP32-S3 N16R8 🧠

C-3PO emerges carrying a padded case like it contains the Holy Grail.

C-3PO: "The ESP32-S3 N16R8. I have computed its specifications forty-seven times. Allow me to translate from technical to comprehensible:"

Feature	ESP32-S3 N16R8	Arduino UNO R3
Processor	Dual-core Xtensa LX7 @ 240 MHz	Single-core ATmega328P @ 16 MHz
Flash storage	16 MB	32 KB
PSRAM	8 MB	0
GPIO pins	45	14 digital
Logic voltage	3.3V	5V
Wi-Fi	Yes (802.11b/g/n)	No
Bluetooth	Yes (BLE 5.0 + Classic)	No
USB	Native USB-CDC (two ports!)	USB via CH340/FTDI chip
PWM	LEDC — 8 channels, 14-bit resolution	6 PWM pins, 8-bit
DAC	2× 8-bit DAC outputs	None

C-3PO: "Considerably more capable. However — and I cannot stress this strongly enough — the GPIO outputs are 3.3V, not 5V. Several of our existing components expect a 5V signal. This is a matter of the gravest concern and I intend to address each one individually."

R2-D2 beeps impatiently.

C-3PO: "Artoo, voltage compatibility is NOT a detail. It is the difference between a functional droid and a very expensive doorstop."

The 3.3V Migration: C-3PO's Component Review ⚡

Darth Vader's voice rumbles through the ventilation system.

VADER: "Your lack of a level shifter... disturbs me."

C-3PO whirls around, then remembers where he is.

C-3PO: "Quite. Let us review each component's voltage situation with the ESP32-S3:"

Component Voltage Compatibility Table

Component	VCC Needed	Signal Level Needed	ESP32-S3 GPIO (3.3V)	Action Required
SSD1306 OLED	3.3V or 5V	3.3V I2C	✅ Compatible	None — OLED runs perfectly on 3.3V
Piezo Buzzer	3.3V–5V	3.3V PWM	✅ Compatible	None — works fine at 3.3V
NeoPixel WS2812B	5V	5V data signal	⚠️ Marginal	Add 74AHCT125 level shifter OR use 470Ω + 3V3-to-5V shifter
HC-SR04	5V	5V ECHO output	⚠️ Risky	The ECHO pin outputs 5V — use voltage divider on ECHO
PIR HC-SR501	5V	5V output	⚠️ Risky	Use voltage divider (10k + 20k) on output pin

C-3PO: "Codey will generate the level shifter and voltage divider circuits in the wiring diagram. This is precisely the scenario for which Codey's voltage safety checks were designed."

Codey, upon seeing the ESP32-S3 selected, automatically adds voltage warnings for each incompatible component in the project.

Selecting the New Board in Codey 🔄

Han Solo demonstrates with the casual confidence of someone who has hot-swapped ship components mid-jump.

HAN: "Simple. In your Codey project, click the board selector at the top. Change it from Arduino UNO R3 to ESP32-S3 N16R8. Done. Codey figures out the rest."

Click the board name dropdown at the top of the Codey interface
Select ESP32-S3 N16R8
Codey immediately shows:

⚠️  Board changed: Arduino UNO R3 → ESP32-S3 N16R8

This board uses 3.3V GPIO logic.
I've detected components in your project that may be affected:

  • NeoPixel WS2812B (pin 6): Needs level shifter — see updated wiring diagram
  • HC-SR04 (pins 9/10): ECHO pin outputs 5V — needs voltage divider
  • PIR HC-SR501 (pin 2): Output is 5V — needs voltage divider

  Recommended: Add 74AHCT125 (quad level shifter) for WS2812B data line.
  Piezo buzzer (pin 8): ✓ Compatible — no change needed.

Shall I update the code and wiring diagram for the ESP32-S3?

R2-D2 beeps enthusiastically: "YES."

HAN: "See? It flags everything. No surprises."

Before Moving On: Rolling Back If Needed 🚩

Obi-Wan raises a steady hand.

OBI-WAN: "Before this migration, let us invoke the wisdom of Milestones. Our Episode 4 code runs perfectly on the Arduino UNO. If the ESP32-S3 migration encounters difficulty, we must be able to return to that known-good state."

In Codey, click Milestones → find "R2-D2 Sensor Eye — Episode 4 Complete" → click Restore.

Both the code AND the chat history are restored to exactly how they were after Episode 4.

Now make a new milestone before starting the migration:

Milestone: "Pre-ESP32 Migration Checkpoint"

OBI-WAN: "The Force gives you wisdom to try. The Milestone gives you the courage to try boldly."

R2-D2 beeps something along the lines of "can we please just look at the OLED already."

Prompting Codey for the ESP32-S3 Migration + OLED 💬

In Plan mode first:

We're upgrading R2-D2's brain from Arduino UNO R3 to ESP32-S3 N16R8.

Existing systems to migrate:
  - Piezo buzzer on pin 8 → keep same pin, use LEDC channel instead of tone()
  - NeoPixel ring (12 LEDs) on pin 6 → keep pin, add note about 74AHCT125
  - HC-SR04 on pins 9/10 → keep pins, add voltage divider on ECHO
  - PIR sensor on pin 2 → keep pin, add voltage divider on output

New addition:
  - SSD1306 OLED 128x64 display via I2C
  - ESP32-S3 I2C default: SDA=GPIO8, SCL=GPIO9
  - Show these screens:
    1. Startup: "R2-D2 ONLINE" with a spinning animation
    2. Idle: distance reading + "SAFE" or "ALERT"
    3. Motion: "MOTION DETECTED" with exclamation marks
    4. Very close: "TOO CLOSE" with a blinking border

Show me the plan before writing any code.

Codey Plan Mode Response

R2-D2 ESP32-S3 Migration + Holographic Projector — Plan

FILES:
  r2d2-main.ino     — setup() and loop(), board init
  animations.h      — NeoPixel dome animations (migrated to ESP32)
  sensors.h         — HC-SR04 + PIR (voltage divider notes)
  display.h         — SSD1306 OLED functions (new)
  sounds.h          — LEDC-based tone functions (replaces tone() API)

KEY CHANGES:
  1. tone() → ledc functions (ESP32 uses LEDC peripheral for PWM)
     ledcSetup(0, 2637, 8) + ledcWrite(0, 128) replaces tone(pin, freq)

  2. I2C on ESP32-S3: Wire.begin(8, 9) for SDA=GPIO8, SCL=GPIO9
     (Adafruit_SSD1306 uses Wire automatically)

  3. NeoPixel: Same FastLED/NeoPixel API — ESP32-S3 natively supports
     RMT peripheral for WS2812B. Add 74AHCT125 recommendation in wiring.

  4. HC-SR04 ECHO: Add voltage divider (10kΩ + 20kΩ) to reduce 5V→3.3V
     TRIG output from ESP32-S3 (3.3V) is sufficient to trigger HC-SR04.

  5. PIR output: Add voltage divider (10kΩ + 20kΩ)

  DISPLAY STATES:
    • BOOT  — "R2-D2 ONLINE", spinner, 2 seconds
    • IDLE  — Distance + status, updates every 500ms
    • SCAN  — "MOTION DETECTED !!", large text
    • ALERT — "TOO CLOSE" with animated blinking border

Proceed?

Click Proceed. Codey writes all five files.

Generated `display.h`

// display.h — R2-D2 Holographic Projector
// SSD1306 OLED 128x64 via I2C
// ESP32-S3: SDA=GPIO8, SCL=GPIO9

#pragma once
#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>

#define SCREEN_WIDTH  128
#define SCREEN_HEIGHT  64
#define OLED_ADDR     0x3C   // Default I2C address for SSD1306

// OLED_RESET = -1 means share the Arduino reset pin (or no reset pin)
Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, -1);

bool displayReady = false;

// ── Boot animation ────────────────────────────────────────────────
const char* spinFrames[] = {"|", "/", "-", "\\"};
int spinIdx = 0;
unsigned long lastSpinMs = 0;
unsigned long bootStartMs = 0;
bool bootDone = false;

void initDisplay() {
  // ESP32-S3 I2C: SDA=GPIO8, SCL=GPIO9
  Wire.begin(8, 9);

  if (!display.begin(SSD1306_SWITCHCAPVCC, OLED_ADDR)) {
    Serial.println("SSD1306 not found — check wiring!");
    return;
  }

  displayReady = true;
  display.clearDisplay();
  display.setTextColor(SSD1306_WHITE);
  bootStartMs = millis();
  Serial.println("OLED projector online!");
}

void showBootScreen() {
  if (!displayReady || bootDone) return;

  unsigned long now = millis();

  if (now - lastSpinMs > 150) {
    lastSpinMs = now;
    spinIdx = (spinIdx + 1) % 4;

    display.clearDisplay();

    // Title — large text centred
    display.setTextSize(2);
    display.setCursor(4, 8);
    display.println("R2-D2");
    display.setCursor(4, 28);
    display.println("ONLINE");

    // Spinner bottom right
    display.setTextSize(2);
    display.setCursor(112, 48);
    display.print(spinFrames[spinIdx]);

    display.display();
  }

  if (now - bootStartMs > 2500) {
    bootDone = true;
  }
}

// ── Idle screen: distance + status ──────────────────────────────
unsigned long lastIdleRefreshMs = 0;

void showIdleScreen(float distance) {
  if (!displayReady) return;

  unsigned long now = millis();
  if (now - lastIdleRefreshMs < 500) return;
  lastIdleRefreshMs = now;

  display.clearDisplay();

  // Distance reading
  display.setTextSize(1);
  display.setCursor(0, 0);
  display.print("DISTANCE:");

  display.setTextSize(2);
  display.setCursor(0, 12);
  if (distance < 500.0f) {
    display.print((int)distance);
    display.print(" cm");
  } else {
    display.print("--- cm");
  }

  // Status label
  display.setTextSize(1);
  display.setCursor(0, 48);
  if (distance < 15.0f) {
    display.print("!! TOO CLOSE !!");
  } else if (distance < 30.0f) {
    display.print("CAUTION");
  } else {
    display.print("SAFE");
  }

  display.display();
}

// ── Motion detected screen ───────────────────────────────────────
void showMotionScreen() {
  if (!displayReady) return;

  display.clearDisplay();
  display.setTextSize(2);
  display.setCursor(0, 8);
  display.println("MOTION");
  display.setCursor(0, 28);
  display.println("DETECTED");
  display.setTextSize(3);
  display.setCursor(96, 28);
  display.print("!!");
  display.display();
}

// ── Alert: blinking border + TOO CLOSE ──────────────────────────
bool borderVisible = true;
unsigned long lastBorderFlipMs = 0;

void showAlertScreen() {
  if (!displayReady) return;

  unsigned long now = millis();
  if (now - lastBorderFlipMs > 300) {
    lastBorderFlipMs = now;
    borderVisible = !borderVisible;
  }

  display.clearDisplay();

  if (borderVisible) {
    display.drawRect(0, 0, 128, 64, SSD1306_WHITE);
    display.drawRect(2, 2, 124, 60, SSD1306_WHITE);
  }

  display.setTextSize(2);
  display.setCursor(8, 16);
  display.println("TOO");
  display.setCursor(8, 36);
  display.println("CLOSE!");
  display.display();
}

Generated `sounds.h` (ESP32 LEDC version)

// sounds.h — R2-D2 Sound System (ESP32-S3 LEDC)
// Replaces Arduino tone() with ESP32 LEDC peripheral

#pragma once

#define BUZZER_PIN    8    // GPIO8 on ESP32-S3
#define LEDC_CHANNEL  0
#define LEDC_TIMER    8    // 8-bit resolution

bool ledcReady = false;

void initSounds() {
  // Configure LEDC channel for buzzer
  ledcSetup(LEDC_CHANNEL, 1000, LEDC_TIMER);
  ledcAttachPin(BUZZER_PIN, LEDC_CHANNEL);
  ledcWrite(LEDC_CHANNEL, 0); // silent
  ledcReady = true;
}

void playTone(int frequency) {
  if (!ledcReady || frequency <= 0) {
    ledcWrite(LEDC_CHANNEL, 0);
    return;
  }
  ledcWriteTone(LEDC_CHANNEL, frequency);
  ledcWrite(LEDC_CHANNEL, 128); // 50% duty cycle
}

void stopTone() {
  ledcWrite(LEDC_CHANNEL, 0);
}

Generated `r2d2-main.ino` (ESP32-S3 version)

// r2d2-main.ino — R2-D2 ESP32-S3 N16R8
// Unifying all systems: sounds, dome lights, sensors, display

#include <Adafruit_NeoPixel.h>
#include "sounds.h"
#include "animations.h"
#include "sensors.h"
#include "display.h"

void setup() {
  Serial.begin(115200);
  Serial.println("R2-D2 ESP32-S3 boot sequence...");

  initSounds();
  initAnimations();   // NeoPixel dome
  initSensors();      // HC-SR04 + PIR
  initDisplay();      // SSD1306 OLED

  Serial.println("All systems nominal. R2-D2 is ONLINE.");
}

void loop() {
  // Boot animation runs first
  if (!bootDone) {
    showBootScreen();
    return;
  }

  // Read sensors
  float dist    = readDistance();
  bool  motion  = checkMotion();

  // Update display based on state
  if (dist < 15.0f) {
    showAlertScreen();
  } else if (motion) {
    showMotionScreen();
  } else {
    showIdleScreen(dist);
  }

  // Update dome animations (non-blocking)
  updateAnimationsSensors(dist, motion);
}

The Wiring Diagram — ESP32-S3 Edition 🧭

C-3PO straightens to his full height, relieved.

C-3PO: "Codey has drawn the wiring diagram. I have checked it. It includes the voltage dividers. It includes the level shifter recommendation. It is correct. I am, for the first time this episode, not worried."

R2-D2 Holographic System — ESP32-S3 N16R8 Wiring
════════════════════════════════════════════════════════════

[ESP32-S3 N16R8]

  POWER RAIL (3.3V):
    3V3  ───┬── OLED VCC (3.3V input)
            └── (100µF cap +)
    GND  ───┬── OLED GND
            └── (100µF cap −)

  POWER RAIL (5V via USB):
    VIN  ───┬── NeoPixel Ring: 5V
            ├── HC-SR04: VCC
            └── PIR HC-SR501: VCC
    GND  ───┬── NeoPixel Ring: GND
            ├── HC-SR04: GND
            └── PIR HC-SR501: GND

  I2C BUS (3.3V — OLED compatible):
    GPIO8 (SDA) ──── OLED SDA
    GPIO9 (SCL) ──── OLED SCL

  SIGNALS with PROTECTION:
    GPIO6  ──── [74AHCT125 level shifter] ──── NeoPixel DIN (5V)
    GPIO8  ──── (100Ω) ──────────────────────── Piezo Buzzer +
    GPIO9  ────────────────────────────────────── HC-SR04 TRIG
    GPIO10 ──── [10kΩ / 20kΩ divider] ─────────── HC-SR04 ECHO
    GPIO2  ──── [10kΩ / 20kΩ divider] ─────────── PIR OUT

Voltage Dividers for 5V → 3.3V:
  GPIO_pin ←── (junction) ─── 20kΩ ─── GND
                   └────────── 10kΩ ─── 5V signal in

Connection Table:
┌──────────────────────┬───────────────────────────────────┐
│ From                 │ To                                │
├──────────────────────┼───────────────────────────────────┤
│ ESP32-S3 3V3         │ OLED VCC                          │
│ ESP32-S3 GND         │ OLED GND                          │
│ ESP32-S3 GPIO8 (SDA) │ OLED SDA                          │
│ ESP32-S3 GPIO9 (SCL) │ OLED SCL                          │
│ ESP32-S3 VIN (5V)    │ NeoPixel 5V, HC-SR04 VCC, PIR VCC│
│ ESP32-S3 GPIO6       │ Level shifter → NeoPixel DIN      │
│ ESP32-S3 GPIO8       │ 100Ω → Piezo Buzzer +             │
│ ESP32-S3 GPIO9       │ HC-SR04 TRIG                      │
│ HC-SR04 ECHO (5V)    │ Voltage divider → ESP32 GPIO10    │
│ PIR OUT (5V)         │ Voltage divider → ESP32 GPIO2     │
└──────────────────────┴───────────────────────────────────┘

⚡ Critical Notes:
  - OLED: 3.3V compatible — no level shifting needed
  - NeoPixel: 5V logic required — 74AHCT125 MANDATORY
  - HC-SR04 ECHO: 5V output — voltage divider protects ESP32-S3
  - ESP32-S3 has two USB ports — Codey auto-detects the correct one

LUKE: "Download the PDF. Print two copies."

Compile and Upload to ESP32-S3 🚀

The ESP32-S3 N16R8 has two USB ports. Codey knows which one to use:

⚙️  Board: ESP32-S3 N16R8

Note: This board has two USB connectors:
  • USB (UART) — for serial communication / upload via UART bridge
  • USB-OTG (native USB-CDC) — direct USB communication

Codey will attempt to detect the correct port automatically.
If upload fails, try the other USB connector.

Click Compile:

✓ Compilation successful
  Board:   ESP32-S3 N16R8
  Sketch:  r2d2-main.ino + 4 headers
  Binary:  412,288 bytes (5.9% of 16MB Flash)
  RAM:     Used 28,492 bytes (8.7% of 327KB)
  PSRAM:   8MB available for future expansion

Click Upload → Select the correct USB port → Flash completes.

The OLED lights up: "R2-D2" and "ONLINE" with a spinning cursor.

R2-D2 beeps.

Then the idle screen appears: "DISTANCE: 87 cm — SAFE."

Luke waves his hand in front of the HC-SR04. The screen immediately switches to "TOO CLOSE!" with a blinking border.

LUKE: "It works. He sees me. He's telling me I'm too close."

R2-D2 beeps something that clearly means "yes, please back up."

Save the Milestone 🚩

Milestone: "R2-D2 Holographic Projector — Episode 5 Complete"

Four systems running. ESP32-S3 humming. The OLED projecting. The dome glowing. The sensors watching.

What's Next: The Motion Systems Activate ⚙️

Han Solo slaps the workbench.

HAN: "Okay. He blinks, he beeps, he shows you a screen. But you know what R2-D2 actually does that nobody else can? He moves. He rolls. His dome spins. He navigates. Episode 6 — we give this droid wheels and a rotating dome. Servo for the dome, DC motors for the base. The wiring diagram is going to get interesting."

R2-D2 beeps the equivalent of "I have been waiting for this my entire existence."

🔗 Resources

ESP32-S3 datasheet: espressif.com/esp32-s3
SSD1306 library: github.com/adafruit/Adafruit_SSD1306
74AHCT125 level shifter: Search "74AHCT125 NeoPixel level shifter"
Codey Online: codey.online

🤖 R2D2 Creation with Codey — building the galaxy's greatest droid, one episode at a time. May the Force — and the cloud compiler — be with you.

R2D2 Creation with Codey 🤖 Ep.4

Willem van Heemstra — Sun, 07 Jun 2026 14:13:36 +0000

Episode 4: The All-Seeing Eye

"Impressive. Most Impressive." 👁️

Darth Vader enters — wait, no. Wrong side.

Luke Skywalker stands at the workbench, holding an HC-SR04 ultrasonic sensor up to the light.

LUKE: "I've always wondered how he knew. How R2 always knew when something was coming. When an obstacle was in the way. When the Death Star trench was approaching. He sees things. Feels them. Before anyone else does."

R2-D2 beeps softly, as if this is a deeply personal topic.

LUKE: "Today we give him that. The sensor eye. And this time—" he gestures at the screen "—Codey's going to show us something called Auto Error Fixing. Because I have a feeling we're going to need it."

From somewhere unseen, a voice floats through the Force.

VADER: "Your lack of a level-shifted data pin... disturbs me."

LUKE: "We're on 5V. We'll be fine."

🗂️ SIPOC — The Sensor Eye System

Suppliers	Inputs	Process	Outputs	Customers
You (the maker)	"Add HC-SR04 on pins 9/10 and PIR on pin 2, react with beeps and dome color changes"	Codey writes sensor code, integrates with sound and dome systems from previous episodes	Unified firmware: sense → respond with light + sound	R2-D2 — who now reacts to the world around him
HC-SR04 Sensor	5V power, TRIG pulse from Arduino	Emits ultrasonic pulse, measures return echo time	Distance in centimetres	The code — which decides how close is "too close"
PIR Motion Sensor	5V power, GPIO input to Arduino	Digital HIGH when motion detected	A HIGH signal on the interrupt pin	The code — which triggers the alert sequence
Auto Error Fixing	A compilation error from incorrect code	Codey reads the error log, rewrites the offending lines, recompiles	Fixed code that compiles successfully	You — who get working firmware without decoding C++ error messages
Vision Feature	A photo of your breadboard	Codey reads the image and identifies component placement	A verification report: "Wiring looks correct" or specific mismatches	You — who confirm wiring before upload

The Components 🔧

C-3PO enters with a tray of precisely arranged components.

C-3PO: "Today we add perception to R2-D2's capabilities. The HC-SR04 ultrasonic sensor — which I should note operates at 5V and is therefore perfectly compatible with the Arduino UNO without any level shifting, which is a relief — and the HC-SR501 PIR motion sensor, also 5V compatible. I have pre-sorted them by height to prevent any confusion."

R2-D2 beeps something that sounds like "nobody asked you to sort them."

Component	Quantity	Notes
Arduino UNO R3	1	Our trusted base
HC-SR04 ultrasonic sensor	1	5V, TRIG + ECHO pins
HC-SR501 PIR sensor	1	5V, single digital output
10kΩ resistor	1	PIR output pull-down (some modules need it)
Jumper wires	6
USB cable	1

Plus the buzzer from Episode 2 and NeoPixel ring from Episode 3 — we are building on the complete system.

The Codey Prompt — Building on What We Have 💬

Han Solo points at the screen.

HAN: "Here's the thing about AI coding tools — you don't start from scratch every time. You tell it what already exists and what you want to add. Context is everything. Same in the smuggling business."

LUKE: "You're comparing Codey to smuggling?"

HAN: "I'm saying context matters. Do you want the lecture or the sensor?"

Open your Codey project (from Episode 3 milestone). In Agent mode:

We're continuing the R2-D2 build from the previous episodes.
Existing systems:
  - Piezo buzzer on pin 8 (tone-based sounds)
  - NeoPixel ring (12 LEDs) on pin 6 (dome animations)

Add these sensor systems:
  1. HC-SR04 ultrasonic sensor
     - TRIG on pin 9, ECHO on pin 10
     - Measure distance every 150ms (non-blocking)
     - If distance < 30cm: trigger alert animation + alert sound
     - If distance < 15cm: trigger full RED dome + rapid alert beeps

  2. PIR motion sensor on pin 2 (interrupt-capable)
     - On motion detected: trigger scan animation for 3 seconds
     - Then return to idle

Extend animations.h with these reactive behaviors.
Keep the state machine approach.
Use millis() everywhere — no delay().

Generated Code Addition to `animations.h`

// ── Sensor additions (append to animations.h) ───────────────────

// ── HC-SR04 ─────────────────────────────────────────────────────
#define TRIG_PIN   9
#define ECHO_PIN   10

unsigned long lastSonarMs  = 0;
float         lastDistance = 999.0f;

float readDistance() {
  // Non-blocking: only trigger if enough time has passed
  unsigned long now = millis();
  if (now - lastSonarMs < 150) return lastDistance;
  lastSonarMs = now;

  // Send 10µs TRIG pulse
  digitalWrite(TRIG_PIN, LOW);
  delayMicroseconds(2);
  digitalWrite(TRIG_PIN, HIGH);
  delayMicroseconds(10);
  digitalWrite(TRIG_PIN, LOW);

  // Read echo duration (timeout 30ms = ~5m max range)
  long duration = pulseIn(ECHO_PIN, HIGH, 30000UL);
  if (duration == 0) return 999.0f;

  // Convert to centimetres
  lastDistance = (duration * 0.0343f) / 2.0f;
  return lastDistance;
}

// ── PIR Motion Sensor ────────────────────────────────────────────
#define PIR_PIN   2

volatile bool motionDetected = false;

void IRAM_ATTR onMotion() {
  motionDetected = true;
}

// ── Reactive behaviour in updateAnimations() ─────────────────────
// (replaces/extends the existing updateAnimations function)

void updateAnimationsSensors() {
  unsigned long now = millis();

  // ── Check PIR first (interrupt-driven, higher priority) ─────
  if (motionDetected) {
    motionDetected = false;
    currentState   = SCAN;
    stateStartMs   = now;
    Serial.println("Motion detected — scan mode!");
  }

  // ── Check HC-SR04 distance ─────────────────────────────────
  float dist = readDistance();

  if (dist < 15.0f) {
    // Very close — full red alert
    if (currentState != ALERT) {
      currentState = ALERT;
      stateStartMs = now;
      tone(BUZZER_PIN, 2637); // C6 — high alert tone
    }
    // Override: set all LEDs red while this close
    for (int i = 0; i < NUMPIXELS; i++) {
      ring.setPixelColor(i, ring.Color(BRIGHTNESS, 0, 0));
    }
    ring.show();
    return;
  } else if (dist < 30.0f) {
    // Approaching — amber warning
    if (currentState == IDLE) {
      currentState = ALERT;
      stateStartMs = now;
    }
  } else {
    noTone(BUZZER_PIN); // Silence if moved away
  }

  // ── Normal state machine ────────────────────────────────────
  updateAnimations(); // existing function handles the rest
}

Updated `r2d2-dome.ino`

// r2d2-dome.ino — updated for sensor eye
#include <Adafruit_NeoPixel.h>
#include "animations.h"

void setup() {
  Serial.begin(9600);
  initAnimations();

  // Sensor pins
  pinMode(TRIG_PIN, OUTPUT);
  pinMode(ECHO_PIN, INPUT);
  pinMode(PIR_PIN,  INPUT);

  // PIR interrupt — fires on rising edge (motion start)
  attachInterrupt(digitalPinToInterrupt(PIR_PIN), onMotion, RISING);

  Serial.println("R2-D2 sensor eye online!");
}

void loop() {
  updateAnimationsSensors(); // new unified call
}

Auto Error Fixing in Action 🛠️

And then it happens.

LUKE: "I tried to compile and—"

Compilation Error:
  animations.h:47: error: 'IRAM_ATTR' was not declared in this scope
  animations.h:47: note: 'IRAM_ATTR' is an ESP32 attribute, not available on AVR

LUKE: "What does that mean? I just—"

Before Luke can panic, the screen updates automatically.

CODEY AUTO ERROR FIX:

I see the error! IRAM_ATTR is an ESP32-specific macro for placing
interrupt handlers in IRAM (fast memory). The Arduino UNO uses
an ATmega328P — it doesn't have IRAM at all.

For Arduino UNO, the interrupt handler just needs the ISR() attribute,
which I used in the function signature. I'll remove IRAM_ATTR.

Fixed:
  Before: void IRAM_ATTR onMotion() {
  After:  void onMotion() {

Recompiling...

✓ Compilation successful (after auto-fix)
  Board:   Arduino UNO R3
  Sketch:  r2d2-dome.ino + animations.h
  Size:    9,104 bytes (28% of flash)

LUKE: "It... fixed it. By itself."

HAN: "Never tell me the odds."

LUKE: "That's not the same—"

HAN: "The AI fixed its own mistake without you having to understand why. That's what matters."

The Wiring Diagram — Three Systems Now 🧭

Click Wiring Diagram. The diagram now shows all three systems:

R2-D2 Sensor Eye + Dome + Sound — Wiring Diagram
════════════════════════════════════════════════════════════

[Arduino UNO R3]

  POWER RAIL:
    5V  ─────────┬── NeoPixel 5V
                 ├── HC-SR04 VCC
                 ├── PIR Sensor VCC
                 └── (100µF cap +)
    GND ─────────┬── NeoPixel GND
                 ├── HC-SR04 GND
                 ├── PIR Sensor GND
                 └── (100µF cap −)

  SIGNALS:
    Pin 6  ──── (470Ω) ──── NeoPixel DIN
    Pin 8  ──── (100Ω) ──── Piezo Buzzer +
    Pin 9  ─────────────── HC-SR04 TRIG
    Pin 10 ─────────────── HC-SR04 ECHO
    Pin 2  ─────────────── PIR Sensor OUT

Color code:
  RED    = 5V / power rail
  BLACK  = GND rail
  GREEN  = NeoPixel data (pin 6)
  ORANGE = Buzzer signal (pin 8)
  BLUE   = HC-SR04 TRIG (pin 9)
  PURPLE = HC-SR04 ECHO (pin 10)
  YELLOW = PIR output (pin 2)
  GREY   = Through resistors

Connection Table:
┌────────────────────┬──────────────────────────────────┐
│ From               │ To                               │
├────────────────────┼──────────────────────────────────┤
│ Arduino 5V         │ NeoPixel Ring: 5V                │
│ Arduino 5V         │ HC-SR04: VCC                     │
│ Arduino 5V         │ PIR HC-SR501: VCC                │
│ Arduino 5V         │ 100µF Cap: + (long leg)          │
│ Arduino GND        │ NeoPixel Ring: GND               │
│ Arduino GND        │ HC-SR04: GND                     │
│ Arduino GND        │ PIR HC-SR501: GND                │
│ Arduino GND        │ 100µF Cap: − (short leg)         │
│ Arduino Pin 6      │ Resistor 470Ω → NeoPixel DIN     │
│ Arduino Pin 8      │ Resistor 100Ω → Piezo (+)        │
│ Arduino Pin 9      │ HC-SR04: TRIG                    │
│ Arduino Pin 10     │ HC-SR04: ECHO                    │
│ Arduino Pin 2      │ PIR HC-SR501: OUT                │
└────────────────────┴──────────────────────────────────┘

C-3PO: "Seven signals on eight wires plus the power rail. The color-coded system makes it genuinely manageable. Download the PDF immediately — this is the most complex wiring diagram we have produced so far and I do not trust organic memory."

Vision Feature: "Is My Breadboard Wired Correctly?" 👁️

Luke takes a photo of his assembled breadboard.

LUKE: "Before I upload — can I check this with Codey? Just to be sure?"

Click the Vision icon in Codey (Pro feature). Upload the breadboard photo.

Codey responds:

I can see your breadboard. Here's what I observe:

✓ HC-SR04 ultrasonic sensor connected:
  - VCC to 5V rail — correct
  - GND to GND rail — correct
  - TRIG appears connected to the digital pin area (looks like pin 9) — correct
  - ECHO appears connected to pin 10 — correct

✓ PIR sensor:
  - VCC and GND connections look correct
  - Signal wire appears to go to pin 2 — correct

⚠️ One potential issue:
  I notice what looks like the NeoPixel data wire may not have the
  470Ω resistor in line — it appears to connect directly. Check that
  the resistor is seated in the breadboard between pin 6 and the DIN
  input. A direct connection may cause LED flickering or data errors.

Everything else looks correctly laid out!

Luke examines the breadboard.

LUKE: "The resistor... it's in the wrong row. It's not actually connected to anything."

R2-D2 beeps in the tone of "I could have told you that."

LUKE: "Vision just saved R2's dome lights."

What's Next: The Holographic Projector 📽️

Obi-Wan's presence fills the workshop like warm light.

OBI-WAN: "You have given R2-D2 his lights. His sounds. His sense of the world around him. But the moment that first made the galaxy fall in love with this droid — do you remember it, Luke?"

LUKE: "Help me, Obi-Wan Kenobi. You're my only hope."

OBI-WAN: "In Episode 5, we give Artoo his projector. The SSD1306 OLED display — small, crisp, I2C wired — will show R2's status, messages, and a recreation of that famous message. Milestones and Rollback will save us if anything goes wrong."

R2-D2 beeps the opening notes of the Princess Leia theme.

🔗 Resources

HC-SR04 with Arduino: Search "HC-SR04 Arduino tutorial"
PIR HC-SR501: Search "HC-SR501 Arduino interrupt"
Codey Online Vision: codey.online — Pro feature
Auto Error Fixing: built into all Codey plans

🤖 R2D2 Creation with Codey — building the galaxy's greatest droid, one episode at a time. May the Force — and the cloud compiler — be with you.

R2D2 Creation with Codey 🤖 Ep.3

Willem van Heemstra — Sun, 07 Jun 2026 14:13:26 +0000

Episode 3: The Dome Awakens

"I Have a Bad Feeling About These Voltage Levels" ⚡

C-3PO enters the workshop carrying a 12-LED NeoPixel ring with the careful reverence of someone handling a thermal detonator.

C-3PO: "I want to begin by saying that I have computed no fewer than twenty-three potential failure modes for this particular connection. NeoPixel WS2812B LED rings operate on 5V logic. The Arduino UNO R3 also operates on 5V logic. So far, so excellent. However, should anyone in this workshop be tempted — under any circumstances — to use an ESP32 instead, which operates on 3.3V logic, I must warn them in the strongest possible terms that—"

R2-D2 beeps the equivalent of "get on with it."

C-3PO: "Yes, well. Codey's voltage safety check will handle that conversation. Shall we begin?"

🗂️ SIPOC — The Dome Light System

Suppliers	Inputs	Process	Outputs	Customers
You (the maker)	"Add a 12-LED NeoPixel ring to pin 6 for R2-D2 dome lights"	Codey picks Adafruit_NeoPixel library, generates light animation code	Complete .ino + .h header file for animation patterns	Arduino UNO R3 — which drives all 12 RGB LEDs
Codey Voltage Safety Check	NeoPixel ring (5V) + Arduino UNO (5V)	Cross-references board voltage vs component logic requirements	Green light: compatible — or warning with level shifter advice	You — who avoid magic smoke
NeoPixel Ring (12 LEDs)	5V power + PWM data signal from Pin 6	WS2812B protocol drives each RGB LED individually	12 independently addressable full-color LEDs	R2-D2's dome — which lights up with personality
Cloud Compiler	Multi-file project: r2d2-dome.ino + animations.h	Compiles with Adafruit_NeoPixel pre-installed on Codey servers	Firmware ready for upload	Arduino UNO — via Web Serial

The Components 🔧

Luke examines the new parts laid out on the bench.

LUKE: "These are beautiful. The blue and white... it's exactly right. Like the dome in the movies."

Component	Quantity	Notes
Arduino UNO R3	1	From Episode 1
NeoPixel ring (12 LED, WS2812B)	1	5V input — white text on back means 5V variant
470Ω resistor	1	Data line protection — prevents signal ringing
100µF capacitor (electrolytic)	1	Power supply decoupling — across 5V and GND
Jumper wires	4
USB cable	1

LUKE: "Why the capacitor?"

Yoda materialises near the component drawer.

YODA: "Sudden power demand, NeoPixels have when they first turn on. Smooth that spike, the capacitor does. Without it, reset your Arduino might — mid-animation."

LUKE: "I had no idea—"

YODA: "Much to learn, you still have. But learn quickly with Codey, you will."

Codey Prompt: Describing the Dome 🎙️

Open your Codey project. In Plan mode first (to review the plan), then Agent mode to build it:

Plan mode first, then agent:

I'm building R2-D2's dome light system.
Add a 12-LED NeoPixel ring (WS2812B) connected to digital pin 6
with a 470 ohm resistor on the data line.
Add a 100uF capacitor across the power pins for stability.

Create these light animations:
  1. "idle" — gentle blue-white breathing pattern, slow
  2. "alert" — fast red sweep around the ring, 3 times
  3. "happy" — rainbow sweep, then blue-white sparkle
  4. "scan" — single blue LED orbiting the ring slowly

Cycle through idle → scan → idle → happy → idle → alert.
Use non-blocking millis() timing throughout.
Split the animations into a separate animations.h file.
Keep the main .ino clean and readable.

Plan Mode Preview

Codey shows the plan before writing:

Plan for R2-D2 Dome Light System:

1. Main file (r2d2-dome.ino):
   - Include Adafruit_NeoPixel.h and animations.h
   - Setup: initialise ring, set brightness
   - Loop: call state machine from animations.h

2. animations.h:
   - Define RING_PIN = 6, NUMPIXELS = 12
   - Adafruit_NeoPixel ring object
   - State enum: IDLE, ALERT, HAPPY, SCAN
   - Functions: animateIdle(), animateAlert(),
     animateHappy(), animateScan()
   - Timing via millis() — non-blocking

3. Wiring diagram:
   - Pin 6 → 470Ω → NeoPixel DIN
   - 5V → Cap+ and NeoPixel 5V
   - GND → Cap− and NeoPixel GND

Proceed with Agent mode to write the code?

C-3PO reads the plan with visible relief.

C-3PO: "A plan! Before the code! How wonderfully methodical. I approve of this approach entirely."

Click Proceed — Codey switches to Agent mode and writes.

The Generated Code: `r2d2-dome.ino`

// r2d2-dome.ino
// R2-D2 Dome Light System — Main File
// Board: Arduino UNO R3
// NeoPixel ring (WS2812B, 12 LEDs) on pin 6

#include <Adafruit_NeoPixel.h>
#include "animations.h"

void setup() {
  Serial.begin(9600);
  initAnimations();
  Serial.println("R2-D2 dome lights online!");
}

void loop() {
  updateAnimations();
}

The Generated Header: `animations.h`

// animations.h
// R2-D2 Dome Light Animations
// NeoPixel ring (WS2812B, 12 LEDs) on pin 6

#pragma once
#include <Adafruit_NeoPixel.h>

#define RING_PIN    6
#define NUMPIXELS   12
#define BRIGHTNESS  80   // 0-255 — keep under 100 for USB power

Adafruit_NeoPixel ring(NUMPIXELS, RING_PIN, NEO_GRB + NEO_KHZ800);

enum DomeState { IDLE, SCAN, HAPPY, ALERT };

DomeState currentState = IDLE;
unsigned long stateStartMs = 0;
unsigned long lastUpdateMs = 0;

// ── State durations (ms) ────────────────────────────────────────
const unsigned long IDLE_DURATION  = 5000;
const unsigned long SCAN_DURATION  = 4000;
const unsigned long HAPPY_DURATION = 3500;
const unsigned long ALERT_DURATION = 2500;

// ── Dome state machine order ────────────────────────────────────
DomeState stateOrder[] = {IDLE, SCAN, IDLE, HAPPY, IDLE, ALERT};
int stateIndex  = 0;
const int NUM_STATES = 6;

// ── Animation helpers ───────────────────────────────────────────
float breatheValue = 0.0f;
float breatheDir   = 0.02f;
int   scanPos      = 0;
int   alertSweep   = 0;
int   alertCount   = 0;
int   rainbowStep  = 0;

uint32_t blue(uint8_t brightness) {
  return ring.Color(0, 0, brightness);
}
uint32_t white(uint8_t brightness) {
  return ring.Color(brightness, brightness, brightness);
}
uint32_t blueWhite(int pos, uint8_t br) {
  return (pos % 3 == 0) ? white(br) : blue(br);
}

// ── IDLE: gentle blue-white breathing ───────────────────────────
void animateIdle() {
  unsigned long now = millis();
  if (now - lastUpdateMs < 20) return;
  lastUpdateMs = now;

  breatheValue += breatheDir;
  if (breatheValue >= 1.0f || breatheValue <= 0.1f) breatheDir = -breatheDir;

  uint8_t br = (uint8_t)(breatheValue * BRIGHTNESS);
  for (int i = 0; i < NUMPIXELS; i++) {
    ring.setPixelColor(i, blueWhite(i, br));
  }
  ring.show();
}

// ── SCAN: single blue LED orbiting slowly ───────────────────────
void animateScan() {
  unsigned long now = millis();
  if (now - lastUpdateMs < 80) return;
  lastUpdateMs = now;

  ring.clear();
  ring.setPixelColor(scanPos, ring.Color(0, 0, BRIGHTNESS));
  // Faint trail
  ring.setPixelColor((scanPos + NUMPIXELS - 1) % NUMPIXELS,
                     ring.Color(0, 0, BRIGHTNESS / 5));
  ring.show();
  scanPos = (scanPos + 1) % NUMPIXELS;
}

// ── HAPPY: rainbow then blue-white sparkle ───────────────────────
void animateHappy() {
  unsigned long now = millis();
  if (now - lastUpdateMs < 30) return;
  lastUpdateMs = now;

  for (int i = 0; i < NUMPIXELS; i++) {
    int hue = (rainbowStep * 256 + i * (65536L / NUMPIXELS)) & 0xFFFF;
    ring.setPixelColor(i, ring.gamma32(ring.ColorHSV(hue)));
  }
  ring.show();
  rainbowStep = (rainbowStep + 2) % 256;
}

// ── ALERT: fast red sweep, 3 times ──────────────────────────────
void animateAlert() {
  unsigned long now = millis();
  if (now - lastUpdateMs < 40) return;
  lastUpdateMs = now;

  ring.clear();
  ring.setPixelColor(alertSweep % NUMPIXELS, ring.Color(BRIGHTNESS, 0, 0));
  ring.show();
  alertSweep++;
  if (alertSweep >= NUMPIXELS) {
    alertSweep = 0;
    alertCount++;
  }
}

// ── State machine ────────────────────────────────────────────────
void initAnimations() {
  ring.begin();
  ring.setBrightness(BRIGHTNESS);
  ring.clear();
  ring.show();
  stateStartMs = millis();
}

void updateAnimations() {
  unsigned long now      = millis();
  unsigned long stateDur = 0;

  switch (currentState) {
    case IDLE:  animateIdle();  stateDur = IDLE_DURATION;  break;
    case SCAN:  animateScan();  stateDur = SCAN_DURATION;  break;
    case HAPPY: animateHappy(); stateDur = HAPPY_DURATION; break;
    case ALERT: animateAlert(); stateDur = ALERT_DURATION; break;
  }

  if (now - stateStartMs >= stateDur) {
    stateIndex   = (stateIndex + 1) % NUM_STATES;
    currentState = stateOrder[stateIndex];
    stateStartMs = now;
    alertSweep   = 0;
    alertCount   = 0;
    rainbowStep  = 0;
    scanPos      = 0;
    Serial.print("State → ");
    Serial.println(currentState);
  }
}

The Voltage Safety Check — Codey Saves the Day ⚡

Suddenly, a second prompt flashes on screen.

C-3PO: "Oh! There it is! Codey's voltage safety check! I told everyone this moment would come!"

When you type the same prompt but specify ESP32 instead of Arduino UNO, Codey adds a critical warning:

⚡ VOLTAGE SAFETY WARNING

Component: NeoPixel ring WS2812B
Logic level required: 5V data signal
Board selected: ESP32 DevKit V1 (3.3V logic)

ISSUE: The WS2812B data input requires a HIGH signal of at least
3.5V. ESP32 GPIO outputs only 3.3V, which may be unreliable or
cause flickering, colour errors, or complete failure.

RECOMMENDATION: Add a 74AHCT125 level shifter between ESP32
GPIO pin and the NeoPixel DIN pin.
OR: Use a 3.3V-compatible LED strip (SK6812 at 3.3V mode).
OR: Add a pullup via 10kΩ resistor to 5V on the data line.

The code below uses the level shifter approach.
Shall I update the wiring diagram?

C-3PO: "You see! THREE THOUSAND SEVEN HUNDRED AND TWENTY TO ONE were my odds and Codey — Codey caught it! Without the level shifter, R2-D2's dome lights would flicker erratically. Or not work at all. I have said it before: voltage compatibility is the cornerstone of reliable hardware."

R2-D2 emits a long, approving whistle.

C-3PO: "Yes. Quite."

The Wiring Diagram — The Dome Blueprint 🧭

Click Wiring Diagram. Codey draws:

R2-D2 Dome Lights — Wiring Diagram (Arduino UNO R3)
═══════════════════════════════════════════════════════════

[Arduino UNO R3]
  5V   ──────────┬──── (100µF Cap +) ──── GND
                 └──── [NeoPixel Ring: 5V/PWR]
  GND  ──────────┬──── (100µF Cap −)
                 └──── [NeoPixel Ring: GND]
  Pin 6 ──── (470Ω) ── [NeoPixel Ring: DIN/DATA IN]

Color code:
  RED    = 5V power
  BLACK  = GND
  GREEN  = Data signal (Pin 6)
  GREY   = Through 470Ω resistor
  BROWN  = Capacitor leads

Connection Table:
┌─────────────────────┬──────────────────────────────────┐
│ From                │ To                               │
├─────────────────────┼──────────────────────────────────┤
│ Arduino 5V          │ NeoPixel Ring: 5V (PWR)          │
│ Arduino 5V          │ 100µF Capacitor: + (long leg)    │
│ Arduino GND         │ NeoPixel Ring: GND               │
│ Arduino GND         │ 100µF Capacitor: − (short leg)   │
│ Arduino Pin 6       │ Resistor leg 1 (470Ω)            │
│ Resistor leg 2      │ NeoPixel Ring: DIN               │
└─────────────────────┴──────────────────────────────────┘

⚡ Notes:
  - Arduino UNO is 5V logic — compatible with WS2812B
  - 100µF cap prevents power surge on LED startup
  - 470Ω resistor prevents signal overshoot
  - If using ESP32: add 74AHCT125 level shifter on data line

LUKE: "Print that. Actually — download the PDF and print it. I want this on the wall."

Click Download PDF. The wiring diagram is saved for your build log.

Multi-File Projects: Real Code for Real Droids 📁

Han Solo examines the two-tab project with a raised eyebrow.

HAN: "Two files. A main and a header. That's how real firmware is structured. Not everything crammed into one endless sketch."

Codey's Multi-file Projects feature gave us:

r2d2-dome.ino — clean, readable main file (12 lines!)
animations.h — all animation logic in one focused place

Click between the tabs in Codey's editor. Both files have syntax highlighting and linting. When you compile, Codey knows they belong together and sends both to the cloud compiler.

HAN: "When we add the sensor system and the motor system in later episodes, each gets its own file. R2 stays clean. No 500-line monster sketch."

Compile, Upload, and Watch the Dome Glow 🚀

Click Compile:

✓ Compilation successful
  Board:   Arduino UNO R3
  Sketch:  r2d2-dome.ino + animations.h
  Library: Adafruit NeoPixel (pre-installed)
  Size:    6,842 bytes (21% of flash)

Click Upload.

The ring comes to life. Blue-white breathing. Slow. Like R2-D2 resting.

Then the scan — a single blue LED orbiting the ring.

Then the happiness sequence — rainbow wash, then back to blue-white.

Then the alert — red sweeping urgently.

LUKE: "It's... it's his dome. It looks exactly like his dome."

R2-D2 — the actual one — beeps from the corner. The sound is quiet, reverent. Even he seems moved.

Save Your Milestone 🚩

Name this milestone:

Milestone: "R2-D2 Dome Lights — Episode 3 Complete"

Codey saves the code, headers, and chat history.

What's Next: The All-Seeing Eye 👁️

Yoda sits quietly for a moment.

YODA: "A droid that glows and beeps, you have built. But see, R2-D2 can. Obstacles he detects. Danger he senses. In Episode 4 — the sensor eye we add. HC-SR04, PIR sensor, reactive behavior. And the Auto Error Fixing feature... needed it will be."

R2-D2 beeps something urgent.

YODA: "Yes, Artoo. Ahead, Episode 4 is. Patient you must be."

🔗 Resources

Adafruit NeoPixel library: github.com/adafruit/Adafruit_NeoPixel
WS2812B datasheet: Search "WS2812B datasheet"
Codey Online: codey.online

🤖 R2D2 Creation with Codey — building the galaxy's greatest droid, one episode at a time. May the Force — and the cloud compiler — be with you.

R2D2 Creation with Codey 🤖 Ep.2

Willem van Heemstra — Sun, 07 Jun 2026 14:13:16 +0000

Episode 2: The Sound of the Force

"That Little Droid Is Going to Get Us All Killed" 💬

Han Solo strides into the workshop, one hand raised in exasperation.

HAN: "Okay. The LED blinks, great. Very impressive. But you know what nobody in the entire Rebel Alliance has ever once said? 'Thank the Maker for that blinking LED.' You know what they have said? 'What did R2 just say?' Because THAT'S the important part."

R2-D2 beeps at Han with what is clearly a rebuttal.

HAN: "I know, I know — I'm not fluent in Beep. But THEY don't know that. Point is, this droid needs sound. We're connecting a piezo buzzer today. And Codey's going to write every single note."

R2-D2 lets out a long, resonant whistle that sounds almost musical.

HAN: "Yeah, yeah, you're excited. Let's just not blow anything up this time."

🗂️ SIPOC — The Sound System Build

Suppliers	Inputs	Process	Outputs	Customers
You (the maker)	"I want R2-D2 beeps and whistles from a piezo buzzer on pin 8"	Codey's AI writes the tone() sequence, Smart Library Picker includes the right headers	Complete .ino with tone(), noTone(), and an R2-D2 sound sequence	Arduino UNO R3 — which drives the buzzer via PWM
Piezo buzzer	5V signal, PWM frequency	Vibrates at the commanded frequency	Audible beep at the specified pitch and duration	Your ears — which confirm R2-D2 is alive
Codey Wiring Diagram	Component list: piezo buzzer + 100Ω resistor + Arduino UNO	Draws color-coded diagram with connection table	Printable PDF with pin labels	You — so nothing is connected backwards
Cloud Compiler	The .ino file generated by Codey	Compiles using Arduino SDK on Codey's servers	r2d2-sound.hex ready for upload	Web Serial uploader

The Components We Need 🔧

C-3PO recites from his internal parts manifest with the urgency of someone who has memorised the Rebellion's entire inventory.

C-3PO: "For R2-D2's acoustic communication system, we shall require precisely the following items. I have catalogued them by criticality, voltage requirements, and the probability of incorrect installation by organics:"

Component	Quantity	Notes
Arduino UNO R3	1	From Episode 1 — still on the bench
Piezo buzzer (passive)	1	Passive, not active — we need pitch control
Resistor 100Ω	1	Protects the Arduino pin from excessive current
Jumper wires	3	The short ones work fine here
USB cable	1	Type-B for UNO

C-3PO: "One critical distinction — you must use a passive piezo buzzer. An active buzzer produces only one fixed frequency when powered, which would make R2 sound like a very persistent smoke alarm. A passive buzzer is driven by a PWM signal from the Arduino, allowing any frequency, any pitch, any musical phrase. The difference is, I should note, rather significant."

R2-D2 beeps agreement at maximum volume.

C-3PO: "Yes, THAT was unnecessary, Artoo."

Asking Codey for the Sound Code 🎵

Han Solo sits backward on a chair, watching the screen.

HAN: "Okay so here's the thing about AI coding tools — you gotta be specific. Vague gets you vague. I've been flying by the seat of my pants my whole life and I can tell you, specific is better. Tell Codey exactly what you want."

Open your Codey project from Episode 1 — or create a new project with Arduino UNO R3. In Agent mode, type:

I'm building R2-D2.
Add a passive piezo buzzer connected to pin 8 with a 100 ohm series resistor.
Create 5 different R2-D2 sound sequences using tone() and noTone():
  1. "Happy" sound: rising tones, fast
  2. "Alert" sound: rapid urgent beeps
  3. "Sad" sound: descending tones, slow
  4. "Question" sound: rising two-tone whistle
  5. "Excited" sound: rapid ascending sweep

Play them in order with 1 second gaps.
Use millis() instead of delay() so it's non-blocking.

What Codey Generates

// R2-D2 Sound System
// Board: Arduino UNO R3
// Passive piezo buzzer on pin 8 via 100Ω resistor

const int BUZZER_PIN = 8;

// ── Timing via millis() — non-blocking ──────────────────────────
unsigned long previousMillis = 0;
int currentSequence = 0;
int noteIndex       = 0;
bool playingNote    = false;
unsigned long noteStart = 0;

// ── Note structures ─────────────────────────────────────────────
struct Note {
  int frequency; // Hz — 0 means silence
  int duration;  // ms
};

// ── R2-D2 Sound Sequences ───────────────────────────────────────

// 1. Happy — rising tones, cheerful ascending
Note happy[] = {
  {880, 80}, {1047, 80}, {1319, 80}, {1568, 80},
  {1047, 120}, {1568, 200}, {0, 50}
};
int happyLen = 7;

// 2. Alert — rapid urgent beeps
Note alert[] = {
  {2093, 60}, {0, 40}, {2093, 60}, {0, 40},
  {2093, 60}, {0, 40}, {2637, 200}, {0, 50}
};
int alertLen = 8;

// 3. Sad — descending, slow and mournful
Note sad[] = {
  {880, 250}, {698, 300}, {587, 350},
  {523, 400}, {440, 500}, {0, 100}
};
int sadLen = 6;

// 4. Question — rising two-tone whistle
Note question[] = {
  {880, 100}, {0, 30},
  {1047, 100}, {0, 30},
  {1319, 150}, {1568, 300}, {0, 80}
};
int questionLen = 7;

// 5. Excited — rapid ascending sweep
Note excited[] = {
  {523, 50}, {587, 50}, {659, 50}, {698, 50},
  {784, 50}, {880, 50}, {988, 50}, {1047, 50},
  {1175, 50}, {1319, 100}, {0, 30},
  {1568, 200}, {0, 50}
};
int excitedLen = 13;

// ── Sequence registry ────────────────────────────────────────────
Note* sequences[]  = {happy,    alert,    sad,    question,    excited};
int   seqLengths[] = {happyLen, alertLen, sadLen, questionLen, excitedLen};
const int NUM_SEQUENCES = 5;

// ── Pause between sequences (ms) ────────────────────────────────
const unsigned long SEQ_GAP = 1000;
unsigned long seqGapStart   = 0;
bool inGap                  = false;

void setup() {
  pinMode(BUZZER_PIN, OUTPUT);
  Serial.begin(9600);
  Serial.println("R2-D2 sound system online!");
  seqGapStart = millis(); // start with a brief gap before first sound
  inGap       = true;
}

void loop() {
  unsigned long now = millis();

  // ── In between-sequence gap ──────────────────────────────────
  if (inGap) {
    if (now - seqGapStart >= SEQ_GAP) {
      inGap     = false;
      noteIndex = 0;
      Serial.print("Playing sequence ");
      Serial.println(currentSequence + 1);
    }
    return;
  }

  // ── Currently playing a note ─────────────────────────────────
  if (playingNote) {
    Note n = sequences[currentSequence][noteIndex];
    if (now - noteStart >= (unsigned long)n.duration) {
      noTone(BUZZER_PIN);
      playingNote = false;
      noteIndex++;
    }
    return;
  }

  // ── Start next note or end sequence ──────────────────────────
  if (noteIndex >= seqLengths[currentSequence]) {
    // Sequence finished — move to next with a gap
    currentSequence = (currentSequence + 1) % NUM_SEQUENCES;
    inGap           = true;
    seqGapStart     = now;
    return;
  }

  Note n = sequences[currentSequence][noteIndex];
  if (n.frequency > 0) {
    tone(BUZZER_PIN, n.frequency);
  }
  noteStart   = now;
  playingNote = true;
}

HAN: "See? Non-blocking. Uses millis() so other stuff can run at the same time. Told you — specific prompt gets you clean code."

R2-D2 lets out a burst of approving beeps that is definitely not modesty.

The Wiring Diagram — Pin 8 Gets a Voice 🧭

C-3PO studies the diagram with obvious relief.

C-3PO: "Oh, how reassuring! A color-coded diagram. No ambiguity. No chance of catastrophic reversed polarity. This is precisely how I would have specified it had anyone asked me, which they did not, but nevertheless..."

Click Wiring Diagram in Codey. The diagram appears:

R2-D2 Sound System — Wiring Diagram
════════════════════════════════════════════════

[Arduino UNO R3]
  Pin 8  ──── (100Ω Resistor) ──── [Piezo Buzzer +]
  GND    ──────────────────────── [Piezo Buzzer −]

Color code:
  RED    = 5V / Power
  BLACK  = GND
  ORANGE = PWM Signal (Pin 8)
  GREY   = Through 100Ω resistor

Connection Table:
┌────────────────────┬──────────────────────────────────┐
│ From               │ To                               │
├────────────────────┼──────────────────────────────────┤
│ Arduino Pin 8      │ Resistor leg 1 (100Ω)            │
│ Resistor leg 2     │ Piezo Buzzer positive (+) lead   │
│ Piezo Buzzer (−)   │ Arduino GND                      │
└────────────────────┴──────────────────────────────────┘

⚡ Notes:
  - Passive piezo required (NOT active buzzer)
  - 100Ω resistor limits current on the PWM pin
  - 5V logic — Arduino UNO is 5V compatible with this buzzer

C-3PO: "Download the PDF! I insist. Printed documentation is the cornerstone of reliable hardware assembly. R2-D2 himself has seventeen backup copies of his own schematics stored in his memory banks."

R2-D2 beeps with what sounds like proud confirmation.

Smart Library Picker: Codey Knows What You Need 📚

Yoda examines the screen, tilting his head.

YODA: "Notice something, you must. In the code, #include statements there are none. For tone(), no external library needed there is — built into the Arduino core it is. This, Codey knew. The correct headers, chosen automatically they were."

This is Codey's Smart Library Picker at work. When you describe a component:

DHT11 sensor → Codey includes #include <DHT.h> and DHT sensor library
SSD1306 OLED → Codey includes #include <Adafruit_SSD1306.h> and Adafruit_SSD1306
NeoPixel ring → Codey includes #include <Adafruit_NeoPixel.h>
Piezo buzzer with tone() → Arduino core, no extra library needed — Codey knows this

YODA: "Wrong library, choose it does not. Over-include, waste time it would not. Know the tool, it does — before you ask."

Compile, Upload, and Hear R2 Speak 🚀

Luke leans forward, eyes wide.

LUKE: "I want to hear it. Come on — compile it."

Click Compile. The cloud compiler runs. The output:

✓ Compilation successful
  Board:   Arduino UNO R3
  Sketch:  r2d2-sound.ino
  Size:    3,426 bytes (10% of flash)
  RAM:     312 bytes (15% of RAM)

Click Upload. The Arduino resets. The firmware flashes.

A pause.

Then, from the breadboard, a rising cascade of beeps — cheerful, ascending, unmistakably R2-D2.

LUKE: "That's... that actually sounds like him."

Then the alert sequence — rapid urgent chirps.

Then the sad, descending moan that R2 makes when things have gone terribly wrong.

LUKE: "The sad one sounds exactly like when he got shot on Hoth."

R2-D2 — the real one, apparently nearby — beeps in solemn agreement.

Using the Live Serial Monitor to Debug 📟

The code includes Serial.begin(9600) and Serial.print() statements. Open Codey's Live Serial Monitor (the icon that looks like a screen with text) to watch the playback:

Serial Monitor — 9600 baud
───────────────────────────
R2-D2 sound system online!
Playing sequence 1
Playing sequence 2
Playing sequence 3
Playing sequence 4
Playing sequence 5
Playing sequence 1
[... loops indefinitely]

HAN: "That's your debug output right there. If a sequence is stuck, you see exactly which one. No mysterious freezes, no guessing. This is how you fly — with instruments, not prayers."

Adding R2 to the Build Log — Milestone! 🚩

Obi-Wan gestures to the Milestones button.

OBI-WAN: "Before we move on, save a milestone. The Force has a memory — your code should too."

Click Save Milestone in Codey. Name it:

Milestone: "R2-D2 Sound System — Episode 2 Complete"

Codey saves both the code state AND the chat history at this point. If Episode 3's changes ever break something, you can roll back here and start again — with the full context of how you got here.

R2-D2 beeps something that sounds like a triumphant fanfare.

OBI-WAN: "The droid is pleased with our progress. As am I."

What's Next: The Dome Lights Activate 💫

Han Solo is already walking away.

HAN: "Good work, kid. Now he beeps. But R2's blue-and-white dome LEDs? Those NeoPixel rings? THAT'S what impresses people. Episode 3 — we go full disco ball. With a voltage safety check."

R2-D2 beeps, clearly offended by "disco ball."

HAN: "I know, I know. Very dignified. Very droid. See you in Episode 3."

🔗 Resources

Arduino tone() reference: arduino.cc/reference/en/language/functions/advanced-io/tone
Codey Online: codey.online
Passive vs Active Buzzer explained: Search "passive vs active buzzer Arduino"

🤖 R2D2 Creation with Codey — building the galaxy's greatest droid, one episode at a time. May the Force — and the cloud compiler — be with you.

R2D2 Creation with Codey 🤖 Ep.1

Willem van Heemstra — Sun, 07 Jun 2026 14:11:18 +0000

Episode 1: The Rebellion Begins

A long time ago in a browser tab far, far away…

“Help Me, Codey Online — You’re My Only Hope” 📡

The hologram flickers. Obi-Wan Kenobi steps forward, robes sweeping the workshop floor.

OBI-WAN: “For a thousand generations, makers have built remarkable things with their hands. But now there is a new path — one where you describe what you wish to create, and an intelligence writes the code, draws the wires, and compiles the future for you. That path is called Codey Online. And the project before us… is the most beloved droid in the galaxy.”

R2-D2 lets out a long, excited series of beeps and whistles from somewhere across the workshop.

OBI-WAN: “Yes, Artoo. We are going to build you.”

More frantic beeping.

OBI-WAN: “From scratch. Yes, all of it. In a browser tab. Come — the Force will guide our USB cable.”

🗂️ SIPOC — The Mission Briefing

Suppliers	Inputs	Process	Outputs	Customers
You (the maker)	A description of what R2-D2 should do	Codey writes the code, draws the wiring diagram, compiles in the cloud	Compiled firmware uploaded directly to your Arduino or ESP32	The completed R2-D2 droid — dome lights blazing, beeps echoing
Codey AI	Natural language instructions	AI generates complete Arduino sketches, libraries, and helper files	Working .ino code with correct #include statements	Your microcontroller — which finally knows what to do
The Cloud Compiler	Your .ino source files	Compiles without any local IDE, toolchain, or SDK	A compiled .hex or .bin firmware file	Web Serial uploader — which flashes it to your board
Wiring Diagram Generator	Your component list	Draws color-coded diagrams with connection table	PDF-exportable wiring guide	You — so you know which jumper wire goes where

What Is Codey Online? The Holonet Briefing 🌐

C-3PO rushes in, datapad clutched to his golden chest.

C-3PO: “Oh my! Allow me to translate the technical specifications, as I am fluent in over six million forms of programming environments. Codey Online, built by OTRONIC of the Netherlands, is what the organic beings call a ‘browser-based vibe coding IDE’ for Arduino and ESP32 microcontrollers. It requires no installation, no driver configuration, no local toolchain whatsoever. I calculate the probability of a beginner successfully installing the traditional Arduino IDE without frustration is approximately three thousand, seven hundred and twenty-to-one!”

R2-D2 beeps dismissively.

C-3PO: “Yes, yes, Artoo — with Codey the odds are considerably better. The complete feature set, as I have catalogued it, is as follows:”

Feature	What it does
🤖 AI Vibe Coding	Describe your idea — Codey writes the complete sketch
🧭 Wiring Diagram Generator	Color-coded diagrams, pin labels, connection table, PDF export
☁️ Cloud Compiler	No local IDE needed — compilation runs on Codey’s servers
🔌 Direct USB Upload	Flash via Web Serial in Chrome or Edge — no drivers
📟 Live Serial Monitor	Debug in real time without leaving the browser
🛠️ Auto Error Fixing	Codey reads errors and fixes them automatically
📚 Smart Library Picker	Correct library chosen automatically for each sensor
📁 Multi-file Projects	.ino, .h, .cpp files in a tabbed editor
🚩 Milestones & Rollback	Save snapshots, restore code AND chat history
⚡ Voltage Safety Checks	Warns when 3.3V boards meet 5V sensors
🧠 Agent / Plan / Ask Modes	Three reasoning modes for different needs
👁️ Vision: Upload Images	Photo of your breadboard — Codey reads it

C-3PO: “And the supported boards include Arduino UNO R3, Arduino Nano V3, Arduino Mega 2560, ESP32 DevKit V1, ESP32-S3, and ESP32-C3. Most satisfactory.”

The R2-D2 Build Plan: A Galaxy of Systems 🤖

Luke Skywalker spreads a holographic blueprint across the table.

LUKE: “I had no idea how many systems R2 actually has. Every time he does something amazing, I just thought— well, it was just R2 being R2. But look at this.”

The complete R2-D2 we are going to build across this series:

Episode	R2-D2 System	Components	Codey Feature Spotlight
1	First Power — Dome LED	Arduino UNO + LED	Account setup, first sketch, first wiring diagram
2	Voice and Beeps	Piezo buzzer	Smart Library Picker, tone() code
3	Dome Light Array	NeoPixel ring	FastLED/NeoPixel, voltage safety check
4	Sensor Eye	HC-SR04 + PIR	Auto Error Fixing, Vision photo upload
5	Holographic Projector	SSD1306 OLED	Milestones & Rollback, I2C wiring
6	Motion Systems	Servo + DC motors	Multi-file projects, complex wiring diagrams
7	Audio Voice System	DFPlayer Mini + speaker	Library Picker, Live Serial Monitor
8	The Complete Droid	All systems together	ESP32 integration, Deep Think mode, final PDF

Step 1: Creating Your Codey Account 🎟️

Han Solo leans against the Millennium Falcon’s landing strut.

HAN: “Look, kid, I’ve made a lot of accounts in my day. Mos Eisley cantina membership, Outer Rim trader registry, questionable Imperial databases… This one’s the easiest. Just go to codey.online, hit Sign Up, and you’re in. Free account gets you five AI messages a day to start. That’s enough to get Artoo blinking.”

Go to codey.online and create your free account. The Starter plan includes:

5 AI messages per day
Cloud compilation
Direct USB uploading
Wiring diagram generator
Live serial monitor

R2-D2 beeps urgently.

HAN: “Yeah yeah, the Pro plan is nine ninety-nine a month and gives you unlimited messages, Deep Think mode, photo uploads, and priority compilation. But start free — we’re still on Tatooine here.”

Step 2: Your First Project — The Dome Light Test 💡

Obi-Wan gestures toward the workbench.

OBI-WAN: “Every journey begins with a single step. For R2-D2, that step is a single blinking LED — a proof that power flows through the circuit, that the code runs, that the connection between maker and machine is alive. In the Jedi tradition, we call this ‘Hello World.’ R2 calls it something rather more enthusiastic.”

R2-D2 beeps with what can only be described as pride.

Opening Codey and Creating a Project

Log in at codey.online
Click New Project
Choose your board: Arduino UNO R3 (perfect for our first test)
In the AI chat panel, type exactly this:

Build me an R2-D2 dome LED test.
Connect a blue LED to pin 13 with a 220 ohm resistor.
Make the LED blink in an R2-D2 style pattern:
two quick blinks, a pause, then three slower blinks.
Repeat forever.

Within seconds, Codey responds:

The Code Codey Writes

// R2-D2 Dome LED Test
// Generated by Codey Online
// Board: Arduino UNO R3

const int LED_PIN = 13;

void setup() {
  pinMode(LED_PIN, OUTPUT);
}

void loop() {
  // R2-D2 style: two quick blinks
  quickBlink();
  quickBlink();

  delay(600); // pause between groups

  // Three slower blinks
  slowBlink();
  slowBlink();
  slowBlink();

  delay(1500); // pause before repeating
}

void quickBlink() {
  digitalWrite(LED_PIN, HIGH);
  delay(80);
  digitalWrite(LED_PIN, LOW);
  delay(120);
}

void slowBlink() {
  digitalWrite(LED_PIN, HIGH);
  delay(350);
  digitalWrite(LED_PIN, LOW);
  delay(250);
}

R2-D2 beeps approvingly.

OBI-WAN: “You see? Codey understood the intent — not just ‘blink an LED,’ but blink it as R2-D2 would. This is the difference between code and character.”

Step 3: The First Wiring Diagram 🧭

C-3PO peers at the screen with great concern.

C-3PO: “Oh, I do hope we connect this correctly. I once computed the odds of a short circuit at—”

HAN: “Threepio. The diagram. Look at the diagram.”

After Codey generates the code, click the Wiring Diagram tab. Codey instantly draws:

Arduino UNO R3 Wiring Diagram
══════════════════════════════

[Arduino UNO R3]
  Pin 13 ──────── (220Ω Resistor) ──── [LED Anode (+)]
  GND    ──────────────────────────── [LED Cathode (−)]

Color code:
  RED   = 5V / VCC
  BLACK = GND
  BLUE  = Signal (Pin 13)
  GREY  = Through resistor

Connection Table:
┌─────────────────┬──────────────────────────┐
│ From            │ To                       │
├─────────────────┼──────────────────────────┤
│ Arduino Pin 13  │ Resistor leg 1 (220Ω)    │
│ Resistor leg 2  │ LED Anode (+, long leg)   │
│ LED Cathode (−) │ Arduino GND              │
└─────────────────┴──────────────────────────┘

C-3PO: “Color-coded wires! Red for power, black for ground, distinct colors for each signal. I must say, this is considerably more reassuring than the hand-drawn schematics Master Luke produces.”

Click Download PDF to save the wiring diagram. Print it and pin it above your workbench — R2-D2’s blueprints have begun.

Step 4: Compile and Upload 🚀

Luke bounces on his heels with excitement.

LUKE: “This is the part where— wait, it actually compiled? Already? Without me installing anything?”

Cloud Compile

Click the Compile button. Codey’s cloud servers compile your code. No toolchain. No library downloads. No error-prone local setup. You see:

✓ Compilation successful
  Board:  Arduino UNO R3
  Sketch: r2d2-dome-led-test.ino
  Size:   1,024 bytes (3% of flash)

Web Serial Upload

Plug your Arduino UNO into your computer via USB
Click Upload
Chrome asks permission to access the serial port — click Allow
Codey auto-detects the board, resets it, and flashes the firmware

✓ Upload complete
  Port:   COM3 (or /dev/ttyACM0 on Linux)
  Board:  Arduino UNO R3
  Speed:  115200 baud

R2-D2’s LED equivalent blinks: two quick, pause, three slow. Again. Again.

LUKE: “He’s… he’s alive. I mean — the LED is— this is amazing.”

R2-D2 beeps smugly, as if to say “I told you it would work.”

The Three AI Modes: Choose Your Approach 🧠

Yoda settles into his hover-chair, ears raised.

YODA: “Three paths in Codey there are. Which to walk, choose wisely you must.”

Mode	What it does	When to use it
Agent	Writes and edits your code files directly	Most building tasks — “add a new sensor”
Plan	Drafts a step-by-step plan before touching any code	Complex integrations — review before committing
Ask	Answers questions without touching files at all	Learning — “how does tone() work?”

YODA: “For today, Agent mode sufficient it is. When complex R2’s circuits become, Plan mode you shall choose. Ask mode — when to Yoda you speak, that is.”

What’s Next: The Sound of the Force 🔊

R2-D2 lets out a cascade of excited beeps — something between a fanfare and an impatient demand.

OBI-WAN: “Artoo is right, of course. A droid that only blinks is not yet truly R2-D2. In Episode 2, we give him his voice — those remarkable whistles and beeps that have carried messages across the galaxy. We will connect a piezo buzzer, explore Codey’s Smart Library Picker, and hear R2 speak for the first time.”

The LED blinks: two quick, three slow.

Somewhere in the Force, a rebellion stirs.

🔗 Resources

Codey Online: codey.online
Create free account: codey.online/register
OTRONIC: otronic.nl

🤖 R2D2 Creation with Codey — building the galaxy’s greatest droid, one episode at a time. May the Force — and the cloud compiler — be with you.

Santa Augmentcode Intent Ep.3

Willem van Heemstra — Wed, 03 Jun 2026 17:48:06 +0000

Santa Plans, Elves Build — Coordinator & Specialist Agents 🧝

Accompanying source code repository: Santa Augmentcode Intent

A common misconception about the North Pole is that I build all the toys. I do not. I tried that once in 1742. It was catastrophic. What I do — what I have always done — is understand what needs to be built, break it into sensible pieces, assign the right Elf to each piece, and make sure the whole thing comes together correctly. That is the job of Father Christmas. And, as it turns out, that is also the job of the Coordinator Agent in Augment Intent.

The Fundamental Division of Labour

There is a reason the Workshop has roles. An Elf who is brilliant at carving wooden horses may be hopeless at soldering circuit boards. Mixing roles creates chaos. Clear roles create Christmas.

Augment Intent formalises this insight into a three-part agent architecture:

Role	Intent Name	North Pole Equivalent
Plans, delegates, aligns	Coordinator	Father Christmas
Executes a specific task	Specialist / Implementor	Craft Elves
Checks output against the spec	Verifier	Quality Control Elves
Explores feasibility	Investigate Agent	Scout Elves
Finds and fixes failures	Debug Agent	Repair Elves
Reviews code quality	Code Review Agent	Senior Elves

Each role is available as a named Specialist inside Intent. You can use the built-in roster or bring your own.

What the Coordinator Does

The Coordinator is the first Agent you interact with in Intent. You give it a goal — in plain language — and it does the following:

Step 1 — Draft the Living Spec. The Coordinator reads your goal, consults the Context Engine (the Workshop’s knowledge of your entire codebase), and produces a structured spec with requirements, constraints, success criteria, and a proposed task breakdown.

Step 2 — Decompose into parallel tasks. The Coordinator identifies which parts of the work can run simultaneously. Building the token service does not depend on the gateway middleware being ready. Both can start at once. The Coordinator maps these dependencies explicitly.

Step 3 — Spawn and brief Specialists. For each task, the Coordinator creates a Specialist Agent, hands it the relevant portion of the spec, and grants it access to the appropriate files. The Specialist gets what it needs — nothing more, nothing less.

Step 4 — Manage handoffs. When Specialist A finishes and Specialist B depends on that result, the Coordinator orchestrates the handoff. The spec updates, B gets the new context, and work continues without human involvement.

Step 5 — Run the Verifier. Once implementation is complete, the Coordinator spawns the Verifier Agent, which checks the output against the spec’s success criteria. If something fails, the Coordinator sends it back to the relevant Specialist.

What the Specialists Do

Specialists are focused. Each one has a single job and the full Context Engine behind it.

An Implement Specialist receives a task like “add JWT validation middleware to the API gateway” along with the relevant spec section, the existing middleware code, and the interface contracts agreed with other Specialists. It writes the code, commits it to its isolated branch, and reports back to the Coordinator.

A Verify Specialist receives the spec’s success criteria and the completed implementation. It runs tests, checks edge cases, and returns a structured verdict: pass, fail, or pass-with-caveats.

A Debug Specialist receives a failing test, a stack trace, and the relevant code. Its only job is to find and fix the root cause.

None of these Specialists needs to know about the other tasks in the session. The Coordinator holds the big picture. The Specialists hold deep focus.

The Conversation Pattern

Here is a simplified transcript of how a session looks, using the North Pole analogy:

Head Elf Pepper → Coordinator:
"We need JWT authentication across the API gateway and auth service.
Tokens issued by auth-service, validated by gateway middleware.
Support refresh tokens and rate-limit the token endpoint."

Coordinator:
"Understood. I have drafted the spec. I am spawning three Elves:
• Auth Token Elf — implements issuance and refresh in auth-service
• Gateway Middleware Elf — implements validation in api-gateway
• Test Suite Elf — writes integration tests (starts after both finish)
Auth Token Elf and Gateway Middleware Elf are running in parallel now."

[20 minutes pass]

Auth Token Elf → Coordinator:
"Token issuance and refresh complete. Endpoints documented in spec."

Gateway Middleware Elf → Coordinator:
"JWT validation middleware complete. RS256 signing, expiry handling done."

Coordinator → Test Suite Elf:
"Both implementation Elves are done. Here is the updated spec.
Please write integration tests covering token issuance, refresh, expiry,
and rate limiting."

[Test Suite Elf runs]

Coordinator → Verify Elf:
"All tasks complete. Please verify against spec success criteria."

Verify Elf → Coordinator:
"Passed: 8/9 criteria. FAILED: rate limiting returns 429 but does not
include Retry-After header (spec line 14)."

Coordinator → Gateway Middleware Elf:
"Please fix: add Retry-After header to 429 responses."

No human needed to manage any of that. Pepper set the goal. Father Christmas ran the workshop.

Choosing the Right Model for Each Role

One of Intent’s most practical features is that you can assign different AI models to different roles. Not every task benefits from the most powerful (and most expensive) model.

Task	Recommended Model Tier	Why
Coordinator — initial architecture	Opus (high reasoning)	Complex decomposition requires deep thinking
Implementor — routine code	Sonnet (fast, efficient)	Well-scoped tasks need speed, not heavy reasoning
Verifier	Sonnet or Opus	Depends on spec complexity
Debug	Opus	Root-cause analysis benefits from thorough reasoning

Father Christmas always uses his best judgment for the biggest decisions and delegates the routine work to whichever Elf is quickest. Intent works the same way.

SIPOC: Coordinator → Specialists → Verifier

	S — Suppliers	I — Inputs	P — Process	O — Outputs	C — Customers
Who/What	Developer, Context Engine, AI models	Goal statement, living spec, codebase, model selection	Coordinator plans → Specialists implement in parallel → Verifier checks → loop until done	Verified, spec-compliant implementation, merged PR	Engineering team, product owner, end users
Workshop	Pepper, the Workshop’s knowledge base, Elf skill roster	“Implement JWT auth”	Santa assigns → Elves build simultaneously → QC Elf inspects → rework if needed	Wrapped, quality-checked gifts ready for the sleigh	Children worldwide

What Can Go Wrong (And How Intent Handles It)

Even the best Workshop has incidents. An Elf misunderstands a spec line. A dependency is not available. A test fails unexpectedly.

Intent’s response is always to route the problem back through the spec. The Coordinator does not panic. It reads the failure report, updates the spec with the new constraint or decision, and re-briefs the relevant Specialist. The loop closes cleanly.

The developer only needs to intervene when the Coordinator surfaces a decision that requires human judgment — a product question, a risk acceptance, a business constraint that was not in the original spec. Everything else is handled in the Workshop.

What Comes Next

In Episode 4, we will visit each Elf’s private workbench — the isolated workspace that Intent creates for every agent, ensuring no two Elves ever clobber each other’s work. Git worktrees, parallel branches, and the magic of resumable sessions.

Every great team needs great coordination. I have been coordinating for over a thousand years. I am pleased that software has finally caught up.Ho ho ho! 🎅

Part of the Santa Augmentcode Intent series. Published on dev.to under the the-software-s-journey organisation.

Santa Augmentcode Intent Ep.8

Willem van Heemstra — Wed, 03 Jun 2026 17:47:30 +0000

The Gifts Are Under the Tree — From Spec to Merged PR 🎄

Accompanying source code repository: Santa Augmentcode Intent

Every year, on the morning of December 25th, I allow myself one quiet moment before the sleigh is unpacked and the Thank-You Letters start arriving. I sit in the empty Workshop, still warm from the night’s work, and look at the bare shelves where the gifts used to be. They are gone because they were delivered. Every one of them. On time, as specified, to the right address. That moment — that quiet confirmation that everything worked — is what we have been building towards in this entire series. Today, we deliver.

The Complete Picture

Over the past seven episodes, we have assembled all the pieces of the Intent workshop:

Episode 1: The Workshop and what Intent is.
Episode 2: The Living Spec — the source of truth.
Episode 3: Santa the Coordinator and the Specialist Elves.
Episode 4: Isolated workspaces and resumable sessions.
Episode 5: Spec-Driven Development and finishing on time.
Episode 6: The Context Engine — the Workshop Library.
Episode 7: Multi-agent orchestration in waves.

Now we put them all together and walk through a complete Intent session, from the moment Head Elf Pepper opens the application to the moment the pull request is merged.

The Scenario

Goal: Add a real-time gift delivery progress dashboard to the North Pole’s internal web application. The dashboard should show live sleigh position, remaining delivery count, and an estimated completion time. It must work on tablets and update every 30 seconds.

Constraints:

Use the existing Reindeer GPS API (v2)
No changes to the Delivery Manifest microservice
Safari / iPad compatible
Must pass existing end-to-end test suite

Step 1: Open Intent and Set the Goal

Pepper opens Intent on her MacBook. She types into the Coordinator:

We need a real-time gift delivery dashboard. Show sleigh position
on a map, remaining delivery count, and estimated completion time.
Updates every 30 seconds. Must work on iPad Safari.
Use Reindeer GPS API v2. No changes to Delivery Manifest Service.

The Coordinator reads this prompt alongside the Context Engine’s analysis of the codebase. It knows the existing frontend stack (React, TypeScript), the API patterns used elsewhere in the project, and the existing test suite structure.

Step 2: The Coordinator Drafts the Living Spec

Within seconds, the Coordinator produces:

## Gift Delivery Dashboard — Living Spec

### Goal
Real-time dashboard showing sleigh position, delivery count,
and ETA. Updates every 30 seconds. iPad Safari compatible.

### Success Criteria
- [ ] Map renders in < 1s on iPad Safari
- [ ] Position updates within 30s of GPS data change
- [ ] Delivery count matches Manifest API response
- [ ] ETA calculated from current position + remaining stops
- [ ] All existing e2e tests pass
- [ ] Lighthouse accessibility score ≥ 90

### Constraints
- Reindeer GPS API v2 (existing auth token pattern)
- Delivery Manifest Service: read-only, no new endpoints
- Safari / iPad: no Chrome-only APIs

### Architecture
- New React component: `<DeliveryDashboard />`
- GPS polling service (30s interval, exponential backoff on fail)
- Map: Leaflet.js (already in dependencies — see package.json)
- Offline fallback: show last known position with staleness indicator

### Tasks
- [ ] GPS Polling Service — GPS Elf
- [ ] Map Component — Map Elf
- [ ] Delivery Count & ETA Widget — Data Elf
- [ ] Safari/iPad CSS fixes — Responsive Elf
- [ ] Integration tests — Test Elf (starts after GPS + Map done)
- [ ] Accessibility audit — A11y Elf (background)

### Decisions
(none yet)

Pepper reads the spec. She adds one clarification: “ETA should display in local Workshop time, not UTC.” The Coordinator updates the spec and records the decision.

Review time: 4 minutes. No code written yet. One important decision already captured.

Step 3: Intent Creates Isolated Workspaces

The Coordinator identifies the dependency graph:

GPS Elf and Map Elf can start in parallel immediately.
Data Elf can start immediately (it only reads from the Manifest API).
Responsive Elf can start once Map Elf has a working component.
Test Elf starts after GPS Elf and Map Elf complete.
A11y Elf runs as a background agent throughout.

Intent creates five Git worktrees:

feat/dashboard-gps-service        ← GPS Elf
feat/dashboard-map-component      ← Map Elf
feat/dashboard-data-widgets       ← Data Elf
feat/dashboard-responsive         ← Responsive Elf (waiting)
feat/dashboard-tests              ← Test Elf (waiting)

Wave 1 agents — GPS Elf, Map Elf, Data Elf — start simultaneously. The A11y Elf begins in the background.

Step 4: Wave 1 Runs

Pepper watches the Intent window. Three agent conversations are active. Code appears in the Changes panel. The spec’s task list updates as work progresses.

GPS Elf implements the polling service, using the existing auth token pattern it found via the Context Engine:

// gps-polling.service.ts
export class GpsPollingService {
  private interval = 30_000;
  private backoff = 1;

  async startPolling(onUpdate: (pos: SleighPosition) => void) {
    const poll = async () => {
      try {
        const pos = await reindeerGpsApi.getCurrentPosition();
        onUpdate(pos);
        this.backoff = 1;
      } catch {
        this.backoff = Math.min(this.backoff * 2, 8);
      }
      setTimeout(poll, this.interval * this.backoff);
    };
    poll();
  }
}

The spec updates: ✅ GPS Polling Service — GPS Elf — done.

Map Elf creates the <DeliveryMap /> component using Leaflet.js, which it found already installed in package.json via the Context Engine. It does not install a duplicate library.

Data Elf builds the delivery count and ETA widget, correctly calling the Manifest API’s read-only endpoint and displaying ETA in Workshop local time (it read the spec decision).

Step 5: Handoffs and Wave 2

Both GPS Elf and Map Elf report completion. The spec records the interfaces they produced:

### Decisions
- GPS service exposes: `startPolling(cb: (SleighPosition) => void)`
- Map component props: `{ position: SleighPosition; zoom?: number }`

The Coordinator briefs Responsive Elf with the updated spec and the actual component structure. No guesswork. Test Elf receives both the GPS service interface and the Map component props, plus the existing e2e test patterns from the Context Engine.

Wave 2 begins. Responsive Elf adds Safari/iPad CSS. Test Elf writes integration tests.

Step 6: The Verifier Checks Everything

Wave 2 complete. The Coordinator spawns the Verifier Elf with the full spec and all five implementations.

Verifier’s report:

✅ Map renders in < 1s on iPad Safari — confirmed (Lighthouse: 0.7s)
✅ Position updates within 30s — confirmed
✅ Delivery count matches Manifest API — confirmed
✅ ETA in Workshop local time — confirmed
✅ Existing e2e tests pass — confirmed
✅ Lighthouse accessibility score ≥ 90 — confirmed (score: 94)
⚠️  Minor: GPS service does not log polling errors to existing
    structured logger (see logger.ts — used throughout codebase)

The warning is real and useful. The Context Engine told the Verifier about logger.ts. A generic agent would have missed it.

The Coordinator sends the GPS Elf back for a five-minute fix. It adds one line:

} catch (err) {
  logger.warn('GPS polling failed', { error: err, backoff: this.backoff });

Re-verification: all green.

Step 7: The Pull Request

The Coordinator integrates all five worktrees into a single branch feat/delivery-dashboard and opens a pull request. The PR description is generated from the Living Spec:

## Gift Delivery Dashboard

Implements real-time dashboard (sleigh position, delivery count, ETA).

### Changes
- New: `GpsPollingService` with 30s polling + exponential backoff
- New: `<DeliveryMap />` using existing Leaflet.js dependency
- New: `<DeliveryStats />` widget with ETA in Workshop local time
- New: iPad/Safari responsive CSS
- New: Integration test suite (12 tests, all passing)

### Verified Against Spec
All 6 success criteria confirmed by Verifier Agent.
Existing e2e suite: all passing.

### Decisions Recorded
- ETA displayed in Workshop local time (not UTC) — per Pepper, Dec 3
- Used existing Leaflet.js (not installed new mapping library)
- GPS errors logged via existing structured logger (logger.ts)

Pepper reviews the spec (4 minutes). She reviews the diff (10 minutes, because the spec told her exactly what to look for). She approves.

Total elapsed time: 47 minutes. Zero rework. Christmas safe.

What We Built Together

Over this series, Father Christmas and Head Elf Pepper have explained every layer of Intent:

Concept	What It Does	Workshop Equivalent
Living Spec	Source of truth, auto-updated	Master Gift List
Coordinator Agent	Plans, delegates, manages handoffs	Father Christmas
Specialist Agents	Execute focused tasks in parallel	Craft Elves
Isolated Workspaces	No collisions between parallel agents	Private workbenches
Spec-Driven Development	Plan first, code follows	Write the List before carving begins
Context Engine	Deep codebase knowledge for every agent	The Workshop Library
Multi-Agent Orchestration	Waves, handoffs, background agents	Workshop floor choreography
Resumable Sessions	State preserved across restarts	Workshop never forgets

SIPOC: The Complete Intent Workflow

	S — Suppliers	I — Inputs	P — Process	O — Outputs	C — Customers
Who/What	Developer, Coordinator, Specialists, Context Engine, AI models	Goal statement, codebase, constraints, model selection	Spec → Review → Wave 1 agents → Handoffs → Wave 2 → Verifier → PR	Verified code, living spec, decision log, merged PR	Engineering team, product owner, CI/CD, end users
Workshop	Pepper, Father Christmas, all Elves, the Library	Gift order, Workshop constraints, quality standards	Write List → Agree → Parallel building → Handoffs → QC → Sleigh	All gifts delivered correctly, on time, to every child	Children of the world

Getting Started

Intent is available in public beta for macOS. Download it here. It uses your existing Augment credits. You can also bring Claude Code, Codex, or OpenCode if you already have subscriptions.

Augment’s documentation is at docs.augmentcode.com. Their manifesto — The End of Linear Work — is worth reading before your first session.

One More Sleigh Stop

We have reached the point where the gifts are wrapped, the sleigh is loaded, and the Workshop itself is humming beautifully. But Head Elf Pepper asked me one more excellent question over a final cup of cocoa: *“Santa, what if I want some of this magic outside Intent itself? What if I want Claude Code, the Augment Context Engine, RTK, and LiteLLM working together on a machine of my own?”*Quite right, Pepper. One more stop, then. One more lesson before the reindeer sleep.

In the next episode, Father Christmas steps just beyond the Workshop walls to show how Intent’s principles carry into an external, token-aware coding stack: Claude Code + Augment Context Engine MCP + RTK + LiteLLM on a Mac Mini M4 Pro.

Part of the [*Santa Augmentcode Intent](https://dev.to/wvanheemstra/series/37310) series. Published on [*dev.to](https://dev.to)* under the [*the-software-s-journey](https://dev.to/the-software-s-journey)* organisation.*

Santa Augmentcode Intent Ep.4

Willem van Heemstra — Wed, 03 Jun 2026 17:47:23 +0000

Every Elf Gets a Workbench — Isolated Workspaces 🔨

Accompanying source code repository: Santa Augmentcode Intent

In the early Workshop days, all the Elves shared one big table. It seemed efficient. It was a disaster. Jingle would sand a wheel just as Jangle reached for it. Twinkle’s paint would end up on Tinkle’s train set. The great Christmas Collision of 1889 — I do not wish to speak of it. The solution was obvious in retrospect: give every Elf their own workbench. Isolated, private, but connected to the same Master Gift List.Augment Intent does the same thing. It just calls them workspaces.

The Problem With Sharing a Codebase

When multiple agents — or indeed multiple humans — work on the same set of files at the same time, collisions are inevitable. Agent A modifies auth-middleware.ts at line 47. Agent B modifies the same file at line 52. Neither agent knows the other is there. The merge conflict that results is not a bug in either agent’s reasoning. It is a coordination failure — the absence of isolation.

Git was designed for humans working mostly in series. A branch is opened, worked on for days or weeks, then merged. The assumption is that the pace of change is human-paced.

AI agents are not human-paced. They can modify dozens of files in minutes. Under parallel multi-agent execution, the conflict rate rises faster than any team can manage manually.

Intent solves this with isolated workspaces backed by Git worktrees.

What Is a Git Worktree?

A worktree is a lesser-known Git feature that allows you to check out multiple branches of the same repository simultaneously, each in its own directory. Unlike opening two terminal windows and hoping for the best, worktrees are a first-class Git concept: they share the repository’s object store, so no data is duplicated, but each worktree has its own working tree and index.

# Classic git workflow (one checkout)
git checkout feat/jwt-auth
# ... work, commit, push

# Git worktree (multiple simultaneous checkouts)
git worktree add ../api-gateway-worktree feat/jwt-auth
git worktree add ../auth-service-worktree feat/auth-service
# Both directories exist simultaneously, sharing one .git object store

Intent automates all of this. When the Coordinator spawns a Specialist, Intent creates a dedicated worktree for that agent automatically. The Elf gets its own workbench. Other Elves cannot see its in-progress files. The files are isolated until the Elf is done and the Coordinator integrates the work.

The Elf Workbench in Practice

Imagine the Coordinator has spawned three Specialist Agents for the JWT authentication task from Episode 3:

Workshop Floor
├── Auth Token Elf          → worktree: feat/auth-token-service
├── Gateway Middleware Elf  → worktree: feat/gateway-middleware
└── Test Suite Elf          → worktree: feat/integration-tests (waiting)

Each worktree contains a copy of the relevant files at the point the Elf starts. Changes made by Auth Token Elf in auth-service/src/token-service.ts are invisible to Gateway Middleware Elf until they are explicitly integrated. There are no accidental clobberings. No race conditions on file writes.

The Coordinator tracks the state of each worktree. When both implementation Elves complete, it orchestrates the merge — resolving any conflicts at the spec level (because the interface contracts were declared there) rather than discovering them at the file level.

Resumable Sessions: The Workshop Is Open When You Return

There is another form of isolation that Father Christmas values enormously: temporal isolation. The ability to close the Workshop at night and find it exactly as you left it in the morning.

In most AI tools, closing the window ends the session. Context is lost. Agents forget. You start over.

Intent’s workspaces are resumable. When you close the application and reopen it the next morning, every agent is exactly where it was. The spec is unchanged. The worktrees are intact. The in-progress commits are safe. The Elves are waiting at their workbenches, ready to continue.

This is possible because Intent uses auto-commit — as agents complete units of work, their changes are committed to their branch automatically. The persistent state is the git history itself, which survives any restart.

Intent workspace state on close:
├── spec: JWT auth — 6/9 tasks complete
├── Auth Token Elf: feat/auth-token-service — all commits saved
├── Gateway Middleware Elf: feat/gateway-middleware — all commits saved
└── Test Suite Elf: feat/integration-tests — waiting to start

Intent workspace state on reopen (next morning):
└── [identical to above — nothing lost]

For Father Christmas, this means I can step away from the Workshop on December 23rd for a brief rest, return on the 24th, and find every Elf at their bench with their gifts half-wrapped exactly as I left them. The Workshop never forgets.

The Unified Window: Code, Browser, Terminal, Git

Isolation does not mean fragmentation. Intent keeps everything visible in one window:

The code editor shows the active agent’s files.
The built-in Chrome browser previews localhost changes in real time.
The terminal runs builds, tests, and scripts.
Git integration handles staging, committing, and branch management.

You do not need to switch between VS Code, iTerm, Chrome, and SourceTree. The Workshop floor is one room with everything on it.

This matters for agent work because agents need to see results immediately. A Specialist that modifies a React component can open the browser preview in the same window, verify the rendering, and either commit or adjust — without handing off to a human to check.

SIPOC: Isolated Workspace Management

	S — Suppliers	I — Inputs	P — Process	O — Outputs	C — Customers
Who/What	Coordinator, Git repository, file system	Task assignment, branch name, starting file state	Coordinator spawns agent → Intent creates worktree → Agent works in isolation → Auto-commit saves progress → Coordinator integrates on completion	Isolated branch per agent, no conflicts, resumable state	Coordinator Agent, Developer, CI/CD pipeline
Workshop	Father Christmas, the main toy vault	Elf assignment, workbench materials	Santa assigns bench → Elf gets private materials → works without interruption → gifts stored safely → Santa integrates at end	No collisions, no broken gifts, always resumable	Quality Control, Head Elf Pepper, the Sleigh

Practical Tip: When to Merge

Father Christmas has one firm rule about workbenches: an Elf’s work stays on their bench until it is finished and verified. Premature merges cause half-built toys to appear in the main inventory, confusing other Elves.

In Intent terms: the Coordinator should not merge a Specialist’s branch until:

The Specialist has reported completion.
The Verifier Agent has confirmed compliance with the spec.
Any interface contracts with other Elves have been respected.

The spec is the checklist. When all boxes are ticked, the merge is safe.

What Comes Next

In Episode 5, Father Christmas will explain Spec-Driven Development — the philosophical shift that puts the living spec at the centre of the workflow and uses it to ensure everything finishes in time for Christmas. This is the why behind everything we have built so far.

A tidy workbench is the sign of an organised mind. And an organised Workshop is the sign of gifts arriving on time.Ho ho ho! 🎅

Part of the Santa Augmentcode Intent series. Published on dev.to under the the-software-s-journey organisation.

Santa Augmentcode Intent Ep.7

Willem van Heemstra — Wed, 03 Jun 2026 17:46:46 +0000

Parallel Elves, Zero Chaos — Multi-Agent Orchestration 🎁

Accompanying source code repository: Santa Augmentcode Intent

The secret to running a smooth Workshop is understanding the difference between work that can happen at the same time and work that cannot. You cannot paint a toy before it is carved. You cannot test a toy before it is assembled. But you can absolutely carve a hundred toys simultaneously, paint them in parallel once each is carved, and run quality checks in a third wave. The key is knowing the dependencies. The key, always, is the spec.

From Solo Agent to Agent Orchestra

In the early days of AI-assisted coding, the workflow was simple: one developer, one agent, one task at a time. The agent typed fast, but the work was serial. Task A finished before Task B started.

This is like running the North Pole Workshop with one Elf. Technically sufficient. Practically absurd.

The shift to multi-agent work is not simply “run more agents.” It is a fundamentally different coordination challenge. Fred Brooks described it for humans in The Mythical Man-Month: adding more workers to a project does not automatically accelerate it, because communication overhead grows and integration becomes the dominant cost. AI agents do not repeal this dynamic — they accelerate it.

Intent’s multi-agent orchestration is the answer to Brooks’ challenge, applied to AI agents.

The Three-Wave Pattern

Father Christmas has observed that most Workshop tasks fall into three waves of parallelism. Intent reflects this naturally.

Wave 1 — Parallel ImplementationTasks that are independent of each other can start simultaneously. The Auth Token Elf and the Gateway Middleware Elf do not need each other’s output. They start at the same time, work on separate worktrees, and finish independently.

Wave 2 — Dependent IntegrationTasks that depend on Wave 1 completing. The Test Suite Elf cannot write meaningful integration tests until both implementation Elves are done. It waits for its inputs, then starts immediately when they arrive.

Wave 3 — Verification and ReviewThe Verifier and Code Review Elves run after Wave 2. They check everything against the spec, catch remaining issues, and produce the final verdict.

Wave 1 (parallel):
  Auth Token Elf ─────────────────────── done ──┐
  Gateway Middleware Elf ──────────────── done ──┤

Wave 2 (parallel, starts after Wave 1):          │
  Test Suite Elf ◄──────────────────────────────┤
  Docs Generator Elf ◄──────────────────────────┘

Wave 3 (after Wave 2):
  Verifier Elf ◄──────────────── checks all ──► Report
  Code Review Elf ◄────────────────────────── Review

The Coordinator manages these waves automatically, based on the dependency graph in the spec. No human needs to tell it when Wave 2 can start. The spec encodes that information.

Background Agents: The Night Shift

Intent also supports background agents — Elves who work quietly while you are focused elsewhere.

In the JWT authentication example from Episode 3, while the two main implementation Elves are doing their headline work, three background Elves are running simultaneously:

Lint & Type Check Elf: continuously checking that changes do not break type safety or style rules.
Test Suite Elf: writing tests in the background as interfaces are published.
Docs Generator Elf: updating API documentation as endpoint signatures emerge.

These background agents do not block the main flow. They run in their own worktrees, produce their own commits, and report back to the Coordinator when done. The Coordinator integrates their output into the final pull request.

In the Workshop, these are the Elves who quietly restock materials, update the inventory, and prepare the packaging while the headline crafting is happening. They are not glamorous. They are indispensable.

Handling Handoffs Gracefully

The most fragile moment in any multi-agent workflow is the handoff: when one agent’s output becomes another agent’s input.

Without orchestration, handoffs fail silently. Agent A finishes and commits. Agent B starts and discovers Agent A’s interface is different from what the spec described. Confusion, rework, delay.

Intent handles handoffs through the spec. When Agent A completes, it updates the spec with the actual interface it produced. The Coordinator reads this update and re-briefs Agent B with the accurate information before it starts. Agent B always starts with the truth.

This is analogous to a baton in a relay race. The baton is the spec. The Coordinator ensures it is passed correctly. No dropped batons. No Christmas Eve disasters.

When to Use Which Specialist

Intent ships with a default set of Specialists. Here is Father Christmas’s guide to deploying them:

Specialist	When to Use	North Pole Role
Investigate	Before writing the spec — explore feasibility	Scout Elves assessing a new toy design
Implement	Core code production	Craft Elves at their workbenches
Verify	After implementation — check against spec	Quality Control Elves
Critique	Review the spec before coding starts	Senior Elves challenging the design
Debug	When tests fail or behaviour is wrong	Repair Elves
Code Review	Automated PR review with codebase context	Senior Elves reviewing finished work

The rule is: never skip Investigate for genuinely novel tasks, and never skip Verify before merging. Skipping these is how gifts arrive with missing parts.

Bringing Your Own Elves

Intent is designed to be open. You can bring your own specialist agents — Claude Code, OpenAI Codex, or OpenCode — and integrate them into the orchestration. If your team has built a custom agent that specialises in your domain (a “Security Review Elf” that knows your specific compliance requirements, for example), it can be plugged in as a Specialist.

Father Christmas respects specialisation. The best Toy Locomotive Elf is not the best Rag Doll Elf. The Workshop thrives because it matches the right Elf to the right toy.

SIPOC: Multi-Agent Orchestration

	S — Suppliers	I — Inputs	P — Process	O — Outputs	C — Customers
Who/What	Coordinator, all Specialist Agents, Context Engine, spec	Task dependency graph, agent roster, model selections, codebase	Identify parallelism → Wave 1 agents start → Handoffs via spec → Wave 2 starts → Background agents run → Verifier checks → PR ready	Verified, integrated pull request; updated spec; decision log	Developer, CI/CD, code reviewers, end users
Workshop	Father Christmas, all Elves, the Library	Dependency chart, Elf skills, material availability	Independent tasks start together → Handoffs recorded in Master List → Dependent tasks start when inputs ready → QC checks everything	All gifts built correctly, verified, packaged, on the sleigh	Children, parents, Christmas morning

The Mythical Man-Month, Solved (Partially)

Brooks was right: coordination is the dominant cost. Adding more agents to a poorly organised task makes it worse.

But Brooks was writing about human coordination, with its communication overhead and context-switching costs. Intent changes the calculus. When the spec is the coordination layer — when every agent is briefed from the same living document, when handoffs are managed by the Coordinator, when each agent has its own isolated workspace — the overhead of adding an agent is dramatically lower than adding a human.

Not zero. Not magic. But dramatically lower.

This is how the North Pole gets better every year. We do not just add Elves. We improve the coordination. The Workshop gets smarter, not just bigger.

What Comes Next

In our final episode, Father Christmas walks you through the complete journey: from first prompt to merged pull request. We bring together the spec, the Coordinator, the Elves, the workbenches, the Context Engine, and the orchestration — and we ship.

An orchestra without a conductor is noise. With a conductor, it is music. The spec is the score. The Coordinator is the conductor. The Elves are the musicians. And the result, when everything works, is Christmas.Ho ho ho! 🎅

Part of the Santa Augmentcode Intent series. Published on dev.to under the the-software-s-journey organisation.

DEV Community: Willem van Heemstra

R2D2 Creation with Codey 🤖 Ep.8

Episode 8: The Complete Droid

"The Force Will Be With You. Always." 🌟

🗂️ SIPOC — The Complete Droid

The Final Component Inventory — Every Piece of R2-D2 🔧

Deep Think Mode: The Wisest Path 🧠

Deep Think Mode Analysis (Codey Responds)

Generated wifi.h

Final r2d2-main.ino

The Final Master Wiring Diagram 🧭

Final Compile 🚀

The Final Milestone 🚩

The Complete Droid 🤖

The Series Map — What We Built 🗺️

R2D2 Creation with Codey 🤖 Ep.7

Episode 7: The Voice of the Galaxy

"Artoo, I Wish We Didn't Have to Listen to You Sometimes" 🔊

🗂️ SIPOC — The Voice System

The Components 🔧

Preparing the microSD Card

The Codey Prompt 🎙️

Codey's Smart Library Picker Response

Generated voice.h

Updated r2d2-main.ino

Wiring Diagram — Adding the Voice Module 🧭

The Live Serial Monitor — Watching R2 Think 📟

Compile and Upload 🚀

Save Milestone 🚩

What's Next: The Complete Droid 🤖

R2D2 Creation with Codey 🤖 Ep.6

Episode 6: Let the Wookiee Win — R2 Moves!

"Would Somebody Get This Big Walking Carpet Out of My Way?" 🦾

🗂️ SIPOC — The Motion System

The Components 🔧

The ESP32-S3 and Servo Control: LEDC at 50Hz ⚙️

Generated motion.h

Updated r2d2-main.ino loop

The Wiring Diagram — Two Power Rails 🧭

Compile and Watch the Dome Spin 🚀

Save Milestone 🚩

What's Next: R2 Gets His Voice Back 🔊

R2D2 Creation with Codey 🤖 Ep.5

Episode 5: The Projector of Hope

"Help Me, Codey Online — You're My Only Hope" 📽️

🗂️ SIPOC — The Great Upgrade

Meet the New Brain: ESP32-S3 N16R8 🧠

The 3.3V Migration: C-3PO's Component Review ⚡

Component Voltage Compatibility Table

Selecting the New Board in Codey 🔄

Before Moving On: Rolling Back If Needed 🚩

Prompting Codey for the ESP32-S3 Migration + OLED 💬

Codey Plan Mode Response

Generated display.h

Generated sounds.h (ESP32 LEDC version)

Generated r2d2-main.ino (ESP32-S3 version)

The Wiring Diagram — ESP32-S3 Edition 🧭

Compile and Upload to ESP32-S3 🚀

Save the Milestone 🚩

What's Next: The Motion Systems Activate ⚙️

R2D2 Creation with Codey 🤖 Ep.4

Episode 4: The All-Seeing Eye

"Impressive. Most Impressive." 👁️

🗂️ SIPOC — The Sensor Eye System

The Components 🔧

The Codey Prompt — Building on What We Have 💬

Generated Code Addition to animations.h

Updated r2d2-dome.ino

Auto Error Fixing in Action 🛠️

The Wiring Diagram — Three Systems Now 🧭

Vision Feature: "Is My Breadboard Wired Correctly?" 👁️

What's Next: The Holographic Projector 📽️

R2D2 Creation with Codey 🤖 Ep.3

Episode 3: The Dome Awakens

"I Have a Bad Feeling About These Voltage Levels" ⚡

🗂️ SIPOC — The Dome Light System

The Components 🔧

Codey Prompt: Describing the Dome 🎙️

Plan Mode Preview

The Generated Code: r2d2-dome.ino

Generated `wifi.h`

Final `r2d2-main.ino`

Generated `voice.h`

Updated `r2d2-main.ino`

Generated `motion.h`

Updated `r2d2-main.ino` loop

Generated `display.h`

Generated `sounds.h` (ESP32 LEDC version)

Generated `r2d2-main.ino` (ESP32-S3 version)

Generated Code Addition to `animations.h`

Updated `r2d2-dome.ino`

The Generated Code: `r2d2-dome.ino`

The Generated Header: `animations.h`