Our policies have to get through a gate before they ship: a second physics engine, courses they have never seen, thresholds written
down before the run, and broken robots the gate must fail before its verdict counts.
Our thesis
A policy is only as good as the test that tried to break it.
Trained in Isaac Sim. Judged in MuJoCo, a second physics engine, so a policy can't win on one simulator's quirks.Our own rover drives, hops each wall and lands. 0 crashes in 1,000 courses it never trained on.A PASS runs on a Jetson GPU in a ROS 2 loop, matching the tested model to within 3e-06.
02 / What the gate sees
CASE Hopper Rover, version 7
It reached the goal. We still pulled it.
The Hopper Rover is our own robot: four wheels and four rotors. The spec says drive by default, fly only over walls it
can't drive over, land after each one, and drive over speed bumps. Version 7 finished 59 of 60 gate courses with zero
crashes, and passed our old checks and a Jetson deploy. Then we watched the side view.
startgoal,
Loading the run…
drivingrotors ontouchdownwall3 cm speed bumpgap the gate checks: green landed, red flown overOne held-out course, the same for all three. Heights exaggerated for legibility.
01
A new gate rule
Every gap of 1 m or more between two walls needs a wheel touchdown, in 95% of gaps. The speed bump must be driven.
02
A canary that must fail
A broken robot whose rotors can't throttle down after take-off. The gate fails it on 7 checks before it may judge anything.
03
New sensors
Version 7 could only see ahead, so it forgot each wall once it was over it. The rover now has rear height rays and a touchdown sensor on every wheel.
PASS The current rover policy finishes 60 of 60 gate courses and lands in
91 of 91 gaps, with 0 crashes in 1,000 courses it never trained on. Along the way the gate passed one version whose wheels
stepped on the walls; a person watching the runs caught it, so the gate is getting a rule for that too.
03 / The machines
Different bodies. The same standard.
Every number on this page comes from a gate report. Nothing is rounded up.
Multirotors
Skydio X2 · customer A · SHIPPED
Position hold under gusts of 0.25 g every 1.5–3 s. The customer's own MuJoCo model, imported as-is: four rotors, 1.325 kg.
Gate episodes
60
Crashes
0
p95 gust recovery
0.5 s
Fails 4 of 6 hardware-readiness probes, including one step of latency. Disclosed in the report.
Each station signs a record of what went in, what came out and its verdict. The next one refuses anything that isn't a
PASS, or that changed after it was judged.
01
Intake
Your MJCF or URDF and a one-page robot card, compiled and checked.
02
Import
We build the training robot and check it against your model before renting a GPU.
03
Train
Isaac Sim, 4,096 copies in parallel on one L40S. The X2 run took 16 min 35 s.
04
Select
Checkpoints compared on held-out courses, never on the gate's.
05
Gate
MuJoCo, randomized episodes, thresholds fixed in advance, then broken robots that must fail.
06
Deploy
TensorRT on a Jetson GPU in a ROS 2 loop, checked for parity.
07
Deliver
The package and the report: every check, every probe it fails.
01
A second physics engine
Trained in Isaac Sim, judged in MuJoCo. A second engine tests whether a policy depends on the training simulator's quirks.
02
Courses it has never seen
Training and checkpoint selection never touch the gate's seeds. Thresholds are written before the run, and a fix goes into the policy, never the threshold.
03
Broken robots fail first
Robots that do nothing, have a capped rotor, dead wheels, a lifted leg or half a second of lag. If one passes, nothing ships.
04
Every gate rule is a training rule
If training doesn't know a rule, the optimizer finds the gap. The rover taught us that four times.
The gate ledger.
Recent verdicts, straight from the reports. Simulation-validated; none has run on a physical robot. Jetson inference is tested on real compute.