# Atlas On a Roll — 官方原文

| 项 | 值 |
|---|---|
| 材料 | Boston Dynamics 官方博客 · Atlas On a Roll |
| 副标题 | Bridging Classical Motor Controls and Whole-Body RL |
| 作者 | Xiaoyu (Andy) Wu，Atlas 团队控制工程师 |
| 来源链接 | https://bostondynamics.com/blog/atlas-on-a-roll/ |
| 抓取日期 | 2026-11-10 |
| 性质 | 网页正文逐段抓取，英文原文一字不动 |
| 发布日期 | 官方页面未显示；第三方一致口径为 2026-11-09 |
| 备注 | 原文中 `“classical”‘` 的引号写法、段尾空格、图片说明保留原样，未校对修改 |

---

# Atlas On a Roll

Bridging Classical Motor Controls and Whole-Body RL

*This article was written by Xiaoyu (Andy) Wu, a Controls Engineer on the Atlas team. He has more than a decade of experience, at Boston Dynamics and before, controlling electric motors and the power electronics that drive them.*

What happens when you put wheels on a humanoid and let a learned controller drive it? We swapped the feet on our [Atlas® robot](https://bostondynamics.com/products/atlas/) to find out; it let us push our actuators, and our models of them, hard.

A wheeled Atlas isn’t a product. It’s a research testbed. From years of data on [customer experiences](https://bostondynamics.com/case-studies/) with Spot and Stretch, we know that robots in the real world often experience challenges we can’t fully recreate in the lab; we need to understand how our robots will react to extreme circumstances and to ensure reliability at the limits. As [Atlas’ other athletic feats](https://bostondynamics.com/blog/can-football-teach-a-robot-to-move/), we have to find ways to push the limits. The goal of this project was to see how faithfully a learned whole-body controller can work with real actuators, especially when they’re running at the edge of their performance envelopes. 

## Why Wheels?

We wanted a scenario where the motors had to deliver high torque and high speed continuously, carrying real load the whole time. Driving on wheels fits that perfectly: every launch, turn, and stop pushes the motors across their full torque-speed range.

The conversion itself turned out to be wonderfully simple. A single custom adapter mounts an off-the-shelf scooter rim onto our existing ankle actuator, and that’s the only new part in the whole build. Because Atlas was designed from the start to be produced at high volume and to be easy to service, the retrofit was about as involved as swapping a wheel on a bicycle.

The software side was just as straightforward. Each wheel is simply modeled as an “ankle” that can spin continuously, so all I had to do was take the baseline robot model and swap the feet out for wheels.

I’m still amazed at just how *easy* the whole process was.

Coming from a more “classical”‘ motor controls background, this was my first real dive into [reinforcement learning](https://bostondynamics.com/blog/training-a-humanoid-robot-for-hard-work/). It was a great opportunity to learn RL from people who do it every day. Beyond pushing the hardware to its limits, I wanted a control response that felt intuitive, responsive, and fun to drive.

### Connecting the Layers

On a robot like Atlas, actuator design, low-level motor control, and whole-body RL each have specialists who know their own layer deeply. This project let me work on the boundaries between those layers. If the simulation used for training assumes the motors are over-idealized, the policy can end up learning things the real hardware can’t actually do. If the simulated motors behave the way the real ones do, the policy learns moves that the robot can carry out for real, with confidence.

![A real Atlas robot mirrors a simulated robot learning the same behavior](https://bostondynamics.com/wp-content/uploads/2026/11/atlas-wheels-rl-split-screen-1024x576.jpg)

## Closing the Sim-to-Real Gap

A quick primer: Reinforcement learning works by running millions of simulations of the robot before it ever runs on the hardware. But for the training to be useful, the simulated robot needs to mirror the real-life hardware. Can we make the simulated motor behave enough like the real world one so that the simulation-trained policy transfers over to the physical robot? Closing that simulation-to-hardware gap, also called the sim2real gap, is the real challenge, and it’s why this project was an important learning platform.

A good share of that work was unglamorous but important: checking that the low-level control parameters matched across every software setup, running characterization experiments, and tuning the simulated motor model to match what we measured on the robot. Just as important was knowing which approximations were safe to make and which ones the policy would learn to exploit. The goal was for the policy to train against the same “plant” it would meet on the hardware.

Transitioning into RL meant adapting established policy frameworks rather than starting from scratch. A few targeted changes to the reward composition, the range of commands the policy trains on, and how it holds its posture were enough for smooth rolling to emerge on its own, while the robot stayed stable and easy to drive.

Working across these layers, I found that the robot’s limits usually lived in the space between them, in how the motors, the low-level control, and the training all play off one another. Getting to see that interplay up close, and exploring this rich design space, was my favorite part of the project.

## Behind the Moves

Some of the moves came from a library of human motion capture data. I deliberately looked for clips with a lot of foot sliding, since that seemed like exactly where wheels would make things interesting. And it was! Take the side dashes: where a person would slide their feet, the policy learned to steer the wheels and roll through it.

The 360-degree jump was actually low-risk, despite looking like a high-energy feat. It’s a trajectory-tracking policy that follows a recording of a person doing the jump, and it worked on the first try. What was interesting was how differently it used traction compared with Atlas on feet. During the “windup” right before the jump, for example, the lower body quickly rolled into place to get ready for the upward push.

It was fascinating to see these little tricks emerge on their own. Give the policy wheels, and it figures out how to use them.

## What Comes Next

Looking back, the best part of this project for me was seeing how much understanding the motors can speed up RL policy design. Building a testbed this fun to drive showed that accurate motor models and high-level learning work best together, and that each one makes the other better.

These insights are already being adapted back to our standard configuration. By maintaining tight integration between actuator dynamics and whole-body RL, we continue to push hardware limits, enhance policy robustness against failure modes, and expand the capability envelope of Atlas.

*Before Atlas rolled across a real floor, it rolled across millions of simulated ones. Thanks to everyone who made this project possible: to Josh Geating for the wheel adapter; to Robin Deits, Shane Rozen-Levy, and Roberto Shu for the RL stack this work was built on; to our technicians, Mark Loughlin and Peter Jardin, for bolting wheels onto Atlas*; *and to Yuval Tassa and the MuJoCo team at Google DeepMind for the open-sourced physics engine*.