Isaac Lab

The goal is the same as for every framework: you bring your registered Isaac Lab task, and pilots drive it through the same headset app, recordings and replay as a MuJoCo simulation. Here’s how we expect it to work.

​

Your task stays native

• You point Ballot at your registered task and its configuration. Ballot builds one interactive environment from it. If that needs a single-environment or headless version of your configuration, preparation shows you the change before you accept it.
• Your action terms stay as they are. Many Isaac Lab tasks control the arm with joint-position actions. Ballot solves for joint targets that reach the pilot’s hand target, then feeds them through your original action term, with its ordering, scaling and clipping.
• Your events, sensors and terminations stay as they are. The task’s own success and ending rules decide each attempt’s outcome. Ballot captures how an attempt ended before Isaac Lab resets the environment.

​

Legged robots and humanoids

Many Isaac Lab tasks train quadrupeds and humanoids to follow velocity commands, such as walking tasks for ANYmal, Unitree Go2 or G1. A policy trained that way already accepts the commands pilots send: pilots choose the direction and speed, and your policy does the walking. See Robots and VR controls.

​

Isaac Lab Arena

Arena already splits an environment into a scene, an embodiment and a task. Ballot will use those pieces directly, so the same Arena task can run against different destinations or scenes without being rewritten. It won’t be translated into a MuJoCo-style task.

​

What will be different from MuJoCo

​

Licensing

Running Isaac Sim for outside pilots involves NVIDIA’s licence terms for the runtime and its assets. We’re confirming them for this use before we launch Isaac Lab support.