We handed out 8 robotsfor the summer and didn’ttell anyone what to build.Here’s what happened.

The six projects had nothing to do with each other: flipping industrial switches, delivering meals in a care home, home care for older people, tidying a student room, a kitchen companion and a bartender. And yet every team built basically the same thing. Teleoperate the arm, record demos with LeRobot, train ACT or SmolVLA, run it on the Jetson, and watch what’s going on through a wrist camera.

Nobody wrote a controller from scratch. Nobody trained a foundation model. Nobody touched simulation or reinforcement learning. Most teams tried a few different policies along the way, and AeroRozum actually kept track and reported it: they trained SmolVLA, ACT and a diffusion policy on the same demos and went with whichever worked best. Either the stack has grown up enough that you can just pick it up and use it, or everyone’s stuck in the same monoculture. Probably a bit of both.

If you look inside these robots, surprisingly little of them is actually a neural network, and that part is slow. A single grasp running inference can take up to twenty seconds. That’s not a knock on anyone, it’s just where things are at this scale. But it means you can’t have a policy running every part of the task.

So nobody did. ForestBridge used Nav2 to get around and only switched to a learned policy for the grasp itself. Primal Intelligence put their policies behind a cloud job queue: the robot grabs a meal job, drives from the kitchen to the table, uses ACT only for the pick and place, then reports back, with the job tracking checking exit codes along the way. Robomates’ bartender has seven stages, two learned and five scripted.

Zuper took this the furthest. Classical vision finds the breaker and builds a four-number state vector for the policy: the relative offset to the target, plus a +1 or -1 flag for whether the switch needs to go up or down (it’s the same motion either way, just flipped). It also draws a synthetic image marking the breaker body and the contact point, and feeds that in as if it were a third camera. The actual motion comes from plain, unmodified LeRobot ACT. Afterwards, classical vision checks whether the switch really moved. The part other people could steal: he didn’t change any policy code. Both signals just go in as observations. The only thing he had to adjust was the state normalization, because otherwise the ±1 flag got drowned out by the millimetre values sitting next to it.

Robomates ended up doing pretty much the opposite. Their bartender has to pick one cup out of several, and teaching a 450M SmolVLA to choose based on a word would have meant a night of training with no guarantee it’d work. So they paint all the other cups out of the head camera image before the policy ever sees it. It takes three milliseconds a frame, and the policy gets the one-cup scene it was trained on. So one team added something to the image to show the policy where to look, and the other removed stuff so it couldn’t look anywhere else, without either of them knowing what the other was up to.

If you can’t get a small policy to pay attention to the right thing, it’s often easier to edit the image than the network.

On September 8th, Robomates’ policy went 0 for 14. Three days later it went 6 for 6. Identical training config. The only thing that changed was the data.

What had gone wrong: their original 40 demos covered the cup positions really unevenly, so the model never learned to look at anything. It learned timing instead, basically closing the gripper on a schedule and hoping for the best. They re-recorded 33 episodes to spread the positions out properly, and the exact same recipe suddenly worked.

Dataset sizes across the teams ranged from about 50 episodes to 500. How many you had mattered a lot less than whether they covered the space evenly.

Every system worked on the table it was trained on and fell apart anywhere else. A different coloured cup, a position slightly outside what was demoed, the table three centimetres higher, and a policy that had just gone six for six was useless.

The one partial exception is Zuper. Because his state vector is a relative offset rather than an absolute position, a breaker somewhere new looks to the policy a lot like one it’s already seen. So he got some generalisation across positions just by picking the right coordinate frame, without collecting more data. Or at least that was the plan. During the live demo on stage it still missed the breaker.

When people who do this for a living saw his system, their verdict was roughly: useful, but not trusted yet. It looks brutal, it misses too often, and in a real factory it would need to work 101% of the time. Getting from “works in a demo” to that is more or less what the whole field is working on right now.

Software broke all the time, obviously. But if you ask the teams what actually ate their summer, nobody’s going to bring up loss curves.

