滴滴自动驾驶：充满“不确定性”环境下的决策和控制

交通参与者的很多行为具有很高的偶然性，比如对于突然跳出的动物、异动的行人、车辆等；

面对突然冲出来的小动物，虽然能够识别出来是动物，但也不能明确动作其下一步动作。

▍3. 规控交互性

当我们和其他交通参与者遇到路权模棱两可的情况时，彼此的决策会产生博弈，这种博弈过程有些时候是明确可判断的，有些时候非常微妙；

面对感知局限性、预测偶然性、规划交互性的驾驶挑战，我们怎样才能让自动驾驶系统具有类似人的“直觉”呢？

最直接的就是增强对环境的感知能力，从外部硬件配置和外部数据的补充来提高。例如使用更好的感知硬件（采用分辨率更高的lidar）、辅助使用V2X数据等，能够尽可能地获取更全面的信息。具备更准确的感知信息后，我们还需从更深层次去理解环境信息，如交通参与者之间微妙的交互信息等，结合一些手势、身体、头部的朝向等进行准确的理解预测。

在现实的世界中，对于感知和理解无法达到百分百的确定, 为此我们不能假设上游是完美的。规控团队需要利用上游对环境“不确定性”刻画的信息，进行响应，必要时采取适当的博弈策略，比如对于一个远处的交通参与者的若干可能行为都进行一定的预响应，当我们走近之后，再做出更加确定性的行为。从更高层面上讲，规控模块需要在复杂多变的环境中，同时满足下面两个要求：

• 稳定性(Stability)：规控软件需要给出安全的行为保证. 典型是一些白盒系统，具有可解释，可调性；

• 可扩展性(Scalability)：能够快速适应新的场景，能够处理复杂多变的（包括没有见过的）实际情景，能够快速迁移到不同的ODD进行快速扩张。

然而这两个特性在某些时候又是存在冲突的。在目前业内规划的解决方案中，很多模块其实是基于规则打磨实现的白盒系统。这样的系统提供了有理论基础的，具有可解释、可调性的算法框架，基本上提供了稳定性保障，性能天花板也是比较高的³，但它的扩展性并不是非常强，特别是面对复杂的场景（比如waymo 仅在凤凰城布署无人驾驶运营服务，目前仍然未扩展到其他城市,特别是复杂城市道路路段）。

这样的系统在开发过程中，会逐渐形成技术栈。需要动技术地基的时候，调整不够灵活，工作量大，且风险高。置之不理则会成为功能发展的瓶颈，甚至会成为一枚定时炸弹，未来需要更大心力才能完成。短期来看，关键是要以一种合适的节奏，调动有经验的工程师，持续主导一些局部、整体重构，不断化解当下矛盾，实现下一个层级表现的提升。而长期来看，完全基于工程师的经验和人力进行不同细分场景的分类逻辑打磨的方式，无论是成本还是管理难度都是成指数倍的增长。

我们要实现真正的无人驾驶，提供更加舒适、安全的无人驾驶服务，不仅要考虑当下业务需求，也要考虑在不远的未来如何让规控能力可持续地发展：如何能够更鲁棒地应对环境的不确定性？如何在保证系统稳定性的同时，在可扩展性上有所突破？如何让开发从完全人工，进化到半自动化开发，甚至更高层级的自动化？如何能够让规划控制在未来某一天，可以自我驱动开发，像人类驾驶员一样自我迭代提升，工程师则来进行指引和辅助？客观讲，现在行业内没有明朗路径，但内各有各的探索，并且已经有了很多令人兴奋的新突破。

我们必须要要开始着力未来，从工程架构和算法能力等方向持续投入与探索。无论是中短期的工程导向目标，还是长期的高度自动化持续进步的愿景，规控领域可能也需要向上游的感知预测模块借鉴，更多以数据驱动。要更有效地发挥数据驱动的效用，要把握两个关键问题：第一个是数据来源，第二是数据驱动的方法论。

▍1. 数据是弹药

无人车路测数据

滴滴拥有大规模车队，在苏州、北京、上海、合肥取得测试牌照，在中美两地进行路测。测试场景包括城市主干道、次干道和支路、有条件高速公路、产业园区道路、城市商圈、校区、港口码头、交通枢纽等多类应用场景。辅以infra团队的配套工具，可以搜集到大量一手资料。针对不同的ODD，根据技术迭代和验证的需求，对交通参与者、环境因素、时间等不同维度进行感知/预测/自车行为等的数据收集，进行帮助我们不断的进行技术优化；

桔视数据

“桔视设备”，这个是一个安放在滴滴网约车的摄像头，对内对外用于安全数据采集，覆盖安装超过100万台，这些设备一年会采集一千亿公里的数据，覆盖城市300个，可以预见各种千奇百怪的数据和场景，以此拓展我们对更广泛真实驾驶场景的理解和应对能力。

▍2. 数据驱动需要方法论

也就是如何实现数据驱动的问题分析，算法开发迭代、系统性验证，来进行技术上的突破；

