DUM-E和U

星期五，2021年1月22日 · 9分钟阅读

目录

• 灭火机器人
• 救生员
• 组装战衣
• 硬件模式
• 示例文件

DUM-E（“笨蛋”）和U（“你”）是《钢铁侠》电影中机器人手臂的名字。在看了第n遍这部电影后，我强烈渴望像托尼·斯塔克一样在车间里拥有机械臂。你可以在整部电影中清楚地看到这些机器人的价值。机器人让托尼能够更快地生产战衣，帮助测试战衣，并提供周期性的喜剧效果。在某一时刻，DUM-E甚至救了托尼的命。作为一个思维实验，我思考了在现实中实现相同功能需要什么。这最终导致了一个用于制造的配置管理系统，很像一个构建系统。本文将对此进行一些概述！

构建机器人最流行的开源框架是ROS（机器人操作系统）。你可以添加不同的组件，如摄像头或传感器，并为你的特定用例编程所有需要的功能。底层基础设施通过发布/订阅系统传递消息来工作。Elementary Robotics创建了自己的操作系统，称为atom。它非常酷，使用Redis作为消息层，使用docker进行打包和定义各个组件。需要机器人的摄像头？在你的atom OS配置文件中包含摄像头容器。然后，你可以将来自摄像头的消息传输到另一个容器中的机器学习中。了解这些框架的基础知识对于继续探讨如何构建DUM-E和U至关重要。

让我们深入探讨。这里的最终目标是像托尼·斯塔克一样高效地构建东西。

灭火机器人

我最喜欢的DUM-E场景之一是托尼测试战衣时，DUM-E的任务是在他着火时用灭火器喷他。为了电影中的喜剧效果，DUM-E搞砸了好几次，在托尼没着火的时候喷了他。

让我们分解一下，从一个会对任何火源喷射灭火器的机器人开始。首先，你需要一个机器人手臂底座，也许是你自己构建的，也许是ABB、Kuka、FANUC或任何其他机器人手臂制造商的产品。假设你有一个可以通过SDK/API编程的某种机器人手臂。你还需要一个灭火器。既然我们是黑客，我们就用胶带把它固定在机器人手臂上，并在开关上设置一个触发器，以便通过程序控制发射。接下来，我们需要一个摄像头。让我们也用胶带把这个和所有电线固定在机器人上。我们需要知道附近是否有东西着火以及它的位置。我们需要一些代码来判断是否有东西着火。你很可能可以训练一个机器学习模型来做这件事。所以，当ML模型识别出某物着火时，我们需要计算它与我们从摄像头识别到固定在机器人上的灭火器的距离关系。这些都是可行的，很大程度上取决于我们训练模型的效果。

在电影中，DUM-E在识别火源方面相当糟糕。这只是一部电影，但我们应该考虑到模型可能很难区分火源和未着火时战衣的颜色。如果你记得，钢铁侠的战衣是深红色和金色的，如果它以火可能移动的相同模式移动，可能会被误认为是火。托尼确实以非常快的速度飞行和移动。这实际上取决于托尼训练模型的效果。只要DUM-E持续学习（它应该这样），在钢铁侠被误喷几次之后，模型应该能够区分两者（着火和看起来像火但以奇怪方式移动的战衣）。我们在电影中也见证了这一学习过程。

救生员

DUM-E，尽管名字如此，却非常聪明。电影中的一个主要场景是，当托尼濒临死亡，反应堆刚好在他够不到的地方时，DUM-E意识到这一点并将反应堆递给他，从而救了托尼的命。这可以通过几种不同的方式编程。

一种方式相当于硬编码这种行为。也许托尼训练DUM-E把反应堆递给他。这有点蹩脚，并且在这种情境之外不太有用。我们假设DUM-E是以另一种方式编程的。

总体上更有用的是，如果DUM-E有一些编程，当托尼伸手去够一个刚好够不到的物体时，DUM-E应该知道递给他。这再次依赖于摄像头和一个非常精确的机器学习模型。不过，与灭火器不同，我们需要一个爪子来拾取物体并传递。这种行为的机器学习模型必须：

• 识别人类
• 识别处于休息状态的人类和伸手够物（手臂伸展）的人类之间的区别
• 识别人类正在伸手够的物体，扫描距离手末端一定距离的物体

我们还需要一些代码来知道物体何时超出范围，机器人应该帮忙，或者人类自己可以够到，不希望机器人手臂在我真正想抓东西时碍事。所以也许观察伸手的速率，并计算手臂是否可能延伸到其前进方向周围的任何物体。

