首页/文章/ 详情

为什么说RSS(责任敏感安全模型)有望解决自动驾驶的安全问题?

8月前浏览228

Mobileye在2017年末发表了一篇重要论文《On a Formal Modelof Safe and Scalable Self-driving Cars》,并在该论文中提出了责任敏感安全模型(RSS)。

   图 1  Mobileye论文

一、RSS的初衷


如何证明一辆自动驾驶汽车是安全的?在RSS出现之前,行业上有两种方法:

一种方法是依靠足够的测试里程。根据统计目前人类驾驶汽车事故的死亡率是10-6次/小时,假设自动驾驶汽车事故死亡率要降低3个数量级,即需达到10-9次/小时,需要的测试里程是30亿英里。

                           

图 2  自动驾驶安全测试里程

另一种方法是对标行业最佳实践(Best Practice)。这就要求车企走上军备竞赛的道路,堆积更多的冗余硬件和开发工作量。


Mobileye认为以上两种方法更多地是统计层面的意义,无法真正证明自动驾驶汽车的安全性,而且巨大的开发工作量也使其很难实施。


为解决此困境,Mobileye推出了责任敏感安全模型RSS,其目标是提出一套被整个社会广泛接受,可以证明自动驾驶安全性的全新方法论。


图 3  责任敏感安全模型RSS

二、RSS到底是什么?


自动驾驶的通用技术架构可以分为“感知-决策-执行”三个层次,其中在决策层面又可进一步细分为以下四个层面:战略(strategy)、战术(tactics)、路径规划(path planning)和控制(control)。


举个例子,战略层面决定要变道;战术层面决定具体变道时机;路径规划根据战术决策规划变道路径;控制就是根据路径规划结果,控制车辆的横纵向运动执行器。

图 4  决策算法

在战略层面和战术层面的决策算法中,机器学习都会起到重要作用。也因为机器学习算法的应用,导致战略和战术层面的算法成为了黑箱,难以判断安全性。


Mobileye的解决思路,就是在路径规划部分中增加责任敏感安全模型RSS。RSS本质是一套数学模型,其将人类对于安全驾驶的理念和概念转化成为了数学公式和计算方法。在车辆通过深度学习算法做出决策后,将指令输入到 RSS 的模型中,如果RSS模型显示结果安全,则执行上层算法;如果RSS模型显示有危险,则将执行返回到上层算法,进行二次决策。


图 5  RSS的作用位置

三、RSS的实现方法


RSS模型的目标为:自动驾驶汽车本身不会导致事故;自动驾驶汽车应该在其它车辆发生错误时做出正确反应。


也就是说在RSS模型作用下,自动驾驶汽车只可能被动卷入交通事故,而不会主动制造交通事故;同时当其它因素引发交通事故时,自动驾驶车型应尽可能采取适当地应对方式。


那怎么实现这个目标呢?


RSS模型的思路是如果可以用数学模型定义出什么是危险情况,以及危险情况下的正确反应,就可以划分事故责任——即在危险情况下,没有采取正确反应的一方需承担事故责任。


具体来说,RSS模型将5种人类驾驶常识进行了数学建模:


1、追尾不是前车的责任,后车必须保持足够的安全距离


RSS模型中对安全距离的定义为:在最恶劣的情况下仍可以避免碰撞的距离,最恶劣的情况是指前车以最大刹车加速度开始刹车,后车发现后有一定的反应时间,并在反应时间内仍以最大加速度前进,然后改成以最小刹车加速度刹车,直到危险解除。

2、 因变道而导致的事故,责任在实施变道的车辆


虽然由其它车辆变道导致的安全事故,责任在变道车辆,但RSS模型中还是定义了变道场景下横向安全距离。只要留有足够的安全距离,自动驾驶车辆就应该保证安全。


3、拥有路权,而不是争抢路权


即使一辆汽车违反了交通规则进入自动驾驶汽车拥有路权的道路,自动驾驶车辆也不能由于自己的路权高而向前冲。而是在有足够的时间刹车避免事故时,必须刹车,否则就要承担责任。


4、行人和遮挡


现有即使条件下,无法完全避免遮挡情况下的行人事故。RSS模型中同样定义了这种情况下自动驾驶车辆的正确行为。


5、避免事故发生


