In my last post, I was teaching my droid project to "see" and "think" on a Raspberry Pi 5. But 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 him, Willard.
The Physical Build
The assembly was surprisingly seamless. Elegoo helpfully 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 of these components are so tiny that getting them into place is a challenge. Even worse, once I got the robot moving, the jerky default programming caused the whole chassis to vibrate. Within minutes, I had bolts and screws flying off the robot like it was undergoing unplanned disassembly! It took some time to figure out where the bits came off of, and I'm not sure if there is some recommended way to actually set this up so that bits don't come off.
Lesson learned: I’ve taken Willard’s wheels off for now. This lets me debug the logic safely on my desk without him shaking himself to pieces or driving off the desk.
The "Hidden" Software Gatekeepers
Even though it’s a kit, customizing your robot car isn't exactly "plug and play." I ran into two gatekeepers that weren't in the printed manual (but were discoverable in the many docs available 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. You must flip it to "Upload" to talk to the Elegoo. It’s printed on the board, but so small you might miss it.
- The Missing Driver: Due to chip shortages, different serial chips might be installed. My Arduino IDE didn't "see" the board until I hunted down the CH340 driver hidden in the tutorial zip file.
Pro-tip: I’ve switched to the Arduino CLI for faster feedback:
arduino-cli compile --fqbn arduino:avr:uno --libraries . smart-robot-car-firmware.ino
This gives me fast feedback if something needs to be fixed.
And, I need that feedback because I keep finding out new things. One of the most frustrating things to debug in hardware is the Restart Loop. Unlike a computer, where an app crashes and gives you an error, an Arduino often just restarts. Because it boots so quickly, it can look like it's just "ignoring" your code or behaving weirdly, when in reality, it’s crashing and rebooting every few seconds.
Every Byte counts
One of the weirdest hurdles was moving to the CLI. The code compiled fine in the IDE, but the CLI threw a "Sketch too big" error.
ETA: I might be misremembering this step as it might be that it was erroring due to the Global variable size. This is what my usage looks like now
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.
It turns out the original firmware was already redlining the Arduino Uno's 32KB limit. Adding even the "negligible" overhead of the Servo library was enough to push it over the edge. I wrote a Python script to see which symbols were eating my space.
import subprocess
# Runs avr-nm to sort symbols by size
nm_output = subprocess.check_output(['avr-nm', '-S', '--size-sort', '-C', elf_file])
This led me to refactor the logic into a non-blocking state machine, reducing the JsonDocument size from 200 to 128 bytes, and replacing sprintf with Serial.write to avoid pulling in heavy string-formatting libraries.
An Independent Eye
The most interesting discovery? The camera isn't connected to the Elegoo brain at all for this kit. It operates on its own IP address. This means for this robot car the "Reflex" layer (Elegoo board) is completely blind to what the camera sees. Even so, this Elegoo kit is incredibly comprehensive; having all the sensors and the camera in one package helps me visualize how much can actually fit into a consumer-level robot.
It also gave me a much-needed reality check on weight restrictions. I’ve been questioning how the Raspberry Pi and the Arduino, along with the LEGO structure, might impede movement. Watching Willard navigate has given me a baseline for how much mass the motors can handle before performance starts to drop. My eventual goal will be to bridge the reflex/cognition gap—having the Pi analyze the visual data and then send high-level commands to my droid's Arduino "muscles."
What's Next
Willard is currently on the operating table. I’m deep in the weeds debugging why his Guard Duty behavior is returning "Ghost States."
Take a look at this serial output:
Current Distance: 13
Current Distance: 12
Alarm triggered!
Guard Duty State: 3 <-- Ghost State Detected
State 3 doesn't exist. This is the classic signature of a Buffer Overflow. Something in Willard's memory is spilling over and rewriting his state variables in real-time.
Next time, we perform surgery to find the leak!
If you've built this car and made modifications or if you have suggestions for other ideas please respond in the comments. So far, I've come up with 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. It uses I2C (Qwiic), which would keep the wiring clean and finally let Willard "speak" with custom tones and alerts.
Top comments (0)