这一切都应该是可能的。作为加分项，让我们让它更有用。托尼在他的车间里使用他的机器人帮助他建造东西，有时他让它们递给他工具。让我们给机器人添加一个麦克风组件和一个模型，以识别我何时在请求一个物体。现在机器人需要根据名称正确识别物体，并且希望它首先能正确解析我说的话。我们还可以帮助机器人识别物体，通过使用摄像头识别我在请求时是否指向了特定物体。这将非常有用，就像身边多了一双手臂。

组装战衣

DUM-E和U都帮助斯塔克组装钢铁侠战衣。要做到这一点，机器人需要知道战衣组装完成时的最终配置。它们还需要知道在托尼身体的哪个部位安装战衣。所以我们需要：

• 一个摄像头来识别托尼以及放置战衣部件的位置，我们还需要识别战衣的部件
• 我们需要一个带有工具的爪子来进行最终的焊接和战衣的组装

硬件模式

在建造了几套战衣之后，托尼的车间看起来不那么像是“我正在积极建造东西”的配置。你可以看到地板更干净，散落的工具和材料更少。基本上就像有人打扫过，东西已经静止了一段时间。当托尼需要建造反应堆来创造为战衣供能的元素时，他告诉机器人“我们要回到硬件模式了。”这让我思考，如果工厂车间布局有不同的配置，可以随意命名和切换，那不是很酷吗？我们该怎么做？

到目前为止，我们已经通过代码编程让所有机器人做我们想做的事。假设我们使用了ROS或Atom，我们会在某个代码库中有一些配置文件和代码。假设每个机器人一个代码库，或者每个机器人行为一个代码库，无论哪种方式，我们都有一个单一的地方定义决定机器人行为的代码。除此之外，我们还需要几样东西：

• 一个带有坐标的工厂车间程序化地图，这样我们可以将机器人分配到特定坐标，我们可以使用地理编码或其他方法，想象一下为你的Roomba提供动力的那种技术

• 每个机器人需要一个摄像头和一个跟踪机制，以知道在这个工作流程中它需要去到哪里到达其定义的坐标（如果它是固定的），如果不是，机器人可能已经有将某物从一个地方移动到另一个地方的任务，稍后详述

• 一个配置来指定：

  • 此步骤使用什么机器人或机器
  • 机器人或机器需要去哪里
  • 现在需要加载到机器人中用于其任务的代码，或者如果代码已经加载到机器人中，机器人需要知道为此配置执行什么代码 例如，这是用于分析物体以确保其达到质量的代码吗？这是传递物体的代码吗？它现在应该进入激光切割模式吗？
  • 机器人需要处理的任何工件

例如，假设在配置文件中，我们的第一步是一个桌面金属打印机打印某个stl文件。很像一个CI流水线，我们的工件将是完成的3D打印物体本身。 流水线中的下一个机器人可能是一个机械臂，被分配到打印机和装配线之间的坐标。文件中的下一个配置会知道它需要获取那个工件（因为我们会定义它）并将其传递给装配线。 然后配置文件的其余部分可以定义装配线。

所以现在我们可以为几种不同的装配过程准备配置文件。如果我们想开始建造不同的东西，我们只需加载新文件，机器人就会更新它们的代码。所以当托尼说“我们要回到硬件模式了”时，我们可以认为他是在告诉系统加载新文件。

示例文件

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

name: "hardware-mode"
steps:
machine: desktop-metal-1
  runs: |
    my-super-cool-stl-file.stl
  artifact: part-hook
machine: dum-e
	location: near-desktop-metal-1 # 或者可能是实际的代码坐标，如果有能翻译成这些坐标的快捷方式就好了
  runs: |
    part-hook | assembly-line # dum-e机器人需要执行的代码，或者可能指向存储代码的代码库

这种设置很酷的一点是，现在我们整个工厂都在代码中配置。我们可以通过回退一个提交来回滚，或者通过修改文件来添加更多功能。我们还免费获得了工厂设置的全部历史记录。可能CAD程序可以帮助生成这些文件。它相当于一个构建流水线，但是用于制造，我想它可以被认为是一个物理构建流水线。

总的来说，这是一个有趣的思维实验。我只能希望有一天能弄到几个机器人，并尝试拼凑一个真实的流水线。我确实认为变得和托尼·斯塔克一样高效是可能的，只需要资金和时间把这一切连接起来。当然，还需要有东西可建造！

© Jessie Frazelle 2022 @jessfraz