本系列博客包括6个专栏，分别为：《自动驾驶技术概览》、《自动驾驶汽车平台技术基础》、《自动驾驶汽车定位技术》、《自动驾驶汽车环境感知》、《自动驾驶汽车决策与控制》、《自动驾驶系统设计及应用》。
此专栏是关于《自动驾驶汽车平台技术基础》书籍的笔记.

2.Apollo平台计算框架——Cyber RT

2.1 Cyber RT计算框架概述

1. 自动驾驶操作系统

   自动驾驶操作系统是一种计算机操作系统，是计算平台的重要组成部分，自动驾驶操作系统的应用场景是自动驾驶汽车，可用于管理、调度和控制车载软硬件资源；自动驾驶操作系统需要具备以下功能：

   • 能够实现多种实时任务和计算任务的系统资源隔离、实时消息通信、实时任务调度、系统级访问控制等基础功能；
   • 有效管理系统资源，提高系统资源使用效率；
   • 可以适配接入摄像头、激光雷达、毫米波雷达等多类传感器设备，并有效屏蔽硬件物理特性和操作细节的差异性；
   • 能够承载运行实时环境感知、高精地图定位、决策规划与控制等自动驾驶核心部件；
   • 能够提供便捷、智能的人机交互功能服务；

   $\mathrm{CarOS}$是百度研制的全球首个实时、可靠、安全、可控的自动驾驶操作系统，能够提供一整套完备的自动驾驶操作系统应用框架及服务；$\mathrm{CarOS}$作为上层应用软件和底层硬件间的中间层，可以提供模块通信、服务调用等应用接口及丰富的传感器驱动等功能，是汽车电子系统的核心软件；

   $\mathrm{Cyber}\mathrm{RT}$计算框架是百度结合自动驾驶业务实际需求场景，自主设计、研发的车载操作系统，是$\mathrm{CarOS}$全新一代的基础运行框架，该框架向下能够兼容主流硬件计算平台，向上能够支持自动驾驶业务各个应用模块的实际业务需求；

2. $\mathrm{ROS}$的缺陷

   在$\mathrm{Apollo}3.5$发布前，$\mathrm{Apollo}$一直以$\mathrm{ROS}$为操作系统框架，但$\mathrm{ROS}$在自动驾驶的实际应用中暴露出一些无法解决的缺陷：

   • $\mathrm{ROS}$作为一个通用框架并未与自动驾驶现有的硬件，$\mathrm{OS}$等底层进行定制，有着较大的优化空间；
   • $\mathrm{ROS}$软件包既繁且重，学习和使用成本较高；部署统一的开发、运行环境较为麻烦；
   • 基于$\mathrm{ROS}$的整体系统分散为大量的独立进程，集成度较低；系统的$\mathrm{CPU}、\mathrm{GPU}$及内存等资源全部由各模块抢占，缺乏全局的分配调度系统；

3. $\mathrm{Cyber}\mathrm{RT}$计算框架

   $\mathrm{Cyber}\mathrm{RT}$是全球首个面向自动驾驶的高性能开源计算框架，可显著提升研发效率，自适应设计易于部署，框架高效可靠，可以帮助客户实现更快速度的搭载与落地；$\mathrm{Cyber}\mathrm{RT}$主要特点：

   • 轻量级、平台无关。基于自动驾驶业务现状深度定制，精简可靠；框架与底层实现剥离，平台可移植性强；
   • 采用$\mathrm{DAG}$拓扑框架件，可使上层模块灵活配置。模块可定义独立的算法，及输入、输出、异常处理等；可根据配置文件动态生成计算流程图并执行；
   • 封装了简单高效的通信组件，可以满足不同驾驶场景下的信息传输需求；
   • 任务的全局调度机制。通过计算流程图的数据依赖，进行任务的全局调度；
   • 细粒度的资源隔离。根据功能对系统各组件进行计算、存储、$I/O$等资源的预分配，运行时根据系统情况实时调整，兼顾稳定与高效；

2.2 Cyber RT拓扑组件概述

• 在图论中，如果一个有向图从任意顶点出发无法经过若干条边回到该点，则这个图是一个有向无环图($\mathrm{DAG}$图)；

