You train a robot in Isaac Lab for hours. The reward curve climbs, the simulated robot starts doing what you wanted, and then training finishes. What, concretely, do you walk away with? The answer is a policy - and understanding exactly what that is demystifies the entire reinforcement-learning workflow.
A policy is a function
At its heart, a policy is just a function that maps an observation to an action:
action = policy(observation)At every step of control, the robot looks at its situation and the policy decides what to do. That’s it. The whole point of training is to find a version of this function that makes good decisions - and “training” means adjusting the function’s internal numbers until the actions it picks earn high reward.
Physically, it’s a neural network
In Isaac Lab, that function is a neural network - usually a modest multi-layer perceptron, sometimes a recurrent network when the task needs memory. Two things define its shape:
- The input is the observation vector: a flat list of numbers describing the robot’s state - joint angles and velocities, body orientation, velocity commands, recent actions, sensor readings. Whatever you decided the robot needs to “see.”
- The output is the action vector: the commands the robot acts on - target joint positions, velocities, or torques.
During training, the network actually outputs a distribution over actions (a mean and a spread) so the robot can explore. At deployment, you usually just take the mean - the confident, deterministic choice.
It comes in two forms
This trips people up, so it’s worth being precise. The policy exists in two distinct forms depending on what you’re doing with it.
The training checkpoint. While training runs, Isaac Lab saves checkpoint files (.pt or .pth) into your logs directory. These hold the full model state, including optimizer information, and are tied to the RL library you used. This is the “work in progress” form - perfect for resuming or fine-tuning, not meant for deployment.
The exported policy. When you run the evaluation/play step, Isaac Lab exports a clean, standalone version into two portable formats:
- TorchScript (
.pt) - the network bundled with its observation normalizer, runnable without the training framework. - ONNX (
.onnx) - a framework-agnostic format you can run through high-performance engines like TensorRT on a real robot.
The checkpoint is the artifact; the exported file is the product.
The hidden catch: the observation contract
Here’s the subtlety that bites people in deployment. The exported network is just math on a raw vector of numbers. It has no idea what those numbers mean. If you trained with joint positions in a specific order, scaled a certain way, the real robot must feed observations in that exact order and scale - or the policy quietly misbehaves.
This is why good tooling now exports an I/O contract alongside the policy: a config file capturing joint names, observation ordering, history buffers, and action scaling. Get the contract right and the policy transfers; get it wrong and you’ll chase a “broken” policy that was never broken.
The takeaway
A policy out of Isaac Lab is a small neural network mapping observations to actions, delivered first as a training checkpoint and then as portable TorchScript and ONNX files. It is the distilled result of all that simulated experience - the robot’s learned instinct, frozen into weights you can ship.