前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >无人驾驶技术,中美差距究竟在哪里?

无人驾驶技术,中美差距究竟在哪里?

作者头像
机器人网
发布2018-04-24 14:43:52
4850
发布2018-04-24 14:43:52
举报
文章被收录于专栏:机器人网机器人网

我们中的大多数人可能不相信自动驾驶汽车将在很近的未来(10~15年)成为现实。汽车厂商和Tie 1供应商都在一个个的整合资源,在各个层面布局。本文也想从全局,落地的角度来讨论下自动驾驶是怎样渗透到我们的实际生活中的。在驱动因素方面,主要是基于道路安全的考虑,如美国在2015年有35,092人死于车祸,94%的事故与驾驶员的决策和操作失误有关。所以不论是交通安全管理部门,汽车制造企业还是技术供应商,高科技企业,都从中看到了机会。

__一、自动驾驶系统技术__

自动驾驶系统需要进行分级,从细节上去考虑,目前美国已形成了统一,以SAE International关于自动化层级的定义为准,如下:

L0 :驾驶员完全掌控车辆;

L1 :自动系统有时能够辅助驾驶员完成某些驾驶任务;

L2 :自动系统能够完成某些驾驶任务,但驾驶员需要监控驾驶环境,完成剩余部分,同时保证出现问题,随时进行接管。在这个层级,自动系统的错误感知和判断有驾驶员随时纠正,大多数车企都能提供这个系统。L2可以通过速度和环境分割成不同的使用场景,如环路低速堵车、高速路上的快速行车和驾驶员在车内的自动泊车;

L3 :自动系统既能完成某些驾驶任务,也能在某些情况下监控驾驶环境,但驾驶员必须准备好重新取得驾驶控制权(自动系统发出请求时)。所以在该层级下,驾驶者仍无法进行睡觉或者深度的休息。在L2完成以后,车企的研究领域是从这里延伸的。由于L3的特殊性,目前看到比较有意义的部署是在高速L2上面做升级;

L4 :自动系统在某些环境和特定条件下,能够完成驾驶任务并监控驾驶环境;L4的部署,目前来看多数是基于城市的使用,可以是全自动的代客泊车,也可以是直接结合打车服务来做。这个阶段下,在自动驾驶可以运行的范围内,驾驶相关的所有任务和驾乘人已经没关系了,感知外界责任全在自动驾驶系统,这里就存在着不同的设计和部署思路了;

L5 :自动系统在所有条件下都能完成的所有驾驶任务。

我们所说的自动驾驶系统,通常是在3~5层级,随着层级的提高,对系统的要求也随之提高。由于目前自动驾驶的分级,特别是L3和L4处在还没有大规模应用在实际生活之中,我们对待这个需求就存在着一些认知上的争议。

分类方法:以DDT、DDT的任务支援和设计运行范围来区分;

动态驾驶任务(DDT):是指在道路上驾驶车辆需要做的操作和决策类的行为;

车辆执行:包括通过方向盘来对车辆进行横向运动操作 、通过加速和减速来控制车辆;

感知和判断(OEDR):对车辆纵向运动方向操作、通过对物体和事件检测、认知归类和后续响应,达到对车辆周围环境的监测和执行对应操作、车辆运动的计划还有对外信息的传递。

动态驾驶任务支援(DDT Fallback):自动驾驶在设计时候,需要考虑系统性的失效(导致系统不工作的故障)发生或者出现超过系统原有的运行设计范围之外的情况,当这两者发生的时候,需给出最小化风险的解决路径。

设计运行范围(ODD)就是一组参数,把我们知道的天气环境、道路情况(直路、弯路的半径)、车速、车流量等信息作出测定,以确保系统的能力在安全的环境之内。

图1 设计适用范围的对比

__L2 组合驾驶__

驾驶员和汽车来分享控制权,系统同时具有纵向和侧向的自动控制,且具备两项以上。在整个开启的过程中,驾驶员可以不操作方向盘、油门和刹车(放弃主要控制权),但需要观察周围情况,并提供安全操 作 。

驾驶员必须随时待命,在系统退出和系统出错的情况下随时接上。

自动驾驶系统:我们从控制和感知进行分解

对执行器的要求可以看出来,是需要对纵向的动力总成和刹车系统,横向的转向系统进行融合控制。

图2 L2的工作方式

解析L2的感知需求,是需要把整个场景考虑清楚

低速自动泊车场景:感知车位、行人、车辆

低速环路堵车辅助场景:识别车辆、摩托车、车道线

高速封闭道路场景:识别车辆、车道线

我们在现实中看到的L2系统,既有单个摄像头实现的TJA,也有很多差异化设计。这里由于有着驾驶员随时监控环境这条要求区分,车企可以选择做得少也可以选择做的多一些,因为不管是感知还是驾驶决策,完全依照车企对L2自动驾驶的需求不同来调整。

既有拿一个LRR、5个SRR、2个Camera来做的,也有拿单摄像头来进行处理的低成本方案。

既可以仅靠车道识别来进行车辆居中保持,也可以依靠高精度定位和高速道路地图来实现车道的匹配和居中,提高横向控制特性。

