Module 01 of this series began with a mission requirement. Every module since has been the systematic translation of that requirement into physical hardware — airframe, propulsion, avionics, manufacturing, integration. This final module closes the loop. Flight testing is where the predictions made in analysis and simulation are confronted with physical reality, and data analysis is the discipline by which that confrontation produces useful knowledge rather than just expensive experience. A vehicle that is not rigorously tested is not a validated system — it is an assumption with wings.

The test plan: structured discovery

A test plan is not a schedule. It is a structured sequence of test points designed to expand the vehicle's demonstrated flight envelope progressively, with each test point building on the results of the previous one, and with clear go/no-go criteria at each stage that define what constitutes successful completion before proceeding. The absence of a test plan does not mean the vehicle is tested more efficiently — it means the testing is unstructured, and unstructured testing produces incomplete data from which incomplete conclusions are drawn.

The test plan begins with the test objectives: what performance parameters must be demonstrated, to what accuracy, across what range of conditions? These objectives come directly from the system requirements written in Module 01 — the test plan is the document that closes the V-model loop opened by the requirements. Every system requirement that was written as "the vehicle shall achieve..." must have a corresponding test point that measures whether it does.

Test points are ordered from lowest risk to highest risk, from closest to the design point to furthest from it. The first flight test points are always in the center of the expected flight envelope — nominal weight, nominal airspeed, nominal altitude, benign weather — not at the edges. The edges of the envelope are explored only after the center has been thoroughly characterized and the vehicle's behavior is well understood. An anomaly discovered at the edge of the envelope in a well-understood vehicle can be diagnosed and corrected. The same anomaly in a vehicle that has never been carefully characterized at nominal conditions produces confusion, not data.

Data acquisition and instrumentation

The autopilot's built-in data log is the primary data source for most UAS flight test programs. Modern autopilots — ArduPlane, PX4, Micropilot — log all sensor measurements, control outputs, EKF state estimates, and system health indicators at rates of 10–200 Hz depending on the parameter, creating a comprehensive record of everything the autopilot measured and commanded during the flight. This log is the flight data recorder of the UAS world, and reviewing it after every flight — not just anomalous ones — is the discipline that separates systematic test programs from hope-based development.

For performance testing that requires accuracy beyond what the autopilot's sensor suite provides, supplemental instrumentation is added. A calibrated pitot-static system more accurate than the autopilot's onboard airspeed sensor provides true airspeed with the precision needed for drag polar determination. A high-accuracy RTK GPS provides centimeter-level position accuracy for trajectory analysis. A dedicated power meter at the battery output provides current and voltage measurement that is more accurate than the autopilot's power module for energy budget verification. The rule for instrumentation: measure what you need to know, with enough accuracy to distinguish between a vehicle that meets its requirements and one that does not.

The data log review habit Every flight should be followed by a data log review before the next flight is attempted. Not a cursory scan — a systematic review of the key parameters against the expected values for that flight profile. This habit catches the anomalies that are too subtle to notice during the flight: an airspeed sensor that reads 3% high at cruise, a GPS that logged a brief accuracy degradation during the turn, a battery that showed a voltage sag 0.2 V below the expected value at maximum throttle. None of these are immediately dangerous, but each is a data point that, accumulated across multiple flights and noticed during log review, becomes a finding that improves the vehicle or prevents a future incident.

Performance envelope establishment

Establishing the performance envelope means measuring, not estimating, the vehicle's key performance parameters across the relevant range of operating conditions. For a fixed-wing UAS, the primary performance parameters are: minimum and maximum airspeed (including stall speed and never-exceed speed), cruise speed at which maximum endurance is achieved, the power-airspeed relationship, maximum rate of climb, and the effect of weight on all of the above.

The aerodynamic drag polar — the relationship between lift coefficient and drag coefficient across the operating angle of attack range — is the most useful single performance characterization of a fixed-wing vehicle. It is determined from level-flight speed-power runs at multiple airspeeds: at each airspeed, measure the power required to maintain level flight. From the power and airspeed, compute the drag at that condition. From the weight and airspeed, compute the lift coefficient. Plot CL against CD, and the drag polar is the result. A drag polar determined from flight test data is the basis for accurate endurance prediction, optimal cruise speed selection, and any future variant design that modifies the aerodynamic configuration.

