Robotics Simulators: The Axes They Actually Differ On
6 min read · updated August 3, 2026
A feature-by-feature simulator comparison is wrong within two release cycles. The architectural choices underneath are stable, they explain most of the differences people notice, and they are what you should be choosing on.
Six axes that decide everything
| Axis | Description |
|---|---|
| Contact formulation | How contact and friction are computed: a complementarity problem solved exactly or approximately, a soft contact with penetration-dependent forces, or a pressure-field formulation. This decides accuracy in contact-rich tasks and it decides stability at large timesteps. The deepest choice, and the one covered separately below. |
| Throughput and parallelism | Steps per second, and whether many environments run simultaneously on a GPU. This is the axis that turns an RL experiment from a month into an afternoon, and it is why GPU-parallel simulation reorganised the field around 2021. It is largely orthogonal to fidelity — the fastest simulators are not the most accurate. |
| Rendering fidelity | Whether images look like camera images: physically-based materials, ray tracing, correct sensor noise, lens distortion. Matters enormously if your policy consumes pixels and not at all if it consumes state. Also expensive — rendering often dominates step time once enabled. |
| Sensor modelling | Whether the simulated depth camera has the failure modes of a real one — holes on transparent and specular surfaces, flying pixels at edges, quantisation, latency. Most simulators return perfect depth by default, which trains a policy on a sensor nobody owns. |
| Determinism and reproducibility | Whether the same inputs give bit-identical outputs across runs and machines. Essential for regression testing and for any verification argument; frequently sacrificed for GPU parallelism, where reduction order varies. |
| Differentiability | Whether gradients flow through the physics, enabling gradient-based trajectory optimisation and system identification. Powerful where it applies and awkward exactly at contact, where the dynamics are discontinuous and the gradient is either undefined or misleading. |
Two axes usually fight each other: fidelity against throughput, and determinism against parallelism. Almost every practical simulator choice is a position on those two trades plus an ecosystem argument.
The contact model is the deepest choice
Everything about how a simulator handles touch descends from how it formulates contact, and there are three broad families.
Rigid contact with complementarity
Model bodies as perfectly rigid and express non-penetration and Coulomb friction as complementarity conditions — either the bodies are separated and the normal force is zero, or they touch and the force is non-negative. This is the physically principled formulation and it has two practical problems: the resulting problems can be expensive to solve, and, as the sim-to-real page notes, rigid-body contact with friction can admit multiple solutions or none at all.
Soft or relaxed contact
Allow a small penetration and generate a restoring force from it, or relax the complementarity conditions until the solver is well-behaved. Fast, stable at large timesteps, and the reason simulators in this family can run enormous numbers of environments. The price is that contact is slightly springy and slightly slippery in ways real contact is not, and a policy can learn to exploit that.
Pressure-field / hydroelastic contact
Compute a continuous pressure distribution over a contact patch rather than forces at a point, which gives smoother, better-conditioned contact torques and behaves more sensibly for area contacts — a box resting on a table, a gripper pad on a face. Drake’s hydroelastic contact model is the well-known implementation. More expensive, and aimed at people who care about being right rather than being fast.
If your task is decided during sustained contact, this axis is your decision and the rest is detail. If contact is incidental, pick on throughput and rendering and move on.
The tools, by design intent
Described by what each was built to do, which changes far more slowly than what each currently supports. Check current capabilities against the project’s own documentation before committing — this list is a map of intent, not a feature matrix.
| Simulator | Description |
|---|---|
| MuJoCo | Built for fast, stable simulation of articulated systems with contact, using a soft-constraint formulation designed to stay well-behaved at large timesteps. Long the default for continuous-control research because it is fast, robust and easy to differentiate against experimentally. Open source since 2021. |
| Bullet / PyBullet | A general-purpose physics engine from the games and film world, adapted for robotics. Broad format support, wide adoption, very easy to start with, and a contact model tuned historically for plausibility and speed rather than for metrological accuracy. |
| Isaac Sim / Isaac Lab | Built around GPU-parallel simulation and high-fidelity rendering together, aimed at training policies at scale with photorealistic observations. The design intent is throughput in the thousands of environments, which is the axis that makes large RL runs practical. |
| Gazebo | The long-standing ROS-ecosystem simulator, designed for whole-system simulation — sensors, plugins, multiple robots, integration with the middleware you deploy with. Its strength is that it simulates your system rather than just your physics. |
| Drake | Built for model-based design, analysis and verification, with an emphasis on being correct and inspectable: multibody dynamics with hydroelastic contact, and a systems framework aimed at people who want to prove things about controllers. |
| Brax and other differentiable engines | Physics written in an autodiff framework so gradients flow through the dynamics and simulation runs on accelerators alongside training. Excellent for gradient-based control and for very high throughput; contact is where the differentiability story is weakest. |
| SAPIEN, Habitat and scene-centric simulators | Built around environments rather than around physics — articulated household objects, large photorealistic indoor scenes, embodied navigation and interaction tasks. Chosen when the asset library and scene scale are the thing you need. |
Choosing by what you are doing
- Locomotion RL. Throughput dominates. You need millions of steps and the contact requirements are relatively forgiving — the ground is flat-ish, contacts are brief, and actuator modelling and randomisation do more for transfer than contact fidelity does. Pick GPU-parallel.
- Contact-rich manipulation. Contact formulation dominates. Insertions, sliding and in-hand reorientation are where soft-contact artefacts become policies that only work in simulation. Pick for the contact model and accept the slower steps.
- Perception training. Rendering and sensor modelling dominate. If the policy consumes pixels, physics accuracy matters less than whether the images have the statistics of real ones — and whether you can randomise them widely.
- Navigation and scene understanding. Scene scale and asset library dominate. You need many diverse buildings more than you need accurate friction.
- Verification and regression testing. Determinism dominates, with contact fidelity second. A test that gives a different answer on a different machine is not a test.
The trap
The failure mode is treating the simulator as the source of truth. It is a hypothesis generator: it narrows the search cheaply and it does not settle anything. Three habits keep that honest.
First, hold out reality. Whatever you tune in simulation, the acceptance criterion lives on hardware, and the hardware number is the one you report. Second, randomise the parameters you cannot measure rather than picking a plausible value — a single plausible friction coefficient is a guess dressed as a fact, and randomising over an interval is an honest representation of what you know. Third, treat a simulated leaderboard as measuring the simulator: a policy ranking established purely in simulation says which policy best exploits that contact solver, which is a real fact about a piece of software and not the fact you wanted. That is the same reasoning as why a benchmark result does not transfer to your workload, with a physics engine in place of a test set.