问题分析

首先，谈谈问题分析方法论：海量的数据提供了多维度的信息，我们运用数据的方式是被动式加主动式双式并行的。

• 被动式：利用工具从各个维度帮我们看清问题的分布，比如需要看清频率最高，最严重的问题，并从中理解目前算法和架构的局限，并基于此指导我们进行工程项目的开发。

• 主动式：通过无人车累计的大量数据和桔视积累的海量数据，Infra团队提供的高效的索引服务，按照地点，自车功能，周边环境的特征，能够过滤出很多有意思的场景; 这些场景不仅可以作为场景库的一部分，进一步大规模处理也能够变成机器学习的数据集。 

算法开发

关于算法开发方法论，基于数据驱动的算法开发离不开机器学习算法的助力。现在流行的机器学习算法，特别是深度学习算法，性能突飞猛进，规控所依赖的很多上游输入也是深度学习算法输出的结果。但深度学习产生的模型越来越复杂，以至于他们自己也变成了一种“黑盒”系统，也变成了一种不确定性的来源。这与规控要给自车行为提供的稳定性要求存在一些矛盾。

那如何破解呢？其实业界也在探索。我们可以优先解决那些定义完备，数据丰富，且有明确兜底方案的模块。中期考虑以持续提升模块性能为主，探索类似上游Perception、Prediction能够实现的Continuous Learning的框架。长期来讲也需要投入一部分兵力做一些前沿研究，比如可解释AI系统⁴以期实现更高层次的算法开发、维护自动化；

算法验证

而在算法验证层面，我们要考虑驾驶环境的不可穷举性也导致了它验证的困难。无论是仿真还是路测，主要依赖于比较全面的场景库。对典型场景具有一定覆盖性，并能够持续进行分类、分层的细化，关键维度能够进行参数扫描的操作等等。场景库的来源也分主动和被动。主动设计的场景比较容易实现结构化，但是很难捕捉到一些实际场景中存在的很强的偶然性。为此，我们需要能够同时主动、被动同时地进行持续积累和场景库的持续打磨。

验证流程（以开发一个功能为例）：

• 仿真系统：有低成本、更快速的优势，它主要应用在开发初期。针对要解决的问题，设计场景，验证功能；可以快速进行对比测试，验证新功能是否有效，是否regression。

• 真实路测：封闭/小范围/车队 路测，确保能够捕捉仿真和真实的差距；封闭场地+真实运营区域。封闭场景需要保证系统基本功能一切正常。真实运营区域才是终极目标，在真实的复杂交通中，才能够最客观的评估我们算法的性能。

定义Ground Truth

以上提到了问题分析，算法开发，以及系统性验证的方法论，而对于规划模块还有一个特别具有挑战的问题，就是如何定义它的Ground Truth?也就是什么是正确的驾驶？监督学习算法而言就是labeled data，对于系统性验证就是Pass/Fail 好与坏的标准。这个目前行业内也没有统一的标准。

我们通常会对某一位技术娴熟可靠的人类司机产生信任感，但假如就拿TA的人工驾驶数据作为我们的Ground truth，这样获得的Ground Truth是不是足够丰富？是不是对自动驾驶来说的客观标准？是否能够得到广泛认可和更多决策场景的复用？如何应对不同用户驾驶习惯的差异性？这些问题值得我们进行潜心思考，解决思路也应该放眼更长远的维度。

整个无人驾驶行业，为了应对复杂的自动驾驶场景、环境的不确定性的挑战，业内已经开始探索使用并部署一些基于规则和从数据中学习的混合策略. 但是面对我们未来的愿景，依旧任重道远。更先进的数据驱动的方法论，将是面对更加复杂的ODD更快速规模化落地自动驾驶载人运营的助推力。这是一个很有潜力、很令人兴奋的行业，有很多高潜力的方向。期待更多有志的工程师和研究者加入到自动驾驶行业中来，一起推动技术的演进。

[1] https://www.wired.com/story/amazon-warehouse-robots/

[2] Ono, Masahiro, et al. "Risk-aware planetary rover operation: Autonomous terrain classification and path planning." 2015 IEEE aerospace conference. IEEE, 2015.

[3] https://www.theverge.com

/2020/10/8/21507814/waymo-driverless-cars-allow-more-customers-phoenix

[4] https://en.wikipedia.org/wiki/

Explainable_artificial_intelligence

本文作者

▬

团队招聘

▬

滴滴致力于打造世界领先的L4级及以上自动驾驶技术，希望通过科技让出行更安全、更高效。2019年8月，滴滴宣布将自动驾驶部门升级为独立公司, 专注于自动驾驶研发、产品应用及相关业务拓展。

滴滴自动驾驶长期招聘计算机视觉、规划与控制、行为预测、高精地图、仿真、基础架构、车辆硬件、测试开发等职位，欢迎投递至diditech@didiglobal.com。

扫码了解滴滴自动驾驶

内容编辑 | Mango

联系我们 | DiDiTech@didiglobal.com