机器人操作系统二 ROS2:设计、架构和野外使用 - 机器翻译

SCIENCE ROBOTICS | REVIEW

ROBOTS AND SOCIETY

Robot Operating System 2: Design, architecture, and uses in the wild

作者:史蒂文· 马琴斯基 塔利 富特 布赖恩· 格基克里斯· 拉兰塞特 和 威廉· 伍德尔

原文链接:www.science.org/doi/10.1126/scirobotics.abm6074


摘要

随着机器人在广泛的商业用例中的部署,机器人革命的下一章正在顺利进行。即使在无数的应用程序和环境中,也存在机器人共享的通用组件词汇表——需要模块化、可扩展和可靠的架构;传感;规划; 流动性;和自治。机器人操作系统 (ROS) 是上一章不可或缺的一部分,它通过免费提供的组件和模块化框架明显加快了机器人研究。然而,ROS 1 并没有设计许多必要的生产级功能和算法。ROS 2 及其相关项目已从头开始重新设计,以应对现代机器人系统在各个规模的新探索领域提出的挑战。在这篇评论中,我们重点介绍了 ROS 2 的哲学和架构变化,为机器人革命的这一新篇章提供了动力。我们还通过案例研究展示了 ROS 2 及其采用对加速真实机器人系统在各种具有挑战性的环境中可靠部署的影响。

简介

已经提出了许多软件平台,有时称为中间件,它们引入了模块化和适应性强的特性,使构建机器人系统变得更加容易。随着时间的推移,一些中间件已经发展成为包含实用程序、算法和示例应用程序的丰富生态系统。很少有人能与机器人操作系统 (ROS 1) 相媲美,因为它对成熟的机器人行业具有重要意义。
ROS 1 由机器人孵化器 Willow Garage ( 1 ) 推广。尽一切努力创建一个高质量和高性能的系统,但没有优先考虑安全性、网络拓扑和系统正常运行时间。无论如何,ROS 1 在几乎所有智能机器领域都具有影响力。它的商业崛起是提供自主导航、模拟、可视化、控制等旗舰项目的结果(2 - 4)。随着商业机会转化为产品,ROS 作为研究平台的基础开始显示其局限性。非传统环境中的安全性、可靠性以及对大型嵌入式系统的支持对于推动行业向前发展至关重要。此外,许多公司正在 ROS 1 的顶部或内部构建变通方法,以创建可靠的应用程序 ( 5 )。
第二代机器人操作系统 ROS 2 从头开始​​重新设计,以应对这些挑战,同时建立其社区驱动能力的成功 ( 6 )。ROS 2 基于数据分发服务 (DDS),这是一种用于通信的开放标准,用于军事、航天器和金融系统等关键基础设施 ( 7)。它解决了构建可靠机器人系统的许多问题。DDS 使 ROS 2 能够获得一流的安全性、嵌入式和实时支持、多机器人通信以及在非理想网络环境中的操作。DDS 是在考虑了其他通信技术后选择的,例如 ZeroMQ 和 RabbitMQ,因为它具有广泛的特性,包括用户数据报协议 (UDP) 传输、分布式发现和内置安全标准 ( 8 )。
在本次评测中,我们将确定 ROS 2 最先进的现代机器人系统适用性,并展示推动其成功的技术和哲学变革。然后,我们将在此基础上进行扩展,以展示 ROS 2 如何影响自治系统在几个独特领域的部署。五个案例研究探讨了 ROS 2 如何使机器人能够或加速机器人进入陆地、海洋、空中甚至太空的野外。


相关工作

机器人软件的历史悠久而传奇,可以追溯到 50 多年前的 Shakey ( 9 ) 等机器人。随着时间的推移,关于如何构建经典规划器、并发行为和三层架构(10 - 12)的文章已经很多。一个早期的例子是任务控制架构(TCA),它被用来控制各种机器人。例如,卡内基梅隆机器人导航工具包 (CARMEN) 建立在 TCA 的称为 IPC(进程间通信)的消息传递系统(13、14)之上。消息传递在分布式系统中有其丰富的历史:来自 IBM 的消息队列、Java 的 Jini 以及 MQ 遥测传输 (MQTT) 等中间件 ( 15 –17 ).
机器人框架提供了将复杂软件分解成更小、更易于管理的部分的架构方法。其中一些组件可以在其他系统中找到重用,并且可以建立到库中以供用户使用。管理这种复杂性的早期尝试是通过 Player ( 18 ) 中的客户端/服务器方法。玩家服务器与机器人硬件通信并运行执行其任务所需的算法。客户端可以连接到服务器以提取数据并通过传输控制协议 (TCP) 连接控制机器人。然而,它的架构阻碍了可靠性、代码重用和更换组件的能力。
另一个机器人平台 (YARP) 有助于构建以对等方式组织的控制系统,通过多种协议进行通信 ( 19 )。它通过在保持高性能的同时促进代码重用和模块化来促进研究开发和协作。YARP 可用于任何应用程序,但其社区专注于类人机器人和腿式机器人,例如 iCub 和麻省理工学院的 Cheetah,并且仅支持 C++。
轻量级通信和编组 (LCM) 是一种中间件,它使用具有多种语言绑定的发布/订阅模型。它专注于在高带宽低延迟环境中处理消息传递和数据编组 ( 20 )。这限制了 LCM 可以有效使用的机器人应用范围。Open Robot Control Software (OROCOS) 是一组用于机器人控制的库,专注于实时控制系统和相关主题,例如计算运动链和贝叶斯滤波 ( 21)。该项目已经发展成为一个完整的框架,集成了通用对象请求代理架构 (CORBA) 中间件和用于实时应用程序中确定性计算的工具。LCM 和 OROCOS 框架各自专注于整个系统的较小部分,将整个机器人问题的重要部分留给最终用户。
ROS 1 包含一组在构建多种机器人时很有用的库 ( 1 )。有用于监控流程、内省通信、接收时间序列转换等的实用程序。ROS 1 还拥有一个由社区贡献提供的由传感器、控制和算法包组成的大型生态系统,使一个小团队能够构建复杂的机器人应用程序。尽管 ROS 1 解决了机器人技术固有的许多复杂性问题,但它难以通过有损链路(如 WiFi 或卫星链路)持续交付数据,存在单点故障,并且没有任何内置的安全机制。表1 列出了 ROS 1 和 ROS 2 之间的主要区别。

类别 (左)~ ROS1 (中) ~ ROS2 (右):

表 1 ROS 1 与 ROS 2 相比的功能总结 

ROS 1 社区试图解决其中一些问题,但几乎在所有情况下,由于架构和工程限制,都做出了妥协。例如,为了解决单点故障(“rosmaster”),需要使用定制的解决方案单独修补所有现有的客户端库。在其他情况下,可以通过 SROS 项目扩展 ROS 1 的安全性。虽然成功,但很难维护,需要进一步开发以满足安全趋势。这些只是修补 ROS 1 的众多尝试中的两个,它延长了它的使用寿命,但并没有解决它的核心限制。


