Entry 2 — Controlling the Simulation & Untangling the Hardware

The main goal this week was to get the drone in the Gazebo simulation to actually respond to commands from a Python script — not just observe iNav running, but actively control it.

Takeoff & Landing via Python over MSP:
Using MSP (MultiWii Serial Protocol), the team wrote a Python script that can command the simulated drone to take off and land. Getting takeoff working was relatively smooth. Landing, however, was less consistent — it worked sometimes but not reliably, pointing to timing or state synchronization issues that still need to be ironed out.

Sensor Data Not Transmitting Correctly:
One of the bigger challenges this week was sensor data. While the basic control loop was functional, the sensor readings were not being transmitted properly through the simulation, meaning the drone was flying somewhat blind. Attitude, position, and other telemetry values were not reliably making it through the MSP bridge — something that will need to be resolved before the simulation can be trusted for more complex manoeuvres.

Looking ahead to MAVLink:
While the MSP-based approach proved the concept works, it was always meant to be a stepping stone. The team's real target is to get the same control working over MAVLink — a richer and more standardized protocol that would open the door to proper ground control software integration and more sophisticated autonomous commands. That transition is the next major challenge on the software side.

The hardware team's focus this week was on two fronts: stabilizing the GPS and figuring out whether there is any viable path to getting the onboard ELRS receiver working with iNav.

Refining the iNav Target – GPS Stability:
Although GPS was partially working after last week's custom target build, it remained inconsistent — sometimes initializing correctly, sometimes not. The team went back into the target configuration files to review the pin assignments more carefully, cross-referencing the board schematic to make sure the UART and signal definitions are correct. Getting GPS to initialize reliably every time is critical for any meaningful autonomous flight, so this remains a priority.

ELRS Receiver – Investigating the Ports:
The other major task was a deep dive into the board's port layout to explore whether the integrated SX1280-based ELRS receiver can somehow be brought to life under iNav. As established last week, iNav does not support SPI-connected ELRS receivers — it only recognizes ELRS via UART using the CRSF protocol.

The team carefully mapped out all available ports on the board to understand what options actually exist. The problem remains the same: UART5 — the only free UART — is already claimed by GPS. There is no clean way to run both GPS and an external ELRS receiver simultaneously without a hardware compromise.

This port analysis was nonetheless valuable, as it gives the team a clear and documented picture of the hardware constraints. The conclusion is that a software-based workaround — either via MSP scripting or MAVLink — remains the most realistic path forward for receiver-less control.

Progress is real, but so are the challenges. The gap between "it kind of works" and "it works reliably" is turning out to be where most of the effort lives — which is probably true of most embedded systems projects. More updates in the next entry.