Welcome to the penultimate post for Project GEPARD V5.0. Before I publish the final project summary and overall review for the Element14 EZ-EV Challenge, I need to take a massive step back and be completely honest about the realities of building an autonomous UGV from scratch.
If there is one overarching takeaway from this entire experience, it is this: compared to the veteran engineers on this forum, I am at the absolute bottom of the robotics learning curve. I took on a project that required a deep understanding of mechanical stress distribution, software abstraction layers, and electrical routing. My biggest mistake wasn't my ambition—it was my isolation. I should have asked this community for help far more often. You all have decades of experience, and my stubbornness to brute-force my way through debugging cost me days of progress.
This build taught me an incredible amount, but it was an absolute trial by fire. Here is my candid retrospective on my master blueprint, the mechanical flaws that emerged under load, the software walls I hit, and the hardware that didn't survive the journey.
The Master Blueprint and the "Rung" System
When I started Project GEPARD, I knew I was building something complex, so I tried to be as disciplined as possible. I didn't want to build a static toy; I wanted to build a modular autonomous IoT rover that could be used as a testbed for operational analytics.
To prevent myself from getting overwhelmed by scope creep, I architected a strict PMO (Project Management Office) Gate System to lock my progress. I broke the build down into specific, non-negotiable rungs:
* Rung 1 (The True MVP): Motor validation to simply make the wheels spin using the UNO Q, TB6612 motor driver, and the battery.
* Rung 2 & 3: Establishing basic communication tests and manual WASD UDP control from the PC to the rover.
* Rung 4 & 5: Completing the drive chain and separating the ESP32 camera as its own independent module.
I explicitly banned myself from writing code for auto-docking, YOLOv8 vision, or SLAM mapping during Build 1, pushing all of those features strictly into Phase 2.
However, a perfect paper blueprint does not survive contact with reality. Even though I was only trying to execute Rung 1 and Rung 2, I learned the hard way that theoretical planning is only half the battle. If you don't fully understand how each individual part interacts with the power bus and the logic board before you plug them all in, you will spend dozens of hours hopelessly debugging a tangled system. Integrating a multi-node system without testing component interactions individually creates a state where power, logic, and code bugs overlap.
Mechanical Forensics: Chassis Wear Under Load
Because I actually managed to get the chassis moving for testing, the physical realities of 3D-printed robotics quickly became apparent. Building a heavy, tracked FWD rover puts immense stress on plastic parts. Two major mechanical flaws revealed themselves over time:
1. Rear Axle Spacer Degradation
I initially designed and printed pipe-like cylindrical spacers on the rear axle to keep the idler wheels aligned. Under the heavy, constant friction of the flexible tracks, these pipe spacers ground down incredibly quickly. As they disintegrated, the rear axle developed a severe slant, which completely threw off the track tension. I learned that using flat, circular pads (like thick washers or shims) distributes the friction over a much larger surface area and prevents this rapid degradation.
2. Front Sprocket Inward Camber
Extended use of the rover highlighted a major stress-distribution issue at the front drive sprockets. Over time, the front shaft that connects the JGA25-370 motor to the drive wheel slowly caused the wheels to develop an inward camber (tilting in toward the chassis). The mechanical stress of the tracks pulling on the wheels migrated upwards, concentrating torque toward the roof of the axle housing. This progressively warped the alignment and caused the tracks to bind. FDM printing tolerances for tracked drivetrains require far more reinforcement at the motor mounting points than I originally calculated.
Software Abstractions: App Lab & The RouterBridge Black Box
Mechanically, despite the wear, the rover functioned. But getting the code to play nicely with the hardware was a completely different story.
My biggest bottleneck was the software environment itself. Working with the new Arduino App Lab introduced a whole layer of troubleshooting I wasn't prepared for. I experienced constant environment quirks where the App Lab interface would clearly state "Library Added," but when I went to compile the code, the compiler would throw fatal errors stating the module could not be found. I wasted critical hours fighting the IDE over module imports, phantom libraries, and compiling errors that had absolutely nothing to do with my actual logic.
The Arduino UNO Q is the hero component of this build, featuring an incredible dual-brain architecture. It utilizes an STM32U585 microcontroller alongside a Qualcomm QRB2210 Linux SBC. To get these two brains to talk to each other, you have to use a software protocol called the Arduino_RouterBridge.
I will be completely honest: I still have absolutely no idea how this Bridge actually works under the hood.
I successfully implemented the syntax to pass UDP strings from my Python base station script to the MCU. The Bridge.provide_safe and Bridge.notify commands worked syntactically to trigger motor functions and relay telemetry. But the actual underlying mechanics of how the Qualcomm chip parses and hands off that data to the STM32 chip is a complete black box to me. As someone coming from a Python and data analytics background rather than bare-metal C++ and RTOS, operating a system where I didn't truly understand the core communication protocol made debugging terrifying. Without deeper diagnostic tooling, I felt like I was flying blind.
The Hardware Graveyard (Failure Analysis)
Beyond the software and the plastic warping, the physical hardware took a massive beating during the integration phase. Three specific components failed during this project, and troubleshooting them consumed days of bench time:
1. The INA226 Telemetry Enigma
The INA226 was supposed to be the core of my operational analytics, continuously polling voltage on the 12V rail and current draw to track power consumption. The I2C address was explicitly hardcoded to 0x40 in the firmware, requiring the A0 and A1 pads to be tied to ground. But the Arduino simply could not find it.
To ensure I wasn't dealing with a logic level or software bug, I took a multimeter, set it to Diode Mode, and ran a reverse-bias test on the SDA and SCL pins. The multimeter read a 500mV drop across both data pins to ground, which definitively proved that the internal silicon diode structures of the logic chip were physically intact and alive. I verified the 3.3V logic supply to the VCC pin, yet the I2C bus remained completely dead, and the scanner returned a total failure.
The frustrating irony of the INA226 breakout board is that the massive physical shunt resistor still worked flawlessly. It continued to pass the full 11.3V battery power to the TB6612 motor driver's VM pin, allowing the rover to drive with full physical torque. It functioned perfectly as a "dumb" power bridge, but the data lines remained totally silent. I never solved this mystery.
2. The Dead MPU6050 IMU
Tracked vehicles inherently suffer from severe heading drift and skid-steer errors. Because of this, an IMU is highly recommended to improve dead reckoning and odometry. I integrated an MPU6050 on the I2C bus at address 0x68. Without warning, the chip simply died. Losing the MPU meant losing the foundation for any future phase of reliable grid mapping. It was a harsh reminder of how fragile cheap breakout boards can be.
3. The Fried Turret Servo
The GEPARD sensory turret relies on an MG90S micro metal-gear servo to actively pan the HC-SR04 ultrasonic sensors. During active testing of the sweeping logic on the bench, the servo just gave up and burned out. Whether it was a voltage spike, a mechanical bind in the 3D printed housing, or simply a defective factory unit, it forced me to completely tear down the SPAAG turret assembly and replace the actuation plant mid-build.
Moving Forward to the Finale
This project humbled me. It taught me the brutal realities of mechanical tolerances, the frustration of black-box software APIs, and the absolute necessity of step-by-step unit testing for hardware before chassis integration.
In the next and final post, I will be wrapping up Project GEPARD V5.0. I will showcase the final physical build, review the successes of the platform, and summarize my Element14 EZ-EV Challenge experience. Thank you to everyone on the forum who has followed along—I promise I will be leveraging your expertise much earlier on the next build!
AI disclaimer: Google Gemini was used to edit the posts wording, gramma and formatting.