CONVOY

Inspiration

Modern warfare has fundamentally changed the calculus of logistics. The most dangerous job in a combat zone isn't pulling a trigger — it's driving a supply convoy down a predictable route. The US Army's Autonomous Mobility Appliqué System (AMAS) and DARPA's RACER program exist precisely because of this: every unmanned vehicle in a convoy is a soldier who doesn't get shot.We were inspired by a simple question: what is the minimum viable hardware required to demonstrate autonomous convoy following in a GPS-denied, communications-degraded environment? Not a simulation. Not a lab demo. A real system, built in 24 hours, that physically drives. The answer turned out to be two RC cars, a camera, and a lot of debugging.

What it does

CONVOY is a two-vehicle autonomous leader-follower system designed for GPS-denied environments. A leader vehicle navigates autonomously using radar-sweep obstacle avoidance. A follower vehicle tracks the leader using computer vision and mirrors its behavior — with zero human input after initialization. The system operates entirely offline. No GPS. No cloud. No internet connection required at runtime. All computation happens on the edge, on hardware that fits in your hand.

How we built it

Challenges we ran into

The Arduino UNO Q is brand new and barely documented. Released in October 2025, the board combines a Qualcomm Linux SBC with an STM32 microcontroller. Standard Arduino libraries — Servo.h, SoftwareSerial.h — don't exist on it. We had to rewrite servo control as raw microsecond pulses via digitalWrite, replace SoftwareSerial with hardware Serial1, and learn the RouterBridge API from a single blink example. Every step of the toolchain was new territory.The SSL certificate clock issue. The board's system clock defaulted to September 2025, causing TLS certificate verification to fail when downloading libraries. The fix was forcing an NTP sync via sudo ntpdate pool.ntp.org — not something you'd find in any tutorial.Two motors instead of four. We split the ELEGOO kit across two cars, leaving each with 2WD. The passive wheel design required careful mechanical consideration — a ball caster on the follower for free rotation, a printed fixed axle on the leader. Differential steering with only two driven wheels meant our turning radius was larger than expected, requiring tuning of turn duration constants.WiFi architecture with one ESP32-CAM. Our original design called for an ESP32-CAM on each car. With only one available, we pivoted: the UNO Q's built-in Qualcomm WiFi handles the leader-side broadcast, while the ESP32-CAM on the follower acts as the Access Point. This actually simplified the architecture — fewer components, cleaner signal flow.Real-time vs. high-level compute separation. The UNO Q's dual-processor architecture forced us to think carefully about what runs where. Navigation decisions belong on the STM32 where latency is microseconds, not on the Linux side where Python loop timing is 50ms. Getting that separation right was the key insight that made the motor control actually responsive.