机器人架构设计和中间件

一．引言

        在无人驾驶与机器人领域，算法一直都是研究的核心。无论是导航技术、控制技术，还是识别技术都是构成其技术栈的重要组成部分。但是，随着技术的发展，开发者们逐渐认识到一个问题，即程序本身的组织架构与实效性，也对系统的正确性与精度产生了极大的影响。低延时、高负载能力、高易用性等等数据传输的质量与性能指标，也逐渐为工程师们所重视起来。这使得中间件与架构设计的重要性，逐渐凸显出来。目前国内主要分为两类方案：一类是基于既存的开源中间件进行开发；另一类则是自己研发或是基于开源中间件二次研发中间件。

二．机器人架构设计

        机器人架构设计主要面向四个方向

        （1）机器人操作系统总体设计与运行环境。

        （2）支持实时性和智能计算的机器人操作系统内核。

        （3）机器人功能组件与可视化集成开发环境。

        （4）机器人网络化分布处理关键技术。

        通过以下四个方面来完成对四个方向的技术覆盖

        （1）操作系统

        （2）实时操作系统内核

        （3）机器人操作系统 Robot Operating System (ROS) 

        （4）机器人中间件框架 Robotics Middleware Framework (RMF)

        其中ubuntu操作系统用来支撑整个结构的运行，RT-Thread支持实时性内核，而ROS和RMF来支撑机器人的功能组件和分布式处理

        下面我们分别从这几个方向来详述

        1. 操作系统

        目前很多机器人使用的是ubuntu 1804作为机器人上位机的基础操作系统，这主要是因为，第一，上层软件是基于的ROS机器人操作系统来开发的，而ubuntu1804操作系统也是目前使用时间最长，最稳定的操作系统，大部分嵌入式硬件厂商都会免费提供该操作系统，而且其集成了ROS Melodic版本，使用ubuntu1804操作系统无疑减少了系统层面的开发工作量，下面就是ubuntu系统和ros的对应关系

        版本代号

        Ubuntu 和 ROS1 部分版本对应关系及官方支持结束时间如下表所示。

Ubuntu	ROS1	发布时间	支持期限
14.04 LTS	Indigo Igloo	2014年5月	2019年4月
16.04 LTS	Kinetic Kame	2016年5月	2021年4月
18.04 LTS	Melodic Morenia	2018年5月	2023年5月
20.04 LTS	Noetic Ninjemys	2020年5月	2025年5月
22.04 LTS	-	-	-

        Ubuntu 和 ROS2 部分版本对应关系及官方支持结束时间如下表所示。

Ubuntu	ROS2	发布时间	支持期限
18.04 LTS	Crystal Clemmys	2018年12月	2019年12月
18.04 LTS	Dashing Diademata	2019年5月	2021年5月
20.04 LTS	Foxy Fitzroy	2020年6月	2023年5月
22.04 LTS	Humble Hawksbill	2022年5月	2027年5月

        但是最近由于ubuntu系统在商业领域出现了授权问题，很多硬件厂商将目光投向了开源系统debain，机器人领域之所以选择debain，而不是centos或者是Redhat，一方面是由于Ubuntu 源自 Debian。这意味着 Ubuntu 使用与 Debian 相同的 APT 包管理系统，并共享来自 Debian 库中的大量包和库。另外一方面在于在我国目前国产芯片适配的国产操作系统也在ubuntu操作系统进行改造而来，对于机器人厂商来讲使用ubuntu操作系统无疑使得我们的产品更易于融入到目前的国内软硬件的生态链中，而且可以极大的减少开发工作量，以及更快的适应国家对于基础硬件和基础操作系统的安全性要求带给我们的迁移工作量。

        因为操作系统和ROS息息相关，选择合适的操作系统，有利于我们减轻系统适配的工作，加速研发进程

        目前我们可采用的操作系统包括ubuntu1804，ubuntu2004，debain11，

        在选择时要考虑到以下问题：

        1. 版权问题，ubuntu1804系统是目前我们使用的操作系统，使用该操作系统，我们的上层软件依赖的ROS版本和其他依赖库版本都是和当前我们发布的产品一致的，并且编译器gcc版本也是一致的，可以极大减少我们的软件迁移工作和整机测试工作，但是在ubuntu的官网上关于版权问题有这样的阐述Must not require royalty payments or any other fee for redistribution or modification.It's important that you can exercise your rights to this software without having to pay for the privilege, and that you can pass these rights on to other people on exactly the same basis.
