The Mission

I’ve designed a project to build an autonomous, GPS-denied drone — one with the same capabilities as the drones doing high-stakes work today: dropping suppressant on wildfires, reaching drowning swimmers minutes before any lifeguard could, or mapping lost cities under Central American jungle canopies with LiDAR, gathering in an afternoon what would take survey teams on foot years. This project is largely inspired by those use cases. For more than a decade I’ve watched drones become vital infrastructure for the world, and I’ve decided to stop being a spectator and engage in this new wave of innovation.

I should mention: I have no prior experience in this realm. I’ll be learning everything from scratch, armed with only my own curiosity.

Why GPS-Denied, and Why Drones?

Drones have seen increasing use across land, sea, and air — but in each of these domains they face unreliable conditions where communication with satellites can drop out and localized systems need to take over. Whether it’s smoke, rough waves, or dense jungle canopy, the systems that guide drones have to handle complex situations at a moment’s notice. Hence this project: a GPS-denied drone that can pilot itself through mission-critical situations.

What excites me most is the quick feedback watching the thing navigate a real environment in real time. The result of the work isn’t a number on a dashboard; it’s a physical device moving through physical space, succeeding or failing right in front of you.

The High-Level Plan

The plan is to break this into phases that build up to the final product: the drone. I’ve identified four milestones.

  1. ESP32 sensor pipeline — custom sensor nodes streaming into ROS2 via micro-ROS over WiFi. Establishes the embedded-to-middleware foundation everything else consumes.
  2. Rover autonomy stack — SLAM, Nav2, and sensor fusion (robot_localization) for GPS-denied ground navigation, built on the pipeline’s data.
  3. Failure injection in simulation — deliberately breaking the stack (sensor dropout, drift, latency) in sim to find where the autonomy degrades and harden it.
  4. GPS-denied autonomous drone — the capstone: PX4 with a companion computer running VIO-based autonomy, applying everything above in the air.

Rules and Guidelines

There are a few architectural rules I’m holding myself to on this project, along with documentation guidelines.

  1. Everything runs on real hardware, not just simulation. Simulation has its place here (see milestone 3), but nothing counts as done until it works in the physical world — real sensors, real noise, real results.

  2. One repo, one PlatformIO project. Sprawling repositories make sense for large teams; for a one-man project they’re overkill. All firmware lives in a single PlatformIO project, and each system stays self-contained in one repo. No repo-per-feature fragmentation.

  3. Every failure gets documented, not just fixed. The most important rule. Failures are part of the curriculum — how you respond to them matters more than avoiding them. Wins and losses both get recorded, for my benefit (and your entertainment).

  4. No copying reference implementations without understanding them. Robotics is full of working example configs you can paste in and move on. If I can’t explain why a line exists, it doesn’t go in the repo. Learning is the journey, and we’re not skipping ahead to the destination.

How to Follow Along

I’ll be documenting all of this in two places: here on the Loops & Logs blog, and on YouTube. The hope is to share the experience closely, entertain a few of you, and maybe save someone else a headache in their own build.