郭继舜带你读汽车科技

汽车之心
  • 0,0 (0)
  • TECHNOLOGIE

《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，每周一至周五更新，每日一期，内容独家授权汽车之心发布。

  1. 017 | 在智能驾驶的开发中，为什么仿真的作用越来越重要?

    02.07.2020

    017 | 在智能驾驶的开发中，为什么仿真的作用越来越重要?

    编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，内容独家授权汽车之心发布。 各位朋友，有挺长一段时间没有更新了，因为这段时间我一直专注于处理一款量产车型的智能驾驶功能问题。 这款车型很快就要量产了，但是智能驾驶功能还有比较大的优化空间，至少还没有到让我们满意。 其实每当到了某个车型智能驾驶配置即将量产的前夕，都是最忙碌的时候，大量的道路测试会反馈回无数多的问题，每天都在不断解决算法 bug 和反复调试系统参数。 因为每款车型我都希望能搭载一些新研发的功能，这些技术的亮点在研发过程中也会是最难做好的问题，所以智能驾驶汽车的研发很像是西西弗斯，每个车型就是一块巨石，痛苦和成就感交替，周而复始。 而最近这款车型，是我从事智能驾驶量产这些年中，最狼狈的一次，因为想上尽可能多的新功能，所以见到了人生里最长的问题列表。 终于，到今晚为止，关闭了 94% 的遗留问题，功能和性能表现达到了不错的水平，赶快来录音频把这几天欠的债补上。 首先，我要把这几天调试的一部分心得给大家做一个梳理，以下主要针对智能驾驶量产的整车系统表现，不包括 L4 及以上智能驾驶： 1. 多传感器融合是非常不好做的，特别是在速度比较高的场景下，更是需要耐心的调教和测试； 2. 我记得 2018 年的 CVPR，在一个智能驾驶的 Workshop 中讨论过一个话题：现阶段什么技术是自动驾驶算法中最难的技术？众多业内大佬经过热烈探讨，结论是感知依然是当前自动驾驶最难做好的技术。 我当时有点不以为然，一群做深度学习和计算机视觉的专家，肯定说自己做的这部分技术含量最高。 经过这几天的历练，我越来越深刻地感受到，感知确实是现阶段最难解决的问题，感知不准确，我们在决策端做再多的算法补偿的效果都是有限的； 3. 行车场景下的各种大货车、模糊不清的车道线、新旧车道线交叠的场景，是最容易影响智能驾驶表现的场景. 泊车场景下，用不同颜色砖块表示泊车线的泊车位、地下停车场柱子旁边的泊车位，这些场景很考验融合泊车系统的鲁棒性； 4. 选择好的执行器件非常重要，特别是 EPS，死区过大往往会让你和工程师们有抱头痛哭的冲动； 5. 智能驾驶开发，仿真平台的作用愈发关键了，实车测试遇到典型场景的密度太低，造成测试效率数量级上的落后。 现阶段，我们在 L4 自动驾驶研发中使用了相对多比例的仿真测试，但因为量产的 ADAS 车型需要兼顾运动学和动力学的系统性能仿真，所以现阶段还不能把各种段整合得足够好。 量产层面，我们还是比较依赖实车的测试验证的。 但大趋势是，整车厂越来越需要智能驾驶仿真了。 其实我们很早就开始尝试使用侠盗猎车手 5、百度 Apollo 平台等来做智能驾驶算法的仿真。 量产上也会使用台架、车辆在环系统进行一部分的仿真工作，但真正让我有深刻触动的，是有一次针对一款旗舰车型的实验样车审批。 因为近年来智能驾驶、车联网功能量产搭载的比例非常大，样车需求也急剧增加，加上智能驾驶的很多功能在量产前的功能验证，动辄数万公里的验证里程，让智能驾驶成为了实验样车需求的大户。 举个例子，去年某款新能源汽车的 AEB 一个功能，我们就验证了 5 万公里。 最终这款旗舰车型的样车需求统计下来，数字惊人，加上实验样车因为量少，零部件成本非常昂贵，样车总计的成本几乎上亿。 所以大家以后在路上看到有伪装的实验样车，可别笑他们破破烂烂，每台车买一两台保时捷 718 是绰绰有余的。 前面讲到仿真的重要性，今天我们就来谈谈自动驾驶的仿真技术。 首先，简单总结自动驾驶为什么需要虚拟仿真技术： 1. 虚拟仿真能够以非常快的遍历速度和极高的场景密度让自动驾驶系统在更多场景下对算法逻辑和功能进行验证，其算法逻辑验证的效率是实车测试的数百、上千倍； 2. 虚拟仿真能够还原极少出现但理论上还是会遇到的 Conner case，甚至是车祸场景，在实际路上故意创造这样的场景的成本很高，也有危险性； 3. 虚拟仿真能够对所有交通参与者的行为进行定量的设定和改变，这样就能够创造出更多的场景，轻松验证场景的覆盖度； 4. 在未来使用量产车型众包的方式来收集场景的过程中，我们需要使用虚拟仿真还原众包数据的结果； 5. 全都用实车测试太贵，算法改进效率也很低； 6. 其实 MPI（Miles Per Intervention），也就是脱离里程，是非常不科学的评测自动驾驶系统能力的手段。 后续我们可以通过收集足够多的场景，使用虚拟仿真系统，快速客观地通过测试不同自动驾驶系统的场景覆盖度来评估优劣。 1、什么是自动驾驶虚拟仿真技术？ 实际上仿真技术从计算机诞生之初就已广泛应用在现代工业化大生产的体系中了，从计算机辅助设计（CAD）、计算机辅助工程分析（CAE）到计算机辅助生产制造（CAM），虚拟仿真技术在其中都起到了非常重要的作用。 仅以汽车行业为例，我们常见的就有空气流体力学仿真、车体碰撞仿真、发动机燃烧过程仿真、车身 NVH 声学仿真、车辆动力学仿真以及车辆控制算法仿真等等。 这些仿真技术的类型与应用各不相同，但是其核心原理仍然是计算机建模与应用，大致的过程可以抽象为以下几个步骤（如下图所示）： 1）分解过程：根据业务过程闭环，将应用系统划分成为接口明确的子系统。具体到智能驾驶，就是把智能驾驶的各个功能和软硬件模块划分出来。 2）建模过程：根据应用需要，对子系统从原理与数据上进行计算机建模，建立子系统的仿真模型。具体到智能驾驶，就是把智能驾驶的某个功能或者零部件的原理或者特性在计算机上尽可能逼真地建立数字化模型。 3）仿真过程：根据测试需求，将部分子系统替换为虚拟的子系统模型，利用仿真引擎进行虚拟仿真下的业务闭环，必要时可以并发进行；具体到智能驾驶，就是在程序内部或者台架上对功能进行模拟，并且通过改变输入，观察输出是不是和我们预设的一样。 4）优化过程：针对虚拟仿真测试的结果优化被测对象的设计与实现，并通过真实测试来验证仿真系统的有效性，获得更多数据优化仿真模型，实现仿真模型与被测对象的共同进化。具体到智能驾驶，就是把虚拟仿真中发现的没做好的算法或者逻辑，修改后进行反复的迭代和优化，最终达到我们满意的结果。 以上步骤，是我们通过虚拟仿真系统来进行开发的通用的流程，而完整的仿真系统还需要做到对仿真模型、案例数据、仿真过程，输入输出接口的完善管理。 在自动驾驶虚拟仿真测试中，根据真实子系统与虚拟子系统的不同划分，可以分为： MIL（模型在环仿真） SIL（软件在环仿真） HIL（硬件在环仿真） VIL（车辆在环仿真） DIL（驾驶员在环仿真） 分别代表了真实子系统为模型、软件、硬件、车辆、驾驶员的情况下的虚拟仿真业务闭环过程。 需要说明一下，如果是我们全部自研算法的智能驾驶系统，从 MIL、SIL 开始到 VIL 都是可以完成的，但是如果你使用的是 Mobileye 的 EyeQ 系列芯片，比较封闭，拿不到代码或者中间数据，我们就只能从硬件在环和车辆在环层面去仿真。 一般来说上述过程闭环所需要的仿真模型通常包括：传感器物理模型，车辆动力学模型，静态虚拟场景模型，天气气候模型，动态虚拟对象模型，动态交通流模型，车辆驾驶行为模型、突发事件模型等等。 这些模型的建模与运算需要非常专业的背景知识技能以及数据积累，并且需要专业的厂商提供的相应的仿真引擎来实现。 例如：车辆动力学建模需要专业的车辆动力学引擎并且需要车厂提供详细的车辆参数，传感器物理建模需要传感器厂商提供电磁学模型，交通流与驾驶行为建模也需要专门的交通流仿真引擎以及更加真实详尽的数据来驱动。 而其中最难的还是如何构建这样的一个虚拟的世界，一方面需要像游戏公司一样进行 3D 模型设计。 虚拟世界中的物体对象，另一方面，需要类似底层的游戏引擎厂商甚至英伟达这样的硬件厂商提供类似于粒子引擎、RTX 实时光线追踪引擎等等底层渲染技术，才能够比较完美的构建一个视觉渲染像更真实，电磁信号反射特性与强度符合真实物理原则的虚拟世界。 目前业内主要通过虚拟游戏引擎来实现上述的功能，最常用的有UnrealEngine4和Unity3D，包括高逼真渲染、模型动作渲染、物理碰撞模拟、天气模拟等等功能，都能够通过这些游戏引擎直接来实现，开发人员可以更多的集中在场景实现与业务逻辑上，提高了开发的效率。 在上述的技术基础上，自动驾驶的虚拟仿真技术才可能通过对采样位置与采样模式的不同设置

    17 Min.
  2. 016 | 软件定义汽车的核心是什么？谈谈特斯拉新一代电子电气架构

    19.06.2020

    016 | 软件定义汽车的核心是什么？谈谈特斯拉新一代电子电气架构

    编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，内容独家授权汽车之心发布。 郭继舜带你读汽车科技No.16 00:0011:32 今天来聊聊新一代电子电器架构，就是我们常说的 EEA3.0。 其实，最开始想到要谈电子电气架构，我是比较抗拒的，因为这是一个非常庞大而复杂的系统，其中涉及到的电子元器件至少数百起步，而且跨越了底盘、动力、车身、座舱、智驾等等多个系统领域，需要在汽车领域浸营多年的资深工程师才有可能窥得全貌。 而我仅仅对汽车领域新兴的智能驾驶有些了解，特别担心班门弄斧、贻笑大方 。 这次也只能够从智能驾驶的角度来对整车电子电气架构的演化过程与发展趋势尝试着做一个理解，还请各位专家多多指正。 我们先来回顾一篇旧闻： 2018 年美国《消费者报告》杂志指出，Model 3 在高速行驶状态下紧急刹车方面存在严重问题。具体来说，当 Model 3 在以 60 英里/小时（约 96.6 公里/小时）的时速行驶时，其制动距离约为 46.3 米，明显高于同级别的其他车型。 随后，Model 3 远程推送固件升级，让紧急刹车距离缩短了大约 6.1 米。 对此，《消费者报告》的汽车测试部门总监 Jake Fisher 不无震惊地说：「我在这岗位工作了 19 年，测试了上千款车型，第一次见识到有车能通过无线升级来大幅改善性能表现的。」 这篇报道中 Model 3 所体现出来能力的就是「软件定义汽车」的能力，而这个能力得以施展的基础就是特斯拉先进的电子电气架构设计。 首先，Model 3 的制动系统采用的是（博世）ibooster 制动机构，其电控软件是特斯拉自己开发的，可以通过 OTA 升级，实现对刹车踏板特性的调节。 这次升级就是通过调整刹车响应曲线来实现整个刹车过程中的制动力最优化的分配，从而减少刹车距离的。 上面的过程说起来很简单，但是却是目前大多数车厂完全无法实现的，其原因就是现有车辆的电子电气架构还是传统的分布式电子电气架构。 我们从下面这张著名的博世电子电气架构演化图可以看出： 当前大多数的汽车还处在从分布式的 Modular 阶段向初步集成的 Integration 阶段升级的过程中，少数先进的 OEM 则在新兴的比如智能座舱、智能驾驶等等需求的驱动下，开始了分功能域的 Centralization 阶段的尝试。 比如广汽、上汽、小鹏等等，而特斯拉则已经实现了基于区域融合的多个功能域控制器融合的 Fusion 阶段，甚至有进一步整合成为 Vehicle Computer（FSD）的趋势。 这样领先的电子电气架构设计，才能够让 OTA 升级功能渗透到刹车控制器上，实现对最底层执行件软件深度优化。 一方面，这需要整车上的 TBox 网关具备高速安全的外网连接能力与数据传输能力。 另一方面，也需要车辆内部具备高速可靠的总线连接，让网关下载的内容能够下发到最底层的执行件电子单元上面。 最后，还需要 OEM 具备强大软件开发能力，能够开发最底层执行件的控制软件，才能够真正实现用软件来定义汽车功能或者性能。 除了博世提出的上述软件架构演化路径以外，其他的先进 OEM 与 Tier1 也提出了各自对于新的电子电气架构的设计思路。 例如宝马就提出了一个基于分层的架构设计理念： 从底向上分别从传感器、执行件层，到标准通用的 ECU 层，再到功能集成的域控制器层，最后到集中式的中央计算平台层。 这是一个基于车内高速通信服务的功能逐步抽象聚类的设计思路，和博世的设计具有异曲同工之处。 本着第一性原理，我们可以来分析一下，驱动电子电器架构进化的要素究竟是什么，从而对于未来电子电器架构进化的形态做一个初步的预测。 首先，是智能化的需求。 早期的汽车主要用机械结构来满足最基本的驾驶需求，以一种机械唯物主义方法论来设计的车辆，所以后续产生的电子系统都以一种辅助机械功能执行的模式来设计实现的，彼此之间通过低速的 CAN、Lin 等等总线以进行简单的信息同步与交互。 而随着智能化时代的到来，未来的汽车对于智能座舱、智能驾驶、智能云服务、智能能源管理等等智能化需求越来越强烈，对算力的要求大大提高。 而个性化与情感化的需求又让车辆的功能迭代更加快速，因此要求新的电子电器架构能够提供更加高性能的运算能力，更加灵活的软件功能，更加快速的内部通信能力，从而催生了算力集中、软硬件分离、负载均衡、高速通信的新一代电子电器架构的演化趋势。 以特斯拉为例，在开发了对应的应用软件并释放的用户群体以后，以类似于互联网领域软件开发方式，通过用户使用应用软件中收集到的真实反馈与真实道路数据，不断优化其应用软件。 虽然在一开始可能会出现一些由于系统不完善而引发的安全事故，但是随着其应用软件不断升级与迭代，目前特斯拉在智能驾驶的开发中越来越成熟，并且可以以满足用户的需求为目标，不断地提供新的智能驾驶使用场景给到用户。 其中包括去年的智能召唤，以及今年预计会推出的反向智能召唤等。 其次，是开放互联的需求。 现在的车辆已经从一个独立的复杂机械变成了社会化信息网络中的一个节点，通过车路协同、车云协同等等互联模式，让车辆具备了与外部网络高速互联的能力。 这一方面对车辆电子电器架构的开放接口提出了标准化、高速度、可靠性、可扩展的要求，另一方面也对车辆的信息安全能力提出了更高的要求，这些在未来的电子电器架构设计中都是需要考虑的。 第三，是系统安全的需求。 由于智能驾驶、智能座舱、智能网联等等功能的实现，汽车的安全将更多的由车辆来主要负责。 为了保证车辆系统能够提供绝对的安全的服务，在电子电器架构设计中也要考虑更多的冗余备份，更高的关键零部件可靠性设计，更多的系统预期功能安全的设计。 以这样的开发思路，特斯拉 CEO 马斯克除了在汽车领域以外，在航天航空领域亦是如此。 近期 Space X 发送的运载火箭，通过用 3 个工业级的英特尔 X86 双核处理器做冗余，以不断同步 6 个核中数据的形式来保持数据同步，再加上基于 Linux 写的操作系统和 C++代码，取代了宇宙级的元器件，降低了运载火箭的发送成本。 可以说，这是通过更加先进的系统设计理念，使用工业级零部件完成航天级复杂系统的典范。 最后，是节能降本的需求。 由于车辆电子器件数量越来越多，布线越来越复杂，功耗越来越大，在设计新一代的电子电器架构的时候，就必然要考虑到相似功能的电子电器部件集中整合。 基于空间优化的器件接入与电源接入的区域控制器设计，更高算力能耗比的芯片的应用等等设计方案，从而实现减少器件数量，减少总线长度，基于功能与空间布局的控制器整合等等需求。 类似于特斯拉 Model 3，其整个电子电气架构主要由三大部分组成：中央计算模块（CCM）、左车身控制模块（BCM LH）、右车身控制模块（BCM RH）。 中央计算模块主要负责信息娱乐系统、驾驶辅助系统和车内外通信连接，左车身控制模块和右车身控制模块分别负责了车身便利性系统，底盘安全系统和动力系统的功能。 一方面可以更好地支撑更高级别的智能驾驶对算力的需求，另一方面极度简化了功能开发与集成部署的难度，同时也更有利于 OTA 的应用软件升级。 随着电子电气架构从分布式架构到域控制式架构，再到集中计算式架构的发展，车上的 ECU 控制器数量也在逐渐递减，同时减少了 ECU 控制器及其周边件的线束。 如特斯拉从 Model S 一共有 3000 米的线束到 Model 3 只剩下 1500 米，而今年年中计划推出的 Model Y 中预计线束只有 100 米。 在降低了车辆成本的同时，也对车辆的轻量化目标做出了贡献，OTA 过程中受到来自电子电器架构的限制也越来越少。 我们以特斯拉为例，主要是特斯拉确实有很多新的技术尝试和量产实践值得我们学习和思考。 如何将智能驾驶带来的安全、舒适与便利快速带给生活中的我们，如何能保障用户手中的智驾系统是时时刻刻让用户满意的，如何从零部件级的功能安全到系统级的功能安全做一个平衡，这些，都是需要我们长期思考的问题。 就我所知，中国的头部 OEM 都在积极开发下一代的电子电器架构，并且在 2022 年左右实现新一代电子电器架构的平台化，这使得国产品牌在功能持续迭代升级、新功能使用、实车数据维护、售后质量问题快速解决上都会有更大的优势。 另外一方面，也会让智能驾驶系统的测试和量产搭载变得更从容。 因为在整车的开发流程中，智能驾驶功能必须要等到底盘性能完全冻结才能开始进行标定、调教和测试，所以智能驾驶基本上是整车所有功能中最后冻结的。 一旦前面的某些开发出现了延期，在量产前最着急最痛苦的就是智

    12 Min.
  3. 015 | 5G V2X将带来怎样的交通大变革？

    16.06.2020

    015 | 5G V2X将带来怎样的交通大变革？

    编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，内容独家授权汽车之心发布。 今天我们聊聊基于 5G-V2X 的路端建设。 我们讲过一期 5G 车路协同的解读（《为什么实现车路协同比造一辆特斯拉还难？》），后来读者群里（P.S.添加微信号 autobit101 加入读者群）有小伙伴留言想要了解基于 5G 通信的车联网场景技术落地的相关内容。 今天的音频向大家分享下我个人在这方面的理解。 因为 5G 和车路协同现阶段都是热门技术，发展很快，相关技术标准还没有成熟，我们现阶段也暂时是基于 5G 民用通讯网络的实验网进行相关的车载测试，如果有部分信息不够专业和准确，还请大家多多指正。 基于 5G 的车联网场景主要可概括为两大类：网联和智驾。 网联场景可以概述为以人为中心的车载互联系统，即依托 5G 网络，车辆将集成智能家居、语音识别、人脸识别、互联娱乐、网上购物等功能，使车辆成为家和办公室以外的第三空间。 网联场景的实现主要依赖于 T-BOX，在未来一到两年的时间里，可逐步用 5G T-BOX 替代现有的 4G T-BOX 来实现应用落地。 今年下半年 5G T-BOX 产品将陆续量产，今明两年，国内外主要 OEM 都计划推出 5G 的网联车辆，相信很快 5G T-BOX 将成为新车标配。 随着 5G 相关技术的提升，AR/VR、4K 视频等技术的逐步引入，网联场景也将逐步得到更加丰富的展现。 5G 车联网在网联场景的应用属于性能的提升，并不是大的功能的变化，落地应用路线明确，也相对简单。然后，咱们重点聊聊 5G 车联网在智驾场景的落地应用。 智驾场景可以概述为以车为中心的智能驾驶系统，即依托 5G 车联网，将单车智能升级为车路协同的多车智能。 我们在之前的音频中已经简单介绍过，车联网主要包括 V2V、V2I、V2N 以及 V2P 等四类。 V2V 方案的实现主要依赖于车载通讯设备，如 OBU、V-BOX 等产品。 由于 5G NR V2X 的相关标准 R16 尚未发布，适用于 5G 的 OBU/V-BOX 等车规级产品还没有量产。 R16 标准按计划今年发布，标准发布半年后，相关芯片、模组及终端产品将会陆续量产，预计明年下半年将开始车端的量产搭载。 V2P 方案的实现依赖于人们携带的移动穿戴设备，但也可通过 V2I 的方案间接实现。 我听到的一个好消息是，华为计划在下一代的手机用麒麟芯片中加入 V2P 模块，如果我们使用华为手机，就可以选择将自己的地理位置信息去隐私化后上传到云端，实时提醒我们周边的车辆注意行人。 这将很好地避免夜间或者处在视觉盲区的车辆对我们造成人身伤害。 V2I 和 V2N 方案是实现车路协同的核心，也是车联网基础设施的主体。 其中「I」为 Infrastructure，指路侧基础设施，包括通讯设备、感知设备、计算设备等； 「N」为 Network，指车联网云平台，包括边缘云、核心云等。车路协同主要涉及三个端口：车端、路端和云端，车端主要依赖 OBU/V-BOX。 下面我将重点分析路端和云端的建设。 路端设备主要包括： 1）路侧通讯设备，也就是 RSU，主要实现 V2I 通讯，将结构化的路侧数据通过无线通讯方式广播出来； 2）感知设备，包括摄像头、毫米波雷达、激光雷达等，主要用于道路环境的检测，包括道路信息、车辆、行人等，多传感器的融合可以弥补各自的感知缺陷； 3）路侧计算单元，如华为的边缘小站等产品，主要用于感知数据处理、融合等，将原始数据处理为标准的结构化数据； 4）辅助设备，如交换机、供电设施等。 云端的设备主要包括服务器、显示器及其辅助设备等，除了这些硬件，云端更重要的是软件，包括基础软件和应用层软件。 基础软件主要指云平台的底层操作系统、环境配置等，比较容易实现。 应用层软件包括数据管理系统，如数据接入、协议解析、数据分析、数据存储等；高精度地图等基础数据；设备及车辆监控系统；测试分析与仿真系统；车联网应用服务软件；大数据应用及算法训练；信息安全服务系统还有设备管理系统等。 因为 C-V2X 的车路协同技术是一个比较新兴的技术，而且欧美之前的 DSRC 车端通讯网络协议相较于我们国家现在倡导推行的 C-V2X 技术先进性差距较大，参考性并不强，所以针对车路协同云端的应用层软件需求缺口很大。 因为承担了广州智能网联先导示范区的建设和频段运营的工作，我们沟通了挺多的 SaaS（软件即服务）的合作伙伴，暂时还拿不出系统级的完善的解决方案。 所以，在新基础设施建设快速发展的大背景下，车路协同的云端应用层软件，以及系统整体的软件、数据整合，都是大有可为的技术领域。 除此之外，路端和云端等建设还需要 4G/5G 基站及光纤网络作为通讯纽带，以及智慧灯杆等作为安装载体，同时也涉及交通设施、电网设施的改造。 以 5G 车联网示范区建设为例，我介绍下 5G 车联网的应用落地，可主要概括为以下几个建设步骤： 第一步： 道路选择及道路类型分析。 综合示范区的路网规划、道路综合安全指数、交通流量、人口密度、服务设施（医院、学校等）等，选择车路协同建设的道路，该环节可联合相关政府部门，如省/市交通勘察设计院来完成； 然后对所选道路进行道路类型分析和统计，道路类型可初步划分为信号灯十字路口、信号灯 T 型路口、无信号的十字路口、无信号的 T 型路口、环岛、掉头、桥梁、直路等，并对数量和长度进行统计。 第二步：确定道路建设等级。 欧洲根据基础设施对自动驾驶的支持，将基础设施划分为 A~E 5 个等级。 国内业内也尝试将车联网划分为网联辅助信息交互、网联协同感知、网联协同决策与控制三个等级，与欧洲形式有所不同，但内涵一致。 以不同阶段的网联化建设为目标，根据道路覆盖度和路侧设备配置，将道路车联网建设等级划分为：顶配、高配、中配、低配。 如低配可以只考虑有信号灯的路口，路侧设备主要是 RSU 和摄像头等；顶配、高配则实现全路段道路覆盖，路侧设备也将面向 5G RSU 以及摄像头、毫米波雷达、激光雷达等多传感器配置。 第三步：方案设计。 根据道路类型和建设等级，设计车联网建设方案。 路口、环岛等特殊道路优先部署，普通直路可 200 米/套进行部署。 十字交叉路口可以部署 1 个 RSU、4 个枪机摄像头、4 个球机摄像头、4 个毫米波雷达、2 个激光雷达、1 个路侧计算单元等。 这样可以基本实现交叉路口的无盲区多感知融合探测，其它路口可根据十字路口方案进行删减。 直路包括 2 个枪机摄像头、1 个球机摄像头、2 个窄角毫米波雷达、1 个广角毫米波雷达、1 个路侧计算单元，其中，2 个枪机摄像头和 2 个窄角毫米波雷达一前一后部署，分别检测来向和去向车辆，相邻站点可共用一个 RSU，400 米/个。 设备数量可根据道路宽度增加。 感知设备通过网线与路侧计算单元相连，如果是多路设备，就需在中间增加交换机；RSU 也通过网线与路侧计算单元相连。 感知设备进行实时数据采集，传感器数据经网线传递给路侧计算单元进行数据处理、融合，并将融合后的结构化数据输出到 RSU 对外广播。 其中，多个感知设备可以共用一个路侧计算单元，相邻感知设备、路侧计算单元可共用一个 RSU。 云平台的建设可采用边缘云+核心云的方案，例如广州市车联网的建设，可以部署一个核心云和若干边缘云。 边缘云可大可小，按区域部署，实现局部数据的快速处理和分发。 一般来说，每 15-25 个路口共用一个边缘云平台。云端和路端设备之间通过光纤相连。 第四步：路侧设备选型。 RSU 应注重通讯距离、互联互通、可靠性等关键指标；感知设备应注重有效探测距离、精度、FOV、可靠性等关键技术指标；路侧计算单元应考虑软件可升级性能，支持 OTA。 路侧设备应根据场景应用需求进行选型，在满足性能要求的前提下再考虑已有设备的复用。否则会出现有些示范区设备利用率低，运维费用高等问题。 这一点，我举个例子，我看到有些建设方案，倡导充分利用现有的交通摄像头，但我在设计具体的技术方案中发现，由于现阶段已有的交通摄像头部署年限差距比较大、种类多、精度不一，需要设计复杂的图像处理算法来达到多摄像头数据拼接共用，技术实现上很麻烦，我个人觉得有点儿得不偿失。 第五步：施工方案协同设计及协同建设。 由政府部门协助，结合路网规划、现有交通/网络设施，与基站、智慧灯杆等协同设计，制定施工方案。 车联网系统是集路侧设施、云平台、4G/5G 网络、智慧灯杆、交通设施等一体的系统，所以要协同设计、协同建设。 以上，我相对系统地介绍了车路协同中路端设备的建设方法步骤，希望提出这个话题的读者群中的小伙伴满意。 因为时间和篇幅的

    13 Min.
  4. 014 | 滴滴杀入自动驾驶有哪些优势？未来的Robotaxi需要什么样的平台车？

    11.06.2020

    014 | 滴滴杀入自动驾驶有哪些优势？未来的Robotaxi需要什么样的平台车？

    编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，内容独家授权汽车之心发布。 今天，我们聊聊滴滴的自动驾驶公司，顺便讲讲 L4 自动驾驶平台车的技术。 根据《晚点 LatePost》独家消息，滴滴旗下自动驾驶公司获得软银愿景基金（Vision Fund）二期领投的 5 亿美元融资。 这是滴滴自动驾驶业务独立拆分后的首轮融资，也是国内自动驾驶公司获得的单笔最大融资。 大家都知道，愿景基金一期的 1030 亿美元，因为投资了 Uber、滴滴、ARM 等著名科技公司名声大噪，但也因为投资 WeWork 等共享经济公司运营不利、上市失败而血亏。 愿景基金二期有 1080 亿美元的投资规模，但据了解，其中有将近 400 亿美元是软银集团出资，可以说，第二期孙正义投的是自己公司的真金白银。 以如此高的效率投资滴滴的自动驾驶公司，足见孙正义对这家公司及其商业模式的看好。 其实在此之前，因为工作和技术的交流，我们接触滴滴的自动驾驶团队有一年多时间了。 在这段时间里，关于滴滴 L4 自动驾驶的新闻很少，但是能清楚地感受到他们默默地飞速地积累技术能力和团队的厚度。 就我所知，滴滴自动驾驶公司马上还有更大的好消息，大家拭目以待。 今天的一开始，我们先要聊聊 L4 自动驾驶的商业模式。也许这是各位非常了解的内容了，但为了保持音频逻辑的连续性，还是允许我简要介绍一下。 之前我们提到过，L0-L3 智能驾驶的功能大都限制在高速公路上，到了 L4 以上，扩展到了城市道路，而且不需要人类驾驶员坐在驾驶位接管车辆了。 我们把 L4 做这样的总结： 1. 因为城市道路的交通环境非常复杂，自动驾驶汽车上需要安装高线数激光雷达，32 线保底，一般是 40 线、64 线甚至 128 线，十多个摄像头对车周身 360 度视角全覆盖等才能够满足感知的要求，同时对硬件系统的算力需求也很大，一般在 80-100Tops。 所以车辆的硬件成本飙升，现阶段改装一台 L4 自动驾驶汽车的成本在 10 万到 12 万美元左右，再加上车辆本身的成本，所以 L4 的单车成本还是很高的； 2. 车内不需要驾驶员了，车辆有足够的智能将乘客安全地从 A 点送到 B 点，正常情况下，全程不需要人类接管； 3. 配合城市道路的高精度地图，加上新能源汽车相对密集的充电站，基本可以实现 24 小时免人工保养。 综合以上特点：昂贵，绝大多数情况不需要人驾驶，全自动保养。人们就想出了一种全新的商业模式——Robotaxi，即自动驾驶出租车。 L4 之前的乘用车主要是卖给个人用户的，在大多数场景人开，少数高速场景车辆自己开，从而一定程度减缓人们的驾驶疲劳感。 但据统计，我们购买的个人汽车，每天有 90% 的时间是停在停车场的，只有 10% 的时间是行驶在路上。 L4 自动驾驶汽车，由于初期硬件成本较贵，个人用户购买的热情可能不高，更有可能是由滴滴这样的 B 方购买，通过高度自动化的自动驾驶出租车运营，快速赚钱收回高昂的硬件成本。 所以，L4 以上智能驾驶汽车的商业模式出现了转变，从把车辆卖给个人消费者变成共享化运营。 这样的商业化模式，能赚到钱吗？市场前景还是很可观的。 我从滴滴了解到，现阶段咱们打滴滴付出的费用中，有至少 60% 是直接付给了司机的，另外还有 5%-10% 是通过奖励或者红包方式补贴司机的。 这就意味着，我们的打车出行费用中，70% 左右是即时支付的人工成本，如果实现了无人驾驶出租车，我们打车的成本至少能下降 50%。 所以，以 Waymo 为代表的科技公司，把自动驾驶出租车作为商业化理想落地的载体。 那么，到底什么样的自动驾驶公司能在这场科技竞赛中获得巨大优势呢？ 我再给大家讲另一个概念：冷启动成本。 试想，在未来，如果你掌握了仅需要云端平台调度，完全不需要人工保养的高智能自动驾驶出租车技术，准备开一个 Robotaxi 公司。 你会面临一个棘手的问题，就是即使你只在中国一个城市里开展业务，为了能够让用户使用你的 APP 随时能打到车，你必须要保持你的 Robotaxi 在这个城市里的密度，就是不管任何时候用户拿出手机打车，最好都能在三分钟之内打到车，再过 3、5 分钟坐上车。 如果我们以北上广深这样的一线城市为例，为了保证你的自动驾驶出租车服务有可用性，用户不会因为你的平台车辆密度太低打不到车而一怒之下卸载 APP 相当长一段时间不会再用，你至少需要 2000-3000 台规模的车队。 按照现在的改装成本算，单个城市满足最低运营需求也要 30-45 亿元人民币的成本。 可以说，现阶段的硬件成本来说，Robotaxi 这样的商业模式天然就有很高的冷启动成本。 但，像滴滴、Uber、Left 这样的共享出行公司就不太一样，他们天然有一个庞大的由人类司机驾驶的车辆群体。 经过多年的发展，他们已经在各个城市保持了足够的运营车辆密度，初步满足了打车用户的需求。 如果滴滴、Uber 等研发出成熟的可运营的自动驾驶出租车，在法律法规允许的前提下，去掉驾驶员，让车辆完全自动驾驶。 即使只有十辆二十辆，滴滴也可以非常容易地把这少数自动驾驶出租车接入到滴滴打车平台，让用户先使用起来，因为还有足够大量的人类驾驶员的汽车保证运营的密度，乘客使用打车服务的体验丝毫没有受到影响，当打到无人驾驶的出租车的时候，反倒会觉得惊喜。 在后续的运营中，滴滴只需要持续把无人出租车的比例不断提高，就能实现商业模式上持续的降本和智能化。 从这个角度，滴滴在做 Robotaxi 技术研发和商业模式实现的时候，有一个天然的优势，就是冷启动成本几乎为零。 我们在讲 Mobileye 的音频中提到过，L4 大规模运营的重要前提是自动驾驶汽车前装量产。 但是现阶段，由于关键零部件无法过车规，全冗余的底盘执行器件由于成本太高，也很难大规模应用。 所以，现在的 L4 自动驾驶汽车，还是由车厂提供量产车型，经过一定的改装和优化，成为自动驾驶平台车，再由滴滴、小马智行、文远知行这样的自动驾驶科技公司添加传感器、运算硬件和算法软件，最终完成一辆 L4 自动驾驶汽车的开发。 我们大家都熟悉的，很多科技公司在使用的林肯 MKZ，就是经过优化后，性能很不错的自动驾驶平台车。 得益于DataSpeed 在自动驾驶风起之初，眼光独到地选择了林肯 MKZ 这样一款具备优良线控执行功能的车型进行改装，为其开发了标准化的 ADAS Kit 编程接口套件，以及 AutonomouStuff 公司在后续的商业推广过程中的出色表现，配合福特公司高瞻远瞩的默许配合。 这种 OEM+后装改车模式的林肯 MKZ 自动驾驶线控平台车在自动驾驶浪潮来临的早期风靡自动驾驶领域，一度成为了自动驾驶线控平台车辆的事实标准。 其拥有原车量产线控执行接口，冗余制动且制动性能良好，并且提供了 EPS 转角接口，加上符合程序员思维的 ADAS Kit 开发接口，让许多初创公司能够快速地将算法实车搭载测试，获得融资，进入方案迭代升级的良性循环中。 但是，林肯 MKZ 这样的后装改造的线控平台车对于自动驾驶进入深水区的 2020 年来说，已经不再适合产业的发展。 主要原因有三点： 1. 后装改造，成本高企：原车售价加上接近原车价格的改车费用，让 Robotaxi 的规模化应用难上加难； 2. 后装改造，改装部分没有经过车规安全认证，产品的质量与稳定性无法保证； 3. 并不是专为自动驾驶设计的，改装无法弥补，或者代价巨大。 那么，怎样才算是一辆好的智能驾驶平台车呢？科技公司怎样选择才能让自己的自动驾驶算法发挥最大化的优势呢？ 综合与滴滴、华为、小马、文远、禾多、轻舟等行业伙伴交流的经验，我从实现技术角度分析了几个现阶段优秀自动驾驶平台车所需要达到的硬指标。 1. 具备冗余安全且性能卓越的线控执行系统。 除了转向冗余因为技术发展的限制，暂时没有量产产品。 优秀的平台车需要具备冗余驱动系统（电机+发动机或者双电机，驱动响应时间不大于 200ms），冗余制动系统（ESP + iBooster，制动响应时间不大于 250 毫秒），转向系统的响应时间不大于 200 毫秒，转向扭矩最大支持 5N 以上，以保证较小的转弯半径。 2. 开放易用的车辆控制接口设计。 通过线控网关设计，自动整合车辆内部各个执行件的响应模式，平抑执行器件性能参数波动，为外部提供统一且线性的车辆控制参数，以及开放易用的控制接口（提供 CAN DBC 矩阵协议或者基于协议开发的 SDK 等等，提供方向盘转角/转矩、加减速度/阀门开度等接口模式，适配 APOLLO、ROS 等等常见的开发平台），让平台车的客户不需要关心平台车内部具体的执行逻辑，方便易用，大大减少了开发的周期。 3. 提供高续航的供电。 自动驾驶

    13 Min.
  5. 013 | Mobileye炫技，仅凭12摄像头穿越闹市区，一辆优秀的L4无人车该是怎样的

    10.06.2020

    013 | Mobileye炫技，仅凭12摄像头穿越闹市区，一辆优秀的L4无人车该是怎样的

    我把这次试乘的感受试着向大家总结一下： 1. 路感异常平顺，加速减速都很稳健，红绿灯路口没有出现急刹，启停颇有点老司机的意思； 2. 在展现识别算法高层语义信息的显示屏上，我看到，所有的车辆和行人，不光做了识别分类，给出了 3D 的 Bounding Box，还预测了每辆汽车和行人的路径； 3. 我们路试的时间是下午 4、5 点，阳光的斜射已经非常明显了，可能是多个角度的摄像头的原因，感觉阳光斜射对自动驾驶的影响不大； 4. 全程大概 30 分钟的时间，绕着耶路撒冷城区转了一圈，遇到非常多异常工况，但没有一次接管，而且在一个进入下穿隧道的场景，车辆还猛然加速，感觉很像是一个对道路非常熟悉的老朋友开车载你去机场赶飞机。安全员告诉我，这一段是故意设定的，就是为了显示一下 Mobileye 的技术能力。 坐在快速行驶的自动驾驶汽车上，看着路边拿着圣经，带着黑色礼帽赶去哭墙朝圣的行人，前沿的科技和古老的圣城，在夕阳下的金色庙宇，那种感觉真的很奇妙。

    15 Min.
  6. 012 | 特斯拉在华组Autopilot开发团队，完成一套智能驾驶系统本土化需要多久？

    08.06.2020

    012 | 特斯拉在华组Autopilot开发团队，完成一套智能驾驶系统本土化需要多久？

    编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，内容独家授权汽车之心发布。 最近身边的不少朋友在讨论，特斯拉在中国准备招聘研发人才和软件人才，这其中智能驾驶团队是非常重要的招聘目标。 今天我们就着特斯拉招聘中国本土技术团队的事情，来聊聊智能网联技术的本土化。 我先简要把这个新闻的内容向大家介绍一下，在 5 月 26 日央视新闻的校园招聘直播活动上，特斯拉对外事务副总裁陶琳表示： 包括 Autopilot（自动辅助驾驶系统）团队在内，特斯拉需要很多本土化研发和软件人才，研发更多贴近中国本土消费者需要的功能，以及车上的应用。 特斯拉中国可能会增加其自动驾驶研发人数，为中国市场单独成立一组自动驾驶团队，来满足中国的道路场景、法规政策要求。 今年年初，特斯拉上海的超级工厂正式投产，仅仅半年左右，特斯拉中国区又推出新战略，招聘本土化研发团队，真的是有全面开拓中国市场的架势。 我向一位在特斯拉负责招聘的朋友了解了更加确切的情况： 特斯拉确实是计划壮大中国本土的技术团队，一开始团队规模小幅扩张，主要是应对智能驾驶、车联网等技术的本土化工作，后续不排除把更多的研发工作交给中国技术团队的可能性，特斯拉的中国技术团队在未来很可能成为特斯拉技术突破的新引擎。 回到我们今天讨论的智能网联技术本土化问题。 每个不同的国家和地区，语言文字，法律法规，文化习俗不同，导致用车习惯、人机交互界面、智能驾驶系统有非常大的不同，汽车技术的本土化是我们在扩展国际化市场必然要面对的问题。 以往本土化的常规操作，包括更换前后保（前后保险杠）造型、加长轴距、两厢改三厢等等，特别是欧美 OEM 为了符合中国市场的审美倾向，往往会专门推出轴距加长版，奥迪 A4L、A8L、凯迪拉克 ATS-L 等。 在性能优化上，比如应对俄罗斯市场对于低附着路面的底盘性能优化车型，应对中东市场砂石路面的高强度版等。 随着智能网联技术的搭载量产，车载娱乐和智能驾驶成为本土化工作量的大头。 一方面，新闻中的特斯拉，还有奥迪、宝马等国际 OEM 都在开发面向中国的本土化车型；另一方面，自主品牌也积极拓展海外市场。 在我个人的研发经历里，我觉得东南亚、非洲、俄罗斯甚至是欧洲的本土化适配都还好，但是设计研发美规的车，真的是异常痛苦。 可能是为了保护美国本土汽车业的发展，美规车辆的要求比较独特和严格，对于胎压监测、防抱死系统、车身稳定系统等安全配置强制性要求安装都算是简单的（还有比这更难的）。 我举个例子大家就明白了。 我们曾经为了设计完全符合美规的油箱，在国内寻找过十几家供应商也没有找到可以适配的，最后还是选了一家美国供应商。所以看看美国满大街跑的思域、普锐斯，丰田本田的研发体系真的是值得我们国内车企好好学习的。 我们先讲讲车载娱乐系统的本土化有哪些工作要做，其实 AVN 或者 AVNT 的硬件基本上是可以迁移使用的，但是软件系统的改动量就比较大了。 总结有一下三点： 1. 语言文字的翻译工作； 2. 车载系统所使用的 APP、导航地图数据等需要根据不同国家做适配； 3. 一些文化习惯的系统性适配。 第三点我还是专门说一下，比如有些阿拉伯国家，车机的操作交互习惯和我们稍有不同，这个因为牵涉到修改系统底层的交互逻辑，工作量比较大，一般第三点各个出海 OEM 改动得不太多。 重点讲讲智能驾驶，接下来我们从自动驾驶的感知、决策、控制三大系统入手，分析下三大系统本土化分别需要做些什么工作。 因为时间关系，我们这次先讲如何把国外智能驾驶技术在中国做本土化迁移。 在感知方面，相比于欧美道路，中国的道路构成复杂、交通设施特殊、交通参与者的复杂行为决定了中国的道路场景特殊性。 我记得今年年初看过一个文远知行的技术报告，他们统计 L4 级别智能驾驶开发过程中，中国开发团队收集交通场景的效率是美国团队的 6 倍左右，足以见得中国的路况复杂程度。 另外的一个例子，是小马智行刚刚把总部搬到广州南沙的时候，楼教主跟我说，在加州跑得非常欢畅的自动驾驶系统，刚到国内的时候完全不能应对如此复杂的场景，车辆会愣在十字路口。 当然，三年过去了，现在 Pony.ai 应对复杂场景已经非常专业顺畅了。 在量产层面，我要吐槽一下 Mobileye EyeQ3 等芯片的算法是在欧美和以色列的数据库上训练的，对一些富有中国特色的场景的识别有不小的问题。 比如：我国南方的丘陵地区经常会出现的鱼骨线，我在文稿中加了鱼骨线的照片，这个交通标志的意思是道路复杂，请驾驶员保持注意力。 但在智能驾驶开发中，一遇到鱼骨线，EyeQ3 的车道线识别算法拟合出的车道线就飘来飘去极不稳定，造成一系列功能的不稳定。 另外，我们很多高速桥的限重标志，比如 30t（30 吨）类的标志，因为我们这个标志不是国际标准，所以包括 Mobileye 在内的很多算法在做 OCR 识别的时候会漏掉那个小「 t」。 这个看起来还好，但是在用户使用的时候，这个识别结果会和另一个功能，限速识别的限速数据搞混。 比如在一个 120km/h 限速的高速公路上，过了一个桥，系统会很容易以为现在限速是 30。 还有类似老人代步车、装满快递包裹的电动车/三轮车等中国特色交通工具等，很多都无法被 Mobileye 很好地识别。 因此，本土化的第一个工作是要建立自有的中国道路场景库。 感知算法基于本地化的场景，建立本地化的感知模型，有针对性地优化感知的全面性、实时性，对场景内涉及到的关键目标提高识别的准确度。 我们也一直在和以色列团队沟通，希望尽快解决这个问题，以上这些问题在 EyeQ4 上有了初步的优化，希望 EyeQ5 会更好。 我忽然想起一个很好玩的例子，我们曾经和一个瑞典团队合作开发 DMS，驾驶员状态监控系统，这个系统的算法模型都是在瑞典当地收集人脸特征训练的。 在我们联合测试过程中，我们团队有一位小伙伴，因为眼睛偏小，系统对他的识别率无论怎么调整参数都识别不了，最后这个国外的合作伙伴毕恭毕敬地把我们这位工程师请过去专门做数据采集，奉若珍宝，享受了 VIP 待遇。 没过多久，这个瑞典公司就开始针对亚洲人的面部特征做专门的数据库了。 在决策方面，也需要根据本土的场景进行适配性的开发工作。 对于 L1-L2 级别的功能，其决策模型较为简单，本土化的工作可能需要重新判定某些临界值的参数，比如感知模块判定前方是快递电动车，那么决策模块就需要将跟车速度降下来。 同时，考虑到快递车有随时停车的可能性，决策模块还需要输出拉大跟车距离的命令。 另外，对于电动车、自动车的行为预测和路径决策，是一直困扰我们的问题。 所以合资品牌新车型即使在深圳广州这种禁摩的城市 ADAS 测试非常顺畅，到了北京、天津就频繁 AEB 触发，就是对两轮车的预测太不准确了。 涉及到 L3 以上的高阶功能，某些连续的行为可能会代表特殊的意义，决策模块需要根据事件发生的概率做出行为判定，其决策模型较为复杂，本土化工作可能不只是参数修改这么简单，可能是模型优化甚至模型新建类的工作。 例如，中国特色的「加塞」行为，决策模块需要判定侧方车辆的意图，如果判定该车有 Cut in 的意图，那本车需要根据前后车的距离、相对车速情况来综合判定是否需要降速让侧方车辆 Cut in 进来。 很多欧美车企在设计 TJC 功能，也就是高速公路辅助驾驶功能的时候，是不考虑 Cut in 的情况的。 我有一次在跟德国系统工程师讨论，他们对于高速拥堵时候还加塞的行为特别不可思议。在我们做技术迁移和本土化的时候，这些都是我们要专门加强的部分。 控制模块本土化的工作相对系统，主要是应对上层决策层的需求，适配不同的车辆，调节算法参数适应不同的工况等。 还有，高精地图 HDMap 也是我们中国企业才能够参与的技术，和地图数据的适配也是高级别智能驾驶中国本土化的工作重点之一。 本土化的参数、算法模型需要这么大的工作量，后续的整车级、系统级、单元级的测试验证还涉及到大量的工时投入。 技术上完成一个本土化的周期我们来粗略的估算一下时间： 采集相关数据，训练数据和模型，保守估计 3 - 6 个月； 场地内功能测试，预计 8 - 12 周时间； 路试，积累足够里程数，周期在 77 天 - 120 天不等； 仅仅对自动驾驶做本土化的技术更新，粗略估计需要 1 年左右的时间，当然这都是在组建好成熟的团队的情况下。 所以，我们至少还需要等待一年以上的时间才能看到特斯拉中国技术团队的本土

    11 Min.
  7. 011 | 什么是智能汽车操作系统？为何大众、戴姆勒都在投入重金研发？

    05.06.2020

    011 | 什么是智能汽车操作系统？为何大众、戴姆勒都在投入重金研发？

    编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，内容独家授权汽车之心发布。 写在前面：昨天我断更一天没有录音，因为临时出差晚上一直在飞机上，错过了录音的时间，在此向大家道歉。 自从开了这个音频栏目后，我差不多每天傍晚 7 点半左右下班，就开始想今天要录点什么内容。晚上 9 点半将文稿的提纲写好，然后对文稿信息的准确性查阅相关资料确认，大约 10 点半左右录音完成，再请编辑小伙伴制作和整理文稿。所以大家会发现，这个音频节目都是差不多接近 12 点的时候才制作完成上线的。 我发现这个制作机制太脆弱了，万一出差（或其他原因）就会断更，我本周末要多录几段儿囤着，也不能老让编辑小伙伴凌晨时候着急忙慌做音频和排版。 在此，对所有为这个小栏目付出辛劳的小伙伴表示衷心感谢。 今天分享的内容源自德国汽车制造商戴姆勒 CEO Ola Kallenius（康林松）在接受德国《商报》采访时提到： 戴姆勒计划为汽车开发软件操作系统（Windows for Cars），同时戴姆勒将开发用于导航、语音控制、音乐、电话通讯，刹车系统、安全气囊控制等一系列的汽车软件。 其实早在今年 1 月拉斯维加斯 的 CES 展上，戴姆勒已经介绍了自家操作系统 MB.OS。 戴姆勒希望在公司内部建立软件开发自研的能力，来替换来自外部的供应商的技术服务。 大概在 2024 年至 2025 年，戴姆勒车辆上的软件操作系统将完成向 MB.OS 的转换。 大家可能对「汽车软件操作系统」这个概念还比较陌生，但是对操作系统本身，应该是比较熟悉。 比如我们日常在电脑上使用的 Windows 操作系统，Linux 操作系统，又或者在手机上使用的 iOS 和安卓。 严谨一点说，操作系统是管理和调度计算机硬件与软件资源的计算机程序。 操作系统需要处理很多的任务，比如，管理与配置内存、决定系统资源供需的优先次序、控制输入设备与输出设备等等。同时，操作系统也能够提供一个让用户与系统交互的界面。 类似的，以目前智能驾驶辅助系统开发流程为例，主要包含了硬件开发、软件开发、系统集成、功能标定测试等等，在这之中软件开发中又分为应用层软件开发、中间件和系统级基础软件平台。 而戴姆勒目前计划开发的部分，几乎涵盖了软件开发中的所有部分。 可以这么讲，戴姆勒的野心是要为行业打造一个跨域的真正为智能汽车量身定制的系统。 而现阶段，我们在量产中广泛使用的 QNX 是黑莓公司当年为黑莓手机研发系统的改进版。 戴姆勒计划开发的车载操作系统 MB.OS 并不是像有些主机厂，仅仅基于安卓做 UI 的修改，通过改变用户的交互界面和操作逻辑体现个性化，它更类似于从底层创建一个汽车的安卓或者 iOS，将软件部分与硬件部分进行解耦，从而减少后期应用软件在适配不同硬件时复杂的重复性工作。 除了戴姆勒，大众集团于 2018 年宣布正在为整个产品线开发新的软件操作系统 vw.os，并从 2020 年起，大众品牌的电动汽车都将采用该操作系统。 理想汽车目前也在内部孵化一个 LiOS 项目，开发自主软件操作系统。 斑马智行基于 AliOS 系统开发了斑马智行车载操作系统，而 AliOS 系统实际的内核是 Linux。 当然，还有大家都熟悉的华为的鸿蒙操作系统。 为什么这么多企业都关注于在车载操作系统的开发呢？ 科技公司做系统开发还有情可原，戴姆勒、大众这样的主机厂有必要做车载操作系统的开发吗？ 我个人从技术的观点出发，认为戴姆勒、大众目前开展的软件操作系统开发是十分有必要的。 原因简要总结为以下三点： 第一，随着操作系统自主化开发，硬件和软件之间的可解耦性也变得越来越清晰。 每一个车型都会存在传感器型号不同、控制器芯片与架构不同等问题，之前部署应用软件在不同的车型中时，会针对每一款车型的硬件平台做定制化的软件适配与部署。 如果软件与硬件可以实现解耦，只需通过调整操作系统与不同硬件平台的适配，就可以将应用软件部署在新的硬件平台中，同时操作系统与不同硬件平台的适配工作量是远远小于应用软件直接和硬件平台进行适配的工作量的。 第二，未来的软件定义汽车的趋势可期。 如果车载操作系统是由主机厂主导设计的，在推向市场后会更容易对汽车进行 OTA 升级。 在功能应用场景新增与扩展，使用逻辑、人机交互策略更新时，则更容易由主机厂主导进行，而不是完全依赖于不同的供应商。 第三，数据在未来的智能驾驶上，扮演着越来越重要的角色。 主机厂如果需要保证用户在车辆使用过程中数据的所有权，车载操作系统在这其中扮演的至关重要的一环。 汽车的车载操作系统开发，只有对其内核、运转机理等研究得越深，主机厂在后续部署其应用软件时能参与的部分才越多，对应主机厂软件开发的自由度才越高。 比如说目前在研究 L4 级别的自动驾驶时，一般是选择 Linux 操作系统，在上面通过 ROS 来搭建一种信息交互的通信框架，这样在开发过程中，应用软件开发工程师可以更聚焦在节点上功能的实现。 由于 ROS 的开源、松耦合运行设计、支持多种开发语言，目前使用 ROS 进行自动驾驶开发时有着很大的便利性。 但是在真正量产的时候，因为 ROS 并没有解决数据实时性传输、数据加密以及数据传输量等问题，所以在实际使用过程中采取 Linux 和 ROS 这样的搭配较少，行业确实需要更加简单、易用、可靠、科学的车载操作系统。 除此之外，Linux 并没有拿到行业功能安全的认证，而如果使用黑莓的 QNX 车载操作系统，其虽已经获得功能安全认证，但是作为未来支持更高级别自动驾驶的系统，还是会存在信息安全、算法多核调度的优化空间。 一方面我们在等待 QNX 系统的升级，另外一方面，各个大厂开始寻找更加彻底的解决方案——自研操作系统，逐步支持未来智能座舱、车载娱乐、L2.9/L3/L4 乃至更高级的自动驾驶的软件开发。 正如大众汽车集团在 2019 年宣布将成为一家软件驱动的汽车公司，其计划通过组建一个 5000 人以上数字化专家团队来负责车辆内的软件开发，并在 2025 年实现内部车辆软件开发占比从 2019 年不足 10% 提高到至少 60%。 传统的汽车主机厂正在试图借助智能驾驶的发展，从车辆销售转变为车辆服务销售。而车辆本身更多的是一个技术的载体。 我们拿手机做类比，手机生态的利润，有不少是通过销售手机软件应用来实现的。 而汽车的利润模式，在未来很可能变成主要提供软件和数据服务，而车辆本身，不过是实现服务的场景罢了。 参考目前特斯拉的销售模式，Autopilot 的售价在中国区为 56000 元人民币，用户购买 Autopilot 后，系统的性能表现在不断地通过 OTA 升级变强，用户的购买意愿和对 Autopilot 的可感知价值都是非常可观的。 我想起 2018 年特斯拉通过 OTA 的升级，将其高速行驶时紧急制动的制动距离缩短了约 6 米。 我当时是非常震惊的，这对整车电子电器架构的支持，和底盘的一致性调教的要求是非常高的。 特斯拉能做到这一点，也是基于其内部拥有大量的软件工程师和软件开发平台的自主化。 在之前的音频中我也提到，特斯拉计划在今年打造一个类似 Uber、滴滴的智能手机应用，用户可以通过该应用呼叫 Robotaxi 自动驾驶出租车服务，并支持特斯拉车主将其车辆加入 Robotaxi 网络。 这也是软件和服务商业化的典型案例。 做一个简短的总结：从车辆制造商到移动出行提供商，未来留给车辆制造企业的想象空间还是很大的。新一代电子电器架构、域控制器的发展、车载软件操作系统等，都在技术层面让未来的汽车和商业模式更值得期待。 往期回顾： 特斯拉撞上了侧翻的大货车，从台湾嘉义事故谈传感器融合 智能汽车的中国芯：华为MDC首发测评 字节跳动入局车联网，互联网应用上车要解决哪些难点？ 为什么欧美车企纷纷放弃L3，而中国车企热衷量产L3？ 传统车企为什么造不出Autopilot，特斯拉L4战略存在什么风险？ 为什么实现车路协同比造一辆特斯拉还难？ 本期制作 主讲：郭继舜  监制：王德芙  编辑：叶方     后期：陆非     设计：陈溪阳  运营：林芝芝 音频平台 喜马拉雅 | 蜻蜓 FM | 听伴 Podcasts | 小鹅通 在以上平台搜索关注汽车之心 即可收听全部节目

    10 Min.
  8. 010 | 特斯拉撞卡车问题有解吗？谈谈自动驾驶感知前融合架构的优势和难点

    02.06.2020

    010 | 特斯拉撞卡车问题有解吗？谈谈自动驾驶感知前融合架构的优势和难点

    编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，内容独家授权汽车之心发布。 前情提要：由于昨天（6 月 1 日）台湾嘉义的特斯拉 Autopilot 事故，我们对 Autopilot 感知系统的安全性以及虚拟激光雷达进行了初步的探讨，同时对自动驾驶多传感器感知后融合的架构进行了一些介绍。 今天，我们来谈谈自动驾驶的感知前融合技术。 同样是特斯拉的新闻，根据外媒报道：2019 年 10 月，特斯拉收购自动驾驶感知创业公司 DeepScale。 DeepScale 的优势主要有两个： 第一，感知前融合（Early Fusion），在做目标检测前利用传感器的原始数据（RAW Data）而不是目标数据（Object Data）做感知融合，大大提高感知系统的鲁棒性； 第二，在不牺牲性能的前提下，通过重新设计神经网络来提升感知系统的效率，使深度学习模型在有限算力的嵌入式设备上运行成为可能。 除了 DeepScale，国内自动驾驶圈曾经的知名创业公司 Roadstar 也把感知前融合技术作为他们解决方案中重要的技术优势，相比于上一期我们提到过的后融合的感知方案，前融合的确具备一定的先进性。 在这里可能需要解释一下：虽然多传感器融合技术从上个世纪 70 年代开始，就已经随着声纳信号处理的需求被美国军方提出来了。 后来在 80 年代，又发展出了多传感器数据融合 MSDF (Multi-sensor Data Fusion) 技术，并且后续理论逐步完善，发展出了包括卡曼滤波、贝叶斯估计、D-S 证据推理、神经网络等等多种理论方法，但是其应用领域更多是信号处理方面。 由于算力不足以处理海量的数据，所以更多的是从信息论与概率论的角度来对观测值求取统计学上的一致无偏最优估计。 但在现在算力爆发的条件下，在自动驾驶的应用背景下，我们在工程实践上更多地会根据实际需要解决的问题，来对技术框架进行梳理，包括后融合与前融合这些行业内的常用说法，可能并不是严谨的学术术语。 回到前融合技术，相比于后融合，前融合具有很大的优势，简要总结为三点： 1.后融合感知框架中，每个传感器单独识别物体。 对于大型物体（如货车），单传感器识别只能识别到物体的一部分，从而容易导致大小及分类识别错误。 前融合通过将所有传感器原始信息有机组合，形成较完整的空间占据数据后，通过数据之间的互补能有效降低因部分识别造成的误判。 2.后融合感知框架中，不同的传感器因自身能力限制，特定条件下可能发生漏检或误检。 上述错误会直接输入后续的融合框架中，后融合对于已经引入的错误的过滤与纠错能力有限，可能无法识别与跟踪特殊物体或者小物体。 而前融合的数据，在融合后能够将数据维数扩展到更加高维的空间，包含的信息更加丰富，能够让算法的分类边界更加易于训练与实现，同时对于小目标的识别率有很大的提升。 3.后融合感知框架中，需要针对不同的传感器训练不同的感知算法，最终的感知结果取决于每个算法的性能，难以调优。 前融合感知框架则能够通过一个单一的识别算法模型对融合后的数据进行统一处理，优化起来更加方便。 当前的数据前融合感知的主要手段有两种： 1.传统的基于三维空间理论分析方法。 首先将图像和激光雷达或者毫米波雷达的信息统一坐标系，即空间同步。 其次对传感器每帧的数据进行校准，进行时间同步。 然后寻找空间之间最佳的线性变换矩阵，将图像标定后每个像素的距离信息与点云进行配准，或者利用点云和摄像头像素的共线原理将点云投射到摄像头图像中进行融合。 融合得到的结果是具备颜色信息的点云数据，或者是具备深度信息的图像数据。 最后再基于融合的结果进行后续的识别操作。 这种方法的优点是可解释性强，对数据的依赖较小，标注工作量小，缺点就是需要极强的标定能力，一旦传感器的种类与位置稍有变化，就需要重新进行标定。 基于视觉染色点云 2.基于神经网络/深度学习的方法。 该方法不会进行点云与像素之间的相互映射，而是直接以端到端的形式输出检测的目标、车道线以及其他的预期目标。 首先对图像和点云进行时间空间同步，然后根据预期的输出目标将图像和点云进行分别标注，将标注好的图像和点云数据输入到神经网络。 通过神经网络去学习图像和点云之间的对应关系和点云和图像的相关性，使得输出结果更加准确。 这种方法对于标定的能力要求大大降低了，可以容忍一定的传感器变化，但是对标注工作量需求大增，因为引入了深度学习模型，可解释性比较差，且对算力的要求更高，目前还是处于探索阶段。 RoadStar 所采用的感知前融合架构 （来源：RoadStar 分享资料） DeepSense 网络结构 （来源：DeepSense: A Unified Deep Learning Framework for Time-Series Mobile Sensing Data Processing） 但是，虽然前融合感知技术能够提高感知系统的准确性与鲁棒性，但在当前还主要面临下面几个难点，造成这个技术并没有被广泛的采用，简要总结为四个难点： 1.数据来源问题：前融合需要对传感器的原始数据进行融合，所以需要各个传感器都能够给出原始的 Raw Data。 但是受限于产品接口与商业协议等等问题，有些传感器无法获得原始数据（例如我们在量产中使用的博世毫米波雷达，EyeQ4 的智能摄像头等），对于这些传感器无法适用前融合感知框架。 2.时间同步问题：通过统一的主机给各个传感器提供基准时间，各传感器根据已经校准后的各自时间为各自独立采集的数据加上时间戳信息，可以做到所有传感器时间戳同步。 但由于各个传感器各自采集周期相互独立，无法保证同一时刻采集相同的信息。时间误差需要在 1 微秒以内，当前是比较难以达到的。 3.空间同步：将不同传感器坐标系的测量值转换到同一个坐标系中，其中激光传感器在高速移动的情况下需要考虑当前速度下的帧内位移校准。100 米外的物体距离精度要在 3 厘米以内。 这对于标定测量提出极高要求。同时，由于在使用过程中传感器的参数与相对位置可能也会发生一些改变，出厂时的标定参数不一定能够使用，所以如何实现在线重标定也是一个难以解决的问题。 4.算力需求：前融合神经网络通过全面接收整车所有传感器数据，通过超大规模神经网络运算识别出障碍物位置、大小及分类信息。这对于硬件的 AI 算力提出极大要求。 当然，不管是前融合还是后融合，白猫黑猫，抓住老鼠才是好猫。 在现在这个阶段，自动驾驶需要的是更加安全与鲁棒的感知系统，最终还是需要根据当前的软硬件条件来选择最适合自己的感知系统实现方案。 我们上一期讲到，特斯拉的虚拟激光雷达可能是一个非常好的探索，由于摄像头的被动感知模式，通过特殊设计的车灯和特定波长的滤镜（参考激光雷达）或许能够在一定程度上改善摄像头失效的问题。 但是，基于功能安全的分析和考虑，自动驾驶所需要的感知方案最终必然是一个足够异构冗余的多传感器融合方案，才能够真正的保证自动驾驶系统的安全性。 还是那句话，虽然我很喜欢特斯拉的电动车，虽然我连续两个晚上熬夜看 SpaceX 的载人火箭发射热血沸腾，但在高级别智能驾驶方面，我依然是激光雷达坚定的支持者。 往期回顾： 特斯拉撞上了侧翻的大货车，从台湾嘉义事故谈传感器融合 自主品牌向上突围，中国车企推出高端品牌的逻辑 智能汽车的中国芯：华为MDC首发测评 字节跳动入局车联网，互联网应用上车要解决哪些难点？ 为什么欧美车企纷纷放弃L3，而中国车企热衷量产L3？ 传统车企为什么造不出Autopilot，特斯拉L4战略存在什么风险？ 为什么实现车路协同比造一辆特斯拉还难？ 本期制作 主讲：郭继舜  监制：王德芙  编辑：叶方     后期：陆非     设计：陈溪阳  运营：林芝芝 音频平台 喜马拉雅 | 蜻蜓 FM | 听伴 Podcasts | 小鹅通 在以上平台搜索关注汽车之心 即可收听全部节目 「汽车之心·行家说」预告 华为智能座舱的野心：HiCar上车，为鸿蒙OS铺路 千倍成本压缩！特斯拉开发虚拟激光雷达，替代最贵自动驾驶传感器 蜂巢能源抢先落地，无钴电池的第一次出击

    9 Min.
Alle anzeigen (17)

Info

《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，每周一至周五更新，每日一期，内容独家授权汽车之心发布。

Informationen

  • Erstellt von
    汽车之心
  • Jahre aktiv
    2020
  • Folgen
    17
  • Bewertung
    Unbedenklich
  • Copyright
    © 汽车之心 @喜马拉雅FM
  • Sendungswebsite
    郭继舜带你读汽车科技