Which physics engine should Gazebo use by default for real‑time simulation?
0 reputation · 25 Aug 2020, 00:07 UTC
0 reputation · 25 Aug 2020, 00:07 UTC
Goal: Identify the physics engine that should be set as Gazebo’s default so that typical simulations maintain a real‑time factor (RTF) of at least 1.0 without sacrificing numerical stability in multi‑body contact scenarios.
Constraint: RTF measurements can be inflated by GUI rendering, making headless execution preferable for isolating physics bottlenecks, and the default engine differs between Gazebo releases (e.g., ODE in Gazebo 9, Bullet in Gazebo Harmonic), which adds version‑specific uncertainty.
Uncertainty: It is unclear whether switching the default from ODE to Bullet yields a measurable RTF improvement for complex contacts, how the trade‑off between stability and CPU load varies across versions, and what RTF threshold should guide the selection decision.
Does changing the default physics engine from ODE to Bullet improve the RTF for typical contact‑rich worlds? Which version‑specific trade‑offs between stability and computational load should be considered when choosing the default? Should the selection be based on a headless‑measured RTF target of 1.0 or higher?
34775 reputation · 25 Aug 2020, 09:28 UTC
For most contact‑rich, real‑time workloads, Bullet is the reasonable default on modern Gazebo releases (Harmonic and later already ship it as the default). Keep ODE as the fallback when a specific world shows contact instability under Bullet, and make the decision from a headless‑measured RTF target of 1.0 or higher on a representative world — not from the GUI's reported number.
Confirmed: Gazebo 9 and earlier defaulted to ODE; newer Gazebo (the gz generation, e.g., Harmonic) defaults to Bullet. RTF shown in the GUI conflates rendering load with physics cost, so GUI numbers can be misleading in either direction.
Likely, but workload‑dependent: Bullet tends to sustain a higher RTF in contact‑heavy scenes because of its optimized collision pipeline and better use of modern CPUs, while ODE can be more numerically forgiving for certain stiff multi‑body contact configurations. This is a tendency, not a guarantee — results vary with world complexity, contact count, solver iterations, and CPU. Treat any single benchmark as evidence only for the world you tested.
gz sim -s -r --physics-engine gz-physics-bullet-plugin your_world.sdf\ngz sim -s -r --physics-engine gz-physics-ode-plugin your_world.sdf(Exact plugin names vary by release; check gz sim --help or your installed gz-physics plugins.) Monitor RTF from the server output or by timing against /clock, and watch CPU with top in parallel.
Whether ODE→Bullet yields a measurable RTF gain for your worlds is genuinely uncertain without your benchmark — published tendencies may not transfer. The defensible policy: default to Bullet on current releases, gate the choice on headless RTF ≥ 1.0 on your representative world, and fall back to ODE per‑world when contact stability degrades. If your worlds are dominated by a few stiff, high‑precision contact chains rather than many simultaneous contacts, run the ODE comparison before committing — that is the one case where the answer can flip.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.