Gazebo

Gazebo is an open-source 3D robot simulator maintained by Open Robotics and closely integrated with ROS 2. It simulates rigid-body physics, sensors such as cameras, depth cameras, lidar, IMUs, and GPS, and the environments robots work in, letting teams develop navigation, manipulation, and perception software and run repeatable tests without hardware. The modern simulator — known for a time as Ignition and now simply Gazebo (gz sim) — replaced Gazebo Classic, which reached end of life in January 2025.

Gazebo is described with SDF (Simulation Description Format) worlds, extended with systems (plugins) for physics, sensors, and control, and connected to ROS 2 through ros_gz bridges. Used well, it becomes part of the development loop and CI; used carelessly, it produces optimistic results from perfect sensors and unrealistic physics.

TL;DR

Quick Example

A minimal SDF world with explicit physics settings and a noisy lidar:

Running it headless (as in CI) and bridging the scan to ROS 2:

Core Concepts

SDF Worlds and Models

SDF describes worlds (physics, lighting, models, plugins) and models (links, joints, inertia, collision and visual geometry, sensors). Robots described in URDF for ROS can be spawned directly; Gazebo converts them to SDF, using <gazebo> extension tags for sensors and plugins. Accurate inertial values and simplified collision shapes matter more for realistic behavior than detailed visuals.

Physics

Gazebo supports pluggable physics engines (DART by default, with Bullet and others available). Key settings:

Contact-rich tasks such as grasping are sensitive to these parameters; validate against hardware. For high-fidelity contact dynamics in control research, many teams use MuJoCo.

Sensors and Noise

Sensor systems simulate cameras, depth and RGB-D cameras, GPU lidar, IMU, magnetometer, air pressure, NavSat (GPS), contact, and force-torque sensors. Configure update rates, ranges, resolutions, and noise to match datasheets, and inject faults through custom systems. Perfect simulated sensors are the most common cause of perception code that passes in simulation and fails in the field. See Robot Perception and Sensing.

ROS 2 Integration

These pieces let Nav2 and MoveIt run unchanged against simulated robots.

Testing and CI

Run Gazebo headless in containers, launch fixed worlds and scenario parameters, record results and ROS bags, and assert on outcomes (goal reached, minimum clearance, no collisions). Pin Gazebo, ROS, and model versions; download Fuel assets ahead of time so tests do not depend on the network. See Robot Simulation and Validation and CI/CD.

Best Practices

Match Sensors to Hardware

Copy rates, fields of view, ranges, and noise from datasheets and measured data.

Use Accurate Inertia and Simple Collisions

Derive inertia from CAD and use primitive or convex collision shapes.

Share Controller Configs With Hardware

Use gz_ros2_control so simulation exercises the same controllers and limits as the robot.

Make Runs Reproducible

Version worlds, pin assets locally, fix seeds, and run headless in CI.

Common Mistakes

Missing or Wrong Inertia

Forgetting Simulation Time

Network-Dependent Tests

FAQ

What is the difference between Gazebo and Gazebo Classic?

Gazebo (formerly Ignition) is the modern, modular simulator using gz tools and libraries. Gazebo Classic (version 11 and earlier) is the older monolithic simulator, which reached end of life in January 2025.

How do I connect Gazebo to ROS 2?

Use the ros_gz packages: ros_gz_bridge for topics and services, ros_gz_sim for launching and spawning, and gz_ros2_control to run ros2_control controllers on simulated joints.

What is SDF?

Simulation Description Format, an XML format describing worlds, models, physics, sensors, and plugins for Gazebo and other simulators.

Can Gazebo run in CI?

Yes. Run the server headless with headless rendering for camera and lidar sensors, launch scenario worlds, and assert on recorded outcomes.

Is Gazebo accurate enough for validation?

It is accurate enough for many integration and navigation tests, but contact-rich behavior, sensor realism, and timing need validation against hardware. Treat it as one stage of a validation ladder.

Related Topics

References