危险情况可能突然发生,除非自动驾驶汽车违反一个或多个道路规则,否则无法避免碰撞,那么他应该违反规则,因为避免事故是首要任务。


四、后续


可以看出,Mobileye的RSS模型是一套基于人类现有驾驶常识的数学模型,其目的在于规范自动驾驶车辆的决策路径,判定自动驾驶车辆的事故责任。


RSS模型只有得到政府、企业和社会的广泛认可情况下,才有可能得到推广。目前已有大量组织和企业开始采用RSS模型:


1、电气电子工程师协会(IEEE),即将出台新的标准“IEEE 2846”是基于RSS制定;

2、 中国交通运输部下属的标准制定机构“中国智能交通产业联盟”已经通过了提议,将采纳RSS模型作为其即将推出的自动驾驶汽车安全标准的框架;

3、百度Apollo和法雷奥都宣布将引入RSS模型。


原文完。


来源:车路漫漫
ACT碰撞通用汽车电子自动驾驶控制电气
著作权归作者所有,欢迎分享,未经许可,不得转载
首次发布时间:2025-12-10
最近编辑:8月前
李慢慢
硕士 自动驾驶仿真工程师一枚
获赞 14粉丝 93文章 320课程 0
点赞
收藏
作者推荐

深入探索Carla-SUMO联合仿真

