Gazebo Sensor Noise: Built‑In vs Custom Plugins

When a controller tuned on pristine simulated data meets a real robot, the mismatch often shows up as jitter, bias, or unexpected drift. The root cause is frequently the sensor model: the simulation is feeding ideal measurements while the hardware delivers noisy signals. The takeaway is that you can close this gap by shaping the sensor output directly in Gazebo’s System Description Format (SDF) before the data ever leaves the simulator.

How Gazebo Sensors Work in SDF

In Gazebo Sim (the current Ignition‑based simulator), a <sensor> tag in an SDF world file does more than attach a visual; it instantiates a sensor plugin that runs alongside the physics loop. The plugin reads raw physics data (e.g., accelerations, laser ranges) and can apply noise, bias, or frequency filtering before publishing the topic on the Gazebo Transport layer. This keeps the physics engine untouched while letting you tailor the sensor’s output.

Built‑In Noise vs. Custom Plugins

Gazebo ships with ready‑made noise models for common sensors: Gaussian noise for IMUs, uniform noise for depth cameras, and so on. These are configured with a <noise> block inside the <sensor> element and are sufficient when the hardware’s error characteristics are well approximated by a simple distribution. If your sensor exhibits traits that the built‑in blocks cannot capture—such as temperature‑dependent bias, non‑linear scale factors, or bursty drop‑outs—you must write a custom plugin. A custom plugin is a C++ (or Python) class that inherits from the appropriate sensor system, receives the raw data, applies your own math, and then forwards the result.

Worked Example: Adding Gaussian Noise to an IMU

The following SDF snippet defines an IMU sensor named imu_sensor on a model called my_robot. It sets a 200 Hz update rate and injects independent Gaussian noise with a standard deviation of 0.02 m/s² on the linear axes and 0.001 rad/s on the angular axes.

<sdf version='1.9'> <model name='my_robot'> <link name='base_link'> <sensor name='imu_sensor' type='imu' update_rate='200'> <pose>0 0 0.1 0 0 0</pose> <plugin filename='gz-sim-imu-System' name='gz::sim::systems::ImuSensor'> <noise type='gaussian'> <mean>0 0 0 0 0 0</mean> <stddev>0.02 0.02 0.02 0.001 0.001 0.001</stddev> </noise> </plugin> </sensor> </link> </model> </sdf>

After loading the world, you can check that the topic is active and that the noise is present.

Verifying the Stream and Spotting Problems

1. Start the simulation: gz sim -s world.sdf
2. List transport topics: gz topic -l. You should see a topic like /model/my_robot/link/base_link/sensor/imu_sensor/imu.
3. Echo a few samples: gz topic -e /model/my_robot/link/base_link/sensor/imu_sensor/imu. If the robot is stationary, the linear acceleration values should fluctuate around zero rather than stay fixed at 9.81 m/s² on the Z axis.
4. Watch the Gazebo console for lines such as [ImuSensor] Plugin loaded successfully. Any Plugin load failed message indicates a filename or name mismatch.

Trade‑offs and Practical Checks

Increasing update_rate improves fidelity but raises the plugin’s CPU load. If the physics step size (set in the <physics> block) is much larger than the sensor’s period, the simulator may drop cycles and fall behind real‑time. A quick way to detect this is to monitor the real‑time factor shown in the Gazebo window; values consistently below 1.0 mean the simulation cannot keep up.

Another limitation is that the built‑in Gaussian model assumes stationary, independent noise. Real IMUs often show bias drift that changes with temperature or sudden spikes from magnetic disturbances. Capturing those effects requires a custom plugin that reads a temperature sensor or applies a time‑varying bias model. Before relying on the simulated noise, compare the statistical properties (mean, variance, autocorrelation) of the logged topic with a dataset recorded from the actual hardware under the same static conditions. If the distributions diverge, adjust the SDF noise parameters or extend the plugin.

Actionable Checklist

• Define the sensor in SDF with a sensible update_rate (start with 100‑200 Hz).
• Add a <noise> block for Gaussian or uniform noise; verify the values with the gz topic -e command.
• If the hardware’s error profile is more complex, prototype a custom plugin that subscribes to the raw topic, applies your model, and republishes on a new topic.
• Run the simulation, check the real‑time factor, and ensure the plugin loads without errors.
• Collect a short hardware log, compute mean and variance, and compare to the simulated topic; iterate on the noise parameters until they match within an acceptable tolerance.

By treating the sensor model as a configurable part of the simulation rather than an afterthought, you give your control algorithms a realistic data diet early in development, reducing surprises when the code finally runs on the robot.