Flight testing is the ultimate validation of any aircraft design, for obvious reasons. It’s when you finally make the hardware prove itself, and get real exhaust and real noise from your real airplane.
You get qualitative results—how well the airplane flies, how loud or quiet it is, and how nail-biting or uneventful the launches and landings are. But you also get quantitative results, in the form of telemetry piped from the aircraft’s autopilot. You can use this to see how well your vehicle matches up to your design and predictions, and start to update and improve your own models to match.
Everyone talks about this. I’ve talked about it in the past, too. And you might be thinking “yeah, cool, I’ve heard it a hundred times, flight data is amazing…but how do you actually do that validation?”
Initially I’d planned for this week’s newsletter to cover the whole topic. But while drafting, I realized I needed to lay a lot more groundwork about how we make performance predictions to evaluate against that flight data.
So this week, I’m detailing what kind of information goes into these predictions, and how that information gets used.
A note about “models”
To use a tired trope, the word “validate” means to check or prove the accuracy of something. That’s what we aim to do: we take our truth source of the flight test data, and compare it to our models and predictions to see if the real aircraft matches up to our PowerPoint promises. So, we need to make sure we have the right predictions to compare to.
It’s important to make note of how I’m using the word model here. In casual everyday usage, it’s usually a representative version of something, often smaller than the real thing. I have a model of a P-38 on my desk. In engineering we also talk about CAD models: 3D representations of a part or assembly, just in digital form.
The definition of model becomes a lot more broad in engineering and related fields. It becomes anything that replicates an existing system or set of systems.
Many models are a collection of data sets that interact based on known laws and trends of a given system. They then generate some sort of output—images, numbers, etc.—that tells us the results of that interaction.
This is what models of hurricanes and other weather systems are. Data about past and current conditions goes in, and known physical laws of weather patterns are applied. The result is information we can use, like predictions about the path a hurricane will take. The more accurate the data—like what’s collected by NOAA’s specialized P-3 aircraft and instruments—the better and more precise the predictions.
In our case, a performance model takes in data about our aircraft and provides outputs to evaluate how it flies, like maximum and service ceilings, max airspeed, and so on.
There are three important parts to that performance model: the aerodynamic database, the propulsion system model, and the final performance prediction code.
The aerodynamic database
An aerodynamic database is a series of matrices that provide force and moment coefficients at every combination of angle of attack and sideslip across a given range.
Most databases are expansive, covering many flight conditions and including control surface deflections. Thankfully, that higher level of detail is meant for computer simulations that replicate movement in all degrees of freedom.
All we really need for our performance predictions is a single matrix that tells us the lift, drag, and pitching moment coefficients at each angle of attack within our expected range.
For more accurate results, it’s nice to create what’s called a “trimmed polar.” This accounts for the fact that, at every angle of attack, the aircraft is generating some amount of nose-up or nose-down pitching moment. An elevator deflection is required to counteract this moment and keep the airplane in level flight. That elevator deflection causes a small change in lift and drag for the aircraft as a whole.
Creating the polar requires just a handful of interpolations: find the pitching moment for a given alpha, find the elevator deflection to cancel out that pitching moment, add the lift and drag deltas to the original coefficients.
If you’re trying to get performance predictions quickly, making a trimmed polar is not a necessary step. But it makes your model more accurate for a small amount of extra effort.
The propulsion system
Your propulsion system model depends on the aircraft’s actual propulsive methods. If you use propellers, you’ll need a model for how they turn power into thrust. If there’s an internal combustion engine, you’ll need to include its power limitations and fuel consumption trends. And if you’re spicy enough to use a jet engine, you’ll have an entirely different power-to-thrust model.
Propeller curves can be challenging to obtain, but are simple in construction. These will likely be in the form of thrust coefficient and power coefficient as a function of advance ratio. Given a propeller RPM and forward airspeed, you can find the thrust generated and power required by a single propeller at those conditions.
The unfortunate thing is most propeller curves provided by manufacturers are from analytical or simulated data, not physical testing. Which is entirely fair—it would be expensive to go to a wind tunnel and test every single propeller! So you’ll have to do your best with using their curves or estimating your own. Thankfully, this is one of the things our flight test data can help refine later.
Engine data often comes from dynamometer testing, recorded as tables of power and fuel consumption against RPM and throttle. The real challenge here is integrating it into the performance code properly: if your propeller is directly connected to your engine, you’ll need to match the models’ RPMs somehow. If you’re running a hybrid setup with the propellers separately controlled, adding all the models in may be easier.
The performance code
The performance prediction code is the final piece. Or really, the final pieces, since you can have different codes for different jobs.
This is often just a single Matlab or Python script. It takes in the data sources mentioned above—aero data, propeller data, engine data—alongside user inputs for the desired flight condition, like airspeed, weight, and altitude. The code then steps through the calculations:
- It uses the flight condition and aerodynamic data to find the drag created, and thus thrust required, for the needed amount of lift,
- Then finds the power consumed by the propellers (one or multiple) to generate that thrust,
- And uses this to find how much “extra” power the engine has available at this flight condition.
That extra power corresponds to the aircraft’s maximum possible rate of climb at that condition.
The fun thing about this being a script is it allows these calculations to be done many times across many conditions, instead of for a single point condition. If you iterate through a range of airspeeds and altitudes, you find the rate of climb at each combination.
What this also starts to show you is the combinations of speed and altitude where either the engine can’t generate enough power, or the propellers can’t generate enough thrust. This is how you define your flight envelope: the maximum speed your aircraft can attain at each altitude, and the maximum altitude where it can safely operate.
You can also obtain detailed endurance and range estimates through a mission profile code. By chaining together the calculations, with each step using the fuel load, altitude, airspeed, and other results of the previous one, you can iterate through an entire flight.
Getting trends of vehicle performance with drag, weight, or other factors will take some time. But if you have it, a mission profile code can generate some excellent insights.
You definitely don’t need to have your entire performance model completed before you go fly for the first time. You probably have more important things to worry about!
But if you want to meaningfully validate your aircraft’s performance, you’ll need a finished model. And that’s where the fun starts.