Flight Controllers & Autopilots
It should be noted that there is a separation in this article between the definitions of autonomy, which is capable of making smart decisions, and automatic, which follows a preset plan best possible. To make the step from automatic to autonomous, additional comuptations or problem solving techniques must be added using devices such as an onboard computer. During the time of writing, and "Autonomous" autopilot does not exist, however, this is more of a technicallity as outside of this article the terms are used interchangably.
A flight controller typically referes to a sensor/chip combination capable of performing basic flight tasks, such as rotation control, stabilization, and potentially a stable hover.
These devices usually fall in the sub-$50 category and typically feature a low-end CPU with basic integrated sensors such as:
- Accelerometer (Linear accelerations)
- Gyroscope (Rotational accelerations)
To be capable of stabilized flight, a flight controller must have at least an accelerometer and gyroscope. Some available flight controllers have additional capabilities, however, for the sake of clarity, these will be covered in the Autopilot Section.
Some common flight controller brands are:
- MultiWii
- Naze32
An Autopilot typically refers to a full sensor/chip combination capable of fully automatic navigation around an environment. As it's hard to state a clear definition between the maximum capibilities of a flight controller versus its step to becoming a full autopilot, we have defined it as the capibility to perform some form of meaningful positioning in the environment.
Autopilots can sometimes be found in the ~$100 range, however, it is possible to find extremely expensive options as well, as they tend towards redundancy and safety. Typical features of an autopilot are:
- Accelerometer (Linear accelerations)
- Gyroscope (Rotational accelerations)
- Magnetometer (Alignment with True North)
- Barometer (Altitude estimation)
- Altimeter (Altitude measurement from a known source, e.g. the ground, using external devices, e.g. sonar, lidar, etc.)
- Optical Flow (Close range position and velocity estimation)
- GPS (Latitude, Longitude, and Altitude from satelite)
- Pitot Tube (Relative Airspeed)
Some common autopilots brands are:
- Pixhawk
- Ardupilot
- DJI
- Asctec
The control techniques implemented will vary between flight controllers and autopilots, however there is usually a reasonably common structure. The diagram below describes a cascading position controller, where one controller outputs a reference for the following controller to use.
At most of the steps in this cascade controller, Proportional-Integral-Derivative (PID) controllers are used to calculate the output based on the error between the input reference and the state that is being controlled.
The position controller for a multirotor autopilot typically uses a structure like the one depicted above. These systems rely on some form of input reference, typically provided by a waypoint or trajectory planner. From here, the position error is turned into a reference velocity with a position PID controller, and then to an acceleration reference with the velocity PID controller. Both of these steps will typically introduce some form of limiting to ensure that the multirotor platform does not attempt to move to quickly, or potentially even attempt to move outside a position boundary (more information on "soft" and "hard" fences can be found in the Navigaiton section).
The acceleration vector calculations can be performed in various manners, depending on the low-level controller. The method that is breifly described below covers the method used in the PX4 autopilot at the time of writing. By using this method, instead of generating an acceleration vector, the result is actually a normalized thrust vector.
For a simple multirotor setup, that is PID controlled with no real knowledge of the mass of the airframe, there are some specific assumptions that can be used that will result in quite acceptable error tracking. Namely, with only the input throttle required to maintain hover, the rest of the control sequence can be be normalized. This however will not covered in detail, more information can be found in the source code. This all is done to determine the length of the normalized thrust vector.
The direction of the thrust vector, which determines the goal roll and pitch motions of the multirotor, is aligned with the direction of the reference acceleration that was previously calculated by the velocity PID controller.
The attitude controller for a multirotor autopilot or flight controller typically uses a structure like the one depicted above.
There are two common methods for when talking about the attitude control of a multirotor; full attitude control and partial attitude control. The prior method requires an accelerometer, to perform lateral stabilization, a compass, to align the multirotor with the heading reference, and gyroscopes, which are used to control rate of rotation. In the latter method a compass is not necessary, as instead of a heading reference, a yaw rotation rate is passed directly to the rate controller (this is how stabilizing RC-type modes are typically implemented).
If a reference heading is not used, a PID controllers can be implemented to control the roll and pitch of the multirotor by calculating reference velocities for the each of these states. However, if a reference heading is to be used, things become much more complicated, as a PID controller cannot be implemented to control the yaw state which loops from pi to -pi. One method to get around this issue is to use Rodrigues' Rotation Formula, which, in short, will calculate an the error in rotation about the roll, pitch, and yaw axes. Use of this formula can become quite complicated around specific edge cases, however, as long as the multirotor stays upright, it will work extremely well to calculate the reference rates of rotation.
As the final step, PID controllers are typically used to determine the outputs used to calculate the rotation acceleration or torque inputs that are used control the motors. These inputs can once again be influenced by assumptions made during the control process, and will usually take the form of normalized torques to be applied along the roll, pitch, and yaw axes.
The motor mixer is the final step in the multirotor controller, and is responsible for producing the throttle output of each motor. The motor mixer also allows for different multirotor configurations, such as X4, +4, X6, X8, etc., and is typically in the form of a motor map matrix, referred to as a mixer.