The Physical AI Sprint

What to expect

We'll begin with technical workshops designed to help you get familiar with the tools, infrastructure, and challenge space. Then, you'll form a team — or work independently — and spend the rest of the day building a working prototype.

• Robotics workshops
• A focused physical AI challenge
• Access to tools, infrastructure, and technical support
• Project demos and judging
• Prizes for the strongest submissions

01The challenge

The perception–reasoning–action loop

Modern AI excels at generating text and pixels. Physical AI requires closing the loop between the digital mind and a physical embodiment, integrating three pillars:

Your goal: design and demonstrate a Physical AI task in simulation, in the real world, or across both. You have several robot modalities, the Antioch simulation platform for building and testing, and a single day. The brief is deliberately open-ended: we provide the robots, the world, and the building blocks, and you decide what the system does and how it thinks. In short, build some cool stuff.

Three project directions

All are equally viable.

• Sim only. Build and demonstrate entirely on the Antioch platform. No hardware queue, unlimited resets, and every robot modality is available.
• Hardware only. Build directly on the physical robots at the hardware stations.
• Sim and real. Show a trajectory between the two: prototype or train in sim and run it on the real robot (sim-to-real), or capture real demonstrations and bring them into sim (real-to-sim).

02Format

100 to 125 participants, hacking in teams of 4 or 5.

03Schedule

Monday, August 17, 2026 · Subject to change

04What you get

The Antioch platform

Antioch is a cloud simulation platform for robotics. You write ordinary Python against the NVIDIA Isaac stack (Isaac Sim and Isaac Lab are both available) on your own laptop, and Antioch dispatches it to GPU machines on Nebius. Nothing heavy runs locally: no GPU, no Docker, no Isaac install, and macOS and Linux both work.

You can develop interactively by building simulations and streaming them into the browser. You can also define parameterized simulation scenarios and run variants at scale headlessly. Scenario runs are recorded and replayable, with metrics, logs, live viewport streams, and 3D recordings you can open in the browser.

Your team will receive a link to sign up for the Antioch Console. Each team gets its own development environment where teammates share machines and scenario runs and can see each other's work as it lands. Signup links will be distributed over email once teams are formed.

Robot hardware

Hardware stations are shared between teams and staffed by the host teams.

Sim-ready assets

• Robots. A calibrated SO-101 digital twin, plus the Unitree lineup in the Isaac asset library (Go2, G1, and others; Guide 4 lists what is on the shelf).
• Environments. Ready-made scenes to stage your task in.
• Objects. Containers, fixtures, and props, so composing a scene takes minutes rather than hours of importing and tuning your own meshes.

Physical assets for SO-101

• Blocks of various size, shape, and color
• Vials and vial racks

Frontier models: Kimi K3 on Nebius Token Factory

Nebius Token Factory serves open-weight frontier models over an OpenAI-compatible API. Kimi K3 is Moonshot AI's open-weight flagship — a mixture-of-experts model with a 1M-token context window, built for agentic work. New accounts get $25 in Token Factory credits plus $25 in Tavily credits for live web search.

In your robot's reasoning layer

This is the pillar that is easiest to underbuild. Any OpenAI client works — point it at Token Factory and use it for natural-language tasking, multi-step planning, or deciding what to do when a grasp fails.

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.tokenfactory.nebius.com/v1/",
    api_key=os.environ["NEBIUS_API_KEY"],
)

plan = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    messages=[
        {"role": "system", "content": "Turn goals into SO-101 pick-and-place steps."},
        {"role": "user", "content": "Put the green cube in the tray, then reset."},
    ],
)
print(plan.choices[0].message.content)

In your coding agent

kimirelay routes Claude Code, Codex CLI, OpenCode, or Pi Code through Token Factory for a single run, without editing your real agent config — useful when you are building fast and would rather not spend your own subscription limits on it.

curl -fsSL https://kimirelay.com/install.sh | sh
kimirelay configure    # your Nebius key, plus an optional Tavily key for web search
klaude                 # or kodex, openkode, kpi

Support

Engineers from the host companies are on hand all day for platform, hardware, and training questions.

05Getting started guides

The four guides at the back of this handbook each take you from zero to a working proof of concept with the hardware or with Antioch.

Some directions to calibrate ambition

• A vial pick-and-place cell that survives a shuffled scene
• A new skill taught by teleop and distilled into a policy
• Person-following with a quadruped
• Pouring with the G1
• A multi-robot scene
• Natural-language tasking
• Deliberate failure recovery

