Bring us a robot and a task.
Vesk is not open yet. Access opens in waves, starting with the people who have a specific robot in front of them and a specific thing they want it to do.
Access opens in waves.
There is no launch day to sit and wait for. Access opens a group at a time, and each group stays small enough that we can pay attention to it.
Who we're prioritising.
The list is not first-come. We are starting with people who can point the thing at a real mechanism, because that is the only place we learn anything we did not already assume.
Robotics developers
You have a URDF, or the CAD you would generate one from, and something specific you want the arm to do. You have written ROS 2 nodes by hand, so you already know what a bad one looks like.
Students and research labs
A robot on the bench, a queue of tasks for it, and less time than ideas. Setups where the controller is a means to an end rather than the project itself.
Early-stage teams
Building on a robot without a dedicated controls engineer, where the node gets written by whoever has the afternoon and reviewed by nobody.
What you get.
Three things, and the third is the one we would care about most if we were the ones signing up.
The engine, when your wave opens
Your robot’s description and a task in plain language go in. A ROS 2 Jazzy package comes out — the node, and a verification case written against the task’s success criteria rather than against the code.
The verification harness
The generated package is built and run inside a containerized ROS 2 Jazzy environment — isolated, resource-capped, no network — before any verdict is put in front of you. A case that exits cleanly having checked nothing counts as a failure, not a pass.
Your runs, reported as verified or not
Every run says what was actually checked and what was not. Physical scoring in MuJoCo is marked advisory and never gates a result: it does not run your generated code, so it is not evidence about your generated code, and the record says so permanently.
What we'll ask you for.
Not much, and none of it is a form for its own sake.
Your robot's description
A URDF, or the CAD export you would build one from. Links, joints, and which of those joints are actually actuated.
The task
In the words you would use with another engineer. “Close the gripper on the block and hold it” is a task. “Pick and place” on its own is a category.
What went wrong
When a run fails — and runs fail — the failure is the part we need back: the code, the verdict, and the assertion that did not hold.
To say it plainly: we want the failure cases. A system that has only ever been shown the runs that worked is a system nobody should trust, ours included. If the output was wrong, do not tidy it up before you send it — the wrong version is the useful one.
Join the waitlist.
Your email, and what you'd point it at. The second field is optional, but it is the one that tells us which wave you belong in.
The form is interface only for now — there is no backend behind it, and submitting stores nothing.