ROS2

ROS 2 是用于开发机器人应用程序的软件平台,也称为机器人软件开发工具包 (SDK)。重要的是,ROS 2 是开源的,并根据 Apache 2.0 许可证分发,该许可证授予用户修改、应用和重新分发软件的广泛权利,没有义务回馈 ( 22 )。ROS 2 依赖于一个联合生态系统,鼓励贡献者创建和发布他们自己的软件。大多数附加软件包也使用 Apache 2.0 许可或类似许可。让代码免费是推动大规模采用的基础——它允许用户利用 ROS 2 而不会限制他们使用或分发应用程序的方式。

范围

ROS 2 支持广泛的机器人应用,从教育和研究到产品开发和部署。它包含大量相互关联的软件组件,通常用于开发机器人应用程序。软件生态系统分为三类:
1) 中间件:被称为管道,ROS 2 中间件包含组件之间的通信,从网络应用程序接口 (API) 到消息解析器。
2) 算法:ROS 2 提供了许多在构建机器人应用程序时常用的算法,例如感知、同步定位和映射 (SLAM)、规划等。
3) 开发工具:ROS 2 包括一套用于配置、启动、自省、可视化、调试、模拟和日志记录的命令行和图形工具。还有一整套用于源代码管理、构建过程和分发的工具。
在本节中,我们将探讨第一个类别,即中间件,它是 ROS 2 的基础。

设计
设计原则
ROS 2 的设计以一套原则和一套具体要求为指导。主张以下原则:
分布式
与类似的复杂领域一样,机器人技术中的问题最好用分布式系统方法来解决(23)。需求被分成功能独立的组件,例如硬件的设备驱动程序、感知系统、控制系统、执行器等。在运行时,这些组件有自己的执行上下文并通过显式通信共享数据。这种组合应该以分散和安全的方式进行。
抽象
为了管理通信,必须建立接口规范。这些消息定义了交换数据​​的语义。有利的抽象平衡了暴露组件细节的好处与将应用程序的其余部分过度拟合到该组件的成本,从而难以替代替代方案。这种方法导致从硬件或软件组件的特定供应商中抽象出来的可互操作组件的生态系统 ( 24 )。
异步
定义的消息在组件之间异步通信,创建基于事件的系统(25)。使用这种方法,应用程序可以跨多个时域工作,这些时域由物理设备与大量软件组件组合而成,每个软件组件可能有自己的频率来提供数据、接受命令或信号事件。

模块化
“让每个程序做好一件事”的 UNIX 设计目标得到了反映(26)。模块化在多个级别实施,包括库 API、消息定义、命令行工具,甚至软件生态系统本身。生态系统被组织成大量联合包,而不是单个代码库。
我们不会假装这些设计原则是通用的并且没有权衡取舍。异步也会使确定性执行变得更加困难。对于任何单一的、定义明确的问题,都可以构建一个计算效率更高的专用整体解决方案,因为它不涉及抽象或分布式通信。
然而,经过十年的 ROS 1 项目经验,我们声称坚持这些原则通常会带来更好的结果。这种方法促进了代码重用、软件测试、故障隔离、跨学科项目团队内的协作以及全球范围内的合作。

设计要求
ROS 2 旨在满足基于机器人开发人员的设计原则和需求的某些要求。
安全
任何与网络交互的软件都必须包含确保交互免受意外和恶意滥用的功能。ROS 2 的集成安全系统包括身份验证、加密和访问控制 ( 27 – 29 )。设计人员可以通过访问控制策略来配置 ROS 2 以满足他们的需求,这些策略定义了谁可以就什么进行通信 ( 30 )。
嵌入式系统
作为一般规则,机器人包括传感器、执行器和其他外围设备。这些设备可能相对复杂,包含需要与运行 ROS 2 的 CPU 通信的微控制器。完整的 ROS 2 堆栈预计不会在小型嵌入式设备上运行,尽管 ROS 2 应该促进和标准化 CPU 和微控制器的集成。Micro-ROS 允许 ROS 2 在嵌入式系统上重用 ( 31 )。
多样化的网络
机器人用于各种网络环境,从装配线上机器人手臂的有线 LAN 到行星漫游车的多跳卫星连接。此外,机器人通常会使用内部网络来连接 CPU 内部和跨 CPU 的进程。ROS 2提供配置数据如何通过系统流动的服务质量,从而适应网络( 32 )的约束。
实时计算
从类人机器人到自动驾驶汽车,机器人应用程序通常包括实时计算要求。为了满足安全和/或性能目标,系统的某些部分必须在确定的时间内执行。ROS 2为实时系统的开发人员提供 API,以强制执行特定于应用程序的约束(33、34)。
产品准备就绪
当机器人走出实验室进入商业用途时,就会引入新的限制条件。ROS 2 旨在满足跨越设计、开发和项目治理的产品需求。这些努力的一个客观结果是 Apex.AI 对其基于 ROS 2 的自动驾驶汽车软件 ( 35 )的功能安全 [国际标准化组织 (ISO) 26262] 认证。这使得 ROS 2 可以在自动驾驶汽车和重型机械等安全关键系统中运行。


通信模式
ROS 2 API 提供对通信模式的访问。这些特别是在节点概念下组织的主题、服务和行动。ROS 2 还为参数、定时器、启动和其他可用于设计机器人系统的辅助工具提供 API。
主题
用户将与之交互的最常见模式是主题,它是一个异步消息传递框架。这类似于其他异步框架,例如 ASIO ( 36 )。ROS 2 提供了相同的发布-订阅功能,但侧重于使用异步消息传递来组织使用强类型接口的系统。它通过在节点的概念下组织计算图中的端点来实现。节点是允许用户推理复杂系统的重要组织单元,如图1所示。

图 1 ROS 2 节点接口:主题、服务和操作。 

匿名发布订阅架构允许多对多通信,有利于系统自省。开发人员可以通过创建对该主题的订阅而不进行任何更改来观察该主题上传递的任何消息。

服务
异步通信并不总是正确的工具。ROS 2 还提供了一种请求-响应样式模式,称为服务。请求-响应通信在请求和响应对之间提供了简单的数据关联,这在确保任务完成或接收时很有用,如图1 所示。独特的是,ROS 2 允许服务客户端的进程在调用期间不被阻塞。服务也被组织在一个用于组织和自省的节点下,允许子系统的接口一起出现在系统诊断中。
行动
ROS 2 独特的通信模式是行动。行动是面向目标的异步通信接口,具有请求、响应、定期反馈和被取消的能力(图 1)。这种模式用于长时间运行的任务,例如自主导航或操作,尽管它有多种用途。与服务类似,动作是非阻塞的,并且组织在节点下。 


