ArduPilot is an open source autopilot software consisting of a collection of well-established autopilot software for several vehicle types from drones to submarines, with over 1 million installs in vehicles. The community ranges from hobbyists to large institutions and groups such as NASA, Boeing, and Intel. It also features data-logging, analysis and simulation tools.
The ArduPilot software suite is made up of:
ArduCopter: Multicopter UAV controller that can transform a range of helicopters and multirorot aircrafts into autonomous flying vehicles. It provides different flight modes from manual to automatic ones.
ArduPlane: provides “fixed wing aircrafts” with full autonomous capabilities.
ArduRover: software used for guiding ground vehicles and boats and provides acces to fully autonomous systems and capabilities leveraged by a mission planning software or pre-recorded events.
ArduSub: software used for remotely operated underwater vehicles (ROVs) and autonomous underwater vehicles (AUVs) providing: depth and heading hold, autonomous navigation, etc.
Antenna Tracker: firmware which calculates the position of a remote vehicle using its own GPS position and GPS telemetry from a vehicle running Copter, Rover or Plane. It then uses this information to aim a directional antenna at the vehicle.
Each software runs on a wide range of embedded hardware consisting of a microprocessor connected to some sort of peripheral sensors used for navigation. Some case studies relate to:
- Aerial Mapping with drones
- VTOL Search & Rescue
- Agricultural automatic robot tractors
- Underwater exploration for coral reefs, oil pipe inspections
More information can be found in our posts (below) or on the official website: https://www.ardupilot.org/
- Levent Gungen is an MSc Embedded Systems student with an Electrical Engineering background, but a leniency towards software as well as writing.
- Phu Nguyen is an MSc Embedded Systems student with an Electrical Engineering background at TU Delft and is interested in smaller devices and IoT.
- Serge Saaybi is an MSc Embedded Systems student with a Computer and Communications Engineering background and two years of technology consulting experience prior to the master.
- Arthur Breurkes is a MSc Computer Science student with a Computer Science background at TU Delft, and is interested in data science.
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.
Having introduced ArduPilot as a whole in our first post, in this second one we look into its components. For ArduPilot, having a sound architecture is important because the software needs to manage various sensors and actuators while operating all kinds of drones like helicopters, planes, rovers, or even submarines. As exemplified by the popular “4+1 View” model of software architecture as well as various academic sources , there are many ways to view the architecture, each with a different focus. In this post we analyze ArduPilot using some of these views. We focus on the different architectural elements of ArduPilot and the connections between them, and the design principles used by the software that allow it to soar.
Having gone through the vision and key architectural aspects of ArduPilot in our previous essays, we will focus in this post on the software quality. Initially we look at the continuous integration and test processes. Then we examine recent coding activities and their alignment with the roadmap. Finally, we assess the code quality and maintainability, as well as the technical debt.
For our last post on ArduPilot, we will be diving into the variability found in the project. We examine aspects like the architectural decisions such as hardware abstraction. A more in-depth analysis of the architecture of ArduPilot can be found in our second post.