How to use Claude to map a smart-car controller
Claude Code mapped a smart car's shift-register motor controls with human wheel observations. Failed GPIO tests preceded working Wi-Fi driving from a phone.
Suggested prompt
Suggested prompt written by Agents In Use, not the source author. Replace bracketed inputs and review tool permissions first.
Inspect the ESP32 smart-car specifications before flashing. Start with an LED and serial check, identify the motor-driver architecture and produce a one-bit-at-a-time mapping sketch. Pause for my wheel-direction observations, then build browser controls only from the verified map.
Reach people exploring AI agents
See placements →What happened
The car drove from a phone webpage after a human-verified motor mapping. Initial hypotheses failed; autonomous agent driving through a REST API had not been implemented.
Reported by SB Corvus — Personal blogHow the agent did it
- Claude compiled and flashed a board-identification sketch before investigating motor control.
- After failed GPIO and I2C tests, documentation identified the shift register.
- Corvus reported wheel motion for each tested bit, and Claude built verified movement and Wi-Fi browser controls.
Where a person stepped in
Corvus assembled and checked wiring, held the car up and identified each wheel movement, then drove it from a phone.
SB Corvus used Claude Code to program an ESP32 smart-car kit assembled with family members. The agent first compiled and flashed a small LED-and-serial sketch, then had to discover how the car's four motors were controlled.
The maker had not supplied the complete technical specification. Claude tried direct GPIO tests and I2C scans, neither of which moved the wheels. Further documentation research identified a 74HC595 shift register between the ESP32 and motor drivers, explaining why the earlier hypotheses could not work.
Claude wrote a sketch that tested the control bits individually. Corvus held the car above the table and reported which wheel moved and in which direction. That human observation supplied the verified mapping the agent needed to combine bits into forward, backward, turning and sideways movement.
The agent then wrote firmware that created a Wi-Fi hotspot and served touch controls in a phone browser. Corvus unplugged USB and drove the car around the living room. The result was working remote-control firmware, not an autonomous robot; a REST interface through which the agent itself could drive remained future work. The account's decisive feedback came from watching physical wheel motion, and its missed documentation was a reported source of wasted investigation.
Prompt
Suggested prompt (written by Agents In Use, not the author's)
Source: Personal blog · SB Corvus
Frequently asked questions
Why did direct GPIO tests fail?
The motors were driven through a 74HC595 shift register.
How was the motor map verified?
Corvus held the car up and reported the moving wheel and direction.
Could the agent drive autonomously?
Not yet. The reported result was phone-controlled firmware; the agent REST interface was planned.
More details
About this account
Claude compiled and flashed a board-identification sketch before investigating motor control. After failed GPIO and I2C tests, documentation identified the shift register.
Primary HTML retrieved and read after web-fetch failures. Initial GPIO and I2C hypotheses failed; omitted specifications cost time. Remote driving worked; a future agent-controlled REST API was not yet built. Suggested prompt written by Agents In Use; no original task prompt was published in the verified account.
Credit: SB Corvus — Personal blog
Source published 29 Mar 2026
Source checked 14 Oct 2026
Tools and topics
Claude Code · ESP32 · 74HC595 · Serial CLI · Phone browser
Motor mapping · Physical feedback
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.