Apollo：实时通信架构CyberRT入门， my writer

Apollo 最初用的中间件是 ROS（机器人操作系统），在 v3.0 之前用的都是基于 ROS 框架进行开发。概括来说，ROS 系统主要包含三方面：

第一是通信系统，ROS 是个分布式的松耦合系统，算法模块是以独立的进程形式存在的，也就是我们常说的 Node。ROS 基于 Socket 实现了pub/sub 的通信方式，不同的算法节点（node）之间通过 pub/sub 的发送/接收消息。
第二是 Framework&Tools （框架和工具），开发者可以基于 ROS 提供的 Client Library 和通信层，方便的收发消息。开发者只需要关注消息处理相关的算法，而至于算法何时被调用，全部由框架来处理。
第三是生态系统，从社区内，开发者可以很方便地寻找到很多现成的「传感器驱动」和「算法实现」等进行参考。

随着自动驾驶的发展，不少开发者，包括 Apollo 平台，把 ROS 应用于自动驾驶系统，毕竟自动驾驶汽车也相当于一个大的机器人。但是我们在实践中也遇到了很多挑战：

首先，ROS 中的算法模块是以独立的进程形式存在的，那么这些进程之间应该以什么样的顺序去执行？实际上，Linux 本身是一个通用系统，内核中的调度器对上面的算法业务逻辑并不清楚，它只是在尽量满足公平的情况下让大家都得到调度。所以，ROS Node 运行顺序并无任何逻辑。但本质上自动驾驶是一个专用系统，任务应该按照一定的业务逻辑执行。那么是在 ROS 层加一个 Node,由其来同步各个算法任务的运行，还是在Linux 内核中实现新的调度策略，使其结合算法业务逻辑进行调度？前者的开销，后者的迁移性，都是需要思考的问题。
其次，ROS 是一个分布式的系统。既然是分布式，就要有通信的开销。即使在同一个物理节点上，依然存在着通信的开销。所以 Apollo 前期曾经使用共享内存去降低 ROS 原生的基于 Socket 通信的开销。ROS 2 也在使用 DDS 解决通信方面的实时性。ROS 也支持 Nodelet 模式，这可以去掉进程间通信的开销，但是调度的挑战依然存在。
第三，除了调度的不确定性，ROS 系统中还存在其他很多不确定的地方，比如内存的动态申请。

随着 Apollo 的发展，对最高水平的稳健性和性能的需求， Apollo Cyber RT 应运而生，它满足了一个面向商业化的自动驾驶解决方案的基础需求。

CyberRT是一个开源，高性能的运行行框架，专为自动驾驶场景设计。针对自动驾驶的高并发、低延迟、高吞吐量进行了大幅优化。
CyberRT是百度推出的替代ROS的消息中间件，自动驾驶中的各个模块通过cyber进行消息订阅和发布，同时cyber还提供了任务调度、录制bag包等功能。Apollo提供了 CyberRT作为中间体，对计算任务和通信进行优化
CyberRT处于底层的实时操作系统和算法模块之间，能够在保证高吞吐的情况下，又能够低延迟的实时响应上层任务，并保证整个系统确认性的运转
CyberRT的核心理念是基于组件，组件有预先设定的输入输出。
- 实际上，每个组件都是一个专用的算法模块，框架可以根据所有预定义的组件生成有向无环图 (DAG)。
- 所有的这些组件都是基于cyberRT提供的调度程序mainboard加载运行。
在运行时，框架把融合好的传感器数据和预定义的组件打包在一起形成用户级轻量任务，之后，框架的调度器可以根据资源可用性和任务优先级来派发这些任务。

总结：