Level-flight speed-power run procedure
Select a calm-air test day. Wind above 5 knots introduces error in speed-power measurements that must be averaged out with multiple runs in opposing directions.
Stabilize the vehicle at the target airspeed in level flight for at least 30 seconds before recording. Transient data is not useful — only the steady-state power draw at constant altitude and airspeed is meaningful.
Record: indicated airspeed, GPS ground speed (for wind correction), altitude, battery current and voltage, throttle position, and attitude. Log at minimum 10 Hz for 30 seconds at each test point.
Run at airspeeds from 10% above stall to maximum cruise speed, in 5 km/h increments. The speed with minimum power-to-airspeed ratio is the maximum endurance speed. The speed with minimum power-to-distance ratio is the maximum range speed.
For each test airspeed, run at least one out-and-back pair in opposing headings to cancel wind effects. Average the power measurements from the two headings.

Stability and control testing

Stability and control testing verifies that the vehicle's handling qualities — how it responds to control inputs and atmospheric disturbances — match the design intent and the requirements written in Module 01. Poor stability and control characteristics are not always dramatic: a vehicle can be flyable but require more autopilot effort than designed, accumulating control surface wear faster than expected, or degrading in turbulence in ways that affect sensor data quality.

The primary stability test is the pulse input: the autopilot applies a brief, defined control surface deflection and then returns to neutral, and the vehicle's response — the oscillation in attitude that follows — is recorded. The natural frequency and damping ratio of the short-period pitch mode and the phugoid (long-period pitch oscillation) can be extracted from the response. If these match the values predicted by the aerodynamic analysis in Module 02, the model is validated. If they do not match, the aerodynamic model is corrected — and the updated model is used for any subsequent flight control law design changes.

Control effectiveness testing verifies that the control surfaces produce the moment authority required by the design. The test: command a known rate of roll (for ailerons), a known pitch rate (for elevator), or a known yaw rate (for rudder) using the autopilot, and measure the control surface deflection required to achieve it. Compare this to the design prediction. Control surfaces that require more deflection than predicted to achieve a given rate are less effective than designed — perhaps because the hinge gap is larger than designed, the control surface is aerodynamically stalled at the test condition, or the linkage has more slop than the design assumed.

Propulsion system flight verification

The static thrust test in Module 07 characterized the propulsion system at zero airspeed. Flight test provides the in-flight characterization — how thrust varies with airspeed, how the motor and ESC thermal behavior changes under sustained flight loads, and whether the endurance predicted by the Module 04 calculation matches the endurance measured in actual flight.

The endurance verification test is straightforward in concept: fly the vehicle at the design cruise speed, in level flight, until the low-battery failsafe triggers, and record the total flight time and the total energy consumed from the battery log. Compare the measured endurance to the prediction from the endurance calculation. A vehicle that achieves 85% of the predicted endurance is revealing something about the calculation's assumptions — typically that the actual cruise power is higher than predicted (the vehicle is flying at a higher angle of attack than designed, increasing drag) or that the battery capacity is lower than the nominal specification (common in Li-Ion cells after many charge cycles).

η_actual = E_used / (t_flight × P_predicted)
η_actual — actual system efficiency (compare to design assumption)  ·  E_used — energy drawn from battery during flight (Wh, from log)  ·  t_flight — flight time (hours)  ·  P_predicted — predicted cruise power (W, from Module 04 calculation)
If η_actual < design assumption: the vehicle is using more power than predicted — investigate cruise AoA, actual propeller efficiency, and battery internal resistance. If η_actual > design assumption: the vehicle is more efficient than predicted — the endurance prediction was conservative.

Anomaly investigation

Every anomaly discovered during flight test — unexpected behavior, parameter out of range, unexplained event in the log — must be investigated to root cause before the next flight. Not to probable cause. Not to likely cause. To root cause: the specific physical mechanism that produced the observed anomaly, confirmed by evidence rather than assumed by elimination.

The investigation process starts with the log. A flight anomaly without a log is a mystery; the same anomaly with a log is an engineering problem. The log provides a timeline of every sensor reading and every autopilot action before, during, and after the anomaly, which allows the sequence of events to be reconstructed with enough precision to identify the initiating cause. The GPS drop-out that caused the autopilot to switch to attitude mode happened because the video transmitter was turned on two seconds earlier — the log shows both events. The oscillation that appeared at high speed happened at an airspeed where the control loop gain was marginally stable — the attitude rate log shows the frequency, which matches the predicted natural frequency of the short-period mode at that flight condition.

A pattern of anomalies that each seem independently explained — this one was a GPS issue, that one was a software bug, the other one was operator error — should always be examined for a common underlying cause. A vehicle that accumulates anomalies at a rate higher than expected is telling the engineer something about the design, the manufacturing quality, or the operational environment that the individual anomaly investigations are missing.

