aerial_gym_simulator: training thousands of multirotors on the GPU with Isaac Gym

A simulator built for parallel MAV training, not for one drone

The Aerial Gym Simulator is described in the README as a high-fidelity physics-based simulator for training Micro Aerial Vehicle platforms such as multirotors to learn to fly and navigate cluttered environments using learning-based methods. The environments are built on NVIDIA Isaac Gym.

The unit of work here is the fleet, not the vehicle. The README says the simulator is designed to simulate thousands of MAVs simultaneously, and that it provides parallelization for the simultaneous control of hundreds of thousands of multirotor vehicles, with the low-level and high-level geometric controllers residing on the GPU. Robot models are offered for standard planar quadrotors as well as fully actuated platforms and multirotors with arbitrary configurations.

Two categories of user fit this. A reinforcement learning researcher who needs many parallel environments to collect samples quickly will recognise the value of GPU-resident controllers, since the classic bottleneck in MAV learning is the physics stepping rate of a CPU simulator. A controls engineer who wants to validate a geometric controller on realistic multirotor configurations gets a different benefit from the same design.

The robot models are chosen to mirror hardware rather than to abstract it. The README states the low-level and high-level controllers that ship with the simulator are also the kind used on real-world systems, which is the reasoning behind including both fully actuated platforms and arbitrary multirotor configurations rather than a single canonical quadrotor.

The README claims sub-minute training and sub-hour vision training

The README makes two timing claims, and they are worth quoting precisely rather than paraphrasing, because they are claims about the README, not measurements made here. It says the Aerial Gym Simulator allows you to train state-based control policies in under a minute, and to train vision-based navigation policies in under an hour.

The gap between those two numbers is itself informative. State-based control means the policy sees the vehicle state directly, so the environment has to produce observations but not images. Vision-based navigation means every step involves rendering, which is where the custom rendering framework earns its keep.

The mechanism behind the speed is the one described in the features list: parallelized geometric controllers that reside on the GPU. When the controller computation for thousands of vehicles runs on the GPU rather than in a Python loop, the bottleneck moves from control computation to physics and rendering, which is a very different profile.

The second version of the simulator is what these numbers describe. The README says this is the second release, that it was rewritten from the ground up to offer very high control over each of the simulation components, and that the optimized code in the newer version is what allows the sub-minute and sub-hour training figures. Anyone benchmarking against the older version would be comparing against a different codebase.

Warp-based ray casting produces depth and segmentation for LiDAR and cameras

Sensors are where a MAV simulator becomes opinionated, and this project's opinion is that sensors should be ray casting based and customizable.

The README lists GPU-accelerated and customizable ray-casting based LiDAR and camera sensors with depth and segmentation capabilities, and explains the technology behind them as a custom rendering framework based on NVIDIA Warp, used to design custom sensors and perform parallelized kernel-based operations. The documentation links to a Warp sensors section for the details.

Why this matters for a robotics researcher: depth and segmentation output is what a perception policy consumes, and segmentation in particular is what lets a training pipeline distinguish obstacles by class. Producing those at speed, in parallel across thousands of simulated sensors, is the enabling detail for vision-based training rather than a rendering nicety.

The word custom is the load-bearing part. The README describes a custom rendering framework, and the features list frames the whole project as modular and extendable, letting users create custom environments, robots, sensors, tasks and controllers, and change parameters programmatically on the fly by modifying the simulation components. The high-fidelity physics engine is Isaac Gym's, and the README notes the possibility of adding support for custom physics engine backends and rendering pipelines.

Task definition and environment configuration are also broken into fine-grained pieces, so a task no longer lives in a large monolithic environment file. That is a change in ergonomics as much as in capability, and it is what makes porting your own robot and task realistic.

Version 2 was a rewrite, with v1 still cited in the paper

The release history shows three milestones. Version 1.0.0 was tagged on 2024-07-18, v2.0.0 on 2025-04-28, and 2.0.1 on 2026-06-28 with the note that it added support for a Unified Autonomy Stack. The last push to the repository was on 2026-06-28, and the repository is not archived.