06Judging

Judging runs science-fair style first: judges from the hosting companies circulate and view projects at team stations, so have a tight walkthrough and a live or recorded demo ready. The top 6 teams then demo to the full group, and winners are announced after.

Projects are judged on four categories, unweighted.

07Ground rules

• Unless you are confident you can pull it off quickly, avoid fine-tuning pre-trained policies or VLA models. Training a small imitation policy from scratch on your own demonstrations fits comfortably in the day (Guide 3 shows the path); wrangling a large pre-trained model usually does not.
• Make it awesome.

Prizes

Prizes for the strongest submissions, awarded after the top 6 teams demo to the full group. Judging criteria are in section 06.

What to bring

Bring your laptop, charger, and anything else you rely on for a full day of building. Required setup instructions and recommended tools are shared with registered participants before the event — the four guides in this handbook cover the setup you can do in advance.

Who should attend

This event is designed for:

• Robotics engineers
• Machine learning engineers
• Computer vision engineers
• Research engineers and applied scientists
• Data and infrastructure engineers working with robotics or physical AI
• Technical founders and builders exploring embodied intelligence

You don't need to arrive with a team. We'll help participants connect and form teams before and at the event — post yours or find one with room in the team directory.

Important notes

• Space is limited, and all attendees must apply and be approved to attend.
• This is a hands-on technical event. Participants should be comfortable writing code and building independently or as part of a small team.
• Please register individually, even if you plan to attend with a team.

Guide 1LeRobot on macOS: first-time setup for the SO-101

Go from a Mac with nothing installed to a real SO-101 arm following your hand. The published LeRobot instructions assume Windows or Ubuntu, so the port names, permissions, and GPU advice in them do not match a Mac. This guide is the macOS version, with every difference called out where you hit it.

Total time

About 45 minutes, most of it calibration.

Tested against

lerobot 0.4.4, Python 3.10, macOS on Apple Silicon.

Vendor manual

Assembly and servo wiring: SO-ARM101 user manual (hiwonder.com)

Step 0 · What you need

Hardware on the desk

• An SO-101 follower arm, which is the one that moves under command.
• An SO-101 leader arm if you want to teleoperate. The leader has a handle and no gripper servo horn.
• One data-capable USB-C cable per arm, plus the arm power supplies. A charge-only cable shows no serial port at all and wastes twenty minutes.

Software: a terminal, and either miniconda or uv (docs.astral.sh/uv). You do not need a GPU, Docker, or ROS.

Step 1 · Create the environment

Either tool works. The conda route pulls in ffmpeg, which LeRobot uses for video encoding during dataset recording:

conda create -n lerobot python=3.10 ffmpeg -c conda-forge -y
conda activate lerobot
pip install lerobot opencv-python

With uv instead:

uv venv ~/lerobot-env --python 3.10
source ~/lerobot-env/bin/activate
uv pip install lerobot opencv-python

Add opencv-python in either case, because anything that touches a camera needs it and the error you get without it is unhelpful.

python -c "import lerobot, torch; print(lerobot.__version__, torch.__version__)"
python -c "import torch; print('MPS available:', torch.backends.mps.is_available())"

Step 2 · Find the serial ports

Plug in one arm, then list the ports:

ls /dev/tty.usbmodem*

macOS names serial ports /dev/tty.usbmodemXXXXXXXX. Linux tutorials say /dev/ttyACM0 and the vendor manual says COM22 or COM24; neither exists here, so substitute your own port name into every command you copy. LeRobot also ships an interactive finder that walks you through unplugging a cable:

lerobot-find-port

Two more macOS specifics. You do not need udev rules or sudo chmod on the port, because it is usable as soon as it appears. USB hubs also renumber ports across reboots and replugs, so check the name at the start of each session rather than trusting one you wrote down yesterday.

Step 3 · Tell the two arms apart

Both arms produce identical port names, so you have to identify them. Two reliable methods:

• The unplug test. List the ports with both arms connected, unplug one, list again, and note which name disappeared.
• The passive wiggle test. This project ships a script that reads joints for 15 seconds and commands no motion.

cd ~/my-sim
python replay/check_so101.py --port /dev/tty.usbmodemXXXXXXXX

Move each joint gently by hand while it prints. The sanity bar comes from the script's own docstring: at rest the numbers should be repeatable, none should sit near plus or minus 180, and moving one joint must move only its own number, in a consistent direction.

