自动驾驶间件水杉和Apollo CyberRT性能对比

实验使用笔记本处理器：Intel® Core™ i7-4710HQ CPU @ 2.50GHz × 8，内大小8GB，操作系统Ubuntu22.04，分别在各自的docker容器内运行，都使用各自的默认配置不做调优，比较不同通信消息大小下的进程间平均通信时延。实验每次重启电脑后要么运行一个Apollo docker容器，要么运行水杉docker容器，除了打开一个终端和容器外，不打开其他如浏览器等程序。

1：Apollo CyberRT代码版本：master分支，commit id：455090bb85807df9a2a1d47632ae9dc8a09f075e

其性能测试程序是CyberRT的talke和listener程序，使用默认配置，只修改通信使用的examples.proto。

具体将examples.proto中的Chatter消息改为如下：

message Chatter {

required int32 x = 1;

required int32 y = 2;

required int32 z = 3;

required int32 speed = 4；

required uint64 timestamp = 5;

required int32 acc = 6;

required bytes content = 7;

};

cyberRT的发送端talker程序每次发送消息时，先填充1、2、3、4、6、7域，最后填充5域（即timestamp字段），然后发送到cyberRT的通道中；每次实验时向content域中填充不同大小的数据，总体上Chatter消息总大小不超过指定的大小。talker发送Chatter消息10万条。

cyberRT的接收端listener，在接收消息的回调函数中，使用cyberRT的Time组件获取当前时间，然后减去接收到消息中timestamp，作为通信此次通信时延。

2：水杉中间件发送端和接收端是水杉中间件简单的talker、listener程序，两个进程，talker发送TestMsg消息10万条，使用与CyberRT类似的消息格式，具体消息如下：

const int TestMsgTotalSize = 1024；

struct TestMsg {

int32_t x;

int32_t y;

int32_t z;

int32_t speed;

uint64_t timestamp;

int32_t acc;

int32_t msgLen;

char msg[TestMsgTotalSize - 64];

};

每次实验时调整TestMsgTotalSize 的大小，即调整msg域的容量，以保证消息总大小为指定的大小。数据填充和通信时延计算方式与CyberRT的相同。

3：实验结果对比

1KB消息平均时延（单位纳秒）：

CyberRT中间件约1KB消息平均时延

水杉中间件1KB消息平均时延

---

2KB平均时延（单位纳秒）

CyberRT中间件约2KB消息平均时延

水杉中间件2KB消息平均时延

---

4KB平均时延（单位纳秒）

CyberRT中间件约4KB消息平均时延

水杉中间件4KB消息平均时延

---

8KB平均时延（单位纳秒）

CyberRT中间件约8KB消息平均时延

水杉中间件8KB消息平均时延

---

1MB平均时延（单位纳秒）

CyberRT中间件约1MB消息平均时延

水杉中间件1MB消息平均时延

---

2MB平均时延（单位纳秒）

CyberRT中间件约2MB消息平均时延

水杉中间件2MB消息平均时延

---

4MB消息平均时延（单位纳秒）

CyberRT中间件约4MB消息平均时延

 水杉中间件4MB消息平均时延

---

8MB消息平均时延（单位纳秒）

CyberRT中间件约8MB消息平均时延

水杉中间件8MB消息平均时延

4：结论

通过以上实验可以发现，水杉中间件的进程间通信性能，在不同消息大小下通信时延一直保持稳定，处于微秒级别，且与通信消息大小无关。在自动驾驶领域，水杉中间件可以大幅减少自动驾驶系统模块间的通信时延，为模块留有更多的计算时间，为自动驾驶系统在不增加硬件成本的情况下使用更复杂的模块算法提供了可能性；也可以在不改变自动驾驶系统模块算法和硬件的情况下，提升自动驾驶系统的计算控制频率，增加自动驾驶系统的安全性可靠性。

这篇好文章是转载于：学新通技术网