​
About Ballot

A platform that lets people pilot your robot simulation from a VR headset and gives you every attempt back as a checked, replayable episode.
No. Ballot is the platform, not a team of operators. In the first release you invite your own pilots with private links. Funded requests that any eligible pilot can pick up are planned.
No. Everything happens in simulation: people pilot simulated robots in your simulated world. Each episode records exactly which simulation produced it.
No. Ballot collects and organises episodes. You train with your own tools.
Ballot is in early access. We’re building the first release with a small group of design partners. Join the waitlist to be considered.

​
For developers

Not for a supported framework. For robosuite you point Ballot at the function that builds your environment, and it runs as it is. Standalone MuJoCo apps will need a short wrapper around their existing functions. See Supported simulators.
The first release supports robosuite on MuJoCo. Isaac Lab and standalone MuJoCo apps are planned next.
Ballot is built for every kind of robot: arms, two-arm setups, rovers and mobile bases, legged walkers, humanoids and drones. Each type gets VR controls made for it and drives your robot’s own controller. The first release starts with robosuite arms, and the other types roll out one at a time. See Robots and VR controls.
Yes, that’s what co-op scenarios are for. Each robot is a seat for one pilot, and the task can have steps and handoffs between robots. Team play rolls out after the first release. See Create a scenario.
Yes. Ballot doesn’t teach robots to walk, balance or fly. They bring their own controller, such as a trained walking policy, and pilots tell it where to go. See Upload a robot.
No. Ballot supplies the headset experience and the controls, and connects them to your robot’s own controller. At launch it runs in the headset’s browser with WebXR, and native Meta Quest and SteamVR apps are rolling out soon.
Full native episodes: the starting state, what the pilot asked for, what your controller applied, the simulation state at every step, the task’s events and outcome, and everything needed to replay it. See Episodes and data.
Mostly, yes, because episodes keep the full simulation state. Rendered camera views and dataset exports are planned. Some things can’t change after collection, such as the robot, its controller and what the pilot could see. See what you decide up front.
You decide who can join and who can read episodes. Pilots can’t download your code or other people’s episodes. A pilot’s headset does receive the meshes and textures it has to draw, so don’t publish geometry you need to keep secret.
Yes. Every command-line action has JSON output and uses the same permissions as the dashboard. See the CLI reference.
Pricing isn’t set yet. You’ll pay for the cloud time your sessions use, and every session has a spending cap you control. Bounties for pilots are optional and planned.

​
For pilots

A Meta Quest headset with its built-in browser, a Wi-Fi connection and an invite or team link. There’s nothing to install and no account to create. See Pilot a robot.
At launch, you pilot in Meta Quest Browser using WebXR. Native apps for Meta Quest and SteamVR are rolling out soon, and SteamVR will bring PC VR headsets.
No. Every robot has simple controls: grab a target for an arm, push a stick to drive or walk. Every session starts with practice time, and the menu always shows the controls.
Yes, in co-op missions: each of you takes a seat and controls a different robot in the same world, with voice chat and a shared reward. Team play rolls out after the first release, which has one pilot per session. See Team play.
A team request pays per accepted run and shows how that’s split across seats before anyone joins, usually equally. See Team play.
Not today. Paid requests, where pilots earn for each accepted episode, are planned. See Requests and bounties.