Platform overview

What AY-Robots is

AY-Robots is a teleoperation platform for robot arms. Clients connect their hardware, most commonly the SO-100 (also sold as SO-ARM100), and remote operators drive those arms from a browser cockpit. Every controlled minute is recorded, so a session produces two things at once: work done on the robot and a demonstration dataset you can train policies on.

The platform has three roles. CLIENT accounts own robots, book sessions, and receive the recorded datasets. OPERATOR accounts drive robots and earn money for completed sessions. ADMIN accounts manage the platform itself, including the review of operator certifications. You pick your role during onboarding, and each role gets its own dashboard.

Nothing about this requires you to write robot drivers. Support for the SO-100 is built in, from servo communication on the arm to episode encoding in the dataset browser. If you can plug in a USB cable and open a browser tab, you can run the full loop.

The loop: robots, operators, sessions, datasets

Everything on the platform revolves around one loop. Once you can see it, the rest of the documentation reads much faster, because every page describes one station of this loop in more depth.

1. 1
   Connect a robot

   A client pairs an arm with the platform using a short pairing code. Once the code is redeemed on the machine at the arm, the robot reports a heartbeat and shows up as online in its environment.

2. 2
   Book a session

   The client books a session, or a certified operator picks up an available robot. The session starts as PENDING and becomes ACTIVE the moment the operator connects and takes control.

3. 3
   Teleoperate

   The operator controls the arm from the browser cockpit while watching the robot's cameras. The platform logs activity events throughout and records joint positions, gripper state, and video.

4. 4
   Collect the dataset

   When the session completes, the recording is organized into episodes in LeRobot format and appears in the client's dataset browser, ready for review and download.

5. 5
   Train and repeat

   Clients train policies such as ACT, Diffusion Policy, SmolVLA, or GR00T fine-tunes on the collected data, then book more sessions to cover the situations the policy still fails on.

What people use it for

The three most common reasons to be here overlap, but they are worth separating, because they change which docs you should read first.

• Imitation learning data collection. Teams that train manipulation policies need many clean demonstrations. Remote operators can record them around the clock, on your hardware, without you standing next to the arm.
• Remote operation. Sometimes the point is simply that the robot does the work while the person is somewhere else, whether that is a different room or a different country.
• Scaling without on-site staff. If you own several rigs, hiring and scheduling local operators for each of them is the expensive part. The operator marketplace removes that constraint.

If data collection is your goal and the arm sits on your own desk, also look at the desktop client. It records episodes locally with a guided flow and uploads them when you decide, without a remote operator involved at all.

Architecture at a glance

You interact with up to three pieces of software, depending on what you are doing. They talk to the same backend and the same account, so a robot paired once is visible everywhere.

Authentication follows the same split. The browser uses your Supabase session, while the API and the MCP integrations use API keys with the ayr_live_ prefix, created under /dashboard/settings. Keys are for programmatic access only; you never paste them into the cockpit.

Where to go next

Frequently asked questions