Learning ArduPilot — Introduction¶
This page introduces the basic structure of ArduPilot. Before you get started you should work out what code exploring system you will use. You could just use a web browser and look at https://github.com/ArduPilot/ardupilot/ but you will probably get a lot more out of it if you have cloned all of the git repositories and use a good programmer’s IDE like the ones recommended here.
The basic structure of ArduPilot is broken up into 5 main parts:
- vehicle code
- shared libraries
- hardware abstraction layer (AP_HAL)
- tools directories
- external support code (i.e. mavlink, dronekit)
The vehicle directories are the top level directories that define the firmware for each vehicle type. Currently there are 6 vehicle types: Plane, Copter, Rover, Sub, Blimp and AntennaTracker. Although There are a lot of common elements between different vehicle types, they are each different. For now we only have a detailed description of the code structure for the Copter code.
Along with the *.cpp files, each vehicle directory contains a wscript file which lists library dependencies.
The libraries are shared amongst all vehicle types. These libraries include sensor drivers, attitude and position estimation (aka EKF) and control code (i.e. PID controllers). See the Library Description, Library Example Sketches and Sensor Drivers pages for more details.
The AP_HAL layer (Hardware Abstraction Layer) is how we make ArduPilot portable to lots of different platforms. There is a top level AP_HAL in libraries/AP_HAL that defines the interface that the rest of the code has to specific board features, then there is a AP_HAL_XXX subdirectory for each board type, for example AP_HAL_AVR for AVR based boards, AP_HAL_PX4 for Pixhawk boards and AP_HAL_Linux for Linux based boards.
The tools directories are miscellaneous support directories. For examples, tools/autotest provides the autotest infrastructure behind the autotest.ardupilot.org site and tools/Replay provides our log replay utility.
External support code¶
On some platforms we need external support code to provide additional features or board support. Currently the external trees are: