How does FlightGear's flight dynamics model work?

FlightGear does not use one universal flight dynamics model. Each aircraft selects a dynamics engine—usually JSBSim or YASim—which takes control inputs, aircraft data and atmospheric conditions, calculates aerodynamic, propulsion and ground-contact forces, then numerically integrates six-degree-of-freedom equations to update the aircraft's position, attitude and velocity.

What happens during each FlightGear simulation step?

Each dynamics step converts pilot commands and the aircraft's existing state into forces and moments, then into a new state.

When an aircraft loads, FlightGear reads its mass, centre of gravity, moments of inertia, aerodynamic definition, engine data and landing-gear contact points. These flight-model files are separate from the visible 3D model.

1. Read the state and controls. The engine receives position, attitude, velocity and rotation rates along with stick, rudder, throttle, trim, flap and gear commands. Depending on the aircraft, commands may pass through FlightGear systems or an FDM-defined flight-control system first.
2. Obtain the environment. The calculation uses air density, pressure, wind, terrain elevation and other relevant environmental properties. Gravity and atmospheric values are either supplied or derived by the selected engine.
3. Calculate aerodynamic loads. Airspeed, angle of attack and sideslip are combined with dynamic pressure, expressed as q = ½ρV², and the aircraft's aerodynamic data. This produces lift, drag, side force and roll, pitch and yaw moments.
4. Add propulsion and ground forces. Engines, propellers or rotors contribute thrust and torque. Tyres, struts, brakes and runway contact add forces while the aircraft is on the ground.
5. Integrate the equations of motion. All forces and moments are summed, then the six-degree-of-freedom equations are advanced by one time step to determine new velocities, rotation rates, attitude and position.
6. Publish the result. FlightGear places the updated values in its property tree, where the instruments, visual system, sounds and aircraft systems can use them.

This is the same underlying process covered in our explanation of how a flight dynamics engine handles forces, moments and six-degree-of-freedom integration. Rendering and flight dynamics are separate jobs, although severe performance problems can still starve the simulator as a whole.

Which flight dynamics engine does FlightGear use?

FlightGear uses the engine selected by the aircraft package, rather than forcing every aircraft through the same model.

The term FDM can mean either the software engine or an individual aircraft's data. They are distinct: JSBSim is an engine, while the coefficient tables, mass properties and propulsion definition supplied for a particular aircraft form its model.

A mistake we see often is treating JSBSim and YASim as quality presets. They are not interchangeable modes, and changing the selected engine will not automatically improve an aircraft. A JSBSim package normally lacks the YASim definition it would need, and vice versa.

Our technical overview of FlightGear's pluggable FDM design gives broader context for why the simulator supports several engines rather than one fixed solution.

Does FlightGear calculate aerodynamics from the 3D model?

No. FlightGear does not normally derive flight behaviour from the aircraft's visible mesh.

JSBSim reads aerodynamic data prepared by the aircraft author. YASim uses its own simplified geometry definition, not the detailed cockpit and exterior mesh drawn on screen. Neither approach is real-time computational fluid dynamics.

Changing a wing's visible shape therefore changes only its appearance unless the FDM data is changed as well. Ground effect, propwash, compressibility, icing, damage and unusual stall behaviour must also be represented by the flight model or connected aircraft systems; FlightGear cannot infer them from the artwork.

Is JSBSim or YASim more realistic?

Neither JSBSim nor YASim is inherently more realistic; the quality and validation of the individual aircraft model matter more than the engine name.

• Mass and balance: Empty weight, payload stations, fuel distribution, centre of gravity and moments of inertia must be credible.
• Aerodynamic coverage: The data should cover more than one trimmed cruise point. Stall, sideslip, control effectiveness and high-speed behaviour expose weak models quickly.
• Propulsion: Engine power or thrust, propeller response, fuel flow and altitude effects need suitable modelling.
• Control systems: Trim, actuator limits, stability augmentation and autopilot coupling can change how the same aerodynamic model feels.
• Validation: Authors should compare climb, cruise, take-off, landing and handling behaviour with dependable performance or flight-test data where available.

Models are often strongest inside the flight envelope used during tuning. Behaviour beyond the available coefficient tables or design constraints may rely on extrapolation. We cover the aircraft-specific factors that decide FlightGear realism separately.

How can I tell which FDM an aircraft uses?

The main aircraft definition and FlightGear's startup log normally identify the selected flight dynamics engine.

1. Open the aircraft package. Find its main *-set.xml file inside the aircraft's folder.
2. Search for the flight-model entry. An entry containing jsb, yasim or another engine name identifies the requested FDM. Nearby references usually point to the associated aerodynamic file.
3. Check the startup messages. FlightGear generally reports the model being loaded and records missing files or XML parsing failures. Exact wording and log location vary between installations.

The FDM label does not describe every part of the simulation. Aircraft scripts and FlightGear systems may still manage controls, fuel, failures, instruments or other behaviour around the core dynamics engine.

Common FDM problems and fixes

Most apparent flight-model faults come from control assignments, loading conditions or incomplete aircraft files rather than the numerical engine itself.

• Every aircraft pulls or rolls: Centre and calibrate the controller axes, remove duplicate bindings and check that trim or an autopilot is not applying an input.
• One aircraft behaves incorrectly: Restore the complete aircraft package instead of mixing configuration files from different releases. Look in the startup log for missing FDM files and XML errors.
• The aircraft departs immediately: Check fuel, payload, centre of gravity, trim and the chosen starting state. An extreme loading condition can place the model outside its valid envelope before it moves.
• Hand edits cause violent motion: Recheck units, axis signs, reference points and coefficient conventions. A small error in centre-of-gravity position or pitching-moment data can generate a very large response.
• Only extreme manoeuvres look wrong: The aircraft may lack data for that part of the envelope. Switching engines is not a repair; the underlying aircraft model needs better data or tuning.

A useful isolation test is to repeat the same conditions with a well-behaved aircraft. If only one package fails, investigate that aircraft's files and loading. If every aircraft fails in the same way, check controls, weather and the FlightGear installation first.