Open Source Drone Technology: Understanding PX4, MAVLink, and MAVLink-M
Behind every autonomous aircraft is a collection of systems working together. An autopilot controls flight. A ground station lets the operator plan and monitor a mission. Communications links carry information between them. Payloads and onboard computers add capabilities specific to the job.
Open source drone technology helps developers build these systems on shared foundations. Open standards help the components communicate.
Understanding the difference—and how projects such as PX4 and MAVLink fit together—explains why Applied Aeronautics builds with these technologies and contributes to their development.
What Does “Open Source” Mean for a Drone?
Open-source software makes its source code available under a license that allows people to use, examine, modify, and share it under defined terms.
For an aircraft developer, that means being able to understand how the software works and adapt it to a particular aircraft or application. For a research team, it can provide a starting point for developing and testing new capabilities.
An open standard serves a related purpose: it defines a shared way for systems to interact. If two manufacturers implement the same communication standard, their products have a common foundation for exchanging information.
A drone can use open-source flight software without its entire airframe, electronics, or payload design being open source. Similarly, using an open communication standard does not mean every component will work together automatically. Compatibility still depends on what each device supports and how the complete system is integrated.
What Is PX4?
PX4 is open-source autopilot software. It runs on a flight controller—the onboard computer responsible for controlling the aircraft.
An autopilot takes information from sensors, estimates the aircraft’s movement and position, and commands motors or control surfaces to achieve the requested flight behavior. PX4 supports aircraft types including fixed-wing platforms, multirotors, and vertical takeoff and landing aircraft. Explore the PX4 project.
The distinction between hardware and software matters: the flight controller is the physical computer; PX4 is software running on it.
Applied Aeronautics uses PX4 in the Albatross UAV. It provides a flight-control foundation that our team incorporates into the aircraft through configuration, integration, and testing. The platform’s open architecture also supports adapting communications, ground-control configurations, and payloads to customer requirements. Explore the Albatross.
What Is MAVLink?
MAVLink is a messaging protocol: a defined format that compatible systems use to exchange information.
Where PX4 handles flight control, MAVLink helps systems communicate. Messages can carry aircraft status, position, commands, and other information. MAVLink also defines interactions for tasks such as transferring missions and changing parameters. Read the MAVLink overview.
Consider an operator uploading a flight plan:
The operator creates a mission in compatible ground-control software.
The ground station transfers the mission using MAVLink messages.
The autopilot processes the mission and controls the aircraft.
Status messages return to the ground station so the operator can monitor progress.
MAVLink defines how those messages are structured. The radio or network connection provides the path they travel over.
This separation gives developers a common messaging framework they can use across different hardware and software implementations.
How the Parts Fit Together
Each part of the system has a distinct role:
ComponentIts role | |
Flight controller | The physical computer running the autopilot |
PX4 | Software that controls the aircraft |
Ground-control software | The operator’s interface for planning and monitoring |
MAVLink | A shared format for exchanging messages |
Communications link | The connection carrying those messages |
Payload or companion computer | Equipment providing mission-specific functions |
These distinctions are useful when evaluating a drone. “Supports MAVLink” describes communication capability. It does not, by itself, describe flight performance, payload compatibility, or the completeness of an integration.
The practical questions are which functions are supported, which components have been integrated, and what has been tested together.
Why Open Standards Matter
Imagine a team wants to introduce a new sensor or connect an aircraft to its own software.
With documented, shared interfaces, its engineers can start from an established communication framework. They can identify the messages and functions already available and determine what additional development is required.
That can reduce repeated engineering work and make it easier to reuse an integration across compatible systems. It also gives customers more options when selecting equipment or planning future upgrades.
Open standards do not remove physical constraints. A payload still needs suitable mounting, power, weight capacity, and data connections. Software behavior must also be checked. A common language is an important starting point; a working aircraft requires the complete system to be engineered and validated.
What Does MAVLink-M Add?
MAVLink-M, short for MAVLink-Military, is a MAVLink 2 dialect developed for military applications. A dialect is a defined set of messages that extends the protocol for particular needs.
Its focus includes communication between command systems, aircraft, and payloads. The broader objective is to make equipment from different suppliers easier to integrate through a shared specification.
Applied Aeronautics participated in the Dronecode and Auterion MAVLink-M integration hackathon, where companies worked on implementations and demonstrations using real hardware. These events help developers learn whether a specification can be implemented consistently across different systems—and where further work is needed. Read Dronecode’s event recap.
Participation in this work is an investment in interoperability. It should not be confused with a claim that every aircraft and payload already supports the same capabilities.
How Aircraft Manufacturers Contribute to Open Source
Writing code is one way to contribute. Flight testing, reporting problems, and validating changes are also essential.
Software developers need evidence of how their work behaves on aircraft. Manufacturers and operators can provide that practical perspective, helping connect development decisions with performance in the field.
Applied Aeronautics’ contributions to PX4 include issue reporting, testing, and field validation for fixed-wing aircraft development, work recognized by the Dronecode Foundation. Read Dronecode’s announcement.
This creates a useful feedback cycle: shared software supports aircraft development, aircraft testing produces practical findings, and those findings inform continued software development.
Why Applied Aeronautics Stays Involved
The technologies behind an aircraft need sustained maintenance, collaboration, and support. Our involvement reflects the importance of that work to the systems we build and the customers who operate them.
Applied Aeronautics supports the Dronecode Foundation as a Silver Member, and CEO Ryan Johnston serves as a Silver Director on its board. These commitments complement our technical participation by supporting the community and its continued development. View Dronecode’s board.
For us, open source is both an engineering foundation and an ongoing responsibility. We use technology developed through shared effort, apply it to customer aircraft, and contribute experience back to the people improving it.
For customers, the value is a more understandable and adaptable foundation: software that can be examined, interfaces that can be built upon, and an ecosystem that supports continued development as mission requirements change.
Comments