One rooted in flight dynamics and tuning, the other in a fundamental architectural gap that nobody in the open-source community seems to have solved yet.
Software Team – The Drift Problem
Mission planning is progressing, but a persistent and frustrating issue has been consuming the last two weeks: the drone takes off correctly, but gradually drifts during flight, and by the time the landing command arrives it is no longer where it is supposed to be.
What "drifting" means in practice:
After takeoff, the drone should hold its position and orientation while awaiting the next mission command. Instead, it slowly rotates or translates in an unpredictable direction — sometimes subtly, sometimes enough to make a clean landing impossible. The drift accumulates over time, meaning longer missions make the problem worse.
The suspected cause — yaw, pitch, and roll calibration:
The team's working hypothesis is that the issue originates in the fundamental attitude settings. In a simulation environment, the default PID values and attitude zero-points may not be tuned for the specific model being used. If the drone's simulated "level" does not perfectly match what iNav considers level — even by a small margin — that discrepancy compounds over time and manifests as drift. Yaw in particular is notorious for this: without a magnetometer or absolute heading reference actively correcting it, any small offset accumulates continuously.
Two weeks of combinations:
The team has spent two weeks methodically working through different configurations — adjusting yaw, pitch, and roll parameters, testing different PID combinations, and experimenting with how iNav's attitude estimator is configured in the SITL environment. Progress has been slow. The simulation is sensitive enough that small changes have unpredictable effects, and there is no single obvious knob to turn. The drift is reduced in some configurations but not eliminated.
This remains the open problem on the software side. The team is not stuck — but it is one of those issues where the path forward requires patience and systematic iteration rather than a single clever fix.
Hardware Team – GPS Stable, Blackbox Working, and a New Frontier
While the software team battles drift, the hardware team had a more mixed week — two clean victories and one problem that is turning out to be genuinely hard.
GPS Fully Stabilized:
After weeks of intermittent initialization issues, the GPS module is now working reliably under iNav. The fix came down to correctly configuring the UART timing and baud rate in the target definition — once the parameters matched what the M10Q module expects, it began initializing consistently on every boot. This is a critical milestone: GPS is the backbone of any autonomous navigation, and having it reliable is a prerequisite for real outdoor flight tests.
Blackbox Flash Recognized:
The onboard SPI flash memory used for blackbox logging — which iNav was failing to detect in earlier builds — is now correctly recognized. This means flight data can be recorded directly to the board during flights, which will be invaluable for debugging real-world flight behaviour later on. Both the GPS and blackbox fixes together mean the LionBee's hardware is now fully operational under iNav — all sensors accounted for, all storage working.
MAVLink over SPI — An Unsolved Problem
This is where things get genuinely difficult. The plan was to run MAVLink communication over the same SPI bus that the ELRS receiver uses — avoiding the need for a separate UART and keeping the hardware setup clean. In theory, SPI supports multiple devices on the same bus through chip select lines, so it should be possible to share it between ELRS and MAVLink.
In practice, nobody seems to have done this. The team researched extensively and found that MAVLink — across Betaflight, iNav, ArduPilot, and every other open-source flight controller firmware — is implemented exclusively over UART. It is a serial protocol, and every existing implementation assumes a dedicated UART connection to a ground station or companion computer. There is no known implementation of MAVLink running over a shared SPI bus alongside an active receiver driver.
This is not just a matter of configuration. The problem is architectural: the ELRS SPI driver runs a timing-critical interrupt-driven communication loop with the SX1280. Sharing that bus with MAVLink — which has different timing requirements and a completely different communication pattern — risks corrupting both. The chip select lines can separate the devices electrically, but the software scheduling of two unrelated SPI drivers on the same bus is a problem that requires careful design, and no existing codebase offers a reference implementation to learn from.
The team is now evaluating what the realistic options are. Running MAVLink over a UART remains the cleanest solution architecturally — but as established in earlier entries, the available UARTs are constrained. The alternative may be a deeper firmware-level solution: designing a SPI bus scheduler that can safely interleave ELRS and MAVLink traffic without interference. That would be novel work, and it carries real risk of instability on timing-sensitive flight control hardware.
Two wins, two open problems — one of which may require writing code that simply does not exist yet anywhere in the open-source ecosystem. That is both the most challenging and the most interesting place to be in a project like this.