中间件架构
秉承之前的设计理念,ROS 2 的架构由分布在许多解耦包中的几个重要抽象层组成。这些抽象层使得为所需功能提供多种解决方案成为可能,例如,多个中间件或记录器。此外,跨多个软件包的分发允许用户更换组件或仅获取他们需要的系统部分,这对于认证可能很重要。
抽象层
图 2显示了 ROS 2 中的抽象层。它们在开发过程中通常隐藏在客户端库后面,开发人员只需要了解它们即可满足特殊应用程序的特殊需求。大多数用户只会体验客户端库。

图 2 ROS 2 客户端库 API 堆栈

客户端库提供对核心通信 API 的访问。它们是针对每种编程语言量身定制的,以使它们更加地道并利用语言特定的功能。通信与系统在计算资源之间的分布方式无关——无论它们是在同一个进程中、不同的进程中,还是在不同的计算机中。用户可以将他们的应用程序分布在多台机器和进程上,甚至可以利用云计算资源,而对源代码的更改最少。ROS 2 能够通过互联网连接到云资源。有一些产品可以帮助将 ROS 2 集成到云平台中,例如亚马逊网络服务 (AWS) 物联网 (IoT) RoboRunner 和相关的 RoboMaker 产品 ( 37)。但是,建议使用更专业的专用技术。
客户端库依赖于中间接口 rcl,它为每个客户端库提供通用功能。该库是用 C 语言编写的,尽管不是必需的,但所有客户端库都使用该库。在 rcl 之下,称为 rmw (ROS MiddleWare) 的中间件抽象层提供了必要的通信接口。每个中间件的供应商都实现了 rmw 接口,并且无需更改代码即可互换。
用户可以根据性能、软件许可或支持的平台等各种限制来选择不同的 rmw 实现,从而选择不同的中间件技术。尽管所有受支持的 rmws 都基于 DDS,但仍有一些社区支持的 rmws 可用于其他通信方法 ( 7 )。这个抽象层为 ROS 2 提供了灵活性,允许它随着时间的推移而改变,而对构建在它上面的系统的影响最小。
网络接口(例如,主题、服务和动作)是使用接口描述语言(IDL)用消息类型定义的。ROS 2 使用 ros idl 格式(.msg 文件)或 OMG IDL 标准(.idl 文件)定义这些类型。用户提供的接口定义在编译时生成,并创建以任何客户端库语言进行通信所需的代码。


架构节点模式
还有其他架构模式可以帮助开发人员构建他们的程序。ROS 2 提供了一种管理节点生命周期的模式,这些节点通过状态机转换为未配置、非活动、活动和已完成等状态。这些状态允许系统集成商控制某些节点何时处于活动状态。这是协调分布式异步系统各个部分的重要工具。
正如前面在上一节中所讨论的,通信与机器和进程内端点的位置无关。但是,将每个节点放置在哪台机器或进程中并不是在编写节点时应该决定的,而是取决于节点在更大的系统中的使用方式。作为组件编写的节点可以作为配置分配给任何进程。这是正在开发的系统的一个重要功能,允许开发人员根据各种情况重新安排节点运行的位置。例如,可以将多个节点配置为共享一个进程以节省系统资源或减少延迟。

软件质量
要在关键应用程序中采用 ROS 2,它必须以可证明的高质量方式设计和实施。监管和认证机构需要了解系统的当前状态以及导致该系统的过程。为此,持续执行三部分方法来衡量和展示软件质量:
1) 设计文档:在重大添加之前,必须建立书面的工作原理和设计。该文档表现为设计文章或 ROS 增强提案 (REP) ( 38 , 39 )。在撰写本文时,有 44 篇设计文章和 7 篇 REP 记录了 ROS 2 的设计。
2) 测试:ROS 2 中的每个功能都需要测试以确保其行为正确。这些测试在持续集成中定期执行。部署了单元测试和集成测试的组合,以及一套静态分析工具(“linter”)。在撰写本文时,在 ROS 2 上运行了 32,000 到 33,000 个测试,其中包括 13 个 linter。
3) 质量声明:并非每个 ROS 2 包都需要严格记录和测试。因此,定义了多级质量政策(40)。该政策在开发实践、测试覆盖率、安全性等方面定义了每个质量级别的要求。在撰写本文时,有 45 个 ROS 2 包达到了最高级别,即质量级别 1。

性能和可靠性
网络是机器人框架的一个重要方面。在可靠的联网情况下,标准解决方案是 TCP/IP(互联网协议),因为它在大多数操作系统中都进行了优化。不幸的是,TCP/IP 难以在无线通信中传递数据,因为中断会导致回退、重传和延迟。ROS 1 建立在 TCP/IP 之上,并在这些情况下受到影响。
ROS 2 在这些情况下不会挣扎。DDS 使用 UDP 传送数据,它不会尝试重新传输数据。相反,DDS 决定何时以及如何在不可靠的条件下重新传输。DDS 引入了服务质量 (QoS) 以公开这些设置以优化可用带宽和延迟。
可靠性设置确定是否保证消息传递。使用“尽力而为”,发布者将尝试一次传递消息,这在新数据会使旧数据过时(例如,传感器数据)时很有用。设置为“可靠”,发布者将继续发送数据,直到接收者确认收到。
持久性 QoS 设置确定消息的持久性。“易失性”消息在发送后将被遗忘一次。同时,“transient-local”将根据需要存储和发送后期加入的订阅数据。
连接的历史决定了网络无法跟上数据时的行为。设置为“keep-all”,所有数据都会保留,直到应用程序使用它们。大多数应用程序使用“keep-last”,它保留一个固定大小的数据队列,根据需要覆盖最旧的数据。其他设置,包括期限、寿命、活跃度和租用期限,有助于设计实时系统。
进行实验以对 ROS 2 的网络性能进行基准测试。图 3A中的图表显示了通过 ROS 2 发送和接收不同大小消息的结果。该实验在运行于 3.4 的六核 Intel i7-6800K CPU 上运行GHz,具有 32 GB 的 RAM。截至 2021 年 9 月 23 日,该机器使用 CycloneDDS 和最新的 ROS 2 Rolling 分发包运行 Fedora 34 ( 41 )。使用的性能测试可以在https://github.com/ros2/performance_test和https://github.com/ros2/buildfarm_perf_tests中找到。

图 3 ROS 2 性能结果(SD 未显示,因为它太小了)
( A ) 不同的消息大小  ( B ) 发送丢包数据 

