你信任你的激光雷达吗？

专栏作者 / Sentinels

首发 / 汽车之心（微信 ID：Auto-Bit）

声明：本文不是官方文档，亦不是某种形式的断言或结论，本文仅仅是技术讨论性质的文章，无论是否用了确定性的语气，作者都不保证内容的准确性和完整性，亦不明示或暗示此文章不是在胡说八道。（事实上，作者过去常常胡说八道并乐此不彼）。因此，所有因采用本文章涉及的方法、数据或其他任何信息，所造成的直接或间接损害，包括但不限于生命和财产损失，作者、撰写团队和平台概不负责。

这一篇本来是想讲几何光学，因为我们的校准参数，还留了一个尾巴。

几何光学就是个怪物，复杂到令人绝望，幸好这两个参数用初中数学就可以说得通，不过我遇到的问题是画图，我既没有 Zemax，也没有 LightTools 这种天价软件（有我也不会用），只能手绘。

汽车之心从老板到员工，他们的大脑前额叶皮质，仿佛都被睾酮溶液浸泡过，工作起来没日没夜，他们昨天深夜打电话警告我，我的文章必须按时交，否则我就看不到明天的太阳了。

惊恐之下，我临时决定，把画了一半的光路图放一放，暂时换个主题，一个更加糟糕的主题：无人车的以太网络交换问题。

睾酮结构式

睾酮分泌丰富的人，比如汽车之心的 CEO，他大概长这个样子。

睾酮分泌不足的人，比如其他公司的男 CEO 们，他们大概长这个样子。

你是说肌肉？No，No，No，睾酮跟肌肉一点关系都没有，我是说头发，睾酮只会让人掉头发。

当前在无人驾驶汽车上：

二层基于以太网接口承载的传感器并不多，除了汽车上本来就有的传感器，后装的要么是 CAN 口，要么是 USB 或者 232，485，UART 等串口，只有大带宽的需求时，比如工控机、4/5G 模块，监控系统，它们的通讯一般使用商用以太网口。

三层挂在 IP 上的通讯接口就更少了。

当然还有其他很多莫名其妙的接口。看着这些七国八制，五光十色的接口，你常常会怀疑，无人驾驶系统的真正商用，真的能在 150 年内实现么？

主机厂们都有一个远大的抱负，面对未来智能汽车，就是把车内能统一的东西，都统一到车载以太网上去，至少激光雷达、摄像头等大流量的玩意应该这样。

车载以太网真的是好处多多，实时性秒杀让人提心吊胆的商用以太网，CSMA/CD 光听名字就觉得不靠谱。

而且，车载以太网有优秀的 EMC，还带全局时钟同步这些特技，要是所有的重要传感器和计算平台，都能使用车载以太网进行统一交换，那真是太完美了……

不过要我说，回到现实吧，亲们～摸摸你们手里能买到的激光雷达，摄像头，工控机，或者毫米波，不管哪个牌子的，告诉我，车载以太网，你在哪里啊？

现实总是很残酷的，你的无人车下个月就要参展了，到头来，它的高带宽通讯部分，大概率还得用这些上古时期的玩意：

上图布线真的很整洁美观，不是么？

所以，当我在一辆无人车里，发现一台 H3C 或者 Cisco 的交换机，或者发现有人用博通的芯片，焊一个综合网关的板子连接一堆传感器，并对外自豪的宣称，这是他们自主研发的，拥有完全知识产权的「核心*GW」，我的内心充满了尊敬，这是一群多么务实的理想主义者啊！

但是，既然是商用以太网，你就绕不开三大传统网络困境「延抖丢」：

延时（delay）、抖动（jitter）和丢包（packet loss），一旦延抖丢，再高级的算法，再牛*的传感器，统统会抓瞎。

所以本文的主旨，围绕着这三个问题展开。

这个延抖丢的效果真是相当的感人。

车上的环境，跟普通商用以太网截然不同，商用以太网那一套，很多并不适用车上，基于此，我们略加提炼，得到如下几个使用原则：

1、使用优秀的，经过历史检验的商用硬件：

商用以太网非常成熟，所以，对于交换机而言，请购买商用的稳定型号，如 Cisco，H3C，Huawei 之类，请立刻忽略你们家里用的那种路由器。

商用的一般长这样：

家用的一般长这样：

家用的路由器，显然是镇不住这辆车的：

2、No Broadcast，Some Multicast, Always Unicast

有些传感器，会把自己的目标地址定义为四个 255，这是一个典型的广播地址，任何时候，都不要广播。

因为以太网交换机工作在二层，它有个非常糟糕的特性，就是不隔离广播，收到广播包后，直接对全网所有端口泛洪。

