As understood from its motto “Versatile, Trusted, Open”, ArduPilot aims to be an ideal autopilot software platform. It presents the quality of being versatile, by supporting all kinds of vehicles and numerous sensors, components, and communication systems. It provides several features such as variable levels of automation, and simulations. ArduPilot is further described as “trusted” based on being reliable thanks to extensive use and testing (over 1 million installs), as well as being transparent, secure, and privacy-compliant. This is enabled by its third major point: open source.
As an open source project started by professionals, the software is openly accessible and has a large and strong community that continuously improves it to stay on the cutting edge. It aims to serve the industry, academia, and hobbyists alike, as it already does with users such as NASA and Boeing 1.
We present below an overview of the overall system’ vision, which would serve as an introduction to anyone planning on diving deeper into ArduPilot and its capabilities.
The end-user mental model
In general terms, users view ArduPilot as an autopilot entity that is expected to function essentially like a regular pilot, who manages flight objectives and parameters with respect to given instructions. It is expected to take care of tasks such as stabilization, navigation, sensor reading, regular communication, or any other supported tasks presented to end-users through the interface.
ArduPilot does not have a default graphical user interface. It is viewed via user interfaces of different supported programs called “ground stations” which may lead to slightly different mental models. The most popular ground station application is Mission Planner. The program provides a graphical user interface where users can use point-and-click controls for interactions such as vehicle configuration, tracking vehicles on maps, waypoint planning, and interfacing with simulations. A snapshot of the Mission Planner interface is given below, where waypoints are set for a circular flight2.
Any supported ground station program on a user’s computer interacts with ArduPilot on a vehicle via serial messages, with an open source protocol called MAVLink. Similarly, ArduPilot can interface via MAVLink with applications made using the DroneKit framework 3.
The current and future context
The autopilot software is used in different kinds of vehicles. Besides drones and rovers, ArduPilot is also used by autonomous planes and helicopters, as well as underwater vehicles such as submarines and boats.
Drones used to map out certain areas leverage the software to fly a predetermined route, without needing human interactions. Combined with IR or multispectral cameras, drones can provide information in order to help improve the yield from crops or monitor the current state of forests. ArduPilot can also be used in an agricultural setting to automate the route for a tractor, and for automatic harvesting, and saving the farmers’ money on wages. Another case relates to inspecting dangerous areas, where drones are used instead of humans, to observe the area of interest in a safe manner. Moreover, crowded areas can be monitored by drones to look out for threatening situations, etc.
ArduPilot is also a leading platform for small or big autonomous underwater vehicles, ROVs (remotely operated vehicles) and AUVs (autonomous underwater vehicles), made possible by ArduSub. The latter is used for inspections, research and adventuring. These vehicles equipped with sensors help researchers solve ocean-related problems such as the impact of chemical spills or help capture invasive species that are posing a major threat to the overall health of marine ecosystems 4.
ArduPilot’s characteristics and features
The system scope and requirements of ArduPilot relate to the main responsibilities, that is, the critical capabilities that it will be required to provide and what it is supposed to do. ArduPilot can be leveraged for developing a large system of robotic vehicles able to perform a multitude of tasks. ArduPilot pioneers in the field of Linux based autopilot hardware, rapidly lowering the barrier for working on drones and encouraging innovation the field of Unmanned Vehicles (UV).
- Copter is a flexible and customizable advanced open source system providing multicopters and helicopters with various flight modes, and offering these vehicles both manual and autonomous capabilities 5.
- The Plane firmware provides full autonomous capabilities for any fixed-wing aircraft including vertical take-off and landing (VTOL) fixed-wing aircraft that hover and cruise in different configurations 6.
- Rover is an open source autopilot for guiding ground vehicles and boats. It can run fully autonomous missions that are defined using mission planning software or pre-recorded by the driver during a manual run 7.
- ArduSub is a fully fledged UV solution for guiding underwater vehicles (ROVs) and autonomous underwater vehicles (AUVs) 8.
- The antenna tracker tracks a vehicle’s location in order to properly align a directional antenna 9.
The figure below presents the key capabilities and requirements provided by each ArduPilot vehicle type best represented by the firmware components.
Following the book “Lean Architecture: For Agile Software Development” by Gertrud Bjørnvig and Jim Coplien 10, we identified five major stakeholders area to be further discussed below. These roles represent those of a lean organization focusing on the value pipeline rather than individuality.
- End users are the people that are actually using the software suite, which is supposed to be up to their expectations in terms of functionalities, and thus meet their technical needs. Systems can cater to a multitude of end users, therefore providing different value streams. The identified end users for ArduPilot are:
- The hobbyists: individuals interested in UVs, experimenting with the different kinds of vehicles and systems provided by ArduPilot as part of a personal project or initiative
- Commercial users: The software suite is installed in aircraft from many OEM UAV companies,such as 3DR, jDrones, PrecisionHawk, AgEagle and Kespry
- Academics: Several large institutions use ArduPilot either for projects, experimenting with UVs, etc.
- Enterprises: NASA, Intel and Insitu/Boeing using ArduPilot for testing purposes
- The business plays a role in the provision of the software and its functionalities to the user, ensuring some sort of Return On Investment. Investing in ArduPilot gives them the possibility to get a seat on the board and to participate in the decision making process for new functionalities and design decisions. We highlight below some of the companies investing into ArduPilot 11. A more comprehensive list can be found on the website.
- EAMS lab
- Customers treat the software as a commodity that passes through their systems. They are the ones performing the purchasing transactions. Since ArduPilot is an open source project where there is no actual “customer”. However, business partners listed above may also be considered as customers since they get a seat at the “ArduPilot Advisory Board” from which they can influence how funds are spent, and can therefore request new features based on their needs as Customers - features which they will incorporate in their end products.
- Domain experts hold a special architectural role in the development of the system in question. They have integrated the perspectives of multiple end user communities and companies and other stakeholders into the forms that underlie the best systems. The main roles are firmware leads (plane, copter, rover, etc.), Bug master, IT and HW lead, etc. 12.
|Andrew Tridgell||Plane Lead|
|Francisco Ferreira||Bug Master|
|Jani Hirvinen||IT \& HW Lead|
|Jacob Walser||Submarine Maintainer|
|Lucas De Marchi||HAL Linux maintainerx|
|Michael du Breuil||GPS Maintainer|
|Michael Oborne||MissionPlanner Lead|
|Peter Barker||DataFlash \& Tools Maintainer|
|Randy Mackay||Copter \& Rover Lead|
|Tom Pittenger||Plane Co-Lead|
|Bill Geyer||Traditional Heli Co-Maintainer|
|Chris Olson||Traditional Heli Co-Maintainer|
|Leonard Hall||Copter Control \& Navigation Maintainer|
|Matt Lawrence||Solo Maintainer|
|Paul Riseborough||EKF Maintainer|
|Pierre Kancir||Copter \& Rover SITL Maintainer|
|Craig Elder||Founders of the ArduPilot Initiative|
|David Bussenschutt||ArduPilot software developer|
|Grant Morphett||Rover Co-Lead|
|Philip Rowse||HW Lead|
- Developers are responsible for the construction of the system. The software suite is also used for testing and development by several large institutions and corporations such as NASA, Intel and Insitu/Boeing, as well as countless colleges and universities around the world. The top 6 developers are identified from the main contributors page on GitHub based on their contributions to the master (excluding merge commits) from Sep 4, 2011 – Mar 1, 2020 13
- Andrew Tridgell (“@tridge”)
- AerialRobotics Australia Pty Ltd
- Randy Mackay (“@rmackay9”)- Japan Drones
- Peter Barker (“@peterbarker”)
- Lucas De Marchi (“@lucasdemarchi)- Intel
- @WickedShell (name not provided)
- Paul Riseborough (“@priseborough”)- GNC Solutions Pty Ltd
Roadmap and future work
Regarding the future, former technical community manager for Dronecode (who leads software teams in ArduPilot) Craig Elders says the following about the roadmap for ArduPilot in 2016:
“Some people would say we have no road map, and that is a good thing because we are not limiting it to our own imaginations. We are allowing people to do something new and something creative with it.” 14
Each year, a new roadmap is developed by the ArduPilot team. This roadmap is not meant to guarantee when features will be added, but instead offers people a means to collaborate with others that share similar interests. The roadmap for 2020 will be made during the ArduPilot Developer Conference from March 27th to 29th this year. New functionalities for vehicles are added every year, as well as additional support for more hardware and OS 15.
The roadmap for 2019/2020 is illustrated below, with the main architectural changes and additions to be made to ArduPilot. The different streams are ran in parallel with different developers acting as point of contact.