Thinking about Autonomous Driving: Infrastructure

image

Picture from the Internet



Participated in the offline sharing of Xiaoma Zhixing at the weekend and benefited a lot. I am very envious of Beijing's environment. Most of the offline are in Beijing, and it is rare that there are in Shenzhen. Although Shenzhen is hailed as the city with the most innovative value, it is heinous that there are few technical exchanges.

Based on the content shared this time, I will introduce some of my thoughts in turn.

The first thing to share is the unmanned driving infrastructure.If you say that the autopilot showed muscles before, it was through the demo to demonstrate the real road conditions in the rainy day to go through the tunnel. Then it will gradually transform into a show infrastructure. I feel that if an autonomous driving company does not pay enough attention to the infrastructure, it will basically fall out of the first echelon. So what infrastructure do we need?

image

According to the content of each module, we will analyze the application scenarios one by one and why we need these systems.

storage

First, let's look at storage, how is it applied in autonomous driving, and what are the application scenarios?

  • File system

  • database

  • Data meta

Autonomous driving generates a large amount of data every day. The reason why there is so much data is that unmanned vehicles are equipped with a variety of sensors, including cameras, lidar, GPS and so on. A large amount of data is produced every second, and the amount of data in 30 minutes is hundreds of gigabytes. If it is a day, a car may produce several terabytes of data. Due to the large amount of data, we have three processing methods. The first one is to cache the data of the last 2 minutes, and discard the other data after processing. This is also the normal practice of unmanned vehicles, but this scenario is only suitable for normal For unmanned vehicles in operation, if my requirement is to collect maps or collect training data, then it is not suitable. In order to solve the above problems, the latter two methods are to consider how to save the data. The second method is to save to the hard disk and then transfer it back to the data center. This method is currently a common method. Because the disk read and write speed requirements are too large, ordinary mechanical hard disks cannot meet the demand at all. Only SSD hard disks, 1T The SSD hard disk is more than 1200 yuan, which is still very expensive. The last one is transmission through the network. The current 4G network speed is definitely not able to support such large data. 5G is currently possible, but it cannot withstand such a large amount of data. A reasonable approach is to transmit small data through the network and place big data on the disk. , The position information of the car is transmitted back to the data center in real time through the network to realize the management of all unmanned vehicles, and other information falls to the hard disk to record the operation status.

image

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

接下来就是数据库的要求,这里主要分析下自动驾驶场景和传统互联网的区别,分享的老师也提到了,互联网的数据生产方式是几亿用户,每人产生几条数据,合起来几个T,而无人车是一辆车,每天产生几T数据,这里的差别很大。互联网中针对几亿用户,一般是选择 key-value 结构的数据库,例如 HBase。但是如果把 HBase 照搬到自动驾驶的场景就很别扭,因为 HBase 的单条数据最好是 10M 以内,否则会影响读写性能。这时候有人说我们可以把数据做拆分,把几个 T 的数据,根据地理位置信息或者时间做拆分,把地理位置信息或者时间作为 key,当时的数据作为 value,这样就可以实现一条数据很小,拆分成很多 key-value 的小数据了。我们再回过头去看下互联网的应用场景,互联网场景下是拿用户的 ID 作为 key,如果同时频繁的命中相邻的 ID,被称为单点问题,即容量上不去,每次访问都到一台机器上面去了。而按照地理位置或者时间的方式刚好又导致了这个问题,因为数据读取的时候就是按照地理位置顺序读取的,每次都命中到一台机器,导致整个系统的容量上不去。如果我们把 key 做哈希散列,把地理位置信息打散,这样容量是提高上去了。而这恰恰又和我们的应用场景有冲突,我们需要的不是高并发读取,即同时几十万的并发,而是一个用户连续读取大量数据,这样反而是单台读取的性能最高,因为会对数据做预取。所以我一度怀疑,自动驾驶的大数据需求都是伪需求,虽然说数据几 T 几 T 的,但是根本不是大数据,就是数据量大而已,根本不需要数据库,只需要文件系统就可以了。如果需要管理结构化的数据,还不如用数据库存储文件路径,而文件本身放到文件系统中。

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

当然有一个 HBase 的 Committer 加入了小马,我觉得 HBase 可能主要应用在他们的打车服务上,比如 routing 路线的记录,车和用户的信息管理等。可以看得出来小马对基础建设这块还是很重视的,也希望更多的人能够提出更多更好的基础建设。

▌计算

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

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

基础服务

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

  • RPC

  • 消息队列

  • 配置中心

  • 容器

基本就是互联网服务的编排,部署和运维了。主要的应用场景比如打车服务,需要用到微服务架构,需要消息队列,需要配置中心,需要容器编排,这些都是比较成熟的架构了,网上有大量资料,就不展开了。

