Google Built Robots A Practice Room

Google put out a demo of a robot opening a trash bin. That's fun to watch, a little sci-fi even. But the interesting part happens before the lid moves. The robot gets somewhere to practice first.

That sounds ordinary until you think about how physical skills get learned. You try something, you get a result, you adjust, and you try again. Now give a machine a practice space you can rebuild in software. At that point you're going after one of the biggest problems in robotics. Where does all the useful experience come from?

In its October 13, 2026 post, Google described Gemini 4 Argon building a MuJoCo foot-pedal bin simulation. It says Boston Dynamics' Spot practiced three-leg balance there, then pressed the physical pedal and dropped a can inside. That's the sequence worth understanding: observe a problem, build a place to rehearse it, then try it in the world. This is a Google demonstration, not an independently replicated result.

The visible action is small. The opportunity is bigger, because it makes learning the next action less dependent on somebody hand-building every part of the lesson.

The words skip the work

When you tell someone to throw a can away, you don't describe the lid, the pedal, where to put their feet, or when to let go. You give the goal, because they bring years of physical experience to it. A robot needs those missing steps turned into actions its body can actually carry out.

Knowing what a bin is and getting something into it are connected problems. They aren't the same problem. The second one forces every assumption to meet the floor, the lid, and the robot's own weight. So you can't judge a robot's intelligence only by how well it explains a task.

Ask an assistant how to make a bed and you'll get a sensible answer. Straighten the sheet, pull up the cover, arrange the pillows. But a useful machine has to find the sheet under the cover, keep hold of the right corner, and notice when pulling one side dragged the other side off. The words skip over the work. A physical learner needs experience of the work itself, including moves that look reasonable and fail.

A childhood you can copy

Robot learning has worked on that connection for years. Google's earlier RT-2 research combined knowledge from images and language with robot demonstrations to produce actions. That matters because general knowledge helps a machine understand an unfamiliar request, while physical examples teach it how to act on that request. A system that knows what a mug is still needs a way to pick it up, turn it, and set it down without losing control.

The way I think about it, the robot needs a childhood. But nobody wants to give every robot its own separate 20-year childhood. We want the useful parts of learning, meaning practice, feedback, recovery and improvement. Then we want to share what one machine learned with the whole fleet.

That's the part that excites me, because the effort you put into one lesson can keep paying you back.

What a practice room needs

Start with the practice space. Google's example used MuJoCo, physics software that models moving bodies and the forces between them. Its job is to calculate how parts move, push and collide.

For the bin, a useful practice world needs more than something shaped like a lid. It needs a relationship between pressure on the pedal and movement of the lid. Without that, the robot rehearses against a picture of the problem instead of its mechanics.

Say you're teaching a machine to move boxes into a cupboard. In a physical practice area, somebody has to supply the boxes, put them in position, and reset the scene after every attempt. If the machine drops one, the next attempt starts with picking it back up. In simulation, resetting can be a software operation. You change where the box starts and try a different approach. So more training effort goes into actual attempts instead of resets.

The reality gap

But useful attempts have to teach the right lesson. If the simulated box slides more easily than the real one, a motion that works in practice can fail at the actual cupboard. Researchers call that difference the reality gap.

One established answer is to vary the simulated conditions during training, so the learner has to cope with a range of possibilities. Research on dynamics randomization showed that principle with a robot arm pushing an object. Don't teach a machine that the world will always behave exactly like its first practice room.

For the cupboard, the lesson should survive changes that leave the job intact. The box might start a little further left. Its contents might make it heavier. The way in might need a different angle. You want the machine to connect what it sees with an action that works, instead of replaying the same motion no matter what's in front of it.

That's how I look at the data problem. A huge pile of videos doesn't automatically give a robot the experience it needs to do something useful. You can watch somebody make a bed a thousand times and still fumble it the first time you try. I want the learning process to capture the failures too, especially the ones that teach you what to do differently. That's where practice turns into skill.

Scoring the right thing

Now give that practice a way to judge progress. In reinforcement learning, a system chooses actions and learns from feedback about the results. The reward is the signal that separates better behavior from worse behavior.

For a simple job, the check might ask whether the object reached the right place. A better check also cares how it got there. Knocking everything else onto the floor shouldn't become a winning strategy for clearing one shelf.

This is where the person defining the job still matters. Ask a robot to tidy a room and score it only on how little shows up on the floor, and it could pass that badly designed test by shoving everything out of sight. What you wanted was toys in their box, clothes where they belong and fragile things left in one piece. Those distinctions have to reach the learning process somehow. A useful robot learns to complete your assignment. A useless one finds a shortcut through a sloppy description of it.

Recovery is part of the skill

Reaching the end once is different from knowing how to recover along the way. Say the robot grabs the wrong corner of the sheet. A rigid sequence keeps pulling because that was the next instruction. A more capable system notices the mismatch and changes what it does. In a real home, somebody may have moved the pillow, folded the cover differently or left a jumper on the bed. The value comes from finishing the same job across those ordinary changes with less need for a person to step in.