这里的核心区别,就是对以下的内容进行限制:

对不同的道路、基础设施的可容忍性

车速的运行范围

对感知错误(误识别率)的容忍性

对自动驾驶系统在不同流量环境下的改进可行性,往L3进化可能性

对车主的使用的判研以评估综合风险性

我们在把这些拿出来讨论的时候,其实是可以考虑做一份工程的规范,然后根据各个车企的配置情况来进行测试和对标的。所以总的来说,这个L2是所有车企在积累和提高特性的必争之地。

__L3 有限度的自动驾驶__

在某些环境允许的条件下,驾驶员可以完全放弃操控,交给自动化系统进行操控。如果系统出现问题,是不能完全自主进入安全状态的,需要驾驶人员来接管,但这个时间一般较短。虽然这个看上去不大实用,但是确实是德国三家豪车企业目前在自身系统演进过程中比较看重的点。这些发表的研究性的配置,都是基于L2的演进来考虑的。

没了驾驶员的确认,整个感知的要求高了很多:

准确度要求高了,不能出错,这里一定有融合对比;

感知范围距离要求高了,需要给自动驾驶决策时间;

对环境耐受性要求高,突然下冰雹和暴雨也需要时间来切换;

即使系统发生错误的时候,整个转换的退出还需要时间;

感知系统要有冗余性要求,既有融合情况,也有单个感知单元失效诊断之后fail-operational的要求,也要独立能运行。

图3 L3的系统情况

因为L3没有进入产品化,所以这些研究阶段的配置可能会进一步进行调整,可以看出,L3阶段是之前L2顶级配置性能上面再进行演化。由于在运行中失去了驾驶员的监控,任何运行中的感知错误都是不能接受的(没看到车就会产生错误决策,就会出现问题)。

__L4 全自动驾驶__

在福特明确提出要做L4的自动驾驶和自动驾驶服务之前,没有哪个车企这么敢来做,因为这里一旦启动,已经对驾驶者没有要求。在之前看到的更多的,还是基于机场小型低速摆渡车、市区低速巴士之类的有限制的运行。

系统100%负责感知的准确性

系统100%要在设定的范围内完成所有驾驶员要做的事情,没有后备

系统在自身出问题和外界环境变化的时候,要考虑冗余的策略,保证车内和车外安全

自身感知、处理和执行段的所有故障诊断

自身感知、处理和执行段的Fail-Operational

图4 L4的运行情况

现阶段,L4的设计考虑还配置个安全驾驶员,这里的情况比较微妙,先做性能,再做冗余,下个阶段就完全考虑实现L4,到了这里就不打折扣了。

__二、各个发展阶段__

1970年以前:一些车企使用射频和磁钉的方式来导引车辆实现自动驾驶。

1977~2000年:日本、欧洲和美国的一些高校进行了一些实验和开放项目,主要提供给高校和研究院所进行的开放项目,如EUREKA Prometheus、CMU NAVLAB、AHS Demo.

2004和2006年:分别进行DARPA的一些比赛,鼓励各个高校组织实际的车辆相互竞争参与比赛。

2007年:DARPA城市挑战赛,这个选择了城市道路这项有很高难度的项目来给各个高校空间,这里Carnegie Mellon和Stanford这两个车队比赛成绩很接近。

2007年之后,以Google为代表成立自动驾驶实验室,制造样车然后进入试验阶段。

图5 自动驾驶技术的发展

目前对于自动驾驶的分化和考虑:

系统服务企业: 基于服务端的IT公司为主,百度、Google、Uber都是考虑在营运端拿来做服务,规划要在3年内实现部分商用;而Tesla就抛出了硬件(无冗余)先行跟进软件的策略。

有个大的转变是Google专门成立了公司,开始与车企合作进行,以后的商业模式值得进一步考虑。

测试阶段和真正运营还是有些差距的,主要体现在投放的范围和控制的力度。

车企运营端的投入:受整个环境的驱策,各个车企现在对于面向消费者的服务端有不少的投入,下一步把试车场里面比较成熟的产品拿出来进行运营级别的测试运行,就是一个比较务实的决定。这些车辆可以分为两部分:

车辆段:可以考虑冗余度,在涉及关键安全控制端(EPS、ESP两块可以单独把冗余的部分应用上去);而整个感知端和计算平台端可以采取先从性能端调试,再加入决策投票确认的冗余机制。

监控端:整个后台运行需要有完整的数据记录机制,也有个后台团队,来处理道路上遇到的各种行为(类似紧急的弹出和道路意外)。

这里既需要有单独的存储和发送机制,把整个感知的数据进行备份和传输(新的传输Tbox2),在云端可以做一些复现和记录,也可以用原有的记录层(T-box1)来记录之前的运行结果。这个提高的路径就是现有软件和后台虚拟运行之间的对比,进化的逻辑就是抓取多台车之前的软件版本运行数据和原始数据虚拟运行对比。

后台的竞争而言,是各个IT公司有天然的优势;不管这个事情最终如何,车企不大可能单独去构建一个非常庞大的后台。

