Diagnosing Exploding Gazebo Simulations: Inertials, Solver Steps, and Contacts

Your robot spawns, vibrates for a second, then launches itself into the sky — or it sinks through the ground plane while the real-time factor (RTF) collapses to 0.1 and the CPU pegs at 100%. This "exploding simulation" pattern in Gazebo almost always traces back to one of three causes: bad inertial parameters, an unstable physics solver configuration, or violent contact behavior. The useful takeaway: fix inertials first because they cost nothing, then trade computation for stability with solver settings, and only then suspect plugins or controllers.

This guide applies to both Gazebo Classic and the newer Gazebo Sim (formerly Ignition) line, but configuration syntax and defaults differ between them and between physics engines (ODE, Bullet, DART). Confirm which line and engine your project uses before copying values from another project's world file.

Recognizing the condition

The failure has a few recognizable signatures:

• Models jitter in place or slowly drift without any applied force.
• Links separate or the model flies apart immediately on spawn.
• Bodies penetrate the ground plane or each other, then snap apart violently.
• RTF drops far below 1.0 while CPU usage stays high — the solver is burning iterations on pathological contacts.

Cause and diagnostic table

Ordered checks

Work through these in order — the cheap, high-probability causes come first. Change one variable at a time and re-run the same scenario after each change, otherwise you won't know what fixed it.

1. Inspect inertials and masses. Every link needs an <inertial> block with a plausible mass and an inertia tensor consistent with that mass and the link's geometry. A 10 kg link with an inertia tensor on the order of 1e-6 makes the equations of motion numerically stiff, and the integrator responds with wild accelerations. For a solid box of mass m and dimensions (x, y, z), the diagonal terms are approximately m(y²+z²)/12, m(x²+z²)/12, m(x²+y²)/12 — compute these and compare against what's in your SDF/URDF. Values orders of magnitude off are your bug.
2. Check for interpenetrating collisions at spawn. In the Gazebo GUI, enable collision visualization (View menu, or the collision display toggle depending on version). If two collision bodies overlap at the initial pose, the contact solver sees deep penetration on the first step and generates enormous restoring forces. Offset the spawn pose or shrink the offending geometry.
3. Lower max_step_size. The classic default is 0.001 s; if someone scaled it up to 0.01 to speed things up, contacts become under-resolved and the simulation gains energy each step. Halve it and observe. If stability returns, you've found a solver-resolution problem — though note this may be masking a bad inertial from step 1.
4. Raise solver iterations. If contacts still look spongy or jittery at a reasonable step size, increase the solver iteration count (the exact element name and location differ between Gazebo Classic's <physics> block and Gazebo Sim's configuration — check your version's documentation). More iterations let the constraint solver converge; the cost is CPU time per step.
5. Simplify collision geometry. Replace detailed visual meshes used as collisions with primitives (box, cylinder, sphere) or a heavily decimated convex hull. Mesh-mesh contact is both slow and prone to deep-penetration spikes. Keep the detailed mesh in <visual> only.
6. Profile. Watch the RTF readout in the GUI status bar and, where available, physics diagnostics showing iteration counts and step timing. A fix that restores stability but drops RTF from 0.9 to 0.3 is a real cost you should record and weigh.

Fixes mapped to findings

Bad inertials: correct the values in the model file. This costs nothing computationally and is the only fix that addresses root cause when the tensor is wrong. A minimal sane link looks like this in SDF (values for a 2 kg box, 0.2 × 0.1 × 0.1 m):

<link name="base">
  <inertial>
    <mass>2.0</mass>
    <inertia>
      <ixx>0.0033</ixx> <ixy>0.0</ixy> <ixz>0.0</ixz>
      <iyy>0.0067</iyy> <iyz>0.0</iyz>
      <izz>0.0067</izz>
    </inertia>
  </inertial>
</link>

Solver instability: reduce max_step_size and/or raise iterations. This is a deliberate trade: you are buying stability with real-time performance. Record the before/after RTF so the trade is explicit.

Contact problems: moderate extreme kp/kd values (defaults exist for a reason; orders-of-magnitude increases create stiff contact springs that inject energy), eliminate spawn interpenetration, and simplify collision shapes. Simplifying collisions trades contact fidelity for speed — acceptable for wheels and chassis, less so for a gripper that must grasp small parts.

Verifying the fix

Reproduce the original failure in a minimal world: just the suspect model and a ground plane, no controllers or plugins. Toggle one variable at a time. Confirm the model now rests stably for at least a minute of simulated time with no drift or jitter, and note the RTF before and after each change. If your version supports multiple physics engines, run the same world under a different one — stability under DART but explosion under ODE (or vice versa) points at engine-specific contact behavior rather than your model.

When to escalate

If the model is still unstable after inertials, spawn interpenetration, step size, iterations, and collision geometry have all been checked, the suspect list shifts: a plugin applying forces (a buggy thrust or hydrodynamics plugin can inject unbounded energy), joint controller gains that are too aggressive, or an engine-specific bug. At that point, strip the minimal world further — remove plugins one at a time — and only then file a report, attaching the minimal world and noting the Gazebo version and physics engine. A report that reproduces with a stock engine and a 50-line world gets diagnosed; one requiring your full robot stack usually doesn't.