Willard’s First Flight (and Unplanned Disassembly)

Source: Dev.to

In my last post I was teaching my droid project to “see” and “think” on a Raspberry Pi 5. While waiting for my Build Hat I discovered these car kits—a ready‑made option to explore physical motion immediately.

Enter the Elegoo Smart Robot Car Kit v4.0, or as my son affectionately calls it, Willard.

The Physical Build

The assembly was surprisingly seamless. Elegoo provides the three screwdrivers you need, and the bags are neatly labeled. It felt very much like “IKEA instructions meet electronics.”

However, I quickly hit a physical “hardware tax.” Some components are so tiny that getting them into place is a challenge. Once the robot was moving, the jerky default programming caused the whole chassis to vibrate. Within minutes bolts and screws were flying off the robot—an unplanned disassembly! I’m not sure if there is a recommended way to secure everything, so for now I’ve taken Willard’s wheels off and debug the logic safely on my desk.

The “Hidden” Software Gatekeepers

Even though it’s a kit, customizing the robot car isn’t exactly “plug and play.” Two gatekeepers aren’t highlighted in the printed manual (but are documented in the downloadable zip file).

• The Upload Toggle: The expansion hat has a tiny toggle switch. If it’s set to App mode you cannot upload code; flip it to Upload to talk to the Arduino. The label is tiny and easy to miss.
• The Missing Driver: Due to chip shortages, different serial chips may be installed. My computer didn’t recognize the board until I installed the CH340 driver hidden in the tutorial zip file.

Pro‑tip: I switched to the Arduino CLI for faster feedback:

arduino-cli compile --fqbn arduino:avr:uno --libraries . smart-robot-car-firmware.ino

A common frustration is the “Restart Loop.” Unlike a PC app that crashes with an error, an Arduino often just restarts, making it look like it’s ignoring your code when it’s actually rebooting every few seconds.

Every Byte Counts

Moving to the CLI revealed a “Sketch too big” error that didn’t appear in the IDE. The original firmware was already close to the Arduino Uno’s 32 KB limit; adding the Servo library pushed it over.

Current build size:

Sketch uses 21166 bytes (65%) of program storage space. Maximum is 32256 bytes.
Global variables use 1208 bytes (58%) of dynamic memory, leaving 840 bytes for local variables. Maximum is 2048 bytes.

I wrote a small Python script to list symbols by size:

import subprocess

# Runs avr-nm to sort symbols by size
nm_output = subprocess.check_output(['avr-nm', '-S', '--size-sort', '-C', elf_file])

Refactoring the logic into a non‑blocking state machine reduced the JsonDocument size from 200 bytes to 128 bytes, and replacing sprintf with Serial.write avoided pulling in heavy string‑formatting libraries.

An Independent Eye

The camera in this kit isn’t connected to the Arduino at all; it operates on its own IP address. Consequently, the Arduino “reflex” layer is completely blind to what the camera sees. Still, having all sensors and the camera in one package makes it easy to visualize what fits into a consumer‑level robot.

It also gave me a reality check on weight restrictions. Watching Willard navigate provided a baseline for how much mass the motors can handle before performance degrades. My eventual goal is to bridge the reflex/cognition gap—having the Pi analyze visual data and send high‑level commands to the Arduino “muscles.”

What’s Next

Willard is currently on the operating table. I’m deep in debugging why his Guard Duty behavior is returning “Ghost States.”

Serial output example:

Current Distance: 13
Current Distance: 12
Alarm triggered!
Guard Duty State: 3  <-- Ghost State Detected

State 3 doesn’t exist, which is a classic signature of a buffer overflow—memory spilling over and overwriting state variables in real time. Next time I’ll perform surgery to find the leak.

If you’ve built this car, made modifications, or have ideas, feel free to comment. So far I’ve implemented a “Guard” mode (detecting motion via proximity changes) and a “Dance” mode (multi‑color lights and pre‑programmed steps).

I’m also considering adding an Arduino Modulino buzzer module that uses I²C (Qwiic) to keep wiring clean and finally let Willard “speak” with custom tones and alerts.