In August, Meta released SuperDex, a physics engine built for robots that work with their hands, and we began testing it. In SuperDex and the Missing Reader we looked at what it shipped: the physics of contact, but not the part that feels it. In Senua AI Drives SuperDex: The Wine Glass Test we found that its friction could not hold a grasp, corrected it, and held a slippery, fragile wine glass one millisecond at a time.
This article reports the first stage in full. We held the whole engine to the laws of physics, piece by piece, until every departure we found had a cause, a correction and a proof, and we published all of it on GitHub: github.com/senuamedia/senua-superdex-accuracy. The last part sets out what comes next: what Senua AI can bring to the SuperDex program.
The Senua AI Robotics Core
The Senua AI Robotics Core is the software a robot is developed and run on. It has four parts, and this article refers to each by name:
- Senua AI's World, the simulator: contact and friction, with simulated sensors and motors that speak the real device's wire format. The same inputs give the same bytes on every run.
- Senua AI's Body, on the robot: device drivers, a real-time layer and a 1 kHz reflex loop that reads, perceives and acts, with a stop latch and force limits below the mind.
- Senua AI's Mind, the causal engine: it reads the robot's sensors as streams, learns their causal states, and turns each moment into a decision with a confidence.
- Senua AI's Measure, the instrument: it holds a simulator to the truth. Its gap instrument reads two sources of the same motion and reports whether they differ, where, and by how much; its known-answer harness holds a physics engine to the right answers of the smallest scenes that have one.
This deep dive is the work of Senua AI's Measure. SuperDex is the first engine it has taken apart in full. The Robotics Core can be used on any robotics library or framework, not just SuperDex.
At a glance
- What we tested: one cube, two cubes, one arm, two arms, rods, cloth, soft bodies, a point-cloud floor and a two-finger gripper, along with Meta's own three benchmark scenes, at every time step from the shipped 10 ms down to 1/64 of it.
- What we found: twelve places where SuperDex departs from the right answer, each one measured and traced to its cause.
- What we built: seven patches that switch on one at a time and leave SuperDex's output byte for byte as stock when they are off, on every play compared. Together with five of SuperDex's own settings, they correct what we found.
- How we know: twenty-three studies, each with its rules written down and committed before its data existed. The whole record was made again on a later build, and rebuilt from nothing on a second operating system.
- Where to check it: every rule, run, patch, rig and raw file is public at github.com/senuamedia/senua-superdex-accuracy.
- What it ran on: one laptop and rented cloud CPU machines. No GPU anywhere.
First, what we do not use
The Senua AI engine uses no models. No LLMs. No SLMs. Of any kind.
It learns the structure of a signal directly from the signal itself. That means no GPU to rent, no data centre behind it, and no AI token bill for running it. It runs on low-end CPUs; the whole engine has run on a Raspberry Pi Zero 2 W. Every simulation and measurement in this article ran on ordinary CPUs.
Why we started with SuperDex
Robots learn in simulation because simulation is cheap. A robot can try a grasp a million times for the price of electricity, and Project SuperDex exists to produce exactly that kind of training data for dexterous robotics, at a scale no fleet of real hands could match. But simulated data is only worth as much as the physics behind it. If simulated contact does not behave like real contact, a robot can learn a skill that fails the moment it touches the world.
SuperDex generates the data. The Robotics Core measures whether it can be trusted.
We started with SuperDex for two reasons. It is publicly available, so anyone can take the same code at the same commit and check every number we publish. And its documentation states plainly where it trades accuracy for speed and stability, which is where testing should start. It is also deterministic: it gives the same answer, to the last byte, every time it runs, so any change in its output is a real change.
Those trade-offs are reasonable engineering for an engine that has to run in real time and produce training data at scale. The question was what each one costs, and where.
Measurement: holding an engine to physics
Senua AI's Measure works in two ways. The gap instrument compares two recordings of the same motion, such as a simulator and the machine it is meant to copy, and reports whether they differ, where in the motion, and by how much. In this deep dive it read Meta's benchmark scenes, and it was checked against plain subtraction before it was relied on: the two agreed on 30 cells out of 30.
The known-answer harness carried most of the work. It builds the smallest scenes that physics can answer on paper and checks the engine against them, using measuring programs that are plain arithmetic on what the engine recorded, published so anyone can repeat it. A cube pushed gently should stay where it is. A sliding block should stop at a distance you can work out by hand. An arm spinning freely should keep its speed. A rotation, however small, should keep its axis.
Against SuperDex it found twelve places where the engine and physics part ways. These are the five that matter most:
| What stock SuperDex v1.0.0 does | What we measured |
|---|---|
| The time step decides how much a body bounces | A dropped cube rebounds 0% of its drop height at the shipped step, and 71% at 1/64 of it |
| Nothing stays put under a load | A cube pushed with 0.6 of what friction can hold creeps away at 3.67 mm a second |
| A damped joint limit holds back a joint that is trying to leave it | An arm leaves its limit 30% slower than it should, or not at all |
| As shipped, the solver stops before it has converged | On 89% of half_cheetah's steps and 79% of ant's |
| A rotation smaller than 2e-9 rad loses its axis | The solver spends 203,419 iterations on 3,079 steps of two cubes in free flight, where 3,080 would do |
None of these is exotic. A cube that drifts when it should sit still is the kind of small error that makes a grasp learned in simulation behave differently on a real bench. The record also states what SuperDex gets right: it is deterministic to the byte, and sliding friction, momentum shared between two bodies, and a joint resting against its limit all match the right answer.
The last row of the table shows why every result is traced to its cause. Extra solver work that looked like a cost of our own patches turned out to be SuperDex's. Its quaternion code returns the x axis for any rotation smaller than 2e-9 rad, and a body held still picks up a rotation of about a nanoradian the moment anything touches it. From then on the solver cannot reach its own tolerance and keeps iterating. One small correction, and every stalled step in our contact tests went to zero.
Validation: being sure
Every claim in this deep dive was written down, together with the test that would decide it, and committed before the data existed (the registrations, one per study, with a page for each). When a result fell short, the rule stood and the result was recorded as measured.
- We checked our own tools first. The rig replays byte for byte, a tiny nudge to its input changes nothing, and the instrument agrees with plain subtraction.
- We tested at every step size. An integrator can hide a fault at the default step. It hid one of ours: a friction patch that looked right at 10 ms oscillated at 1/64 of it. We withdrew it and corrected it.
- We traced the solver. Whenever SuperDex reported a step as stopped, we followed it iteration by iteration. That is how the quaternion fault was found.
- Every correction passed five checks. It is required: stock fails a test with a known answer. It is correct: the test then passes. Nothing else gets worse. It is safe when off: SuperDex's output is byte-identical to stock when its switch is unset. And the solver keeps converging.
The patches were reviewed independently, twice. Each review read every patched line, given the code and its purpose but not our results. Neither found anything that behaves differently from stock with the switches off. Between them they found seven problems with the switches on; all seven are corrected, and each has been reached by a test of its own. Every registered play of the record was made again on library build 15, each study by its own scripts from a fresh copy. The final build differs from it only in patch G under the second-order integrator, and is byte for byte the same with every switch off and under the shipped integrator. The record was also rebuilt from nothing on Linux: every patch applies, every library comes out byte for byte, and every reading re-makes byte for byte from the record's own files.
The same standard applies to our own measuring programs. In the last round, one rule failed: two cubes trading momentum read 0.9% short of keeping it, while the physics kept it to the last digit. The measuring program took each cube's mass in units of 10 grams, and the fresh cubes, 4,177 and 698 grams, were the first in the record that were not round numbers. We corrected the program, kept the failed rule as registered, and ran the study again on new numbers. On the new numbers the corrected program read the momentum kept to within 111 parts per million, and every rule of patches F and G held, so patch F is now recorded as required, correct and safe, as patch G already was.
Patching: corrections a maintainer can merge
Each finding became a correction that SuperDex's own maintainers can merge. There are seven patches, A to G. Each one only adds code, never edits what is there, does nothing until its switch is set, and leaves SuperDex's output byte for byte as stock when it is off.
Two went deepest. Patch F gives friction the normal force of the step being solved, so friction meets an impact on time. Patch G corrects how SuperDex projects a jointed body's inertia, so a free arm keeps its speed. Validating patch G under SuperDex's second-order integrator exposed a further cause in SuperDex itself: it starts each step of a jointed body from the wrong combination of past positions, which makes a chain first order. We derived the correct form from the published theory of multibody integration, and a registered study adopted it: a free chain now converges at second order, with its momentum kept to 5 parts in a million at the accurate step.
Together with five of SuperDex's own settings, the patches form one recommended configuration. In the final study, on fresh numbers, it held 117 of its 118 rule lines. The one that failed is on the open list below: on a point-cloud floor, friction over a one-step impact read 5.1% above Coulomb's law at 1/4 of the step, against a bound of 4%, so the configuration as a whole is not yet recorded as validated end to end. It delivers:
- Friction at an impact within 1 part in 1,000 of Coulomb's law at every step size: 2,999 or 3,000 parts in 10,000, against a right answer of 3,000.
- A free arm that keeps 9,999 of every 10,000 parts of its speed at the shipped step.
- A load below the friction limit that holds, on a flat floor, on a point-cloud floor and in a two-finger gripper, where stock lets it creep away.
- On a point-cloud floor, friction over an impact within 2 in 100 of Coulomb's law at the shipped step on fresh cubes, where stock gives 3.1 to 3.6 times the law.
- On Meta's
ant, with every correction on at the shipped step and on commands it had never seen, 0 solver steps of 21,600 stopped without converging, where stock stops on 199. Under the accurate configuration, not one step of 345,600 stops on any of Meta's three scenes.
What remains open
Four items remain, each on the record's open list:
- Friction over an impact on a point-cloud floor. On the final study's fresh cube, at 1/4 of the step, it read 5.1% above Coulomb's law where the bound was 4%, so the recommended configuration is not yet recorded as validated end to end. Its cause has not been traced.
- 32-bit precision. In SuperDex's shipped 32-bit arithmetic the contact corrections pass every test of what they do, but free flight and the finest refinement steps are limited by 32-bit precision itself, with or without them. The joint, limit and rotation corrections are validated in 64-bit only.
- Soft bodies. A soft body rocks back up to 0.9 mm after a slide on SuperDex's own compliant contact, with or without the patches.
- A real robot. Every result is the engine against a right answer, or against itself. Reading a recorded machine against its own simulation is the next step.
Next steps: what Senua AI can bring to the SuperDex program
The deep dive measured SuperDex and corrected what it found. The same Robotics Core can take the program further. Here is what it delivers, in three groups: what is done, what we can deliver now, and what we propose to prove with the SuperDex team.
Done, with the evidence published
- Twelve departures from physics in SuperDex, each measured and traced to its cause.
- Seven corrections, A to G, each adding code only and byte-identical to stock when switched off.
- A defect in SuperDex's own second-order integrator for jointed bodies, found and corrected with a derived form that makes a chain second order.
- A recommended configuration: the corrections with five of SuperDex's own settings, every cost measured.
- Safe when off, proven: byte-identical output with the switches off, on macOS and on Linux, across the record.
- A record anyone can repeat: twenty-three registered studies, every reading re-made byte for byte from the published files, rebuilt from nothing on a second operating system.
- SuperDex driven live: Senua AI's Body and Mind held a wine glass in SuperDex with a tactile reflex, one millisecond at a time.
- CPUs only: no GPU and no data centre; the Senua AI engine has run on a Raspberry Pi Zero 2 W.
Ready to deliver now
- The corrections, upstream: each patch as a pull request with its proof.
- Accuracy on every commit: Senua AI's Measure running the known-answer suite on each SuperDex commit and release, at every step size, catching a change to contact, joints or the solver the day it lands.
- Determinism guarded: byte-for-byte output checked across platforms, release to release.
- The cost of every accuracy setting, measured for each release.
- A cross-engine scorecard: SuperDex beside other engines on the same tests.
- A physics quality gate for training data: every episode SuperDex generates checked for creep, energy gained, a ground that pulls, slip where it should hold and penetration, and the bad ones flagged before anything learns from them.
- Simulation against recordings: given recorded streams from hardware, Senua AI's Measure reports where, when and by how much SuperDex differs.
- The missing reader: Senua AI's Body and Mind reading tactile and joint streams in real time on the robot's own CPU, the part our first article found missing.
- Further physics improvements, each derived, patched and validated: less solver work for the friction correction, a clean start for the second-order integrator, better results in SuperDex's shipped 32-bit build, and a deformable contact that does not rock back.
To prove with the SuperDex team
- Finding faults without a known answer: Senua AI's Measure flagging physically wrong behaviour from the streams alone, on grasping, deformable bodies and long tasks, where no textbook answer exists.
- Training data without headsets: Senua AI's Mind producing task behaviour in SuperDex, such as grasp, insert and place, at volume on CPUs, without human VR demonstrations.
- Closing the sim-to-real gap on hardware: the same commands into SuperDex and a real arm or hand, the differences measured by Senua AI's Measure, and corrections that close them.
- Better transfer from accurate physics: a policy trained on the recommended configuration's physics, tested on a real robot against one trained on stock.
- A reference simulator: Senua AI's World, the Robotics Core's simulator, built to meet every right answer in this record by design.
- Calibration from the robot itself: a robot's real friction, damping and contact recovered from its own streams, with no tuned constants.
Each of these would be registered and decided the same way as everything in this record. We are ready to take these steps with the SuperDex team.
What would it find in your engine?
None of this depends on SuperDex. Senua AI's Measure never looks inside an engine. It reads what a body did at each step, or the stream from an encoder, as it would read a real robot. A new engine needs only a rig, a small adapter that plays a scene and records what happened; every rig in this deep dive is a single C++ file written against SuperDex's public API.
The same measurement, validation and patching apply to MuJoCo, Isaac Sim, Bullet, Drake, an in-house engine, or a robotics framework built on any of them, and to a simulator read against a recording of a real machine.
A robotics engine, or a robot built with any of these frameworks, can be measured the same way and benefits from the same analysis with Senua AI's Measure:
- A known-answer suite: the smallest scenes, each with its right answer and its pass line, played at every step size.
- A findings ledger: what the engine gets right, where it departs from the right answer, at which step, and by how much.
- The cost of every accuracy setting: the shipped settings against the engine's own more accurate ones, one change at a time.
- Corrections held to the five checks, delivered as patches that change nothing when switched off.
- An open list and the whole record: rules, runs, raw files and checksums, so anyone can check every reading and make every play again.
If you maintain a simulator or a physics library, or you are building a robot 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.
The record
- github.com/senuamedia/senua-superdex-accuracy. Every study, run, patch and rig, a page for each study, and the open list.
- Project SuperDex. Meta Platforms, Inc. and affiliates. SuperDex Physics v1.0.0 (Apache-2.0), at the commit given in the record.
- SuperDex and the Missing Reader, 27 August 2026. The first article in this series.
- Senua AI Drives SuperDex: The Wine Glass Test, 27 September 2026. The second.
This is the third article in our SuperDex series, after SuperDex and the Missing Reader and Senua AI Drives SuperDex: The Wine Glass Test. Every figure here was measured in simulation, and every one is in the public record. The Senua AI engine is proprietary.