How a flight control system is tuned from measured data rather than by feel. The methods are configuration-agnostic. They apply to rotorcraft, fixed wing, multirotors, eVTOL, and unconventional concepts alike, at any scale from sub-kilogram aircraft to crewed-scale vehicles, because what is identified is the aircraft's measured response rather than an assumed form of its dynamics. This page walks through the frequency-domain process: designing the excitation, estimating frequency responses, fitting a state-space model, optimizing gains against stated requirements, and validating the result in simulation and flight.
Tuning by hand is common practice at every scale, from sub-kilogram multirotors to crewed-scale rotorcraft. An engineer raises a gain until the aircraft feels stiff, backs off when it oscillates, and stops when the result looks acceptable. The method works, and where the airframe is simple and cheap it is often the quickest route. Its limits are worth stating plainly, because they explain why the rest of this page exists.
A gain found this way encodes no knowledge of why it works. It does not survive a payload change, an airspeed change, or a shifted center of gravity; it carries stability margins nobody has measured; and a revised airframe starts the process over.
It is also a search with no memory. Each flight evaluates one point in a gain space with several dimensions, judged by how the aircraft looked from the ground, and nothing measured today improves tomorrow's guess. The expense is rarely the tuning itself. It is crew time, range booking, batteries, a weather window that closes, and airframe hours spent on sorties flown only to try another number.
And the method locates the stability boundary by crossing it. Each of those flights is deliberately taken toward the edge of an envelope that has not been characterized, which is why airframes are lost during tuning often enough for it to be budgeted for.
Identification inverts the problem. The aircraft is measured rather than guessed at, and a state-space model is fitted to that measurement. The requirements the closed loop must satisfy, including stability margins, disturbance rejection, bandwidth and actuator activity, are then written down, and an optimizer finds the gains that meet all of them at once. A configuration change becomes a re-run of the optimization rather than another flight campaign.
| One flight buys you | Tuning by hand | Identification and optimization |
|---|---|---|
| Data value | One gain set, judged by impression | Response across the whole frequency band, reusable indefinitely |
| What is learned | Whether that gain felt acceptable | A model that predicts responses never flown |
| Stability margins | Unknown | Measured, and designed to a stated value |
| Configuration change | The campaign restarts | The optimization re-runs, usually without flying |
| Finding the limit | By crossing it, in the air | By predicting it, on the ground |
| Evidence for review | Pilot opinion | Traceable compliance against a requirement set |
| Where it lives | In one engineer's head | In a model, a specification set, and a report |
The trade is effort spent up front against effort spent repeatedly. On a cheap, well-understood airframe that will never change, tuning by hand usually wins. The balance shifts as the aircraft becomes expensive, carries something, keeps changing, or has to satisfy somebody asking how its safety is known.
Identification is only as good as the data. We inject a designed excitation, usually a frequency sweep covering roughly 0.3 to 30 rad/s, at the surface or rate-command input with the outer loops opened or held as loose as the aircraft safely allows. Doublets and steps are flown as well and held back from the fit, so they stay independent data for verification. We log at 200 Hz or better on the excited channels, with known latency and documented anti-alias filtering.
How the excitation gets in depends on the autopilot. Ardupilot and Betaflight provide the functions natively. For PX4 and custom autopilots we write the firmware library that generates and injects the signal, and we modify either of the others where a program needs more than the stock build.
Windowed FFT turns the time histories into frequency responses. FRESPID computes the autospectra and cross-spectrum for each record, MISOSA conditions correlated control inputs into individual decoupled responses, and COMPOSITE merges several window lengths, taking low-frequency accuracy from long windows and high-frequency accuracy from short ones.
Coherence is the quality gate. Above roughly 0.6 the response is linear, repeatable, and driven by the input we applied. Outside that band it is noise or nonlinearity, and it gets no weight in the fit. Being disciplined here largely determines whether the model is trustworthy.
NAVFIT handles a quick transfer-function fit. For a full vehicle, DERIVID fits a coupled state-space model: stability and control derivatives, rotor or inflow states where the dynamics demand them, and equivalent time delays that absorb unmodeled lag from filters, bus latency, and actuators.
Fit quality is judged numerically, not by eye. An average cost J below roughly 100 per response means the model is not readily distinguishable from the flight data; insensitivities under about 10% and Cramér–Rao bounds under about 20% mean each derivative is genuinely identifiable. Anything failing those tests is dropped or fixed to an analytical value. VERIFY then drives the model with the withheld doublets and steps, which is the honest test because it uses data the fit has never seen.
With a validated plant model, tuning becomes a constrained optimization rather than a search. We build the closed loop in Simulink, including the identified plant, the real controller structure, sensors, filters and delays, and declare the requirements in tiers:
CONDUIT drives the hard constraints feasible, then the soft constraints into the satisfactory (Level 1) region, then minimizes the objectives while holding everything already achieved. Design margin optimization pushes each specification a stated percentage past its boundary so the gains tolerate model error and configuration drift. Trade-off studies sweep a requirement, disturbance rejection bandwidth for example, and show what it costs in actuator activity, turning a design argument into a plotted curve.
Optimized gains go into nonlinear simulation, then into software- and hardware-in-the-loop with the real flight code and autopilot timing. Our PX4 / Ardupilot SIL for Simulink is built for this handoff, so discretization, filter and latency effects show up on the bench instead of in the air. Flight validation then expands the envelope incrementally, repeating the sweeps at each new condition. Where the dynamics change materially with airspeed, weight or CG, we identify at multiple points and schedule the gains, verifying the blending across the schedule rather than assuming it.
Nearly every judgment in this process is made in the frequency domain, because that is where model error, time delay, and stability margin are visible at a glance. A usable identification result looks like the figure below: the identified model overlays the flight-derived response across the band where coherence is high, and neither the fit nor the design requirements depend on the regions where it is not.
The same picture supports the design side. Broken-loop responses give gain and phase margin directly, closed-loop responses give bandwidth and phase delay, and the disturbance rejection response gives the metrics that determine how well the aircraft holds position in wind. Because all of them come from one identified model, a change to any gain can be evaluated against every requirement at once.
Requirements come from the applicable specification and from the mission. Rotorcraft and eVTOL work generally anchors on ADS-33E-PRF; fixed-wing on MIL-STD-1797 and MIL-DTL-9490. For an uncrewed aircraft with no pilot in the loop, handling-qualities criteria still apply: they remain the most mature quantitative statement of what a well-behaved aircraft response looks like, and they translate directly into autonomy performance.
Unconventional concepts, including tilt-rotors, tail-sitters, lift-plus-cruise, distributed electric propulsion, and coaxial or vectored-thrust layouts, often have no directly applicable specification. Identification matters more there, not less. With no legacy database to draw on and no handbook derivative estimates to fall back on, a measured model is frequently the only trustworthy description of the aircraft, and the requirement set is assembled from the nearest applicable specification plus mission-derived criteria.
| Requirement | Tier | What it protects |
|---|---|---|
| Eigenvalue stability | Hard | No unstable closed-loop modes at any design point. |
| Gain / phase margin | Hard | Tolerance to model error, latency, and actuator variation. |
| Bandwidth & phase delay | Soft | Command responsiveness and freedom from pilot- or autopilot-induced oscillation. |
| Disturbance rejection bandwidth / peak | Soft | Position and attitude hold quality in gusts and turbulence. |
| Damping ratio | Soft | Settling behavior; no lightly damped closed-loop modes. |
| Model-following error | Soft | Response matches the commanded response model. |
| Actuator RMS & rate | Objective | Servo duty cycle, heat, wear, and power draw. |
| Crossover frequency | Objective | Avoids buying performance by pushing gains into unmodeled dynamics. |
A full campaign is not always justified. These are the conditions under which it usually is.
A wobble that appears at a particular airspeed, payload, or wind condition is a symptom of a margin that has never been measured. Identification makes it visible, and usually explains it in the first session of analysis.
New payload, larger battery, shifted CG, a stretched fuselage. When each change costs another week of flying, the underlying problem is the absence of a model.
Copied from a similar airframe, left behind by a departed engineer, or produced by autotune. They may fly acceptably today, with margins nobody has quantified.
Design reviews, airworthiness submissions, and customer acceptance all ask the same question: how is this known? A traceable requirement set and measured margins answer it.
First flight has happened and the program is moving. Identification converts the remaining work from an open-ended search into a bounded, plannable task.
Precision hold in wind, tight tracking, sensor-driven landing, and payload stabilization are all capped by disturbance rejection, which cannot be improved without measuring it.
Excitation design per axis, instrumentation and logging requirements, test cards, and the reduced flight data, including the independent maneuvers reserved for verification.
A state-space model with stability and control derivatives, equivalent time delays, and documented fit quality: cost, insensitivity, and Cramér–Rao bounds for every retained parameter.
The full constraint set the control law is designed against, traced to ADS-33, MIL-STD-1797, or mission-derived criteria, with the rationale for every boundary and design margin.
Tuned gain sets per design point, the blending across the schedule, and the trade-off studies showing what each requirement cost, in a form the autopilot can load directly.
The Simulink plant and closed-loop architecture used for the optimization, wired into software- and hardware-in-the-loop against the real flight code.
Predicted versus measured response for the verification maneuvers, achieved margins and specification compliance at each design point, and the flight results from envelope expansion.
OASiS, the optimAero Sizing and Simulation tool, is our in-house environment for aircraft sizing and simulation. Beyond sizing it performs the two functions described above in CIFER and CONDUIT: frequency-response estimation and parametric model identification from flight data, and multi-objective optimization of control laws against tiered specifications. Keeping all of it in one environment closes a loop the conventional toolchain leaves open, because a model identified from flight data feeds back into the sizing models that predicted it.
OASiS is used internally on optimAero programs and is not currently available for licensing. Where a program requires CIFER and CONDUIT specifically, which is common on government work and reasonable whenever deliverables must be reproducible in the tools a team already runs, that work is done directly in those instead. The process and the deliverables are the same either way.
The standard reference for this material is Mark B. Tischler and Robert K. Remple, Aircraft and Rotorcraft System Identification: Engineering Methods with Flight-Test Examples (AIAA, 2nd ed.), which covers the frequency-response methods, the CIFER workflow, and worked examples from real flight-test programs. CONDUIT and its specification library are documented in the accompanying NASA and U.S. Army technical reports.
For related work on our side, see Projects for aircraft these methods have been applied to, Research for published papers, and PX4 & Ardupilot SIL for Simulink for the open-source simulation environment used in the validation step.
optimAero runs this process on customer aircraft, on Ardupilot, PX4, Betaflight, and custom autopilots, across rotorcraft, fixed wing, multirotor, eVTOL, and unconventional configurations from 1 lb to crewed scale. Scope varies from identifying a single axis to a full multi-design-point campaign, and sometimes the useful answer is that identification is not what an aircraft needs.
Questions about the method are welcome whether or not there is a project attached.