Entry 3 – A Real Drone in Simulation & A Hard Decision on the Receiver

This week brought a meaningful step forward on the simulation side and a difficult but necessary conversation on the hardware side. The team is now flying a model that actually represents the real drone — and the ELRS receiver problem has been analyzed thoroughly enough to make a clear decision on how to proceed.

Up until now, the simulation was running with a generic drone model. This week, the software team replaced it with a model of the actual LionBee, built to match the real drone's physical properties — weight, motor thrust, dimensions, and visual appearance.

This matters more than it might seem. A simulation that uses a generic model gives you unrealistic flight dynamics. By matching the real drone's mass and thrust characteristics, the simulation becomes a much more faithful testing environment — meaning that flight behaviours and control scripts validated in Gazebo will translate much more reliably to the real hardware later on.

Landing via MSP Now Working:
The inconsistent landing behaviour from last week has been resolved. The drone now takes off and lands reliably via the Python script over MSP. This closes out the MSP chapter in a clean state — the team has proven that full programmatic control of the simulated drone (arm, takeoff, land) is achievable through a Python interface.

→ Moving on to MAVLink:
With MSP working as a proof of concept, the team is now shifting focus entirely to MAVLink. MSP was always a stepping stone — it confirmed the approach is sound, but MAVLink is the protocol that will power the actual autonomous system. It supports richer telemetry, proper mission commands, and integrates with standard ground control software. This transition is the software team's central focus going forward.

The hardware team sat down with the project owners this week for a focused discussion on one topic: what to do about the ELRS receiver. After a thorough analysis of the available ports, the conclusion was clear — and the team had to choose between two realistic paths.

The Problem, Restated:
The LionBee's SX1280-based ELRS receiver is connected to the flight controller via SPI. iNav has no support for SPI-connected ELRS receivers — it only recognizes ELRS via UART using the CRSF protocol. And with no free UART available (UART5 is already used by GPS), a simple external receiver is not a practical option either.

That leaves two paths:

Betaflight already supports the SX1280 over SPI. The idea would be to take that existing driver code and port it into iNav's codebase — essentially teaching iNav to talk to the onboard chip the same way Betaflight does.

Concretely, this involves four main steps:

1. Add a new receiver type in rx.h — iNav currently has no RX_TYPE_SPI in its receiver enum. This needs to be added.
2. Port the SPI abstraction layer — Betaflight has drivers/rx/rx_spi.c and rx_sx1280.c which handle low-level SPI communication with the chip. iNav has no equivalent, so these files need to be ported and adapted to iNav's hardware abstraction API.
3. Integrate into rxInit() — A new case in iNav's receiver initialization function needs to call the new SPI driver when the target is configured to use it.
4. Adapt the build system — The LionBee's target definition needs a new define that tells the compiler to include the SPI ELRS driver and specifies which pins the SPI bus uses.

The main difficulty is that Betaflight and iNav, while sharing common ancestry, have diverged significantly in their hardware abstraction layers. Timer APIs, DMA buffer declarations, and configuration macros all differ between the two codebases — so the porting work is not a simple copy-paste but a careful translation. It is technically the cleanest solution, but it is also a substantial engineering effort with real risk of getting stuck on timing-critical hardware bugs that are hard to debug remotely.

The alternative is to connect a small external CRSF/ELRS receiver to the board via a UART. This is a well-understood, low-risk solution — but it requires physically soldering to the board, and it goes against the original intent of using the integrated hardware that is already there.

After discussing the tradeoffs with the project owners, the team has decided to pursue Option A — the firmware porting. The integrated SX1280 is there for a reason, and the goal of the project is to build a full software stack around the existing hardware. A working SPI ELRS driver in iNav would also be a genuine contribution back to the open-source community, since this support currently does not exist anywhere in iNav's codebase.

It will not be easy — but the team goes in with a clear picture of exactly what needs to be done.