How Did Boston Dynamics Teach Atlas to Roller Skate?

How did Boston Dynamics get Atlas to roller skate?

Boston Dynamics removed Atlas's feet and attached off-the-shelf scooter wheels. The only new part they built was a single adapter connecting a scooter rim to the robot's ankle motor. They then treated each wheel as an ankle that never stops spinning and let the robot practice rolling in simulation millions of times. Nobody hand-programmed the skating. The robot learned it through trial and error, and the learned skills ran on the real machine, including a 360-degree spin that worked on the first real-world try.

What exactly did they change on the robot?

Very little, and that is the point. The team took the feet off Atlas and mounted wheels from a scooter. A scooter rim is a mass-produced, cheap part. The only thing they had to design was one adapter that bolts that rim to the motor at the robot's ankle.

Atlas is a humanoid robot. Its ankles are powered joints, and they normally tilt the foot to help the robot balance and walk. In this version, the ankle motor drives a wheel instead of tilting a foot. A small hardware change like this tells you where the real work happened: in the software that decides what the motors do.

Why treat a wheel as a "spinning ankle"?

A robot's control software works with a model of its own body: which joints exist, how they move, what limits they have. A wheel on a motor looks, to that model, a lot like an ankle joint. The difference is that a normal ankle rotates a limited amount and stops, while a wheel rotates indefinitely.

So instead of building a separate "wheeled robot" system, the team described each wheel as an ankle that keeps on spinning. That framing let the robot's existing way of thinking about its body apply to the new hardware. It is a good example of a broader pattern in engineering: when a new problem can be described in the terms of an old solved problem, you reuse more and build less.

How does the robot learn to roll in simulation?

The method is reinforcement learning, a way of training software by trial and error. The process works like this:

1. A virtual copy of the robot is placed in a physics simulator.
2. The software tries actions, such as pushing the wheels, leaning, or shifting its arms.
3. It gets a score for outcomes that match the goal (stay upright, move where commanded, follow a target motion) and a penalty for outcomes that don't (falling over).
4. Over millions of attempts, it adjusts toward behavior that scores well.

Simulation matters because a real robot is expensive and can break when it falls. A simulator lets you run huge numbers of attempts, far faster than a physical robot could. Nobody had to write rules like "when tilting forward by this much, push the wheel by that much." The robot discovered the balance and steering behavior itself.

The video coverage of this project doesn't detail the exact scoring setup or training time, so treat those as unknown. The broad approach is well established in robotics.

What was the motion-capture 360 spin?

For the spin, the team started with motion capture of a real person jumping. Motion capture records how a human body moves, giving the robot a reference to imitate. In the training setup, the robot is rewarded for reproducing that motion while staying balanced, now on wheels rather than human feet.

The notable result: the move worked on the real robot on the very first try. That matters because simulations are never perfect. Friction, motor response and small timing differences all vary between a virtual world and a real warehouse floor. This difficulty is called the sim-to-real gap. Crossing it on the first attempt suggests the simulation was a faithful enough stand-in for the real machine for this task.

Why did the robot steer instead of sliding its feet?

The side dashes are the most interesting detail. A person doing a quick sideways move would typically slide their feet. The robot, though, figured out that it should steer its wheels and roll through the move.

This shows what learning-based training does that scripted programming doesn't. The robot was given a goal, and it found a solution that suited its own body rather than copying a human one. Wheels are good at rolling and bad at sliding sideways in the way feet do, so the robot used what its hardware does well. That is the difference between imitating a motion and achieving an outcome.

Why put wheels on a humanoid at all?

The wheels weren't meant as a product. Per the coverage, they were a way to push the Atlas motors to their limits, because the motors spin fast under load the whole time. In normal walking, a motor works in bursts. With wheels, the ankle motors are working continuously at speed, which exposes how much the hardware and software can really handle.

It is also a demonstration that is easy to understand. Few people can judge a robot's torque curves, but everyone can see a humanoid doing a 360 on wheels. Andy Wu, the engineer behind the project, drives it around with a game controller. He reportedly said he hasn't touched his gaming rig since the project began.

What does this have to do with the Atlas going into factories?

What the team learned goes back into the standard Atlas, which still has feet. That is the version Hyundai wants to put into its car factories in 2028, according to the coverage. Boston Dynamics is owned by Hyundai, so the link is direct.

The practical takeaway: a stunt like roller skating is a cheap way to find out where the motors, the control software and the training method break down. Lessons about fast, loaded motors and about moving learned behavior from simulation to the real robot apply to a walking, lifting factory robot too. What this demo does not tell you is how well Atlas will perform on a real production line. Skating around a warehouse is not the same as doing repeatable work next to people.

What does this mean for you?

You probably aren't going to buy a skating robot. But this story shows how robot capability is being built, and that affects planning at work.

• If you work in operations, manufacturing or logistics: the shift to learned, simulation-trained behavior means robots may be adapted to new tasks with software and training, not only new hardware. Watch for pilot programs, and ask vendors how skills are trained and tested, not just what the robot can do in a demo.
• If you manage people or budgets: treat demos as evidence of a method, not a delivery date. The 2028 factory target is a stated plan, not a guarantee. Plan around pilots and see what survives contact with real conditions.
• If you're worried about your job: factory humanoids are still a future plan, and a demo of a robot on wheels says little about your role today. The useful move is to learn how your own workflow could be described as a goal with measurable outcomes, because that is how both robots and AI tools get trained.
• If you're just curious: the "spinning ankle" idea is a good lesson in problem solving. Reframe the new problem as a version of one you've already solved.

How could you track this kind of change at your own company?

Most teams that follow automation news end up with a messy spreadsheet of links, vendor notes and pilot ideas. A small internal tool can replace it. With Remy, you describe the app in plain English, for example a tracker where colleagues submit automation or robotics ideas, tag them by department, attach vendor notes and mark pilot status. Remy builds and deploys it as a full-stack app with sign-in and a database, so your team owns a simple shared system rather than another subscription.