就是说重新发布或者修改后都不可以再收费。我们是否要规避这样的授权限制是要考虑的

        2.Ubuntu18和ubuntu20，机器人厂商想使用的部分新功能在ubuntu20上比较容易编译通过，这当然不是我们选择ubuntu版本最根本的依据，考虑下面随后几年的ros的主流版本才是我们重点需要考虑的，根据ros来选择ubuntu操作系统版本，确保我们花了一年研发稳定下来的版本起码可以在随后的3-5年内稳定的使用

2.RTOS

        在讨论RTOS的时候我们首先要了解实时操作系统和分时操作系统，以及软实时和硬实时等相关概念

        实时操作系统（Real Time Operating System，简称RTOS）是指当外界事件或数据产生时，能够接受并以足够快的速度予以处理，其处理的结果又能在规定的时间之内来控制生产过程或对处理系统做出快速响应，调度一切可利用的资源完成实时任务，并控制所有实时任务协调一致运行的操作系统。提供及时响应和高可靠性是其主要特点。

        实时操作系统是保证在一定时间限制内完成特定功能的操作系统。实时操作系统有硬实时和软实时之分，硬实时要求在规定的时间内必须完成操作，这是在操作系统设计时保证的；软实时则只要按照任务的优先级，尽可能快地完成操作即可。我们通常使用的操作系统在经过一定改变之后就可以变成实时操作系统。

        14种主流的RTOS，分别为μClinux、μC/OS-II、eCos、FreeRTOS、mbed OS、RTX、Vxworks、QNX、NuttX；而国产的嵌入式操作系统包括都江堰操作系统(djyos)、Alios Things、Huawei LiteOS、RT-Thread、SylixOS。

        ROS 是在 Linux 上运行的一套软件框架，Linux 本身并不是实时系统（可以通过打补丁的方式转换为实时操作系统），机器人一些对实时性要求比较高的任务并不太适合用 Linux，例如RT-Thread这一款完全由国内团队开发维护的集实时操作系统（RTOS）内核 虽然是实时操作系统（RTOS），但毕竟 MCU 的资源有限，并不能直接运行完整的 ROS。

        于是，通常的做法是利用 Linux 丰富的软件包实现一些顶层算法，而 RT-Thread 则负责实时控制相关的任务，它们之间的通信就是可以通过 rosserial 和 micro_ros。rosserial 和 micro_ros 共同的目标都是为了把 MCU 接入 ROS，使得 MCU 能和 ROS 通信，并且在 MCU 上调用 ROS 的 API，主要区别就在于 rosserial 是针对 ROS1，而 micro_ros 是针对 ROS2。

        机器人是否需要引入软实时或者硬实时内核功能，这与产品是息息相关的。

        这里我们仅仅列出FreeRTOS和RT-Thread的比较

        Freertos是一个国外推出的一个迷你的实时操作系统内核，开源，功能包括：任务管理、时间管理、信号量、消息队列、内存管理、记录功能、软件定时器、协程等，可基本满足较小系统的需要。

        RT-Thread是中国人自己推出的一个集实时操作系统（RTOS）内核、中间件组件和开发者社区于一体的技术平台，开源os，RT-Thread除了有常规RTOS的功能，还具备一个IoT OS平台所需的所有关键组件。

        例如GUI、网络协议栈、安全传输、低功耗组件等等。

        下面比较一下Freertos和RT-Thread 在内核、支持的组件、驱动：

