AI 中文社/资讯/详情

波士顿动力技术揭秘：后空翻、俯卧撑与翻车，6年经验、教训总结

2024-08-18 发布 · 浏览192次 · 点赞0次 · 收藏0次

为什么波士顿动力的人形机器人能完成跑酷、后空翻等高难度动作？为什么有时候它会翻车？工程师从中总结的经验、教训都在这里了。

今年 4 月，著名机器人公司波士顿动力跟全世界开了一个玩笑，先是官宣人形机器人 Atlas 退役，狠狠来了一波回忆杀。

^{退役的 Atlas。}

紧接着，就在第二天，他们又放出了一个新的人形机器人视频。新机器人也叫 Atlas，不过由原来的液压改为了电动，身材更为小巧、灵活。

此时，外界才反应过来，原来波士顿动力并不是要放弃人形机器人，而是转变了研发方向，让机器人更加适应工业环境。该公司表示，这个电动版的 Atlas 将于明年初在韩国现代汽车工厂里开始进行试点测试，并会在几年后全面投产。

自公布后，这个机器人鲜少露面。直到最近，在机器人顶会 RSS 的一场技术分享上，大家才知道，原来新的 Atlas 已经进化到可以做俯卧撑、倒立行走的地步了。

这个技术分享来自波士顿动力机器人工程师 Robin Deits。他是 MIT 博士，2018 年至今一直在波士顿动力工作，研究 Atlas 人形机器人的控制。

个人主页：http://robindeits.com

在分享中，他介绍了 Atlas 机器人过去几年的研发历程，以及从中学到的经验、教训，对机器人行业从业者可能很有启发。机器之心将在这篇文章中进行系统梳理。

