Training a Custom Quadruped from Scratch in Isaac Lab

1 Sim vs. Lab, in plain words

The two names confuse everyone. Here is the short version.

Mental model if you come from web dev: Isaac Sim is the renderer plus physics. Isaac Lab is the game framework that wires up player input, scoring, level reset, and parallel instances. PPO is the agent that figures out the controls.

2 Install on Windows

The clean path that worked here is the pip install of Isaac Sim plus Isaac Lab from source, all in one Python 3.11 venv. No Docker, no Visual Studio, no source build of Sim. Big install, but reproducible.

What lives where

Isaac Lab repo : C:\Users\jaha\robotic\IsaacLab
Virtual env    : C:\Users\jaha\env_isaaclab
Python         : 3.11
Isaac Sim      : 5.1.0
torch          : 2.7.0+cu128

The five commands that matter

py -3.11 -m venv C:\Users\jaha\env_isaaclab
git clone https://github.com/isaac-sim/IsaacLab.git C:\Users\jaha\robotic\IsaacLab

C:\Users\jaha\env_isaaclab\Scripts\python.exe -m pip install ^
  "isaacsim[all,extscache]==5.1.0" --extra-index-url https://pypi.nvidia.com

C:\Users\jaha\env_isaaclab\Scripts\python.exe -m pip install -U ^
  torch==2.7.0 torchvision==0.22.0 torchaudio==2.7.0 ^
  --index-url https://download.pytorch.org/whl/cu128

cd C:\Users\jaha\robotic\IsaacLab
.\isaaclab.bat -i

3 First examples to run

Before touching your own robot, run two NVIDIA examples to confirm the install. All three scripts below ship with Isaac Lab and live in the cloned repo under IsaacLab/scripts/. stock isaac lab

Spawn a primitive

cd C:\Users\jaha\robotic\IsaacLab
C:\Users\jaha\env_isaaclab\Scripts\python.exe scripts\tutorials\00_sim\spawn_prims.py

A box appears in a scene. Read the script top to bottom. This is your scene.add(mesh) equivalent.

Drive an articulation

C:\Users\jaha\env_isaaclab\Scripts\python.exe scripts\tutorials\01_assets\run_articulation.py

A robot appears, joints driven by code. The class to look for is ArticulationAction. Joints are the things RL will eventually control.

Train a built-in robot, end to end

C:\Users\jaha\env_isaaclab\Scripts\python.exe scripts\reinforcement_learning\rsl_rl\train.py ^
  --task=Isaac-Velocity-Rough-Anymal-C-v0 --headless

This trains Anymal-C on rough terrain. If the terminal prints rising mean rewards, the install is healthy. You can interrupt at any point and play the latest checkpoint with play.py.

4 Designing in Fusion 360

Fusion is great for building the body. It is bad at exporting it. Plan for both phases.

Build it as components, not bodies

Each link must be its own Component. Bodies inside one component become a single rigid link in URDF, which is almost never what you want. For the four legs of ZHAW Wild, use prefixes fl_, fr_, rl_, rr_ on every component name. You will love yourself in three hours.

Joint discipline

• Revolute for hips and knees. Always set joint limits in Fusion. URDF inherits them.
• Rigid for fixed connections. Cheaper than fixed joints in URDF.
• Avoid continuous unless you really mean unbounded rotation. Wheels yes, hips no.
• For copied legs, use Make Independent on the components. Otherwise both legs share one joint and the URDF will be mysterious.

Three things to set before export

1. Set the world origin sensibly. The base link will sit at this origin.
2. Apply real materials so mass and inertia are not zero. Steel is rarely correct for hobby parts. Use ABS or aluminum.
3. Pre-orient the robot to Z-up if your exporter offers it. Otherwise you fix this later in code.

5 Exporting to URDF

Fusion has no native URDF export. Use the ACDC4Robot add-in. It writes URDF in the Gazebo flavor, which is identical to what Isaac Lab consumes. Three tabs to set: choose URDF as the format, pick an output folder, click run. The add-in walks the component tree and emits one <link> per component plus one <joint> per Fusion joint.

