Believer Fixed Wing Drone
Project overview
Believer is a long-range, fixed-wing UAV built through the QUT Aerospace Society (QUTAS) for beyond-visual-line-of-sight (BVLOS) observation: shark spotting, monitoring threatened ecosystems, and agricultural surveying. As UAS Systems Lead and Program Manager, I lead the avionics integration and flight-readiness work, a V-tail, twin-motor airframe built around a Holybro Pixhawk 6X flight controller running PX4.
The aircraft is pre-maiden: avionics integration is largely complete and a redundant RC control link, the near-term goal in the original project proposal, is done. What’s not yet true: it hasn’t flown, RTK-precision GPS isn’t online yet (antenna not fitted), and the onboard object-detection payload that’s central to the project’s long-term purpose is a future phase, not built or installed. None of that is operational today.
System architecture
The Pixhawk 6X sits at the centre of every link below. Each exists for a specific reason, not just “because the airframe has one”:
| Link | Carries | Why it exists |
|---|---|---|
| RC link (GX12 → DBR4, ExpressLRS) | Pilot stick/switch commands, plus MAVLink | Primary flight control, shares one radio with telemetry instead of needing a second |
| Telemetry (RFD900x) | Two-way MAVLink to the ground station | Long-range command and monitoring, BVLOS by design |
| GPS 1 (u-blox M8N) | Primary position fix | Navigation today |
| GPS 2 (SparkFun ZED-F9P) | RTK-corrected position fix | Future centimetre-level positioning, not yet online, antenna not fitted |
| Airspeed (MS4525DO, I2C) | Differential pressure → airspeed estimate | Feeds the autopilot’s airspeed control |
| Power (Holybro PM03D, INA228) | Battery voltage/current, isolated 5V servo rail | Battery monitoring and a servo supply independent of the flight controller’s own rail |
| Actuators (PWM, MAIN 1-6) | Control surface and motor commands | V-tail, ailerons, and twin motors |
Current status
Completed: avionics integration (flight controller, dual GPS routing, airspeed, power monitoring, actuator mapping), a redundant RC control link, and most of the maiden-flight build checklist (airframe, avionics mounting, pitot and magnetometer installation, antenna placement, a parachute bay repair).
Verified: the RC channel remap (below), the power module swap against real ground-test telemetry, and the RFD900 link configuration via two independent methods.
Unresolved: the RTK GPS module still needs its antenna fitted, the airframe still needs paint, and a final pre-flight configuration and tuning pass (with a build log) is still to be run.
Next milestone: fit the RTK antenna and complete that final configuration pass, then the maiden flight.
Selected engineering challenges and decisions
RC link reliability. ExpressLRS Hybrid mode only carries the first 12 RC channels, but the flight-mode selector switch was originally wired to channel 13, so PX4 never saw it move, a silent failure on one of the aircraft’s core safety controls. The fix was a full remap: arm and kill onto channels that are actually transmitted, the flight-mode selector onto channel 6, and a separate channel repurposed as a direct override into Hold, a fast backup path into a safe holding pattern independent of whatever mode the main selector is in. This mattered because arm, kill, and flight-mode are exactly the controls a pilot needs to trust completely; the remap is documented and verified in the parameter log.
Power telemetry validation. An earlier power module reported battery telemetry in a format the Pixhawk couldn’t parse correctly, surfacing as a battery setup that couldn’t be calibrated, a -100% charge reading, and a status panel reporting “Charge State: Ok” beside a blank voltage field. Battery monitoring underpins every other go/no-go call in flight, so trusting illogical readings wasn’t an option. The fix was a Holybro PM03D power module (INA228-based), sourced partly out of pocket once the gap was identified, now confirmed reporting clean voltage and current.
RF link tuning. The RFD900x telemetry link worked out of the box, but getting the highest practical bitrate meant tuning AIR_SPEED (over-the-air rate) against SERIAL_SPEED (the UART rate to the flight controller), since the serial side has to stay within what the air side can actually sustain or the link bottlenecks. Encryption, channel-hopping range, and transmit power are separate tradeoffs again, each trading range, robustness, or regulatory headroom for bandwidth or security, not a single “better” setting. Because tuning is just plain text over a serial connection (RFDesign’s own GUI tool, or AT commands directly), the same interface could eventually let a companion computer retune the link automatically in flight.
Mechanical integration: a modular, glue-free avionics bay and antenna mount. The avionics suite is still evolving toward the companion-computer phase, so I avoided gluing components to the airframe, a permanent fix for what’s still an iterative design. Instead, a custom 3D-printed bay mounts the flight controller, GPS modules, telemetry radio, and power module mechanically, so a module can be swapped or repositioned by reprinting the bay rather than cutting into the airframe.
The RFD900x’s own antennas drove a second mounting decision: at 900MHz they’re too long to fit inside the bay while staying properly orthogonal to each other (the spacing that gives a diversity link its benefit), and a transmitter that close to the GPS receivers risked interference. A custom external mount solves both at once.
Verification or evidence
The power module decision above was driven by real, captured symptoms, not a hunch:
The RF link tuning above was verified two independent ways, RFDesign’s own configuration tool and AT commands read directly over a serial terminal, confirming the same settings either way:
And an early ground test confirmed the integrated system could acquire GPS position in QGroundControl, well before anything was flight-ready:
What I learned or am proud of
The most useful habit on this project wasn’t any single fix, it was treating a small inconsistency as a reason to investigate rather than a reason to move on: a battery percentage that didn’t add up, or a switch that silently stopped registering, each turned out to be a real issue worth catching before flight test rather than during it.
The other piece I’m proud of is configuration control. 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 actual operating record rather than an afterthought. I maintain it with AI assistance, working from a context folder of standing directives that gets read at the start of every session, so conventions and accumulated facts carry across sessions rather than living in one chat history.
Those same directives tell the AI to mark anything unconfirmed as TBD rather than guess, and to flag a judgement call rather than quietly make one, the same discipline behind catching the power-module and RC-channel issues above rather than discovering them later. Used this way, the documentation process improves traceability rather than trading it for speed, which matters more on a project whose records people will eventually 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, but a future phase, not current capability.
Gallery
