Open a robot recording. Nothing leaves the tab.
Ferroscope is the open interface layer for physical AI: a WebGPU 3D viewer, a determinism receipt you can recompute from the file itself, and E_task in joules for every run. Plain MCAP in and out, so it also opens in the viewers you already use. Pure Rust, MIT or Apache-2.0.
A one-legged hopper mid-stride. Ghosts are the same machine at earlier instants, the gold ribbon is the path travelled, the leg turns red in contact, and the strip along the top is a real comparison against a second run: diverged at step 90, on a difference of 2×10⁻⁹.
The landscape · August 2026
Four good tools. What falls between them?
| Tool | Does well | Stops at |
|---|---|---|
| Foxglove | The best panel-and-layout viewer in the field. MCAP is theirs and genuinely open. Live streaming, teleoperation, a real data platform. | The app is proprietary; Studio 1.x was frozen in February 2024. Seats, storage and device counts are metered. No physics, no scenario execution, no notion of whether a run reproduced. |
| Rerun | Open core, a Rust viewer that runs native and in a browser, real timelines. | Its own MCAP support is marked experimental and the viewer is RAM-bounded. A logging layer by design, not a place a run is executed or certified. |
| Isaac Sim / Lab | The strongest physics and rendering primitives available, GPU-parallel environments, OpenUSD, an enormous asset ecosystem. | Apache-2.0 source that needs Omniverse Kit under NVIDIA's terms, and an RTX-class GPU. Isaac Lab's own docs state the limit plainly: GPU work scheduling reorders floating-point reductions, so "experiments from the IsaacGym simulator are not perfectly reproducible on a different system." |
| Antioch | The best-designed scenario model in the field, and the reason Ferroscope has one: parameterized scenarios, case grids, verdicts as named checks with measured details, suites as selector unions, history queried by key:op:value. |
The delivery, in their own documentation. A run needs an ephemeral GPU VM, "allocation is the slow step", and the CLI "polls up to 600 s" when none is warm. Cost is assignment-scoped: "there is no per-run or per-scenario cost figure to report". Reproduction is re-queueing images, "multi-machine interactive runs are not currently rerunnable". And "the CLI has no compare command". |
Nothing there lets a stranger holding only the file establish that a run reproduced, or what it cost. Determinism is asserted by whoever ran it; energy is not modelled at all. Ferroscope is that seam, and only that seam.
Three ideas
What the file carries that others do not.
Recomputable by anyone
A spec digest over everything two runs must share to be comparable, deliberately excluding the platform, and a trace digest at a declared precision. Both recompute from the file's own bytes: no simulator, no source tree. A digest match is proof; a mismatch is a question, answered by a comparator that names the step.
E_task = E_compute + E_actuation
From measured power integrated over the run, never a datasheet TDP. On this hopper compute is 24 % of the energy. The ledger also refuses: sample too sparsely and it prints DO NOT QUOTE with the gap that caused it, because a number nobody can stand behind is worse than none.
Sim, wall, control step
MCAP gives a message two timestamps. A robot has three clocks, and the interesting bugs live in the drift between them: 1 kHz in simulation and 780 Hz on hardware is not a controller that works. Every message carries all three, so real-time factor and loop jitter read straight off the file.
The harness
How long should a robot test take to start?
1.7 milliseconds, cold, including discovering thirteen cases. A scenario is a function in your binary: no manifest, no services map, no container, no machine. run.tick() is the only bookkeeping call in the loop, and it is what buys the three clocks, the energy ledger, the digest and the verdict at once.
$ hopper run --suite acceptance hop[stiffness=4000] failed 3 check(s), 1 failed 5.0 ms 28.70 J x leg did not bottom out: worst penetration 0.0886 m <= 0.0600 m hop[stiffness=8000] passed 3 check(s) 4.6 ms 26.28 J hop[stiffness=16000] passed 3 check(s) 4.7 ms 24.29 J ... 13 run(s), 8 passed, 5 not, 338.32 J total, in 197 ms
A softer leg bottoms out; a bouncier one costs more joules. A real trade-off, surfaced in a fifth of a second, with a receipt and an energy figure on every row.
| Measured on one laptop, release, no GPU, no container, no network | Median |
|---|---|
| start, discover 13 cases, print the catalogue | 1.7 ms |
| 4 runs, 4,000 steps, 4 sealed and re-verified recordings | 39 ms |
| 13 runs, 13,000 steps, 13 recordings | 132 ms |
| query a 105-run history | 3.7 ms |
| Antioch's documented machine-allocation ceiling, before any build or boot | 600 s |
The fair framing, since a comparison deserves one: this is a local harness with no GPU and no Isaac, so it is not doing a cloud platform's job and these are not a benchmark against one. They measure the overhead around the physics. Deliberately absent: GPU orchestration, a queue, fan-out, a renderer, an asset catalogue. For a photorealistic sensor sim on twenty machines, Antioch and Isaac are the right tools.
Status · v0.1
What is real, and what is next?
Shipping: the zero-dependency MCAP reader and writer, tested against Foxglove's own parser as an oracle; the three-clock model and published schemas; the energy ledger with its refusal; the receipt and comparator; verify recomputing a receipt from bytes alone; the six-verb scenario harness; and the WebGPU viewer. 72 tests, clean clippy, three platforms in CI plus wasm32, zero-dependency and viewer-freshness jobs. Seven crates on crates.io.
Next, in the open: live streaming over WebTransport, URDF and glTF geometry in the 3D panel, a scenario runner that executes a spec rather than describing one, and coupling to Ferromotion so a run is produced and certified by the same stack that draws it.