你信任你的激光雷达吗?(第3话) | 行家说

Sentinel 2020-03-09 08:07:00

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

相关阅读:

你信任你的激光雷达吗?(第1话)| 行家说

你信任你的激光雷达吗?(第2话) | 行家说

几何光学就是个怪物,复杂到令人绝望,幸好这两个参数用初中数学就可以说得通,不过我遇到的问题是画图,我既没有 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)。

本文为汽车之心原创文章,作者:Sentinel,如需转载,请联系授权。违规转载法律必究。

(0)
(0)
参与评论:

    汽车之心

    • 累计发布 1232 篇文章
    • 关注我们:扫描二维码,关注微信公众号
    登录或注册
    注册、登录代表你已阅读并同意《用户协议》
    My title page contents