测试包括一个发布者和一个订阅。对于每个消息大小,每秒发送 1000 条消息,系统会记录延迟、有效发布率和 CPU 利用率。选择消息大小以测试不同方面,从关键间隔的小消息到大消息。测试在不同进程、同一进程内以及使用进程内通信的同一进程内重复。
数据显示进程内通信是最有效的,对于所有低于 8 MB 的大小,95% 的延迟都低于 1 毫秒。Intraprocess 是最可靠的,满足 8 MB 以下所有大小的发送速率。这绕过了中间件堆栈并通过将指针从发布者传递到订阅来传递数据。当处理大约 1 MB 或更大的大型消息时,这种改进尤其明显,这些消息通常与图像、点云或其他形式的高分辨率数据相关联。使用节点组合时,数据显示了类似的情况——第 95 个百分位延迟低于 1 毫秒,且大小低于 8 MB 时没有丢弃消息。
多进程通信允许发布者和订阅者在网络上的不同机器上。预计,它还显示出最高的延迟,低于 1 毫秒直到 1 MB,然后以 8 MB 飙升至 7.85 毫秒。发送率呈现类似趋势;在大小不超过 2 MB 的情况下,第 95 个百分位的发送速率为 1000 Hz,对于 8 MB,下降到 213 Hz。
使用多进程和进程间通信是最灵活的方案,但它也显示出最高的延迟和 CPU 利用率。简单地使用节点组合和/或进程内通信,延迟、CPU 利用率和发送速率都会显着降低。然而,对于小消息,所有机制都能够可靠地发布超过 1 kHz 的消息而不会丢失。
DDS 的默认配置在传递大于 1 MB 的信息时并不是特别有效,这对用户来说是一个真正的挑战。这有几个原因:小的默认 UDP 缓冲区大小、UDP 分片限制以及需要重新传输数据包的 DDS 可靠性保证。许多这些问题可以通过调整网络参数来消除,但代价是计算资源。使用 ROS 2 中的组合和进程内通信模式也可以提高性能。组合是 ROS 2 中推荐的设计模式,并且简化以鼓励其采用。
图 3B中的图表展示了 ROS 2 对网络中丢包的恢复能力。测试在 Ubuntu 20.04 虚拟机上运行,​​包含六个 Intel Xeon E5-2666 v3 CPU,频率为 2.9 GHz 和 16 GB RAM,使用 CycloneDDS rmw。对于每个测试,在不同的进程中运行相同的发布者和订阅节点。网络是通过 mininet 运行的,mininet 是一个网络模拟器,允许用户指定任意拓扑和链接特征。在本实验中,带宽上限为 54 Mbps(与慢速无线网络相当),丢包率在 0% 到 20% 之间变化。每条消息都由一个 1000 字节的数组组成,并且记录了接收到的消息数量。在具有中等丢失量的网络中,ROS 2 仍然可以有效地通过网络传递数据。

安全
安全性是任何现代商业机器人 SDK 的重要元素。ROS 2 不仅依赖于 DDS 安全标准,还提供了一套额外的工具 SROS2,以简化安全基础设施的管理。DDS 安全性主要包含三个概念:
验证
这确定了网络中消息或参与者的身份。ROS 2 使用数字签名进行身份验证,称为公钥加密。SROS2 包括用于生成和存储这些数字签名的命令行实用程序。
访问控制
这允许将细粒度的策略应用于经过身份验证的网络参与者。它允许参与者仅发现已批准的参与者并通过预先批准的网络接口进行通信。SROS2 具有用于生成这些配置的命令行工具。
加密
这确保了第三方无法窃听或重播数据到网络中。使用高级加密标准伽罗瓦/计数器模式 (AES-GCM) 对称密钥密码术执行加密。密钥材料源自作为身份验证的一部分获得的共享秘密。


实例探究
进行了五个案例研究,重点介绍了 ROS 2 提供的物质加速。每项研究都基于研究期间分析的访谈、客户体验和代码库,对 ROS 2 对每个组织的影响进行了主要的定性分析。各种用例和规模证明了 ROS 2 在机器人领域的重要性。
土地:幽灵机器人
Ghost Robotics 是一家总部位于费城的公司,专门生产用于国防、企业和研究的四足机器人。他们的机器人(图 4A)是为传统轮式或履带式机器人无法穿越的非结构化自然环境而制造的。Ghost 的 Vision-60 机器人被部署在洞穴、矿井、森林和沙漠中,可以轻松地穿过几英寸深的水或雪。他们的机器人被宾夕法尼亚大学团队用于 DARPA 地下挑战赛,Ghost 与美国军方在基地安全和其他实验应用方面建立了积极的合作伙伴关系 ( 42 )。 

图 4  案例研究机器人系统部署在陆地、空中和海上。
( A ) Ghost Robotic 的 Vision-60 机器人  ( B ) Mission Robotics 潜水机器人 

( C ) OTTO Motor 的“OTTO 100”机器人  ( D ) Freefly 的 Auterion 动力无人机 

图片来源:

(A) Ghost Robotics Corp. (B) Mission Robotics Inc.

(C) OTTO Motors/Clearpath Robotics。(D) Auterion 有限公司 

ROS 2 用于他们的主要计算平台 Nvidia Jetson Xavier,该平台处理任务执行、高级步态规划、地形构建和定位(SLAM)。Ghost 大约 90% 的软件使用 ROS 2 进行通信和架构,其余软件计划在不久的将来效仿。

软件架构
ROS 2 在构建内部协作和软件设计方面发挥了强大的作用。它们的高级和任务控制软件架构都与 ROS 2 高度集成。它们利用主要子系统之间的发布-订阅接口,使它们能够享受一致的 API,同时每个子系统中的技术都在不断改进。项目之间的这种清晰分离使他们能够在不干扰其他团队活动的情况下执行并行开发。
根据高级自主工程师 Hunter Allen 的说法,“这很棒;它是我们自治架构的基础。” 他们的任务控制软件使用 ROS 2 操作来请求、取消或获得有关当前任务的反馈。它需要一个任务标识符来交叉引用潜在任务的内部数据库来执行。接下来,它组装任务中的每个任务并激活特定任务所需的功能,建模为生命周期节点。最后,它执行任务。
Ghost 的大部分软件都是作为生命周期和组件节点来实现的。生命周期节点用于根据当前任务要求动态激活和停用功能,例如在基于全球定位系统和基于视觉惯性里程计 (VIO) 的定位之间切换。它们拥有数十种独特的功能,可随时用于不同的任务,空闲时占用的后台资源很少。组件节点是由多个团队开发并在运行时组合的独立模块。Ghost 发现,在有限计算平台上与大型跨学科团队合作时,这些策略非常重要。
所提供的 ROS 2 工具使 Ghost 能够在短短几个月内创建一个高度灵活和高效的自治系统。相比之下,该公司估计,如果从头开始,需要多名工程师来创建类似的功能,从而帮助支持新的自定义用户应用程序,需要很多年的时间。

xxxxx-19 大流行
在最初的 2019 年 (xxxxx-19) 封锁之后,机器人软件团队的有效规模翻了一番,同时减少了对关键硬件的访问。与此同时,他们正准备在几个月后与美国空军 (USAF) 一起进行演示。最终,该公司通过将其流程转向使用 ROS 2 中提供的功能而获得了成功。
在大流行之前,大部分开发都是在他们的办公室使用机器人进行的。当对机器人的访问突然停止时,Ghost 不得不将开发切换到 ROS 2 模拟器 Gazebo。一位工程师能够创建代表四足动物所需的自定义 Gazebo 插件和模拟文件。该模拟被用于开发整个美国空军演示的自主系统。这种新功能在他们能够返回办公室很长时间后仍在使用——它允许更快的内部开发来创建自定义行为并将它们部署到客户的机器人上。

