← Back to all projects Pre-maiden

Believer Fixed Wing Drone

Project overview

Believer is a long-range, fixed-wing UAS developed through the QUT Aerospace Society (QUTAS) as a research and development platform for prospective beyond-visual-line-of-sight environmental-monitoring and aerial-survey applications. Potential future uses include shark spotting, threatened-ecosystem monitoring, and agricultural surveying.

I have developed the project end-to-end, from system architecture and avionics integration through to mechanical installation, PX4 configuration, ground verification, and flight-readiness planning. The aircraft is a V-tail, twin-motor platform built around a Holybro Pixhawk 6X flight controller running PX4, with long-range telemetry, ExpressLRS control, dual GNSS receivers, airspeed sensing, and onboard power monitoring.

Avionics integration and ground verification are substantially complete, with final configuration, RTK GPS commissioning, and the maiden flight remaining.

The Believer fixed-wing drone, ready to fly, with ground control laptop and transmitter
The Believer fixed-wing drone, with ground control laptop and transmitter

System architecture

Believer ICD block diagram: the Pixhawk 6X at the centre, wired to the DBR4 receiver, RFD900x telemetry radio, M8N and ZED-F9P GPS modules, MS4525DO airspeed sensor, and PWM-driven control surfaces and motors, powered through the PM03D module from a 6S LiPo battery
Believer's ICD block diagram: the full avionics architecture in one view

The Pixhawk 6X sits at the centre of the avionics architecture:

Component Role
RC link (GX12 → DBR4, ExpressLRS) Primary flight control; pilot commands and MAVLink telemetry over a single radio
Telemetry (RFD900x) Long-range, two-way MAVLink to the ground station
GPS 1 (u-blox M8N) Primary position and navigation
GPS 2 (SparkFun ZED-F9P) RTK-corrected centimetre-level positioning (antenna installation pending)
Airspeed (MS4525DO, I2C) Differential pressure measurement for autopilot airspeed control
Power (Holybro PM03D, INA228) Battery voltage and current monitoring; isolated 5V servo rail
Actuators (PWM, MAIN 1-6) V-tail, aileron, and motor commands

Power telemetry validation

Reliable battery telemetry is a flight-safety requirement. It supports pre-flight checks, remaining-endurance estimates, low-battery failsafes, and every battery-related decision.

The original power module was a Holybro PM06, which provides analogue voltage and current outputs. The Pixhawk 6X expects battery telemetry through its digital power-monitor interface, so it could not obtain a valid battery measurement from the PM06. In QGroundControl, this appeared as unavailable calibration fields, a zero cell count, a battery indication of -100%, and other values that could not be treated as trustworthy.

Rather than attempting to calibrate invalid telemetry, I replaced the PM06 with a Holybro PM03D digital power module. The PM03D communicates voltage and current data over I2C using an INA228 power-monitor IC, making it suitable for the Pixhawk 6X.

The hardware change resolved the interface mismatch but did not immediately produce complete telemetry. Initial readings from the PM03D remained incomplete or erroneous because PX4 had not enabled the INA228 driver. Enabling the SENS_EN_INA228 parameter and rebooting the flight controller allowed PX4 to initialise the correct driver and read the power module correctly.

Following this configuration change, battery voltage and current telemetry became coherent in ground testing, providing a reliable basis for battery configuration, pre-flight checks, and in-flight monitoring.

The RFD900x telemetry link worked out of the box, but “working” and “configured for the mission” are different things. The key tradeoff is between AIR_SPEED (the over-the-air bitrate) and SERIAL_SPEED (the UART rate to the flight controller): the serial side has to stay within what the air side can actually sustain, or the link bottlenecks and drops packets silently. Encryption, channel-hopping range, and transmit power are all separate tradeoffs again, each trading range, robustness, or regulatory headroom against bandwidth or security; there is no single “better” setting across all of them.

Because tuning is just plain text over a serial connection, I verified the configuration two independent ways: RFDesign’s own graphical tool, and AT commands read directly over a terminal, confirming the same settings either way.

That same serial interface, a simple text protocol over a known port, means a companion computer could eventually retune the link automatically in flight without any hardware change.

A modular, glue-free avionics bay

The avionics suite is still evolving toward a companion-computer phase, so I avoided fixing components to the airframe with adhesive: a permanent solution for what is still an iterative design. Instead, a custom 3D-printed bay mounts the flight controller, GPS modules, telemetry radio, and power module mechanically, so any module can be swapped or repositioned by reprinting the bay rather than cutting into the airframe.

The photos below trace the design from an early bench layout to the empty bay built into the fuselage, through to the current fully-populated installation:

Keeping the antennas clear of the avionics bay

The RFD900x’s own antennas presented a second mechanical problem. At 900MHz they are too long to fit inside the bay while staying properly orthogonal to each other, the spacing that gives a diversity receive link its benefit. A transmitter that close to the GPS receivers also risked interference. A custom external mount solves both problems at once.

Configuration control as a safety practice

Believer’s documentation lives in its own private GitHub repo: the project outline, interface control document, flight manual, spending history, datasheets, and the PX4 parameter change log, treated as the project’s operating record rather than an afterthought. I maintain it with AI assistance, working from a context folder of standing directives read at the start of every session, so conventions and accumulated facts carry across sessions rather than living in one chat history.

Believer's context folder: standing directives, project notes, and a running change log, plus a supporting-document archive
Believer's context folder: standing directives, project notes, and a running change log

Those directives tell the AI to mark anything unconfirmed as TBD rather than guess, and to flag a judgement call rather than quietly making one, the same discipline behind catching the power-module and RC-channel issues above rather than discovering them in flight. Done this way, the documentation process improves traceability rather than trading it for speed, which matters on a project whose records people will rely on to fly the aircraft safely.

Next phase

Fit the RTK GPS antenna, run a final pre-flight configuration and tuning pass with a build log, then the maiden flight. After that: flight controller tuning and expanded flight testing per the original project roadmap. Further out, and not yet started: a companion computer and camera payload for onboard object detection, the long-term purpose the platform is being built toward.