Why URDF, not the USD that Fusion can spit out

A USD exported straight from CAD looks fine in a viewer and silently fails in Isaac Lab. The same three sins show up every time:

• No ArticulationRootAPI on the root prim. Isaac Lab does not see a robot, only a bag of Xforms.
• Loose nested Xform hierarchy like /World/asm/asm/... because every assembly layer becomes its own group.
• Auto-generated joint names stitched together from the connected components, for example revolute_joint_body_uleg_fl. They work mechanically, but no regex you write will be readable.

The fix is the same every time: regenerate URDF, hand that to Isaac Lab, and let Lab bake a compliant USD itself. Isaac Lab adds the ArticulationRootAPI, contact-reporting hooks, and inertial tensors during conversion. Going through URDF is the only path that gives you these for free.

What to fix in the URDF after export

• Joint type. ACDC4Robot sometimes emits continuous for joints you defined as revolute. Open the file, search for type="continuous", replace with type="revolute", and add <limit lower="..." upper="..."/>.
• Y-up vs Z-up. Most CAD exports are Y-up. Isaac is Z-up. Either rotate the robot in Fusion before export, or apply a +90° rotation in init_state.rot later. Quaternion (w, x, y, z) = (0.7071, 0.7071, 0, 0).
• Mass and inertia. Confirm none are zero. Easiest check: load the URDF, run a step, watch if the robot collapses sensibly under gravity. A truly massless link is silent and weird.
• Mesh paths. URDF uses package:// paths in ROS land. Isaac Lab is happy with relative file:// paths or plain relative paths. Keep meshes next to the URDF.

6 Loading into Isaac Lab

Two files own the robot side: an asset config and a task registration. For ZHAW Wild they sit at:

IsaacLab\source\isaaclab_assets\isaaclab_assets\robots\zhawild.py
IsaacLab\source\isaaclab_tasks\...\velocity\config\zhawild\__init__.py
IsaacLab\source\isaaclab_tasks\...\velocity\config\zhawild\flat_env_cfg.py

Open the live files: zhawild.py (asset) · __init__.py (task registration) · flat_env_cfg.py (env) · rsl_rl_ppo_cfg.py (PPO).

The asset config view full file

ZHAWILD_CFG = ArticulationCfg(
    spawn=sim_utils.UrdfFileCfg(
        asset_path="path/to/quadruped_zhawild_v1/quadruped2.urdf",
        rigid_props=...,
        articulation_props=...,
    ),
    init_state=ArticulationCfg.InitialStateCfg(
        pos=(0.0, 0.0, 0.75),
        rot=(0.7071068, 0.7071068, 0.0, 0.0),    # Y-up to Z-up
        joint_pos={".*": 0.0},
    ),
    actuators={
        "legs": ImplicitActuatorCfg(
            joint_names_expr=[".*_haa", ".*_hfe", ".*_kfe"],
            stiffness=80.0, damping=2.0,
        ),
    },
)

The viewer parses the same STL meshes Isaac Lab loads, in the same joint hierarchy. Drag the sliders to drive the hfe (hip flexion) and kfe (knee) joints across all four legs. Source: quadruped2.urdf + 11 STL meshes.

Why URDF is passed in, not USD

Isaac Lab attaches contact-reporting APIs to the foot links during URDF conversion. That is what makes the gait, air-time, slip, and body-contact reward terms work. If you pre-convert to USD outside the loop, you skip that step and your foot contacts will be empty. Pass the URDF, let Lab convert it once, cache it.

7 Building the training environment

An Isaac Lab env is a Python class made of seven configs. Read this once, then it is just lego.

The simulation loop, end to end

One iteration of the inner loop is one physics tick across all 1024 parallel envs. PPO collects 24 ticks per env, runs a gradient update, and starts the next iteration. That is the heartbeat.

Terrain

Isaac Lab ships a procedural terrain generator. Three shapes you actually want:

