From Simulation to First Flight: The Real Workflow

A design can be flawless in simulation and still surprise you on the pad. The workflow between those two moments is where reliability actually gets built.

An engineering team spent three months in flight dynamics simulation tuning an octocopter's control loops before a single motor had ever spun for real. The airframe used coaxial motor pairs, two motors stacked on each of four arms, the same X8 layout this series covered a few posts back for its propulsion redundancy. The simulated aircraft flew beautifully: clean step responses, stable hover, no overshoot worth mentioning. On the pad for its first real hover, the airframe immediately began a low-frequency wobble the simulation had never shown. The cause turned out to be a structural resonance between the frame and the flight controller's mounting, driven by the extra vibration coupling between each coaxial motor pair, something no flight dynamics model had been asked to represent, because it was never a flight dynamics problem in the first place. It took a physical vibration test, not another round of simulation, to actually find it.

That gap between a perfect simulation and a surprising first flight is not a sign the simulation was wrong. It is a sign that simulation was only ever meant to answer one part of a much longer question. The real path from a design file to a working aircraft runs through several distinct validation stages, each one built to catch a different category of failure, and understanding what each stage can and cannot see is what keeps a surprise like that octocopter's wobble from becoming something worse. This post picks up where the last chapter left off, moving the series from how a design should be shaped to what actually happens once that design leaves the drawing board.

It is tempting to think of the path from CAD file to flying aircraft as a single pipeline: design it, build it, fly it. In practice it is a chain of checkpoints, each one narrower and more expensive to fail at than the last. A software bug caught in simulation costs a few minutes to fix. The same bug caught during a tethered hover costs a damaged prop. The same bug caught during an untested first free flight can cost the airframe. The workflow exists to make sure failures get caught as early and as cheaply as possible, and skipping a stage does not remove the failure it would have caught. It just moves that failure to a more expensive place to find it.

None of this is about being risk averse for its own sake. A team that skips straight to a free flight isn't taking on one risk, they are taking on every risk every earlier stage was built to filter out, all at once, in front of a real aircraft with real consequences if something goes wrong.

Every validation stage catches a specific category of failure. Skip one, and whatever it would have caught doesn't disappear. It just waits for a later, more expensive stage to find it instead.

Picture the workflow as a funnel of increasing consequence. At the wide end, a bug or a bad parameter costs nothing more than a crashed simulation and a few minutes of debugging. At the narrow end, the exact same mistake costs a real airframe. Each stage between those two ends exists to filter out failures before they reach a more consequential one: software-in-the-loop simulation filters out control logic and software bugs with zero hardware at risk, hardware-in-the-loop testing filters out firmware and timing issues that pure software simulation cannot see, bench and ground testing filters out physical integration problems, and a tethered or short hop hover filters out the real-world surprises that no simulation, however good, was ever going to predict.

The mistake most first-time teams make is treating simulation as the expensive, rigorous part of the process and the physical stages as a formality on the way to the real test. It works the other way around. Simulation is cheap precisely because it cannot see everything, which is exactly why the physical stages exist and why none of them are optional just because the simulation looked clean. A team that spends three months polishing a simulation and three days on physical validation has the ratio backwards, not because the simulation work was wasted, but because it was never the stage most likely to catch the failure that actually shows up on the pad.

The two simulation stages sound similar but catch different things. Software-in-the-loop, or SITL, runs the actual flight stack, PX4 or ArduPilot, entirely on a development computer against a physics simulator like Gazebo or jMAVSim, with no flight controller hardware involved at all. It is where control loop tuning and flight logic get validated first, because a bad PID gain or a logic error in a failsafe crashes a simulated aircraft instead of a real one. Hardware-in-the-loop, or HITL, moves the same firmware onto the actual flight controller board, connected to the simulator over USB instead of running purely in software. That step exists because a control loop that behaves correctly in pure software can still behave differently once it is running on the real processor, with real timing and real interrupt handling, and HITL is often where those integration problems surface first, well before a propeller ever needs to spin.

Once the firmware has cleared both simulation stages, the aircraft itself needs its own round of validation before it leaves the ground. Motors and ESCs get bench tested under load to catch a bad solder joint or a mismatched motor before it fails in the air. Propellers get balanced, because an imbalanced prop introduces vibration at a frequency that can interfere with the IMU's readings in ways no simulation modeled, which is close to what happened to the octocopter in the introduction. A simple quadcopter's bench test mostly stops there, one motor and one prop per arm to check. An octocopter built with coaxial motor pairs needs an extra pass: each pair has to be checked for cross-coupling vibration between the upper and lower motor on the same arm, which is exactly the kind of interaction a flight dynamics simulation has no reason to model and a bench test is built to catch. Sensor calibration gets verified on the actual airframe too, not just in the lab, because a magnetometer that reads clean on a bench can pick up interference once it is mounted a few centimeters from a power distribution board carrying real current. Only after the aircraft has cleared its bench tests does it fly for the first time, and even then, an experienced team keeps that first flight tethered or limited to a short hop within reach of the kill switch, because a real aircraft can still surprise you in ways a simulated one, and a benched one, cannot.

