Pegasus Simulator puts PX4 and ArduPilot drones inside Isaac Sim

A framework that inherits Isaac Sim's release rhythm

Pegasus Simulator is a framework built on top of NVIDIA Omniverse and Isaac Sim, designed to provide an easy yet powerful way of simulating the dynamics of vehicles. It provides a simulation interface for PX4 and ArduPilot integration, as well as a custom Python control interface.

The most consequential thing about the project is visible in the version numbers. The current release is v5.1.0, and the badges in the README pin IsaacSim 5.1.0, PX4-Autopilot 1.14.3, ArduPilot-Copter 4.4 and Ubuntu 22.04LTS. Every Pegasus release corresponds to an Isaac Sim release, and the release notes say so explicitly: v5.1.0 is released for Isaac 5.1.0, v4.5.1 for Isaac 4.5.0, v4.5.0 for Isaac 4.5.0, v4.2.0 for Isaac 4.2.0 and v4.1.0 for Isaac 4.1.0.

And each of those notes repeats the same warning: this version is not compatible with older versions of Isaac Sim. That is a hard constraint on adopters. There is no supported path to a Pegasus version that matches an Isaac Sim version you already had, because a Pegasus version only exists for the Isaac version it was built against.

The vehicle scope is equally narrow for now. The README states that only multirotor vehicles are supported, with support for other vehicle topologies planned for future versions. A team working on fixed-wing aircraft or ground robots is outside the current scope, and the roadmap is where that would be tracked.

What the project does have is a coherent story about its own life. The framework is described as an open source effort started in January 2023 to serve a four year PhD work plan, with the author stating that the repository can be expected to be maintained, hopefully at least until 2027.

Three ways to fly a simulated drone

The examples directory is the clearest description of the architecture, because each numbered file is a different way of putting a vehicle into the world.

There is a single vehicle flown with PX4, and a multi vehicle version flown with PX4. There is a single vehicle version driven from ROS2, a single vehicle version driven by the custom Python control interface, and a multi vehicle version driven by Python as well. Then there is an ArduPilot multi vehicle example, which the release notes describe as an experimental interface.

Two more examples round out the picture. There is a camera vehicle example, and one involving people in the scene, which matters because a photorealistic world with no humans in it is a poor test of a perception pipeline.

So the framework supports three distinct control paths, and the difference between them is a genuine architectural choice rather than three names for the same thing. PX4 and ArduPilot are external autopilot stacks running in the loop, which means the flight logic under test is the real one. The Python control interface bypasses the autopilot entirely and drives the vehicle from a Python process, which is faster to iterate on and does not test the autopilot.

The ROS2 path sits in between, and the fact that the v5.1.0 change was made specifically to simplify launching Isaac Sim from the terminal with ROS2 support suggests that path matters to the maintainers.

The examples also show how the research output is produced. There is a paper results example, a paper plots notebook, and a results directory alongside a trajectories directory, which is the shape of a project that has to produce figures for publications as well as run simulations.

isaac_run replaced the old launch command

The one piece of upgrade advice the README puts in front of every user of an earlier version is about a command line tool, and it is worth understanding because it breaks working setups.

For users of versions prior to v5.1.0, a new command line tool named isaac_run is now used to launch Isaac Sim. The README is explicit that this is a function that should be added to your .bashrc or .zshrc file during the installation of Isaac Sim, and it points at the installation instructions for the details.

The stated reason is to simplify launching Isaac Sim from the terminal with ROS2 support. All previous instructions that mentioned launching Isaac Sim examples from the examples folder using the ISAACSIM_PYTHON command should now use isaac_run instead.

That is a shell function rather than a binary, and it is the kind of thing that will not survive a fresh machine setup. A developer who upgrades Pegasus, reinstalls Isaac Sim and does not re-read the installation page gets an environment where the documented command does not exist, and the failure is a command not found rather than anything that points at the cause.

The repository root reflects this. There are link_app.sh and link_app.bat files, which are the Unix and Windows equivalents of the step that puts the helper on your path, alongside a tools directory and a .vscode directory for editor configuration.

For an adopter the practical rule is simple. Treat the installation page as part of the upgrade, not as something you read once.

Where the project is thin, and where it is honest about it

Two things stand out in the release notes, and both are about honesty rather than capability.

The first is that the ArduPilot integration is described as experimental, and the notes track that status release by release. In v4.5.0 the ArduPilot experimental interface was not tested in that version. In v4.5.1 it was fixed and improved, with credit to two named contributors. In v5.1.0 it was again not tested in that version. A framework that tells you which of its own features were not exercised in a given release is doing something that many projects do not.

The second is that contributors are named per release, with credit for the initial open-source contribution to v5.1.0 and for the ArduPilot fixes in v4.5.1. The main developer team section breaks the work down by area, with architecture, multirotor dynamic simulation and control, example applications, and the experimental ArduPilot integration each attributed to specific people.

Where the documentation is thin is in the parts the project delegates. The README is a short index that points at the documentation site for installation, usage, a project roadmap, a contributing guide and the licence files of dependencies and assets. The README itself does not describe the API, the physics model, the sensor configuration or the extension points, so an engineer evaluating this has to read the hosted documentation rather than the repository.

The dependencies also matter more than usual here. The framework is released under the BSD-3 licence, but Isaac Sim is available under an individual NVIDIA licence, and the repository keeps the licence files of its dependencies and assets in a docs/licenses directory. A team that has to run this in a lab has to accept the Isaac Sim terms as well, and that is a procurement conversation the BSD-3 grant does not settle.

The simulation stack and the real-robot code are separate projects

The README draws a distinction that matters for anyone reading this as a flight stack rather than a simulator. In parallel to this project, the Pegasus guidance, control and navigation project serves as the foundation control code for performing real-world experiments, and it lives at its own site.

So Pegasus Simulator is the simulated half and Pegasus GNC is the real-vehicle half, and they are separate repositories with separate documentation. The distinction is worth holding on to when reading the example names, because a Python control example in the simulator is not the same code path as the guidance, control and navigation code that runs on the aircraft.

For a research group, that split is a feature. The simulation exists so that the guidance and control code can be exercised in a realistic world, including perception and cameras, before it is flown. The camera vehicle example and the people example exist precisely because the point is to test the pipeline in a world that looks like the one the real vehicle will see, not a simplified physics sandbox.

The research framing also explains the citation requirement. The project asks users to cite the paper if it proves useful in academic work, with a DOI, and the BibTeX entry is included for the 2024 International Conference on Unmanned Aircraft Systems, listing the authors, the volume and page numbers and the keywords covering simulation, robot sensing systems, real-time systems, sensor systems and task analysis.

The project page, the paper and the simulator are the three parts of the same body of work, and the simulator is the one that is open source and versioned against Isaac Sim.

Editorial conclusion

Pegasus Simulator suits a drone researcher or robotics team that needs a full flight stack, PX4 or ArduPilot plus physics plus sensors, inside a simulation rather than in a gazebo world, and who is prepared to live inside Isaac Sim's release cycle. It is the wrong tool for a team that wants a lightweight, dependency-light simulator, because the whole value comes from Isaac Sim and its own licensing and hardware requirements, and it is the wrong tool for a fixed-wing or ground vehicle project while multirotor is the only supported topology. Before you adopt it, match the Pegasus release to your installed Isaac Sim version exactly, because every release states that it is not compatible with older Isaac Sim versions, and read the installation instructions, because the launch mechanism changed at v5.1.0 with the new isaac_run command.

Frequently asked questions

Official sources

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