LibrePilot is an Open Source Avionics Solution for Unmanned Aerial Vehicles (UAV), Model Aircraft and other robots. It implements sensor fusion as well as fully configurable Steering, Control, Guidance and autonomous Navigation and runs on a flight controller circuit board. It interfaces with remote control receivers, GPS, IMU, Barometer and other sensors and controls a number of actuators such as brushless engines, navigation lights, buzzers, servos, etc...

1 Hardware Architecture



Figure 1 Hardware Architecture
A typical UAV or Model Aircraft will be controlled by a human operator with a remote control transmitter. It’s signals will be received by some sort of receiver, which in some cases would directly control the actuators. In case of multicopers and other vehicles with augmented control, a flight controller sits in between to interpret the control commands, then runs control algorithms on the vehicle. For this it is fusing information from integrated sensors typically forming an Inertial Measurement Unit (IMU) as well as possible auxiliary sensors such as a GPS receiver. The controller then steers the actuators such as engine controllers and servos.

2 Software Architecture



Figure 2 Software Architecture

2.1 Ground Control Software


The Ground Control Software (GCS) is typically running on a laptop. It is connected to the Flight Controller using USB, serial cables or some form of radio telemetry. The GCS is used to configure the Flight Controller and to monitor and log flight telemetry data. It can also act as a bridge for hardware in the loop simulation. It is implemented in C++ using the platform independent Qt5 framework.

2.2 Flight firmware


The Flight Firmware is running on the embedded Flight Controller and can operate both while connected to GCS or independently. It is implemented in Embedded C and C++ using the FreeRTOS embedded real time operating system and typically runs on ARM architecture micro controllers. Using a FreeRTOS emulator (“simposix”) the Flight Firmware can also be run on a (Linux)-PC for simulation and test purposes.
The LibrePilot Flight Firmware utilizes a hardware abstraction layer named “PiOS” on top of the FreeRTOS base, as well as a custom scheduler for delayed callback functions with realtime scheduling guarantees. PiOS contains drivers for various communication devices, sensors, actuators, persistent memory, etc... It allows accessing these using hardware independent abstract interfaces.

2.3 UAVObjects


All data is kept in well defined data containers called UAVObjects, which are defined at compile time using XML-description. Both persistent settings and transient run time data is kept in UAVObjects. Any defined UAVObject can be exchanged and modified by both GCS and Flight Firmware based on defined policies. Typically this is usually done using the UAVTalk Protocol.

2.3.1 UAVTalk protocol


The UAVTalk protocol is typically used to exchange UAVObjects between components that share the same set of defined objects. Typically the Flight Firmware and the GCS. UAVTalk implements messages to

2.3.2 Settings UAVObjects


Settings UAVObjects are typically modified only on the GCS, then sent once per modification to the Flight Firmware. They are loaded at boot Time from Non Volatile Memory on the flight controller. The GCS can instruct the Flight Firmware to store such a UAVObject to Non volatile Memory. All settings are retrieved from the Flight Controller by the GCS when a new connection is established to synchronize the configuration. In the GCS, Settings can also be exported to or imported from disk.

2.3.3 Data UAVObjects


Data UAVObjects store runtime values such as sensor data, control commands or status information. They are typically only sent from the Flight Firmware to the GCS, usually at periodic intervals. A notable exception are control objects. These are data objects which are used to influence the runtime behavior, such as objects used for the Connection Handshake between GCS and Flight Firmware or for sending specific control commands for example to instruct the Flight Firmware to save a specific Settings Object to Flash memory or to Erase it. Data Objects can be Single- or Multi-Instance objects, examples for the latter are Waypoints in a navigation Route. These are also Control Objects.

2.4 GCS Plugins


Software components of the GCS are implemented as Plugins. Each plugin defines optional user interface widgets, which can be displayed on a tab within the GCS. For each plugin one or multiple widgets can be configured, each with its own settings.
Examples for plugins are:


Plugins usually operate on one or more UAVObjects which are either read and displayed or modified or both. Each modification of any UAVObject - for example when it is received from the flight firmware or modified by another plugin - triggers an event which any plugin can respond to.

2.5 Flight Firmware Modules


Software components within the Flight Firmware are implemented as Modules. Modules can exist both in form of threads or callback functions.
Their execution can be triggered either by hardware events (such as availability of new sensor data) or by the update of specific UAVObjects.
Modules communicate exclusively using UAVObjects, both between each other and with the GCS.
Examples for Firmware modules are:

3 Control Architecture


The control architecture is dependent on flight mode and settings. This document describes a few noteworthy examples and how they are implemented.
All Modes share a common vehicle agnostic control channel abstraction, where each control channel can assume values between -1 and +1. The following control channels are defined, as seen in the ActuatorDesired UAVObject:


These virtual control channels are mapped to physical actuators using a Mixer Matrix which is stored in the MixerSettings UAVObject along with information about the channel type.

3.1 Manual Control


In Manual Control Mode, the ManualControlCommand coming from the control receiver is directly fed to ActuatorDesired. As such the flight controls directly steer the actuators in open loop control. The pilot actuating the control transmitter closes the loop using hand eye coordination or relies on aerodynamic flight stability.


3.2 Stabilized Control


In Stabilized Control Mode, the ManualControlCommand from the receiver is fed into StabilizationDesired. In Rate mode, a single PID control loop is used for control, while in Attitude mode, two cascaded PID loops are used where the outer loop controls the angular velocity setpoint based on attitude error, and the inner loop controls the actuator based on angular velocity errors.

3.2.1 Rate Control


3.2.2 Attitude Control


3.3 Autopilot Control


In control Modes that involve the Autopilot, the craft is flown by the Flight Controller based on the trajectory instructions in the PathDesired UAVObject. This is initialized to the current position in “Position Hold”, set dynamically based on the ManualControlCommand in various assisted flight modes, or might even be set by the Navigation Computer implemented in PathPlanner module, which traverses a conditional graph of waypoint coordinates.


The control algorithm F varies based on vehicle type and also the PathMode requested in the PathDesired UAVObject. At the time of writing this document the supported control modes are:


It is needless to say that correct function of the autopilot is dependent on a myriad of factors, including but not limited to

4 PDF Version

system_architecture.pdf