3. 机器人操作系统 Robot Operating System (ROS)

        ROS是一个适用于机器人的开源的元操作系统。其实它并不是一个真正的操作系统，其底层的任务调度、编译、寻址等任务还是由Linux操作系统完成，也就是说ROS实际上是运行在Linux上的次级操作系统。但是ROS提供了操作系统应用的各种服务（如：硬件抽象、底层设备控制、常用函数实现、进程间消息传递、软件包管理等），也提供了用于获取、编译、跨平台运行代码的工具和函数。

        目前很大一部分厂商采用的还是ROS1，ROS1骨架框架中的架构和功能无法满足当今快速发展的机器人行业的需求。ROS2的开发具有增强的架构，可用于工业界和学术界。为了避免弃用ROS开发的当前应用程序，ROS 2不是作为ROS1的更新而开发的，而是作为与现有版本一起运行的软件开发的。 

        (1)进程管理：在ROS1中，需要开启中央节点管理器Master，统一管理所有节点。如果Master节点出现故障，将严重影响ROS系统功能。在ROS2中，系统引入节点自发现机制，可有效提高系统鲁棒性。ROS1 中，在运行节点之前，需要启动 ROS 主节点。ROS1 主节点将充当节点的 DNS 服务器，以便它们可以相互检索。

        ROS2 中，不再有 ROS 主节点！这不再是一个集中式系统。每个节点都具有发现其他节点的能力。可以简单地启动一个节点，而不必担心是否有主节点正在运行。可以创建完全分布式系统。

        (2)进程间通信：ROS1基于TCP和UDP协议自己开发了TCPROS和UDPROS协议，而在ROS2中，通信协议更换成了更加复杂但也更加完善的DDS系统。

        (3)进程内通信：如果是在进程内需要进行大量数据的通信，ROS1 和ROS2都提供了基于共享内存的通信方法，分别是Nodelet和 Intra-process模块。

        (4)跨平台：最下边是系统层，也就是可以将ROS安装在哪些操作系统上，ROS1主要安装在Linux上，ROS2可跨平台，如Linux、windows、MacOS、RTOS。

        (5)ROS1无法解决的多机器人团队应用场景,未来机器人一定不会是独立的个体，机器人和机器人之间也需要通信和协作,虽然今天可以用ROS来构建多机器人系统，但没有标准方法，且都是基于ROS的单一主机结构之上的,ROS2为多机器人系统的应用提供了标准方法和通信机制。

        (6)我们希望直接在ROS中支持实时控制，包括进程间和机器间通信（假设有合适操作系统和/或硬件支持的情况下）。机器人运动控制和很多行为策略要求机器人具备实时性，比如机器人要可靠得在100ms内发现前方的行人，或者稳定的在1ms周期内完成运动学、动力学的解算，ROS1不支持实时系统，ROS2为类似这样的实时性需求提供了基本保障。

          （7）在非理想网络：我们希望ROS在网络连接因数据包丢失和/或延迟而降低时（从质量差的WiFi到地对空通信链路）表现得尽可能好，而无论在怎样的网络环境下，ROS2都可以尽量保障机器人大量数据的完整性和安全性，比如在wifi信号不好的时候数据也要尽力发送过去，在有黑客入侵风险的场景下要对数据进行加密解密

        （8）在 ROS1 中，服务是同步的。当服务客户端向服务器请求请求时，该请求将一直卡住，直到服务器响应（或失败）。在 ROS2 中，服务是异步的。调用服务时，可以添加一个回调函数，该函数将在服务器响应时触发。同时，您的主线程不会卡住。

        （9）接口更统一，在 ROS1 中，对于 Cpp，你使用 roscpp，而对于 Python，你使用 rospy。这两个库都是完全独立的，从头开始构建。有些功能接口不统一。

         （10）ROS2 具有更多层。只有一个名为 rcl 的基本库，它是用 C 语言实现的。这是包含所有 ROS2 核心功能的基础。在此基础上构建Cpp和Python接口，底层接口统一

         （11）使用 OOP 写入节点，在 ROS1 中，没有特定的结构告诉您应如何编写节点功能。您可以决定在程序中的任何位置添加回调函数，或者根据需要使用OOP，但每个函数的实现都可以是唯一的。在 ROS2 中，情况有所不同。有一个关于如何编写节点的约定。您必须创建一个继承自 Node 对象的类。这将为每个人节省大量时间。您已经拥有了一个良好的模块化结构来编写节点。这将使您的程序更干净，开发人员在不同项目上的合作将更容易。

         （12）Navigation软件在ROS 2的开发及移植工作，对ROS 2核心功能的完善以及商业产品的应用都非常关键，同时，相较于ROS版Navigation，Navigation2也在设计上对模块功能边界做了更有意义的封装，保证了Navigation2对未来需求的应变能力，例如对不同地图格式、机器人本体以及路径与避障算法等等的支持。

        总体上来说，ROS2除了功能性加强之外，在以下的性能和安全性方面也得到了了极大的增强

        （1）实时性增强：数据必须在deadline之前完成更新；

        （2）持续性增强：DDS可以为ROS 2提供数据历史服务，新加入的节点也可以获取发布者发布的所有历史数据；

        （3）可靠性增强：配置可靠性原则，用户可以根据需求选择性能模式（BEST_EFFORT）或者稳定模式（RELIABLE）。

        （4）安全性增强：在有黑客入侵风险的场景下要对数据进行加密解密

        （5）在延时、吞吐量、线程数、内存消耗等几个方面的性能也有了比较大的提升

        关于ROS1和ROS2之间的通信问题

        ROS2提供了一个ROS2 package，这个包提供了一个桥(bridge)，可以在 ROS 1 和 ROS 2 之间交换消息。

        总体上来说，ROS2取代ROS1是必然的，但是否使用ROS2来替换ROS1，我认为对于中国的机器人制造商来说还是需要考量的，为什么这么说，是因为不论是ROS1还是ROS2都是大学里面输出的，他的后期维护和版本的更新都是跟不上企业的节奏的，特别是ROS1，其还有几百个bug没有解决，这样子的情况虽然在ROS2上有所改善，但是明显支撑力不够。

        下面我们就来讲一下百度的Apollo Cyber RT ，Apollo Cyber RT 是专为自动驾驶场景设计的开源、高性能运行时框架。 基于中心化计算模型，主要价值是提升自动驾驶系统的高并发、低延迟、高吞吐。

        Apollo 并不是一开始就使用 CyberRT，在 v3.0 之前用的都是基于 ROS 框架进行开发。但在之前的版本中发现了很多问题，随着 Apollo 的发展，对最高水平的稳健性和性能的需求， Apollo Cyber RT 应运而生，它满足了一个面向商业化的自动驾驶解决方案的基础需求。

        从技术细节来看感觉Apollo Cyber RT和ROS2针对于ROS1的优化方向大致相同，如果appollo的社区和开发人员更加给力的情况下，毫无疑问选择appollo。

