The arm in the lab sits idle most of the time.In those hours it can record data somebody pays for.
A robot arm does not learn a task from a description. It learns from recordings: a person guides the arm through the task while cameras write down the picture and sensors write down the joint angles. Whoever needs recordings like that posts them on AY-Robots and puts money behind them. Whoever has a fitting arm records and gets paid. In a lab the arm is already standing there.
Your chair needs the data rather than the recording hours?Post the request yourself, no account needed to fill it in
- Yours
- The dataset you record
- 90 %
- Your share of every paid episode
- €10
- Payout from this amount
- LeRobot
- Format of every recording
What actually happens here
Three parties, one shared pot, billing by the hour. In that order.
AY-Robots has had a marketplace for finished datasets for a while: somebody made the recordings, somebody else buys them. What is new is the other direction. Whoever needs recordings that do not exist yet describes them and commissions them. The pot that fills up in the process is called a Collection.
Three parties hang on a Collection. The first is the requester. That can be a company, a lab or a private person. They write down which robot arm is meant and what the arm is supposed to do, and they set how many recordings they need and how much money they put behind it. Their name appears nowhere. Requests are always anonymous.
The second are the collectors. A collector reads the description, rebuilds the scene at their own place, records and uploads. They need no application and no contract for that, only a fitting arm and the time. They can stop after ten recordings and they can carry on after three hundred.
The third is the platform. It holds the money until the requester has reviewed the recordings. It links the datasets of all collectors into one Collection without mixing them. And it bills by the hour rather than by the file, because one recording takes five seconds and the next takes two minutes.
Two words that come up again and again on this page and do not mean the same thing: a dataset is what you record. It belongs to you, the same way it does today. A Collection is the requester pot. It consists of many datasets from many people, and the requester sees it as one whole.
- The request is a tile in the marketplace. Anyone can open it.
- Recording happens at your place, with your arm and your cameras.
- Payment is by the hour, settled per accepted recording.
- Your dataset stays yours.
Why a robot arm needs recordings at all
Once you have understood this, you also understand why time at an arm is worth something.
A classic robot program tells the arm where to drive: point by point, angle by angle. That works as long as the world holds still. As soon as the cup stands somewhere else every time, the light changes or the object is soft and gives way, the program gets longer and longer and still misses.
The other route is called imitation learning. Instead of describing the motion, you show it. A person guides the arm through the task while cameras record the picture and the joints report their angles. One such recording from start to finish is called an episode. Out of many episodes a model works out which motion belongs to which picture. After that it drives the task by itself, even when the cup stands a little differently.
The catch is the quantity. For a single task a model becomes useful after a few hundred episodes. Every one of those episodes is a person guiding the arm, tidying the scene up again and starting over. At roughly a minute per episode, three hundred episodes are a full working day, and that is for one task, in one environment, with one arm.
That is exactly where it jams. The models are openly available and the arms have become affordable. Recordings are still made by a person, task after task, hour after hour. That is why people buy them. That is why an hour at an arm is worth something. And that is why a lab with an arm that stands still most of the time is an unclaimed asset.
- An episode is one recording from start to finish, with picture and joint angles.
- A model learns from many episodes, not from a description.
- The recordings only come into being on real hardware, in real time.
- This is not a computing problem. It is working time at a table.
A request, step by step
Five stations from posting to payout. At the top right you can switch the view. The same station looks different for the collector than for the requester, and at several points one of the two sides deliberately sees nothing at all.
The screens are rebuilt from the real ones and carry example values, not live requests. The camera frames and the desktop client are real.
The request is created
The requester fills in a short form. Two entries are mandatory: which robot arm is meant, and what the arm is supposed to do. The description box carries the main load, because there is no form here with twelve separate fields for lighting conditions and gripper angles. Whoever wants to can attach pictures, videos or documents. None of that is mandatory. On top of that come the number of episodes wanted and the budget; what an hour is worth follows from those two.
See how a request is postedThere is nothing to see yet. A request only becomes visible once it has been posted.
Your dataset stays yours
Whether one person delivers or fifteen: the requester sees one whole, and every recording still belongs to whoever made it.
This is where a request differs from everything else you know. Your recordings are not pushed into somebody else folder. You create a dataset, exactly as you do today, with your cameras, your frame rate and your numbering. That dataset is merely linked to the request.
Through that link the requester sees a composed view: a fill level, a total number of episodes, one download. Behind it there are still as many datasets as there are people. The assembly happens at download time, not at upload time, and whatever does not match the specification does not go in and is named to them.
For you that has three consequences. First: nothing is renumbered, and nobody writes into your data. Second: different camera counts and resolutions between two labs do not break the recording, because every dataset stays coherent in itself. Third, and this is the decisive one: you keep what you recorded.
So that the parts fit together in the end, the request specifies two things. The embodiment, that is which arm, is not negotiable: a different arm has different joints and different value ranges, and that cannot be aligned afterwards. And the cameras are assigned by role rather than by number, so wrist, front, side. Whoever skips that delivers an archive that opens and is still wrong: if the first camera sits at the wrist for one person and at the front of the table for the next, training runs through and the policy drives wildly later. Nobody notices that. This is why you assign your cameras explicitly while setting up.
Many collectors
Each at their own setup, at their own time, with their own dataset.
One specification
The same embodiment, the same camera roles, the same task.
One Collection
The requester sees one whole and downloads once.
The one catch you have to read first
A requester can post their request as exclusive. If that box is ticked, you may not additionally sell the dataset you recorded and were paid for in the marketplace afterwards, and the platform does not technically allow it either. Without the box you may. This stands on the tile before you begin, not in the small print at handover, and it cannot be changed afterwards in either direction.
What an hour at the arm brings in
Set the rate and your free hours; the calculation runs on the same lines the platform bills with.
The rate is set by the requester and it stands on the tile. The ends of this slider are the rates we publish today for remote-controlled recording sessions; for commissioned requests there is no published range yet.
Calculated with a set assumption of 20 recordings per hour; in the real case that number comes from the time allowance of the request.
Mark the hours in which nobody needs the setup.
€226.80
€982.80 per month (52 divided by 12 weeks) · 280 recordings per week
- Comes to, per hour at the arm
- €16.20
- Of that, platform share (10 %)
- - €1.80
Show the whole calculation
- Price per recording
- €0.90
- Stays with you, per recording
- €0.81
- Recordings per hour
- 20
Payable as soon as the requester has accepted. From €10.00, to a bank account or to the payout method stored in your account.
A calculation, not a promise. Payment is per accepted recording: discarded and rejected recordings do not count.
For supervisors
Seven questions that come before the first go-ahead, and the answers we can give.
The arm stays in your lab, under your supervision, operated by somebody standing in front of it. Nobody reaches in from outside.
You do. Whoever records for a request creates their own dataset, exactly as today, and stays its owner. The requester gets the right to use it for their project, and that is what they pay for. What they do not get is your dataset instead of you.
The one restriction is stated explicitly further up: if they post the request as exclusive, you may not additionally sell the same dataset afterwards. You see that beforehand on the tile, and it does not change afterwards.
And if the institute wants to train on that data rather than only record it: the runs rent their cards by the minute, and no graphics card has to be bought for it.What training without your own GPU costs
You want several places for a course or a lab practical? Write to us
Recording for yourselves or recording on request
Two routes, the same software, the same arm. The difference is not in the technology.
| Question | For yourselves | On request |
|---|---|---|
| Who owns the dataset | You | You |
| Who may use it | You | You and the requester, who pays for it |
| Who sets the task | You | The posting |
| Where the raw data sits | On your computer, uploading is voluntary | On your computer, what goes into the request is uploaded |
| Who pays | Nobody | The requester, by the hour |
| Who reviews | You yourselves | The requester, recording by recording |
| Resale in the marketplace | Any time | Only if the request is not exclusive |
| What it is good for | Your own publication, your own model, your own teaching | Extra income, practised hands, a setup that stays in operation |
The two do not exclude each other. The same arm can record for you one week and for a request the next. That is decided per recording, not per semester.
How much a commission is worth depends on one thing above all: how many other people can record on that arm.How rare is the arm in your lab?
Three ways to fit this into a degree
The same process, three different reasons to do it.
Four people, one request, four datasets in one Collection
A group takes on an open request and splits the hours between them. Each of them builds the scene according to the specification, assigns their cameras to the required roles, records their part and uploads. Because everybody works to the same specification, the four datasets fit together in the end without anybody having to align them by hand.
The learning effect sits exactly where it usually goes missing in data work: with the first rejections the group notices how much a clean specification is worth, and reads differently afterwards.
- Task
- Work on a posted request until the pot is full
- What comes out of it
- Your own dataset in the LeRobot format, plus a recording routine that sits
- How it is measured
- Share of accepted episodes, and how it climbs over the weeks
The list is short
If recording already happens in the lab, you have everything.
- Arm
- The one named in the request
- This is the only hard requirement. The catalogue knows 353 models from 37 brands, and a self-built arm goes in as free text. A request for a different arm cannot be served with it: a model learns the motion of one particular mechanism.
- Cameras
- As many as the request names roles
- Every camera is assigned its role while setting up, wrist or front for instance. Explicitly, not via the file name.
- Computer
- macOS, Windows or Linux
- The client detects arm and cameras by itself. No Python environment, no driver hunt, zero lines of code.
- Space
- A table that can be reset
- Between two recordings the same starting state has to be restorable. That is the actual requirement, not the size of the table.
- Time
- A block in which the setup is free
- Two hours in one go bring more than four separate quarter hours. Setting up only happens once.
- Account
- Role Robot Trainer
- There are two roles at sign-up. You need Robot Trainer, not Remote Data Collector: the second role is for people who remotely operate arms belonging to others, and with it you cannot get to a request.
What this is not
So that nobody starts with the wrong expectation.
- Employment
- Not a side job with fixed hours
- There is as much work as is currently posted. If no open request fits your arm, there is nothing to do that week.
- Contract
- Not a job
- You work on your own account. Taxes and the rules of your country are your business; we withhold nothing and remit nothing.
- Insight
- No look into other people research
- What stands in the request is everything you learn. Who is behind it and what the data is for, you do not learn.
- Billing
- No payment without acceptance
- A rejected recording is not paid. The reason comes with it, and the next recording gets better for it. Without review the Collection would be worthless to the requester.
- Access
- No remote control of your arm
- With a request nobody steers from outside. Whoever wants that has to switch teleoperation on explicitly, and that is a different product.
- Speed
- Not quick money
- The first hour goes on setting up, calibration and the first failed attempts. Recordings are paid, setting up is not.
Frequently asked questions
Yes, if you are willing to practise the first hours without earning. The arm is operated through a second, identical arm that you guide by hand. The motion transfers; that is understood in ten minutes. What takes longer is everything around it: placing cameras so that the task is visible, calibrating once, and getting a feel for what a usable recording looks like. The client walks you through every episode in the same order so that you do not have to concentrate on that.
Read on
The client
What you record with. Detects arm and cameras by itself, exports to the LeRobot format, runs on macOS, Windows and Linux.
Read moreSO-100
The arm that stands in most labs. Assembly, calibration, first recording.
Read moreCommission data instead of recording it
Describe the task once, pay by the hour of recorded material, and let people with the right arm record it.
Read moreMarketplace
Finished datasets and open requests in the same place.
Read moreOpen requests, right now
The public directory: which arm, which task, what an hour pays, how full the pot already is.
Read moreSelling recordings you already have
A finished dataset from a past project can be listed for sale. What the fee leaves you, in one calculation.
Read moreThe arm is standing there anyway.
Have a look at which requests are open right now. You only need an account when you want to record, and the client only after that.