Telling a robot to move its hand to a coordinate is one thing. Telling it to put the washing away takes a chain of decisions that depend on earlier results. Did it pick up one item or two? Is the drawer open? Is there room inside? The machine has to hold the job together while the physical situation shifts underneath it.

The test I'd care about

My test is very ordinary. Say clean up the mess, and the robot goes through the whole house and handles it. Toys picked up, kitchen cleaned, stuff back where it belongs. I think that's a far better way to judge this technology than asking whether a robot can pull off one wild-looking move. Can it carry a job all the way through? Can you stop managing every step and go do something else?

That job gives the learning problem a clear shape. The robot has to recognize objects, decide what goes where, handle them and check the result. A toy that disappears behind a chair creates an observation problem. A soft item that changes shape creates a handling problem. A full storage box creates a decision problem. That's a reason to make practice richer, because a tidy demo space can hide the exact situations that turn a helpful machine into one more thing its owner has to babysit.

And supervision changes the math. Spend half an hour standing next to a robot while it does a job you could finish yourself, and your attention is still tied up even though its hands do the work. Hand it the job, check at the end, find it done, and that time is actually yours again. The unit of value is the completed job, counting the human attention it took.

Brain and body have to match

That's also why the robot's brain is more than a model name. It has to interpret what's happening, remember the assignment and pick the next action in time for the body to use it. So the chips, memory and model all matter. A machine that loses track halfway through creates work for its owner.

Say the robot starts with cups on the table, carries one to the kitchen and comes back. It has to hold onto the goal while updating what's left. If someone moved another cup in the meantime, the newest observation should change the plan. You want continuity about the goal and flexibility about the next step.

The body has to keep up too. Give the cupboard robot a gripper that can't reliably hold the box, and better planning won't finish the job. Give it a good gripper and a poor sense of where the shelf is, and you get the opposite problem. That's why practicing with a model of the actual body matters. The learner picks actions through the hands, joints and reach it really has, instead of some fantasy machine that can do anything.

Copying Michael Jordan

Think about Michael Jordan. Suppose you could copy everything he learned about basketball into your own brain. You still wouldn't play like him, because your strength, joints and coordination still matter. Robots get around that, because we can build matching bodies and distribute the software. That's what I mean when I say one robot learning can benefit the others. Develop a useful skill once and you have a route to putting it into more machines.

Sharing knowledge across machines is already an active research direction. Google's Open X-Embodiment work pulled demonstrations from different robots and studied models trained across them. So experience can be pooled instead of staying locked inside one machine's training history. Different bodies still bring different control problems, though. A short arm and a long arm don't reach the same spot with the same joint movement, so a shared lesson still has to be translated into an action that fits the receiving machine.

For a future household fleet, I'd think of it as a reusable lesson rather than a magic download. In that hypothetical, one team finds a better way to handle an awkward box, tests the change, checks that other jobs still work, and ships the improvement to compatible machines. Owners get the benefit without teaching that movement themselves. The cost of discovering a better method gets spread across every use of it. But the lesson is only worth sharing if it survives the move into a real task.

Count finished jobs

So what should you measure? How many virtual attempts ran matters less than whether the next version does the job better. Does it recover after a bad grasp? Does it finish without leaving a new mess? A fair comparison gives two software versions the same kinds of clutter, the same storage space and the same chance to recover. Then you count completed jobs and human interventions instead of picking the nicest moment from each run. That tells a developer whether a change improved the whole job or just made one movement look smoother while breaking something else.

56% to 75%

Google separately reported a tabletop VLA experiment, not the Spot task. It says 4,500+ simulated training episodes helped raise physical-robot success from 56% to 75%. That's 19 percentage points, about 34% relative to baseline. Google does not give the physical evaluation trial count; 4,500+ is the training count, not that denominator. This company result does not establish a gain across robotics generally. For me, what matters is whether practice improves the physical job.

The cost of the next skill

The same logic makes the practice scene itself valuable. Keep the cupboard and robot, change the object and its starting position, and a developer can ask a specific question. Did the new approach handle the unfamiliar shape better? Say the virtual robot lifts the box cleanly but the real gripper lets it slip. Now you have a focused question about contact. The failed physical attempt improves the practice world, and the improved practice world helps you pick what to test next.

That's why this turns into a question about the cost of learning the next skill. You've already built a model of the body, a way to describe the task and a process for checking the result. The more of that you keep, the less you rebuild for the next assignment.

So when I look at this demo, the trash can is the least interesting part. The progress is in teaching a machine to do work. Give it a useful way to practice, feedback that means something and a body that can execute what it learns. Keep tightening that connection, and the question becomes how much everyday work we can hand over. What I want is a robot that leaves the house tidier and gives people their time back.