ROS 2 作为均衡器
ROS 2 是 Ghost Robotics 的强大平衡力量。它帮助他们有效地与资金充足且根深蒂固的竞争对手竞争。他们没有构建端到端的专有软件组合,而是尽可能利用 ROS 2 的功能。根据 Hunter Allen 的说法,“我们拥有具有竞争力的产品,因为我们拥有制造具有竞争力的产品所需的工具。我们不必浪费时间去做 ROS 2 已经做的事情。” 截至 2021 年 8 月,只有 23 名员工,与竞争对手相比,ROS 2 已经拉平了竞争环境。仅用了 30 个工程师年(大约 7.5 名工程师在 4 年内),Ghost 就能够向客户发布他们的 Vision-60 机器人以供部署使用。
ROS 2 提供了 Ghost 使用的高质量通信和无数实用程序,例如 TF2、URDF、rosbag、rviz、roscli 和 Gazebo,它们加速了 Ghost 的机器人进入野外。

海:任务机器人
Mission Robotics 是旧金山湾区一家制造海洋机器人的公司(图 4B)。他们的设计优先考虑灵活性,支持范围广泛的客户,每个客户都为其应用程序定制平台。Mission 机器人的用例包括结构检查、环境调查、打捞和安全。这些任务传统上由专业潜水员执行,他们的时间稀缺且宝贵。增加机器人可以更频繁、更长时间地完成重要的水下工作,并且对人类的风险要小得多。
Mission的车辆携带传感器,收集有关地表和水下环境的数据。机器人的传感器套件会因用户而异,甚至在用户执行的潜水之间也会有所不同。重要的是,用户能够为给定的潜水添加和删除组件,同时确保能够可靠地访问结果数据。Mission Robotics 使用 ROS 2 作为这些数据流的通用数据总线,使客户能够轻松集成新硬件。

客户架构
Mission 的核心机器人软件不依赖于 ROS 2。工程团队有使用 DDS 的经验,直接在 Cyclone 和 Connext DDS 上构建了他们的内部系统 ( 41 )。该内部软件仅由 Mission 团队的一小部分人维护。
海上任务的要求通常是针对客户的,不容易一概而论,导致购买后进行定制。业界的一种常见做法是根据需要附加额外的传感器或工具,但通过各种特定于设备的接口独立操作和访问每个额外的外围设备。
Mission 使用 ROS 2 作为通用接口。当要集成新的传感器(例如特殊的低光摄像头)时,会开发一个设备驱动程序,与传感器通信并通过 ROS 2 发布其数据。驱动程序部署在 docker 容器中,将其与车辆的其余部分。重要的是,Mission 的客户可以创建自己的扩展,使用 ROS 2 作为通用语言,允许他们快速修改他们的机器人以用于自定义应用程序并共享通用基础设施。
例如,Mission 与 Aqualink 合作,为自主水面舰艇增加深度感应。感兴趣的有效载荷是一个 Zed 立体相机,它具有开箱即用的 ROS 2 驱动程序,包括对所使用的 Jetson Nano 单板计算机的支持。根据 Mission Robotics 首席技术官 Charles Cross 的说法,“立体相机在海洋机器人领域越来越受欢迎,尤其是在珊瑚礁测绘和物种识别等清水应用中。” 通过在 Jetson 上通过 ROS 2 集成 Zed 相机,Mission 和 Aqualink 能够为任何想要为海洋应用开发新的计算机视觉和自主能力的人创造一个起点。这项工作引起了其他潜在客户的关注。

ROS 2 作为加速器
对 ROS 2 的支持是 Mission 的一个卖点,它为内部系统提供抽象,并提供熟悉的开发人员体验。Cross 报告说,对于他们的至少三个客户,“对 ROS 2 集成的支持在他们的购买决策中明确发挥了作用。”
Mission 将 ROS 2 视为整个行业的加速器。根据 Cross 的说法,“在海洋领域,几乎没有标准化,也缺乏对现有能力的建设。” 结果,“人们不断地重新发明轮子”,从数据记录、传感器集成到消息格式。这种重复的工作是浪费的,并导致不兼容系统的扩散。
Mission Robotics 相信 ROS 2 正在改变海洋机器人技术,就像它为其他行业所做的那样。一套通用的消息、API 和工具将大大加快 Mission 和该领域其他公司的工作。特别是,使用 rosbag 进行数据记录为协作打开了大门。这种信息交换可以使机器人工程师、操作员和海洋科学家受益,他们通常是数据的最终用户。正如 Cross 所说,“使用一致的通信系统是这个行业的一大胜利。”

空气:Auterion 系统
Auterion 是一家来自瑞士苏黎世的空中无人机初创公司。它成立的目的是培育开源 PX4 Autopilot 开发者社区 ( 43 )。Auterion 以他们的 PX4 飞行经验为基础,生产了基于该项目的商业自动驾驶仪,并为客户集成提供商业支持。Auterion 的产品在整个行业中得到广泛应用,并支持多种类型的机身,包括 Freefly(图 4D)。
从历史上看,无人机只能由熟练的飞行员或在开放空间安全操作。Auterion 旨在将无人机带入具有危险的非结构化空间,同时在更多自主权下运行。Auterion 强调开放标准,选择 ROS 2 将更高级别的功能与 PX4 Autopilot 一起集成到他们的无人机系统中。
记录和自省
ROS 2 的日志记录、自省和调试提高了他们在 Skynode 上开发过程的效率,Skynode 是他们完全集成的自动驾驶解决方案。ROS 2 的日志记录功能用于收集运行时事件,例如错误、调试输出和有关系统的其他元数据。这些存储起来以供以后分析和调试。Auterion 还依赖 rosbag2 在运行时从系统的所有层(从传感器流到车辆行为)收集原始数据流。这种全面的记录对无人机特别有价值,因为风等环境因素对飞行条件有重要影响,而这些影响很难重现。因此,ROS 2 的数据集和日志记录功能对于有效的开发、调试和验证过程至关重要。
Auterion 还利用了强大的内省功能。Auterion 使用 rviz2,这是一个 3D 渲染器,可以在交互式环境中可视化无人机及其所有传感器数据。
ROS 2 中的 3D 可视化、数据记录和日志记录功能是 Auterion 使用 ROS 2 的驱动原因之一。Auterion 的软件工程师 Nuno Marques 最简洁地抓住了这些工具的价值,“事实上,我们拥有自省和可视化工具会让一切变得不同。” 利用这些能力,公司可以将开发工作重点放在核心飞行控制能力和客户需求上,而不是构建基础工具。
安全的自动化测试