一、介绍1.1 CARLA CARLA是由西班牙巴塞罗那自治大学计算机视觉中心指导开发的开源仿真模拟器,目前被广泛用于自动驾驶系统的开发、训练与验证。模块化和灵活的API,可以用于解决涉及自动驾驶问题的一系列任务。CARLA 的主要目标之一是为自动驾驶研发提供易用和可定制化的工具。可以满足自动驾驶中学习驾驶策略、训练感知算法等各方面需求。CARLA基于Unreal Engine虚幻引擎来运行仿真,并使用OpenDRIVE (目前为1.4)高精地图来定义道路和城市设置,支持高渲染的三维模型。可以通过 Python和C++ 的API 来控制和自定义仿真,API的功能也在不断丰富和完善。CARLA 模拟器是可伸缩的客户机-服务器架构。服务器端负责与仿真本身相关的所有任务: 传感器渲染、物理计算、世界状态及角色的更新等。为了更接近真实世界,推荐使用搭载 GPU 的服务器来运行,尤其是机器学习相关任务。客户端由场景中的角色控制逻辑和模拟世界的设置模块组成,通过API实现。 1.2 SUMO SUMO是一款由德国航空航天中心交通运输研究所开发的开源的、多模式微观交通仿真软件。SUMO提供了具备一个完善的 Python 接口:Traffic Control Interface(TraCI),通过与仿真进程通讯,TraCI 可以获取仿真 主体的所有信息并在线调控,以控制仿真内个体的行为(包括机动车、路侧设施等) 。TraCI 接口提供了良好的二次开发基础与条件,可以灵活地与现有人工智能相关的 Python 库结合,为跨平台的联合仿真提供基础接口。这也是与Carla联合仿真的基础。 1.3 为什么需要联合仿真? 在目前的自动驾驶仿真测试领域中主要聚焦关键场景生成的测试方法,该方法用于针对性地构建容易诱发自动驾驶车辆发生事故的场景,并评估自动驾驶车辆在这些边角案例中的表现,从而对自动驾驶车辆进行测试。在仿真交通流环境中对自动驾驶车辆进行测试有不少优点,在仿真中可以全面构建各种与现实世界的驾驶条件非常相似交通环境。此类测试方法可以有效评估自动驾驶汽车在不同真实交通场景下的性能。CARLA与SUMO在仿真结构上,均采用客户端-服务器的框架,这也为两者的联合仿真创造了条件。其中,服务器负责展示仿真界面,而客户端与服务器的连接,TCP/IP端口获取仿真内的信息,通过不同的端口,实现多客户端同步运行。通过构建桥接器,将SUMO和CARLA中不同格式的信息进行匹配,包括车辆类型、车辆位置信息、基础设施信息等。基于该桥接器,SUMO生成的背景车流可以在CARLA的环境中产生实时同步的映射车辆,而CARLA中接入的自动驾驶等控制算法 会对此产生反馈,也同样会在二维场景中进行同步。 二、安装本节主要讲解安装Carla和SUMO。孙工的视频详细讲解了Ubuntu系统上Carla的安装,习惯用linux的小伙伴们有福了。唯一提醒的地方是ubuntu20在升级pip时,加入环境变量时记得带上bin目录,否则pip -V还是20版本。 我这里就简单说说Windows平台(以Win10为例)的安装,并不涉及源码编译,使用官方编译好的压缩包CARLA_0.9.14.zip,解压后第一级目录只有一个WindowsNoEditor文件夹。进入下一级目录,如下图。 可以看到令人激动的CarlaUE4.exe服务端啦,点击就能运行(系统没有DirectX组件则需要先去下载安装好),效果如图。后续主要是安装Python的carla包和依赖。 说明一下,本例使用Python3.8(在另一台机器测试Python3.7也是可以的,其余版本未测试,不行的话建议创建虚拟环境)。2.1、安装Python carla包 使用pip install carla安装,最好加上国内的源,速度超快,否则就难说了,我这里和后续的包安装都使用清华源,加上-i https://pypi.tuna.tsinghua.edu.cn/simple,下图是安装示例。 2.2、安装依赖 2.2.1 PythonAPI 进入到PythonAPI/util目录,安装requirements.txt中的依赖,执行pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple 很快就装完,过程如下图。 2.2.2 联合仿真依赖 要想进行Carla-SUMO联合仿真,还需要进入到Co-Simulation/Sumo安装requirements.txt中的依赖(虽然只有一个处理XML的包,因为SUMO是的输入基本都是XML文件),安装命令同上,确认当前目录是Sumo即可,过程如下图。 到此,Carla的开发环境就准备好了,接下来就是安装SUMO。2.3、安装SUMO 在官网下载安装包,地址如下:https://sumo.dlr.de/docs/Downloads.php 当前Windows平台安装包为sumo-win64-1.18.0.msi,可以根据引导完成安装,过程中需要注意自动把设置SUMO_HOME、PYTHONPATH环境变量选项勾上(省去后面手动配置)。 安装完SUMO后,测试环境变量是否正常,在cmd输入sumo-gui,如果能自动弹出SUMO界面,如下图,就说明SUMO安装成功、环境变量配置正确。 三、CARLA-SUMO联合仿真3.1 案例文件 官方的案例库只提供了三个场景Town01, Town04, Town05,如下三图,用sumo-gui打开可以配置文件.sumocfg,查看路网和运行仿真。Town01 Town04 Town05 3.2 运行联合仿真 运行联合仿真的基本逻辑是:先启动CarlaUE4.exe服务端,使用Carla的PythonAPI加载场景地图,再启动基于Carla PythonAPI和SUMO TraCI Python API编写的run_synchronization.py脚本进行联合同步仿真。前面提到,直接点击CarlaUE4.exe就启动了服务端,也就是场景渲染的地方。接下来就是加载场景和运行联合仿真脚本:3.2.1 加载场景也就是使用PythonAPI/uitl下的config.py加上map参数指定相应地图,本例就使用Town01,命令为python config.py –-map Town01 运行后出现的视角如图。 3.2.2 错误处理进入到Co-Simulation/Sumo目录,运行命令python run_synchronization.py ./examples/Town01.sumocfg --sumo-gui 关于各个参数的详细解释下一节有专门解释,运行后就会出现弹出下图的sumo-gui,本例使用Town01场景。 朋友们别激动,不出意外的话点击sumo-gui上的绿色三角图标开始仿真就会报错,原因如下。首次运行联合仿真脚本出现错误的原因是在官方提供的sumo_integration包有个小问题,sumo_simulation.py文件中的第304行的traci模块错用,原代码为sumo_net = traci.sumolib.net.readNet(net_file) 但实际上sumolib并不是traci的子模块,也就是下图所示的错误,只要去掉traci.即可。 3.2.3 运行同步仿真脚本再次运行脚本就可以顺利地跑起来Carla和SUMO的联合同步仿真了,在Carla端界面,可以跟玩游戏一样用WASD键+鼠标调整视角。下面是Carla和SUMO并行的一个视角,便于观察双边的车辆是否同步。 到此就算跑通了Carla和SUMO的联合同步仿真。随后是之前的那个预告片,即Town01场景的运行记录。下一节将介绍联合仿真的核心要点,将涉及一些比较重要的概念和代码逻辑,帮助大家理解联合仿真。四、核心要点4.1 车辆类型映射 在Carla和SUMO中有着不同的车辆类型定义,在进行联合仿真前需要确定车辆类型的映射关系,实际是从Carla映射到SUMO,即基于Carla中车辆的blueprint来生成SUMO中的vType。官方提供的脚本create_sumo_vtypes.py就是做这件事的(在Co-Simulation/Sumo/util/目录),我们来简单分析这个脚本。从main(args)函数开始,可以看到上来就是创建客户端,显然需要提前将Carla服务端运行起来。然后从世界中筛选出车辆的蓝图存到vehicle_blueprints变量,随后一个for循环遍历vehicle_blueprints,调用generate_vtype()方法来创建SUMO中对应的vType,最后调用write_vtype_xml()方法把结果写到一个xml文件供SUMO使用。其中还用到一个本地vtypes.json文件(在/Co-Simulation/Sumo/data目录下),这个文件是真正的车辆类型映射关系。4.2 创建SUMO路网 仿真路网是车辆运行的基础,Carla官方是假定你已经有一个Carla的仿真场景,再去创建SUMO的场景,本处也就是生成SUMO的路网.net.xml文件。该过程并不需要Carla服务端正在运行。Carla官方提供的脚本Co-Simulation/Sumo/util/netconvert_carla.py的功能就是基于Carla场景生成SUMO路网,同样也简单对其进行分析。基本逻辑是首先使用SUMO的netconvert工具,将Carla中的OpenDRIVE地图转为一个初步的SUMO路网文件,然后对该路网文件进行修正。脚本定了两个重要的类SumoTopology和SumoTrafficLight,用于描述中间过程的SUMO路网结构和信号灯。两个重要的方法:build_topology(),是将由OpenDRIVE路网转换得到的初步SUMO路网作为输入然后构造成一个SumoTopology对象,在后续步骤使用。_netconvert_carla_impl(),会使用到SumoTrafficLight类,是后续修正SUMO路网的具体实现,作为netconvert_carla()方法只是类似接口的一个包装。其中还用到OpenDRIVE和SUMO道路类型的映射关系文件opendrive_netconvert.typ.xml,存放在/Co-Simulation/Sumo/util/data目录下。4.3 生成SUMO交通需求 该部分可以通过netedit的demand模式手动编辑,但这仅限于简单和少量的路径和需求,所以这里不展开如何进行操作。更好的办法是使用SUMO官方提供的工具脚本randomTrips.py来自动生成随机的交通需求,即.rou.xml文件,具体操作可以看往期内容【省心省力 | SUMO交通需求自动创建工具 | randomTrips.py】,该文还介绍了其他几种创建需求的方法。但需要注意一点,使用该脚本生成联合仿真的交通需求时,要对SUMO中车辆或流量的type参数进行匹配,也就是上面提到的create_sumo_vtypes.py脚本生成的vType集 合。4.4 Carla & SUMO同步仿真 4.4.1 准备仿真 运行SUMO仿真需要将此前转换的路网.net.xml文件和生产的交通需求文件.rou.xml组装在一起作为仿真配置文件.sumocfg文件,设置交通需求时,需要将carlavtypes.rou.xml文件提供的车辆类型文件也加载进去,所以route-files对应的值是逗号分隔的两个rou.xml文件,其中一个就是carlavtypes.rou.xml。准备好SUMO的仿真配置文件.sumocfg后,运行脚本run_synchronization.py加上相应的参数即可与Carla进行同步仿真,SUMO侧使用TraCI接口来实现数据交换和同步。比如下面的命令即可启动Town01的同步仿真(控制台的当前目录在Co-Simulation/Sumo,即脚本run_synchronization.py所在目录):python run_synchronization.py ./examples/Town01.sumocfg --sumo-gui 由于带上了参数sumo-gui,所以也能同时弹出sumo-gui界面,效果如案例视频。4.4.2 参数说明 目前的版本0.9.14 中run_synchronization.py脚本除了必须的SUMO配置文件外,还有12个参数,其中前4个分别指定Carla和SUMO的ip和端口,--carla-host (default: 127.0.0.1) ,IP of the carla host server--carla-port (default: 2000) , TCP port to listen to--sumo-host (default: 127.0.0.1) , IP of the SUMO host server.--sumo-port (default: 8813) , TCP port to listen to.其余8个参数包括:--sumo-gui,开启sumo-gui界面;--step-length (default: 0.05s) , Carla和SUMO联合仿真的时间步长,这里需要说明,该参数也会通过TraCI接口传给SUMO作为其仿真步长;--client-order,联合仿真在SUMO侧的TraCI客户端编号,默认为1;--sync-vehicle-lights (default: False) , 是否同步车辆灯态,默认不同步;--sync-vehicle-color (default: False) , 是否同步车辆颜色,默认不同步;--sync-vehicle-all (default: False) ,是否同步所有的车辆属性,默认不同步,笔者提醒,同步车辆属性在SUMO侧调用TraCI接口实现,比较耗时,所以都默认不同步;--tls-manager (default: none) , 指定管理信号灯运行的依据,如果为sumo则会根据SUMO仿真中的信号灯同步到Carla显示;如果选择carla则Carla自行管理,还会同步给SUMO;默认的none则双侧的信号灯不会同步,由哪一侧产生的车辆就遵守其对应的信号灯,而不会理会另一侧的设置。可以根据具体情形和需要来设置;--debug,调试模式,在测试过程中输出更多的日志。4.4.3 同步仿真原理 接下来将简要分析一下run_synchronization.py脚本的逻辑,如果想深入了解Carla和SUMO的联合仿真,可以继续阅读本节内容,如不感兴趣可以直接跳过到4.5节。该脚本的准备工作除了引入必要的carla相关包和SUMO_HOME环境变量设置外,还需要引入sumo_integration包,包括其中的bridge_helper、carla_simulation、sumo_simulation以及存放常量的constants。脚本中设计了一个SimulationSynchronization类,其中实现同步仿真的是tick()方法,同步仿真结束时释放各种资源的方法close()。synchronization_loop()是同步仿真运行的逻辑,首先分别初始化Carla和SUMO仿真(分别在carla_simulation和sumo_simulation中实现),再创建同步仿真类SimulationSynchronization实例,接下来就是一个while死循环,按固定的时间步长step-length推进仿真(即Carla的tick,这里也就是同步仿真类实例调用tick()方法),同步仿真结束后释放资源。相信到这里,大家已经完全理解Carla和SUMO的同步仿真原理了。4.5 SUMO管理NPC车辆 得益于Carla和SUMO同步仿真实现,可以使用SUMO来管理在Carla生成的车辆(SUMO实现了Carla中Traffic Manager功能)。官方提供的spawn_npc_sumo.py脚本直接引入了run_synchronization.py中的SimulationSynchronization类,当然也有sumo_integration包中的carla_simulation和sumo_simulation。spawn_npc_sumo.py脚本首先根据Carla服务端运行的场景在临时目录下自动生成SUMO路网,准备好.sumocfg配置文件。然后根据输入的NPC数量和参数生成车辆,在每次同步仿真推进一步后更新车辆在SUMO中的路径,下一步同步到Carla中。该脚本的参数可以理解为run_synchronization.py和PythonAPI/examples目录下generate_traffic.py两个脚本参数的部分组合,TraCI相关只多了一个additional-traci-clients额外客户端参数,其余的参数包括:车辆数(-n);行人数(-w);车辆过滤(--filterv);行人过滤(--filterw);安全设置(--safe)都来自于generate_traffic。比如服务端加载Town04,使用如下命令可以加入由SUMO控制的10辆车和20个行人,并在sumo-gui界面可以观察到相应的对象。python spawn_sumo_npc.py -n 10 -w 20 --tls-manager carla --sumo-gui 五、结语本文从安装到调试细致地讲解了如何进行Carla和SUMO的联合同步仿真,详细地阐述了同步仿真中的几个重要问题,并配合代码逻辑的梳理,相信读完本文,会对大家的工作和科研有所帮助。来源:车路漫漫

未登录
还没有评论
课程
培训
服务
行家
VIP会员 学习计划 福利任务
下载APP
联系我们
帮助与反馈