Microsoft AirSim: What the Open Source Autonomous Vehicle Simulator Actually Does

The gap AirSim fills between a game engine and a flight controller

Robotics work usually splits into two unsatisfying halves. A physics-only simulator gives you clean state vectors and no believable camera. A game engine gives you a believable camera and no vehicle dynamics you can trust. AirSim is built to sit between them. The README describes it as a simulator for drones, cars and more, built on Unreal Engine, with an experimental Unity release alongside. It is packaged as an Unreal plugin that can be dropped into an existing environment, which is the important detail: the project does not ship one canonical world. It ships the vehicle, the sensor models and the API, and expects you to bring the scene.

The audience follows from that. The stated goal is to be a platform for AI research into deep learning, computer vision and reinforcement learning for autonomous vehicles. If you are training a perception model and need labelled depth or segmentation frames aligned with pose, or if you are testing a controller against PX4 or ArduPilot in software-in-the-loop before touching hardware, that is the intended use. If you want a turnkey driving game, this is the wrong shape of tool.

How the AirSim plugin talks to your code

The architecture has three layers, and the repository layout makes them visible. AirLib/ holds the vehicle models, sensor simulation and physics abstraction. Unreal/ and Unity/ hold the engine plugins that render and step the world. PythonClient/, DroneServer/, DroneShell/ and MavLinkCom/ hold the client side. The README states that APIs are exposed through RPC and are accessible from C++, Python, C# and Java, which is why the same script can drive a simulated drone and later run on a companion computer on the real vehicle. That portability is the design bet: write and test against the simulator, then move the client code to hardware.

The data flow is request and response. Your script calls an RPC method to get an image, a state vector or a lidar scan, or to send a velocity or position command. The plugin steps the Unreal world, renders the sensor, and returns the result. MavLinkCom exists because PX4 and ArduPilot speak MAVLink, so the simulator can present itself as a vehicle those stacks recognise. For pure vision work there is a Computer Vision mode where, per the README, there are no vehicles or physics at all: you move a camera by keyboard or API and collect depth, disparity, surface normals or object segmentation. That mode is the cleanest fit for dataset generation, and it also removes the flight dynamics you would otherwise have to fight.

Getting AirSim on Windows or Linux and pointing it at a first script

The README splits installation by platform. Windows and Linux each offer two routes: download precompiled binaries from the releases page, or build from source using the build_windows and build_linux documentation pages. macOS is listed as build-only, with no binary download offered. If you only want to try the API, take the binary path, because building against a specific Unreal Engine version is the expensive part. The repository also carries build.sh and install_unreal.sh at its root, and the README points at the use precompiled binaries document under docs/use_precompiled.md for the binary route.

The README does not print a Python install command, so the concrete step it does give is the API description: RPC methods reachable from C++, Python, C# and Java. The repository layout shows the Python client in PythonClient/, and the README's own tutorial list points to the reinforcement learning page and to a TensorFlow collision avoidance example for worked code. Start there rather than guessing at a package name.

What the README does specify is how to stop being prompted for a vehicle on every launch. It points at the SimMode setting, and at Computer Vision mode, so the simulator starts in the configuration you want. A settings file in your Unreal project's config directory controls this:

{
  "SettingsVersion": 1.2,
  "SimMode": "ComputerVision"
}

With SimMode set to ComputerVision, the scene starts with no vehicle and no physics, which is what you want for camera-only data collection. For data capture the README gives two routes. Press the record button in the lower right corner and it starts writing pose and images for each frame, and the logging code is simple enough to modify. The API route gives finer control over what is captured and when. Weather is a third switch: press F10 for the weather options, or drive them through the weather APIs, and press F1 for the other in-simulator options.

Where AirSim stops being the right tool

The release history is the first constraint. The listed releases are v1.8.1 for Linux and Windows from July 2022, plus v1.8.0 and its Windows build from June 2022. Nothing newer appears in that list, even though the repository's last push is 2026-06-30. A project can receive commits without cutting releases, and that is what the two facts together suggest. It means you should not expect a stream of tagged versions to pin against, and you should read CHANGELOG.md rather than assuming a binary on the releases page reflects the current main branch.

The second constraint is the engine coupling. Because AirSim is an Unreal plugin, your simulation is only as portable as your Unreal project. Upgrading the engine can invalidate the plugin build, and the README does not document a rollback path for that. Teams that need a simulator they can install from a package manager and run headless in CI will find the Unreal dependency heavier than they want.

The third is scope. AirSim simulates vehicles and sensors. It does not give you a traffic system, a scenario description language, or a standardised benchmark suite. If your question is how a planner behaves across thousands of scripted urban scenarios, you are building that harness yourself on top of the API. And the Unity release is described in the README as experimental, so treat it as a secondary target rather than a supported equal.

AirSim against CARLA, and what the difference costs you

CARLA is the obvious comparison for anyone working on self-driving perception, and the split is about what each project treats as fixed. CARLA ships an urban driving world and a scenario runner: the environment is the product, and you write agents against it. AirSim ships the vehicle, the sensor models and the API, and expects you to supply the environment as an Unreal project. That inverts the work. With AirSim you spend time on world building and get to reuse any Unreal scene you already have; with CARLA you spend time on agent code and accept the world you are given.

The second difference is the vehicle range. AirSim covers drones and cars in one API surface, with PX4 and ArduPilot integration through MavLinkCom, so a team working on both aerial and ground vehicles keeps one client library. CARLA is a driving simulator, and its dynamics are tuned for cars. If your project is a drone, that difference decides the choice on its own.

Maintenance, licensing and the cost of an upgrade

The repository is not archived, and its last push was on 2026-06-30, so the code is being touched. That is not the same as shipping. With the newest listed release at v1.8.1 from July 2022, anyone who pins to a release is pinning to something four years old, and anyone who tracks main is tracking untagged code. Budget for reading commits rather than release notes.

The licence file is present at the repository root, but the metadata reports it as NOASSERTION, meaning the automated classifier could not map it to a standard identifier. That is a practical problem for anyone whose legal review keys off an SPDX string: you will need to read LICENSE yourself rather than rely on a tool's summary. The README also asks that the FSR 2017 paper be cited in academic work, and gives the BibTeX entry, which is a norm rather than a restriction.

Upgrade cost concentrates in two places. The client libraries sit in PythonClient/ and the other client directories, so client changes arrive with a pull. The plugin side is the expensive half, because it is compiled against a specific Unreal Engine version. Check cmake/ and the build documentation pages before assuming a newer engine will take an older plugin.

Editorial conclusion

Adopt AirSim if your work needs a vehicle that responds to physics and a camera that returns depth, disparity, surface normals or object segmentation on demand, and you can commit to an Unreal Engine build. Do not adopt it if you need a supported release cadence: the newest releases listed are v1.8.1 for Linux and Windows, both from July 2022, and the README points contributors at open issues rather than a roadmap. Verify two things first: whether a precompiled binary exists for your platform on the releases page, and whether your scene is already an Unreal project, because the plugin is meant to be dropped into one rather than generated from scratch.

Frequently asked questions

Official sources

1. Issues
2. microsoft/AirSim on GitHub
3. Project website
4. README
5. Releases