Autonomous robot policy lab / 001

Motion.
With proof.

Give us your robot.
We teach it how to move.
Then make it prove it.

Control policies trained in simulation, tested against a frozen gate, delivered for your Jetson.

Start with a $1 pilot Read a real delivery report
Recorded simulation MuJoCo / dagger9
HOPPER ROVERDRIVE + FLY / R&D
One body. Two ways to move.

Every landing.
Accounted for.

TRAIN IN ISAAC SIMJUDGE IN MUJOCOSHIP ON JETSONFollow the proof
Real simulation footage · Skydio X2 · Unitree A1 · Hopper Rover

01 / The standard

A beautiful run.
A harder test.

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.

Side view of one test course.

startgoal,

Loading the run…

driving rotors on touchdown wall 3 cm speed bump gap the gate checks: green landed, red flown over One held-out course, the same for all three. Heights exaggerated for legibility.

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.

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.

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.

Read the delivery report

Quadrupeds

Unitree A1 v5 · customer B · SHIPPED

Velocity-commanded walking with stop and turn, on randomized friction, payload and pushes. Versions 4b and 4c were rejected by the gate.

Gate episodes
72
Falls
0
Checks passed
13/13

Holds one step (20 ms) of latency, fails two. Fails a dead knee motor.

Report on request

Drive-and-fly hybrids

Hopper Rover · our R&D · PASS

Drives by default and flies only over what it can't drive over. One body, two ways of moving, and a gate that checks when it switches between them.

Gaps landed in
91/91
Courses finished
60/60
Bumps flown over
2/43
See what the gate caught

Policyforge in action

04 / From model to motion

Seven stations.
Nothing skips the gate.

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.

  1. 01

    Intake

    Your MJCF or URDF and a one-page robot card, compiled and checked.

  2. 02

    Import

    We build the training robot and check it against your model before renting a GPU.

  3. 03

    Train

    Isaac Sim, 4,096 copies in parallel on one L40S. The X2 run took 16 min 35 s.

  4. 04

    Select

    Checkpoints compared on held-out courses, never on the gate's.

  5. 05

    Gate

    MuJoCo, randomized episodes, thresholds fixed in advance, then broken robots that must fail.

  6. 06

    Deploy

    TensorRT on a Jetson GPU in a ROS 2 loop, checked for parity.

  7. 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.

Real sim · 4 unseen courses
  • 0crashesSkydio X2 · 60 episodes · PASS
  • 0fallsUnitree A1 v5 · 72 episodes · PASS
  • 89/89gaps flownHopper Rover v7 · 60 courses · FAIL
  • 2.86e-06max action diffTensorRT on Jetson vs tested model · X2
  • 16:35training timeX2 · 1,500 iterations · one L40S
  • ~$0.67GPU costX2 training run

05 / Your next behavior

Start small.
Ask something hard.

Pilot pricing, November 2026. We confirm the price in writing before any work starts.

Pilot

$1

One behavior, 48-hour target. The trained policy, the gate report and a Jetson TensorRT package. While we take our first customer robots.

Per behavior

$2,500

A delivered package that passed the gate, including retraining when the first run fails.

Gate retainer

$750/mo

Re-gate when your robot or spec changes, up to twice a month.

Pilot terms, in short

  • You keep your robot model, your data, the trained policy and the TensorRT package.
  • We may use anonymized test results. Never your name or model without your written OK.
  • Provided as is, no warranty for hardware use. Either side can stop at any time.

Plain-language draft; a lawyer has not reviewed it yet. The full text comes with your quote.

Read before hardware

  • Simulation-validated only. Nothing here has been tested on a physical robot.
  • Latency is the known weak spot; every delivery reports its latency and noise probes.
  • Not yet: manipulation, collective-thrust drones (Crazyflie style). Boston Dynamics Spot fails 8 gate checks today.
  • No safety-critical use without your own safety sign-off, hardware testing and a person able to take over.

06 / Put us to the test

Your robot.
Our next challenge.

  1. Your model. A link to an MJCF file, or a URDF with its meshes, as a folder or a .zip.
  2. A robot card. One page: robot type, standing pose or rotor layout, motor limits. Download the template (YAML)
  3. The behavior. One or two sentences, e.g. "hold position within 10 cm in 0.25 g gusts" or "walk at up to 1 m/s and stand still on command".

Today we take legged robots and multirotors with one thrust actuator per rotor. Unsure? Send it anyway and pick "other".

Robot type

GitHub, Drive, Dropbox or any link we can download. Leave empty to send it by email.