UAV: Extending QGroundControl (QGC): Building an Interactive Primary Flight Display (PFD)

Apr 12
5 min read

Updated: Apr 13

Open Source Ground Control Stations: The Feature Gap

Open source Ground Control Station (GCS) software has dramatically lowered the barrier to entry for UAV development. Tools like QGroundControl, Mission Planner, and APM Planner give developers and operators a capable, cross-platform starting point - without the cost of proprietary alternatives.

However, these platforms are designed for the broadest possible audience. Features standard in certified avionics - interactive flight instruments with pilot-adjustable setpoints, seamless unit conversions, or direct barometric reference inputs - are frequently absent or only partially implemented.

Fortunately, these tools are extensible - and with the right architecture, filling those gaps can be done cleanly, without abandoning upstream development.

QGroundControl as an Expansion Platform

QGroundControl (QGC) stands out among open source GCS tools not just for its feature set, but for its deliberate architecture around extensibility. The codebase is built on Qt and QML, which means the UI layer is declarative, hardware-accelerated, and straightforward to modify or extend. Custom components slot naturally alongside the existing interface.

Plugin Architecture

The core of QGC’s extensibility is its plugin system. Three primary interfaces govern how the application can be customized:

FirmwarePlugin - abstracts all firmware-specific behavior, including MAVLink message handling, parameter naming, and vehicle-specific logic.
AutoPilotPlugin - controls the vehicle setup UI, allowing teams to expose only the configuration relevant to their platform.
QGCCorePlugin - governs application-level behavior: which views are visible, how the UI is structured, and what features are accessible in standard vs. advanced mode.

To build a custom feature, a developer subclasses one or more plugin interfaces and overrides the relevant methods. There is no need to fork or patch the main QGC codebase. The result is a custom build that can be rebased against upstream QGC releases with minimal friction. It’s very easy to customize and extend QML architecture. A further challenge arises when customization requires touching core classes that were never designed to be extended. They are internal, tightly coupled, and subject to change between releases. When a feature genuinely requires extending or wrapping such a class, developers face an uncomfortable choice: fork the codebase and absorb the maintenance burden, or work around the limitation with increasingly fragile solutions.

A Practical Guide to QGC Plugin Customization

QGC's custom build system requires a dedicated “custom” folder at the root of the project. This folder acts as the override layer — any resource or component placed here takes precedence over its equivalent in the main QGC codebase, without modifying shared code directly.

Customizing a UI component follows a straightforward three-step process, illustrated here with AirspeedIndicator.qml as an example:

Add the custom file to the appropriate subfolder. Place your modified component in the matching location within the custom folder. In this case, AirspeedIndicator.qml goes into custom/Widgets/.
Register the file in custom.qrc. Open custom.qrc in a plain text editor and add the path to your new file: res/Custom/Widgets/AirspeedIndicator.qml
Full path will be:
<file alias=”src/Widgets/AirspeedIndicator.qml”>res/Custom/Widgets/AirspeedIndicator.qml</file>
Build and run. From this point, QGC will load your custom component instead of the original. No changes to the core codebase are required.

This pattern scales cleanly — the same process applies to any QML component you want to override or extend, whether it is a flight instrument, a toolbar indicator, or an entirely new view.

Process of customizing a UI component in QGC

Custom builds overview: https://docs.qgroundcontrol.com/master/en/qgc-dev-guide/custom_build/custom_build.html

Repository setup for plugin customization: https://docs.qgroundcontrol.com/master/en/qgc-dev-guide/custom_build/fork_repo.html

Toolbar customization overview: https://docs.qgroundcontrol.com/master/en/qgc-dev-guide/custom_build/toolbar.html

FlyView customization overview: https://docs.qgroundcontrol.com/master/en/qgc-dev-guide/custom_build/fly_view.html

QML and C++ Integration

QGC’s UI is written in QML, which makes it well-suited for building rich, interactive instrument displays. QML’s property binding system and its native support for animations and transformations are exactly the kind of primitives needed for real-time flight instruments. C++ backend classes expose telemetry data and vehicle state to the QML layer via Qt’s property system, keeping the separation of concerns clean.

Custom QML components can be injected into the toolbar, the fly view, or entirely new views - all through the plugin interfaces described above. Resources such as icons, colors, and fonts can also be overridden, allowing a fully branded or mission-specific appearance without touching shared code.

Generic MAVLink Support

Because QGC communicates over MAVLink, custom extensions are not tied to any specific autopilot firmware. A component built on standard MAVLink messages works equally well with PX4, ArduPilot or any other MAVLink-compliant system. This makes QGC a solid base for building GCS tools.

A New Interactive UAV Primary Flight Display

Original QGC Primary Flight Display (PFD) looks like this:

Aircraft cockpit instruments, showing an attitude indicator with blue sky and green ground, and a compass with heading 206 in red. — Original QGC Primary Flight Display (PFD)

As part of an ongoing effort to bring professional-grade avionics UX to open source UAV operations, we developed a fully interactive UAV Primary Flight Display (PFD) as a custom QGC component. The goal was not simply to improve the visual presentation of existing data, but to make the instrument itself an active control surface - one that allows the operator to communicate flight intent directly from the instrument panel.

New custom and interactive Primary Flight Display:

Flight instrument display showing altitude at 264 meters, airspeed at 15 m/s. Brown and blue horizon, QNH 1013.3 in green text. — New custom interactive PFD

Now it is time to compate Original QGC with the one extended by improved PFD:

Drone app interface showing a map of Irchelpark with a flight path. Text: "Takeoff from ground and start the current mission." — Original, community version of QGC with standard PFD

Drone navigation interface shows aerial view of fields with a red flight path spiral. Dashboard displays speed and altitude data. — QGC with upgrade PFD

The new PFD goes beyond passive data display. At its core, the instrument is interactive - operators can adjust altitude and airspeed setpoints directly from the display using sliders, or type values precisely into input fields. Commands are dispatched to the autopilot over MAVLink immediately upon confirmation.

The display is fully configurable to match operational context. Speed can be shown as Indicated Airspeed (IAS) or Groundspeed (GS), altitude as Above Mean Sea Level (AMSL) or Above Ground Level (AGL), and the barometric reference (QNH) can be updated at any time directly from the instrument. Units switch on the fly between knots and m/s, or feets and meters - applied consistently across both readouts and setpoint inputs.

Beyond the interactive controls, the PFD presents a complete situational picture: climb rate, compass heading, and current altitude and airspeed - all sourced in real time from MAVLink telemetry. Minimum and maximum allowable value of setpoints, also received via MAVLink, are displayed on the altitude or airspeed tape, giving the operator clear awareness of operational boundaries at a glance.

Aircraft cockpit display showing altitude, speed, and attitude indicators. Blue sky and brown earth are represented. Text: IAS, QNH 1013.3, AMSL. — New PFD in action

Conclusion

QGroundControl’s plugin architecture makes it a genuinely practical base for building professional-grade GCS extensions. The combination of Qt’s QML rendering pipeline and a well-structured plugin interface means that complex, interactive components like a full PFD can be developed and maintained without forking the core codebase.

The interactive PFD described here addresses a real operational gap: the need for a cockpit-style instrument that is not just a data display, but an active interface for flight intent. Setpoint control, QNH input, reference mode switching, and unit conversion are all features that experienced operators expect from a mature ground station - and they are now available within the open source QGC ecosystem.

This PFD is one of many custom avionics components we have developed as part of our UAV platform work at Apptimia. If you are facing a similar challenge or are curious about the implementation and want to leverage our capabilities and our 10 year UAV software experience, get in touch with us!

Artur M., Software Engineer at Apptimia