• 有向无环图拓扑关系如下图所示：
  

• "有向"指的是消息传递过程中任意一条边有方向，若该边可双向传输，则为无向；"无环"指的是任务的通信过程中不存在环路，即消息从任务$A$点出发经$B$点经$C$点，不可再回到$A$点，否则为有环图；

• 有向无环图的特点是去中心化，在一个分布有众多节点的系统中，每个节点都具有高度自治的特征；节点之间彼此可以自由连接，避免了中心故障将影响整个系统的缺陷，从而形成扁平化、更平等的系统拓扑结构；

• 有向无环图的另一个特点是可以有多个出度，因此可以同时处理多个出度连接的节点；这样的特性可以加快处理任务的速度，且使其拓展性得到提高；

• 利用$\mathrm{DAG}$拓扑框架可将计算任务分成若干个子任务，每个子任务独立完成各自计算，并形成输入输出依赖关系；

• 在$\mathrm{Cyber}\mathrm{RT}$框架中，最小的任务处理单元就是各类算法，因此每个算法可以独立编写；同时，$\mathrm{Cyber}\mathrm{RT}$为各个算法定义了一套简单的描述语言规则，即$\mathrm{DAG}$文件；

• 应用模块算法只需通过配置$\mathrm{DAG}$文件，来定义算法的向上依赖、向下输出和算法的具体实现逻辑即可；

• $\mathrm{Cyber}\mathrm{RT}$调度器根据全局配置文件，加载对应应用模块算法及处理逻辑，生成通信拓扑图和处理任务集，然后根据任务的输入、输出及执行时间的先后依赖关系，将不同任务调度到不同的容器中执行；

• 多进程模式下，所有模块的算法根据模块内部的$\mathrm{DAG}$拓扑图组装成进程，算法模块进行进程间通信；单进程模式下，所有模块算法根据模块$\mathrm{DAG}$拓扑图进行总体挂接，算法模块进行进程内通信；

• 在自动驾驶算法实际应用中，核心算法包括点云预处理算法、障碍物检测算法、点云定位算法、决策控制算法等；这些算法在$\mathrm{Cyber}\mathrm{RT}$框架下相互解耦，被封装成独立可拆分的计算任务单元，任务单元间彼此相互独立，只是通过输入和输出完成数据链路连接，如下图所示：
  

• 利用$\mathrm{Cyber}\mathrm{RT}$拓扑框架可以使各个算法间耦合降至最小，应用模块可以实时调整某一算法策略模块而不影响整体算法链路的正常执行，实现动态可"插拔"；如：点云定位算法存在$\mathrm{CPU}$版本和$\mathrm{GPU}$版本，应用可根据实际硬件负载情况选择合适的算法版本"插入"自动驾驶原有整体算法链路中，无须做其他代码上的变更；

2.3 Cyber RT计算框架通信组件概述

1. 基本概念

   • $\mathrm{Cyber}\mathrm{RT}$中定义并封装好了一系列计算框架通信组件，不仅通信效率高，使用简单，还可以满足不同场景不同功能的通信要求；

   • 节点$(\mathrm{Node})$

     在$\mathrm{Cyber}\mathrm{RT}$框架中，节点是最基础的单元，每个节点都有各自独立的算法程序，如：点云预处理算法、障碍物检测算法等；能够基于信道、服务等功能与其他节点进行通信，各个节点间进行通信即可形成拓扑关系，并完成指定任务；

     通过使用节点，可将代码和功能解耦，提高了系统容错能力和可维护性，使系统简化；同时，节点允许了$\mathrm{Cyber}\mathrm{RT}$能够布置在任意多个机器上并同时运行；

   • 信道$(\mathrm{Channel})$

     若需要完成节点间的通信，则需要建立一条信息传输通道，在$\mathrm{Cyber}\mathrm{RT}$中称为信道；节点可以将消息发送进入某一指定的信道中，若有其他节点定义接口接收此信道的消息，则可完成消息收发过程；若没有，则消息也依然存在于信道中；

   • 服务$(\mathrm{Service})$

     服务是$\mathrm{Cyber}\mathrm{RT}$中的另一种通信方式，与信道通信相同，基于服务的通信也需要有消息的收发节点；但服务需要两个节点间完成请求或应答才可完成通信；