其他传感器，如果也连接到这个交换机上，这个传感器就杯具了，它稚嫩的小网卡多半会挂掉。因为接收了太多本不属于它自己的东西。

还需要注意的一点就是，广播分二层广播和三层广播，一般情况下，修改广播至组播或单播，只需要改三层 IP 即可。

但是，传感器毕竟不是电脑，有的改了 IP，二层依然改不掉，这就变成了一个尴尬的假单播。

这真的很尴尬，究其原因，可能是传感器厂家的 FPGA 在实现以太网络功能时，并未按照 ITU-T 的 RFC 严格定义。

所以，它依然会冲掉其他传感器。

这个问题的解决，要依赖网络交换机的广播隔离，但是二层交换机广播可以隔离么？

当然不可以。

所以，你整个网络，要提到三层去，方法多种多样，做 VLAN 或者起单臂路由。所以你一看到广播，想都不想，直接毙掉；

组播是一个部分广播的情形，配置相对也比较复杂，总的来说它适用于多个接收者，而单播，适合一个接收者。

大部分情况下，我们都推荐使用单播，这使得带宽占用最小。

但有人会在整个无人车感知系统上，再挂一个监控组件，这就要求传感器发出的消息，需要 2 个以上的接收者同时接收，如果不让用广播，那么，组播就是唯一的选择。

组播一般的交换机都有默认配置，如果你只有一套组播流量，那无需配置，即插即用。

但多个组播流量，那可能也需要进行配置，无人车应用相对还是比较简单，但可能需要对 Ubuntu 的内核中统一组管理协议（IGMP）版本，这里就不展开了。

另外，无人车常常还需要安装一个 4/5G 网关或者 WiFi 热点，用于对外界的通讯，最通常的做法，是工控机另外安装网卡，单独处理这个通道的数据。

然而，也有一部分人直接复用交换网络，这真是个糟糕的主意。

不用广播，用单播，这就可以了么？

差得远呢，你还得有个重要的思想，这个思想必须贯穿始终，这就是 QoS。

3、不要偷懒，尽量部署 QoS

商用以太网为什么在无人车上感觉很挫？

就是因为它的哲学——「尽力而为」，绝大多数流量都是发出去就行，爱谁谁。

为了保证可靠性，不得以在四层搞了一个重传机制（TCP），收不到，就反复要求重传，但这样可靠性上去了，实时性又降下来了。

传感器但凡使用以太网，为了保证实时性，数据传输就绝无可能使用 TCP，一定要用面向无连接的 UDP，这时，数据是否可靠，整个网络是否有拥塞等「延抖丢」问题，一定不在传感器厂商的考虑之列，这些，就需要无人车自身的网络软硬件加以保证。

提升交换和传输质量的一个最重要的方法，就是部署 QoS。QoS 在各个交换设备上设置都不太一样，实现的子功能也很复杂，好在无人车的网络很简单，我们可以用到如下几个简单功能：

（1）通信速率管理。

对于非重要节点发来的异常流量进行整形和丢弃，防止其对重要流量产生冲击，比如，永远限制监控系统的输出流量至一合理水平；

（2）资源分配。

改变「尽力而为」的 FIFO 粗糙机制，改成各种队列（Queue），队列的种类千奇百怪，根据不同的流量，进入不同的队列，最简单的队列机制是 PQ（Priority Queue），我们可以把重要传感器，如激光雷达的数据，调度进最高优先级队列，无论网络是否拥塞，激光雷达的数据，总是优先转发。

（3）拥塞避免和分组丢弃策略。

在各个 Queue 中，如果丢弃拥塞的数据包，比如随机尾丢弃之类；

刚开始，你的 QoS 也许布置的不太好，这个是个反复磨合的过程，常常有经验因素在里面，部署 QoS 需要反复调试，最终会接近一个比较理想的状态。

4、Socket 写法有讲究

在工控机上，socket 存在大量参数，要根据发送端和自身条件进行调整，延抖丢有可能发生在接收系统上，而且常常是因为 Socket 写得不规范造成的。

在上层看，你会以为是传感器质量不好。

比如接收数据前的轮询，防止接收端卡死的小技巧：

比如 buf 的大小等，buf 需要根据自身的设备情况进行平衡选择，但是如果选择太小，则在操作系统上层繁忙时，buf 可能被填满，进而导致丢包发生。

关于 Socket，没有什么书，比这套圣经更管用了：

此书分卷一卷二卷三，作者 W.Richard Stevens，一个生于赞比亚，成长于南非的白人。生的神秘，死得更神秘的一位大神。你要的答案，就在里面。

对了，如果你希望更多了解 QoS，这本书也值得一读，当然，你需要知道如何操控一般商用以太网的路由交换设备。

是的，「得救之道, 就在其中」(Salvation lies within)。