export LEADER=/dev/tty.usbmodemAAAAAAAA
export FOLLOWER=/dev/tty.usbmodemBBBBBBBB

Step 4 · Assign servo IDs (DIY kits only)

Pre-assembled arms arrive with servo IDs set, so skip this step. If you built the arm from a kit, each servo needs its ID written one at a time, with only that servo connected:

lerobot-setup-motors --robot.type=so101_follower --robot.port=$FOLLOWER

Follow the prompts and the vendor manual's wiring order. Connecting several unconfigured servos at once writes the same ID to more than one of them, which is confusing to undo.

Step 5 · Calibrate each arm

Calibration teaches LeRobot each joint's real range. Do it once per arm, in the calibration start pose from the manual:

lerobot-calibrate --robot.type=so101_follower \
    --robot.port=$FOLLOWER --robot.id=my_follower_arm

lerobot-calibrate --teleop.type=so101_leader \
    --teleop.port=$LEADER --teleop.id=my_leader_arm

The --id you choose here is the --id every later command must use, because profiles are keyed by it. They are written to ~/.cache/huggingface/lerobot/calibration/.

ls ~/.cache/huggingface/lerobot/calibration/

Step 6 · First motion: teleoperate

With both arms calibrated, the leader drives the follower:

lerobot-teleoperate \
    --robot.type=so101_follower --robot.port=$FOLLOWER --robot.id=my_follower_arm \
    --teleop.type=so101_leader --teleop.port=$LEADER --teleop.id=my_leader_arm

Keep one hand near the power switch for the first run. Move the leader slowly and watch for a joint that travels the wrong way, which points at a calibration or ID mismatch rather than a hardware fault.

Step 7 · Record a dataset

Recording captures synchronized camera frames, joint states, and commands in the LeRobot dataset format, which is what the training scripts consume. Check your cameras first:

lerobot-find-cameras opencv

Then record, adding your camera and dataset flags from lerobot-record --help:

lerobot-record \
    --robot.type=so101_follower --robot.port=$FOLLOWER --robot.id=my_follower_arm \
    --teleop.type=so101_leader --teleop.port=$LEADER --teleop.id=my_leader_arm \
    --dataset.repo_id=<your-name>/so101-pick-place \
    --dataset.single_task="Put the green cube in the tray."

macOS differences at a glance

Troubleshooting

House rules for real hardware

These are enforced by the scripts in replay/, and they exist because each one was learned the expensive way.

• Pin one driver per data file. Every trajectory and policy records the driver, lerobot version, and calibration id it was made with, and the loader validates all three before anything moves. A mismatch stops the run loudly instead of falling back.
• Treat units as data. The units dictionary travels with the file and is asserted against the robot config at both ends.
• Never cut torque while the arm holds a commanded pose, because the arm drops. Ramp back to the rest pose read at connect time, then disconnect.
• Run the real --dry-run first, every time the code or the trajectory changed. It exercises the whole path with sends suppressed. Note that --dry-lift-mm is a rehearsal that does move the arm.
• Keep a hand near the power switch on first runs.

Scripts referenced here: replay/check_so101.py, replay/replay_on_so101.py, replay/run_act_on_so101.py. Sim teleop and cloud setup: Guide 2.

Guide 2Sim teleoperation: drive the Antioch sim with a real SO-101 leader arm

Hold a real leader arm, watch a physics-simulated SO-101 mirror your hand on a cloud GPU, and record demonstration episodes that are scored the moment you stop recording. Nothing runs locally except the arm driver, so your Mac needs no GPU, no Docker, and no Isaac install.

First motion

About 5 minutes once the setup in Step 0 is done.

Tested against

antioch-sim 0.3.27 on isaac-601-ga, lerobot 0.4.4, Python 3.10 in the robot env, macOS on Apple Silicon.

Step 0 · One-time setup

You need three things before the fun part.

1. The project at ~/my-sim, with its own environment.
2. A separate environment that talks to the arm over USB. Keep it separate from the project environment, because mixing the two causes the most confusing errors in this whole pipeline.
3. A calibrated leader arm. If yours has never been calibrated, follow Guide 1 through Step 5 and come back. The follower arm stays in its box for this guide, because the sim replaces it.

cd ~/my-sim && uv sync && .venv/bin/antioch auth login