自动驾驶车企零售模式:单独把L4的车辆卖给普通消费者,天然就蕴含很多的风险因素。所以我们可以把这个行为,当作是运营之后的一小步,发售给部分发烧票友来尝试的。这应该只占到非常小的部分。

图6 各家公司对L4的商业化计划

图7 L4的车型和部署与打车服务是很难分离的

__三、自动驾驶产业情况__

根据参考文献2的整理,大概有如下的产业格局,如图8所示(这是一个基本的概览,在里面的角色可以进一步定位),我们可以根据整个细分类目做进一步的划分。原来的单一分法,主要有:

汽车厂家:生产、设计、测试或计划售汽车

汽车系统和部件供应商:向汽车厂家出售部件或者系统,主要负责这些零件/系统的生产、设计和测试,包括:

感知层:我们可以逐个细分成摄像头、激光雷达和毫米波雷达,这些主要是以传统汽车电子厂家为主,或者从其他工业行业转过来的供应商。

网络连接:主要是V2X的模块和服务供应商。

还有其他如计算处理、地图和定位、网络安全和系统安全、处理算法提供商。

新的玩家

自动驾驶系统供应商:由于自动驾驶系统的特殊性,出现了整个系统方案提供商,通过在已经有的车辆基础上,来生产、设计、供应高度自动驾驶的系统,或是测试、销售、运营、应用整个产品。

自动驾驶系统使用者:潜在的包括运输公司、车队经营者、出租车公司等机构,希望在其应用平台之上,将原有的部分或者全部驾驶员的工作替换为自动驾驶车辆。

从整个产业来看,由于系统比之前有过之而无不及,从系统的底层往下走,需要保持高度的信息透明,才能准确的应用系统;出现认知的误差,或者系统安全上面的疏忽,将会导致系统的滥用,也会造成安全事故。整个自动驾驶的链条是需要挺多的时间,包括监管层面的梳理才能慢慢运作出来,原有的汽车厂家一方,是很难独立完成这个任务的。

图8 自动驾驶产业概览

__四、自动驾驶在中国__

前期军工高校独立研发,校企合作。

2008 年启动“视听觉信息的认知计算”重大研究计划,项目每年持续推动无人车及其关键技术的研究。

自2009 年起每年举办“中国智能车未来挑战赛”,通过集成创新研发无人驾驶汽 车,促进研发交流及产业化应用。中国智能车未来挑战赛国家自然科学基金(NSFC)设立了与智能汽车技术有关的“视听觉信息的认知计算”重大研究计划,自2009年起共举办了五届比赛。

2013 发布《汽车无人驾驶技术体系》等汽车安全技术的四个工作组征求意见稿,推动汽车信息化与智能化发展。

研究项目概览

国防科技大学1992年成功研制出中国第一辆真正意义上的无人驾驶汽车。

2005年,首辆城市无人驾驶汽车在上海交通大学研制成功。

上海交通大学Shanghai Jiaotong University 与欧盟合作研发的“CyberC3” 项目,2007年亮相东方绿舟。

2011年7月,由一汽集团与国防科技大学共同研制的红旗HQ3无人驾驶汽车完成了286公里的高速全程无人驾驶试验,人工干预的距离仅占总里程的0.78%。

2012年,军事交通学院的“军交猛狮Ⅲ号”以无人驾驶状态行驶114公里,最高时速105公里/小时。

2015年12月初,百度无人驾驶汽车在北京进行全程自动驾驶测跑,实现多次跟车减速、变道、超车、上下匝道、调头等复杂驾驶动作,完成了进入高速到驶出高速不同道路场景的切换,最高时速达100公里/小时。

2016年4月12日,两辆长安无人驾驶汽车,从重庆出发,沿高速公路前往北京。

这些成果主要体现在各个无人驾驶的比赛中,随着国外的投入,国内的各个主要公司也在投入。阿里、腾讯和百度三家都进入了这个领域:他们特点是布局产业链,商业模式清晰,投入也会很大。各个部件层面有着很多的创业公司:在芯片、部件层面都涌现出了很多的企业。涵盖了算法提供商:如地平线。系统层面如驭势也有了自己的定位:一开始是作为整合者来出现的。

图9 中国目前的情况

参考文件:

1. OEM和供应商一致认为自动驾驶离我们并不遥远 Bill Visnic SAE International

2. Segmenting the Autonomous Vehicle Value Chain: A Look at Who is in the “Driverless" Seat

3. Federal Automated Vehicles Policy Accelerating the Next Revolution In Roadway Safety

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2017-01-06,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 机器人网 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
Prometheus 监控服务
Prometheus 监控服务(TencentCloud Managed Service for Prometheus,TMP)是基于开源 Prometheus 构建的高可用、全托管的服务,与腾讯云容器服务(TKE)高度集成,兼容开源生态丰富多样的应用组件,结合腾讯云可观测平台-告警管理和 Prometheus Alertmanager 能力,为您提供免搭建的高效运维能力,减少开发及运维成本。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档