Gazebo (simulator)
Gazebo is an open-source 3D robotics simulator designed for modeling, simulating, and testing robots, sensors, and their interactions in realistic dynamic environments, supporting high-fidelity physics, rendering, and sensor data generation to accelerate robotics development without physical hardware.[1] Originally developed starting in the fall of 2002 at the University of Southern California by Dr. Andrew Howard and his student Nate Koenig, Gazebo emerged as a tool to recreate complex multi-robot scenarios for research and algorithm testing.[2] Its first stable release occurred in October 2012, with subsequent support from Willow Garage beginning in 2011 and the Open Source Robotics Foundation (OSRF), formed in 2012, which hosted events like the 2013 Virtual Robotics Challenge.[2] After over 15 years of evolution, the project underwent a major modernization in 2020, transitioning from Gazebo Classic (the legacy version, with its final major release Gazebo 11 in January 2019 and support ending on January 29, 2025) to the current Gazebo (formerly Ignition Gazebo), which unifies a suite of modular libraries for simulation, transport, sensors, physics, and rendering and serves as the actively maintained version following the end-of-life of Gazebo Classic.[3][2] Key features of the modern Gazebo include plugin-based extensibility for custom physics (powered by the DART engine), advanced graphics via Ogre 2.1 with physically based rendering (PBR) materials and enhanced shadows, and a wide array of sensor models such as LIDAR, cameras (monocular and depth), IMUs, and magnetometers, all incorporating realistic noise and environmental effects.[4] It supports distributed simulations across multiple machines, dynamic asset loading, tunable time steps for real-time or accelerated execution, and asynchronous inter-process communication using ZeroMQ and Protocol Buffers.[4] Gazebo integrates seamlessly with the Robot Operating System (ROS) via bridges, enabling workflows for autonomous systems, and offers cloud services for model management, world sharing, and scalable simulations through platforms like Fuel.[4] Cross-platform compatibility spans Linux and macOS, with tools including a QtQuick-based GUI, command-line utilities (e.g.,gz sim for launching and controlling simulations), and programmatic interfaces in C++ and Python.[4]
Widely adopted in academia, industry, and competitions for tasks like algorithm validation, AI training, and hardware-in-the-loop testing, Gazebo's open-source nature—licensed under Apache 2.0—fosters a vibrant community contributing models, plugins, and extensions, making it a cornerstone for advancing robotics in areas from mobile manipulation to aerial vehicles.[1][2]
Overview
Definition and Purpose
Gazebo is an open-source 3D robotics simulator that enables the accurate simulation of physics, sensors, and actuators within complex, dynamic environments.[1][5] It supports the modeling of realistic interactions among multiple robots, objects, and surroundings, providing high-fidelity representations suitable for advanced robotics research and development.[1][5] The primary purposes of Gazebo include facilitating the testing of robot algorithms and control strategies without the need for physical hardware, accommodating multi-robot scenarios for coordination and interaction studies, and accelerating rapid prototyping in robotics research and development.[1][5] By allowing developers to iterate on designs and behaviors in a virtual setting, it minimizes the time and resources required for hardware-dependent experimentation.[5] In a typical workflow, users define simulation elements such as worlds (representing environments), models (for robots and objects), and plugins (to implement custom behaviors) using the Simulation Description Format (SDF) or the Unified Robot Description Format (URDF), with URDF files converted to SDF for internal processing.[6][7] These descriptions allow for the construction of intricate scenes where robots can navigate, sense, and actuate in response to simulated physical laws. Developed to bridge the gap between simulation and real-world robotics, Gazebo reduces costs and risks associated with hardware testing by enabling safe, repeatable experiments in diverse scenarios.[5] It commonly integrates with the Robot Operating System (ROS) as a framework for robot control and data handling.[8]Versions and Evolution
Gazebo Classic, the original iteration of the simulator, began development in 2002 at the University of Southern California and evolved through versions 1 to 11, culminating in the last major release, Gazebo 11, in 2020.[2] This version featured a monolithic design structured around a single executable, integrating core functionalities with supporting libraries such as the Open Dynamics Engine (ODE) for physics simulation by default and OGRE for 3D rendering.[2] Gazebo Classic reached end-of-life in January 2025, after which no further updates or support were provided by the Open Source Robotics Foundation (OSRF).[9] In contrast, modern Gazebo, rebranded from the Ignition project in 2022, represents a post-2022 evolution with a modular, library-based architecture comprising independent components like gz-sim for core simulation, gz-physics for physics engines, and gz-rendering for graphics.[10][11][12] This design supports native integration with ROS 2 and follows a release cadence with codenames such as Garden (2022), Harmonic (2023), Ionic (2024), and Jetty (2025), remaining under active development as of November 2025.[13] The primary evolution from Gazebo Classic to modern Gazebo involved a shift from a monolithic executable to composable libraries, enabling greater scalability, easier customization, and improved performance through plugin-based extensions.[10] This architectural refactor, initiated around 2017 but formalized under the new branding, addressed limitations in the original design while maintaining backward compatibility where possible. Official migration guides provide step-by-step resources for transitioning projects, including SDF file adaptations and ROS package updates.[3] The discontinuation of Gazebo Classic in 2025 has prompted widespread adoption of modern Gazebo for new robotics projects, particularly in ROS 2 ecosystems, as evidenced by its integration in major distributions like Ubuntu 24.04 and ongoing OSRF support commitments.[14]History
Origins and Early Development
Gazebo originated in the fall of 2002 at the University of Southern California (USC) Robotics Research Laboratory, where it was developed by Andrew Howard and Nate Koenig as a component of the Player Project.[2][5] This initiative addressed the growing need for simulating multi-robot systems in dynamic, outdoor environments, particularly for mobile robotic vehicles, complementing the existing 2D simulator Stage within the Player ecosystem.[5] The project was motivated by applications in autonomous robotics, including data visualization and algorithm testing, and received support from DARPA through the Mobile Autonomous Robot Software (MARS) grant.[15] Early development emphasized open-source principles, with Gazebo released under the GNU General Public License (GPL) version 2 or later, enabling free redistribution and modification by the research community.[15] The simulator focused on high-fidelity 3D modeling of rigid body dynamics, sensors, and actuators to support realistic interactions in complex terrains, distinguishing it from simpler 2D tools.[5] A key milestone came in 2004 with the first public release (version 0.4.0 on May 31), which integrated seamlessly with Player and Stage for hybrid 2D/3D simulations, allowing developers to prototype multi-robot behaviors without hardware.[15] This integration facilitated seamless transitions between simulated and real-world testing via Player's device server interfaces.[5] At its inception, Gazebo adopted the Open Dynamics Engine (ODE) for physics simulation, enabling accurate handling of collisions, joints, and environmental forces essential for mobile robot navigation.[15][5] The tool quickly gained traction in academic research, particularly for swarm robotics and distributed sensor networks, where it supported experiments with large populations of robots in unstructured settings.[5] By providing extensible models for laser rangefinders, cameras, and odometry, early versions empowered studies in cooperative localization and formation control, laying the groundwork for broader adoption in robotics education and prototyping.[15]OSRF Era and ROS Integration
In 2012, the Open Source Robotics Foundation (OSRF) assumed stewardship of the Gazebo project following its spin-out from Willow Garage, marking the beginning of a phase focused on professional development and community-driven enhancements. This transition enabled sustained funding and coordination, leading to the release of Gazebo 1.0 in October 2012, which introduced greater stability through refined core architecture and initial optimizations for compatibility with the Robot Operating System (ROS). These improvements addressed earlier limitations in real-time performance and multi-robot simulation, laying the groundwork for broader adoption in robotics research and education.[16][17] From 2012 to 2020, OSRF oversaw the evolution of Gazebo through versions 2 to 11, incorporating significant technical advancements to enhance simulation fidelity and flexibility. Notable additions included support for the Bullet and DART physics engines in 2014, providing alternatives to the default ODE engine and enabling more accurate modeling of complex dynamics such as articulated bodies and contact interactions. Rendering capabilities were bolstered via enhancements to the OGRE engine, including improved lighting, shadows, and texture handling, which elevated visual realism without compromising computational efficiency. Additionally, native plugins for ROS 1 were developed, allowing developers to extend Gazebo's functionality directly within ROS workflows for tasks like sensor data publishing and actuator control.[18][2] Gazebo's integration with ROS deepened during this era, establishing it as the de facto simulator for the framework and facilitating message passing through the gazebo_ros package, which bridged ROS topics and services with Gazebo's internal transport system. Official support began with the ROS Hydro distribution in 2013, enabling seamless use in ROS-based pipelines for environment setup, robot spawning, and real-time data exchange. By 2015, Gazebo powered thousands of ROS-based projects across academia and industry, bolstered by extensive community contributions via the project's GitHub repository, which amassed hundreds of pull requests and fostered collaborative model and plugin development.Transition to Modern Gazebo
In 2014, the Open Source Robotics Foundation (OSRF) initiated the Ignition project as a modular successor to Gazebo Classic, aiming to overcome the original architecture's limitations in scalability for complex, large-scale robotic simulations.[10] This fork introduced a set of independent libraries designed for greater flexibility and performance, with the first public release, Ignition Acropolis, arriving in February 2019, followed by Ignition Citadel in December 2019 as the initial long-term support version.[19] OSRF continued maintaining both versions during this period to ensure a smooth evolution.[16] The motivations behind the Ignition development centered on enhancing simulation efficiency for multi-robot scenarios, improving extensibility through decoupled components, and better integrating with ROS 2's distributed architecture, which demanded more robust real-time capabilities than Classic provided.[10] By April 2022, due to trademark considerations and to unify branding under the established Gazebo name, the project was rebranded as modern Gazebo, with core libraries renamed such as gz-sim for the simulation engine.[10] This rebranding marked a full pivot away from the Ignition moniker while preserving backward compatibility efforts. The transition culminated in the end-of-life for Gazebo Classic in January 2025, establishing modern Gazebo as the primary simulator with complete separation from the legacy codebase.[2] To facilitate user adoption, the project included porting support for the Simulation Description Format (SDF) across versions and official migration tools for converting URDF and SDF models from Classic to the new libraries.[20] These outcomes have enabled modern Gazebo to handle simulations at scales previously constrained, such as those involving hundreds of robots, while aligning seamlessly with contemporary robotics workflows.[10] Following the end-of-life of Gazebo Classic, modern Gazebo has continued to advance with regular releases, including the long-term support version Jetty on September 30, 2025.[21]Technical Components
Physics Engines
The physics engines in Gazebo simulate rigid body dynamics, collisions, and forces to enable realistic robot motion within simulated environments.[22] These engines compute the interactions between objects, including acceleration due to applied forces, using the fundamental equation of motion \mathbf{F} = m \mathbf{a}, where \mathbf{F} is the net force, m is mass, and \mathbf{a} is acceleration, integrated over time via numerical solvers specific to each engine.[18] Key concepts include joint constraints (e.g., revolute or prismatic types limiting motion), friction models (e.g., Coulomb friction for contact surfaces), and gravity (applied as a uniform downward acceleration, typically 9.81 m/s²).[22] In Gazebo Classic, four physics engines are supported, selectable at runtime via an abstraction layer for flexibility in different scenarios. The default Open Dynamics Engine (ODE) excels in speed for simple scenes with cluttered environments, using a maximal coordinate solver optimized for performance.[18] Bullet provides real-time capabilities, suitable for simulations with many independent models, also employing a maximal coordinate approach.[18] The Dynamic Animation and Robotics Toolkit (DART), developed at Georgia Tech, focuses on articulated bodies like humanoid robots, leveraging Featherstone algorithms for accurate constraint handling.[18] Simbody, from Stanford University, targets biomechanical systems with high precision in multibody dynamics, also based on Featherstone methods.[18] Modern Gazebo employs the Gazebo Physics (gz-physics) library, which offers a pluggable backend system with DART as the default for robust dynamics simulation.[23] Supported backends include Bullet for real-time performance and the custom Trivial Physics Engine (TPE) for kinematics-only simulations in large-scale environments.[22] This architecture improves parallel computation support through backend-specific optimizations, such as multi-threading in DART, enabling efficient handling of complex scenes.[23] Engine selection occurs via SDFormat (SDF) files, command-line flags, or C++ APIs, allowing users to balance accuracy and speed.[23] Gazebo's physics engines can manage up to thousands of objects, as demonstrated by 2020 TPE benchmarks simulating 9,000 shapes with real-time factors around 0.006 while maintaining low memory overhead compared to full dynamics engines like DART.[24] Tunable parameters, such as solver iterations and maximum step size, allow trade-offs between simulation fidelity and computational efficiency across all engines.[22]Rendering System
The rendering system in Gazebo is responsible for providing 3D visualization of simulated worlds, models, and their interactions, leveraging OpenGL-based rendering to generate realistic graphics for user observation. It abstracts the underlying graphics pipeline, allowing simulations to display dynamic environments with high fidelity while maintaining compatibility across different hardware configurations. This system operates independently of other simulation components, ensuring smooth visual feedback even when computational demands vary.[12] In Gazebo Classic, the rendering is powered by the OGRE engine (version 1.x), which handles scene management, including the loading and organization of visual elements such as models and environments. OGRE enables advanced features like dynamic lighting, shadow casting, texture application for surface realism, and multiple camera views for user navigation through the simulated space. These capabilities allow for immersive representations of robot interactions, with the engine optimizing rendering calls to support interactive exploration.[25] Modern Gazebo, through the gz-rendering library, introduces a more modular approach with plugin-based backends such as OGRE2 (OGRE-Next) and Vulkan, providing greater flexibility and performance improvements over the classic version. This library supports headless mode, enabling rendering without a graphical display for continuous integration testing and server-based simulations. Key features include texture mapping for detailed material properties, particle effects for simulating phenomena like smoke or debris via the Ogre2 particle system, GUI overlays for interactive elements, and level-of-detail (LOD) optimizations to efficiently handle large-scale scenes by reducing polygon counts at distance. Additionally, shader support allows for custom visual effects, such as procedural textures or advanced lighting models.[12][26] The rendering pipeline is decoupled from the physics simulation, permitting independent update rates to achieve real-time visualization, typically targeting 30 frames per second (FPS) for smooth display regardless of physics timestep complexity. This separation, facilitated by inter-process communication via Gazebo Transport, ensures that visual updates remain fluid, enhancing usability in research and development workflows.[27]Sensor and Actuator Simulation
Gazebo simulates a wide array of sensors to replicate robot perception in virtual environments, enabling realistic data generation for algorithms in robotics research and development. Supported sensor types include cameras for RGB and depth imaging, LIDAR for distance measurement, inertial measurement units (IMUs) for orientation and acceleration, global positioning system (GPS) sensors for navigation, and contact sensors for collision detection.[28] These models draw from real-world hardware behaviors, with over 20 distinct sensor types available through the Gazebo Sensors library, allowing users to configure parameters like field of view, resolution, and update rates directly in simulation description format (SDF) files.[29][30] To enhance realism, Gazebo incorporates noise models into sensor outputs, preventing idealized data that could mislead algorithm training. For instance, Gaussian noise is added to camera pixels across color channels, with configurable mean (typically 0.0) and standard deviation (e.g., 0.007 for high-quality sensors), clamped between 0.0 and 1.0 to simulate amplifier noise.[31] Similarly, LIDAR rays receive Gaussian perturbations on range measurements, while IMUs model both noise and bias in angular rates and linear accelerations using Gaussian distributions—for example, noise standard deviation of 2×10^{-4} rad/s for rates and 1.7×10^{-2} m/s² for accelerations, with bias sampled once per simulation.[31] Plugins extend this capability, permitting custom noise implementations, such as environmental effects like wind gusts that perturb IMU readings to mimic aerial disturbances.[28] Actuator simulation in Gazebo focuses on emulating motor and joint behaviors for robot action, integrated with the underlying physics but specialized for control interfaces. Joint controllers manage torque application with limits to prevent unrealistic forces, alongside velocity profiles that enforce smooth motion trajectories.[32] For stability, proportional-integral-derivative (PID) controllers are employed, with tunable gains—such as proportional gain of 100.0, integral of 0.01, and derivative of 10.0—applied to position or velocity commands, ensuring responsive yet damped responses in multi-joint systems.[32][33] Sensors and actuators integrate seamlessly within Gazebo's event-driven architecture, where sensors publish generated data to transport topics (e.g.,/imu for IMU readings or /lidar for scan points), and actuators subscribe to command topics for inputs like target positions.[34] This data flow supports interoperability, such as with ROS via brief topic bridging for perception-action loops. LIDAR simulation exemplifies this through GPU-accelerated ray casting, computing distances as the minimum intersection point along each emitted ray from the sensor origin to scene geometry:
d = \min \{ t \mid \mathbf{o} + t \mathbf{r} \in \mathcal{G} \}, \quad t > 0
where d is the measured distance, \mathbf{o} the ray origin, \mathbf{r} the unit direction vector, \mathcal{G} the set of geometric surfaces, and t the parameter along the ray.[30] This approach yields point clouds with configurable ray counts (e.g., 640 horizontal samples), clamped to the sensor's maximum range for accurate environmental mapping.[34]
Key Features
World and Model Management
In Gazebo, simulation environments, known as worlds, are defined using XML-based Simulation Description Format (SDF) files, typically with a .world extension. These files encapsulate the overall scene, including static and dynamic elements such as terrain, lighting, and actors. For instance, terrain can be incorporated by including pre-built model files via the<include> tag, pointing to URDF or SDF assets from repositories like Gazebo Fuel, while lights are specified using the <light> element with attributes for type (e.g., directional or point), pose, and attenuation properties to simulate realistic illumination. Actors, representing animated entities like walking humans, are added similarly through model includes, allowing for scripted paths or behaviors within the world.[35]
To optimize performance in resource-intensive simulations, Gazebo supports dynamic loading and unloading of world components, particularly models, based on the spatial proximity to active performers such as robots. This feature, often implemented via the Levels system, partitions large environments into manageable sections, automatically creating or removing entities and their associated physics and rendering components as the simulation progresses, thereby reducing computational overhead without manual intervention. In expansive worlds, this mechanism effectively culls distant assets, maintaining real-time factors above 1.0 even in scenarios with thousands of objects.[36][37][4]
Robot and object models in Gazebo are described using reusable SDF or URDF files, which detail the kinematic and geometric structure for simulation. URDF files, prevalent in ROS ecosystems, are automatically converted to SDF upon loading and include specifications for links (rigid bodies), joints (connections enabling motion), visual geometries (for rendering appearance), and collision shapes (for physics interactions). These models promote modularity, allowing users to spawn identical instances multiple times within a world, such as deploying fleets of drones, while ensuring consistent behavior across simulations.[7][38]
Model management is facilitated through Gazebo's API and the Fuel database, an open repository for sharing and versioning SDF/URDF assets. Users can spawn models dynamically via transport services like /world/<world_name>/create, specifying parameters such as file path, initial pose, and name, or destroy them using corresponding delete services to free resources during runtime. The Fuel platform enables community contributions and downloads, with models tagged for compatibility; for example, hierarchical structures—where a parent model nests sub-assemblies like a robot arm with gripper components—are supported in SDFormat, allowing complex assemblies without flattening the description.[39][40][7] This versioning ensures backward compatibility while introducing features like nested <model> elements for improved organization in large-scale designs. Automatic asset culling extends to models in vast worlds, leveraging spatial hashing to unload inactive sub-assemblies, which is crucial for maintaining simulation fidelity in multi-robot or expansive terrain scenarios.[41]
Plugin Architecture
Gazebo employs a plugin-based architecture that enables extensibility by allowing users to load custom code at runtime to modify simulation behaviors without altering the core simulator. Plugins are primarily implemented as C++ shared libraries, with support for Python through bindings, and are dynamically loaded during simulation initialization. This design facilitates the integration of specialized functionality across various aspects of the simulation, such as physics processing, sensor simulation, and environmental effects.[27] The primary plugin type in modern Gazebo is the system plugin, which can be attached to specific entities including the world, models, sensors, or actors to provide targeted behaviors. World-attached system plugins handle global environmental effects, such as wind simulation that influences all objects in the scene. Model-attached plugins manage per-robot functionalities, for instance, gait generators or joint controllers that dictate movement patterns for individual robotic models. Sensor-attached plugins enable custom data generation and processing, while actor plugins support scripted behaviors for non-physics entities like crowds.[42][43] Development of plugins involves implementing interfaces from the Gazebo Sim library, such asISystemPreUpdate, ISystemUpdate, and ISystemPostUpdate, which provide callbacks executed at different simulation stages—equivalent to event-driven hooks like OnUpdate in earlier versions. These interfaces grant access to the Entity Component Manager (ECM) for reading or modifying entity states, components, and simulation data. Plugins are registered using macros like GZ_ADD_PLUGIN and loaded via SDF file specifications under the relevant entity, with paths configurable through environment variables like GZ_SIM_SYSTEM_PLUGIN_PATH. Examples include the ROS bridge plugins from the ros_gz package, which embed ROS 2 nodes within system plugins to enable seamless communication between Gazebo topics and ROS messages, such as publishing sensor data or subscribing to control commands.[42][44][8]
This modular approach ensures that Gazebo's core remains lightweight, as plugins can be selectively included or excluded, promoting reusability and community contributions for diverse simulation needs.[27]