JSBSim: the open source flight dynamics model under a lot of simulators
An open source flight dynamics & control software library
At a glance
- What is it?
- A C++ flight dynamics library with an Earth model built to WGS84 and the 1976 standard atmosphere, wrapped in Python, Matlab and Unreal Engine bindings, and validated against six NASA tools in 2015.
- Who is it for?
- JSBSim earns its position by being the flight dynamics layer that nobody has to own. It computes six-degree-of-freedom motion with Coriolis and centrifugal terms, WGS84 geodetic coordinates and a 1976 standard atmosphere, and then gets out of the way: aircraft are XML, output goes to screen, file or socket, and Python, Matlab and Unreal bindings all reach the same engine.
- Can I use it commercially?
- Yes, with conditions. LGPL-2.1 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 10 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 28, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The physics and math model, and nothing else
The README defines the scope precisely and it is worth reading before you install anything. JSBSim is a multi-platform, general purpose, object-oriented Flight Dynamics Model written in C++. The FDM is the physics and math model that defines the movement of an aircraft or a rocket under the forces and moments applied to it by the control mechanisms and by the forces of nature.
That definition also tells you what the library is not. There is no rendering, no terrain, no audio, no traffic. It is the part of a flight simulator that answers the question of where the vehicle is and where it is going, given a control input and the atmosphere around it.
The README describes two ways to run it. There is a standalone batch mode flight simulator with no graphical display, console mode, intended for testing and study. And there is integration with the Unreal engine, FlightGear and many other simulation environments. Both are first-class, which is why the repository contains a console entry point and a plugin at the same time.
The features list names nonlinear six-degree-of-freedom motion, a fully configurable flight control system, aerodynamics, propulsion and landing gear arrangement all driven through an XML-based text file format, and configurable data output to screen, file, socket or any combination. The XML point is the key architectural decision and it is what makes the library usable at all: an aircraft is a data file, not a subclass.
The Earth model is where the precision claims come from
The Earth model is the bulleted item that distinguishes this from a simpler physics engine, and the three sub-points are specific enough to check.
First, rotational effects on the equations of motion are modeled, meaning Coriolis and centrifugal acceleration are included rather than neglected. For a small aircraft at low altitude and short flight times this barely moves the answer, but for long-range navigation, for launches and for anything near the equator it is not optional.
Second, the shape of the Earth is an oblate spheroid and coordinates are geodetic according to the WGS84 system. Using geodetic rather than geocentric coordinates means altitude is measured above the ellipsoid, which is what altitude in aviation actually is.
Third, the atmosphere follows the International Standard Atmosphere published in 1976. That is a piecewise layered model up to 86 kilometres, and it is the reference against which most aircraft performance data is quoted. Building it in rather than approximating density with a formula means simulated engine thrust and lift curves line up with published figures for the same conditions.
None of this is exotic research code. It is a careful implementation of published reference models, which is exactly the property you want in something that will be used as a plant model for a controller.
Python, Matlab and Unreal bindings all reach the same engine
The README lists three bindings and makes a specific claim about the first one: the Python module provides the exact same features as the C++ library, with Python simulation samples that can be run on Google Colab.
The distribution story is broad. Badges at the top of the README point at PyPI, a Conda channel, and a Zenodo DOI, which together mean the library is citable, installable by pip or conda, and archived with a persistent identifier. The v1.3.1 release notes spell out the artifacts: a Windows installer compiled with Visual Studio Enterprise 2022, Debian packages for Ubuntu Jammy 22.04 and Noble 24.04 on amd64, and Python wheels on PyPI.
pip install jsbsimThe Matlab side is an S-Function that interfaces with Simulink, which is the path used in a lot of control research because the controller being tested lives on the other side of the boundary. The Unreal side is a plugin that connects the flight dynamics model to the entire virtual environment provided by the engine. The repository tree backs all three up: `python/`, `matlab/` and `UnrealEngine/` sit alongside `src/` and `engine/`, and there is a separate `JSBSimForUnreal.sln` with `.vcxproj` files and shell scripts for building the Unreal plugin on Linux and Mac.
That last detail is more than housekeeping. Building a native plugin against two engine versions on three platforms is the part of integration that eats time, and the repository ships the project files so you do not have to reconstruct them.
Who actually runs on this, from autopilot SITL to reinforcement learning
The README's applications list is the strongest evidence of fitness, because it names projects whose users would switch to something else if the physics were wrong.
Flight simulation: FlightGear, OutTerra and Skybolt Engine. Software in the loop autopilot testing: ArduPilot, PX4 Autopilot and Paparazzi, all three of which document their JSBSim SITL setup publicly. That last group matters most, because an autopilot development loop needs a plant model that runs headless, fast and deterministically, which is precisely what batch mode is.
Unreal Engine's Antoinette Project lists JSBSim as the tool for creating the next generation of flight simulators. PteroSim runs every vehicle type, multirotors, helicopters, VTOLs, tailsitters and fixed-wing, on JSBSim with PX4 or ArduPilot SITL in the loop and a Python API, and Epic covered it in an Unreal Engine spotlight. Project AirSim, which Microsoft recognizes as the evolution of AirSim, integrates JSBSim for fixed-wing dynamics with public Cessna 310 and Skywalker X8 examples.
The DARPA Virtual Air Combat Competition is the entry that reads like a story and is a real use case: one of the AI went undefeated in five rounds of mock air combat against an Air Force fighter. And gym-jsbsim wraps the engine as a reinforcement learning environment for aircraft control, which is the same research trajectory the README's academic section describes, citing more than a thousand Google Scholar references as of May 2025 and a 2023 paper on deep reinforcement learning for high-performance aircraft that used the Matlab interface.
The 2015 NASA check cases, and what they do and do not prove
The README cites a specific verification exercise: in 2015, NASA ran verification check cases on seven flight dynamics software including JSBSim, the other six being NASA in-house tools. The quoted result is that the seven tools were good enough to indicate agreement between a majority of simulation tools for all published cases, with most remaining differences explained and reducible with further effort.
Read that carefully. It is a cross-comparison, not a truth test. It tells you JSBSim agrees with six other professional tools on published cases, which rules out gross modelling errors. It does not tell you the model matches a specific airframe in every regime, and it is now more than a decade old.
What the repository does offer is the machinery behind such a comparison. There is a `check_cases/` directory, a `tests/` directory, `data_output/` for the configurable output formats, `utils/` and `scripts/`, and `codecov.yml` at the root. The XSD files at the top level, `JSBSim.xsd`, `JSBSimCommon.xsd`, `JSBSimScript.xsd` and `JSBSimSystem.xsd`, with matching `.xsl` files, define the schema for the XML configuration format. That schema is the real user-facing contract, and having it versioned means a malformed aircraft definition can be caught by a validator rather than by a silent zero in the output.
The `systems/` and `aircraft/` directories are where you will spend the most time. `aircraft/` is a library of aircraft definitions, and the quality of your simulation is bounded by the quality of the model you load. There is also `joss_paper/` and a `CITATION.cff`, which means the project is a citable piece of research software rather than only a tool.
Version 1.3.1, an active licence, and three recent releases
Three releases are visible and they are recent and close together: v1.2.4 on 2026-02-07, v1.3.0 on 2026-04-09 and v1.3.1 on 2026-05-17. The last push to master was 2026-09-26. For a simulation library that has existed since the 1990s and is used by flight sims, autopilot toolchains and research groups simultaneously, that is an active project.
The release notes themselves are short and mostly about artifacts rather than features, which suggests the interesting changes are in the commit history rather than in the release text. The version number is past 1.0 but the project still describes itself as a general purpose FDM rather than promising API stability, so read the changelog before upgrading a controller that depends on specific channels.
The licence is LGPL-2.1, which is the right choice for this kind of library and has one consequence worth stating. If you link JSBSim dynamically into your simulator, your obligation is limited to making the library and its modifications available. If you statically link it into a binary you distribute, you have more to think about. For research, internal tooling and most simulator projects the dynamic case is the common one and it is unproblematic.
The repository also carries `COPYING`, which holds the LGPL text, plus `AUTHORS`, and the build system is CMake at the root with `CMakeLists.txt`. There is a Windows Installer Definition, `JSBSim.iss.in`, for the Windows build and a `JSBSim.pc.in` template for pkg-config, so the Unix packaging was done deliberately rather than left to whoever needed it first.
Editorial conclusion
JSBSim earns its position by being the flight dynamics layer that nobody has to own. It computes six-degree-of-freedom motion with Coriolis and centrifugal terms, WGS84 geodetic coordinates and a 1976 standard atmosphere, and then gets out of the way: aircraft are XML, output goes to screen, file or socket, and Python, Matlab and Unreal bindings all reach the same engine. Three things to settle before you commit. The library was verified by NASA in 2015, which is old enough that you should read the current test corpus in `check_cases/` and `tests/` rather than lean on that result alone. Licence is LGPL-2.1, so dynamic linking keeps your obligations light but a static build into a shipped product needs care. And the aircraft library under `aircraft/` is only as good as the individual models, so the fastest way to evaluate this is to load a model you already know and check its trim numbers before writing any integration code.
Frequently asked questions
What is the JSBSim flight dynamics model?
It is the physics and math layer of a flight simulator: a C++ library that computes where an aircraft, rocket or other vehicle moves to under control inputs and environmental forces. It runs headless in batch mode for testing, or is integrated into a graphical environment such as Unreal Engine or FlightGear. It contains no rendering or terrain, only the motion model.
What can I use JSBSim Python for?
The Python module provides the same features as the C++ library, with sample simulations that run on Google Colab. Wheels are on PyPI and can be installed with `pip install jsbsim`. It is used this way for software in the loop autopilot testing with ArduPilot and PX4, and as the plant model behind reinforcement learning environments such as gym-jsbsim.
Does JSBSim include rendering and a cockpit view?
No. JSBSim is the flight dynamics model only, and the README is explicit that it runs as a standalone console-mode simulator for testing and study, or integrated with an environment that supplies rendering. For visuals, you pair it with FlightGear, Unreal Engine via the bundled plugin, or another simulator front end.
How accurate is JSBSim compared with other flight simulators?
In 2015 NASA ran verification check cases across seven flight dynamics tools including JSBSim and six NASA in-house tools, and reported agreement across the published cases with remaining differences explainable. That establishes it is not grossly wrong. Aircraft accuracy still depends on the specific model you load, since `aircraft/` holds definitions contributed over many years and they differ in how closely they match a real airframe.
Which autopilots support JSBSim for simulation?
ArduPilot, PX4 Autopilot and Paparazzi all document JSBSim for software in the loop testing. PteroSim builds on that by running PX4 or ArduPilot SITL against JSBSim in Unreal Engine 5 with a Python API, and Project AirSim uses it for fixed-wing dynamics with public Cessna 310 and Skywalker X8 examples.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/jsbsim-team-jsbsim)