MuJoCo is Google DeepMind's physics engine. DeepMind acquired it in October 2021 as "the physics simulator of choice for DeepMind's robotics team" and made it free for everyone (Google DeepMind, 2021), then released its whole codebase as open source in May 2022 (Tassa and Tunyasuvunakool, 2022). Google DeepMind maintains it on GitHub, and builds on it: MuJoCo Playground, Google DeepMind's work with UC Berkeley, the University of Toronto and the University of Cambridge, trains robots in it (Zakka et al. 2025). Its physics is published, from its first paper (Todorov, Erez and Tassa 2012) to its convex contact model (Todorov 2014). A mature engine with a published model is the strongest second test the Senua AI Robotics Core could take after Meta's SuperDex Physics.
Senua AI's Measure held Google DeepMind's MuJoCo, one of the most widely used physics engines in robotics, to the laws of physics and to the problems its users report: 21 issues, 20 counted once each. It fixed sixteen of them, each fix proven in a pre-registered study, and then proved the fixes together as one set:
- Held objects now hold. A cube pushed with 60% of what friction can hold crept 1.3 mm every second. With Senua AI it holds: 0, up to 95% of the limit, and a gripped cube to within 1 micrometre a second. An arm resting on its tip crept up to 0.7 mm a second in some poses; with Senua AI's patch it holds at 0 in every pose played, set down or dropped. A free cube pushed square to a face at 95% of its limit, which still crept 1.5 mm a second, holds at 0 with two more options MuJoCo already has, chosen and proven by Senua AI.
- Friction no longer depends on direction. A cube slid at 45 degrees went 42% further than along an axis. With Senua AI's patch, the same slide in every direction played, to the micrometre.
- A robot arm ends where it should, however its scene file is written. The same arm, started in the same place, ended up to 25.6 mm apart. With Senua AI's patch, 0 nm apart, for contacts, joint limits, joint friction,
connectandweld. - A joint held by friction holds. Held level by friction half again its load, a joint turned 1.5 degrees a second, and under the elliptic cone with noslip a two-link arm held by joint friction still crept up to 0.4 mm a second. With 100 noslip iterations in place of 10, an option MuJoCo already has, the joint holds at 0 and the arm at 3 micrometres a second, every contact play unchanged.
- A sliding body stays on the ground. Under MuJoCo's elliptic cone a cube slid at 0.81 m/s rose 4.4 mm off the ground at a 10 ms step and, free to turn, slid up to 1.9% further along some directions than others, drifting off its line and turning. With Senua AI's patch, de Saxce's correction, it never leaves the ground and slides the same along every direction, to the micrometre, while every held object is held exactly as before. With noslip on it tipped a stack of nine cubes, a cost later traced to MuJoCo's own box-on-box collision and fixed (below).
- A straight stack stands. Under the elliptic cone with noslip, stacks of nine and twelve cubes tilted up to 10.9 mrad at some steps and stood at others. Senua AI's Measure traced it to MuJoCo's box-on-box collision, which adds contacts along a face's edges when equal cubes stand straight and drift. With Senua AI's patch every straight stack played stands, its contacts never changing.
- A box that should rest comes to rest. MuJoCo's own test scene with rolling friction and noslip never came to rest: its box rocked onto an edge every six steps, at up to 77 mm a second. With Senua AI's patch to noslip's rolling friction it comes to rest, and three fresh boxes too, at every step and noslip setting played.
- A joint held by friction no longer drags what it is coupled to. With noslip, a joint its friction held stayed still while a joint coupled to it moved and stayed moved, up to 1.64 m in a second, as MuJoCo's users reported. With Senua AI's patch to noslip the coupling holds, under 1 micrometre apart, and everything without such a coupling plays exactly as before.
- A concave shape collides as itself. A ball dropped into a cup written as one mesh rested on a lid that is not there, 36 to 40 mm above the cup's floor. Written as convex parts, MuJoCo's documented remedy, chosen and proven by Senua AI, it rests on the floor, meshes and primitives alike to the nanometre.
- The step no longer decides the contact. Past MuJoCo's own stiffness guard a resting body sank deeper as the step grew, and a bounce depended on the step and could even create energy, throwing a cube higher than it fell. With a step of at most half the contact's time constant, and at most half its time constant times its damping ratio where a bounce matters, the depth is the same at every step to 1 part in 10,000 and the bounce the same to within 5%, never above the drop.
- A tumbling body keeps its energy. MuJoCo's default integrator added up to 3.4% to a body tumbling with nothing acting on it. MuJoCo's own RK4, chosen and proven by Senua AI, keeps its energy and angular momentum at every step.
- A stack stands without sinking or turning. Stacked cubes sank up to 0.9 mm at a contact under the elliptic cone, and three cubes set each over the one below leaned up to 5.4 mrad and, under noslip, kept turning. With impratio and a contact as stiff as MuJoCo allows, both options it already has, chosen and proven by Senua AI, every contact sinks at most 11 micrometres, every lean is under 0.05 mrad and every offset stack is at rest.
- Inverse dynamics agrees. With noslip holding friction exactly, inverse dynamics was off by the whole force friction holds, up to 34,723 N. Without noslip, every friction as stiff as MuJoCo allows, it agrees with the forward step to under a nanonewton, every hold, grip, arm and stack still holds, and friction creeps by a law Senua AI measured, under 2 micrometres a second at gravity's load. Friction held exactly under any load, or inverse dynamics: Senua AI's configuration comes in two forms, one for each.
- The same bytes on Intel and arm64. Google DeepMind's arm64 release departs from its Intel release in 50 of 114 plays, at the last digit, which a moving stack amplifies. Senua AI's Measure traced it to the compiler fusing a multiply and an add into one rounding, which IEEE 754 allows (IEEE 754-2019). Built from its source with gcc, or with clang and fused multiply-add off, MuJoCo makes the same bytes on both, and so does Senua AI's set (Study 24).
| Issues, 20 counted once each | Fixed and validated | No departure where measured | Outside this deep dive |
|---|---|---|---|
| 21 | 16 | 3 | 1 |
Better than the fixes already out there. Others have proposed fixes for several of these, a MuJoCo pull request among them. Senua AI's Measure held each one it could play to the same answers as Senua AI's own, and below each is set beside Senua AI's with its pros and cons as measured. For a held object that creeps, only Senua AI's fix held every rule (Study 11). Every run is public on GitHub: github.com/senuamedia/senua-mujoco-accuracy.
What Senua AI found and fixed in MuJoCo
| MuJoCo 3.16.0 as released | What the Senua AI Robotics Core measured | With Senua AI |
|---|---|---|
| Friction has a direction under the default friction cone | A cube slid at 30 degrees to the cone's axes goes 30% further than along an axis and leaves its line by 23 mm; at 45 degrees (run 003), 42% further. Pushed along 30 degrees with 85% of the friction it is rated for, a held cube slides away at 0.3 m/s | Corrected. Senua AI's patch gives the same slide along every direction played to the micrometre, no drift, and the same hold as along an axis. Validated: 17 of 17 pre-registered rules (Study 1). MuJoCo's own test suite passes test for test with it off; with it on, four side effects to answer before merging (run 020); a third version answers them but the lift and passes every check and MuJoCo's whole suite (run 022); its three registered studies held 29, 29 and 31 of 32 rules, failing only by the runner and by a step or a percent that MuJoCo's own direction-free cone does not keep against its own pyramid (Study 3, Study 4, Study 6) |
| Nothing holds at rest | A cube pushed with 60% of what friction can hold creeps at 1.3 mm a second, at every step; a cube gripped between two pads with friction for twice its weight slips out at 6.1 mm a second (run 027) | Corrected by configuration. Senua AI's recommended configuration, two options MuJoCo already has (the elliptic cone with noslip), holds every load it was given, up to 0.95 of the limit, to 0 and removes the direction too; an arm resting on its ball crept in one pose of two (714 um/s) until Senua AI's patch, the friction solved in the directions that can move, held every pose, set down and dropped (validated in the set, 33 of 33 rules, Study 15); a cube that cannot turn, with condim 4 or 6, crept, until the friction solve's second version held all 108 holds (Study 21); a free cube pushed square to a face at 0.95 of its limit crept under noslip, 173 to 1,124 um/s, until impratio 1,000 and every contact's time constant at twice the step held it at 0 (Study 23). Validated: 11 of 11 pre-registered rules (Study 2), and replicated on fresh numbers with the grip held too, end to end with the patch below (Study 10), and the only fix in the wild that held every rule, beside MuJoCo's own options and pull request #3349's stiction (Study 11) |
| A sliding body leaves the ground | A cube set sliding at 1.2 m/s rises 10.8 mm off the ground at a 10 ms step, 0.8 mm at 2.5 ms | Friction makes it: the elliptic cone's convex relaxation of Coulomb friction (Anitescu 2006, Le Lidec et al. 2024); none of the cone, noslip, impratio, or the solref and solimp values MuJoCo documents removes it without a cost of its own (runs 016, 019). Corrected under the elliptic cone. Senua AI's patch, de Saxce's correction (de Saxce and Feng 1991), keeps the cube on the ground at every step. Validated: 43 of 43 pre-registered rules (Study 12), every hold and grip as released; two of MuJoCo's tests fail with it on, both traced in advance; with noslip it tipped a stack of nine the release keeps upright. Under the default pyramidal cone the lift remains |
| The default integrator adds energy | A free two-link chain gains 9.7% of its energy and 6.6% of its momentum in 2 s at 10 ms; a single body tumbling with nothing acting on it, up to 3.4% and 1.3% (run 039) | Corrected by configuration. MuJoCo's own RK4 keeps a tumbling body's energy and angular momentum at every step, 8 of 8 rules; Euler, implicitfast and implicit each fail 4 of 8 (Study 9) |
| A free cube has a direction under the elliptic cone | Slid free to turn along 22.5 degrees under the recommended configuration, a cube goes 1.4% to 2.3% further than along 0 or 45 degrees; under the defaults, 20% further and 35 mm off its line | Traced to the lift: the hopping cube lands on its corners, whose friction turns it off its line. Corrected by the same patch: the same slide along every direction to the micrometre, no drift, no turn, all four corners on the ground. Validated (Study 12) |
| A constraint's softness depends on how the scene is written | The same arm, in the same place and at rest, its tip on the ground, sinks 169 or 105 um and creeps at 0.85 or 0.52 mm/s depending only on the pose its file was written in; held up by joint friction, it ends up to 32 mm apart by writing (run 034) | Measured: MuJoCo takes each contact's softness from inverse weights frozen in the written pose; a tighter solve does not change it, and the elliptic cone with noslip stops the creep in one pose of two, not the depth (run 025). MuJoCo's own diagexact flag removes it, but makes straight stacks and a centred grip turn under the default cone (run 028). Corrected. Senua AI's patch, MuJoCo's own formula taken where the bodies are, ends every writing in the same place to the nanometre and changes no cube scene and none of MuJoCo's tests. Validated: 86 of 86 pre-registered rules (Study 5); its second version, for joint limits and joint friction too, which runs 032 and 034 found affected (released, Study 7's arm ends up to 21 mm apart by writing), validated: 134 of 134 rules (Study 7); and its third version, equality constraints too (run 036), validated: 154 of 154 rules (Study 8), and for a weld, 26 of 26 rules (Study 9); and under the recommended configuration, with the default integrator and with RK4, validated (Study 10) |
| A stack sinks, and an offset stack leans | Ten cubes stacked lose 1.6 mm at their contacts, 6.1 mm under the elliptic cone with noslip; three cubes set each 20 mm over the one below tilt by up to 1.5 mrad and creep | Measured: every cube carries its weight and a box slides on a box face as on the ground; the soft contact sinks with the load, as deep as the model's own softness says (run 026, run 089). by a depth that falls with the square of its time constant (run 102); under noslip an offset stack keeps turning, the instability MuJoCo's documentation names. Corrected by configuration. Every contact's time constant at twice the step, the stiffest MuJoCo's own guard allows, with impratio 1,000: every contact of stacks of 3, 5 and 10 within 10.8 um where it sank up to 901, every lean within 47 urad, every offset stack at rest, with noslip or without it. Validated: 8 of 8 rule lines (Study 23) |
| A bounce depends on the step | Set the documented way, one bounce setting rebounds 0.03 to 0.63 of the drop across the steps; at 10 and 5 ms a bouncier one throws the cube 1.2 to 104 times higher than it fell, or more | Corrected by configuration: a step at most half the contact's time constant times its damping ratio, the spring MuJoCo's own discrete integrator calls resolved: the bounce the same at every such step to within 5% and never above the drop (Study 21) |
| Noslip breaks a joint equality | With noslip, a joint its friction holds stays still and a joint coupled to it moves and stays moved, as MuJoCo's issue #2430 reports: 386 um to 1.64 m in 1 s (run 094, Study 22). Noslip re-solves the friction rows only | Corrected. Senua AI's patch: noslip's pass re-solves the equality rows too, as MuJoCo's own PGS solves them; the coupling under 1 um apart, the held joint held, nothing without an equality changed (Study 22) |
| Inverse dynamics cannot agree with noslip | With noslip, MuJoCo's own forward-inverse comparison differs by the whole force friction holds: 3.35 N at a push of 3.35 N (run 094), up to 34,723 N (Study 23). Friction held exactly makes inverse dynamics ill-defined, as MuJoCo's computation chapter says | A configuration for it. Without noslip, impratio 1,000 and every contact's and joint's friction as stiff as MuJoCo allows: inverse dynamics agrees to under 1 nN, every hold, grip, arm and stack of the set holds, and friction creeps by a law Senua AI measured, (1 - I) dt a, within 0.05 per cent. Validated: 49 of 49 rule lines, with the other form, noslip kept, for friction exact under any load (Study 23) |
| Deterministic only on one architecture | Google DeepMind's arm64 release, played on a Graviton3 machine, departs from the Intel release in 50 of 114 plays, the contact-rich ones, first within 38 to 1,449 steps (run 107) | Traced: the release is built with clang, which fuses a multiply and an add into one rounding on arm64; a clang build reproduces it byte for byte. Corrected by configuration. MuJoCo built from its source with gcc, or with clang and fused multiply-add off, makes the same bytes on arm64 as on Intel, and so does Senua AI's set. Validated: 12 of 12 rule lines (Study 24) |
| A mesh collides as its convex hull | A ball dropped into a cup written as one mesh rests on the hull's top, a lid that is not there, 36 to 40 mm above the floor (run 092, Study 22) | Corrected by configuration. The cup written as convex parts, MuJoCo's documented remedy: the ball rests on the floor, meshes and primitives alike to the nanometre (Study 22) |
Each patch only adds code, does nothing until its switch is set, and leaves MuJoCo exactly as released when it is off: every file played the same, and all 3,492 of MuJoCo's own tests giving the release's result.
The fixes already out there, measured
MuJoCo's maintainers, its users and other engines already have answers for several of these problems. Wherever a fix could be played, Senua AI's Measure held it to the same known answers as Senua AI's own, in the same scenes. The full comparison is in the record: the fixes in the wild, measured.
At a glance
| The problem | The best fix in the wild | What it leaves | With Senua AI |
|---|---|---|---|
| A held object slides away | Stiction, MuJoCo pull request #3349 | Pulls a moved body back; a restored state does not replay | Holds at 0; a moved body stays put; a restored state replays |
| Friction depends on direction | The elliptic cone | Not the default; a free cube still drifts | The same slide in every direction, on either cone |
| The arm depends on how its file is written | The diagexact flag | Tilts stacks, turns grips, changes slides | 0 nm apart, everything else as released |
| A free body gains energy | implicitfast | Loses energy as fast as the default gains it | Energy kept, with MuJoCo's own RK4 |
| A bounce depends on the step | Tune the contact per scene | Wrong at any other step | The same bounce at every step |
| A firm grasp, stacks, inverse dynamics | A hardened configuration | No values given; no inverse dynamics | Two validated forms of MuJoCo's own options |
| Uncertain physics in general | Randomise it in training | Trains around the error; does not correct it | Measures the error and corrects its cause |
1. A held object slides away
A load inside the friction limit does not move (Coulomb 1785, Popov 2010). Under MuJoCo's defaults it does: a cube pushed with 60% of what friction can hold creeps 1.3 mm a second, and a gripped cube slips out at 6.1 mm a second. MuJoCo's friction responds to how fast a contact slides, not how far, so a steady load gives a steady slip.
One study put every fix in use or proposed to the same rules, registered before its data existed and played once on fresh numbers (Study 11). The right answer for every creep is 0.
| The fix | What it does well | Where it falls short | Rules held |
|---|---|---|---|
| MuJoCo's defaults, "working as intended" (PR #3526) | Nothing to change | Creeps 0.5 to 2.0 mm a second; a gripped cube slips out at 7 mm a second | 2 of 4 |
A larger impratio | The creep falls in proportion: 5 to 20 micrometres a second at 100 | Never reaches 0; grips slip at 74 to 813 micrometres a second | 2 of 4 |
| The elliptic cone alone | No direction | Creeps 471 to 895 micrometres a second | 2 of 4 |
| Noslip under the default cone | Holds a light push | Changes nothing at 0.6 of the limit and above (run 013) | 2 of 4 |
| Stiction (PR #3349, 646 lines, not merged) | Holds every held object and its own two demos | Pulls a body moved from outside back, at up to 3.1 mm a second; a restored state strays up to 120 micrometres | 4 of 7 |
| Senua AI's configuration: the elliptic cone with noslip | Every hold and grip at 0; a moved body stays put; a restored state replays byte for byte; no new code | About twice the solver work | 11 of 11 |
Since then, two more of MuJoCo's own options, an impratio of 1,000 and the stiffest contact MuJoCo allows, hold the last case too: a free cube pushed near its limit, from 1.5 mm a second to 0 (Study 23).
2. Friction depends on direction
MuJoCo's default friction cone is a pyramid, so the friction it gives is a diamond, not a circle (Stewart and Trinkle 1996, Le Lidec et al. 2024). A cube slid at 45 degrees goes 42% further than along an axis.
| The fix | Measured |
|---|---|
| The elliptic cone, MuJoCo's answer (#1366) | No direction for a slide kept from turning; not the default; a cube free to turn still goes 1.4% to 2.3% further along 22.5 degrees (Study 10) |
| Friction turned along the slip, in Bullet (its solver) | The right idea, but it lives in Bullet's solver and cannot be played in MuJoCo |
| Senua AI's patch for the default cone, 25 lines | The same slide in every direction, to the micrometre and within 0.05% of Coulomb's distance (Study 1, 17 of 17) |
| Senua AI's patch for the elliptic cone, de Saxce's correction, 103 lines | No hop and no drift: the same slide along every direction, the free cube too (Study 12, 43 of 43) |
3. The arm depends on how its file is written
MuJoCo works out each constraint's softness once, in the pose the scene file is written in. The same arm, started in the same place, ends up to 25.6 mm apart depending only on how its file was written.
| The fix | Measured |
|---|---|
| Write the scene in the pose it works in | Right in that pose only; a robot moves |
| MuJoCo 3.5.0's change to the frozen weights | MuJoCo's maintainers decided to revert it after it stopped a Rubik's cube turning (#3163) |
The diagexact flag | Removes it, but tilts a stack of ten, turns a centred grip 112 to 118 mrad in 2 s, and makes the arm creep faster (run 028) |
| Senua AI's patch, 104 lines | 0 nm apart in every writing; every other scene and all 3,492 of MuJoCo's own tests as released (Studies 5, 7, 8, 9 and 10) |
4. A free body gains energy
With nothing acting on it, a body keeps its energy and angular momentum (Landau and Lifshitz). Under MuJoCo's default integrator a free two-link chain gains 9.7% of its energy in 2 s at 10 ms.
| The fix | Measured |
|---|---|
implicitfast, as the documentation recommends (PR #3554) | Stable, but loses energy and angular momentum at about the rate the default gains them (Study 9) |
implicit | The same as implicitfast on a free body; blows up a swinging chain at 10 ms |
| Senua AI's configuration: MuJoCo's own RK4 for free and spinning bodies | A free chain's energy and momentum kept to 1 part per million, a tumbling body's exactly at four steps (Study 18, 7 of 7) |
5. A bounce depends on the step
MuJoCo has no restitution setting, so users tune each contact's damping to get a bounce (#3404), and published work fits contact settings to real impacts (Acosta et al. 2022).
| The fix | Measured |
|---|---|
| Tune the contact per scene | One setting rebounds 3% to 63% of the drop depending only on the step; bouncier settings throw the cube up to 104 times higher than it fell (run 017) |
| Senua AI's first candidate patch | Failed its own check (run 018), so it is not offered |
| Senua AI's configuration: a step at most half the contact's time constant times its damping ratio | The same bounce at every step, to within 5%, never above the drop (Study 21) |
6. Hardening the contact
Users who need a firm grasp harden MuJoCo: the elliptic cone, a high impratio, stiffer contact settings and optional noslip (Yan et al. 2025). The direction is right, but no values are given, and with noslip inverse dynamics cannot agree. Senua AI's Measure found the values and proved them, in two forms (Study 23, 49 of 49):
| Senua AI's form | For | Measured |
|---|---|---|
| With noslip | Friction held exactly under any load | Every hold, grip and arm at 0; every contact of a stack within 10.8 micrometres; every offset stack at rest |
| Without noslip | Inverse dynamics | Inverse dynamics agrees to under 1 nN; friction creeps by a measured law, under 2 micrometres a second at gravity's load |
7. Randomise and hope
Much of robotics copes by randomising friction, mass and other settings across training runs, as MuJoCo Playground does (Zakka et al. 2025). It makes a trained policy robust to what is randomised, but it cannot remove an error that does not depend on it: a cube creeps whatever its friction, and the written-pose error depends on how a file is written. Randomising trains around a simulator's error; it does not correct it.
The difference. Each fix in the wild documents an error, shrinks it, moves it or trades it for another. Senua AI's Measure holds the engine to the answer physics gives, traces each error to its cause, changes only the cause, and proves in a study registered in advance that nothing else moved.
Proven, not claimed
- Twenty-four pre-registered studies. Every rule was written down and published before its data existed, and a rule that fails is reported as failed.
- Against the fixes in the wild, on fresh numbers. Every fix in use or proposed for a held object that creeps, played beside Senua AI's on the same rules: only Senua AI's held all 11 it was put to (Study 11, every fix with its pros and cons).
- End to end, on fresh numbers. The fixes were played together on numbers no earlier study used, 298 rule lines, 290 of them held (Study 10). No single MuJoCo integrator passes every rule, so the record says which to use for which motion: the default for contact, RK4 for free spinning bodies.
- Every run from 001 to 106 replays byte for byte, and every number on the record's pages to run 100 was traced to the file it is read from (the audit); runs 107 and 108 and the pages since are next.
- Held to textbook physics, with its sources. Coulomb's law of friction (Coulomb 1785), the conservation of momentum, energy and angular momentum and Euler's equations of a rotating body (Landau and Lifshitz), the coefficient of restitution (Stronge 2018), the integrators' known error (Hairer, Lubich and Wanner), and MuJoCo's own published model with the contact literature it rests on: every DOI and arXiv number checked (the references).
All 21 issues, counted once
Before its first registered study, Senua AI gathered the problems MuJoCo's users, its documentation and published papers report, sixteen of them; Senua AI's Measure found sixteen departures of its own. Many are the same departure seen from two sides, so the record counts each issue once: 21 in all, one of them found to be another seen through a different reading, so 20. 16 are fixed and validated; 3 show no departure where they were measured; 1 is outside this deep dive. One trade-off is stated as measured: friction held exactly under any load and inverse dynamics cannot both be had, MuJoCo's documented limit of hard friction, so Senua AI's configuration comes in two forms, one for each; without noslip, friction creeps by a law, (1 - I) dt a, which the record holds to 0.05 per cent (the issues).
The record also states what MuJoCo gets right. It is deterministic to the byte on every machine played, macOS, Linux and arm64, and built from its source with gcc it makes the same bytes on arm64 as on Intel. It gets friction at an impact, free joint motion and the smallest rotations right as released, the last exact down to 2e-15 rad, a million times below the point where SuperDex loses a rotation's axis. On the ten known-answer tests SuperDex was held to, MuJoCo as released passes 9 and, with Senua AI's recommended configuration, 10 of 10. SuperDex as released passes 6.
The Senua AI Robotics Core
The Senua AI Robotics Core is the software a robot is developed and run on. It has four parts:
- Senua AI's World, the simulator.
- Senua AI's Body, the real-time layer on the robot.
- Senua AI's Mind, the causal engine that perceives and decides.
- Senua AI's Measure, the instrument that holds a simulator to the truth.
This deep dive is the work of Senua AI's Measure, the second after Meta's SuperDex Physics. Senua AI's Measure never looks inside an engine: a rig, a thin adapter on the engine's own interface, plays the smallest scenes physics has an answer for, and Senua AI's Measure holds what it records to that answer.
Any engine, the same Measure. Nothing in Senua AI's Measure is particular to MuJoCo. The rigs are thin adapters on each engine's own interface, the known answers are textbook physics, and every study is registered before its data exists. The same Measure that held Meta's SuperDex Physics held Google DeepMind's MuJoCo, and it now turns to Newton, the open physics engine of the Linux Foundation developed with NVIDIA, Google DeepMind and Disney Research: the same tests, the same validation, the same patching.
What we do not use
The Senua AI engine uses no models. No LLMs. No SLMs. Of any kind.
No GPU, no data centre and no AI token costs, ever. The engine runs on low-end CPUs, and every play and measurement in this deep dive ran on an Intel laptop and cloud CPU machines, Intel and arm64.
What would it find in your engine?
SuperDex was first and MuJoCo second; Newton is next. The same measurement, validation and patching apply to Isaac Sim, Bullet, Drake, an in-house engine, or a robotics framework built on any of them. If you maintain a simulator or build robots and need to know how far your simulation is from the right answer, we can run the Senua AI Robotics Core on your engine. Contact us through senuaai.com.
References
The physics the record is held to, and the published work it cites, each checked against its registry (the references in the record says what each is used for):
- Coulomb, C.-A. (1785). Theorie des machines simples, en ayant egard au frottement de leurs parties et a la roideur des cordages. Memoires de mathematique et de physique, vol. 10; new edition, Bachelier, 1821. doi:10.14711/spcol/b668151
- Popov, V. L. (2010). Contact Mechanics and Friction. Springer. doi:10.1007/978-3-642-10803-7
- Landau, L. D., and Lifshitz, E. M. (1976). Mechanics, 3rd edition. Pergamon. doi:10.1016/C2009-0-25569-3
- Stronge, W. J. (2018). Impact Mechanics, 2nd edition. Cambridge University Press. doi:10.1017/9781139050227
- Hairer, E., Lubich, C., and Wanner, G. (2006). Geometric Numerical Integration, 2nd edition. Springer. doi:10.1007/3-540-30666-8
- Featherstone, R. (2008). Rigid Body Dynamics Algorithms. Springer. doi:10.1007/978-1-4899-7560-7
- Todorov, E., Erez, T., and Tassa, Y. (2012). MuJoCo: A physics engine for model-based control. IEEE/RSJ IROS, 5026-5033. doi:10.1109/IROS.2012.6386109
- Todorov, E. (2014). Convex and analytically-invertible dynamics with contacts and constraints: Theory and implementation in MuJoCo. IEEE ICRA, 6054-6061. doi:10.1109/ICRA.2014.6907751
- Stewart, D. E., and Trinkle, J. C. (1996). An implicit time-stepping scheme for rigid body dynamics with inelastic collisions and Coulomb friction. International Journal for Numerical Methods in Engineering 39(15), 2673-2691. doi:10.1002/(SICI)1097-0207(19960815)39:15<2673::AID-NME972>3.0.CO;2-I
- Anitescu, M. (2006). Optimization-based simulation of nonsmooth rigid multibody dynamics. Mathematical Programming 105(1), 113-143. doi:10.1007/s10107-005-0590-7
- De Saxce, G., and Feng, Z.-Q. (1991). New inequality and functional for contact with friction: the implicit standard material approach. Mechanics of Structures and Machines 19(3), 301-325. doi:10.1080/08905459108905146
- Acary, V., Cadoux, F., Lemarechal, C., and Malick, J. (2011). A formulation of the linear discrete Coulomb friction problem via convex optimization. ZAMM 91(2), 155-175. doi:10.1002/zamm.201000073
- Le Lidec, Q., Jallet, W., Montaut, L., Laptev, I., Schmid, C., and Carpentier, J. (2024). Contact models in robotics: a comparative analysis. IEEE Transactions on Robotics 40(5), 3716-3733. doi:10.1109/TRO.2024.3434208
- IEEE (2019). IEEE Standard for Floating-Point Arithmetic, IEEE Std 754-2019. doi:10.1109/IEEESTD.2019.8766229
- Google DeepMind (2021). Opening up a physics simulator for robotics. deepmind.google
- Tassa, Y., and Tunyasuvunakool, S. (2022). Open-sourcing MuJoCo. Google DeepMind. deepmind.google
- Zakka, K., Tabanpour, B., et al. (2025). MuJoCo Playground. arXiv:2502.08844
The record
- github.com/senuamedia/senua-mujoco-accuracy. Every finding, patch, study and run, a page for each study, the scorecard and the audit.
- MuJoCo. Google DeepMind. MuJoCo 3.16.0 (Apache-2.0), at the commit given in the record.
- The Senua AI Robotics Core, complete deep dive: Meta's SuperDex Physics, 15 October 2026. The first deep dive.