Gazebo is an open-source 3D robot simulator that models rigid-body physics, sensors, actuators and environments so that robot software can be developed and tested without physical hardware. In robotics simulation, it is the reference tool of the ROS ecosystem: the same nodes that drive a real robot can be connected to a simulated one and exercised in a repeatable virtual world.
Gazebo originated at the University of Southern California in 2002 and is maintained today by Open Robotics and its community under the Apache 2.0 license. The name now refers to the modern, modular Gazebo (formerly Ignition), while the original monolithic simulator is called Gazebo Classic and reached end of life in January 2025.
How Gazebo simulates a robot
Gazebo runs a simulation loop that advances the world in fixed time steps. At each step the physics engine integrates forces, joint torques and contacts, sensor plugins generate synthetic measurements from the updated scene, and controller plugins or external programs read those measurements and send new commands. A rendering engine draws the scene for cameras and for the user interface.
Worlds and robots are described in SDFormat (Simulation Description Format), an XML format that covers links, joints, inertia, collision and visual geometry, sensors, lights and plugins. Robot models written in URDF, the common ROS description format, are converted to SDFormat on loading. Ready-made models of robots, objects and buildings can be downloaded from the Gazebo Fuel repository.
The modern Gazebo uses an entity-component-system architecture: every model, link and sensor is an entity, its properties are components, and behavior is added by system plugins loaded at runtime. The simulation server and the graphical client are separate processes, so the server can run headless on a build machine for automated tests.
The table lists the main building blocks of a Gazebo setup.
| Component | Role | Typical options |
|---|---|---|
| Physics engine | Dynamics, contacts and joint constraints | DART (default), Bullet, TPE; ODE in Gazebo Classic |
| Rendering engine | Camera images and visualization | OGRE 2 in modern Gazebo |
| Description format | Worlds, models and sensors | SDFormat; URDF converted on load |
| Transport layer | Messaging between server, GUI and tools | Gazebo Transport with Protobuf messages |
| ROS integration | Connects simulation to ROS 2 nodes | ros_gz bridge and launch packages |
Simulated sensors and the real-time factor
Gazebo ships plugins for the sensors most robots carry. Each sensor publishes data at a configured update rate and can add Gaussian noise or other artifacts so that perception and estimation code is not tested against unrealistically clean data.
| Sensor | Simulated output | Typical use |
|---|---|---|
| Camera and depth camera | RGB images, depth images, point clouds | Object detection, visual odometry |
| GPU lidar | Range scans from ray casting | Mapping, localization, obstacle detection |
| IMU | Angular velocity and linear acceleration | State estimation, balance control |
| Contact and force-torque | Contact points, wrench at a joint | Grasping, legged locomotion |
| NavSat and magnetometer | Geographic position, field direction | Outdoor navigation of field robots |
The real-time factor (RTF) is the ratio of simulated time to wall-clock time. With the common default of a 1 ms physics step and 1,000 steps per second, the target RTF is 1.0. Heavy scenes, many lidars or small step sizes push RTF below 1.0, which is acceptable for testing because ROS 2 nodes can follow the simulated clock instead of the system clock.
Gazebo versions and ROS 2 pairing
Modern Gazebo releases carry alphabetical names, and long-term support releases are paired with ROS 2 distributions. Choosing the officially paired release avoids building the ROS bridge from source and resolves most compatibility issues.
| Release | Type | Typical ROS 2 pairing |
|---|---|---|
| Gazebo Classic 11 | Legacy simulator, end of life in 2025 | ROS 1 Noetic, ROS 2 Humble with extra packages |
| Gazebo Fortress | Long-term support | ROS 2 Humble |
| Gazebo Harmonic | Long-term support | ROS 2 Jazzy |
| Gazebo Ionic | Short-term release | Newer non-LTS ROS 2 distributions |
Migration from Gazebo Classic is not a drop-in replacement. Plugin APIs, topic names and some SDFormat tags changed, so teams typically port custom plugins and switch from the old gazebo_ros packages to the ros_gz packages.
Gazebo compared with other robot simulators
Gazebo is a general-purpose robot simulator optimized for ROS integration and open development rather than for photorealism or massively parallel training. The comparison below shows where it fits among common alternatives.
| Simulator | Main strength | Typical use | Main constraint |
|---|---|---|---|
| Gazebo | Deep ROS 2 integration, open source | System and integration testing | Moderate visual realism |
| Isaac Sim | Photorealistic rendering, GPU physics | Synthetic data, large-scale learning | Requires NVIDIA RTX hardware |
| MuJoCo | Fast, accurate contact dynamics | Reinforcement learning, control research | Limited sensor and world tooling |
| Webots | Easy setup, many built-in robots | Education, rapid prototyping | Smaller ROS 2 ecosystem |
Limitations and common mistakes
Simulation results are only as good as the model behind them, and the sim-to-real gap is the main risk when relying on Gazebo.
- Wrong inertia values: copying visual meshes without correct mass and inertia tensors makes robots tip over or vibrate.
- Overly detailed collision meshes: high-polygon collision geometry slows physics sharply; primitive shapes are usually sufficient.
- Idealized contacts: friction, wheel slip and soft contacts are approximations, so grasping and legged gait need validation on hardware.
- Ignoring the simulated clock: nodes that use wall time misbehave whenever the real-time factor drops below 1.0.
- Noise-free sensors: perception that works only on clean simulated data often fails on the first real dataset.
In simple terms
Gazebo is a virtual test track for robots. It builds a 3D world on a computer, places a model of the robot in it and imitates gravity, collisions, cameras and laser scanners.
The robot software cannot tell that it is driving a simulated machine. Developers can therefore test new code safely, quickly and many times over. Crashes in Gazebo cost nothing, while crashes of a real robot cost time and money. Final testing still happens on the real machine, because no simulation is perfect.
A practical example
A team building an autonomous mobile robot for warehouses models its differential-drive base in SDFormat, adds a 2D lidar at 10 Hz, an IMU and a depth camera, and loads a world built from the floor plan of the customer site. ROS 2 Jazzy navigation runs unchanged against Gazebo Harmonic through the ros_gz bridge.
Every code change triggers a headless simulation job on the build server that drives the robot through fifty scripted missions with pallets, narrow aisles and walking pedestrians. A regression in the path planner that caused the robot to stall in tight corners was caught in simulation within an hour, before any field deployment. Remaining issues, such as wheel slip on a polished floor, were found and tuned during a short on-site test, which was considerably shorter than it would have been without simulation.