Drones: they’re just racers and glorified picture takers with closed software, right? Wrong. The open source software community in ArduPilot is pushing drone innovation to new heights.

Just as Linux was revolutionary to the computer space, this open source project is just as revolutionary to the drone space. In this article, I will be introducing you to the open source software projects that are propelling (sorry) today’s drones.

If you’re interested in this material, checkout my complete course on drone programming and the ArduPilot flight stack.

While this post focuses on ArduPilot, the content is valuable in understanding the structure of any open source stack of drone software. I also have a list of the top open source drone projects if you’re looking for ArduPilot alternatives.

arduPilot-flight-stack

Software Structure of an Open Source Flight Stack

There are three main layers in the typical open source flight stack:

  1. Firmware layer. This is the low level interface to controlling the drones hardware. Activities in this layer are numerous, but a couple examples are auto-leveling the drone 400 times a second or automatic obstacle avoidance. This layer is written primarily in C/C++.
  2. Middleware layer. This is essentially the protocol that standardizes communication between your drone/vehicle and anything wanting to communicate with it. This layer is programming language agnostic, and both layers 1 and 3 incorporate the communication protocol into their code to allow for bi-directional communication.
  3. Interface/Software layer. This is a high level layer that can be used to communicate with the drone or command certain behavior. Examples could be receiving updates from the drone on its current battery voltage levels or commanding it to land. This layer can materialize into advanced GUIs or even simple command line programs.

The Firmware

ardupilot-logo

The two predominant open source flight control projects today are:

  1. ArduPilot. This operates under the GPL license, meaning if a product is shipped with the ArduPilot code on it, the forked changes must be submitted back to the mainline ArduPilot branch for the benefit of all. You can see the code on ArduPilot’s github page here. This project also has excellent documentation dedicated for devs, and if interested I highly encourage you check it out here.
  2. PX4. This uses the BSD license, so any changes you make with your fork can forever be kept in secret, making it more attractive to businesses trying to protect their competitive advantage.

Both projects use MAVLink as its Middleware.

ArduPilot was the trailblazer for open source flight control software, and was started around 2008. It now has around 1 million lines of code, and can actually be used on 7 different vehicle types.

It also pioneered the first Linux based flight controllers, spearheaded by Andrew Tridgell. An exciting event happened when Matternet, arguably the largest drone delivery company, flew one of its ArduPilot empowered drones to deliver a cup of coffee to the roof of a Mercedes-Benz.

Intro To ArduPilot

PX4 is the featured flight control project of DroneCode. DroneCode is associated with the Linux Foundation, and essentially offers a complete drone system solution for all three layers of the open source flight stack, among other things.

If we were to look at a Venn diagram to compare and contrast the features of the two projects, the circles would majorly overlap, but substantial differences in features can be seen at the edges for particular scenarios.

For example, if you had a particular piece of LIDAR hardware in mind that you wanted to use on a drone, it may be supported in ArduPilot but not PX4, and vice versa.

That being said, this post focuses mainly on the ArduPilot flight stack.

The Middleware

mavlink-logo

The main middleware project being used in the open source community is MAVLink. It offers two main standards:

  1. Packet Structure. MAVLink packets always have a 6 byte header representing 6 different packet fields, followed by the data and checksum. This standard protocol means MAVLink-nodes receiving the packet can parse the data in a concrete manner, and MAVLink-nodes sending the packet can also package the data according the the standard protocol. This is what makes the MAVLink project programming language agnostic.
  2. Standard Messages. MAVLink defines a standard set of messages and enums that are used by any MAVLink empowered drone/vehicle. You can see the standard messages and enums here. For example, message ID 76 command 21 is the command to land the vehicle. As mentioned previously, both ArduPilot and PX4 are MAVLink enabled, so both a PX4 and ArduPilot enabled drone would respond to receiving message ID 76 command 21 by landing. Keep in mind that MAVLink is just the standard, not the code that is directly commanding the drone’s hardware to land. That is handled independently in the PX4 and ArduPilot codebases.

Intro to MAVLink

Interface/Software Layer

There are many different flavors of projects that exist in this layer for open source drone systems, but they all basically perform the same function, which is to send and receive MAVLink messages to and from the drone. Often this layer is referred to as a ground control station.

The ground control station connects to the vehicle either through radio communication (telemetry) or TCP/UDP. Once connected this layer lets us treat our PX4 and ArduPilot vehicles as APIs that we can send high level requests to, without needing to worry about the meticulous underlying details in the flight control codebases. We can do things like command the drone to fly 10m into the sky, or move to a particular waypoint.

These are three examples of flavors for this interface layer

1. Command Line. MAVProxy is THE command line ground control station. It is written in python and can be installed with the pip package handler. You can find the documentation here.

2. GUI. This is a popular flavor of project for our interface to our drone. Mission Planner and QGRoundControl are popular choices for Windows and Linux, respectively.

They visually update the location of the drone on the GUI map once connected, and provide you with constant visuals for important drone attributes like battery voltage, GPS health, and many other things.

3. Python Script. The only project here is DroneKit, and can be installed with the pip package handler as well. It essentially allows you to model your connected drone as an OOP object in python.

In DroneKit, you can command the vehicle with velocity commands, tell the drone to move to a particular waypoint and many other functions, all from within a script. This will be the realm for drone application developers.

Examples of such drone applications could be sophisticated high level package delivery systems, or computer vision based tracking that sends the drone velocity commands based on the object being tracked. The possibilities here are really endless. You can checkout their documentation here.

Intro to Python Dronekit

Conclusion on Open Source Drones

The merging of drone technology with open source projects makes a coder’s skill-set easily portable to the exciting drone industry. While we may only see drones currently as picture takers, future applications will see agricultural crop sprayers, precision fire-fighting for skyscrapers, package and food delivery and many other society changing applications.

These will all require programmers to make these applications come to fruition, so it is a perfect time to get on the bandwagon and start learning how to code drones!

Next Steps: Build a Drone that uses ArduPilot?

Build a Drone Education Course

If you want to get involved in the ArduPilot community, building your own drone is definitely a part of the curriculum. Check out my guide on how to build a drone that uses the ArduPilot flight stack if you are curious!

The guide provides all the information you need to build your own drone from scratch.