Behind the stable flight of every drone is a small circuit board performing thousands of calculations per second: the Flight Controller (FC). As the first installment of our Fundamentals series, this article explains what an FC does and breaks down its essential core components. Understanding the bigger picture of the FC—alongside your existing knowledge of ESCs and motor design—will give you a clear, system-level perspective on drone development.
What Exactly Does a Flight Controller Do?
The flight controller is the embedded computer that calculates the drone's attitude (orientation) and position, and ultimately determines the output power for each motor.
When a pilot moves a transmitter stick, that control signal is delivered to the FC. The FC then calculates exactly how much each motor needs to spin and sends corresponding commands to the Electronic Speed Controllers (ESCs). In the case of GPS-guided or waypoint flight, autonomous navigation algorithms generate these commands instead of manual pilot inputs.
The primary operations handled by an FC can be broken down into three distinct layers:
1、Sensing Layer: Gathers raw data from sensors like the IMU (gyroscopes and accelerometers), GNSS, barometric pressure sensors, compasses, and optical flow sensors.
2、Estimation Layer: Estimates the actual state of the robot (attitude, position, and velocity) from the collected sensor data. Because a standalone IMU accumulates drift over time, an Extended Kalman Filter (EKF) fuses data from multiple sensors to achieve high-precision state estimation.
3、Control Layer: Calculates the error between the estimated state and the target values (e.g., hovering, moving forward, or hitting a waypoint) and determines the exact motor outputs needed to close that gap, typically using PID control or Model Predictive Control (MPC).
This three-layer process continuously loops at an ultra-fast cycle time of 500 µs to 125 µs (2 kHz to 8 kHz).
Internal Hardware Components of an FC
An FC is built from several specialized hardware components working in tandem:
MCU (Microcontroller Unit): The brain of the FC. It handles everything from reading sensor data and filtering to executing EKF/PID calculations and outputting ESC commands. The Pixhawk series relies on STM32F7 or STM32H7 chips, which we will cover in depth later in this series.
IMU (Inertial Measurement Unit): A MEMS sensor that measures the aircraft’s angular velocity (gyro) and acceleration. Chips like the ICM-42688-P and BMI088 are widely adopted. High-quality FCs often pack two or three IMUs to provide hardware redundancy.
Barometric Pressure Sensor: Sensors like the BMP388 or SPL06 estimate altitude based on atmospheric pressure. They offer an accuracy of roughly ±1 m and are used complementarily with GNSS altitude data, which typically has a wider vertical error margin (around ±3 m).
GNSS Module: Modules featuring u-blox chips, such as the M9N or the RTK-enabled F9P, are standard. The F9P provides centimeter-level positioning accuracy.
Compass (Magnetometer): Sensors like the IST8310 or QMC5883L establish an absolute heading reference for yaw. Because they are highly vulnerable to electromagnetic interference (EMI) from power lines and motor currents, they are usually housed externally, far away from the main FC board.
Power System: Consists of DC-DC converters and Low-Dropout (LDO) regulators that step down battery voltage (3S to 12S LiPo) to clean 3.3V and 5V rails. Dedicated LDOs isolate the sensitive sensor circuitry from power noise (detailed in our EMI series).
Connectivity Interfaces: Employs UART, SPI, I2C, CAN, USB, and PWM/DShot protocols to communicate with sensors, ESCs, and Ground Control Stations (GCS).
The Control Problem: Why Drone Flight is Difficult
Flying a drone is not as simple as "spinning up the motors." Taking a quadcopter as an example highlights the engineering challenges:
Multi-Input, Multi-Output (MIMO): A quadcopter has 4 motors but must simultaneously control 4 independent degrees of freedom: roll, pitch, yaw, and thrust (altitude). This makes it a complex 4-input, 4-output control problem.
Actuator Latency: Electric motors and propellers possess mechanical and electrical lag. It can take tens to hundreds of milliseconds from the moment a command is sent for a propeller to actually hit its target RPM. This latency is a primary driver of control instability.
Real-Time Disturbance Rejection: The system must adapt to unpredictable environments instantly. A sudden 5 m/s crosswind can push an uncompensated drone off course by tens of centimeters; the FC must detect this via its sensors and apply counter-torque immediately.
Vibration Noise: High-frequency vibrations from the motors travel through the frame and corrupt raw IMU readings. Combating this requires a careful mix of software filtering (low-pass and notch filters) and physical vibration isolation mounts—a topic we explored thoroughly in our IMU series.
The core job of the FC is resolving these interconnected issues consistently within its strict 8 kHz loop time.
Key FC Platforms and Software Ecosystems
The current landscape of flight control hardware and firmware used across industry and research can be categorized as follows:
Hardware Platforms
Pixhawk Series: Open-hardware FCs (manufactured by Holybro, mRo, etc.) designed to run ArduPilot or PX4. They utilize STM32F7 or H7 MCUs and often feature a dual-processor architecture separating the Flight Management Unit (FMU) from the Input/Output (IO) processor. This is the gold standard for industrial applications due to its robust ecosystem.
Betaflight Ecosystem: Hardware tailored strictly for racing and FPV (First-Person View) drones. They prioritize low-latency processing and ultra-fast control loops using STM32F4 to H7 chips, keeping onboard sensors to a bare minimum (often omitting GNSS).
Proprietary Systems: Ecosystems like DJI’s N3/A3 platforms represent closed, highly integrated solutions designed to work seamlessly within their own software development kits (SDKs).
Note on Custom Development: The most common approach for custom industrial FC design is defining your proprietary STM32H7 hardware architecture via ArduPilot’s hwdef.dat configuration file, allowing you to run a mature flight stack on bespoke hardware. We will focus on this methodology in the latter half of this series.
Flight Stacks (Firmware)
ArduPilot: An open-source project active since 2009. It supports an incredibly diverse array of platforms including multirotors (ArduCopter), fixed-wing aircraft (ArduPlane), ground rovers (ArduRover), and submersibles (ArduSub). While its massive parameter set offers unmatched flexibility, it comes with a steep learning curve. It is highly favored in commercial drone manufacturing.
PX4 Autopilot: Developed originally out of ETH Zurich, PX4 features a highly modular, clean software architecture. It offers native, out-of-the-box support for ROS 2 via uXRCE-DDS, making it an increasingly popular choice for academic research and advanced robotics development.
This series will primarily focus on ArduPilot. Advanced topics like writing custom hwdef.dat files and implementing low-level drivers will be covered starting in FC5.
Summary
The flight controller is an embedded powerhouse that executes sensing, state estimation, and control loops at the kilohertz level. Its performance hinges entirely on deliberate hardware component selection and software optimization.
In our next post, FC2, we will break down the UAV Control Architecture, mapping out the hierarchical relationship between the attitude loop, position loop, and the mission planner.