2. 基于信道的通信

   若需要完成基于信道的通信，先需要定义消息的发送方$(\mathrm{Writer})$和接收方$(\mathrm{Reader})$，以保证消息可以通过$\mathrm{Writer}$和$\mathrm{Reader}$共同指定的$\mathrm{Channel}$，从一个节点传输到另一个节点。

   此类通信方式的特点：

   • 同一个节点可以同时发送多条消息，也可以同时接收多条消息，即可以同时定义多个$\mathrm{Writer}$和$\mathrm{Reader}$；
   • 基于信道的通信是一种单向通信，消息只能由$\mathrm{Writer}$传输到$\mathrm{Reader}$，而不能反向传输；
   • 信道中的消息不需要实时应答，即当某一条消息通过$\mathrm{Writer}$送入$\mathrm{Channel}$后，可以没有$\mathrm{Reader}$来读取消息；当某一个$\mathrm{Reader}$想要读取$\mathrm{Channel}$中的信息时，$\mathrm{Channel}$中也许没有消息输入；

3. 基于服务的通信

   • $\mathrm{Service}$是节点间通信的另一种方式，不同于$\mathrm{Channel}$的通信方式，$\mathrm{Service}$的一个节点如果想要获取信息，需要给另一个节点发送请求，以此来获取响应，这就完成了节点间的双向通信；
   • 在$\mathrm{Service}$中，发送请求的一方为客户端$(\mathrm{Client})$，接收请求的一端为服务端$(\mathrm{Server})$；

4. 三种通信模型

   • 根据上层模块所处的进程，可以将模块间的关系划分为同一进程内、同主机进程间和跨主机3种；
   • 同一进程内通信：指在同一个主机的同一进程节点间的相互通信，对于进程内的数据，直接传递消息对象的指针；这样可以避免消息数据复制的开销，尤其是一些较大的消息，如：图像和点云等；
   • 同主机进程间通信：指在同一个主机下，不同进程间节点的传播或交换信息；对于跨进程的数据，利用共享内存传输，这样可以减少传输中的数据复制，提升传输效率，还能有效满足一对多的传输场景；共享内存通信可分为3个主要步骤：写入 数据、发出可读通知、读取数据；
   • 跨主机的数据利用$\mathrm{socket}$传输。目前，跨主机通信采用了第三方的开源库$\mathrm{Fast}\mathrm{RTPS}$，即$\mathrm{Real}\mathrm{Time}\mathrm{Publish}\mathrm{Subscribe}$，实时发布订阅协议；$\mathrm{RTPS}$是$\mathrm{DDS}$标准中的通信协议，$\mathrm{Fast}\mathrm{RTPS}$是支持$\mathrm{RTPS}$协议版本的一个订阅发布消息的组件，具有高性能，实时性高，多平台支持等优点；

2.4 Cyber RT计算框架调度组件概述

• $\mathrm{ROS}$通信框架下，各算法模块作为单独进程各自开发，存在资源相互抢占的风险，且工程与算法深度耦合，每个算法模块定义为一个进程不方便总体协调和调度，模块内部包含大量的工程冗余建设，同时由于算法和工程耦合过于紧密，算法策略拆分以进行并行计算受到很大程度的制约；
• $\mathrm{Cyber}\mathrm{RT}$将自动驾驶所有算法处理任务封装成一个最小计算单元，模块策略开发只需要定义算法及算法的输入输出，模块间的数据通信、服务调用、数据接口等放到优先级队列中由框架进行全局统一管理调度；
• $\mathrm{Cyber}\mathrm{RT}$调度系统的调度策略主要分为：$\mathrm{classic}$(经典)策略和$\mathrm{choreography}$(编排)策略，根据$\mathrm{DAG}$文件描述生成自动驾驶模块算法拓扑链路，通过读取算法上下游依赖，确定算法执行先后顺序，然后分配执行单元进行运算；