What Does a Flight Controller Do in Each Control Loop?

• Sensor measurements
• Flight controller
• Controlled motor

A control loop runs from sensors to motors

Imagine a simulated drone asked to hold still at a point. The flight controller does not see a “point” as a person does; software receives messages with timestamps, units and coordinate frames. The sequence below is a conceptual model, not a claim that every firmware runs these steps in precisely this order or at one fixed rate.

For example, simulated wind pushes the drone away from its hold point. Motion sensors register acceleration; the estimator updates velocity and position. The controller sees that estimated position no longer matches the target and requests a corrective attitude and force. Allocation turns that request into relative commands for the motors. If the new state shows the drone closer to its target, the next loop reduces the correction. If error grows or sensors become unreliable, the system needs to limit or reject control rather than pretend the point is still being held.

Why estimate state instead of using one sensor?

A gyroscope measures rotation rate; by itself it does not give a map position. An accelerometer responds to acceleration and gravity, but its reading alone is not a complete state. An estimator combines measurements with a motion model to produce a consistent state. That result remains an estimate: delay, vibration, bias or lost positioning can make it wrong.

In PX4, the flight stack on the flight controller includes drivers, communication modules, controllers and estimators. PX4 controller diagrams describe a cascaded structure: when a mode needs position holding, an outer loop creates motion requests; attitude and angular-rate loops help carry them out; control allocation maps force and torque to outputs. This describes PX4, not a mandatory design for every controller.

Use a log to trace the loop

In a simulator exercise, select a short interval around a change in the position target. Plot the target position, estimated position, estimated velocity and motor outputs against the same time axis. Error is the directed difference between the target and estimated state; a mode-change event alone cannot explain it.

Ask in sequence: did the target arrive at the expected time? Did the state update after sensor samples? Did error shrink after a correction? Did an output saturate or data disappear? A log contains only signals that were enabled and may have missing samples. It shows timing relationships, but cannot establish a cause by itself without inputs, estimator state and matching configuration.

What changes between systems?

PX4 distinguishes manual modes, which provide different levels of autopilot support while a pilot flies, from autonomous modes that can be fully controlled by autopilot. Topic names, sensors, fusion algorithms, loop structure and the location of allocation depend on firmware, airframe and configuration. A companion computer may send a high-level task, but the flight controller still has to accept it and pass it through a suitable control interface. This diagram helps explain the data flow; configuration and logs from the exact version identify the real signals.

Summary

Each loop samples data, estimates state, computes error, creates a correction, distributes it to motors and uses new feedback to update the decision. To understand a log, follow the target, state and outputs on the same timeline.