Entry 1 — First Milestones: Firmware Bring-Up & Simulation Link

Now that the team is set up and the project goals are defined, it's time for the first real development update. This week, both the hardware and software teams hit the ground running. With some solid wins, but also some tricky obstacles that will keep us busy in the coming days.

The software team's main focus this week was establishing a communication link between iNav and the Gazebo simulation environment — a foundational step, since everything else in Phase 1 depends on being able to test the flight stack safely in simulation before any real-world flights.

MSP Connection Established: The team successfully set up a working MSP (MultiWii Serial Protocol) connection between iNav and Gazebo. This means the flight controller firmware can now exchange data with the simulation, which is the essential first step toward a fully functional SITL pipeline.

Ongoing Challenges: Two important issues remain open. First, not all onboard sensors are being correctly recognized within the simulation environment yet, which limits how realistic simulated flights can be. Second, and more importantly, the team's ultimate goal is to move beyond MSP and use MAVLink instead. MAVLink is a more widely supported protocol that enables richer telemetry and easier integration with ground control software. Bridging iNav's MSP-based architecture to MAVLink is technically non-trivial, and will be a central focus going forward.

The hardware team made substantial progress this week on the firmware bring-up side of things.

Drone Assembled & Verified with Betaflight: The drone is now fully assembled and successfully connects to Betaflight (the stock firmware). All onboard sensors are recognized and functional, which confirms the hardware itself is in good shape before attempting the switch to iNav.

Custom iNav Target Created from Scratch: This was the week's biggest hardware achievement. The LionBee's AT32F435-based flight controller had no existing iNav support whatsoever — meaning the team had to create it themselves. This involved writing a custom target.h configuration file and a dedicated hardware target folder, both required by iNav's build system to understand the board's peripherals and pin assignments.
To get this right, the team studied the configurations of similar supported boards and carefully cross-referenced the LionBee's own schematic: identifying UART assignments, SPI buses, sensor connections, and other hardware dependencies pin by pin. The result: a custom iNav target that compiles successfully and can be flashed onto the board. For a flight controller with zero prior community support, this is no small feat.

GPS Not Yet Functional: Despite the GPS module working fine under Betaflight, it is not yet correctly initialized under iNav. Further investigation into the target's pin mapping is needed.

Blackbox Flash Not Recognized: The onboard SPI flash used for blackbox logging isn't being detected by iNav either — likely requiring additional configuration in the target definition.

ELRS Receiver — A Structural Problem: Perhaps the most significant challenge is the lack of iNav support for the onboard SX1280-based ELRS receiver. The SX1280 is integrated directly onto the flight controller and communicates via SPI — a configuration that iNav simply does not support. iNav only recognizes ELRS receivers connected via UART using the CRSF protocol. The obvious workaround would be to connect an external CRSF/ELRS receiver via UART — but the only available UART (UART5) is already needed for GPS. Using it for the receiver would mean losing GPS, which is not acceptable.
Two alternatives are being explored:

• MSP scripting: Sending RC control inputs programmatically via MSP, bypassing the need for a physical receiver entirely.
• MAVLink integration: A more powerful approach that aligns well with the software team's goals — but also significantly more complex to implement.