Because v2 was a rewrite rather than an incremental series, the upgrade story is not a patch-level story. The README points to the paper describing the previous version for motivation and design principles, with the arXiv link 2305.16510, and notes that the link will be updated to reflect the newer version soon. The citation request in the README is for a 2025 paper in IEEE Robotics and Automation Letters, volume 10, number 4, pages 4093 to 4100, and a separate request for the reinforcement learning policy that ships with the simulator, which points to a 2024 ICRA paper on collision-free flight using deep collision encoding.

Two details in the citation instructions are easy to miss. The first is that the paper is for the previous version, so the design rationale you read is not exactly the design of the code you install. The second is that the navigation policy is a separate citation, which tells you the repository carries trained policies as artifacts, not only environments.

The repository layout supports this structure: an `aerial_gym/` package directory, `docs/` with the mkdocs site, `resources/`, `supplementary_material/`, and a `mkdocs.yml` that builds the documentation site at ntnu-arl.github.io.

The dependency list pins numpy and warp-lang, and Isaac Lab is not ready

Installation is a Python package. The `setup.py` in the repository root declares the package name as `aerial_gym`, the version as `2.0.1`, the license as BSD-3-Clause, and the following install requirements.

    install_requires=[
        "isaacgym",
        "matplotlib",
        "numpy",
        "torch",
        "pytorch3d",
        "warp-lang==1.0.0",
        "trimesh",
        "urdfpy",
        "numpy==1.23",
        "gymnasium",
        "rl-games",
        "sample-factory",
    ],

Two details in that list will affect your environment. `numpy` appears twice, once unpinned and once pinned to exactly 1.23, and `warp-lang` is pinned to exactly 1.0.0. Exact pins in a package that also depends on `torch`, `pytorch3d` and `gymnasium` are where dependency resolution tends to get difficult, particularly in a machine learning environment that already has a numpy version of its own.

The `requirements.txt` file is a shorter list, with the same pins for `warp-lang` and `numpy`, plus `urdfpy=0.0.22`, `networkx==3.1` and `scipy`. The project formats its Python with black, configured in `pyproject.toml`.

[tool.black]
line-length = 100

The most important limitation is stated in a callout box near the top of the README: support for Isaac Lab and Isaac Sim is currently under development, and the project anticipates releasing that feature in the near future. If your team has standardised on Isaac Lab, this simulator is not yet the option, because the current build depends on the older Isaac Gym package instead.

Compared with the v1 simulator, the difference is fine-grained customisation

The obvious alternative to this project is its own previous version, and the README is unusually direct about why it moved. The v2 release was rewritten from the ground up, with task definition and environment configuration allowing fine-grained customization of all the environment entities without having to deal with large monolithic environment files.

That is a real difference in approach rather than a version number. In the earlier arrangement, an environment was a large file you edited, and experimenting with a different task, robot or sensor meant copying and pruning a monolith. In v2 the same pieces are components you can create, replace and parameterise programmatically, which is what makes the modular and extendable claim in the features list credible.

The second alternative is the one the project is migrating towards rather than competing with. Isaac Lab and Isaac Sim support is under development, and the difference there is architectural: rather than building environments on top of Isaac Gym primitives with a custom Warp rendering layer, the migration path is to use the newer Isaac stack as the base. The repository does not yet describe that migration in detail, and the paper link for the current version is still marked as pending.

A third framing matters for licensing and adoption. The simulator is open source under the BSD-3-Clause License, which permits commercial use and modification with attribution and retains the disclaimer of warranty, and the repository ships a `LICENSE` file along with the code style and contributing files under `.github/`.

Editorial conclusion

Adopt aerial_gym_simulator when you train reinforcement learning policies for multirotors and need GPU-parallel environments with ray casting depth and segmentation sensors, especially if you already run the Isaac Gym stack with PyTorch. Do not adopt it if your pipeline is built on Isaac Lab or Isaac Sim, because support for those is still under development, and do not adopt it expecting a pip install to be frictionless, since the dependency list pins warp-lang and numpy to exact versions. Verify first that your environment can install isaacgym, pytorch3d and warp-lang together, check the changelog between v1.0.0 and v2.0.0 since the simulator was rewritten from the ground up, and read the arXiv paper linked in the README for the design rationale before porting existing environments.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. ntnu-arl/aerial_gym_simulator on GitHub
3. Project website
4. README
5. Releases