• Flat plane. Use it for early training and for clean playback. Anything weird you see is the policy, not the floor.
• Rough terrain. Bumpy heightmap. Forces the policy to handle uneven contact, which is most of the value of training in sim.
• Stairs and gaps. Optional. Useful only if your reward and observation include height-scan info.

Obstacles

Movable obstacles are just rigid bodies you spawn into the scene with collision and mass. Boxes and cylinders work fine. They are not part of the policy observation, the robot just bumps into them. Useful for stress testing and for the kick-disturbance scenario described later.

Domain randomisation

The single thing that makes a sim-trained policy survive in the real world. In ZHAW Wild we randomise:

• Static and dynamic friction at the foot per env.
• Base mass within ±10 percent.
• A small velocity push every 10 to 15 seconds, drawn from a square in the xy plane.

Each parallel env gets a different draw. With 1024 envs, the policy sees thousands of variations every minute.

8 Reward shaping & the crawl trap

PPO does exactly what your reward function says, never what you meant. This was the most expensive lesson of the whole project. On Robot20, our 2-DoF custom robot, 15 hours of GPU time produced a policy that maximised every term we wrote, while crawling on its lower-leg shins like skis. No standing, no foot clearance, healthy gait reward, full speed reward.

Three failures that compound

1. Gait reward checks alternation, not posture. A crawling robot with alternating shin contact also satisfies it. Combine the gait term with a base-height target.
2. Termination only on torso and thigh. The lower-leg segment was supposed to be the foot. Lying flat on it was perfectly legal. Add bottom-link termination, or a strong slip penalty when the bottom is in flat contact.
3. Geometry locks you in. A 2-joint leg has no abduction and no ankle. Standing is hard, crawling is easy. No reward function can overcome that. ZHAW Wild with its three rotational DoF per leg does not have this problem.

Reward terms that work for a classical quadruped

A second example from this run · the bunny hop recording · 9 s

Why it hops & what would fix it

The bunny-hop is the exact same kind of reward exploit as the crawl, just one rung higher. The policy satisfies every term we wrote without any of the things that make a gait look right.

In short: the policy has no incentive to stagger the legs. Every reward we wrote is satisfiable by a perfectly in-phase bounce. Adding a single "never less than two feet on the ground" contact constraint, either as a hard penalty or a contact-schedule reward, breaks the hop and forces a real trot. NVIDIA's Anymal and Spot configs do this with a feet_air_time term tuned per-foot and a flat_orientation_l2 term that punishes the pitch wobble that a hop produces on landing.

9 Running PPO & reading the log

train.py and play.py ship with Isaac Lab. stock isaac lab The custom piece is the task ID Isaac-Velocity-Flat-ZHAWild-v0, which gets registered when our zhawild_task package is on the import path.

Train

cd C:\Users\jaha\robotic\IsaacLab
C:\Users\jaha\env_isaaclab\Scripts\python.exe ^
  scripts\reinforcement_learning\rsl_rl\train.py ^
  --task=Isaac-Velocity-Flat-ZHAWild-v0 --headless --num_envs=1024

Play a checkpoint

C:\Users\jaha\env_isaaclab\Scripts\python.exe ^
  scripts\reinforcement_learning\rsl_rl\play.py ^
  --task=Isaac-Velocity-Flat-ZHAWild-Play-v0 --num_envs=1 --real-time ^
  --checkpoint logs\rsl_rl\zhawild_flat\2026-04-26_17-46-09\model_1500.pt

Five numbers to watch

For ZHAW Wild, after 2 h 11 min and 37 M timesteps, mean reward went from 0.9 to 48.7, episode length from 14 to 292, body-contact from 100 percent to 73 percent. The policy is learning. It still falls in three out of four episodes. That is the next training target.

The numbers run 2026-04-26_17-46-09

Highlighted row: the checkpoint model_1500.pt shown in the kick video below. The last row is the final iteration before the run was stopped, slightly worse than 1500. That is why we never replay the last checkpoint.

Charts

10 The kick test