conda create -n lerobot python=3.10 ffmpeg -c conda-forge -y
conda activate lerobot
pip install lerobot opencv-python

Step 1 · Two terminals

This pipeline needs two terminals at once, and it helps to know which is which before you start.

Step 2 · Find the leader port

Plug in the leader arm by itself, then capture the port in one command:

export LEADER=$(ls /dev/tty.usbmodem* | head -1) && echo $LEADER

Step 3 · Warm a machine and start the session

In Terminal A. The first command claims a cloud machine and warms it, which matters because a freshly claimed machine deadlocks on its first render and a teleop session started cold dies a few minutes in with no useful error:

cd ~/my-sim && .venv/bin/antioch scenario run --scenario so101_render_probe --timeout 300

Then start a 30 minute session on that same machine. Leave off --machine entirely and the session uses the machine you just warmed:

.venv/bin/antioch scenario run --scenario so101_live_teleop \
    --set max_seconds=1800 --verbose --timeout 1900

Step 4 · Open the livestream

In a third shell, or Terminal B before you connect the arm, open the machine's viewport straight into your browser:

cd ~/my-sim && .venv/bin/antioch machine status | awk '/url/{print $2}' | xargs open

Step 5 · Connect the arm

In Terminal B, in your (lerobot) environment. One command, no machine id to look up, because the wrapper resolves the assigned machine itself:

~/my-sim/replay/teleop_pipe.sh $LEADER

Step 6 · Record episodes

The collection rhythm:

r  →  new cube position
s  →  recording starts
      pick the cube up with the leader, place it in the tray
s  →  episode saved and auto-scored
r  →  again

Aim for quality over quantity: smooth approach, clean grasp, deliberate place. Ten to fifteen good episodes per session is a solid haul. Episodes upload as they close, so a session that dies loses at most the episode in progress.

Step 7 · Download your data

From ~/my-sim, once you are done. This resolves the newest run id for you:

.venv/bin/antioch scenario download $(.venv/bin/antioch scenario list --limit 1 \
    | grep -oE '[0-9a-f]{32}' | head -1)

Why the pipe uses machine exec

This is the one detail worth understanding, because getting it wrong fails silently.

antioch machine exec forwards stdin into the container where the scenario runs. antioch machine ssh lands you in a separate ephemeral filesystem, so a /tmp/leader_stream.jsonl written there is invisible to the scenario.

The sim arm then never moves, with no error printed anywhere. The wrapper script uses machine exec for exactly this reason, which is why the recommended path is to run the wrapper rather than assemble the pipe by hand.

Troubleshooting

Scripts referenced here: replay/teleop_pipe.sh, replay/leader_bridge.py, src/so101_live_teleop.py. Arm setup: Guide 1. Training on this data: Guide 3.

Guide 3Train your first SO-101 policy: ACT/Diffusion on sim data

Generate demonstration episodes in simulation, train an imitation policy on them, check it closed-loop in sim, and run it on a real arm. You need the my-sim project with Antioch access, plus a Python 3.10 env with lerobot, torch, and opencv-python. Your laptop needs no GPU and no Isaac install: simulation runs on cloud GPUs, and training runs locally on Apple Silicon (MPS).

First policy

About 1.5 hours, most of it unattended training.

Tested against

lerobot 0.4.4, torch 2.10 for training and 2.11+cu130 for remote eval, Python 3.10 in the lerobot env, antioch-sim 0.3.27 on isaac-601-ga, asset so101_antioch 1.3.0.

Step 1 · Generate episodes

From the project root, run the scripted-expert suite. It replays a verified pick-and-place over randomized cube positions and sizes:

.venv/bin/antioch suite run wrist_cam_enabled --queue
.venv/bin/antioch scenario list --limit 5          # find the run ids
.venv/bin/antioch scenario download <run-id>

If you would rather record human demonstrations, drive the sim arm with a real leader arm instead (Guide 2). The output format is the same; plan for 10 to 15 episodes per session.

Step 2 · Build the dataset

Convert the episode pairs into a LeRobot dataset with exactly these fields:

Step 3 · Train

Train ACT with the LeRobot default config (chunk 100), batch 8, inside your lerobot env:

lerobot-train --policy.type=act --dataset.repo_id=<your-dataset> \
    --steps 15000 --batch_size 8 --save_freq 5000

