CLAUDUINO

"Claude + Arduino = AI that controls real hardware. Write, deploy & debug firmware through conversation. The bridge between language models and the physical world."

Comment

CLAUDUINO

When AI meets Arduino, the conversation becomes physical.

Inspiration

Every Arduino project hits the same wall: write code, compile, upload, open the serial monitor, read the output, tweak a value, repeat — forever. The feedback loop between intent and hardware is brutally slow, and the cognitive load of remembering pin assignments, library quirks, and timing constraints falls entirely on the developer.

We asked a simple question: if LLMs can reason about code, why can't they reason about hardware?

The Model Context Protocol (MCP) gave us the answer. MCP provides a standardized way for AI models to call external tools — and there's no rule that says those tools have to be software. We realized we could expose an entire Arduino board as a set of callable tools, giving Claude the ability to read sensors, toggle relays, drive servos, and monitor serial output through natural language conversation.

The result is CLAUDUINO — a system where you describe what you want your hardware to do, and Claude makes it happen. No IDE. No compile-upload-debug cycle. Just conversation.

What it does

CLAUDUINO is a dual-server MCP architecture that gives Claude direct, bidirectional control over Arduino hardware through natural language:

Arduino Agent MCP — The development workflow layer:

  • Board detection, selection, and configuration
  • Library management (install, resolve, list)
  • Sketch compilation and upload via arduino-cli
  • Real-time serial monitor (start, read, send, stop)
  • Live monitoring dashboards
  • Firmware rollback and OTA upload support
  • Power estimation and schematic generation

Arduino MCP Extension — The hardware abstraction layer with 20+ tools:

  • Pin Configuration with human-readable aliases ("fan" instead of 7)
  • Relay Control with single and orchestrated multi-relay sequencing
  • PWM Waveform Generation for motor speed and LED dimming
  • RGB LED Pattern Animations (breathing, rainbow, pulse)
  • Multi-Sensor Fusion — read DHT11/DHT22, analog, I2C sensors with data fusion
  • Continuous Data Logging to serial, SD, or MQTT
  • Servo Choreography with keyframe-based animation
  • RF24 Wireless Networking — mesh setup and transmission via nRF24L01+
  • Event-Driven State Machines for complex automation logic
  • Yún Bridge Commands — execute Linux-side shell commands via the ATmega
  • Hardware Interrupts, Watchdog Timers, EEPROM, Analog Comparators
  • Power Management — sleep modes for battery-powered deployments
  • Full Hardware Diagnostics — memory check, I2C scan, voltage level validation

The key insight: Claude doesn't just send commands — it closes the loop. It reads serial feedback, interprets sensor data, diagnoses failures, rewrites firmware, re-uploads, and confirms the fix. The AI becomes a full participant in the hardware development cycle.

How we built it

The architecture is a Node.js/TypeScript MCP server built on the official MCP SDK, communicating with Arduino hardware over serial via the serialport library.

Stack:

  • Runtime: Node.js with TypeScript
  • MCP Framework: @modelcontextprotocol/sdk
  • Serial Communication: serialport library for bidirectional board communication
  • Build Toolchain: arduino-cli for compilation, upload, and library management
  • Validation: zod schemas for every tool parameter
  • Target Board: Arduino Yún (ATmega32U4 + Atheros AR9331 Linux SoC)

Architecture Pattern:

Claude (LLM) 
  ↕ MCP Protocol (JSON-RPC over stdio)
    ↕ Arduino Agent MCP Server (workflow tools)
    ↕ Arduino MCP Extension Server (hardware abstraction tools)
      ↕ serialport (USB serial)
        ↕ Arduino Yún (ATmega32U4 + Linux SoC)
          ↕ Physical Hardware (sensors, relays, servos, radios)

Every hardware tool follows the same pattern: resolve pin aliases → construct a serial command → send to the board → parse the response → return structured results to Claude. The Extension server maintains an in-memory pin alias map so Claude can refer to hardware by name rather than pin number.

For the Yún specifically, the Bridge library enables a unique capability: Claude can execute Linux commands on the Yún's Atheros processor through the ATmega, enabling WiFi configuration, file operations, and HTTP requests — all through natural conversation.

Challenges we ran into

