自动驾驶——基础架构

基础架构

下图为自动驾驶的基础架构图: 下面根据各个模块的内容,逐个分析下有哪些应用场景,为什么我们需要这些系统。

存储

首先我们看下存储,在自动驾驶中如何应用,有哪些应用场景?

    文件系统 数据库 数据meta

自动驾驶每天会产生大量的数据,之所以有这么多数据是因为无人车配置了多种传感器,这些传感器包括摄像头,激光雷达,GPS等。每秒钟会生产大量的数据,30分钟的数据量就有几百G,如果是一天的时间一辆车可能就产生几T的数据。由于数据量太大,我们有3种处理方式,第一种,缓存最近2分钟的数据,其他的数据处理完之后丢弃,这也是无人车正常情况下的做法,但是这种场景只适合正常运行的无人车,如果我的需求是采集地图,或者收集训练数据,那么就不太合适了。为了解决上述问题,后面的2种方法就是考虑如何把数据保存下来。第二种,保存到硬盘,之后再回传到数据中心,这种方法是目前普遍的方法,由于磁盘读写速率要求太大,普通的机械硬盘根本满足不了需求,只能采用SSD硬盘,1T的SSD硬盘1200多块钱,还是很烧钱的。最后一种就是通过网络传输,目前4G的网速肯定是支持不了这么大数据的,5G目前看是有可能,但也禁不起这么大流量,合理的做法是小数据通过网络传输,大数据落盘,把车的位置信息通过网络实时回传到数据中心,实现所有无人车的管理,其他的信息落到硬盘,记录运行情况。、

介绍了自动驾驶的数据生产场景,那么再接下来看我们需要什么样的存储,首先我们需要一个分布式的文件系统,大数据时代已经被广泛证明了分布式文件系统的好处,最主要的好处就是容量可以水平扩展,而且可靠性高。这样每天产生的几十T的数据都可以通过分布式文件系统保存下来。

接下来就是数据库的要求,这里主要分析下自动驾驶场景和传统互联网的区别,

    互联网的数据生产方式是几亿用户,每人产生几条数据,合起来几个T 而无人车是一辆车,每天产生几T数据

这里的差别很大。互联网中针对几亿用户,一般是选择key-value结构的数据库,例如Hbase。但是如果把hbase照搬到自动驾驶的场景就很别扭,因为hbase的单条数据最好是10M以内,否则会影响读写性能。这时候有人说我们可以把数据做拆分,把几个T的数据,根据地理位置信息或者时间做拆分,把地理位置信息或者时间作为key,当时的数据作为value,这样就可以实现一条数据很小,拆分成很多key-value的小数据了。

互联网场景下是拿用户的ID作为key,如果同时频繁的命中相邻的ID,被称为单点问题,即容量上不去,每次访问都到一台机器上面去了。而按照地理位置或者时间的方式刚好又导致了这个问题,因为数据读取的时候就是按照地理位置顺序读取的,每次都命中到一台机器,导致整个系统的容量上不去。如果我们把key做哈希散列,把地理位置信息打散,这样容量是提高上去了。而这恰恰又和我们的应用场景有冲突,我们需要的不是高并发读取,即同时几十万的并发,而是一个用户连续读取大量数据,这样反而是单台读取的性能最高,因为会对数据做预取。

另外有一点我认为很重要,就是元数据,元数据是详细数据的数据,比如采集的时间,地点,天气,采集的人,当时的情况等信息,对数据做分类管理。类似你到了一个图书馆,图书馆的书都是按照类目分门别类,然后你找书的时候直接按照索引来找就行了,试想一下,如果你去了一个图书馆,没有分类,书是按照出版时间来放置的,那么让你找一本烹饪类的但是不知道出版时间的书,试问你如何找到呢?由于自动驾驶的数据极其不具备可视化,就是一大堆二进制文件,没有什么可视化的信息。而且自动驾驶的场景多样,路况,时间,天气都不一样,数据量巨大,版本更新快。如果不分门别类,做好信息的meta,那么后面假如你需要找所有下雨天的数据来进行测试,你如何去找呢?还得每个包确认下是否下雨?另一种应用场景就是测试数据的管理,每天测试的大量数据,什么时候因为什么原因接管的,这在后面回归测试和仿真中很关键,如果没有这些meta信息,假如我需要查找所有红绿灯引起的问题,来回归测试,我怎么怎么去查找呢?数据meta对自动驾驶的数据管理尤为关键,甚至目前我觉得自动驾驶只需要数据meta和文件系统就可以了。

