How Does the Drone Work? Inside the Flight Controller and ESC Loop

At its most fundamental level, a drone is an unmanned aerial vehicle stabilized by a microcontroller that reads inertial sensors and adjusts brushless motor speeds hundreds of times per second to maintain attitude and position. If you have ever watched a quadcopter hover perfectly still in a gust of wind, you are watching a high-speed digital control loop executing in real-time. Understanding how does the drone work requires looking past the plastic frame and propellers, straight into the embedded systems architecture that translates physical forces into digital corrections.

The Core Control Loop: Translating Physics to Pulses

The heartbeat of any multirotor is the sensor-to-motor control loop. The Inertial Measurement Unit (IMU), typically a combined accelerometer and gyroscope chip like the MPU6000 or ICM42688P, measures angular velocity and linear acceleration. The flight controller (FC) reads this data, runs it through a Proportional-Integral-Derivative (PID) algorithm, and outputs a command to the Electronic Speed Controllers (ESCs). The ESCs then commutate the 3-phase brushless DC (BLDC) motors to generate the exact thrust required.

Think of it like balancing a broom on the palm of your hand: your eyes act as the IMU, your brain is the flight controller calculating the PID error, and your arm muscles are the ESCs and motors adjusting the base to keep the center of gravity aligned. If your reaction time is too slow, the broom falls; if the drone's PID loop is too slow, it crashes.

What people commonly confuse it with: Beginners frequently confuse the RC receiver’s 50Hz command update rate (how often your radio sticks send a new position to the drone) with the flight controller’s internal stabilization loop. The RC link might update 50 times a second, but the internal IMU-to-motor PID loop on a modern FC runs at 4kHz to 8kHz (4,000 to 8,000 times per second). The drone stabilizes itself long before your thumb even finishes moving the stick.

The Math of Hover: A Worked Numeric Example

To understand how the embedded system manages power, let us look at the exact numbers required to hover a standard 5-inch freestyle quadcopter weighing 1,000 grams (1 kg) using a 6S LiPo battery and 2306 2400KV brushless motors.

In a legacy PWM setup, a 1550 µs (microsecond) pulse width tells the ESC to run the motor at roughly 58% capacity. However, modern builds use Bidirectional DShot600. Instead of a fragile analog-style pulse width, DShot sends a digital packet of 16 bits over a standard UART-like GPIO pin. The first 11 bits represent the throttle value (0-2047), and the 16th bit is a telemetry request. When the FC sends a telemetry request, the ESC uses the exact same signal wire to send back the motor's actual electrical RPM (eRPM). This allows the FC to apply an RPM-based low-pass filter, completely eliminating motor noise from the PID loop without introducing the phase delay of a traditional software filter.

Where You Meet This In Practice: Wiring the Stack

When you are at the bench soldering a stack (the combined FC and 4-in-1 ESC), you are physically routing the control loop. Here is how the connections actually map out on a modern STM32F405-based flight controller:

1. Power Delivery: The main 6S battery leads (10 AWG silicone wire) solder directly to the ESC's large pads. A smaller pigtail (usually 20 AWG) routes 22.2V to the FC's voltage regulator, which steps it down to 5V for the logic chips and 3.3V for the IMU and MCU.
2. Signal Routing: A single signal wire runs from the FC's 'Motor 1' pad to the ESC's 'M1' pad. This carries the DShot600 digital packet. A shared ground wire is mandatory to provide a common reference plane for the high-speed digital signals.
3. UART Peripherals: The RC receiver (like an ExpressLRS module) connects to a dedicated hardware UART (e.g., TX2/RX2) running at 420,000 baud for CRSF protocol. The OSD (On-Screen Display) chip connects to another UART to inject telemetry data into the analog or digital video feed.

According to the official Betaflight documentation, assigning the correct UART and timer resources in the firmware configurator is critical; mapping a DShot motor to a pin that lacks a hardware timer will result in a dead motor or a bricked ESC.

Scenario Walkthrough: The Vibration Trap on a 5-Inch Build

Theory is clean, but the bench is messy. Here is a real-world scenario that highlights what happens when the physical environment interferes with the embedded control loop.

The Setup: You build a 5-inch drone using a SpeedyBee F405 V3 stack. You hard-mount the flight controller directly to the carbon fiber frame using the provided metal standoffs and steel screws. You flash Betaflight, set your PID profiles to the default, and take it to the field.

The Numbers: The FC is running an 8kHz PID loop. The MPU6000 gyro is sampling at 8kHz. The motors are spinning at roughly 32,000 RPM at hover, which translates to a fundamental mechanical vibration frequency of about 533 Hz (assuming a 2-blade prop, 2 × 533 = 1066 Hz blade pass frequency, but the motor bearing noise sits lower).

The Outcome: When you give the drone a quick yaw stick input, it snaps to the new heading but then violently oscillates back and forth, shaking itself out of the sky.

What Went Wrong: You fell victim to IMU aliasing and derivative kick. Because the FC was hard-mounted, the high-frequency mechanical vibrations from the motors traveled directly through the steel screws into the gyro chip. The gyro read this 500Hz+ physical noise as actual rotational movement. The 'D' (Derivative) term in the PID loop calculates the rate of change of the error. When the derivative term saw the massive, rapid spikes from the motor noise, it panicked and commanded the motors to fight a vibration that wasn't actually a rotation, creating a positive feedback loop of oscillation.

Frequently Asked Questions