Set the budget to 15k steps rather than the 100k in the LeRobot tutorial. The tutorial assumes large, messy, human-collected datasets; 30 consistent scripted episodes converge much earlier. For Diffusion Policy, swap in --policy.type=diffusion and expect a longer wall clock (about 90 M parameters against ACT's 52 M).

Step 4 · Evaluate closed-loop in sim

A low training loss tells you the policy can imitate the dataset. It does not tell you the policy can do the task. To find out, export the checkpoint as TorchScript (trace it on torch 2.10; the remote's 2.11 loads it) and run the eval scenario. The policy takes the scripted expert's place at 10 Hz: it receives the wrist image and the measured joints, and it outputs joint targets. It receives nothing else.

The run scores against the same physics gates as the expert suite: the cube must end inside the tray within the tick budget.

Step 5 · Run on the real arm

The runner is replay/run_act_on_so101.py:

# stamp the policy with driver + lerobot version + calibration id
python replay/run_act_on_so101.py --stamp --id my_follower_arm

# the full path with motion suppressed
python replay/run_act_on_so101.py --port /dev/tty.usbmodemXXX \
    --id my_follower_arm --camera 0 --dry-run

python replay/run_act_on_so101.py --port /dev/tty.usbmodemXXX \
    --id my_follower_arm --camera 0

Troubleshooting

Code: replay/run_act_on_so101.py, replay/leader_bridge.py, src/so101_bench_tasks.py. Benchmark and results: sim2real_benchmark.md.

Guide 4Running Unitree robots on Antioch: Isaac Sim vs Isaac Lab

Spawn a Unitree quadruped or humanoid, give it a controller, and prove it works. The first decision is which engine you run on, because Isaac Sim and Isaac Lab expose completely different Python entry points for the same robot. This guide covers both, then walks the path from a stock asset to a verified walking robot.

Standing robot

About 15 minutes on an engine you have already chosen.

Tested against

antioch-sim 0.3.27, engines isaac-601-ga (Isaac Sim 6.0.1) and isaac-lab-30b2 (Isaac Lab 3.0), URDF importer 3.11.2, Unitree URDFs from unitreerobotics/unitree_ros, policies from fan-ziqi/rl_sar.

Step 1 · Choose your engine

One project runs one engine, selected in three places that must agree: the antioch-sim extra in pyproject.toml, the image coordinate or Dockerfile in antioch.yaml, and the FROM line of that Dockerfile. Changing engines means editing all three and rebuilding the image.

The two engines are not two flavors of the same API. They are different libraries:

Choose Isaac Sim when you want a robot standing, driving, or running a pretrained policy, which is what this guide's verified runs use. Choose Isaac Lab when you want its ArticulationCfg library or its managers for training.

The same 15 lines on each engine

from isaacsim.core.api import World
from isaacsim.core.api.robots import Robot
from isaacsim.core.utils.stage import add_reference_to_stage
from isaacsim.core.utils.types import ArticulationAction

world = World(physics_dt=1/200, rendering_dt=1/200, stage_units_in_meters=1.0)
world.scene.add_ground_plane(z_position=0.0)
add_reference_to_stage(usd_path=usd, prim_path="/World/robot")
robot = world.scene.add(Robot(prim_path="/World/robot", name="robot",
                             position=np.array([0.0, 0.0, 0.42])))
world.reset()
controller = robot.get_articulation_controller()
controller.set_gains(kps=kp, kds=kd)
controller.apply_action(ArticulationAction(joint_positions=targets))
world.step(render=True)

import isaaclab.sim as sim_utils
from isaaclab.actuators import ImplicitActuatorCfg
from isaaclab.assets import Articulation, ArticulationCfg
from isaaclab.sim import SimulationCfg, SimulationContext
from isaaclab_ovphysx.physics import OvPhysxCfg

sim = SimulationContext(SimulationCfg(dt=1/200, device="cuda:0",
                                      physics=OvPhysxCfg()))
robot = Articulation(ArticulationCfg(
    prim_path="/World/robot",
    spawn=sim_utils.UsdFileCfg(usd_path=usd),
    init_state=ArticulationCfg.InitialStateCfg(pos=(0.0, 0.0, 0.42)),
    actuators={"all": ImplicitActuatorCfg(joint_names_expr=[".*"],
                                          stiffness=25.0, damping=0.5)}))
sim.reset()
robot.set_joint_position_target(targets)
robot.write_data_to_sim()
sim.step(render=True)
robot.update(1/200)

Step 2 · Check what already exists

Before building anything, find out whether your robot is already on the shelf. The Isaac 6.0 asset library carries these Unitree models:

A1  B2  Dex3  Dex5  G1  G1_23dof  Go1  Go2  H1  H2  Z1  aliengo  laikago

Isaac Lab additionally ships ArticulationCfg objects with tuned gains: UNITREE_A1_CFG, UNITREE_GO1_CFG, UNITREE_GO2_CFG, H1_CFG, G1_CFG, G1_MINIMAL_CFG, and G1_29DOF_CFG. Those configs live in isaaclab_assets, which is importable on the Lab engine only.

To check for yourself rather than trusting a list, src/unitree_go2w_probe.py lists the library and the config module in one boot:

.venv/bin/antioch scenario run --scenario unitree_go2w_probe --verbose

Step 3 · Spawn a stock robot

For a robot the library already has, point at its USD and let the engine spawn it. On Isaac Sim, resolve the asset root and reference the file:

from isaacsim.storage.native import get_assets_root_path
usd = f"{get_assets_root_path()}/Isaac/Robots/Unitree/Go2/go2.usd"

On Isaac Lab, use the shipped config instead, which carries both the USD path and the tuned actuator groups:

from isaaclab_assets.robots.unitree import UNITREE_GO2_CFG
robot = Articulation(UNITREE_GO2_CFG.replace(prim_path="/World/robot"))

Step 4 · Build a robot the shelf does not have

This is the Go2W path, and it applies to any Unitree model missing from the library. Unitree publishes official URDFs in unitreerobotics/unitree_ros under robots/<model>_description, with real masses, limits, and geometry. The pipeline is fetch, patch, import, bake, and it lives in src/unitree_go2w_bake.py:

.venv/bin/antioch scenario run --scenario unitree_go2w_bake --verbose

Four things about the importer on this engine, all measured rather than documented:

• Importer 3.11.2 has no Kit commands. The documented URDFParseAndImportFile belongs to an older generation. Use URDFImporter(URDFImporterConfig(...)).import_urdf() from isaacsim.asset.importer.urdf.
• Its usd_path is a directory, not a filename. Output lands at <usd_path>/<robot>/<robot>.usda with payload files beside it, and the call returns the file it wrote.
• It converts primitive collisions and silently drops mesh collisions. A Go2W imported as-is has no wheel colliders at all and rests on its belly, so author convex hulls on the visual meshes yourself, per mesh rather than on the parent Xform.
• Patch package:// mesh references to relative paths before importing.

The bake then writes gains into the USD DriveAPI so the file stands on its own. Two conversions matter: USD angular drives store stiffness and damping per degree while robot gain tables are per radian, so divide by 57.2958, and wheel joints take velocity drives with stiffness zero rather than position drives.

Step 5 · Give it a controller

No pretrained locomotion policy ships with either engine for a wheeled quadruped, and Unitree's own RL repositories cover Go2, H1, and G1 rather than the W variants. The one public source of deployable checkpoints is fan-ziqi/rl_sar, which also deploys them to real robots over unitree_sdk2. It carries policies for go2, go2w, b2, b2w, g1, a1, lite3, tita, and others.

Read the contract from each policy's config.yaml rather than guessing it. The two we run differ in a way that matters:

Both are velocity-commanded at the operator level, meaning you send a body twist of forward speed, lateral speed, and yaw rate at 50 Hz on a 200 Hz sim. Set the policy's own gains on the articulation controller at runtime, which is what the real deployment does.

Step 6 · Gate it on physics, not on video

A robot that looks fine in a clip can be sliding on frictionless wheels or holding a pose the drives cannot actually produce. Every scenario here asserts measured quantities, and the useful gates for legged robots are base height above a floor, tilt off vertical, joint tracking error, and real displacement over ground for a commanded velocity.

Allow a grace window at the start of each segment. A dropped-in robot rocks once while the controller catches it, and on the Go2W that transient reaches about 27 degrees of tilt before settling under 4 degrees. Judging the caught state rather than the transient is the difference between a meaningful gate and a flaky one.

Engine gotchas

Verified runs

Scenarios referenced here: src/unitree_go2w_probe.py, src/unitree_go2w_bake.py, src/unitree_go2w_policy.py, src/unitree_go2w_follow.py, src/unitree_g1_policy.py, and src/unitree_stand.py for the Isaac Lab bake pattern.