← Back to all work

Engineering case study · Aerospace & Autonomy · 2026

Aircraft 6-DOF Flight Dynamics Simulator

A from-scratch nonlinear six-degree-of-freedom rigid-body aircraft flight-dynamics simulator in Python, now extended with reusable trim, finite-rate actuators, fail-fast simulation guards, state-aligned reporting, and an adverse-yaw dynamics study with local modal analysis.

PythonNumPyFlight DynamicsControlRK4
DevelopmentActive
VerificationIn progress
EvidenceRecorded
Physical validationNot performed
ResearchActive research / control foundation

Central idea

What this system investigates.

A flight-dynamics model becomes a useful foundation for autonomy when its equations, assumptions, steady states, disturbances, numerical methods, and verification boundaries remain inspectable.

Problem

Why this system exists.

Most flight-simulation work can hide the underlying model behind a black-box engine. This project builds the nonlinear rigid-body formulation explicitly, then keeps extending the same canonical model with the analysis primitives needed for control: trim, actuator dynamics, reproducible disturbance models, numerical health checks, and local dynamics studies.

System architecture

How the system is organized.

  • Define aircraft state
  • Compute relative air data
  • Apply actuator dynamics
  • Assemble aero / thrust / gravity
  • Integrate nonlinear 6-DOF EOM
  • Analyze trim / modes / response
  • Export diagnostics

Implementation

Methods and engineering choices.

The simulator propagates a 13-state aircraft representation containing local NED position, body-frame velocity, body angular rates, and quaternion attitude. Aerodynamics are assembled from nondimensional stability/control derivatives; relative air velocity includes steady wind and gusts; forces and moments combine aerodynamics, propulsion, and gravity; actuator dynamics sit between commands and achieved deflections; and the equations are integrated with fourth-order Runge-Kutta while preserving quaternion normalization. A reusable trim solver and a dedicated adverse-yaw study now consume the same aircraft derivative instead of copying the physics.

Results and evidence

What the current record demonstrates.

  • Public from-scratch 6-DOF FDM with explicit translational and rotational equations of motion.
  • Quaternion attitude propagation with normalization and body/NED frame transformations.
  • Aerodynamic coefficient build-up includes longitudinal, lateral, directional, rate, and control-surface derivatives.
  • Atmosphere, steady wind, one-minus-cosine gust, and reproducible Dryden-style stochastic turbulence models are implemented.
  • The reusable trim API supports straight level, climb/descent, coordinated-turn, steady-sideslip, and straight-flight wind conditions; the canonical documentation reports typical convergence in 2–3 iterations near machine precision.
  • The adverse-yaw study reuses the canonical trim/simulation path, compares aileron-only and rudder-coordinated cases, sweeps rudder gain, decomposes yaw-moment contributions, and compares nonlinear response with local lateral-directional modal estimates.
  • Local study results report Dutch roll at -0.90 ± 3.74j 1/s, roll subsidence at -8.12 1/s, spiral at +0.020 1/s, and a 1.69 s nonlinear yaw-rate period against a 1.68 s linear prediction for the studied case.
  • Actuator/state history alignment, quaternion handling, gravity convention, and simulation health guards now have explicit regression/verification coverage.
  • The project runner still produces machine-readable CSV/JSON outputs and 16 core engineering plots for the standard simulation case.

Verification

Checks performed and their scope.

  • Verification now includes dedicated trim tests, actuator integration/response tests, adverse-yaw study regression coverage, quaternion invariance checks, and simulation health/divergence handling.
  • State-aligned actuator reporting prevents aerodynamic reconstruction from using the wrong surface deflection for a propagated state.
  • The historical ~2240.6 N·m pitching-moment event remains unresolved because its original state history is unavailable; it is not presented as solved.

Limitations

What this work does not yet establish.

  • Generic representative aerodynamic coefficients are not a validated aircraft-specific model.
  • The adverse-yaw study changes Cn_da to a plausible generic adverse value for mechanism demonstration; its specific numerical predictions are not aircraft-identification results.
  • No independent flight-test, wind-tunnel, CFD, or validated reference-simulator correlation has yet established physical predictive accuracy.
  • The historical 2240.6 N·m event remains unresolved because its original state history is unavailable.
  • Core nonlinear dynamics are reusable and tested, but closed-loop flight-control laws and RL environment integration are still future work.

Engineering decisions

Decisions that define the model boundary.

  • Kept the aircraft generic rather than presenting representative coefficients as a validated digital twin.
  • Used the canonical aircraft derivative as the shared physics path for simulation, trim, and studies rather than maintaining private copies of the equations.
  • Treat actuator rate limiting and lag as physical model behavior, not cosmetic signal smoothing.
  • Used quaternion attitude propagation and removed unnecessary q0 ≥ 0 sign forcing because q and -q encode the same physical attitude.
  • Added broad numerical health guards as fail-fast sanity checks, explicitly described as generic simulation limits rather than certification boundaries.
  • Keep study assumptions explicit: for adverse yaw, Cn_da = -0.03 is a plausible generic value selected to demonstrate the mechanism, not a flight-test or CFD identified coefficient.
  • Preserved unresolved anomalies and model-validation gaps as visible limitations instead of forcing a cleaner narrative.

A note from the build

What stayed with me.

Why I chose it

I wanted to understand what a flight simulator is doing underneath the plots, so I started with the equations instead of wrapping an existing engine.

What surprised me

One thing that caught me off guard was how a small timing or state-bookkeeping detail can distort what the plots seem to say. An older pitching-moment spike is still unresolved because its original state history is missing.

What I learned

I learned to trace results through the model, numerical integration and recorded state—and to leave an open question open rather than tidy it into a success story.

Next step

What I would investigate next.

Recover or reproduce the historical anomaly where possible, add independent reference-based validation cases, then build closed-loop control laws and expose the canonical simulator as a reproducible RL environment for aerospace autonomy experiments.

Source and related work

Inspect the implementation.