另一个F词:机器人开发者如何通过接受失败来做得更好

现代机器人非常棒，但它们也因陷入危险境地而臭名昭著。有时，这很滑稽，有时，这是灾难性的。人们曾看到机器人驶入池塘、卡在垃圾桶旁边、滚进零售店试衣间或突然起火。有些人可能会认为机器人不能工作，但现实更微妙:机器人在大多数时候工作得很好——直到它们不能。

传统的机器人被设计成连续完成单一的主要任务，比如在汽车厂焊接一辆汽车。这些机器人在为它们量身打造的受控环境中工作得最好，就像在装配线上的笼子里工作一样。在这种情况下，它们是非常可靠的。

它们的成功推动了制造业的自动化，但从历史上看，它们限制了其他行业采用机器人。现在这种情况正在改变自治机器人试图在非结构化环境中处理更复杂的任务。无论这项任务多么狭窄或简单，如今在机器人领域工作的任何人都知道自主机器人失败的故事。但这并不像听起来那么糟糕。

当自主移动机器人没有那么自主时年代

现实世界是混乱和混乱的，人类的活动不可预测，环境不断变化。一种新型的自主移动机器人(amr)被专门设计出来，利用传感器和人工智能对环境做出反应，但即使是最好的机器人也会经常失去自主能力。一些简单的事情，比如反射表面产生的眩光干扰了传感器，或者直接的人为干扰，比如撞到机器人，都可能导致最强大的AMR定位错误，中止给定的任务或停止，直到人类帮助到来。这种机器人发现自己在其操作参数之外而失败的不幸情况被称为"自治例外”。

新兴的机器人市场在生产力、灵活性和效率方面要求很高。因此，机器人制造商正在将机器人的能力推向极限——甚至超越极限。随着制造商着手处理更多的基本操作功能，实现“完美自动驾驶”所需的努力呈指数级增长，这导致了一种新型汽车自治的差距。

这一差距导致正在部署自动化解决方案的公司面临运营挑战。随着自动化从试点阶段发展到大规模部署，自动化异常的影响呈指数级增长。一个公司在处理5个机器人时必须解决的问题，与处理500或5000个机器人时面临的挑战截然不同。

缩小自主性差距

未来几代人在回首往事时，可能会把这些机器人的失败视为标志着机器人技术进步的历史记录，就像我们在黑白电影中看到人们试图制造飞行机器的报道一样。一个有效的机器人操作(或RobOps)的基础可以确保进展的继续。扩展业务首先要接受这样一个事实:自主操作的例外是不可避免的，机器人将会失败。

这是一种很好的失败。迭代过程的本质要求失败才能实现增长。在机器人领域，了解故障的生命周期可以让公司定义具体的操作步骤来解决异常，并最终减少这些事件的发生。

当考虑多个机器人的编排时，这一挑战是复杂的，它们来自不同的供应商，执行不同的任务。这就产生了复杂的互操作性挑战，并需要与各种业务线软件集成。

鲁棒RobOps从可观察性开始。可观察性不仅指运行状况监视，还指数据、日志和度量，它们是理解问题发生及其来源所必需的。机器人舰队应该被认为是真正的分布式系统，每个机器人都是独立的，但也是整体的一部分，就像一个由数千台主机服务器组成的数据中心一样。

大规模缓解问题需要一个可靠的配置管理(CM)解决方案。由于无法在整个团队中部署可审计的变更和更新(包括支持回滚和最终一致性)，机器人开发人员只能依赖于沉重的质量保证和软件分发流程，从而限制了频繁发布更新以响应代码离开实验室时可能出现的问题的能力。

如果失败不能带来学习和成长，它就毫无价值。有什么比有效地发现和解决问题更好的呢?一开始就避开他们。预防与安全、安全与审计相辅相成。由于自主机器人仍然是一个新兴领域，确保在广泛情况下的安全操作对建立信任至关重要。机器人的最终目标是增强人类的自主能力，使机器人和谐地融入人类的生活和工作中

《机器人:新希望》(RobOps: A New Hope

就在DevOps社区聚在一起的时候安德鲁·克莱和帕特里克·德布瓦在2008年然后慢慢扩散DevOpsDays活动于2009年在比利时举行在美国，RobOps社区开始联合起来。作为非营利组织的一部分，大规模运行机器人的专家每月开会进行虚拟讨论机器人操作组(ROG)来定义最佳实践，例如最近发布的开源宣言这就是本文的框架。

其他组织像MassRobotics此外，欧洲的一个汽车制造商协会也发布了一些早期的互操作性标准。最后，一些初创公司正在开发一种新型的RobOps工具，旨在解决自动驾驶的例外情况，并简化车队管理。

标准、工具和最佳实践将把DevOps和云的可扩展性带给自主机器人世界。本文描述的故障生命周期方法建立在自身的基础上，以创建一个灵活的、自愈的系统，可以随着机器人舰队的增长而适应和进化。随着智能机器人的新应用每天都在出现，各种规模的公司高管对自动化的兴趣也在增加，这是参与下一波劳动力数字化浪潮的绝佳时机。

*这篇文章最初发表于Forbes.com