At a glance
Each framework runs on a tested runtime profile: a pinned simulator version, Python version and Ballot integration.
ballot sim profiles list shows the profiles available to your project, including which robots each one supports.
robosuite environments like these, rendered in MuJoCo. Which tasks and robots are qualified for piloting is listed per runtime profile.
Robots of any type come to Ballot the same way in every framework: with the controller that already moves them. A walking humanoid in Isaac Lab and a rover in a MuJoCo app both receive commands from pilots and do their own moving. See Robots and VR controls.
What an integration does
Reads your environment
Finds the robot, gripper, controller, reset and success rule, using the framework’s own structures.
Connects the controls
Turns the pilot’s hand target into commands for your robot’s controller.
Extracts the scene
Gives the headset the meshes and textures to draw, then streams positions as they change.
Records at the source
Saves actions, state and task events at every step of your simulation.
Why one framework at a time?
There’s no portable “simulation file”. A MuJoCo scene is data, but a task’s reset, success check and controller are code, and every framework structures that code differently. Pretending otherwise would mean rewriting your task in someone else’s format, or guessing at what your code means. So Ballot keeps your code native and adds one well-tested integration per framework. When we add a framework, every simulation built on it can come in without changes.Choosing where to start
- You use robosuite, or a project built on it: you can start with the first release. Read the robosuite guide.
- You wrote your own MuJoCo app: see what the wrapper will look like, and join the waitlist so we know you’re interested.
- You use Isaac Lab: see the Isaac Lab plan. It’s the next framework we’re adding.