The SO-family of arms is known for being affordable, easy to use, fully open. But not for its reliability. Almost every team burned out motors. We replaced eight during the challenge. Several teams spent long nights recalibrating and ID:ing arms after a servo decided to stop cooperating, and we’re proud of them for sticking with it. The biggest source of weird failures was the USB-C power delivery from the power bank. It would cut out for a split second and crash whatever script was running, and for a few unlucky teams it took the Jetson down in the middle of data collection, losing many episodes (sorry Pavlo).

Robomates had the smart idea to run the arms off the Anker’s 12V car socket instead, which turned out to be much more reliable. USB-C power works by the power bank and the device first agreeing on a voltage, and every so often it decided to reopen the negotiations mid-teleoperation. The car socket was built for cigarette lighters and has never negotiated anything. Just hands you 12 volts without asking questions. That tip is probably more useful to the next batch of teams than anything else in this post.

The gripper servos also overheat if you run them continuously, so thermal guards became mandatory: a warning at 50°C and a hard stop at 60°C. This stuff everyone will need to write for themselves because it’s not included in the stock lerobot. And nobody ended up using the VR headsets. We are a bit sad about it because they cost a small fortune, but maybe we should have seen it coming. VR teleop made recorded trajectories shaky, and one team spent a whole week fiddling with Quest’s sensitivity settings before giving up. Everyone switched to leader arms, or turned a second follower arm into one.

On hardware, closer than you’d think. On methods, further than we’d like.

The LeHome Challenge at ICRA 2026 in Vienna is a good comparison of Lerobot SOTA. It ran on the SO-ARM101, the same arm family our teams had on their desks, and it was a garment manipulation competition in two phases: an online simulation round, then a real-world final on site. The top entry came first out of 62 teams online and second in the real-world final. It used a vision-language-action policy improved with a reinforcement learning loop: a frozen SigLIP encoder feeding a Gemma-2B prefix, with a Gemma-300M flow-matching action expert putting out 30-step action chunks.

Two things from their write-up stood out to us. The author had about three months for the simulation round and just over a week for sim-to-real, which they described as a hackathon-style sprint. So the same three months our teams had, just spent almost entirely in simulation. And the LeHome paper reports that co-training on simulation data plus ten real demos took average real-world success from about 15% to about 50%. None of our teams went anywhere near a simulator. Setting up a physics environment, matching it to your hardware and getting a policy to transfer is a whole project by itself, and twelve weeks with a robot on your desk doesn’t leave much time for that. But that’s probably where the next big jump in improvement was hiding, for anyone with the time or the guts to go for it.

It’s also worth knowing how low the numbers are even at that level. On the challenge’s hardest garment task, success rates were 25% for ACT, 20% for diffusion policy, 36% for SmolVLA and 14% for Pi0. Nobody has long-horizon manipulation of floppy things like clothes figured out yet.

Then there’s the actual frontier. Physical Intelligence released π0.7 in April 2026 and pitched it as a steerable generalist model with a step-change in generalization. They compared it against specialist models on things like making coffee, folding laundry and assembling boxes, and the generalist kept up with them. Autonomy on 10 minute long tasks. Completely different league. Still, the paper hedges a lot, talking about “early signs” of generalization and “initial demonstrations” of new capabilities, and when asked when a deployed system might follow, Levine didn’t want to guess. That’s from a company that has raised over $1 billion and was last valued at $5.6 billion.

So yes, there’s a big gap between a billion-dollar lab getting (cautiously) generalist behaviour and our teams getting a reliable grasp on one table. But that gap is about data, simulation and scale. It’s not really about access anymore. Everything our teams used is open: the arms, the datasets, the policy implementations, the training recipes, even the winning competition solutions with checkpoints included. In 2019 a student team couldn’t have gotten near any of this. Now the difference between a Helsinki summer project and an ICRA competition entry mostly comes down to who spent their summer in a simulator.