An honest devlog of how a tank became a car, a "simple" telemetry link ate 3 weeks, and why the pile of failed prints in the corner is the most useful part of this project.
Intro: the gap between the render and the reality
When I pitched Project GEPARD, the vision was clean: a tracked, Ripsaw-inspired autonomous UGV with a sensor turret, self-docking, on-board AI, and a tactical command dashboard. Scaled-down EV-fleet tech in a one-foot rover.
What I actually have, weeks later, is a wheeled rover, a graveyard of failed prints, a multimeter I now can't live without, some chips I need to re-order, and a much deeper respect for the phrase "it's just a wiring problem."
This post is the honest version — every place the plan bent, every thing that released the magic smoke, and what I learned. The polished final build is the last post. This one is the mess in the middle, because that's where the actual engineering happened.
Part 1: The Great Pivots (Scope Creep in Reverse)
Most scope creep adds features. Mine mostly removed them — the harder and more valuable kind.
Pivot 1 — Tracks → Wheels (a printing defeat, told honestly). The whole identity was the aggressive tracked "Ripsaw" look, and I fought hard for it. I printed multiple sprocket designs and tested three different track-link designs, and hit a wall of print-reality problems the CAD never warns you about:
- Getting a printed track to actually seat and travel over the sprocket — it kept binding or skipping teeth.
- I redesigned the sprocket for dual-tooth engagement to grip better. It failed again.
- The real killer was tolerances and print settings — the gap between "looks right in CAD" and "flexes, meshes, and holds under load in PETG/TPU" was a tuning rabbit hole I couldn't climb out of in the time I had.
Eventually I made the honest call: switch to a differential wheeled drivetrain. Same tank-steer control, same motor driver, same code — but far better odometry (tracked skid-steer scrubs sideways and wrecks the encoder data any future SLAM needs), much faster to print, and it deleted my single highest-risk mechanical subsystem in one move. I lost the aesthetic. I kept the deadline. Sometimes engineering is knowing when to stop fine-tuning a thing that isn't converging.
Pivot 2 — Tri-Node Compute → "the board already does this." The original plan was three brains: Arduino for motors, ESP32 for Wi-Fi, a PC for heavy lifting. Then I actually read the Arduino UNO Q datasheet and realized it's already a dual-brain board — an STM32 real-time MCU plus a Qualcomm Linux computer with built-in Wi-Fi 5. I was bolting a weaker ESP32 Wi-Fi onto a board that already had a better one. The ESP32 got demoted to just the camera.
Pivot 3 — "Do Everything" AI → a finishable MVP. The design doc had Google Cast control, Workspace alarms, Bluetooth audio, cloud upload, facial recognition (owner vs. stranger vs. pet vs. rat), and IR-beacon precision docking — on a four-week clock. I cut all cloud/Bluetooth, kept and simplified manual drive + obstacle avoidance (the real MVP), offline voice, and April tag-marker docking instead of research-grade IR beacons. Face-rec, SLAM, and full autonomy became a documented Phase-2 roadmap instead of broken half-features.
Pivot 4 — The rear idler: sliding mount → eccentric cam → just a wheel. This one's a perfect little case study in over-engineering and then coming to my senses. The rear support started as a sliding-mount idler (slot + screw to tension). Then I got fancy and redesigned it as a 12-sided eccentric-cam idler — rotate the cam, move the axle, tension the track. Genuinely clever… for a track system I no longer had after Pivot 1. Once the tracks were gone, the whole reason for a tensioning idler evaporated. It collapsed down to what it should have been all along: a plain free-rolling wheel on a bearing, with a simple printed circle spacer to hold it off the chassis wall. Three designs to arrive at "a wheel."
Pivot 5 — The Docking Dream → a cardboard box with a printed face. Auto-docking is one of the most failure-prone things in mobile robotics. The honest MVP: a cardboard enclosure for the relay + a printed faceplate holding the pogo pads and ArUco marker at the right height. Proof of concept, documented as such.
Part 2: The Errors (the actually-useful part)
Error 1 — The 3.3 V that broke everything. The UNO Q looks like a 5 V Arduino. It is not — its headers are 3.3 V logic. My spec said "all sensors 5 V." That mismatch meant the HC-SR04's 5 V ECHO needed level-shifting, and only D2/D3 are bench-verified for interrupts on its STM32 — so my five-IR-encoders-on-five-interrupts plan was a coin-flip. Fix: two encoders on the two proven interrupt pins, the rest polled.
Error 2 — Powering I2C sensors at 5 V killed the whole bus. My INA226 and MPU6050 both showed offline at once. I assumed two dead boards. Wrong. Powering them from 5 V made their pull-up resistors drag the I2C lines to 5 V, so the 3.3 V UNO Q couldn't talk to either. Three symptoms, one cause. Fix: moved one wire from 5 V to 3.3 V; both woke up. Lesson: when multiple boards fail at once, look for the one shared thing — a rail, a ground, a bus — not multiple faults.
Error 3 — The 1 a.m. wiring mistake that cost me chips. Late-night bench work is a trap. At 1 in the morning I wired the ultrasonic sensor backwards — VCC into ground, ground into VCC. Reverse-polarity into a sensor is exactly how you release the magic smoke. That chip (and a couple of friends) are now on a re-order list. Lesson: past midnight, walk away. The mistake you make tired costs more than the sleep would have.
Error 4 — The motors that wouldn't spin (my code, not my wiring). My raw test sketch spun the motors. My "real" firmware left PWMA reading 0 V on the multimeter. Same wiring, so it was software. Two culprits, both mine: (1) an obstacle-override "safety" that force-stopped forward motion when the ultrasonic read too close or wasn't wired — my safety feature was stopping the wheels; (2) the Bridge used backwards. The UNO Q's two brains talk over an RPC "Bridge," and the official rule is: the MCU never initiates — Python always makes the call, the MCU only responds. My code had the MCU pushing telemetry, which silently fails. The fix is Python polling the MCU.
|
WRONG (what I did): MCU tries to push data at Linux — silently drops Bridge.notify("telemetry", distance, voltage, ticks /* ... */); RIGHT: MCU exposes a function; Linux POLLS it when ready void get_telemetry() { /* return sensor struct */ } void setup() { Bridge.begin(); Bridge.provide_safe("get_telemetry", get_telemetry); // MCU responds only Bridge.provide_safe("set_drive", set_drive); |
The multimeter ended the guessing: STBY = 3.3 V (driver awake), VM = 10.97 V (power good), PWMA = 0 V on "forward" (no signal) → the code, not the wiring.
Error 5 — Servo.h freezes the board. A diagnostic sketch used the classic AVR Servo.h. On the UNO Q's STM32/Zephyr stack it grabs a hardware timer the motor PWM needs — servo swept once, board froze. Classic "treat the UNO Q like a 5 V ATmega" trap.
Error 6 — The suppressed holes I found 25 hours too late. While cleaning up the rear chassis CAD, I suppressed the mounting holes and forgot to un-suppress them before hitting print. I noticed after the 25-hour print finished. No way I'm reprinting a full day of filament four days from deadline — so the fix became a printed drill-jig to re-add the holes with a soldering iron. Lesson: a pre-print checklist ("are all the holes actually there?") is cheaper than 25 hours.
Error 7 — I flipped the battery bay's length and width. Here's a fun one. I got the orientation of the battery bay wrong in CAD — swapped length and width — so when I went to install the 464 g battery pack, it didn't fit lying down the way I'd planned. My only option post-print was to stand the battery up vertically at the very back. That single mistake shoved the center of mass rearward, which then forced me to actually sit down and do a tipping calculation to make sure the rover wouldn't wheelie backward. (It won't — the CoM lands ~95 mm from the rear, inside the wheelbase, so it's stable, just rear-biased.) An orientation typo in a sketch turned into a physics homework problem. Lesson: double-check which dimension is length before you commit a 20-hour print.
Error 8 — The pan-tilt turret that ended in double-sided tape. The camera turret went through rounds of design → print → reprint: servo pockets that didn't fit, mounts that didn't hold, a built-in-spacer-vs-bearing conflict. After enough reprints eating time I didn't have, I did the honest maker thing and mounted it with double-sided tape. Not elegant. It works. Four days out, "works" wins. 
Error 9 — The print farm of sadness. 23-hour chassis prints (fine layers + high infill) → fixed with 0.28 mm layers, ~15–20% infill, 3 walls, and supports OFF. Warping on big flat PETG → brim, non-negotiable. An extruder squeal/skip (filament pushed then backed out) turned out to be wet PETG — drying the spool fixed the squeal, the stringing, and the surface finish at once. Wiggly soldered pins = cold joints; a board can read "dead" when it's really an intermittent joint, so re-flow before you condemn it.
Error 10 — Mechanical odds and ends. The motor mount alone evolved faceplate → pipe-clamp saddle → full sleeve → a half-U cradle (open top, prints with no supports, motor drops in, screws hold it). And the rear wheel axle taught me a 3 mm bearing needs a 3 mm axle — an M3 screw or literally a nail. Imperial 6-32 and 8-32 are both too fat to pass through a 3 mm bore; I measured, doubted, re-measured, and gave up on the hardware-store bin.
Part 3: How the software is structured now
The Bridge lesson forced a clean brain / spine model (which is also the officially-supported App Lab pattern):
|
1 STM32 MCU ── "spine" ── reflexes: read sensors, drive motors, fast + dumb 2 │ (Bridge RPC: Python polls, MCU responds) 3 ▼ 4 UNO Q Linux ── "brain's home" ── holds ALL sensor feeds, hosts dashboard, 5 │ (Wi-Fi) runs decision logic; AI sees every feed 6 ▼ 7 Browser (laptop or phone) ── tactical HUD at :7000 8 ▲ 9 Laptop GPU (RTX 3050) ── heavy muscle: YOLO / local LLM, only when needed |
Principles earned the hard way: the spine has veto and the brain proposes (but in manual mode nothing overrides me); every sensor reports its own ACTIVE/OFFLINE status so I bring the system up one circuit at a time, like an electrician testing a panel breaker by breaker; and the dashboard is hosted on the rover itself, reachable from any browser on my Wi-Fi — laptop or phone, no app to install.
Part 4: The Tactical HUD
If you're going to build a UGV, the command interface should look like one — dark theme, live camera center-stage, a sweeping proximity radar that plots the live ultrasonic contact, battery/voltage/speed gauges, a scrolling command console, and an "AI Cognition" panel that shows the brain's perception → decision stream in autonomous modes. (Insert HUD screenshot here.)
Where it stands + what's next
Working / in-hand: wheeled drivetrain (motors verified on the bench), the 3.3 V sensor suite coming online one circuit at a time, the WebUI control architecture, the printed chassis, and an educational pile of failed prints.
Next posts: getting all sensors green on the HUD; tuning the IR wheel-encoders (odometry is the road to mapping); the ArUco docking attempt (and the honest manual-dock fallback).
Phase-2 roadmap (documented, not promised): 2D SLAM room-mapping from encoder + IMU + sonar fusion, named locations in roam mode, and local (privacy-preserving) facial recognition.
The One Takeaway
The render never smokes. The prototype always does.
Every failed print, every wiring mistake, and every 0-volt reading in this post taught me something a clean success never would. Honestly, documenting those mistakes is probably the most useful thing I can hand to the next person who picks up an Arduino UNO Q and assumes it is just another 5 V Arduino.
If you are still reading, I'd like to share why this project means so much to me.
When I was in high school, I spent a lot of time building things. We had STEM classes where we worked on robotics-related projects, and one of the most memorable was building a small submarine. Outside of school, I was always experimenting with random ideas and turning them into increasingly complicated devices. One time I set out to build a simple handheld vacuum to clean my desk. By the end of the project, it had somehow evolved into a wheeled robot that could only vacuum very tiny particles.
After the military takeover in Myanmar, life took a very different direction. I stopped building projects altogether. Years passed, I moved to Canada, and eventually started my undergraduate studies. Somewhere along the way I realized I no longer had a hobby that I was genuinely excited about and life felt flat.
Then, by pure chance, I found a 3D printer on Facebook Marketplace for $100. About a week later I came across the Element14 EZ-EV Design Challenge. Before I knew it, I was designing parts, printing prototypes, making wiring mistakes, and staying up far too late troubleshooting electronics.
In a way, Project GEPARD is not just about building a rover. It is about reconnecting with the version of myself that loved making things when I was younger.
So please excuse the cable spaghetti in the videos, the rough prototype parts, and the occasional piece of double-sided tape holding something together. This project is very much a work in progress.
I would also like to thank Element14 for providing me with a sponsored kit. As a university student, I simply would not have been able to justify buying all of this hardware myself. The challenge gave me both the tools and the motivation to start building again. Without the competition, I probably would have kept telling myself, "I'll start next week."
I also owe everyone an apology for the quality of the video. It was recorded around 1 a.m. after a long day of work. I kept telling myself I would make a post after fixing one more bug, printing one more part, or reaching one more milestone. The result was that I kept pushing updates further and further back.
No more.
From this point forward, I am going to focus on documenting the process as it happens, mistakes and all. The written portions will remain organized and professional, but I am completely new to making videos, so thank you for bearing with me while I learn that side of the process as well.
More soon.
The wheels are turning. Mostly.
Featured in this post:
- 3 failed track designs
- Multiple failed sprocket revisions
- Rear idler redesigns
- Battery packaging mistakes
- 25-hour print failure
- Ultrasonic sensor wiring failure
- Current rover prototype footage