Serial port timing was the first battle. Arduino boards reset when a serial connection opens. If Claude's tool loop fires too quickly, it catches the board mid-bootloader. We implemented connection stabilization delays and retry logic with exponential backoff.

Cross-platform COM port detection was surprisingly painful. Windows, macOS, and Linux all report serial devices differently. Auto-detection had to handle COM8, /dev/ttyACM0, and /dev/cu.usbmodemXXXX gracefully, plus deal with ghost ports from unplugged boards.

Preventing tool-loop thrashing was critical. Claude is eager — given a sensor reading tool, it will happily poll a DHT11 at 100ms intervals and crash the board. We implemented rate limiting, configurable polling intervals, and sensor fusion with caching to keep the hardware responsive.

Upload failure recovery required careful state management. If an upload fails mid-flash, the board can end up in an undefined state. We built firmware rollback capabilities and board state verification to ensure Claude can always recover gracefully without human intervention.

The DHT22 timing bug taught us the most. Claude was getting NaN readings from a humidity sensor. It autonomously hypothesized a timing issue, wrote a diagnostic sketch that tested both DHT11 and DHT22 modes, uploaded it, read the serial output, confirmed the sensor was actually a DHT11 (not DHT22 as labeled), rewrote the production sketch with the correct configuration, re-uploaded, and confirmed working readings — all in one uninterrupted conversation. Zero human intervention.

Accomplishments that we're proud of

Autonomous hardware debugging. Claude diagnosed a DHT sensor identification error, rewrote firmware, re-uploaded, and confirmed the fix without any human touching the keyboard. This is a genuine closed-loop AI-hardware feedback system.

20+ hardware tools with zero hardware abstraction leaks. Pin aliases, sensor fusion, relay orchestration, and servo choreography all work through clean, validated MCP tool interfaces. Claude never sees raw pin numbers unless it wants to.

Real production use. This isn't a demo — we built a working humidity-controlled fan system where Claude reads the DHT11, decides when humidity exceeds threshold, activates a relay to spin up a fan, and monitors the feedback loop until conditions stabilize. Physical automation through conversation.

Dual-server architecture that separates workflow concerns (compile/upload/monitor) from hardware abstraction (pins/sensors/actuators). This makes the system extensible — adding a new sensor type means adding one tool definition, not refactoring the entire server.

The "aha" moment came when we realized Claude could read its own serial output from a sketch it just uploaded, interpret the sensor data, and decide whether the code was working correctly — then fix it if not. The LLM wasn't just writing code. It was engineering.

What we learned

LLMs are remarkably effective hardware debuggers when given real-time feedback. The bottleneck in Arduino development was never AI reasoning — it was always the missing I/O bridge. Once Claude could see what the hardware was actually doing (via serial), its diagnostic accuracy was startling.

Pin aliasing changes everything. When Claude can say "turn on the fan" instead of "set pin 7 HIGH", the conversation becomes about intent rather than implementation. This is the difference between programming and engineering.

MCP is the right abstraction for hardware. The tool-calling pattern maps naturally to hardware operations. Each tool is essentially a hardware capability with validated inputs and structured outputs. The protocol handles all the complexity of bidirectional communication.

Rate limiting is a feature, not a constraint. Hardware has physical limits that software doesn't. Teaching the system to respect those limits (sensor read intervals, relay switching speed, servo slew rates) made the entire system more reliable.

What's next for CLAUDUINO

  • RF24 Wireless Mesh Support — Multi-node Arduino networks where Claude manages an entire mesh of distributed sensors and actuators through a single conversation
  • Arduino Yún WiFi Deployment — Remote hardware control over the network, so Claude can manage boards that aren't physically connected to the host machine
  • Visual Circuit Diagram Generation — Claude describes what it built, and the system generates wiring diagrams and schematics from the conversation
  • Cloud Relay Architecture — A relay server so Claude can control hardware remotely from anywhere, enabling IoT deployments managed entirely through natural language
  • CNC Machine Integration — Extend the MCP toolset to control CNC routers and 3D printers, bringing conversational AI to digital fabrication
  • Multi-Board Orchestration — Coordinate multiple Arduino boards simultaneously, with Claude managing inter-board communication and distributed state

Built With

  • node.js · typescript · arduino · model-context-protocol · serialport · arduino-cli · zod · claude · arduino-yun

Built With

Share this project:

Updates