How test data closes the design loop

The flight test program generates data. The data analysis generates findings. The findings generate action: either confirmation that the design meets its requirements and the vehicle is cleared for operational use, or identification of a deficiency that must be corrected before clearance. This loop — design, build, test, analyze, correct — is the fundamental discipline of engineering, and it applies to the smallest amateur UAS and the most sophisticated tactical system with exactly the same logic.

The most valuable flight test findings are not the ones that reveal dramatic failures — those are usually obvious and quickly corrected. The most valuable findings are the quantitative discrepancies between prediction and measurement that would never be found without careful data analysis: the 8% drag penalty from a surface finish that is rougher than designed, the 12-minute endurance shortfall traced to a motor efficiency that peaks at 3,400 RPM rather than the 4,000 RPM the propeller matching assumed, the compass deviation that only appears at full throttle because the motor current field was calibrated at idle. Each of these findings feeds directly back into the analysis models, making every subsequent prediction more accurate — and making every subsequent design in the same family faster to validate.

Test reporting and documentation

A flight test program that is not documented is a flight test program from which no one benefits beyond the people who were there. The test report translates the raw data and findings into a form that can be reviewed, archived, and referenced by anyone who will ever work on this vehicle or its successors. It is also the document that closes out the V-model — the formal record that the system requirements established in Module 01 have been verified by test, analysis, demonstration, or inspection as specified in the requirements traceability matrix.

The minimum test report content is: the test objectives and how each was addressed; the test conditions for each test point (date, weather, vehicle configuration, instrumentation); the results for each test point in the form of measured values compared to predicted values and to requirements; and the disposition of each finding — closed (root cause identified and corrected), accepted (within requirements despite exceeding prediction), or open (requires additional investigation or design action).

The flight log data files should be archived alongside the report, referenced by flight number, so that future engineers can return to the raw data to answer questions that the original test report did not anticipate. A vehicle that is modified, repaired, or upgraded after its initial test program should have its test report updated to reflect the change — not replaced, but updated, so that the history of what was tested, what was found, and what was changed remains complete and traceable.

From test data to operational clearance

The output of a completed flight test program is not just a report — it is a defined, tested, and documented flight envelope within which the vehicle is authorized to operate. The operational flight envelope specifies: the weight limits (minimum and maximum takeoff weight), the airspeed limits (minimum and maximum), the altitude limits, the wind limits (maximum crosswind and headwind for launch and recovery), the temperature and humidity limits for electronics and battery operation, and any operating restrictions identified during testing (no operations over water beyond glide range from shore, for example, if the recovery system has not been tested for water landing).

Operating outside the tested and documented flight envelope without additional testing is not a matter of pilot skill or engineering judgment — it is the technical definition of an untested condition. An operator who takes a vehicle above its tested altitude limit, or in crosswind above its tested crosswind limit, is conducting flight test whether they intend to or not. If they have the instrumentation, the test plan, and the progressive expansion discipline to do it safely and generate useful data, that is legitimate. If they are simply accepting a risk that has not been quantified because the mission requires it, that is a different matter — and the distinction matters for the engineering record and for any liability that follows from an incident.

The test program never truly ends A vehicle that re-enters service after any modification — a changed propeller, an updated firmware version, a repaired structural member, a different battery chemistry — should be treated as a partially unknown system until the modified configuration has been verified by test. The original test clearance applied to the original configuration. The engineer who assumes that a firmware update has no flight dynamics implications has made an assumption that the test data does not support. Regression testing after any significant change — even a brief check flight at the nominal condition to confirm that the basic performance has not changed — is the discipline that maintains the integrity of the operational clearance over the vehicle's service life.

Closing the loop on the series

This module completes the design-to-test path laid out at the beginning of this series. Module 01 defined what the vehicle must do. Modules 02 through 06 defined what it must be. Module 07 integrated those definitions into a physical system. Modules 08 and 09 extended the methodology to the maritime and subsea domains. This module closes the loop by verifying, through test and data, that the physical system actually does what Module 01 required.

The loop closes — but it does not end. Test findings update the models. Updated models produce better designs. Better designs produce better test results. Each iteration through the loop produces a vehicle that more precisely does what is required of it, with less margin consumed by unknown variables and more margin available for the next increment in capability. This is the engineering process applied to unmanned systems — not a linear sequence that ends at first flight, but a cycle that continues for as long as the vehicle is in service and the program has the discipline to keep the loop turning.