CtrlK
Gazebo is an open-source 3D dynamic robotics simulator that has served as the de facto standard simulation environment for the robot software research community for over two decades. The project began in the fall of 2002 at the University of Southern California (USC), where Andrew Howard and his graduate student Nate Koenig built it as a complement to the 2D Stage simulator within the Player Project [1]. The name was chosen because a gazebo is the structure most similar to an outdoor stage. From those academic origins, Gazebo has grown into a mature ecosystem maintained by Open Robotics that powers algorithm development, sensor simulation, reinforcement learning, and high-stakes program work for organizations including DARPA, NASA, and the US Department of Defense. Today the project exists in two distinct lineages: the original monolithic codebase known as Gazebo Classic, whose final long-term release Gazebo 11 reached end of life on 29 January 2025, and the modern modular rewrite simply called Gazebo, which uses lettered release names such as Garden, Harmonic, Ionic, and the upcoming Jetty [2][3].
Gazebo is free software released under the Apache 2.0 license. It runs primarily on Ubuntu Linux, with experimental builds available for macOS and Windows. The simulator combines a rigid-body dynamics engine, a 3D graphics renderer, sensor models, a graphical user interface, and a publish-subscribe transport layer into a single integrated environment that can simulate one or many robots interacting with each other and with the world. It is most commonly paired with the Robot Operating System (ROS) for high-level robot software development, making it the canonical choice for any robotics project built on the ROS ecosystem. The combination of Gazebo and ROS has trained generations of roboticists and remains the entry point for most academic and many industrial robotics projects.
Gazebo was conceived in 2002 in the USC Robotics Research Lab as part of a larger effort to give roboticists better tools for testing software without the cost, fragility, and time pressure of physical hardware. The Player Project, founded by Brian Gerkey, Richard Vaughan, and Andrew Howard, already provided two pieces of infrastructure: Player itself, a network server that exposed robot hardware through a uniform device interface, and Stage, a fast 2D multi-robot simulator. Stage worked well for swarms of small ground robots in flat indoor environments but could not represent the three-dimensional structure of outdoor terrain, the optical properties of cameras, or the dynamics of objects with mass and inertia. Howard and Koenig set out to fill that gap with a 3D simulator that supported high-fidelity sensor models and rigid-body physics, while preserving the Player device interface so that simulated and real robots could be controlled by identical client code [1].
The first public release of Gazebo arrived in 2004. It used the Open Dynamics Engine (ODE) for rigid-body physics, OpenGL for rendering, and a small set of sensor plugins covering monocular cameras and laser range finders. Worlds were described in an XML file format that defined geometry, joints, sensors, and physical properties. The core insight was that a robot controller written against the Player API could not tell whether it was talking to a physical Pioneer mobile robot or to a Pioneer model spawned inside Gazebo, which made the simulator an inexpensive proxy for hardware that researchers could use for development, debugging, and validation. This sim-to-real symmetry remains a defining property of the Gazebo and ROS workflow today.
Gazebo was a component of the Player Project from 2002 through 2011. In 2011 it spun out as an independent project under the stewardship of Willow Garage, the Menlo Park robotics company that was simultaneously building ROS and the PR2 humanoid mobile manipulator. Willow Garage funded the integration between Gazebo and ROS through the gazebo_ros_pkgs metapackage, which allowed ROS topics, services, parameters, and actions to act as the primary interface to a simulated robot. When Willow Garage wound down in 2012, the Open Source Robotics Foundation (OSRF) was created to take stewardship of both ROS and Gazebo. The transition to OSRF marked the start of Gazebo's professional, full-time development phase and gave the project a sustainable institutional home.
The single event that did the most to push Gazebo from a useful research tool into a serious piece of professional infrastructure was the Defense Advanced Research Projects Agency (DARPA) Robotics Challenge. Announced in 2012 in response to the Fukushima Daiichi nuclear disaster, the DRC asked teams to build humanoid robots that could perform a sequence of disaster-response tasks including driving a vehicle, traversing rubble, opening doors, climbing ladders, and operating power tools. DARPA awarded Open Robotics a contract to build a Virtual Robotics Challenge (VRC) and to upgrade Gazebo to support the demanding simulation requirements of a humanoid in a complex environment [4]. The VRC, run in June 2013, served two purposes: it allowed software-only teams without their own humanoid hardware to compete, and it filtered the large initial pool of competitors down to the teams that would receive Boston Dynamics ATLAS robots for the live trials.
For Gazebo, the DRC contract drove a multi-year sprint of engineering improvements. The simulator gained better contact handling for bipedal locomotion, improved camera and laser sensor models, support for haptic feedback, and far higher physical fidelity than it had previously offered. The DRC required Gazebo to simulate a fully articulated humanoid with a realistic mass distribution, multiple cameras, lidars, and force-torque sensors, all at near real-time rates while teams ran their control software against it. The investment paid off: the VRC successfully ran in parallel across cloud computing infrastructure, and the simulator code that emerged from the DRC effort was the basis for many subsequent Gazebo releases.
The DRC engagement also led directly to NASA's Space Robotics Challenge (SRC), which began in 2015 and used Gazebo to simulate NASA's Valkyrie humanoid robot performing repair tasks at a future Mars habitat. NASA selected its 20 SRC finalists based on their performance in a Gazebo qualifying round, and several teams continued to use the simulator for ongoing humanoid research after the competition ended. The DRC and SRC together cemented Gazebo's status as the standard simulator for serious robotics work, and they accelerated the institutional maturation of Open Robotics from a small open-source project into an organization that could deliver mission-critical software for government and industry partners.
Gazebo Classic refers to the original codebase developed continuously from 2002 through Gazebo 11. It uses a monolithic architecture in which the simulator core, physics interface, rendering, sensors, and graphical interface live in a single tightly coupled C++ project. The numbered releases (2.x through 11.x) shipped on a roughly annual cadence, with Gazebo 11.0.0 released in January 2020 as a Long Term Support release [5]. Gazebo 11 received bug fixes and ROS integration updates for its full five-year support window, which expired on 29 January 2025 [2][3].
Gazebo Classic's most distinctive feature is its support for four different physics engines that share a common Physics API [6]. The default and most heavily tested engine is ODE, the Open Dynamics Engine, which uses a maximal-coordinate Lagrangian formulation and an iterative LCP solver well suited to cluttered scenes with many independent objects. The Bullet engine, the same library used in many video games, also uses maximal coordinates and shares strengths and weaknesses with ODE. DART (Dynamic Animation and Robotics Toolkit), developed at Georgia Tech, uses generalized coordinates with the Featherstone algorithm and tends to produce more accurate simulations of articulated structures such as humanoids. Simbody, originally developed at Stanford for biomechanical simulation, also uses Featherstone-style generalized coordinates and is particularly strong at constrained mechanisms with many degrees of freedom. Gazebo's plugin-based physics architecture lets users select an engine at world-load time without changing their model files, although ODE is by far the most commonly used in practice.
For rendering, Gazebo Classic uses the Object-Oriented Graphics Rendering Engine (OGRE) version 1.x. The renderer supports texture mapping, dynamic lighting, shadows, and post-processing effects, and provides the visual output for both the user-facing GUI and for the camera and depth sensors used by simulated robots. Sensor simulation includes monocular RGB cameras, depth cameras (with both software and GPU implementations), laser scanners (including the GPU-accelerated gpu_ray sensor), inertial measurement units, GPS receivers, magnetometers, contact sensors, and force-torque sensors. Worlds, models, and robots are described using the Simulation Description Format (SDF), an XML schema developed alongside Gazebo and standardized through the SDFormat project [7]. SDF files describe the geometry, inertia, joints, sensors, and plugin attachments of a robot or environment, and the simulator parses them into a scene graph that drives both the physics and the rendering.
In 2017 Open Robotics began an ambitious rewrite of the simulator that would become known as Ignition. The motivation was that the monolithic Gazebo Classic codebase had become difficult to extend and maintain. New features had to touch many parts of the system, and dependencies between subsystems made it hard for users to swap in alternative components or to use Gazebo's libraries in isolation. The Ignition project replaced the monolithic core with a collection of independent C++ libraries, each responsible for one concern, that could be assembled into a full simulator or used standalone in other applications. The libraries follow a uniform versioning and release cadence and are connected by a publish-subscribe message bus called Ignition Transport (now Gazebo Transport) [8].
The core libraries of modern Gazebo include gz-sim, the simulator itself; gz-physics, a thin abstraction layer over physics engines (currently DART by default, with optional Bullet, TPE, and ODE plugins); gz-rendering, an abstraction over rendering engines (currently OGRE 2.x by default with experimental OGRE 1 and OptiX backends); gz-sensors, the sensor implementations; gz-gui, the Qt-based user interface; gz-transport, the inter-process message bus; gz-msgs, the protocol buffer message definitions; gz-fuel-tools, the asset management system that downloads models from the Gazebo Fuel cloud library; and several support libraries for math, common utilities, and plugin loading. gz-sim itself uses an entity-component-system (ECS) architecture, in which simulation state is represented as a flat collection of entities tagged with arbitrary components, and behavior is implemented by systems that iterate over entities with a particular set of components. The ECS pattern, borrowed from the game industry, makes it easy to add new functionality without modifying existing code and supports parallel execution of independent systems.
The rewrite first appeared as Ignition Citadel in December 2019, followed by Ignition Edifice (2021) and Ignition Fortress (September 2021). Then came an unexpected detour. In April 2022, Open Robotics announced that a trademark obstacle had blocked their continued use of the name "Ignition" and that the project would revert to the Gazebo brand. The original codebase was renamed Gazebo Classic, and the modern fork received the Gazebo name [9]. The first release under the new convention was Gazebo Garden in September 2022. From that point forward, the modern simulator has used lettered, alphabetical release names just as ROS distributions do.
The table below compares the two lineages on the dimensions that matter for a user choosing a simulator today.
| Property | Gazebo Classic | Modern Gazebo |
|---|---|---|
| Architecture | Monolithic C++ project | Modular collection of independent libraries |
| Versioning | Numbered (2 through 11) | Lettered (Citadel, Garden, Harmonic, Ionic, Jetty, ...) |
| Default physics engine | ODE | DART |
| Other physics engines | Bullet, DART, Simbody | Bullet (plugin), TPE, custom plugins |
| Renderer | OGRE 1.x | OGRE 2.x by default |
| Transport | Custom Boost.Asio TCP layer | gz-transport (ZeroMQ + Protocol Buffers) |
| Simulation API | C++ plugins inside the gzserver process | ECS-based system plugins, gz-transport messages |
| GUI | Qt 5 with custom widgets | Qt 5 with QML and ImGui-style panels |
| ROS integration | gazebo_ros_pkgs | ros_gz bridge plus topic remapping |
| ros_control bridge | gazebo_ros2_control (frozen at EOL) | gz_ros2_control |
| Scene description | SDFormat 1.7 and earlier | SDFormat 1.10 and later |
| Fuel asset library | Limited support | First-class integration |
| Status | End of life on 29 January 2025 | Actively developed |
| Recommended for new projects | No | Yes |
The modern fork follows a yearly release cadence with alternating two-year and five-year support windows. Long-term support (LTS) releases land every two years and receive five years of maintenance, while the in-between releases receive two years of maintenance. The releases align loosely with ROS 2 distributions to make it easier for developers to choose a matching pair.
| Release | Release date | Support type | End of life | Paired ROS 2 distribution |
|---|---|---|---|---|
| Citadel | December 2019 | LTS (5 years) | December 2024 | Foxy |
| Edifice | April 2021 | Two-year | March 2023 | Galactic |
| Fortress | September 2021 | LTS (5 years) | September 2026 | Humble |
| Garden | September 2022 | Two-year | November 2024 | Iron |
| Harmonic | September 2023 | LTS (5 years) | September 2028 | Jazzy |
| Ionic | September 2024 | Two-year | August 2026 | Kilted |
| Jetty | September 2025 | LTS (5 years) | September 2030 | Lyrical (planned) |
Gazebo Jetty is the tenth major release of the modern simulator and the fifth long-term support release. As of April 2026 it is the recommended Gazebo release for new projects that need long-term stability. Gazebo Harmonic remains a popular choice for teams already on the ROS 2 Jazzy LTS line.
Gazebo's sensor library covers most of the perception modalities that a real robot would use. Cameras include monocular RGB, stereo pairs, wide-angle and fisheye lenses, depth cameras (in both software and GPU-accelerated variants), thermal cameras, segmentation cameras that output per-pixel object identifiers, and "logical" cameras that report visible models and their poses without rendering. Lidar sensors include both single-line laser scanners and multi-channel rotating lidars, with a CPU implementation for simple cases and a GPU implementation that uses depth-buffer reads for high-resolution scans. Inertial measurement units provide simulated linear acceleration and angular velocity with optional Gaussian noise and bias drift. GPS or GNSS sensors emit latitude, longitude, altitude, and velocity in a configurable global frame. Magnetometer, altimeter, contact, and force-torque sensors fill out the suite [10].
The physics interface in modern Gazebo abstracts over multiple engines through gz-physics. The default backend is DART, chosen for its accuracy on articulated systems and for its permissive license. Bullet is available as an optional plugin for users who prefer its solver characteristics or who need to share simulation models with other Bullet-based tools. The Trivial Physics Engine (TPE) is a lightweight kinematic-only backend useful for large-scale multi-robot simulations where dynamics are not needed. The plugin-based design allows third parties to add new physics backends, and several research groups have published plugins for specialized engines including MuJoCo and PhysX.
World and robot description files use the SDFormat standard. An SDF file describes a <world> element that contains static lighting, atmospheric conditions, gravity, and one or more <model> elements. Each model has <link> elements (rigid bodies with mass and inertia) connected by <joint> elements (revolute, prismatic, ball, fixed, and other types), with <collision> and <visual> geometry attached to each link. Sensors and plugins are also defined within the SDF file [7]. Many users author models in URDF (Unified Robot Description Format), the older format inherited from ROS, and rely on the urdf_to_sdf converter or the on-the-fly parser in gz-sim. Models can also be downloaded from Gazebo Fuel, a community-curated asset library that hosts thousands of free and commercial robot, environment, and prop models.
Gazebo and ROS have been intertwined since 2009, when Willow Garage merged Gazebo into the ROS ecosystem and started shipping the gazebo_ros_pkgs metapackage. The integration provides bidirectional plugins that publish ROS topics for sensor data and subscribe to ROS topics for actuator commands, expose ROS services for spawn and delete operations, and bridge the ROS time and TF (transform) systems with Gazebo's internal world clock and frame tree. For most ROS 1 projects with Gazebo Classic, gazebo_ros_pkgs is still the canonical bridge.
With the move to modern Gazebo, the integration package is called ros_gz. ros_gz contains a generic bridge that converts between ROS 2 messages and gz-msgs protocol buffer messages, plus convenience packages for common topics such as image, camera info, and TF. The bridge is configurable through a YAML mapping file that lists which topics should be bridged in which direction, and it supports both lazy and eager bridging modes [11]. For real-time control loops the gz_ros2_control package provides a tight integration with the ros2_control framework, exposing simulated joints as ros2_control hardware interfaces so that the same controllers can run in simulation and on real hardware without modification [12].
The gz_ros2_control package is the modern replacement for the older gazebo_ros2_control package. Because Gazebo Classic reached end of life in January 2025, gazebo_ros2_control has been frozen and will not receive updates. New ROS 2 projects should use gz_ros2_control with a modern Gazebo release. Migration guides on the Gazebo website cover the SDF, plugin, and topic-name changes needed to move a project from Classic to modern [13].
Gazebo serves a wide range of applications across academia, industry, and government. The dominant use case is robot algorithm development: motion planners, controllers, perception pipelines, and SLAM (simultaneous localization and mapping) systems are typically tested in Gazebo before being deployed to hardware. The simulator's tight ROS integration means a project can swap between simulated and real sensors and actuators by changing a launch parameter, which makes Gazebo a natural part of the development loop for ROS-based robots. Most academic ROS tutorials begin with a Gazebo simulation, and the standard TurtleBot, PR2, ATLAS, and Husky models are all available with Gazebo support out of the box.
Reinforcement learning has become a major Gazebo use case in recent years. Frameworks such as gym-gz (formerly gym-ignition), stable-baselines3 with Gazebo wrappers, and the OpenAI ROS toolkit treat a Gazebo world as an OpenAI Gym environment in which a policy emits actions, the simulator advances by a fixed time step, and observations and rewards are returned. Researchers train policies for navigation, manipulation, and locomotion this way, often running many copies of the simulator in parallel across cloud infrastructure to gather training data. Gazebo can be configured to run faster than real time by setting the real_time_update_rate parameter to zero, allowing data collection to scale with available compute.
The DRC, NASA SRC, and DARPA Subterranean Challenge demonstrated Gazebo's value for high-stakes program work that needs to be verifiable, reproducible, and inexpensive to iterate on. The same simulator and asset libraries used in those competitions are available to industrial and government users for in-house simulation programs. Autonomous driving research uses Gazebo for sensor simulation and small-scale testing, although larger-scale autonomy programs typically prefer specialized simulators such as CARLA or LGSVL that focus more narrowly on driving scenarios. Multi-robot research, swarm robotics, and warehouse automation all use Gazebo extensively for simulating fleets of mobile robots and the static environments they navigate.
Educational use is enormous. Most university robotics courses teach ROS through Gazebo, and Gazebo simulations underlie the example assignments in textbooks and online courses such as those from The Construct, MathWorks, and Coursera. The free availability of the simulator, the breadth of free robot models on Fuel, and the depth of community tutorials make Gazebo the entry point for newcomers to the field.
Gazebo is one of several major options for robot simulation, each with a different design philosophy and feature set. The table below summarizes how Gazebo compares to its main contemporaries as of 2026.
| Simulator | Developer | License | Default physics | Renderer | ROS support | Strengths | Weaknesses |
|---|---|---|---|---|---|---|---|
| Gazebo (modern) | Open Robotics, Intrinsic | Apache 2.0 | DART | OGRE 2.x | Native via ros_gz | Mature, ROS-native, broad sensor suite, large community | CPU-bound physics, limited GPU parallelism, slower than newer simulators |
| MuJoCo | DeepMind, Google | Apache 2.0 | MuJoCo (custom) | MuJoCo OpenGL | Via mujoco_ros and ros2_control | Fast and accurate articulated dynamics, dominant in RL research | Smaller sensor library, less plugin ecosystem, weaker visual rendering |
| NVIDIA Isaac Sim | NVIDIA | Apache 2.0 (since 2025) | NVIDIA PhysX (GPU) | RTX ray tracing | Native via Isaac ROS | GPU-parallel physics, photorealistic rendering, large-scale RL | Requires NVIDIA GPU, heavy install, steeper learning curve |
| Webots | Cyberbotics | Apache 2.0 | ODE | OpenGL with WebGL preview | Via webots_ros2 | Stable for large time steps, easy onboarding, strong asset library | Smaller community than Gazebo, less ROS depth |
| CoppeliaSim (V-REP) | Coppelia Robotics | Commercial / educational | ODE, Bullet, Vortex, Newton, MuJoCo | OpenGL | Via simROS2 | Very flexible, multiple physics engines, strong scripting | Commercial license for production use, less standardized than Gazebo |
| Genesis | MIT-led collaboration | Apache 2.0 | Genesis (custom GPU) | Path-traced renderer | Limited (in development) | Extreme physics speed, multi-physics (rigid, soft, fluid), generative scene support | Very young (2024), small ecosystem, limited robot library |
The core trade-off across these options is between maturity and modernity. Gazebo and Webots represent the mature end: stable, well-documented, with deep ROS integration and large communities. They run on modest hardware, scale to small to medium fleets, and support every common sensor. They were not designed for the GPU-parallel, large-batch training workloads that have become dominant in modern reinforcement learning, and their physics implementations are largely CPU-bound. MuJoCo and Isaac Sim sit at the modernity end: faster, more parallel, and better suited to large-scale RL, but with smaller communities and less of the scaffolding that Gazebo has built up over twenty years. Genesis is the newest entrant, promising orders of magnitude more throughput than any predecessor, but is still in early adoption.
For a typical robotics project that targets a real robot, the choice usually comes down to whether the project lives in the ROS ecosystem (in which case Gazebo or modern Gazebo with ros_gz is the natural choice) or whether it is a research project focused on RL throughput (in which case MuJoCo or Isaac Sim is often preferred). Many projects use multiple simulators side by side, training policies in MuJoCo or Isaac for speed and validating the trained policies in Gazebo for compatibility with the production ROS stack.
Gazebo's primary strengths are maturity, openness, and ecosystem depth. The codebase has been continuously developed since 2002 and has been hardened by use in mission-critical projects from DARPA and NASA. The simulator is fully open source under the Apache 2.0 license, which makes it suitable for commercial deployment without licensing concerns. The documentation, tutorial corpus, and Q&A archives on Gazebo Answers and ROS Answers represent more than a decade of accumulated practical knowledge. The community of users and contributors is one of the largest in robotics; major releases attract dozens of external contributors and the project has thousands of commits per year.
The ROS integration is unmatched among robotics simulators. Gazebo and ROS were developed in close collaboration for over a decade, and the ros_gz bridge plus gz_ros2_control plugin let a robot's full software stack run unchanged between simulation and hardware. The SDFormat and URDF formats supported by Gazebo are also the standards used by most ROS-based robots, so migrating a model into the simulator usually requires no changes. The Gazebo Fuel asset library provides thousands of free models that can be dropped into a world without authoring custom geometry.
Gazebo's physics interface is unusually flexible. The plugin-based architecture supports four mature physics engines in Classic and an extensible engine system in modern Gazebo, allowing users to choose the engine best suited to their workload. The sensor library covers virtually every perception modality used in modern robotics, with both CPU and GPU implementations of compute-intensive sensors. The graphical interface, while not as polished as some commercial alternatives, exposes the full state of the simulation and is fully scriptable through plugins.
The modular architecture of modern Gazebo is a long-term strength. Individual libraries such as gz-physics, gz-rendering, gz-transport, and gz-fuel can be used outside the simulator, in tools that need only one piece of the stack. The ECS-based simulation engine is easier to extend than the monolithic Gazebo Classic engine, and its message-bus design makes it straightforward to attach external monitoring, recording, or control software without modifying the simulator core.
Gazebo's most discussed weakness is performance, especially for large-scale reinforcement learning. The physics simulation in Classic and most of modern Gazebo is single-threaded and CPU-bound. Benchmarks regularly show that Gazebo uses one CPU core nearly to saturation while leaving the rest of the machine idle, even when expensive sensors are also being computed. The simulator does not provide native GPU-parallel physics in the manner of NVIDIA's PhysX-based Isaac Sim, and recent community discussion has described the lack of GPU-native physics as an existential challenge for the project in the era of large-scale RL [14]. The development team has acknowledged the gap and is investigating both vectorized CPU implementations and GPU backends, but as of 2026 Gazebo cannot match the per-machine throughput of Isaac Sim, MuJoCo MJX, or Genesis.
The rendering, while functional, is not photorealistic by modern standards. OGRE 2.x supports physically based shading, dynamic lighting, and shadows, but produces images that are visibly less realistic than the RTX-based ray-traced rendering in Isaac Sim. For perception research that needs photorealistic synthetic data, Gazebo is usually a poor choice and users prefer Isaac Sim or specialized photorealistic simulators such as Unreal-based options. Gazebo is much better suited to algorithm development and dynamics-focused research where rendering quality is secondary.
The transition from Classic to modern Gazebo, while necessary, has been disruptive. Many existing ROS 1 packages depended on gazebo_ros_pkgs, and migrating them to ros_gz with modern Gazebo requires non-trivial code changes. Documentation is split between the legacy classic.gazebosim.org site and the gazebosim.org site for modern releases, and online tutorials and Stack Exchange answers are frequently out of date or apply to only one branch. Users new to Gazebo often spend considerable time figuring out which version to install and which packages to use; the answer in 2026 is almost always modern Gazebo with ros_gz, but the legacy material remains heavily indexed by search engines.
The simulator's macOS and Windows support has historically lagged Linux. Most production deployments target Ubuntu, and many tutorials assume Ubuntu. Recent modern Gazebo releases have improved cross-platform support, but Linux remains the platform of choice and the only one fully tested by the upstream team.
Open Robotics, the umbrella organization that maintains Gazebo, ROS, and Open-RMF, has gone through significant structural change since 2022. The organization actually consists of three legal entities: the Open Source Robotics Foundation (OSRF), a nonprofit that holds the project intellectual property and governs the open-source projects; the Open Source Robotics Corporation (OSRC), a for-profit subsidiary that historically did paid contract development to fund the open-source work; and Open Source Robotics Corporation - Singapore (OSRC-SG), a related entity in Singapore that led work on Open-RMF for fleet interoperability.
In December 2022, Intrinsic, an industrial robotics software company spun out from Alphabet's X moonshot lab, acquired OSRC and OSRC-SG. The acquisition transferred the for-profit consulting and contract-development arms of Open Robotics to Intrinsic, while OSRF remained an independent nonprofit responsible for the open-source projects [15][16]. The change put much of the day-to-day Gazebo and ROS engineering staff inside Intrinsic, and Intrinsic has since become a major institutional sponsor of the Gazebo project. Intrinsic's CEO Wendy Tan White announced in 2023 that the company would continue investing in the open-source codebase, and Gazebo Ionic and Jetty have been described as collaborative releases between the Intrinsic engineering team and the broader Gazebo community.
OSRF retains governance, project leadership, and trademark ownership for Gazebo and ROS, and the open-source projects remain under permissive licenses with the same governance structures they had before the acquisition. The arrangement is similar to other open-source projects that have a nonprofit foundation alongside one or more commercial companies that employ committers; it gives the project sustainable funding without compromising its open-source nature. Gazebo is also developed in the open on GitHub, and external contributors continue to make a significant fraction of all changes.
The Gazebo roadmap for the second half of the 2020s is shaped by three pressures: the end of life of Gazebo Classic in January 2025, the rise of GPU-parallel physics for reinforcement learning, and the continued growth of the ROS 2 ecosystem. The end of Classic forces all remaining Classic users to migrate to modern Gazebo within a finite window, which is driving steady investment in migration tooling, documentation, and feature parity. Modern Gazebo Jetty (September 2025) is the first LTS release that explicitly assumes Classic is gone and treats the modular architecture as the only Gazebo. Subsequent LTS releases will maintain backward compatibility within the modern lineage but will not look back at Classic.
GPU-parallel physics is the most active area of architectural research. Open Robotics and Intrinsic have publicly discussed plans to add a GPU-based physics backend to gz-physics, either by integrating an existing engine such as PhysX or MuJoCo MJX, or by developing a custom backend optimized for the ECS data layout used by gz-sim. The goal is to support thousands of parallel simulation instances on a single GPU for reinforcement learning workloads, similar to what Isaac Sim and Genesis already provide. Several community-contributed prototypes exist but a production-ready GPU backend has not yet shipped as of 2026.
The ROS 2 ecosystem continues to mature in parallel with Gazebo. Each ROS 2 distribution since Galactic has been paired with a recommended Gazebo release, and the ros_gz bridge is now the canonical way to connect ROS 2 software to Gazebo. The pairing is expected to continue for the foreseeable future, with the upcoming ROS 2 Lyrical distribution targeting Gazebo Jetty as its default simulator. Open-RMF, the third major Open Robotics project, also uses Gazebo for its multi-robot fleet simulation, and improvements to Gazebo's multi-robot performance directly benefit the Open-RMF community.
Longer term, the simulator is competing in a much more crowded field than it was a decade ago. Isaac Sim, MuJoCo, and Genesis all offer capabilities that Gazebo currently lacks, and each has captured a meaningful share of the research community. Gazebo's response is to lean on its ecosystem advantages (the ROS integration, the asset library, the install base, the established workflows) while incrementally adding the high-performance physics and rendering needed to remain competitive for new use cases. Whether that strategy will hold the simulator's central position in the field through the late 2020s is one of the open questions in robotics infrastructure, but Gazebo's history of reinventing itself through Player, Willow Garage, OSRF, and now Intrinsic suggests it has institutional staying power even as its technical leadership in some areas is challenged.