Robotics / UAV2025 - 2026Active - competition delivery

Autonomous Drone Platform - IESL RoboGames

A real-hardware UAV platform plus a simulator-in-a-container, so students can develop autonomy like it's a sandbox.

ArduPilot
MAVLink
Pixhawk
Raspberry Pi
Docker
Webots
SITL

For the IESL RoboGames competition I led the build of the autonomous UAV platform that contestants program against. The goal was unusual: give school and university teams the feel of a clean software sandbox, while the code actually runs on a real Pixhawk-based drone.

That meant building two things that had to agree with each other - the physical aircraft, and a reproducible simulation environment that behaves closely enough that code written against the sim runs on the real airframe with minimal surprises.

Highlights

Pixhawk autopilot running ArduPilot, paired with a Raspberry Pi companion computer for onboard scripting and vision.
A single Docker image bundling Webots + ArduPilot SITL, so every contestant gets an identical simulation environment.
Hardware abstraction layer so the same contestant script targets sim and real hardware.
Containerised sandbox environments (Docker + Linux services) that isolate each team's code.

Why simulation-first

Competition hardware is scarce and fragile. If forty teams each need hours of flight time to iterate, the drones never survive the week. The fix is to make the simulator the primary development target and the real drone the final validation step.

Webots gives the physics and sensor models; ArduPilot SITL gives the exact flight-control firmware behaviour. Running both inside one container means a contestant's laptop, a lab machine, and the judging rig all execute byte-identical environments.

The companion-computer stack

The Raspberry Pi talks to the flight controller over MAVLink, handling the higher-level autonomy: mission scripting, camera capture, and the abstraction layer that lets contestant code stay unaware of whether it's flying pixels or propellers.

Keeping the time-critical control loop on the Pixhawk and the heavy/higher-latency work on the Pi is the standard split - it keeps the vehicle safe even when the companion code misbehaves.

Reproducibility as a feature

The whole point of shipping a container was determinism: 'works on my machine' is fatal in a competition. One image, versioned, is the contract between the organisers and every team.