Flight Dynamics Toolkit — Stengel FLIGHTv2 Reproduction

This is not a new flight-dynamics model. Its contribution is making an established simulation easier to inspect, configure, test, reproduce, and extend without silently changing its numerical behavior.

The original FLIGHTv2 implementation is an established instructional flight-dynamics simulation, but its use of numerous global variables, hard-coded flight conditions, repeated aircraft-data reads during integration, and an undocumented legacy dependency made it harder to configure, test, reuse, and run in a student-accessible environment. The engineering task was to improve the software structure while deliberately preserving the underlying numerical model.

• Load a documented JSON flight scenario
• Construct aircraft and control-history data
• Evaluate the original aerodynamic and motion equations through modular components
• Solve the documented trim condition
• Integrate the flight with the configured numerical method
• Compare the refactored output against the original implementation
• Export plots and numerical results for inspection

The code is reorganized into classes and modules for the aircraft, control history, trim solver, flight simulation, equations of motion, kinematics, atmosphere, and helper functions. Scenario inputs are moved into JSON configuration, data construction is separated from execution, and the implementation is designed to work with licensed MATLAB and GNU Octave. Numerical behavior is checked against the original implementation using matching inputs rather than assuming that a clean refactor is automatically equivalent.

• Reorganizes Robert F. Stengel’s FLIGHTv2.m supplement into a configuration-driven and testable MATLAB/Octave project; the underlying model is credited to the original author.
• The repository documents zero absolute difference for tested pure-function layers including atmosphere, direction-cosine matrix, quaternion rotation, wind-field, and event helpers.
• Aircraft aerodynamic coefficient lookups are documented as matching the original AlphaModel.m and MachModel.m across a spread of tested states and controls.
• The equations-of-motion equivalence checks document zero absolute difference across 12 combinations of state, control history, and run mode.
• The trim solver reproduces the documented original trim point at 3,050 m and Mach 0.3 with zero absolute difference in the comparison recorded by the repository.
• A complete 30-second elevator-doublet run with 1,601 time steps is documented as matching the original trajectory with zero absolute difference in both Euler and quaternion modes.
• Portability decisions account for MATLAB/Octave differences, including class-property syntax, optional arguments, and the fact that matlab.unittest is not available in GNU Octave.

• Verification is based on running the original and refactored implementations with identical inputs and comparing numerical outputs, not merely reviewing source-code similarity.
• The repository documents function-level, trim, equations-of-motion, and end-to-end trajectory comparisons.
• The original implementation’s documented behavioral quirks are preserved when needed for equivalence and described rather than silently corrected.

• Numerical equivalence shows behavior preservation for the tested cases; it does not independently establish that the original physical model is correct.
• The toolkit is a restructured implementation of an established educational model, not a novel flight-dynamics formulation or an aircraft-specific validated digital twin.
• The documented comparisons do not replace independent physical validation against flight-test, wind-tunnel, CFD, or another independently validated aircraft model.
• The test-suite framework differs by environment: MATLAB uses matlab.unittest, while Octave equivalence is checked through direct comparison runs.
• The original model’s assumptions and limitations remain relevant even where the refactor reproduces its outputs exactly.

• Preserve the original physics and numerics; focus the work on structure, configuration, portability, and verification.
• Replace extensive global state with explicit objects and module boundaries so aircraft data and control history are easier to reason about.
• Move flight conditions into JSON scenarios rather than editing the simulation entry point to change conditions.
• Avoid loading aircraft lookup data from disk inside every integration step.
• Keep known behavior quirks documented rather than turning a refactor into an unreviewed model change.
• Attribute the underlying equations, aerodynamic model, and simulation architecture to Robert F. Stengel.

Keep the original-equivalence tests reproducible across supported environments, improve scenario and test documentation, and use the toolkit as a transparent reference alongside the from-scratch 6-DOF simulator when comparing modeling choices and numerical behavior.

Explore all engineering work →