飞行无人机对地面上的人和物以及机身本身都有固有的风险。进行安全飞行测试需要大量的劳动力和时间,因为每次实际飞行都有坠毁的风险。然而,在模拟中,与试飞相关的成本和风险几乎为零。模拟中的故障可以快速修复和迭代,然后重新运行。Auterion 使用 ROS 2 的模拟 Gazebo 能够在硬件测试之前对软件进行端到端测试,以验证安全功能。
Gazebo 用于他们的持续集成管道,以防止一系列车辆类型和场景的回归。测试并行运行以获得快速结果,这使开发人员可以专注于特定问题,同时保持对软件安全的信心。
Auterion 还利用模拟测试来验证开发过程中具有挑战性的场景中的功能。例如,他们可以设置对验证他们的工作很重要的飞行制度或特定情况。2021 年,Auterion 在 Gazebo 内飞行了大约 22,000 小时,包括无法使用硬件进行测试的高风险场景。Auterion 估计这些模拟取代了 12 名全职工程师,以在现场测试中提供相同的价值。他们的机身成本从 1000 美元到 100,000 美元不等,因此在任何测试中都存在相当大的风险——尤其是在需要测试的危险飞行条件下。开发和验证中的 ROS 2 模拟相结合,可实现更低的成本和更快的开发。 


空间:NASA VIPER
NASA 的 Volatiles Investigating Polar Exploration Rover (VIPER) 任务计划于 2023 年 11 月向月球南极地区发射。VIPER 漫游者将在为期 100 天的任务中使用各种仪器搜索水冰和其他资源. 地球计算资源将用于映射、注册地形和计算立体解决方案,以通过其与深空网络的 X 波段链接来帮助操作。许多基于地球的操作工具、计算模块和高保真模拟都是基于 ROS 2 和 Gazebo,如图5 所示。

图 5  带有命令和控制软件 VERVE 的月球模拟中的 VIPER 漫游者。
( A ) 月球表面上的 VIPER(渲染) ( B ) 指挥和操作软件。 

NASA 的核心飞行系统提供硬件接口、基本错误检查和有效载荷服务 ( 44 )。卫星链路向流动站传送命令和遥测数据。地球上的遥测数据被接收并发送到 ROS 2 网络,并由一组节点进行处理。节点将图像数据转换为点云,计算视觉里程计和地形配准,并融合数据以提供姿势校正。这些数据被输入 NASA 的远程虚拟探索视觉环境 (VERVE),使操作员能够可视化漫游车的环境 ( 45 )。操作员使用结果来模拟移动,然后最终在流动站上执行移动。

模拟任务测试
由于 VIPER 是一项太空飞行任务,因此该团队专注于生产高度可靠的软件。为了实现这一目标,他们广泛使用 Gazebo 对其所有组件和系统进行高保真测试。Mark Allen 说,“拥有一个模拟器 [Gazebo] 对于开发所有 VIPER 软件在某种程度上是必不可少的。”
VIPER 团队求助于 Gazebo 来帮助开发,因为在地球上模拟一个准确运行的月球车是不可行的。他们强调,“月球环境非常独特,有光照和重力,模拟测试非常重要,因为它不可能在地球上有效地进行测试。” 该项目能够使用 Gazebo 用户界面的自定义插件创建模拟。它专为高度定制而设计,以支持广泛的机器人技术需求——甚至空间。
NASA 开发了新的插件来模拟任务细节,例如相机镜头光晕、月球照明条件、重力和月球表面的地形。NASA 能够模拟低级串行链路的车辆接口。该仿真对于帮助迭代和改进 VIPER 的系统设计选择非常有价值。将漫游车模拟到硬件级别后,VIPER 团队在发射前使用 Gazebo 测试和验证了几乎所有漫游车的软件。
VIPER 重用了 284,500 条重要代码行 (SLOC),无需从 Gazebo 进行修改,修改不到 1% 即可通过验证。NASA 估计模拟器的开发速度为每个工作月 116 SLOC(完全实施需要 2456 个工作月)。这种代码重用加速了开发,使他们能够在仅 266 个工作月内生成模拟,专注于 VIPER 特定的元素 ( 46 )。
Gazebo 和 ROS 2 的组合用于训练流动站的操作员。ROS 2 用于向流动站注入故障;使用 VERVE,操作员需要确定如何清除故障以使流动站移动。
创造遗产
NASA 使用了许多不同的通信机制,但近年来,许多项目选择了 DDS,因为它能够穿越可能具有高延迟、低带宽和低可靠性的卫星链路。VIPER 团队评估了这些选项并选择了 DDS 以及基于地球的操作。
除了通信机制之外,VIPER 团队还渴望使用 ROS 2 的快速开发能力、自省和可视化工具以及开源可用的资源。这些特性缩短了新工程师将他们所知道的知识应用于飞行任务的学习曲线。
但是,在飞行任务中使用新软件需要严格的验证和确认 (V&V) 过程。NASA 更喜欢使用在之前的任务中经过审查的组件;利用传统软件可以减少开发时间和成本 ( 47 )。VIPER 正在重用来自 Resource Prospector 的 588,000 行代码中的 84%,以及 Gazebo 和大约 312 个开源 ROS 2 包(46)。ROS 2 尚未在之前的任务中使用,但 VIPER 团队认为它提供的功能值得花费额外的管理开销来完成该过程。在 ROS 2 被验证并用于 VIPER 任务的地面操作之后,ROS 2 在未来任务中的多种角色使用变得更加容易,并允许在任务程序之间更多地重用机器人软件。


大规模:OTTO Motors
OTTO Motors 是一家位于安大略省的 Clearpath Robotics 衍生公司,销售陆地和海洋研究平台。OTTO 使用自主机器人大规模生产仓库和工厂物料搬运服务,以取代人工控制的设备(图 4C)。他们在全球部署了数千个机器人,并在一个设施中运营着 100 多个车队。丰田、通用电气等客户都采用了奥托。本案例研究提供了对大型机器人应用的独特见解。自从 ROS 2 部署在 OTTO 的机器人上以来,它已经协调了超过 200 万小时的运行时间和 150 万公里的行程。
扩展多机器人技术
OTTO Motors 最初在 ROS 1 上开发了他们的技术。使用它,他们无法使用带有车队管理软件的自定义多主机系统在同一个共享 ROS 1 网络上测试超过 25 个机器人。这对于小型车队来说已经足够了,但随着 OTTO 发展成为更大的设施,这成为了一个瓶颈。
OTTO 对可用技术进行了一项调查,并独立得出了相同的结论,即多机器人车队通信的最佳技术是 DDS。更大的网络效应有利于他们在 ROS 生态系统中继续存在;因此,他们是 ROS 2 的早期采用者之一。这使他们能够利用 ROS 中启用的功能,同时无需独立维护专有的 DDS 框架。
迁移到 ROS 2 后,OTTO 能够在客户设施中扩展到 100 多个机器人。启用更大的多机器人规模是因为 ROS 2 具有细粒度和可扩展的网络拓扑管理,并且更好地支持通过共享网络链路上的 QoS 管理带宽。2017 年的这些部署代表了 ROS 2 在世界任何地方的首批商业部署。ROS 2 通过快速使他们能够扩展到前所未有的机器人数量,明显加快了他们的上市时间。OTTO Motors 估计,通过使用 ROS 2,他们在 5 年内节省了 100 万美元到 500 万美元。此外,他们通过不将这些工具重写到专有框架中节省了数百个工程小时。
OTTO Motor 的首席技术官 Ryan Gariepy 认为 ROS 生态系统对企业来说是必要的:“如果 ROS 不存在,整个企业可能不可行。本来就太贵了。” 他估计,如果没有它,他们的持续工程成本每年会高出 5% 到 10%。
加速发展
OTTO Motors 在另外两个领域加快了开发和部署。首先,它加速了他们的内部功能开发过程。分布式架构和流程隔离允许大型、物理上分布式的团队进行协作。使用明确定义的 ROS 2 接口允许 OTTO 分离主要类别的任务。Ryan Gariepy 在接受采访时表示,“就我们正在建造的机器人规模和现代制造的复杂性而言,你确实需要灵活地修补和删除能力并在大型团队中共享。” 他们的产品软件以多种语言分布在不同团队拥有的许多存储库中,并在运行时通过 ROS 2 组合在一起。
其次,事实证明,提供 ROS 2 支持对他们的客户和客户很有价值。OTTO 和 Clearpath 将他们的平台出售给其他企业,以在定制产品的基础上进行构建。一家公司最近从 OTTO 购买了平台来制造紫外线消毒机器人,以应对 COVID-19 大流行。因为他们有明确定义和标准的 API,这些外部合作者很容易利用机器人平台并将其绑定到他们的自主系统中。R. Gariepy 总结如下:“借助我们提供的 ROS API,我们的外部合作伙伴现在能够在我们的自主能力之上构建应用程序,而无需我们对他们进行机器人概念或专有库的培训。” 这种分离关注点和抽象供应商特定硬件甚至整个机器人平台的能力。


