从钢铁侠机器人到制造配置管理系统

DUM-E和U

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

DUM-E（“笨蛋”）和U（“你”）是《钢铁侠》电影中机械臂的名字。在看了无数遍这部电影后，我强烈渴望像托尼·斯塔克一样在工作室里拥有机械臂。在整部电影中，你可以清楚地看到这些机器人的价值。它们让托尼能更快地制造战衣，帮助测试战衣，并提供周期性的喜剧效果。在某个时刻，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应该知道递给他。这再次依赖于摄像头和一个非常精确的机器学习模型。不过，与灭火器不同，我们需要一个爪子来拾取物体并传递它。这种行为的机器学习模型必须：

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

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

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

组装战衣

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程序可以帮助生成这些文件。它相当于一个构建流水线，但是用于制造，我想它可以被认为是一个物理构建流水线。

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