Section 47.6: Quadrotor dynamics and flight control

"The outer loop dreams of waypoints; the inner loop keeps the aircraft from arguing with gravity."

A Field-Tested Control Loop

Figure 47.6A shows the core intuition before any math: the vehicle holds against wind because fast inner loops stabilize attitude and body rates while the outer autonomy stack requests only motion the airframe can produce.

Quadrotor State And Forces

Before writing any equations, consider what a quadrotor can and cannot do. It has four rotors and must produce thrust, roll torque, pitch torque, and yaw torque from those four inputs. That controls four degrees of freedom, but the vehicle moves through six degrees of freedom in space. It is underactuated. We call this the tilt-thrust coupling constraint: you cannot independently command horizontal acceleration and attitude at the same instant. When an AI decision ignores this coupling, the flight controller silently saturates or rejects the resulting commands. Mastering the state and force equations lets a planner know which motions are feasible before it asks for them.

A quadrotor state can be written as position \(p\), velocity \(v\), attitude \(R\), body angular velocity \(\omega\), and rotor speeds \(\Omega_i\). The translational and rotational dynamics are commonly summarized as:

$$m\dot v = mg e_3 - f R e_3 + d, \qquad J\dot\omega = \tau - \omega \times J\omega.$$

The total thrust \(f\) and body torque \(\tau\) come from rotor thrusts through an allocation matrix. Together the thrust and the three torque components are called the wrench, the combined force-and-moment command a controller asks the rotors to produce. For a plus or x quadrotor, the command vector \([f,\tau_x,\tau_y,\tau_z]^T\) is generated by squared rotor speeds, so the high-level planner is really choosing targets that must remain inside a polytope (the multi-dimensional region of feasible thrust-and-torque combinations, bounded on every side by a rotor's saturation limit) defined by rotor saturation, battery voltage, and motor dynamics. If the planner asks for a force or moment outside that envelope, the mission is already infeasible even if the waypoint list looks smooth.

The allocation matrix matters for embodied AI because it is where a learned policy's abstract force-torque command collides with physical motor limits. A policy trained in simulation with unlimited actuators routinely requests combinations of thrust and yaw torque that no real motor configuration can satisfy at once. ETH Zurich's agile-flight group added rotor saturation constraints inside the simulator reward. In their reported experiments, that change reduced the real-world fine-tuning needed by roughly two orders of magnitude, because the policy had already learned not to ask for the impossible; exact episode counts vary by task and airframe, so treat the specific figures as illustrative of the effect size rather than a guaranteed reduction for any given policy. When the firmware clips those commands, the vehicle follows a different trajectory than the policy intended, and the break in that closed loop is what learning relied on. A policy that no motor can execute is not a flight policy; it is a wish list.

From rotor speeds to the allocation matrix

Mechanically, each rotor \(i\) produces thrust \(T_i = k_T \Omega_i^2\) and a reaction torque \(Q_i = k_Q \Omega_i^2\) proportional to squared speed. The allocation matrix \(A\) stacks these contributions so that \([f, \tau_x, \tau_y, \tau_z]^T = A [\Omega_1^2, \Omega_2^2, \Omega_3^2, \Omega_4^2]^T\). Inverting \(A\) converts a desired wrench into target rotor speeds, but the solution is only valid when every resulting \(\Omega_i^2\) stays within the motor's operating range.

Cascaded Flight Control

Those fast inner loops that keep the body stable are not a single controller but a nested stack, and seeing how a waypoint descends through that stack is what reveals where a learned command actually lands. Most practical quadrotor stacks use cascaded control: position control produces velocity or acceleration targets, velocity control produces attitude and thrust targets, attitude control produces body-rate targets, and rate control produces motor commands. The outer loops can be slower. The inner loops must be fast, stable, and well tuned.

PX4 makes this hierarchy visible in its controller diagrams: multicopter position, attitude, and rate controllers are separate contracts with clear setpoints and saturation points. For a learning system, those boundaries are not implementation trivia. They decide whether the policy should command a waypoint, velocity, attitude, body rate, or direct actuator target. Figure 47.6B diagrams this setpoint flow from position through attitude and rate to motor allocation, including the saturation feedback path that an outer loop cannot see directly. The Drone Control Stack table below summarizes each loop's typical input, output, and the failure it should log, so you can see at a glance which layer a learned command targets and what evidence to capture when it goes wrong.

Geometric Control And MPC

Geometric control and MPC are not alternatives to the cascade just described, they are candidate implementations of its attitude and position loops respectively, so every saturation and wind-up behavior from the previous section still applies underneath them. Once the cascaded loops and their saturation-driven wind-up are understood, the next question is which controller fills each loop, and two modern choices move beyond hand-tuned PID. Geometric control treats attitude directly on \(SO(3)\) (the group of all 3D rotation matrices, i.e. the full space of orientations a rigid body can have), avoiding Euler-angle singularities. Concretely, it defines the attitude error as a rotation matrix difference rather than an Euler-angle difference, then drives that error and the body-rate error to zero with gains applied directly on the rotation group; this is what lets a quadrotor track large, fast attitude changes, such as recovering from a near-inversion gust, without the controller's own math blowing up near the poles where roll and yaw angles become degenerate. Nonlinear MPC adds constraints for thrust, tilt, obstacle clearance, geofences, and energy. The practical question is not which controller sounds more advanced, but which one meets the update deadline while keeping enough safety margin.

# Drone control evidence record.
# Roll out one flight-test metric packet after a wind-perturbed run.
# The fields mirror what a PX4 or simulator experiment should save.
from dataclasses import dataclass, asdict

@dataclass
class DroneMissionMetric:
    controller: str
    wind_mps: float
    mean_tracking_error_m: float
    max_tilt_deg: float
    failsafe_events: int

    def as_row(self) -> dict[str, object]:
        return asdict(self)

metric = DroneMissionMetric("geometric_controller", 6.0, 0.21, 24.0, 0)
print(metric)

Expected output: the printed record should show a controller name, a perturbation level, and at least one safety-relevant consequence such as tilt excursion or failsafe count. If your experiment logs only average tracking error, it hides the distinction between graceful recovery and a controller that briefly leaves the safe flight envelope.