讨论
这五个案例研究说明了使用 ROS 2 的广泛应用、环境和基本原理。选择这些案例是为了提供在每个领域部署的现代应用机器人系统的独特横截面。无论它们在应用程序中的不同之处如何,都存在它们共享的几个共同线程。
ROS 2 使许多人能够更好地在其系统中重用软件组件。Mission Robotics 利用 ROS 社区的设备驱动程序和集成,以便他们的客户可以快速适应海洋机器人的特定用例。同样,Auterion 不仅使用较低级别的驱动程序,还使用社区的高级算法。VIPER 团队使用 ROS 2 来促进机构内的软件重用。在我们的采访中,他们表示让其他 NASA 团队重用代码具有挑战性,并且 ROS 生态系统具有内部名称识别功能,因此更容易鼓励此类合作。
另一个共同点是实现内部和外部的协作。Ghost Robotics 和 OTTO Motors 使用接口和组合节点来分离复杂系统的各个部分,以便团队可以进行协作,而无需关心系统其他部分的细节。Mission 和 Auterion 都能够使用 ROS 2 与其客户合作构建定制解决方案。
最后,ROS 2 允许企业通过销售可信平台来加速他人的发展。所有接受调查的公司都将其平台出售给其他企业以在其上构建产品。ROS 专业知识在行业中的普及,与其免费提供的许可相匹配,使其成为主要的机器人 SDK。通过使用 ROS 2 及其约定,他们能够销售可以在定制应用程序中快速运行的平台。
应该注意的是,这些主题——软件重用、协作和可信平台——与“设计原则”部分中列出的设计原则高度相关。特别是它们符合分布式、抽象和模块化的设计原则。对这些设计原则的坚持直接导致了我们研究中的新兴主题,这些主题代表了当今机器人行业的一些最大的加速因素。
结论
ROS 2 已从头开始重新设计,以应对现代机器人技术的挑战。它的设计基于一套深思熟虑的原则、现代机器人技术要求以及对广泛定制的支持。ROS 2 主要基于 DDS,是一个可靠且高质量的机器人框架,可以支持广泛的应用程序。该框架继续帮助加速机器人从实验室到野外的部署,并推动下一波机器人革命。
我们通过一系列案例研究表明,它如何明显加速公司和机构在各种规模的多种环境中进行有用的部署。他们表明 ROS 2 是推动者、均衡器和加速器。各行各业围绕 ROS 2 的标准化正在为新的合作、更快的开发和推动新开发的技术创造机会。随着 ROS 2 继续达到其成熟的顶峰,这种趋势可能会在未来几年继续显现。
致谢
我们要感谢在案例研究中接受采访的公司代表。其中包括 Ghost Robotics 的 H. Allen 和 J. Laney、Mission Robotics 的 C. Cross、Auterion 的 N. Marques 和 M. Achtelik、NASA Ames 的 M. Allen 和 T. Fong,以及 OTTO Motors 的 R. Gariepy。我们还要感谢 Open Robotics 的团队、ROS 2 技术指导委员会的成员以及社区的热情支持。


REFERENCES AND NOTES
1
M. Quigley, B. Gerkey, K. Conley, J. Faust, T. Foote, J. Leibs, E. Berger, R. Wheeler, A. Ng. ROS: An open-source Robot Operating System, in IEEE International Conference on Robotics and Automation Workshop on Open Source Software (IEEE, 2009).


2
S. Chitta, E. Marder-Eppstein, W. Meeussen, V. Pradeep, A. R. Tsouroukdissian, J. Bohren, D. Coleman, B. Magyar, G. Raiola, M. Lüdtke, E. F. Perdomo, ros_control: A generic and simple control framework for ROS. J. Open Source Soft. 2, 456 (2017).

CROSSREF

3
E. Marder-Eppstein, E. Berger, T. Foote, B. Gerkey, K. Konolige, The Office Marathon: Robust navigation in an indoor office environment, in IEEE International Conference on Robotics and Automation (IEEE, 2010), pp. 300–307.

4
D. Coleman, I. Sucan, S. Chitta, N. Correll, Reducing the barrier to entry of complex robotic software: A MoveIt! case study. J. Soft. Eng. Robot. 5, 3–16 (2014).


5
B. Cairl, Deterministic, asynchronous message driven task execution with ros, in ROSCon Madrid 2018 (Fetch Robotics Inc., Open Robotics, September 2018).


6
S. Macenski, F. Martín, R. White, J. G. Clavero, The Marathon 2: A Navigation System, in Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems (IEEE, 2020).


7
G. Pardo-Castellote, OMG Data-Distribution Service: Architectural overview, in International Conference on Distributed Computing Systems Workshops (2003), pp. 200–206.


8
W. Woodall, ROS on DDS (2022); https://design.ros2.org/articles/ros_on_dds.html [accessed 11 February 2022].


9
B. Kuipers, E. A. Feigenbaum, P. E. Hart, N. J. Nilsson, Shakey: From conception to history. AI Magazine 38, 88–103 (2017).

CROSSREF

10
R. E. Fikes, N. J. Nilsson, Strips: A new approach to the application of theorem proving to problem solving. Artificial Intell. 2, 189–208 (1971).

CROSSREF
ISI

11
R. Brooks, A robust layered control system for a mobile robot. IEEE J. Robot. Autom. 2, 14–23 (1986).
CROSSREF