Vibration deserves a closer look than the other bench checks, because it is the one physical issue that keeps paying interest long after it is first noticed. Both major flight stacks, PX4 and ArduPilot, log raw accelerometer and gyroscope data during a short test hover, typically no more than thirty seconds of hovering with some gentle roll and pitch thrown in, and that log gets run through a Fast Fourier Transform to turn it into a frequency spectrum. A clean spectrum is quiet across the board. A noisy one shows sharp spikes at the motor's blade-pass frequency and its harmonics, which is the signature of exactly the kind of resonance that caused the octocopter's wobble. Both stacks also offer dynamic notch filters that can automatically cancel a spike at that frequency, using either the ESC's own RPM telemetry or the FFT reading itself to track it.

The part worth sitting with is what a notch filter actually does and does not fix. It cleans up the signal the control loop sees. It does nothing to the loose motor mount, the unbalanced propeller, or the resonant frame section that produced the vibration in the first place. PX4's own tuning documentation is direct about this: high vibration should be fixed in the vehicle's hardware, not papered over with filter tuning. An airframe that quietly relies on a notch filter to fly smoothly is still shaking exactly as much as it was before the filter was added, and that shaking keeps loosening fasteners, fatiguing mounts, and wearing motor bearings for every flight hour that follows. The crash it eventually causes, months later, is far harder to trace back to its root cause than the FFT spike would have been on day one.

A flight-ready simulation means the control logic is sound. It says nothing about vibration, structural resonance, or a sensor behaving differently mounted on a real airframe than it did in a model. Those only show up once the aircraft is physically real.

The most common failure in this workflow is not any single stage going wrong. It is a team skipping straight from a clean simulation to an untethered first flight, because the simulation looked so solid that the intermediate physical stages felt like bureaucracy rather than engineering. That instinct is understandable and it is exactly backwards. A simulation is a model, and a model is only as good as what its author thought to represent. The octocopter's frame resonance was not a bug in the flight dynamics simulation. It was a category of failure the simulation was never asked to model at all, and no amount of additional simulation time would have caught it. Only a physical stage could. A simpler quadcopter without coaxial motors would have had one less thing to check on the bench, but it would still have needed the same bench, because the failure category the workflow guards against is not specific to any one airframe layout.

Experienced teams treat the tethered hover as the point where the simulation's confidence actually gets tested against reality, not as a formality to clear on the way to the real flight. It is often the single most information-dense few minutes in the entire development cycle, because it is the first moment the aircraft is simultaneously real and still recoverable if something goes wrong.

This is also why the workflow does not compress well under schedule pressure. A team behind on a launch date is tempted to treat the physical stages as the ones to trim, since they feel slower and less glamorous than another week of simulation refinement. That instinct gets the risk backwards. Simulation time is cheap precisely because a simulated crash costs nothing, which means it is exactly the stage where extra time is safest to spend, and exactly the stage least worth cutting corners on to save a week.

Software teams learned this same lesson long before UAS engineers did. A staging environment mirrors production as closely as a team can manage, and code that passes every staging test still sometimes breaks in front of real users, because staging is a model of production, not production itself. That is exactly why mature engineering teams do not go straight from staging to a full rollout. They ship to a small slice of real traffic first, a canary release, specifically to catch the category of problem staging was never going to reveal. A tethered hover is a UAS team's canary release: the smallest possible exposure to reality, kept short and recoverable, before committing to the real thing. Neither team is being overly cautious. Both have simply learned that the model and the real thing diverge in ways you cannot predict from inside the model.

The path from a design file to a flying aircraft is not one pipeline, it is a chain of validation stages, each one catching a category of failure the previous stage could not see.

• Skipping a validation stage does not eliminate the failure it would have caught. It moves that failure to a later, more expensive stage to discover
• SITL validates control logic and software with no hardware at risk. HITL validates that same firmware against real timing and real hardware behavior
• Bench testing catches physical integration faults and calibration issues, and vibration deserves the closest look of all of them, since it keeps compounding for every flight hour that follows
• A notch filter that quiets a vibration spike does not fix what is causing it. Unresolved vibration keeps fatiguing mounts and wearing bearings until it surfaces later as a much harder failure to trace
• The biggest risk in this workflow is treating a clean simulation, or a filtered flight log, as a green light to skip fixing what the physical stages actually found

Once an aircraft has cleared every stage in that funnel, the flight controller takes over the real work: turning raw sensor data into a stable, controllable aircraft in real time, moment by moment, for the length of the flight. Understanding what that box is actually doing, and where its sensing and decision-making can fail, is where this series goes next.

Curious to exchange some ideas? Reach out via the contact form or connect on Linkedin!