Last time, when I talked about the God complex—the belief that, through your own expertise, you can (and will) always devise the right solution to a problem of any complexity—I focused more on the higher-level impacts of this mindset.
That’s partially because letting it influence your project can have serious program-level consequences. Believing the team can analyze its way to the perfect solution uses up engineers’ time retreading old decisions, substantially slows the team’s momentum, and at its worst, results in not fulfilling the obligations of the contract. Yikes!
Somehow in discussing the impacts of the God complex, I forgot about one of the best examples in the aero industry: the philosophy of the Wright brothers versus their contemporary Samuel Langley in inventing the first airplane. One of this newsletter’s readers, Cliff Brake, reminded me of this when he sent me his article about the two that contrasted the Wrights’ “Release First” approach against Langley’s “Big Release” methodology.
Testing To Learn
The article does a really great comparison and you should absolutely read it for yourself. The short version is that while Langley’s approach “was to design the perfect flying machine on paper, build it, and then attempt a single dramatic launch,” the Wrights carried out an enormous amount of iterative, informative testing. This was a huge factor in their success, despite having substantially less funding and fewer resources available than Langley.
One of the truly excellent points Cliff makes in his article is that the Wrights “were not trying to fly; they were trying to learn.” They tested over 200 different wing shapes in a homemade wind tunnel so as to characterize the relationships between specific geometries and the resultant aerodynamic effects. They intentionally explored existing areas of uncertainty to educate themselves and then find a solution. In doing so they ended up inventing three-axis control—something that feels so fundamental to us now, but had barely been investigated before!
I think this aspect of not purely trying to design, but also trying to learn, is a key part of how trial and error shows up in aerospace engineering. There have been a handful of engineers who can design a perfect airplane on a napkin. But for the rest of us, trade studies and understanding the design space are a key part of our process. We do explorations as simple as trying different wing incidence angles to see the aerodynamic impacts.
It’s in the testing phases of development where it’s harder to embrace trial and error. After all, when you’re testing a flying vehicle, “error” usually means you break something. Admitting uncertainty and fallibility is incredibly painful, uncomfortable, and often expensive. So more often than not, we shy away from it. But there are still ways to try ideas and learn while appropriately addressing risk.
Please note that, as always, I’m specifically talking about UAV design and testing here. Crewed aircraft have substantially more intense requirements and a level of risk tolerance orders of magnitude lower than I typically work with—for good reason! If you work on airplanes that carry people, I hope you filter everything I say through your own best judgement and experience.
Here’s a handful of good ways to incorporate some of that trial and error spirit into your design and testing efforts, without entirely throwing caution to the wind.
Cheap to Make, Cheap to Break
If your aircraft is designed to be relatively low-cost to build, can you hustle to make a version that’s good enough to fly safely and start getting real data? With a cheaper build you can afford to have wings that aren’t perfect and propulsion that isn’t optimized, as long as your avionics stack and other critical components are fully functional.
Fly the airplane you have and use the data to validate the existing analysis for that specific iteration. Propulsion systems especially benefit from this, as you often don’t truly know the performance of your propeller(s) until you get forward flight data. This becomes your springboard to go and optimize the aspects of the design that will notably benefit the aircraft as a whole.
At the same time you can keep flying the physical vehicle, giving other disciplines a chance to find and fix problems that pop up—even simple things like harness connectors that work themselves loose, or control logic that causes lots of rocking. And because the vehicle has a low cost, you can make multiple flight assets, and/or have a beefy stash of spare parts to make repairs a non-event. You might be flying a less-than-ideal aircraft design, but the consequences of your errors have a smaller impact overall which lets you keep testing.
The Mini-Me Test Bed
What if you’re a step up, and your aircraft is not meant to be low-cost to build? You probably don’t have the resources to make a small fleet of 100+ lb aircraft, and repairs and replacements can get costly. But can you make a lower-cost version?
This works great for vehicle designs that have unique, complex control logic for behaviors like VTOL hovers. You can test out new software developments, settings, and other changes on an aircraft that doesn’t have the purchase price of a small house. You may not be able to explore many aero questions, but for these larger aircraft it’s often the flight control software that is the riskiest subsystem.
One platform I worked on utilized this strategy: it had four electric motors for vertical launch, like a quadcopter, but once above the ground it set the main engine to full throttle and transitioned to forward flight. For landing it did the reverse, which was much more difficult. We had a mini version of the aircraft for testing: basically a foam hobby airplane with a scaled-down quad of motors taped on, and a fifth pointing backwards for the forward propulsor.
Before going on the full-sized airplane, any updates to the controls were tested on the mini version. The control logic was the same between the two aircraft, the numbers were just a little different, making this a really effective lower-risk way to validate code updates. Errors in the controls might have led to some unexpected landings, but it was a lot cheaper, easier, and honestly less demoralizing to fix the smaller testbed. And as a bonus, we could also use it for new operators’ first training flights, letting them get used to procedures and timing with much less pressure.
Arts and Crafts in the Tunnel
Trial and error in testing doesn’t even have to stick to flight testing. If you’re taking your vehicle to a wind tunnel test to get data on its current design, can you bring extra parts with you to play with some different options?
This is even easier if you’re using a machined scale model: the whole thing comes apart anyways, so why not duplicate a few components and adjust their design. The extra pieces add cost, but if you’re already paying for testing time and a full model anyways, the additional engineering insight might make the price worth it. When you already have the parts, taking an extra twenty minutes to try a different horizontal tail or wingtip you’re curious about often turns into a “well, why not?”
You can take this a step further: consider going to a lower-speed or less expensive tunnel to have even more freedom to explore the configuration. I’ve seen pieces of sheet metal turned into strakes or tail extensions in a quest to fix an aerodynamics problem. One test had engineers sculpting their model’s final curvature on the fly using clay.
The lower speed means smaller loads on the model, which means you can start to get creative with new parts and have more confidence they won’t come off. A number of low-speed tunnels are operated by universities as well, so they’re more lenient with arts-and-crafts experimentation than a large commercial tunnel might be. Your vehicle might cruise at transonic speeds, but testing at a slower tunnel first could help you solve major problems and get real-world feedback quickly (and for a lower cost).
These are just a handful of suggestions from my own experiences. But the big idea I want you to take away is a classic one: don’t let perfect stand in the way of good. Make decisions so you can continue to progress. Document things thoroughly, so you know why those decisions were made. Use iteration and testing as much as you can within the bounds of your project.
Doing this can provide more value than months of discussion and digital analysis. If we wanted to remove all chance of error, we would never fly our airplanes to begin with.