12
E. Gat, On three-layer architectures. Artificial Intell. Mobile robots 1998, 195–210 (1998).


13
R. G. Simmons, Structured control for autonomous robots. IEEE Trans. Robot. Autom. 10, 34–43 (1994).

CROSSREF

14
M. Montemerlo, N. Roy, S. Thrun, Perspectives on standardization in mobile robot programming: The carnegie mellon navigation (carmen) toolkit, in Proceedings 2003 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS 2003) (Cat. No. 03CH37453) (IEEE, 2003), vol. 3, pp. 2436–2441.


15
C. Mohan, R. Dievendorff, Recent work on distributed commit protocols, and recoverable messaging and queuing. Data Eng. 17, 1 (1994).


16
J. Waldo, The jini architecture for network-centric computing. Commun. ACM 42, 76–82 (1999).
CROSSREF

17
OASIS, MQTT Version 5.0: OASIS Standard, (OASIS MQTT Technical Committee, 2019).


18
B. P. Gerkey, R. T. Vaughan, K. Støy, A. Howard, G. S. Sukhatme, Maja J Matarić, Most Valuable Player: A robot device server for distributed control, in Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems (IEEE, 2001).


19
G. Metta, P. Fitzpatrick, L. Natale, YARP: Yet another robot platform. Int. J. Adv. Robot. Syst. 3, 8–48 (2006).

CROSSREF

20
A. S. Huang, E. Olson, D. C. Moore, LCM: Lightweight Communications and Marshalling, in IEEE/RSJ International Conference on Intelligent Robots and Systems (IEEE, 2010), pp. 4057–4062.


21
H. Bruyninckx, P. Soetens, B. Koninckx. The real-time motion control core of the Orocos project, in Proceedings of the IEEE International Conference on Robotics and Automation (IEEE, 2003).


22
Apache Software Foundation, Apache License, Version 2.0 (2021); https://www.apache.org/licenses/LICENSE-2.0.html [accessed 3 September 2021].


23
K. Birman, T. A. Joseph, Exploiting virtual synchrony in distributed systems, in ACM Symposium on Operating Systems Principles (1987), pp. 123–138.


24
J. Corbet, A. Rubini, G. Kroah-Hartman, Linux device drivers ("O’Reilly Media Inc., 2005).


25
G. Mühl, L. Fiege, P. Pietzuch, Distributed Event-Based Systems (Springer Science & Business Media, 2006).


26
M. D. McIlroy, E. N. Pinson, B. A. Tague, Unix time-sharing system: Foreword. Bell Syst. Tech. J. 57, 1899–1904 (1978).

CROSSREF

27
A. Sundaresan, L. Gerard, Secure ros: Imposing secure communication in a ros system, in ROSCon Vancouver 2017 (Open Robotics, September 2017).


28
K. Fazzari, ROS 2 DDS-Security integration, (2021); https://design.ros2.org/articles/ros2_dds_security.html [accessed 6 September 2021].

29
OMG, DDS Security (2022); www.omg.org/spec/DDS-SECURITY/1.0/PDF [accessed 9 February 2022].


30
R. White, G. Caiazza, H. Christensen, A. Cortesi, Procedurally provisioned access control for robotic systems, in Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems (IEEE, 2018).


31
I. Lütkebohle, B. O. Gamarra, I. M. Goenaga, J. M. Losa, V. Mayoral Vilches, micro-ROS: ROS 2 on microcontrollers, In ROSCon (Open Robotics, October 2019).


32
Object Management Group, Data Distribution Service for Real-time Systems Specification (December, 2004).


33
L. Puck, P. Keller, T. Schnell, C. Plasberg, A. Tanev, G. Heppner, A. Rönnau, R. Dillmann, Distributed and Synchronized Setup towards Real-Time Robotic Control using ROS2 on Linux, in Proceedings of the 2020 IEEE 16th International Conference on Automation Science and Engineering (CASE) (IEEE, 2020), pp. 1287–1293.


34
J. Staschulat, I. Lütkebohle, R. Lange, The rclc Executor: Domain-specific deterministic scheduling mechanisms for ROS applications on microcontrollers: Work-in-progress, in International Conference on Embedded Software (IEEE, 2020), pp. 18–19.


35
M. Sagar, ISO Certification of ROS 2, in Embedded World Conference (March 2021).


36
J. Torjo, Asio C++ Network Programming: Enhance your skills with practical Examples for C++ Network Programming (2013).


37
C. Yun, AWS IoT RoboRunner for Building Robot Fleet Management Applications (2022); https://aws.amazon.com/blogs/aws/preview-aws-iot-roborunner-for-building-robot-fleet-management-applications/ [accessed 11 February 2022].


38
ROS 2 Design, (2021); http://design.ros2.org/ [accessed 5 August 2021].


39
ROS Enhancement Proposals (2021); https://ros.org/reps/rep-0000.html [accessed 5 August 2021].


40
W. Woodall. REP 2004: Package Quality Categories (2021); https://ros.org/reps/rep-2004.html [accessed 5 August 2021].


41
Eclipse Foundation, Cyclone DDS (2021); https://cyclonedds.io/ [accessed 3 September 2021].


42
I. D. Miller, F. Cladera, A. Cowley, S. S. Shivakumar, E. S. Lee, L. Jarin-Lipschitz, A. Bhat, N. Rodrigues, A. Zhou, A. Cohen, A. Kulkarni, J. Laney, C. J. Taylor, V. Kumar, Mine tunnel exploration using multiple quadrupedal robots. IEEE Robot. Autom. Lett. 5, 2840–2847 (2020).

CROSSREF

43
L. Meier, D. Honegger, M. Pollefeys, Px4: A node-based multithreaded open source robotics framework for deeply embedded platforms, in Proceedings of the 2015 IEEE International Conference on Robotics and Automation (ICRA) (IEEE, 2015), pp. 6235–6240.


44
D. McComas, NASA/GSFC’s Flight Software Core Flight System, in Flight Software Workshop (Southwest Research Institute San Antonio, Texas, 2012).


45
S. Y. Lee, S. Lees, T. Cohen, M. Allan, M. Deans, T. Morse, E. Park, T. Smith, Reusable science tools for analog exploration missions: xgds web tools, verve, and gigapan voyage. Acta Astronaut. 90, 268–288 (2013).

CROSSREF

46
S. Stukes, M. Allan, Matthew Deans Georgia Bajjalieh, T. Fong, J. Hihn, H. Utz, An innovative approach to modeling viper rover software life cycle cost, in Proceedings of the 2021 IEEE Aerospace Conference (50100) (IEEE, 2021).


47
C. Price, Heritage Software Save up to 97% on future V&V for real projects (2021); www.nasa.gov/sites/default/files/03-09_ivv_guidance_for_ivv_for_product_line_software.pdf [accessed 7 September 2021].


  • 6
    点赞
  • 22
    收藏
    觉得还不错? 一键收藏
  • 6
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 6
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值