具体实施方式
以下结合附图对本公开的示范性实施例做出说明,其中包括本公开实施例的各种细节以助于理解,应当将它们认为仅仅是示范性的。因此,本领域普通技术人员应当认识到,可以对这里描述的实施例做出各种改变和修改,而不会背离本公开的范围和精神。同样,为了清楚和简明,以下的描述中省略了对公知功能和结构的描述。
城市道路中,需要实时监测道路的拥堵状态,为人们日常出行提供指导。传统的车道级拥堵检测方案,通常基于二维图像计算车道上的车数并估算车辆速度。一方面,受摄像头朝向角的影响,二维图像中车道线可能出现遮挡,或者车辆本身也可能遮挡车道线,这对车道判断造成干扰。另一方面,基于二维图像估算车辆速度,由于二维图像不包含深度信息,导致由此获得的车辆2D信息不稳定,进而导致估算结果误差较大。而基于车辆回3D属性和高精地图进行车道级拥堵检测,由于高精地图中车道是分段的,造成同一车道被划分为多个区域,很容易导致车道级拥堵漏报(如同一车道的某个或者某几个不同区域不满足车道级拥堵定义而导致车道级拥堵漏报)和多报(如同一车道的多个不同区域都满足车道级拥堵定义而导致车道级拥堵多报)。
对此,本公开实施例提供了一种改进型的用于车道级事件的检测方案,其发明构思在于:基于多个设备采集的多组视频流进行目标检测并估算车辆速度,可以减少车速估算误差;同时基于高精地图获取车道地图,并基于车道地图和通过上述的多组视频流获取的车辆3D信息估算车道上的车辆数,可以避免对车道判断造成干扰,同时可以避免车道级拥堵漏报或多报。
以下将结合具体实施例详细阐述本公开。
适于本公开实施例的用于车道级事件的检测方法和装置的***架构介绍如下。
图1示例性示出了适于本公开实施例的用于车道级事件的检测方法和装置的***架构。需要注意的是,图1所示仅为可以应用本公开实施例的***架构的示例,以帮助本领域技术人员理解本公开的技术内容,但并不意味着本公开实施例不可以用于其他环境或场景。
如图1所示,***架构100可以相机设备101、102、103,服务器104和服务器105。
需要说明的是,在本公开实施例中,相机设备101、102、103可以为路侧设备,架设在道路附近,能够检测附近车道上的人流和车流等。比如,相机设备101、102、103可以针对同一车道进行图像采集,以便检测该车道上是否出现拥堵状况。相机设备101、102、103可以是具有相机功能的任何设备。
服务器104用于提供车道地图。具体地,服务器104可以基于高精地图生成车道地图。
服务器105与相机设备101、102、103以及服务器104进行通信连接,可以获取这些相机设备采集的视频流,以及获取服务器104提供的车道地图,并基于获取的车道地图和多组视频流进行目标检测,确定对应车道上的车辆数以及各车辆的车速,进而判断该对应车道上是否发生了车道级拥堵。
应该理解,图1中的相机设备和服务器的数目仅仅是示意性的。根据实现需要,可以具有任意数目的相机设备和服务器。
适于本公开实施例的用于车道级事件的检测方法和装置的应用场景介绍如下。
需要说明的是,本公开实施例提供的检测方法和装置可以用于车道级拥堵检测、车道级事故检测、车道级排队数检测等车道级事件检测场景。以下将以车道级拥堵检测为例详细阐述本公开。
根据本公开的实施例,本公开提供了一种用于车道级事件的检测方法。
图2示例性示出了根据本公开实施例的用于车道级事件的检测方法的流程图。
如图2所示,该方法200可以包括:操作S210~S230。
在操作S210,获取由N个设备针对同一车道采集的N组视频流,其中N大于1,且N为整数。
在操作S220,基于N组视频流,确定目标车辆在预设时间段内的车速。
在操作S230,基于车速,检测目标车辆所在的车道是否发生了车道级事件。
在本公开实施例中,可以利用路侧设备采集的视频流检测是否存在车道级拥堵事件。在操作S210,可以获取由架设在同一路段附近的至少两部相机设备采集的视频流。例如,获取由架设在道路A附近的相机设备1和相机设备2分别采集的视频流X和视频流Y。
在操作S220,可以统一对视频流X和视频流Y进行目标检测,并确定各目标车辆的车速;或者可以先单独对视频流X进行目标检测,确定各目标车辆的一个车速,并单独对视频流Y进行目标检测,确定各目标车辆的另一个车速,然后针对每个目标车辆,对两次确定的两个车速进行融合,以便确定每个目标车辆的最终车速。
由于车辆正常行驶时车速通常大于某个预设值,并且发生堵车事件时车道上的车辆在堵车时间段内通常会以小于某个预设值(如以≤5km/h)的车速行驶。因此在操作S230,可以根据由操作S220计算得到的车速大小判断目标车辆所在的车道是否发生了车道级拥堵事件。
具体地,可以预先定义车道级拥堵状态,例如定义持续5min内平均车速≤5km/h,且车辆数≥10的车道状态为车道级拥堵状态。此种情况下,在检测到车道上各目标车辆的车速在5min内平均车速≤5km/h的情况下,可以认为目标车辆所在的车道发生了车道级拥堵事件。否则,可以认为目标车辆所在的车道没有发生车道级拥堵事件。
需要说明的是,在本公开实施例中,虽然获取的是由架设在同一路段附近的多个相机设备采集的多组视频流,但是由于这多个相机设备可以同时针对同一路段的多个车道进行图像采集,因此在判断是否发生车道级拥堵事件时,还需要确定各目标车辆所在的车道。在操作S230,可以基于高精地图或者车道地图以及各目标车辆的3D信息来确定各目标车辆所在的车道。其中,车辆的3D信息可以基于操作S210获取的N组视频流来获取。车辆的3D信息可以包括但不限于:车辆的中心点坐标,车辆的长、宽、高和方向角等信息。
通过本公开实施例,在车道级事件的检测方案中,基于由多个设备采集的多组视频流估算目标车辆的车速代替基于由单个设备采集的一组视频流估算目标车辆的车速,可以减小误差,提高车速估算的准确度,进而可以提高车道级事件检测结果的准确度。此外,基于高精地图或者车道地图确定各目标车辆所在的车道,可以解决基于二维图像进行车道判断存在车道遮挡的问题。
作为一种可选的实施例,基于通过操作S210获取的N组视频流,确定目标车辆在预设时间段内的车速,例如可以包括如下操作。
针对该N组视频流中的每组视频流,对视频流中的每帧图像进行目标检测,以获取图像中目标车辆的3D信息。
基于由每组视频流中的每帧图像获取的3D信息,分别确定目标车辆在预设时间段内的一个车速。
对由N组视频流确定的目标车辆在预设时间段内的N个车速进行计算,以得到N个车速的融合结果。
用融合结果表示目标车辆在预设时间段内的车速。
示例性的,可以获取由架设在同一路段附近的两部相机设备采集的两组视频流,并由此进行目标检测并估算目标车辆的车速。例如,获取由架设在道路A附近的相机设备1和相机设备2分别采集的视频流X和视频流Y。针对视频流X中的每帧图像进行目标检测,可以获取图像中各目标车辆的3D信息,并基于通过视频流X获取的各目标车辆的3D信息,估算各目标车辆在预设时间段内的平均车速1。同样地,针对视频流Y中的每帧图像进行目标检测,可以获取图像中各目标车辆(与基于视频流X检测到的各目标车辆对应相同)的3D信息,并基于通过视频流Y获取的各目标车辆的3D信息,估算各目标车辆在预设时间段内的平均车速2。然后,针对每个目标车辆,对两次求得的平均车速通过加权平均的方式进行融合,可以得到各目标车辆最终的车速。
应该理解,在本公开实施例中,还可以通过其他方式对多个车速进行融合,本公开在此不做限定。
此外,在本公开实施例中,对每帧图像进行目标检测,可以通过方框取目标,其中方框的像素坐标是可以确定的,基于方框的像素坐标可以估算目标车辆的3D信息。此种情况下估算的车辆3D信息是用图像平面坐标系下的像素坐标表示的。进一步,基于相机设备的内外参数以及一个或者多个预先设定的平面方程,可以将由图像平面坐标系下的像素坐标表示的车辆3D信息先转换为相机坐标系下的坐标表示的车辆3D信息,再转换为世界坐标系下的坐标表示的车辆3D信息,而基于世界坐标系下的坐标表示的车辆3D信息,可以估算各目标车辆的车速及其所在的车道。需要说明的是,本公开实施例中,相机内参数包括但不限于:焦距、像元尺寸等;相机外参数包括但不限于:相机在世界坐标下的位置以及三个坐标轴的偏向角等。
通过本公开实施例,基于车辆的回3D信息(与2D信息相比更加稳定)和多相机结果融合跟踪手段,解决了相关技术中车辆速度估算不准确的问题,可以达到提高车速估算准确度的技术效果。
作为一种可选的实施例,基于通过上述实施例确定的车速,检测目标车辆所在的车道是否发生了车道级事件,可以包括:响应于该车速小于第一预设值,针对该目标车辆所在的车道输出车道级事件提示信息。
由于车辆正常行驶时车速通常大于某个预设值,并且发生堵车事件时车道上的车辆在堵车时间段内通常会以小于某个预设值(如以≤5km/h)的车速行驶。因此,在本公开实施例中,可以根据计算得到的车速大小判断目标车辆所在的车道是否发生了车道级拥堵事件。
具体地,可以预先定义车道级拥堵状态,例如定义持续5min内平均车速≤5km/h,且车辆数≥10的车道状态为车道级拥堵状态。此种情况下,在检测到车道上各目标车辆的车速在5min内平均车速≤5km/h的情况下,可以认为目标车辆所在的车道发生了车道级拥堵事件。否则,可以认为目标车辆所在的车道没有发生车道级拥堵事件。
需要说明的是,在本公开实施例中,上述的第一预设值可以根据经验确定。此外,可以在高精地图中以不同的颜色显示不同车道的通行状态,例如以红色作为拥堵提示,以绿色作为畅通提示等。
作为一种可选的实施例,该方法还可以包括:在针对目标车辆所在的车道输出车道级事件提示信息之前,统计在预设时间段内该目标车辆所在的车道上的车辆数。其中,响应于车辆数大于第二预设值,执行针对目标车辆所在的车道输出车道级事件提示信息的相关操作。
通常情况下,车辆正常行驶时车速会大于某个预设值,并且发生堵车事件时车道上的车辆在堵车时间段内通常会以小于某个预设值(如以≤5km/h)的车速行驶。但是在个别情况下(如因突发状况限速),也可能导致车辆行驶速度在某个时间段内小于某个预设值。但是这种情况并不属于车道级拥堵事件,因此在输出车道级拥堵事件提示信息之前,进一步确认车道上的车辆数是否也满足车道级拥堵事件的定义,可以排除因个别情况导致的车道级拥堵误判。
作为一种可选的实施例,针对目标车辆所在的车道输出车道级事件提示信息,可以包括如下操作。
针对通过上述操作获取的N组视频流中的每组视频流,对视频流中的每帧图像进行目标检测,以获取图像中目标车辆的3D信息。
基于预先生成的车道地图和获取的目标车辆的3D信息,确定目标车辆所在的车道。
针对目标车辆所在的车道输出车道级事件提示信息。
应该理解,本公开实施例中基于视频流获取车辆3D信息的方法与前述实施例中基于视频流获取车辆3D信息的方法相同或类似,本公开实施例在此不再赘述。并且,在本公开实施例中,也是先获取用图像平面坐标系下的像素坐标表示的车辆3D信息,再基于相机设备的内外参数以及一个或者多个预先设定的平面方程,该车辆3D信息先转换为相机坐标系下的坐标表示的车辆3D信息,进而再转换为世界坐标系下的坐标表示的车辆3D信息。最终,将世界坐标系下的坐标表示的车辆3D信息与车道地图中各车道的位置信息进行匹配,可以估算出各目标车辆所在的车道。
通过本公开实施例,由于车道地图中每条车道都是完整的,没有被划分为多个区域,因而利用车道地图代替高精地图进行车道判断,可以解决基于高精地图进行车道判断容易导致车道级事件漏报或多报的问题,即,利用车道地图进行车道判断,可以避免车道级事件漏报或多报。
作为一种可选的实施例,可以通过以下方式获得车道地图:针对高精地图中的所有车道,按照车道的前驱和后继关系进行拓扑排序,以获得车道地图。
具体地,在本公开实施例中,可以从高精地图中抽象出车道地图层。具体做法可以包括:对高精地图中的所有车道,按照其前驱和后继关系进行拓扑排序,得到对应的车道地图。该车道地图中,每条车道都是一个最小粒度单位,并没有被进一步划分为多个区域,因而不可能出现针对同一车道的不同区域多次上报车道级事件的情况。类似地,也不可能出现漏报车道级事件的情况。
需要说明的是,在本公开实施例中,车道之间的前驱和后继关系可以用车道的前驱参数和后驱参数表示,并且这些参数都可以直接从高精地图中读取。
或者,在本公开实施例中,车道地图还可以直接根据各车道的前驱信息和后继信息进行拓扑排序得到。
通过本公开实施例,基于高精地图抽象出车道地图层,可以避免因高精地图车道分段(即分区)导致的车道级事件漏报或多报,同时可以解决因二维图像拍摄角度导致的车道遮挡问题。
作为一种可选的实施例,车道级事件包括以下至少之一:车道级拥堵、车道级事故和车道级排队数。
图3示例性示出了根据本公开实施例的用于车道级拥堵的检测原理图。
如图3所示,可以预先通过高精地图抽象出车道地图。可以通过多个相机设备(如相机设备1~相机设备3)针对同一车道采集多组不同的视频流,并分别基于每组视频流进行目标检测,以获取各目标车辆的回3D信息并基于该信息先单独进行车速估算,再将基于各组视频流计算得到的车速(如车速1~车速3)进行融合跟踪以便得到各目标车辆的最终车速。与此同时,可以将通过各组视频流获取的车辆回3D信息与抽象出来的车道地图进行匹配,以确定各目标车辆所在的车道,进而统计出各车道上的车辆数。判断该车辆数和对应目标车辆的车速是否满足车道级拥堵事件定义的车辆数和车速。响应于判断结果表示该车辆数和对应目标车辆的车速是否满足车道级拥堵事件定义的车辆数和车速,则针对对应车道输出车道级拥堵事件的提示信息。否则,不输出车道级拥堵事件的提示信息。
根据本公开的实施例,本公开还提供了一种用于车道级事件的检测装置。
图4示例性示出了根据本公开实施例的用于车道级拥堵的检测装置的框图。
如图4所示,该装置400可以包括获取模块410、确定模块420和检测模块430。该装置400可以用于实现图2所示的用于车道级拥堵的检测方法及其变形。
具体地,获取模块410,用于获取由N个设备针对同一车道采集的N组视频流,其中N大于1。
确定模块420,用于基于N组视频流,确定目标车辆在预设时间段内的车速。
检测模块430,用于基于车速,检测目标车辆所在的车道是否发生了车道级事件。
作为一种可选的实施例,确定模块包括:第一检测单元,用于针对N组视频流中的每组视频流,对视频流中的每帧图像进行目标检测,以获取图像中目标车辆的3D信息;第一确定单元,用于基于由每组视频流中的每帧图像获取的3D信息,分别确定目标车辆在预设时间段内的一个车速;融合单元,用于对由N组视频流确定的目标车辆在预设时间段内的N个车速进行计算,以得到N个车速的融合结果;以及第二确定单元,用于用融合结果表示目标车辆在预设时间段内的车速。
作为一种可选的实施例,检测模块还用于:响应于车速小于第一预设值,针对目标车辆所在的车道输出车道级事件提示信息。
作为一种可选的实施例,该装置还可以包括:统计模块,用于在针对目标车辆所在的车道输出车道级事件提示信息之前,统计在预设时间段内目标车辆所在的车道上的车辆数。其中,上述检测模块用于响应于车辆数大于第二预设值,执行针对目标车辆所在的车道输出车道级事件提示信息的相关操作。
作为一种可选的实施例,上述检测模块包括:第二检测单元,用于针对N组视频流中的每组视频流,对视频流中的每帧图像进行目标检测,以获取图像中目标车辆的3D信息;第三确定单元,用于基于车道地图和获取的目标车辆的3D信息,确定目标车辆所在的车道;以及输出单元,用于针对目标车辆所在的车道输出车道级事件提示信息。
作为一种可选的实施例,通过以下方式获得车道地图:针对高精地图中的所有车道,按照车道的前驱和后继关系进行拓扑排序,以获得车道地图。
作为一种可选的实施例,车道级事件包括以下至少之一:车道级拥堵、车道级事故和车道级排队数。
应该理解,本公开装置部分的实施例与本公开方法部分的实施例对应相同或类似,本公开在此不再赘述。
根据本公开的实施例,本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。
图5示出了可以用来实施本公开的实施例的示例电子设备500的示意性框图。电子设备旨在表示各种形式的数字计算机,诸如,膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机和其它适合的计算机。电子设备还可以表示各种形式的移动装置,诸如,个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例,并且不意在限制本文中描述的和/或者要求的本公开的实现。
如图5所示,电子设备500包括计算单元501,其可以根据存储在只读存储器(ROM)502中的计算机程序或者从存储单元508加载到随机访问存储器(RAM)503中的计算机程序,来执行各种适当的动作和处理。在RAM 503中,还可存储电子设备500操作所需的各种程序和数据。计算单元501、ROM 502以及RAM 503通过总线504彼此相连。输入/输出(I/O)接口505也连接至总线504。
电子设备500中的多个部件连接至I/O接口505,包括:输入单元506,例如键盘、鼠标等;输出单元507,例如各种类型的显示器、扬声器等;存储单元508,例如磁盘、光盘等;以及通信单元509,例如网卡、调制解调器、无线通信收发机等。通信单元509允许设备500通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
计算单元501可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元501的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元501执行上文所描述的各个方法和处理,例如标定雷达参数的方法。例如,在一些实施例中,标定雷达参数的方法可被实现为计算机软件程序,其被有形地包含于机器可读介质,例如存储单元508。在一些实施例中,计算机程序的部分或者全部可以经由ROM 502和/或通信单元509而被载入和/或安装到设备500上。当计算机程序加载到RAM 503并由计算单元501执行时,可以执行上文描述的标定雷达参数的方法的一个或多个步骤。备选地,在其他实施例中,计算单元501可以通过其他任何适当的方式(例如,借助于固件)而被配置为执行标定雷达参数的方法。
本文中以上描述的***和技术的各种实施方式可以在数字电子电路***、集成电路***、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上***的***(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括:实施在一个或者多个计算机程序中,该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程***上执行和/或解释,该可编程处理器可以是专用或者通用可编程处理器,可以从存储***、至少一个输入装置、和至少一个输出装置接收数据和指令,并且将数据和指令传输至该存储***、该至少一个输入装置、和该至少一个输出装置。
用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器,使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行,作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
在本公开的上下文中,机器可读介质可以是有形的介质,其可以包含或存储以供指令执行***、装置或设备使用或与指令执行***、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体***、装置或设备,或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
为了提供与用户的交互,可以在计算机上实施此处描述的***和技术,该计算机具有:用于向用户显示信息的显示装置(例如,CRT(阴极射线管)或者LCD(液晶显示器)监视器);以及键盘和指向装置(例如,鼠标或者轨迹球),用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互;例如,提供给用户的反馈可以是任何形式的传感反馈(例如,视觉反馈、听觉反馈、或者触觉反馈);并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
可以将此处描述的***和技术实施在包括后台部件的计算***(例如,作为数据服务器)、或者包括中间件部件的计算***(例如,应用服务器)、或者包括前端部件的计算***(例如,具有图形用户界面或者网络浏览器的用户计算机,用户可以通过该图形用户界面或者该网络浏览器来与此处描述的***和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算***中。可以通过任何形式或者介质的数字数据通信(例如,通信网络)来将***的部件相互连接。通信网络的示例包括:局域网(LAN)、广域网(WAN)和互联网。
计算机***可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。
应该理解,可以使用上面所示的各种形式的流程,重新排序、增加或删除步骤。例如,本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行,只要能够实现本公开公开的技术方案所期望的结果,本文在此不进行限制。
根据本公开的实施例,本公开还提供了一种路侧设备和一种云控平台。该路侧设备包括本公开实施例的上述电子设备。该云控平台包括本公开实施例的上述电子设备。需要说明的是,路侧设备除了包括电子设备,还可以包括通信部件等,电子设备可以和通信部件一体集成,也可以分体设置。电子设备可以获取感知设备(如路侧相机)的数据,例如图片和视频等,从而进行图像视频处理和数据计算。云控平台在云端执行处理,云控平台包括的电子设备可以获取感知设备(如路侧相机)的数据,例如图片和视频等,从而进行图像视频处理和数据计算;云控平台也可以称为车路协同管理平台、边缘计算平台、云计算平台、中心***、云端服务器等。
上述具体实施方式,并不构成对本公开保护范围的限制。本领域技术人员应该明白的是,根据设计要求和其他因素,可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等,均应包含在本公开保护范围之内。