Simulation stack
There is no such thing as the “best” simulator. You pick the one whose trade-offs you can live with, and this guide tells you which trade-off each stack is actually asking you to make.
IA
Ishan Acharya-Gangopadhyay
SIMULATIONS CO-LEAD · AUTHOR
Wrote this guide from hands-on evaluation of the six stacks against SAR's ROS 2 work.
EA
Eleazar Asase
PROJECT DIRECTOR · REVIEWER
Peer-reviewed the guide against the team's simulation-first workflow.
Why it matters
Your simulator choice sets the ceiling on everything downstream: how accurate your physics can be, how easily your ROS 2 stack ports to real hardware, and whether your team can even run the thing on the laptops it owns. Picking based on “what everyone uses” (Gazebo) versus “what the research needs” (MuJoCo) versus “what the demo needs” (Isaac Sim, or a game engine) are three different decisions, and getting them mixed up is the most common way a project stalls six weeks in. This guide exists so that choice is made on purpose, not by default.
The six stacks
Gazebo (Harmonic / Jetty)
The ROS 2 default: boring-correct, well-supported, not flashy.
Physics / sensor fidelity
Mid-tier: ODE / Bullet / DART physics, functional (not photorealistic) rendering, wide sensor plugin coverage.
ROS / ROS 2 integration
First-party:
ros_gz bridge; what most ROS 2 tutorials and launch files already assume.Sim-to-real support
Solid via
ros2_control (same controller code, sim or real); no built-in domain randomization suite.Licensing / cost
Free, Apache 2.0. Maintained by Open Robotics.
Best forValidating a ROS 2 navigation / control stack end to end, the path of least resistance.
Watch out forLow-to-medium learning curve if you already know ROS 2 (steep if you don't); SDF is its own format to learn on top of URDF. Runs on a CPU, no GPU required.
Examples: TurtleBot3 + Nav2 (Open Robotics / ROBOTIS) · gz_ros2_control demo (ros_controls)
NVIDIA Isaac Sim
GPU-accelerated photorealism for perception training and humanoid RL.
Physics / sensor fidelity
Best-in-class: GPU PhysX physics plus RTX ray-traced rendering; camera/LiDAR sims that can pass for photographs.
ROS / ROS 2 integration
First-party: OmniGraph-based bridge; NITROS zero-copy transfer to Isaac ROS (targets ROS 2 Jazzy).
Sim-to-real support
Purpose-built: Isaac Lab domain randomization + the Isaac GR00T humanoid sim-to-real pipeline.
Licensing / cost
Free / open source. Redistributing Omniverse Kit in a commercial product needs an Enterprise license (only matters if shipping it).
Best forTraining vision-based or humanoid RL policies that need to transfer to real cameras and hardware.
Watch out forSteep learning curve: USD scene composition, OmniGraph, JAX-adjacent RL tooling all at once. Needs a real RTX-class GPU; laptop integrated graphics won't run it.
Examples: Isaac-GR00T (NVIDIA) · Sim-to-Real SO-101 Workshop (NVIDIA Isaac Sim team)
MuJoCo
The physics-accuracy reference: contact dynamics done right.
Physics / sensor fidelity
Best-in-class contact/joint physics; sensor plugin support comparatively immature; rendering functional, not photorealistic.
ROS / ROS 2 integration
Community-maintained only (
MujocoROS2Control, mujoco_ros2): no official bridge from DeepMind.Sim-to-real support
Strong for RL-policy transfer (train at scale in MJX, deploy the policy); less turnkey for swap-the-controller-code sim-to-real.
Licensing / cost
Free, Apache 2.0. Maintained by Google DeepMind (acquired 2021, open-sourced 2022).
Best forContact-rich RL research, legged locomotion, dexterous manipulation, where physics accuracy is the actual research question.
Watch out forSteep learning curve: MJCF format and, for performance, the mjModel/mjData structures directly; no drag-and-drop world builder. CPU-only runs fine; GPU (MJX/Warp) only matters for parallel RL training.
Examples: MuJoCo Menagerie (Google DeepMind) · unitree_mujoco (Unitree Robotics)
This is the stack SAR uses for its gait work.
This is the stack SAR uses for its gait work.
Webots
Batteries-included: fastest path from zero to a moving robot.
Physics / sensor fidelity
Solid, well-rounded physics; an unusually deep built-in sensor catalog (cameras, LiDAR, GPS, IMU) with no plugin-hunting.
ROS / ROS 2 integration
First-party and actively maintained (
webots_ros2), with packages for common platforms (TIAGo, UR arms, TurtleBot).Sim-to-real support
Good via
ros2_control; Supervisor API + headless fast-sim mode useful for automated regression testing.Licensing / cost
Free, Apache 2.0 since December 2018. Maintained by Cyberbotics (originated at EPFL, 1996).
Best forTeaching, hackathons, or anything that needs to be working before lunch, lowest ramp-up on this list.
Watch out forLowest learning curve here: readable Proto files, intuitive GUI, tutorials get you moving in under an hour. Runs comfortably on a laptop CPU, no GPU required.
Examples: webots_ros2_universal_robot · webots_ros2_tiago (both Cyberbotics)
CoppeliaSim (formerly V-REP)
Built for heterogeneous multi-robot fleets and rapid algorithm prototyping.
Physics / sensor fidelity
Flexible rather than best-in-class: swappable physics engines per scene (MuJoCo, Bullet, ODE, Newton, Vortex).
ROS / ROS 2 integration
Dedicated ROS 2 plugin, but secondary to its own multi-language remote API (Python, Lua, Java, MATLAB, C/C++, Rust).
Sim-to-real support
Reasonable, though more integration work falls on you than Gazebo's or Webots' opinionated ROS 2 pipelines.
Licensing / cost
Dual-licensed: free “Edu” tier for education/non-commercial; commercial needs a paid license. Coppelia Robotics AG (Zurich).
Best forProjects with several robot types cooperating (arm + mobile base + drone), its distributed, per-object control model fits that shape naturally.
Watch out forMedium learning curve: Lua scripting and an object-based architecture take adjustment coming from ROS 2/URDF. CPU-only is fine; GPU helps rendering but isn't required.
Examples: RLBench manipulation benchmark · CoppeliaSim sample scenes library (Coppelia Robotics AG)
PyBullet
Quick Python-native RL prototyping · but largely dormant as a maintained project now.
Physics / sensor fidelity
Adequate rigid-body dynamics via the Bullet engine; basic camera/LiDAR simulation.
ROS / ROS 2 integration
Minimal, community-maintained at best: usually means writing your own bridge code.
Sim-to-real support
Workable in its niche (drone-control RL, some manipulation); no dedicated domain-randomization tooling.
Licensing / cost
Free, zlib license. Nominally maintained under the Bullet Physics project (Erwin Coumans).
Best forContinuing an existing PyBullet pipeline (e.g. gym-pybullet-drones), not recommended as a starting point for new work.
Watch out forMaintenance has slowed substantially: no new PyPI release in over a year, and OpenAI Gym's own maintainers moved off it years ago toward MuJoCo/Brax. Low learning curve otherwise; CPU-only, runs anywhere.
Examples: gym-pybullet-drones (UToronto DSL) · Bullet3 pybullet examples (Erwin Coumans)
Honorable mention: game engines
Unity and Unreal aren't robotics simulators, they're rendering/game-logic engines robotics teams borrow when visual fidelity or human-robot interaction demos matter more than physics accuracy. Unity has the more mature robotics tooling via Unity Robotics Hub (URDF importer, ROS-TCP-Connector); its Robotics-Nav2-SLAM-Example swaps Unity in for Gazebo entirely. Unreal shows up mostly through AirSim / Cosys-AirSim for photorealistic aerial work. Reach for either when the deliverable is “look how good this looks” rather than “is this physically correct” , and budget for Unity's paid license above certain revenue thresholds.
Can you mix simulators?
Yes, but “combine” means a few different things, not one universal move. Four real patterns, roughly in order of how often they're actually used:
| Pattern | What it actually does | Maturity / caveat |
|---|---|---|
| Split by job, glue with ROS 2 | Train/tune a policy in MuJoCo (fast, cheap, accurate contacts), then validate the same controller code against Gazebo's richer sensors. Nothing shares physics state, separate runs, same code path via ros2_control. | The most common pattern in real use. Low effort since the controller talks over ROS 2 topics either way. |
| Convert models between formats | gz-mujoco is a two-way SDFormat ↔ MJCF converter: design a robot in one tool's format and carry it into the other without rewriting XML. |
Real and actively maintained (DeepMind-listed). Converts models, not live simulation state. |
| Loosely-coupled multi-sim over a shared bus | Run one sim (e.g. Isaac Sim) for perception/rendering while a separate process handles physics or planning, synced over ROS 2 or a shared clock. | Common in aerial/SITL stacks, close to what some of our own aerial work already does with mavros/pymavlink. |
| Swap the physics engine under another sim | Gazebo's physics layer (gz-physics) is pluggable: a proof-of-concept MuJoCo backend gave MuJoCo's solver under Gazebo's sensors/ROS 2 bridge. |
Proven possible, not productionized: the 2021 MVP never fully merged. Don't rely on it as a drop-in today. |
True simultaneous co-simulation, two physics engines stepping in lockstep, sharing state every tick, is rare outside research demos, because keeping contact solvers agreeing is genuinely hard. In practice, “combining sims” almost always means one of the four patterns above.
Spec comparison
| Spec | Gazebo | Isaac Sim | MuJoCo | Webots | CoppeliaSim | PyBullet |
|---|---|---|---|---|---|---|
| Physics fidelity | Mid-tier | Best (GPU PhysX) | Best contacts | Solid | Flexible (5 engines) | Adequate |
| ROS 2 integration | First-party | First-party | Community only | First-party | Plugin (secondary) | Minimal / DIY |
| Sim-to-real tooling | ros2_control | Isaac Lab + GR00T | MJX transfer | ros2_control | DIY | Limited |
| License / cost | Free | Free | Free | Free | Dual (Edu / paid) | Free |
| Learning curve | Low-med | Steep | Steep | Lowest | Medium | Low |
| GPU required? | No | Yes (RTX) | MJX only | No | No | No |
How to choose for your project
| If your question is… | Start with |
|---|---|
| Does my ROS 2 navigation/control stack work at all? | Gazebo, path of least resistance in the ROS 2 ecosystem. |
| Does my contact-rich physics actually behave correctly? | MuJoCo, best-in-class contacts, MJX for GPU-parallel RL on top. |
| Can a vision policy trained on synthetic data transfer to a real camera? | Isaac Sim, RTX rendering + Isaac Lab domain randomization. |
| I need something working before the meeting ends. | Webots, lowest learning curve, richest built-in sensors, no GPU. |
| Several different robot types that must cooperate? | CoppeliaSim, distributed per-object control (budget the commercial license). |
| I already have a PyBullet pipeline to extend. | PyBullet, fine for continuity; don't start anything new on it. |
| Show a non-technical audience, or generate a photoreal dataset. | Unity or Unreal, rendering over physics, the opposite trade-off. |
| I just know I'm doing ROS 2 robotics research. | Gazebo first, then MuJoCo once physics accuracy becomes the bottleneck. |
Glossary
- SDF (Simulation Description Format)
- Gazebo's XML format for describing a world and the robots/objects in it, a blueprint the simulator reads to build the scene.
- URDF (Unified Robot Description Format)
- ROS's XML format for a single robot's links, joints and physical properties, the standard “robot blueprint” most tools import.
- MJCF (MuJoCo XML)
- MuJoCo's own model format, similar purpose to URDF/SDF, with MuJoCo-specific physics tags.
- ROS 2
- Robot Operating System 2, not an OS, but the standard shared toolbox and messaging system for building robot applications.
- PhysX
- NVIDIA's physics engine; calculates how objects move, collide and react to forces. The engine under Isaac Sim.
- RTX ray tracing
- NVIDIA's real-time rendering that simulates how light bounces, why Isaac Sim's camera images can look near-photographic.
- MJX (MuJoCo XLA)
- A GPU version of MuJoCo built on JAX that runs thousands of simulations in parallel, used to train RL policies fast.
- Domain randomization
- Deliberately varying simulated conditions (lighting, friction, noise) during training so a policy handles real-world messiness instead of overfitting.
- Sim-to-real gap
- The difference between how a robot behaves in simulation versus reality, the whole reason “sim-to-real support” is a column in this guide.
- USD (Universal Scene Description)
- Pixar-developed 3D scene format Isaac Sim/Omniverse is built around, the file format for an entire virtual world.
- OmniGraph
- Isaac Sim's visual node-based system for wiring simulation logic (e.g. “publish this camera to this ROS 2 topic”).
- ros2_control
- A ROS 2 framework for writing a controller once and running it against simulated or real hardware, the main sim-to-real mechanism most of these sims use.
Cite this
Acharya-Gangopadhyay, I. (2026). Simulation stack: a decision guide to robotics simulators. Spartan Autonomous Robotics, Michigan State University. Reviewed by E. Asase. https://msusar.org/research/simulation-stack
Sources
More field guides
Practical decision guides from the team, meant to save the next member six weeks.
ALL RESEARCH →