4. 机器人中间件框架Robotics Middleware Framework (RMF)

        想象一下，在这个我们生活的世界中，来自不同公司和制造商的机器人可以在同一设施中共存；优雅地共享重要资源，例如走廊，电梯（电梯），门和其他基础设施，以实现更高效的整体系统。想象一下，通过一种允许任何机器人可靠受控和安全的方式使用共享资源的方式集成到一起。想象一下，在共享走廊中没有机器人困境的世界。今天，使用称为RMF的惊艳系统可以实现这些想法。

        如今，生产环境中的当前一代机器人能够提供服务，包括批量和单件流量交付，清洁，消毒，安全性，监控等等。这些多样化的用例很可能意味着针对每个任务的最佳机器人将来自不同的机器人提供商或系统集成商。这种现代的现实状况对于使用适当的通用软件框架来管理这些异构资源并确保有效地利用不同平台上的信息以提高整体系统效率至关重要。

        如果没有针对整体高效的机器人系统的计划，那么最终用户在向单个系统或平台提供商承诺时可能会面临重大但隐藏的风险。隐藏的风险可能会迫使最终用户限制用户从该特定提供商那里选择将来的解决方案，以最大程度地降低运营风险并避免多余的集成成本。随着机器人部署范围的扩大和规模的扩大，这个问题更加严重，使客户感到除了留在当前供应商之外，没有其他好的选择。

        除了与不同提供商进行扩展部署而增加的成本风险之外，共享资源（例如电梯，门口，走廊，网络带宽，充电器，运营中心屏幕“不动产”）和人力资源（例如IT人员）也存在内在冲突和维护技术人员。随着机器人规模的扩大，运营团队考虑管理大型的，异构的，多供应商的机器人环境变得更加麻烦。

        这些问题陈述是RMF开发的基本动力。从历史上看，ROS的开发主要集中在单个机器人上或附近运行的软件。 RMF旨在在更高的抽象层上运行，以创建与建筑基础设施系统，企业服务，物联网设备和人机界面互操作的网络化机器人团队。

        使用RMF使开发者的选择、设备和未来不再受限。

        使用机器人操作系统ROS2和机器人中间件框架系统RMF进行多机器人系统集成，高层规划及其应用等。

        RMF是在ROS 2之上构建的可重用，可伸缩的库和工具的集合，这些库和工具可实现任何类型的机器人系统的异构团队的互操作性。 RMF利用与基础设施，环境和自动化的标准化通信协议，在这些基础设施，环境和自动化中部署机器人来优化关键资源（即机器人，电梯，门，通道等）的使用。它通过资源分配和通过RMF核心防止共享资源之间的冲突为系统增加了智能，这将博文的后续内容中进行详细介绍。

        RMF具有足够的灵活性和鲁棒性，几乎可以在任何通信层上运行，并且可以与任何数量的IOT设备集成。 RMF的体系结构设计为允许随着环境中自动化水平的提高而具有可伸缩性。系统和用户可以通过API和可自定义的用户界面通过多种方式与RMF进行交互。一旦部署到环境中，RMF将通过允许共享资源和最小化集成来节省成本。这就是机器人开发人员和机器人客户一直在寻找的东西。简而言之，RMF架构如下：

        地图、楼层、路径、航点等概念几乎对所有移动机器人都是适用的，因此RMF可以直接使用。但在不同类型的机器人之间，还有哪些概念是共有的？RMF目前将移动机器人的任务抽象成3种：清洁、运送、循环。当然，以后可能会增加其它类型。大家可能会惊讶，仅这3种几乎就能覆盖目前所有类型的移动机器人。清洁任务是对某片区域进行全覆盖，因此不仅是扫地机器人，如果系统中有自动割草机，也适用这种任务。循环即在固定的航点间往返，对于安防巡逻任务非常合适。而还有很多不同的机器人任务都可以被抽象成是运送任务。运送是一项普遍的需求，机器人在一点拿取货物，再移动到另一点放下。其中最重要的在于抽象出了拿取和放下这两个概念。系统只给机器人这样的命令并监控执行状态，而并不管具体如何实现。例如自动叉车叉取货物时，先识别托盘，再进行对接；复合机器人通过机械臂进行抓取；还有些机器人依靠人工协作取货。这些都属于拿取。类似的，机器人放下货物也可以有各种不同的方式。甚至迎宾机器人将客人从一处带到另一处也可以看作是运送任务，尽管客人只是跟着机器人，并没有实体的拿取和放下。这些具体实现由供应商完成，但经过抽象后，RMF就能以标准的方式来管理。

        任务的具体实现仍然是供应商完成的，只是服从RMF的管理。因此需要看下RMF和供应商系统的对接层面。RMF并不在乎机器人的供应商是谁，而只关心机器人是何种类型的，可执行什么样的任务。因此一般把同样的机器人放到一个机队里，在机队层面进行管理。当然，目前大多数情况下，供应商的系统只要做一些适配就可以成为机队的系统。当然，鉴于之前描述的各种情况，复杂性也不是可以完全避免的，这取决于之前的系统设计的是否守弱。RMF当然希望能对机队进行完全控制，最好是能单独控制每台机器人的运行路线。但最糟糕的情况是，一个机队完全不可调度，我们只能知道其运行状态，但没有接口修改任务，甚至没有接口进行暂停。RMF对此也是有应对，可以将其作为一个只读机队，其它机队都要对其避让。显然，系统中只能有一个只读机队，但这至少保证可以有多个机队同时使用。比这好一点的层面是交通灯的控制，路线仍无法修改，但这时至少可以将任务暂停和恢复了，在解决资源冲突上就方便了一些。所有机队都能完全控制是最理想的情况，这时系统可以有最高的效率。

三.总结

        根据上面的总结，以下只是我的建议

1. 使用debain11系统替换ubunutu18操作系统，并且对系统进行定制，例如使用轻量级桌面替换现有的gnome桌面，减少不必要的系统服务，减轻图形界面对于系统的不必要的负载

2. 鉴于服务类机器人，并不需要绝对的硬实时，可以通过向内核打入实时补丁包的方法，允许任务优先级调度，实现软实时，增加机器人行动的实时性

3. 使用Apollo Cyber RT替换ROS1无论是从系统的功能，性能和安全性方面都能极大提高产品的竞争力

     4.   使用RMF架构，提高在产品集成领域的位置，健全生态链