Entry 7 – Wrapping Up: What We Built, What We Learned, and What Comes Next

This is the final entry of the SudoFly project blog. The semester is over, and it is time to look back at what the team set out to do, how far we got, and what we would do differently.

A few months ago, the project began with a drone in a box, no iNav support for the hardware, and a simulation running a generic model that had nothing to do with the real aircraft. The goal was ambitious: build a full autonomous drone software stack from scratch, from firmware bring-up to Python-controlled autonomous flight.

At the time, that felt like a lot. Looking back, it was.

The hardware side of this project turned out to be deeper than anyone expected at the start. Building and soldering the drone was the easy part. What followed was months of firmware work on a flight controller that had zero community support.

The team wrote a custom iNav target from scratch, cross-referencing the board schematic pin by pin. They stabilized GPS, got the blackbox flash working, and dialled in PID tuning until the drone flew smoothly and reliably. Each of these sounds like a single step, but each one involved days of debugging, flashing, and iterating.

The standout achievement is the ELRS firmware port. iNav had no support for SPI-connected ELRS receivers anywhere in its codebase. The team ported the driver from Betaflight across seven steps, navigating the differences between two codebases that share a common origin but have diverged significantly over the years. The result is a working SPI ELRS driver in iNav, something that did not exist before this project. The drone can be armed and flown with a real radio transmitter under iNav, a genuine contribution not just to this project but potentially to the broader open-source FPV community.

The one open problem that remains on the hardware side is MAVLink over SPI. The plan was to run MAVLink on the same SPI bus as ELRS, but no existing firmware, not Betaflight, not iNav, not ArduPilot, has ever done this. The architectural challenges are real, and the team ran out of time before finding a working solution. It is an honest limitation, and one that would require dedicated firmware-level work to resolve.

The software team built a functioning simulation pipeline around the real LionBee model in Gazebo. Starting from a generic drone and a raw MSP connection, they worked their way up to a MAVLink-based Python interface that can read live sensor data and upload waypoint missions to iNav.

Getting MSP working was the proof of concept. Getting MAVLink working on top of it, with clean telemetry, structured sensor data, and missions that actually appear in iNav's interface, was the real work. Both are now functional.

The drift problem in simulation was never fully resolved. The drone takes off and follows mission commands, but positional accuracy in the SITL environment remains imperfect due to attitude reference mismatches between the simulation and iNav's estimator. The team spent significant time on this and reduced it, but did not eliminate it. In a real-world context, the hardware's GPS and PID tuning compensate for this in ways the simulation cannot replicate.

One thing this project made clear is how much of embedded systems work lives in the gap between "technically possible" and "actually working." The ELRS port was theoretically straightforward once the plan was laid out. The GPS took weeks to stabilize despite the hardware being correct. The drift in simulation persisted despite the logic being sound. In each case, the gap between understanding a problem and solving it on real hardware was larger than expected.

That is not a failure. It is what embedded systems development looks like, and learning to work through it systematically is probably the most transferable skill the team takes away from this semester.

With the benefit of hindsight, a few things stand out.

Starting the ELRS port earlier would have given more time to tackle the MAVLink over SPI problem, which remains unresolved. The port took several weeks and its scope was not fully clear at the start.

On the simulation side, establishing a reliable SITL baseline with verified sensor data earlier in the project would have made the drift investigation less time-consuming later. Some of the tuning effort was spent on problems that stemmed from an unstable simulation foundation rather than the mission logic itself.

And more outdoor testing, earlier. The contrast between the indoor GPS results and the outdoor results in Entry 6 was striking. Getting the drone outside sooner would have given the team a clearer picture of what the hardware was actually capable of under real conditions.

The LionBee flies autonomously. It takes off, navigates to a GPS waypoint, and lands. A Python script can upload a mission and read back live telemetry over MAVLink. The drone runs a custom iNav firmware with a receiver driver that the team wrote from scratch.

None of that existed at the start of the semester.

It was not always clean, not always smooth, and not everything on the original roadmap made it to the finish line. But the core of what this project set out to build is real and working. That is something the team can be proud of.

Thanks for following along.