Details
Drone programs must combine responsive interfaces, mission maps, real-time telemetry, video, connectivity, and fleet management while meeting demanding performance, security, maintainability, and certification requirements.
In this webinar, Qt Group explains how a cross-platform software foundation can reduce duplicated development and hardware dependency across a program’s lifecycle. The team examines the Qt modules behind QGroundControl, demonstrates a proof of concept for faster runtime customization, and presents Argus—a C4ISR technology demonstrator that shares a live common operating picture across command centers, tablets, and embedded systems.
A drone program’s software architecture influences more than its operator interface. It affects delivery schedules, hardware choices, supplier dependency, certification effort, security maintenance, and the cost of supporting a fleet over time.
Qt’s cross-platform approach allows teams to reuse a common codebase across desktop, mobile, embedded Linux, real-time operating systems, and some microcontroller environments.
Drone applications repeatedly need the same capabilities:
Responsive operator interfaces
Two-dimensional and three-dimensional mission maps
Live video and telemetry
Vehicle communication
Multi-vehicle fleet views
Offline operation
Qt provides libraries for graphics, multimedia, positioning, mapping, networking, serial communication, Bluetooth, MQTT, and data storage. These components reduce the amount of infrastructure teams must build themselves.
Airborne software, ground systems, and development tools can fall under different assurance standards. The session discusses DO-178C for airborne software, DO-278A for relevant ground-based systems, and DO-330 for tool qualification.
Qt Framework itself is not presented as DO-178C certified. Instead, Qt Group offers quality-assurance tools—including Axivion, Coco, and Squish—that can support static analysis, code coverage, UI verification, and the evidence-generation process.
QGroundControl is built extensively with Qt and provides a practical starting point for PX4- and ArduPilot-based systems.
A full fork can appear inexpensive initially, but upstream synchronization, security updates, branding, interface changes, custom protocols, and dependency management can create considerable long-term work.
QGroundControl supports application, firmware, and autopilot plug-ins. Using these defined extension points helps teams keep proprietary changes separate from the upstream codebase.
The webinar also demonstrates a proof of concept that loads selected QML files, assets, themes, map styles, and MAVLink definitions from a runtime folder. This allows teams to test some interface changes by relaunching the application instead of rebuilding the entire project.
The proof of concept can accelerate interface design, branding, map styling, panel creation, and protocol experimentation. It does not replace development work involving C++ logic, firmware extensions, mission-control behavior, or new communications architecture.
The presenters also emphasize that writable runtime configuration should not remain exposed in a production release. Approved resources should be incorporated into the secured release build.
The Argus demonstrator shows a common operating picture shared across command-center systems, ruggedized tablets, augmented-reality views, and embedded devices.
Qt states that the demonstrator uses shared QML application logic, synchronized through Qt MQTT, while supporting tactical overlays, terrain, satellite imagery, entity tracking, drone video, encrypted communications, and AI-assisted mission planning. Argus is a demonstrator rather than a finished product. Qt Group
Cross-platform reuse reduces program risk
Practical implication: Design application logic and interfaces for reuse across operator stations, tablets, and embedded targets instead of maintaining a separate implementation for every device.
Performance needs architectural separation
Practical implication: Keep intensive processing in C++ worker threads while using GPU-accelerated Qt Quick and Qt Quick 3D for visualization.
QGroundControl customization should minimize divergence
Practical implication: Use documented plug-in and extension mechanisms before modifying upstream source code directly.
Designers need realistic data without the entire application
Practical implication: Provide mock telemetry and defined data models so designers and AI coding tools can create panels without loading or understanding the complete QGroundControl codebase.
Licensing must be evaluated across the complete dependency tree
Practical implication: Review QGroundControl, Qt, GStreamer, codecs, hardware decoders, and other dependencies separately. A commercial Qt license does not automatically resolve every third-party licensing requirement.
Certification is program-specific
Practical implication: Determine whether the target is airborne software, a ground system, or a qualified development tool before assigning a certification standard.
Development demonstrations are not production architectures
Practical implication: Treat runtime customization and Argus as architectural examples requiring security review, integration, validation, and certification work before operational deployment.
Q: Why is Qt used in drone ground-control software?
A: Qt combines GPU-accelerated interfaces with mapping, positioning, multimedia, networking, serial communication, Bluetooth, MQTT, and cross-platform deployment. This aligns with the principal requirements of ground-control applications.
Q: Is QGroundControl built with Qt?
A: Yes. Qt is used throughout QGroundControl for its QML interfaces, maps, positioning, multimedia, network connections, and local map-tile storage.
Q: Can QGroundControl be customized without maintaining a large fork?
A: Teams can use QGroundControl’s application, firmware, and autopilot plug-ins to reduce direct changes to upstream code. The webinar also demonstrates an experimental runtime-customization approach for selected QML files, assets, themes, maps, and MAVLink definitions.
Q: Does the runtime approach eliminate rebuilds?
A: It eliminates rebuilds for some interface and configuration changes during development. Changes to C++ behavior, firmware support, mission logic, or communications architecture still require code changes and a rebuild.
Q: Is the runtime-customization capability a Qt product?
A: No. The presenters describe it as a proof of concept intended to demonstrate possible extension approaches. It is not a certified product.
Q: Is Qt Framework DO-178C certified?
A: No. The webinar states that Qt Framework itself is not DO-178C certified. Qt Group instead provides quality-assurance tools and qualification resources that can support applicable certification workflows.
Q: Which standards were discussed?
A: The session discusses DO-178C for airborne software, DO-278A for certain ground-based aviation systems, and DO-330 for tool qualification.
Q: Do proprietary QGroundControl applications need to open-source their changes?
A: That depends on the selected licensing path and the application’s complete dependency structure. The presenters explain that GPLv3 obligations apply under the GPL path, while proprietary development requires an appropriate commercial strategy. Teams should obtain licensing guidance for their specific implementation.
Q: Does a commercial Qt license cover every QGroundControl dependency?
A: No. Third-party libraries, codecs, GStreamer plug-ins, and hardware decoders may carry separate open-source or commercial licensing requirements.
Q: What is Argus?
A: Argus is a Qt-based C4ISR technology demonstrator developed with Siili Auto. It illustrates how common application logic can support a synchronized operating picture across multiple device classes. Qt Group
Ben Minichino: Hello, everyone, and welcome to today’s webinar. I’m Ben Minichino, Global Business Development Director for Aerospace and Defense at Qt Group. I’ll be guiding today’s conversation with my colleagues.
Before we begin, today’s session is being recorded. We’ll share the on-demand recording with everyone registered for the webinar. If you have questions, please submit them through the Q&A panel. We’ll address as many as possible during the Q&A portion.
We’ll also launch a couple of polls during the webinar, so please keep an eye out and cast your votes.
Drone software must bring many capabilities together. Operators need responsive interfaces, accurate mission maps, live video and telemetry, and reliable connectivity. Engineering teams must provide all of that while managing demanding performance, maintainability, and certification requirements.
The software foundation behind those systems therefore has an impact far beyond the interface. It can influence development effort, program timelines, supplier dependencies, and how effectively the platform evolves throughout its lifecycle.
Today, we’ll examine those considerations through the lens of Qt and explore how the technology can support everything from ground-control stations to advanced C4ISR systems.
We’ll also examine QGroundControl, a widely used ground-control station built largely with Qt. We’ll explore how teams can customize and extend existing technology without assuming unnecessary engineering and maintenance work.
With that, I’ll ask the rest of the Qt team to introduce themselves. Amit?
Amit Nainawat: Hello. My name is Amit Nainawat. I’m Director of Solutions Engineering at Qt Group, based in our Paris office.
Deepak Somasekharan: Hello. My name is Deepak Somasekharan. I’m a Senior Solutions Engineer at Qt Group, helping customers build their next generation of products with Qt.
Ben Minichino: Thank you. Let’s begin with an overview of how Qt fits into the drone sector.
Qt Group is a global software company trusted by industry leaders and more than 1.5 million developers worldwide. Our customers span more than 70 industries and over 180 countries.
Qt Group includes Qt Development, Software Quality Solutions, and IAR embedded-development capabilities. You may know Qt as the cross-platform C++ framework for desktop, embedded, and portable devices.
It is used extensively for graphical software layers across industries, including highly regulated sectors such as automotive, medical devices, aerospace, and defense. Qt is not only a graphical user interface. It provides a broad set of libraries.
Qt Group has expanded its portfolio to provide an end-to-end offering for multiple stages of software development: design, conversion of designs into code, application development, quality assurance, and compilers for safety-critical applications.
Our products also provide offline installers for use in air-gapped environments and networks.
Qt is an open technology with decades of production history in regulated sectors. Teams can inspect the source code rather than relying on an unknown black box. This gives organizations greater control over their software stack.
Qt is cross-platform, allowing software to move among supported targets with comparatively few changes. It can deliver a consistent experience across desktop, mobile, embedded systems, real-time operating systems, and microcontrollers.
This flexibility reduces dependence on a single hardware supplier, which can become important during a chip shortage or supplier negotiation.
Qt relies on public and established security standards. Our software ships with a software bill of materials so that customers can understand what they are using.
With Qt, teams can maintain one codebase across platforms, avoid duplicated work, and reduce dependency on individual hardware suppliers.
Qt provides real-time performance at scale. Applications can render drone swarms and telemetry efficiently, use advanced two-dimensional and three-dimensional graphics, and handle live video streams for precision landings without introducing unnecessary interface latency.
The architecture extends from high-level QML to low-level graphics. Teams can prototype quickly and optimize the rendering pipeline when performance is critical.
Three-dimensional visualization and mapping can represent airspace, terrain, mission paths, and vehicle positions.
Concise and traceable code can help teams map implementation decisions to system requirements and streamline certification activities in regulated environments.
Qt also supports rapid iteration from prototype to validated feature through live previews and shorter rebuild cycles.
Built-in connectivity supports MAVLink, serial communications, network communications, telemetry, and encrypted ground-to-air data.
Qt for MOSA brings Qt’s graphics, controls, and development capabilities into a common operating environment established under the FACE Technical Standard.
Current aviation regulations distinguish among operational categories and risk levels. In the United States, FAA Part 107 generally covers small uncrewed aircraft under 55 pounds, while heavier or higher-risk operations can require additional exemptions or airworthiness certification.
Programs must generate evidence as they develop. Relevant standards may include DO-178C—or ED-12C in Europe—for airborne software, DO-278A for applicable ground systems, and DO-330 for tool qualification. Modified condition/decision coverage is required at Design Assurance Level A.
Qt Group provides DO-330 tool-qualification kits for Axivion, Coco, and Squish.
At this point, I’ll hand it over to Amit.
Amit Nainawat: Ben discussed program risk, development capability, and certification. I’ll focus primarily on development capability.
Let’s examine what engineers build, the challenges they encounter, and why so many drone programs arrive at similar requirements.
Whether the application supports farming, logistics, or defense, teams frequently build the same four capabilities.
First is the operator interface: flight displays, instruments, alerts, and controls. These elements must work together under stress, whether they appear on a control-room monitor or a tablet in the field. The operator interface must prioritize clarity and responsiveness.
Second is mission planning: waypoints, survey patterns, geofences, relay points, and two-dimensional or three-dimensional maps. This is where the operator determines what the drone will do.
Third is live video and telemetry. A camera feed with overlays appears beside high-rate telemetry and health data. Video recording, map rendering, and telemetry processing compete for the same processor and screen.
Fourth is the fleet view. Teams may need to control several drones simultaneously while seeing status, tasking, and a shared view of the operation.
These are graphically intensive, data-heavy applications that must run on more than one type of device. That creates the real-time interface challenge.
We repeatedly hear six challenges from drone programs. I’ll explain each challenge and what Qt Framework provides to help address it.
The first challenge is real-time performance. Video, telemetry, and map layers update simultaneously, and the interface cannot slow down.
Qt Quick renders on the GPU. Qt Quick 3D handles terrain and drone models. Intensive work can remain in the C++ backend on worker threads, while Qt Multimedia manages video.
The second challenge is geolocation and mapping. Qt Positioning and Qt Location provide coordinates, geometry, maps, and overlays—the building blocks for mission planning. Teams do not have to create a mapping engine from the beginning.
The third challenge is connectivity. Qt Network supports UDP and TCP, while Qt Serial Port, Qt Bluetooth, and Qt MQTT provide additional communications options.
The fourth challenge is supporting multiple platforms. Qt allows teams to use a common codebase across Windows, macOS, Linux, Android, embedded Linux, real-time operating systems, and certain microcontrollers.
The fifth challenge is the length of program lifecycles. Commercial Qt releases provide long-term support options suitable for programs expected to operate for years.
The sixth challenge is security and supplier dependency. Qt Group is a CVE Numbering Authority, publishes security advisories, and provides access to source code.
The next fair question is: Who is using it?
This brings us to QGroundControl. Many teams do not begin with a blank page. They fork QGroundControl, which is built natively with Qt, to save years of development. Teams working in the PX4 or ArduPilot ecosystems may also be using Qt indirectly.
Drones depend on dense MAVLink streams. Qt can bridge low-level C++ data into the user interface while avoiding unnecessary memory and latency overhead.
Heavy-duty payloads—three-dimensional airspace, offline maps, and high-definition video—need direct access to graphics hardware. Qt’s rendering stack can work directly with Vulkan, OpenGL, and other native graphics APIs.
However, QGroundControl introduces several practical concerns.
It has a large codebase. Even when a program needs only part of its functionality, the team may still have to build and understand the complete source tree.
The customization interface can also be difficult. Interface screens live deep in the source tree. Custom build overlays can help, but each source-code change may still require a rebuild, creating a slow iteration loop for designers.
Upstream synchronization is another concern. QGroundControl continues to change, so every proprietary fork must keep pace with QGroundControl and Qt releases.
There are also workflow tools that teams frequently have to create themselves, including designer workflows, mock data, interface workspaces, and configuration utilities.
QGroundControl is an excellent starting point, but it is not a finished product for every program. We asked how teams could keep its strengths without assuming the full maintenance cost of a large fork.
Deepak will explain the work we explored.
Deepak Somasekharan: QGroundControl is one of the most widely used cross-platform ground-control stations for PX4- and ArduPilot-based uncrewed aerial vehicles.
Many teams begin exploring, prototyping, or building products with QGroundControl. It therefore makes sense to understand what it contains and what it takes to customize it—for example, adding a sensor-visualization panel or applying proprietary branding.
We also explored how to enable faster development iterations without rebuilding the code every time. I’ll refer to QGroundControl as QGC.
Qt is integral to QGC. It is not merely an interface placed on top of another application.
Qt QML draws the screens. Qt Location and Qt Positioning drive the maps. Qt Multimedia handles audio and video streams. Qt Network carries vehicle connections, and Qt SQL stores the map-tile cache.
QGC is dual-licensed under Apache 2.0 and GPLv3. Customers unable to meet the GPL requirements because of proprietary or closed-source constraints can evaluate the applicable QGC licensing path alongside a commercial Qt license.
At a high level, QGC has four layers.
The QML user interface sits at the top. Beneath it, C++ handles vehicle data, mission-planning logic, and video-stream management.
Below that is a firmware-abstraction layer supporting firmware such as PX4, ArduPilot, and generic MAVLink-based vehicles.
At the bottom, the protocol and communications layer establishes TCP, UDP, and serial connections.
QGC offers several customization options. It follows a plug-in architecture.
Teams can extend the QGC core plug-in for application-level features such as branding, themes, and settings.
Custom flight modes can be implemented by extending the firmware plug-in. An autopilot plug-in provides the user interface for configuring the vehicle.
One common approach is to fork the project and adapt it. That can be inexpensive on the first day but becomes progressively more costly.
Synchronizing upstream bug fixes and security updates—and potentially meeting applicable Cyber Resilience Act obligations—can become difficult when a fork contains many changes and conflicts.
QGC also supports compile-time extensions. Teams can subclass the firmware, autopilot, or QGC plug-ins to alter behavior without directly modifying upstream code.
New behavior such as changing the core vehicle model or adding a communication protocol still requires C++ changes and a rebuild. Nevertheless, keeping these changes in extensions makes it easier to incorporate upstream updates.
We wanted to determine whether we could enable faster iterations for themes, icons, QML panels, and two-dimensional map layers by relaunching the application rather than rebuilding it.
For this proof of concept, we added a URL interceptor that can replace selected compiled assets, resources, and interface files with versions stored in a predefined runtime folder.
For example, if a team customizes the Fly View interface in
FlyView.qmland places it in the runtime folder, that file overrides the compiled version when QGC launches.The same approach can add interface panels embedded within the main window or displayed as separate windows showing vehicle data and trends.
We also added a mechanism to parse a MAVLink dialect defined in XML. Teams can define custom MAVLink messages that QGC understands after relaunch.
Values from those messages are exposed to QML through the core plug-in and can be used for visualization.
We wanted designers to create panels and windows around the data they care about without understanding the internals of QGC.
For that purpose, we used Qt Design Studio. MAVLink messages exposed to QGC become simulated mock-data items, providing a richer designer experience without requiring access to the QGC source tree.
In AI-assisted development, this mock-data approach can also give a language model the focused context needed to generate a panel instead of loading the entire project into its context window.
Under the hood, the URL interceptor checks for a matching resource or QML file in the configured runtime folder. If the file exists, the application loads it. Otherwise, it loads the compiled resource.
The MAVLink dialect XML is parsed at startup. QGC learns the new message, accepts and decodes it like a built-in MAVLink message, and exposes the decoded values to QML through the core plug-in.
We also created a separate configurator application using PySide6 and Qt QML.
The configurator does not change the QGC source. Instead, each tab writes configuration files into the predefined runtime folder.
These settings can include the application name, logo, theme, supported MAVLink messages, two-dimensional map styles, and military symbols.
The first result demonstrates the interceptor. The product name and logo come from the configurator, and the supplied logo replaces the compiled asset.
We also replaced the login interface with an updated QML file. In the three-dimensional viewer, another QML replacement renders military symbols and engagement-zone volumes.
The second result demonstrates runtime MAVLink adaptation.
A team can define a new MAVLink message with custom fields and generate a Qt Design Studio project from that message. Designers can build a panel using animated mock data.
When the panel is complete, its QML file can be placed in the runtime folder. After QGC restarts, it understands the custom MAVLink message and displays live values in the panel.
These interfaces can appear as embedded panels or floating windows that operators move to another screen. No rebuild is needed during that portion of the iteration loop.
The third result involves map styling and offline availability.
Maputnik, an open-source map-style editor, is embedded in the configurator. It allows teams to restyle two-dimensional maps and save the configuration as JSON.
For three-dimensional maps, a user can select a region and radius, then download buildings and optional elevation data for offline operation.
When QGC starts, it opens the two-dimensional and three-dimensional maps with the new styles.
There are important limitations to this runtime approach.
It currently requires a relaunch rather than providing hot reload, although a file watcher could potentially enable that behavior.
It covers QML and assets, not core C++ logic. New firmware behavior, mission-control logic, or other core functionality still requires C++ changes and a rebuild.
Once developers approve the changes, the resources and QML files should be incorporated into the release build. Leaving a writable runtime configuration folder exposed in production could create a security risk.
This is a proof of concept for faster development iterations. It is not a Qt Group product or certified software. Its purpose is to demonstrate how flexible Qt Framework can be.
Now let’s examine what else can be done with Qt.
Ben Minichino: QGroundControl is where many teams begin. I’m now going to show the latest demonstrator built by Qt with our partner Siili Auto.
Argus shows how far Qt Framework can extend. It is a C4ISR technology demonstrator and a working prototype of a complete software stack for multi-domain mission planning.
The objective is to provide a live common operating picture across command centers, ruggedized tablets, augmented-reality field views, and low-power embedded devices.
Everyone sees the same information, whether they are in a control room or in the field. One codebase serves each of those device classes.
The demonstrator runs on a PC and an Android tablet, and it can be embedded into a platform.
It presents two-dimensional tactical overlays, three-dimensional terrain with satellite imagery, live drone video, and real-time entity tracking.
Its symbology follows NATO and other applicable military standards, allowing operators to work with conventions they already understand.
Operators can pan the map and open drone feeds while each information layer remains live.
Traditional C4ISR programs may maintain a separate codebase for each device, multiplying research-and-development costs and integration risk.
Argus instead uses the same QML application logic across targets. Teams can build and test common logic, then deploy it to the relevant supported devices.
The devices remain synchronized through Qt MQTT with less than 50 milliseconds of latency on a local network.
The architecture is also designed to maintain a coherent operating picture when communications are interrupted. Commands, telemetry, and drone video travel through encrypted channels.
AI can support threat analysis and generate mission plans, drone routes, team deployments, transport corridors, and avoidance zones.
Argus is a demonstrator, not a product. It shows how far a common framework can extend—from a command center to a low-powered embedded station.
For those already using QGroundControl, remember that proprietary applications require careful licensing review. Without an appropriate proprietary licensing path, GPLv3 requirements may apply to the software and source code.
Thank you to everyone who joined us. Please watch your inbox for the on-demand recording.
I’ll now hand the session to Deepak for questions.
Q&A
Deepak Somasekharan: Thank you for listening. Let’s begin with the questions.
Is the runtime-customization proof of concept open source, and where can teams obtain the code?
The runtime-customization work is currently a proof of concept developed by Qt Group to explore QGroundControl’s extension possibilities.
We want our research and development team to evaluate whether and how it could be shared. We are also discussing possible approaches with the Dronecode Foundation.
In the meantime, teams interested in the runtime-customization approach can contact us. We can demonstrate what we tried and discuss the team’s specific pain points.
How can teams try Argus?
Argus is a C4ISR software-stack demonstrator developed with an open-ended architecture. It can be extended around specific requirements.
It was created in partnership with Siili Auto. Teams can contact us to discuss requirements such as additional military symbols or fleet-management capabilities. We can then discuss how the demonstrator could be extended and how source access would work.
Do teams using QGroundControl have to open-source their changes?
QGC provides different licensing paths. Under the GPL path, the corresponding GPL obligations apply, including requirements concerning the distribution of source-code changes.
Organizations that need to keep application logic or military intellectual property proprietary should evaluate the Apache 2.0 components, commercial Qt licensing, and the licensing of every other dependency with qualified counsel.
Does a commercial Qt license cover everything in QGroundControl?
Not necessarily.
QGC links to other components, including GStreamer. Hardware-accelerated H.264 or H.265 decoding may require additional plug-ins or hardware decoders.
Those dependencies can use GPL, LGPL, commercial, or other licensing models. Teams must identify which features and libraries their implementation uses and evaluate each applicable license.
Some paid hardware decoders may need to be purchased separately from Qt.
Is Qt Framework DO-178C certified?
No. Qt Framework is an open framework used across several industries and is not itself presented as DO-178C certified.
Qt Group supports certification activities through quality-assurance tools such as Axivion, Coco, and Squish. These tools support activities such as static code analysis, code coverage, and interface verification and can have qualification materials for applicable domains under standards such as DO-330.
It is also important to distinguish airborne software from a ground-control station. A ground-control application may not require DO-178C because it is not airborne software.
Teams should work with their relevant authority to determine whether DO-278A or another assurance framework applies to their particular program.
Is the EU Cyber Resilience Act relevant?
Its relevance depends on the product and market.
Certain defense applications may fall outside its scope, while commercial drone applications used in areas such as agriculture or fleet management may be affected.
Organizations should evaluate the specific product, market, and applicable exclusions rather than assuming that every drone application is treated the same way.
Thank you.
Presenters:
Ben Minichino
Business Development Director, Aerospace and Defense, Qt Group
Amit Nainawat
Director, Solutions Engineering, Qt Group
Deepak Somasekharan
Senior Solutions Engineer, Qt Group
Join Now for More Content & Events
For event and sponsorship inquiries, please email: [email protected]