计算

有了数据之后,需要计算才能得到结果,这就要用到计算平台。计算可以分为2块,一块是离线计算,一块是在线计算。

离线计算就是数据的处理,这一块应该是可以完全借鉴互联网的分布式计算平台,因为无人车收集的数据需要分类,清洗,以及一些处理。一部分的应用场景是高精度地图的制作,需要把采集到的地理位置信息离线计算生成高精度地图;另一部分的应用场景是离线计算好一些数据给到在线,利用空间换时间。比如planning模块reference line的生成;routing线路事先计算保存;感知的ROI区域;定位的点云数据处理等。主要的需求是能够更快的处理数据,这一部分用spark就可以解决了。

在线计算主要是无人车的实时计算,感知车当前的环境,控制车辆前进。这一部分目前主要是一些异构计算,通用的计算放在CPU上,神经网络的计算放在GPU上,控制部分有单独拿处理器做的,这一块可以参考下博世等厂家。目前看好的趋势是拿FPGA做一些定制的算法开发,好处是比纯软件快,而且灵活,并且FPGA可以和硬件传感器深度定制。比如4路camera,之前遇到一个问题是关于4个camera如何保持同步,即每个摄像头拍照的时间戳如何同步,看起来很难处理,你怎么保证它们同时拍摄呢,其实摄像头有一个trigger功能,即每次拍照类似按下快门,如果每次拍照的时候同时按下4个摄像头的快门,这样就能保证摄像头的同步了,高级点的摄像头都带有这个功能,可以预见FPGA和硬件算法的融合,会在在线计算中扮演越来越重要的角色。在线计算还需要低时延。

基础服务

有了计算和存储,我们可以搭建基础的自动驾驶服务,但是如果要提供更多的服务,我们还需要以下几个部分。

    RPC 消息队列 配置中心 容器

基本就是互联网服务的编排,部署和运维了。主要的应用场景比如打车服务,需要用到微服务架构,需要消息队列,需要配置中心,需要容器编排等等等、

业务场景

上面主要是分享了一下基础的建设,那么如何和业务场景联系呢,我们接下来看目前的一些业务场景:

    地图服务 - 主要是提供高精度地图服务。 人机交互 - 主要是人和车如何交互,如何知道车当前的状态,所处的环境等。比如坐车的时候可以通过界面知道车当前的状态,自己所处的位置,有没有异常等。不仅仅应用在乘客,还可以应用在内部测试和研发。这一部分我觉得主要是夸平台,免得二次开发,目前来看大部分的公司采用的都是web服务。 车辆管理 - 类似现在的美团外卖,实时知道外卖员的位置和派单信息,用算法来动态调度,无人车还需要多一个功能就是实时监控无人车的健康状态,可以理解为监控满大街在跑的服务器? 数据采集 - 主要是针对测试和采集地图的场景,需要一套全自动的采集流程,并提供可视化的交互,如果全部手工完成工作量太大了。 测试平台 - 主要是针对无人车的各项测试,包括硬件和软件,这涉及到各个模块,我觉得主要是流程的维护和测试项的定义,保证质量。 仿真平台,仿真是重点之一,在版本发布之前,都需要在仿真平台测试,目前宣称的测试里程是30W公里,这一块肯定用到了分布式计算,否则没法实现。另外我觉得这个流程也挺有意义,在无人车路测之前进行仿真,可以减少故障,类似发布之前的集成测试。由于不需要真车,可以跑大量的测试,对工程化是很重要的一环。关于仿真还有另外的用途就是复现场景,比如一次撞车或者接管事故,现场不可能再去复现,成本太高,而通过仿真去模拟复现这些问题就变得容易多了,另外一个应用是训练模型,对于需要大量数据的训练,仿真可以虚拟和合成大量的数据,提高效率。关于仿真可以参考。
经验分享 程序员 微信小程序 职场和发展