自动驾驶算法模块通信简谈

提到自动驾驶，大家通常想到的是各个模块的算法，其实还有一个很重要的内容是各算法模块之间的通信，比如上游感知模块的结果以什么数据类型发出来，下游规控模块如何去转换和消费等。主要有用到两种通信方式：DDS IDL和Google Protobuff。

1. DDS（data distribution service数据分发服务）

目前工程中商用较多的是RTI公司的DDS数据服务，当然也有公司会开发自用的系统。DDS的特点：微秒级别的延迟；高安全性能；高可靠性，数十亿美元产品线上操作的证明。

DDS通信基本概念：以数据为中心的发布-订阅模型，为所有的分布式节点之间创建了一个虚拟共享的全局数据空间，网络中的数据对象用Topic作为标识。

QoS：quality of service策略，可以理解为一个缓存队列。比如上游频率是20HZ，下游频率10HZ，对于下游每一帧运行，上游会发两帧数据，实际下游只会用最新的一帧数据，如果缓存数大于1的话，次新的数据先放到缓存队列存起来，备用。

2. google protobuff，下面这篇知乎文章讲解的很到位

Protobuf通信协议详解：代码演示、详细原理介绍等 - 知乎

举个例子：

以Planning模块为例，需要订阅SensorFusion模块的消息，通过dds通信。

首先，会定义好Topic名字，类型和QoS。name和type是一一对应的，相当于key与value的关系，不能一个name对应多个type。

name: SensorFusionTopic
type: xx::xx::xx::SensorFusionMsg
qos: default

其次，需要定义消息结构体的具体内容（实际会比这里的内容丰富很多），SF和Planning之间的通信本质上就是去传递这个message里面的内容。支持大多数类型和自定义类型，包括boolen，uint，float ，double，string，octet，enum，sequence（相当于vector）。

Struct SensorFusionMsg {
  DynamicObjectList dynamic_object_list;
  StaticObjectList static_object_list;
};

最后就是dds_convert_to_proto了，这个也比较好理解，一一对应就好了，格式不能有冲突。注意，如果dds里是optional的数据类型，转换的时候需要判断is_set是否为true