下面我们主要讲下实时计算平台,也就是无人车的自动驾驶平台,听到小马说我们是自己研发的一套自动驾驶操作系统,我还是感到有点震惊的,后面仔细想想其实可以把问题转换一下,看起来也就不是那么遥不可及了,当然如果要自研一套这样的系统,肯定是需要一个稳定成熟的团队。首先看下我们需要一个什么样的自动驾驶平台呢?我们由自动驾驶需要哪些模块来进行展开。

image

下面我们看下各个模块是如何工作的,我们以激光雷达来举例子,激光雷达实时的拍摄了一帧数据,然后放到了系统内存,这时候感知和定位模块都需要处理激光雷达的数据,一个不好的方式的是把数据拷贝一份分别给感知和定位模块,因为大数据的拷贝很耗时间,影响系统性能。我们需要换一种方式,以传递内存地址的方式把数据给感知和定位模块,减少内存的拷贝,分享的老师也强调了这点。接下来我们把刚才的过程抽象一下,即来了一份激光雷达的数据之后,系统分别调用定位和感知的函数,并且把数据在内存中的地址作为参数传递进去。接着我们把模块抽象一下,我们有3个模块,系统平台需要把 A 模块的数据传递给 B 和 C 模块,这样一来,我们需要的是一个能够同时发送消息给多个模块的功能,即一个分布式的消息队列。

image

也就是说自动驾驶平台实际上实现2个功能就可以了,一个是分布式消息队列,一个是各个模块的调度执行所以我们把研发一个自动驾驶操作系统,转换为研发分布式消息队列和进程调度的问题了,这样看起来就简单了很多,因为都有现成的例子可以借鉴,回过头来看 Apollo 的 cyber 也就是实现了这2件事。最后还分享了一下研发效率提升的一些基础建设,包括代码管理,代码 review,内存泄露检测,代码扫描等,这些都代表了开发质量和生产力。

业务场景

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

  • 打车服务 - 小马主打 L4 的自动驾驶,目前主要是运营打车业务,类似一个滴滴提供的服务。

  • 地图服务 - 主要是提供高精度地图服务。

  • 人机交互 - 主要是人和车如何交互,如何知道车当前的状态,所处的环境等。比如坐车的时候可以通过界面知道车当前的状态,自己所处的位置,有没有异常等。不仅仅应用在乘客,还可以应用在内部测试和研发。这一部分我觉得主要是夸平台,免得二次开发,目前来看大部分的公司采用的都是 web 服务。

  • 车辆管理 - 类似现在的美团外卖,实时知道外卖员的位置和派单信息,用算法来动态调度,无人车还需要多一个功能就是实时监控无人车的健康状态,可以理解为监控满大街在跑的服务器?

  • 数据采集 - 主要是针对测试和采集地图的场景,需要一套全自动的采集流程,并提供可视化的交互,如果全部手工完成工作量太大了。

  • 测试平台 - 主要是针对无人车的各项测试,包括硬件和软件,这涉及到各个模块,我觉得主要是流程的维护和测试项的定义,保证质量。

  • 仿真平台,仿真是介绍的重点之一,在版本发布之前,都需要在仿真平台测试,目前宣称的测试里程是 30W 公里,这一块肯定用到了分布式计算,否则没法实现。另外我觉得这个流程也挺有意义,在无人车路测之前进行仿真,可以减少故障,类似发布之前的集成测试。由于不需要真车,可以跑大量的测试,对工程化是很重要的一环。关于仿真还有另外的用途就是复现场景,比如一次撞车或者接管事故,现场不可能再去复现,成本太高,而通过仿真去模拟复现这些问题就变得容易多了,另外一个应用是训练模型,对于需要大量数据的训练,仿真可以虚拟和合成大量的数据,提高效率。关于仿真可以参考。

image

summary

The above are some thoughts and experiences sorted out from memory based on the last preaching. You are welcome to correct any errors or omissions. In addition, we look forward to more introductions and sharing of infrastructure. Later, we will introduce the sharing and experience of hardware and perception. .

Guest introduction

Wang Fanghao, former senior software engineer at Ant Financial. Has been engaged in software-related work, and is a fan of operating systems, big data, and autonomous driving related technologies.

Friends who are interested in the author, please click on the end of the article to read the original text and communicate with the author.

——END——


About DataFun:

DataFun is positioned as the most practical data intelligence platform, mainly in the form of offline deep salons and online content organization. It is hoped that the practical experience of industry experts in their respective scenarios will be spread and diffused through the DataFun platform, which will inspire and learn from students who are about to or have started relevant attempts.

DataFun's vision is to create a platform for big data and artificial intelligence practitioners and enthusiasts to share, communicate, learn, and grow, so that the knowledge and experience in the field of data science can better spread and generate value.

Since its establishment, DataFun has successfully held dozens of offline technology salons nationwide, with more than 300 industry experts participating in sharing and gathering tens of thousands of practitioners in big data and algorithm related fields.

image


Guess you like

Origin blog.51cto.com/15060460/2676705