^{视频链接：https://www.youtube.com/watch?v=aQi6QxMKxQM}

Atlas 控制器的核心 ——MPC

在演讲开头，Robin Deits 首先介绍了波士顿动力这家公司。

波士顿动力现在是韩国现代汽车公司旗下的人形机器人公司，员工大概有八九百人，其代表性的机器人有 Spot（机器狗）、Stretch（仓库搬运机器人）和 Atlas（人形机器人）。目前，Atlas 主要还是一个研发平台，波士顿动力正慢慢将其转化为产品。

接下来，Robin Deits 介绍了他们如何将 MPC 用于 Atlas，包括怎么用、遇到了哪些挑战、还有哪些问题没有解决等。

MPC 指的是 Model Predictive Control（模型预测控制），这是一种高级控制策略，通过使用数学模型来预测系统在未来一段时间内的行为，然后优化控制输入，以实现系统性能的最佳化。MPC 的一个关键优势是它能够处理多变量系统，并且可以显式地考虑约束条件（例如输入和状态的限制）。在机器人领域，MPC 通常用于路径规划、运动控制、姿态控制等任务中，因为它能在动态和复杂的环境下提供鲁棒的控制解决方案。

Robin Deits 表示，他们从 2019 年以来实现的所有机器人动作都是依靠 MPC 来完成的，包括跑酷、体操、跳舞、后空翻等等。最近，他们还展示了 MPC 用于操纵物体的效果。2024 款纯电驱动的 Atlas 新版本也是由 MPC 驱动的。

所有版本 Atlas 的 MPC 都有一些共同特点，包括：

1、非线性动力学、成本和约束

Deits 指出，所有 MPC 版本从一开始就包含非线性动力学，非线性无处不在，特别是接触点的位置与接触点施加力的大小之间的耦合。他们选择接受这一点：如果一切都是非线性的，他们不会找到一个完美的线性近似系统。

2、迭代线性化并求解 QP

他们通过迭代地线性化来解决这个问题。这包括从一个初始猜测开始，然后解决一个 QP（二次规划问题），围绕那个 QP 的解进行线性化。

3、从不运行到收敛

他们对收敛不感兴趣，因为 Deits 认为收敛并不能很好地预测机器人是否真的有效。如果机器人在等待过程中摔倒了，那么为了等待收敛到某个阈值而花费上百倍的时间并不值得。

4、利用问题结构提高速度

他们做了很多工作，利用问题结构来提高速度，尽可能保留由 MPC 问题结构带来的稀疏性。

5、不将求解器视为黑盒

他们尝试打开求解器，重写其内部，以提高性能，而不是简单地将求解器视为一个无法更改的黑盒。因为最终，他们需要尽可能快地解决最大的 MPC 问题。

自进入波士顿动力以来，Deits 所在的团队已经在机器人（硬件）上解决了大约 1000 万个 QP 问题，在模拟环境中则解决了 100 亿个。但这些还远远不够。

把机器人看成长了四肢的「土豆」

为了简化模型，他们首先把机器人想象成一个土豆。机器人存在诸多非线性因素，比如力的位置和大小之间的耦合，以及旋转动力学等。通过简化模型，专注于重心动力学，他们成功实现了 Atlas 机器人的 360 度旋转、后空翻等动作。

但是，归根结底，机器人不是土豆，它有可以移动的四肢，因此他们转向了分阶段优化：首先考虑土豆的重心动力学，然后在独立的运动学上做一些下游优化，以找到与「土豆」一致的运动学行为。这种方法效果很好，帮 Atlas 实现了单手支撑跳过平衡木的动作。在这一过程中，他们使用手和脚来操纵重心动力变化，但是以一种跟踪参考轨迹的方式移动四肢，使其清楚地避开平衡木。

但问题是，一旦「土豆」想做一些四肢做不到的事情（「土豆」以为能跳到那么远，而四肢其实不能），Atlas 就会贡献翻车片段。二者之间不够协调。

所以，从这时起，波士顿动力调整策略，开始将 Atlas 视为一个运动学 - 重心动力学耦合的系统（a Kinodynamic System）。这个系统可以让 Atlas 完成 540 度的转体空翻，这是以前的分阶段优化系统做不到的。

此时，他们也意识到，增加模型的复杂性似乎总能在某种程度上提升机器人的性能，尽管这确实会让计算过程变得更加复杂，软件也更加庞大。他们在 MPC 问题中加入的每一个正确元素，都有助于改善机器人的表现，但这同时也意味着需要更强大的计算能力和更精细的软件实现。他们尚未发现一个临界点。

为了让机器人能够操纵物体，他们采取了类似的耦合方法，将机器人和物体的状态放到一个 MPC 问题中去解决，因为二者的运动互相约束。这使得 Atlas 能够做到扔工具包、搬运木板、操纵较重物体等动作。

不过，这些动作都是在非常结构化的环境中完成的，波士顿动力需要考虑机器人实际所处的世界。这让问题变得更大、更难，引入了感知驱动的约束之类的东西。

他们采用像体素地图这样的世界表示，并将其作为 MPC 问题的额外约束。在一个例子中，他们让机器人慢跑，没有特别的参考动作，但是要求它保持头部在体素外面，结果可以看到，机器人知道遇到体素要低头。这仍然是一个局部优化，机器人不会特别聪明地决定如何绕过一棵树。但是 Deits 表示，依靠这些局部优化并看看能用它做到什么，效果出奇地好。在一个让机器人跑向盒子的例子中，它居然通过一个聪明的扭臀动作绕过了盒子。

但想要真正创造出一个用于执行任务的有用机器人，只让它在障碍物周围走动并做一些编程好的动作还远远不够。波士顿动力最近面临的一大挑战是如何将整个 MPC 系统应用到人类在线指定的某种任务上。

Deits 展示了他们遥控机器人进行操作的例子。在遥控过程中，他们获取操作者手部的动作，并将这些动作转换成 MPC 的参考轨迹。由于无法预知操作者将来想要做什么，他们必须采取一些策略，将他们手部的即时姿态转换成随时间变化的 MPC 参考轨迹。

同样的，他们还在尝试执行一些自主行为，比如让机器人注视一个固定点并向其移动。他们利用可能异步在线传入的传感器输入来构建 MPC 的参考，这意味着 MPC 必须能够非常灵活地适应参考轨迹在一瞬间完全改变的情况。

经验、教训总结

到目前为止，他们得到的有关模型「复杂性」的教训是：

更复杂的模型持续有效；
将重心动力学和完整的运动学结合在一个优化过程中，而不是分开处理，通常效果更好。这种方法可以避免当机器人作为一个整体（如土豆）尝试执行动作时四肢无法实现的问题；
不要丢失那些梯度。在将运动学和重心动力学优化分开时，他们没有办法告知机器人的主体部分四肢无法做到某些动作，因此那些梯度只能通过工程师的大脑间接地传递。而更有效的方式是让这些梯度成为实际的梯度，让求解器沿着这些梯度找到解决方案，而不是工程师自己去手动寻找。

Deits 还举了一个例子来说明「一起优化」的效果要好于分阶段优化。他们以很快的速度把一个篮球扔向机器人，机器人在平衡木上很难单脚保持平衡。但是，如果给机器人一根杆子，它就能利用那个杆子的动力学来保持平衡。波士顿动力也曾尝试用分阶段优化来做这件事，但结果都没有成功。只有把机器人的模型和与之交互的物体的模型放在一起优化，机器人才能在平衡木上保持平衡。

第二个教训是关于「非线性」方面的。他们发现，直接优化的非线性 MPC 可为非凸问题做出令人惊讶的正确决策，例如接触点的位置和力的非凸性问题。Deits 确信他们经常达到的是局部最小值，但这些结果通常已经足够好。他认为，在机器人出问题时，原因并不是他们未能解决特定的非凸问题，而是他们的模型在某些方面存在根本性错误，或者他们未能做出有用的决策，比如改变模式序列。

在这里，Deits 举了一个例子：他们用一个棍子用力推机器人，但没有告诉 MPC 该怎么应对，只是让它保持机器人直立（不要摔倒），然后给它一个左右踉跄的序列。它所有的位置和选择的力，包括所有的手臂、腿部动作都只是一个局部优化。

除了常规的保持直立，这个 MPC 系统还能支持一些非常规动作，比如做俯卧撑、倒立行走。

第三个教训是从「工程」角度来总结的。Deits 认为：

精心的工程设计是使 MPC 真正发挥作用的一大因素。把一个数学上合理的东西放入一个实际运行的机器人中，并让它运行 100 亿次 QP 求解，需要大量的工作。
软件性能很重要，如果你的答案给得太晚，那就没有用了。但软件正确性更重要，一个符号错误会导致系统失效，或效果很差。在没有找到 bug 之前，你很难区分问题出在数学上还是实现上，这会导致大家错失一些好点子。因为一个符号错误而放弃一个在数学上很合理的点子是非常可惜的。
机器人的表现是唯一的目标，其他都是次要的。比如，求解器的「收敛」是无关紧要的，机器人是否完成了后空翻才是关键。

第四个教训是关于「轨迹」的。Deits 发现，粗略的轨迹竟然可以成为良好的参考。他们把复杂的期望行为编码为关节、末端执行器、物体姿态的轨迹。这些轨迹可能不一致，甚至完全不切实际。但更复杂的 MPC 能够容忍这些不一致的参考。这意味着他们可以对所有动作运行相同的 MPC，而它却能处理这些看似不合理的参考轨迹，并产生实际可行的动作。

在这里，他发现了一个有用的指标：对于控制工程师来说，你的控制器越好，它能接受的参考就越差。按照这个标准，工程师们都会期望自己的 MPC 能够接受几乎无意义的参考，并产生物理上合理的东西。

尚未解决的问题

显然，使用轨迹作为 MPC 的参考可以带来很好的控制效果，但轨迹本身很难制作。因为，在为机器人的控制策略制定参考轨迹时，需要预测和定义一个考虑时间因素的成本函数。这个成本函数是 MPC 决策过程的关键部分，它影响着机器人如何根据当前状态和预期目标来规划其动作。

然而，一个主要的挑战是，机器人的期望行为可能不是静态的，而是根据机器人当前的行为和环境反馈动态变化的。这意味着，控制策略需要具备适应性，能够实时调整参考轨迹以适应不断变化的情况。比如在一个行走→到达→抓取→举起的序列中，如果你处在到达与抓取之间，MPC 的参考轨迹应该是什么？包括抓取吗？我们不知道是否应该包含抓取，直到我们知道我们是否真的到达了应该到达的位置。MPC 的成本函数应该包括动态变化吗？Deits 表示，对于这些问题，他们也还没搞清楚。