Reward curves do not tell you whether the policy is robust. A kick test does. The training-time push event covers the small disturbances. For a controlled scientific test you want repeatable kicks with known direction and magnitude.

Why keyboard, not mouse

Mouse-click kicks need a viewport raycast. In Isaac Sim 5.1.0 the viewport mouse events are intercepted by the selection and manipulator system before any custom subscriber sees them. Left-click on the robot just selects its prim. Keyboard events go through carb.input which is not affected by UI focus and works as long as the Sim window itself is active.

Bindings

I/J/K/L instead of WASD because WASD is reserved for the viewport fly-mode camera.

Run play_kickable.py custom

C:\Users\jaha\env_isaaclab\Scripts\python.exe ^
  path\to\code\scripts\play_kickable.py ^
  --task=Isaac-Velocity-Flat-ZHAWild-Play-v0 --num_envs=1 --real-time ^
  --checkpoint logs\rsl_rl\zhawild_flat\2026-04-26_17-46-09\model_1500.pt ^
  --kick_speed 2.0

What it looks like recording · 2:25

What the kicks tell you

The implementation pushes via robot.write_root_velocity_to_sim(...), the same call the training-time push event uses. Disturbances are physically equivalent to what the policy was trained against, just on demand.

★ What I would do differently

• Choose three rotational DoF per leg before anything else. Two-joint legs are a research dead end for walking. Hip abduction is what makes lateral stability possible.
• Treat URDF as the source of truth. Generate USD via Isaac Lab on every load. Never edit USD by hand.
• Name joints in the Spot convention from the first Fusion sketch. fl_haa, fl_hfe, fl_kfe. Your future regex configs will thank you.
• Run a smoke test before a long run. One iteration with one env. If it crashes during Isaac Lab startup, the bug is import-time and a long run will not magically fix it.
• Save checkpoints often, ignore the last one. PPO can drift into NaN late in a run while reward and episode length still look fine. Keep save_interval=50 and pick a mid-run model.
• Cross-check rewards against degenerate behaviour before kicking off training. If a crawl satisfies the gait reward, fix the reward, not the training time.
• Build the kick tool early. It takes an hour to write and changes how you evaluate every checkpoint afterwards.

The custom-robot RL pipeline works end to end. URDF in, policy out, kick test for robustness. The remaining work is reward design and physical design. Both of those compound. Both of those are also where the interesting research lives.

A Source files

Every Python file referenced in this post is bundled next to it. Click to read in the browser, right-click to download.

Robot & assets

• quadruped_zhawild_v1/quadruped2.urdf — the URDF the viewer above and Isaac Lab both consume
• quadruped_zhawild_v1/ — 11 STL meshes referenced by the URDF

Isaac Lab asset config

• code/asset_cfg/zhawild.py — ZHAWILD_CFG: spawn pose, Y-up to Z-up rotation, joint defaults, actuator gains. Goes into IsaacLab/source/isaaclab_assets/isaaclab_assets/robots/.

Training task package

• code/zhawild_task/__init__.py — gym.register(...) for Isaac-Velocity-Flat-ZHAWild-v0 and the play variant
• code/zhawild_task/flat_env_cfg.py — scene, observations, rewards, terminations, events, terrain
• code/zhawild_task/agents/rsl_rl_ppo_cfg.py — PPO hyperparameters
• code/zhawild_task/mdp/__init__.py — custom reward / observation terms re-exported here

Drop the whole code/zhawild_task/ folder into IsaacLab/source/isaaclab_tasks/isaaclab_tasks/manager_based/locomotion/velocity/config/zhawild/. Isaac Lab auto-imports task packages on startup, which is when gym.register(...) runs.

Runtime scripts

• code/scripts/load_zhawild.py — minimal loader, drops the URDF into a Sim with ground and light. The "does the asset even spawn" smoke test.
• code/scripts/play_kickable.py — fork of play.py with the keyboard kick controller from Section 10

This page

• index.html — the post itself, plus the embedded Three.js URDF viewer in Section 6
• README.md — repo overview, how to run locally