CN114783187B - 一种智能交通请求和应答方法及装置 - Google Patents

Abstract

本发明公开了一种基于人车交互的智能交通的请求方法和应答方法及装置，涉及至少一个车辆或车外设备。所述请求方法包括：交通数据计算步骤；请求发送步骤；接收应答步骤；交通数据调整步骤；发送确认步骤。所述应答方法包括：交通数据计算步骤；请求接收步骤；发送应答步骤；接收确认步骤。该技术方案可以更加准确地规划车辆和车外人员的交通，提高了交通效率和交通安全性。

Description

一种智能交通请求和应答方法及装置

技术领域

本发明涉及自动驾驶领域，尤其涉及智能交通方法及装置。

背景技术

自动驾驶技术是一种通过计算机实现辅助驾驶或无人驾驶的技术，其依靠可见光相机、毫米波雷达、激光雷达、惯性导航系统、全球定位系统等传感系统，使计算机可以部分或全部代替人类驾驶员自动安全地操作车辆。

现有技术中，自动驾驶技术主要应用于标准道路场景。标准道路例如根据道路交通相关法律法规规定的具有特定标线、标识等信息的道路。在标准道路场景下，自动驾驶技术可以获取规范的道路标线标识等环境感知信息，可以利用规范的地图测绘提供的普通地图和高精度地图，也可以与智能交通系统中的交通基础设施进行规范的信息交换。

但是，自动驾驶技术不仅可以应用在标准道路场景中，也可以应用在非标准道路场景。非标准道路场景例如野外环境等自然场景，例如乡村道路等农业环境场景，例如园区内部道路等场景，例如矿山矿井等特定作业场景。

在非标准道路场景下，车辆和车外人员无法直观地观察到标准道路场景的道路标线、标识等信息，即车辆和车外人员无法利用双方共同遵守的并且可见的交通信息，因而容易出现交通事故。例如，多个车辆会根据自己的位置来自行规划行驶路线，多个车外人员也会根据自己的位置和环境观察来选择行走路线，这些行驶路线和行走路线之间很可能会发送冲突。

此外，现有技术中的集中控制系统，可以对从属于该集中控制系统的多个车辆进行统一的路线规划。但现实中车辆不可能都从属于同一个集中控制系统，特别时行人的私有设备，更不可能从属于某一个车辆的集中控制设备。

因此有必要解决如何自动地在多个独立的车辆和车外人员设备之间进行信息交互和确认的技术问题，以及如何将双方或多方的交通规划数据进行有效的融合的技术问题。

发明内容

本发明提供了一种基于人车交互的智能交通的请求方法和应答方法及装置。

根据本发明的第一方面，提供了一种智能交通的请求方法，涉及至少一个车辆或车外设备，所述车辆或所述车外设备具有对应的交通规划装置，所述交通规划装置以硬件或软件方式部署于以下位置之一：所述车辆本地、所述车外设备本地、第三方设备处，所述方法包括：

交通数据计算步骤：所述交通规划装置获取所述车辆或车外设备的传感器数据，并计算所述车辆或车外设备的交通数据；所述交通数据包括当前位置，还包括以下至少一种：可通行区域、不可通行区域、历史通行路线、拟通行路线；

发送请求步骤：所述交通规划装置作为发送方，其他至少一个交通规划装置作为接收方；所述发送方发送请求信息到所述接收方，所述请求信息包括所述交通数据；

接收应答步骤：所述发送方接收所述接收方发回的应答信息；所述应答信息包括是否同意发送方的请求信息，还包括以下至少一种：发送方的交通数据的建议值；接收方的交通数据；

交通数据调整步骤：根据所述应答信息包括不同意发送方的请求信息，所述发送方根据对方的交通数据调整自己的交通数据；并根据需要再次发送请求信息和接收应答信息；

发送确认步骤：根据所述应答信息包括同意发送方的请求信息，所述发送方向接收方发送确认信息，并进行交通规划并执行。

根据本发明的第二方面，提供了一种智能交通的应答方法，涉及至少一个车辆或车外设备，所述车辆或所述车外设备具有对应的交通规划装置，所述交通规划装置以硬件或软件方式部署于以下位置之一：所述车辆本地、所述车外设备本地、第三方设备处，所述方法包括：

交通数据计算步骤：所述交通规划装置获取所述车辆或车外设备的传感器数据，并计算所述车辆或车外设备的交通数据；所述交通数据包括当前位置，还包括以下至少一种：可通行区域、不可通行区域、历史通行路线、拟通行路线；

接收请求步骤：所述交通规划装置作为接收方，接收发送方的请求信息；所述请求信息包括所述发送方的交通数据；

发送应答步骤：根据接收到的发送方的请求信息，所述接收方生成应答信息；所述应答信息包括是否同意发送方的请求信息，还包括以下至少一种：发送方的交通数据的建议值；接收方的交通数据；所述接收方将所述应答信息发回所述发送方；

接收确认步骤：根据所述应答信息包括同意发送方的请求信息并收到所述发送方的确认信息，所述接收方进行交通规划并执行。

根据本发明的第三方面，提供了一种智能交通的请求装置，涉及至少一个车辆或车外设备，所述车辆或所述车外设备具有对应的交通规划装置，所述交通规划装置以硬件或软件方式部署于以下位置之一：所述车辆本地、所述车外设备本地、第三方设备处，所述请求装置包括：

交通数据计算模块：所述交通规划装置获取所述车辆或车外设备的传感器数据，并计算所述车辆或车外设备的交通数据；所述交通数据包括当前位置，还包括以下至少一种：可通行区域、不可通行区域、历史通行路线、拟通行路线；

发送请求模块：所述交通规划装置作为发送方，其他至少一个交通规划装置作为接收方；所述发送方发送请求信息到所述接收方，所述请求信息包括所述交通数据；

接收应答模块：所述发送方接收所述接收方发回的应答信息；所述应答信息包括是否同意发送方的请求信息，还包括以下至少一种：发送方的交通数据的建议值；接收方的交通数据；

交通数据调整模块：根据所述应答信息包括不同意发送方的请求信息，所述发送方根据对方的交通数据调整自己的交通数据；并根据需要再次发送请求信息和接收应答信息；

发送确认模块：根据所述应答信息包括同意发送方的请求信息，所述发送方向接收方发送确认信息，并进行交通规划并执行。

根据本发明的第四方面，提供了一种智能交通的应答装置，涉及至少一个车辆或车外设备，所述车辆或所述车外设备具有对应的交通规划装置，所述交通规划装置以硬件或软件方式部署于以下位置之一：所述车辆本地、所述车外设备本地、第三方设备处，所述应答装置包括：

交通数据计算模块：所述交通规划装置获取所述车辆或车外设备的传感器数据，并计算所述车辆或车外设备的交通数据；所述交通数据包括当前位置，还包括以下至少一种：可通行区域、不可通行区域、历史通行路线、拟通行路线；

接收请求模块：所述交通规划装置作为接收方，接收发送方的请求信息；所述请求信息包括所述发送方的交通数据；

发送应答模块：根据接收到的发送方的请求信息，所述接收方生成应答信息；所述应答信息包括是否同意发送方的请求信息，还包括以下至少一种：发送方的交通数据的建议值；接收方的交通数据；所述接收方将所述应答信息发回所述发送方；

接收确认模块：根据所述应答信息包括同意发送方的请求信息并收到所述发送方的确认信息，所述接收方进行交通规划并执行。

应当理解，本部分所描述的内容并非旨在标识本发明的实施例的关键或重要特征，也不用于限制本发明的范围。本发明的其它特征将通过以下的说明书而变得容易理解。

与现有技术相比，本发明的有益效果是：

充分利用车载传感器和车外人员设备的传感器，对人车交通环境进行多方多视角的感知，提升了非标准交通场景的信息感知的全面性和准确性；建立了自动化的高效车辆、车外人员设备的多方请求和应答多次握手方式，在没有标准道路标线等人车交通行为规范手段时，通过感知信息的融合，提高了交通效率和交通安全性。

附图说明

附图用于更好地理解本方案，不构成对本发明的限定。其中：

图1示出了根据本公开一个实施例提供的非标准道路场景的示意图；

图2示出了根据本公开一个实施例提供的智能交通的请求方法的示意图；

图3示出了根据本公开一个实施例提供的智能交通的应答方法的示意图；

图4示出了根据本公开一个实施例提供的智能交通的请求方法的示意图；

图5示出了根据本公开一个实施例提供的智能交通的应答方法的示意图；

图6示出了根据本公开一个实施例提供的智能交通的应答方法的示意图；

图7示出了根据本公开一个实施例提供的智能交通的请求装置的示意图；

图8示出了根据本公开一个实施例提供的智能交通的应答装置的示意图；

图9示出了根据本公开一个实施例提供的电子设备的示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

所涉及的技术术语包括：

标准道路场景：标准道路是指符合道路交通相关法律法规规定的、具有特定标线标识等信息的法定道路。标准道路场景下，自动驾驶技术可以通过规范的道路标线、标识等信息来获取准确的道路信息，也可以与交通基础设施进行规范的信息交换，从而获得自动驾驶所必需的环境信息。

非标准道路场景：非标准道路场景是指不具备道路交通相关法律法规规定的标线标识等信息的道路。非标准道路场景，例如野外环境等自然场景，例如乡村土路等农业环境场景，例如园区内部道路等内部场景，又例如矿山矿井等特定作业场景。

传感器数据：传感器数据是指传感器获取到的数据。在本实施例中，根据情况也会特指自动驾驶相关的传感器获取到的数据。常见的传感器例如可见光相机、红外相机、深度相机、毫米波雷达、激光雷达等。传感器数据既可以是直接从传感器中产生的原始传感器数据，也可以是经过预处理、配准、转换、融合、特征提取等处理后的传感器数据。

点云：点云是指点数据的集合。点云可以通过摄影测量原理或激光测量原理获得。根据激光测量原理获得的点云，包括三维坐标（XYZ）和激光回波强度（intensity），根据摄影测量原理获得的点云，包括三维坐标（XYZ）和颜色信息（RGB）。

三维点：三维点是指具有三维坐标属性的点，例如点云中的点即为三维点。

坐标系：在传感器采集时，获取的三维点的坐标系一般是传感器坐标系。根据数据处理的需要，三维点的坐标系有时候需要转换到其他坐标系，例如地面坐标系。

高程数据：高程数据时指描述地形地貌的空间分布的数据；通过等高线或其他立体模型进行数据采集测量，然后将进行数据内插形成；高程数据采集测量可以基于规则网格，或不规则网格。

传感器探测区域：传感器探测区域是车辆在行驶时传感器能够探测到的区域，该区域的地形需要进行测量，以从中发现可供车辆正常行驶的部分区域。传感器探测区域本质上是一个三维曲面。但在实际应用中，常常假设这个三维曲面可以无交叠地投影到水平面上。也就是说，传感器探测区域不包括屋顶、洞顶、天花板等能够造成投影交叠的区域。传感器探测区域常常使用高程数据描述。

可通行区域：可通行区域描述的是传感器探测区域中可以通行的区域。上述可以通行的区域本质上是传感器探测区域的一个子集。为了避免重复存储数据，可通行区域不直接存储传感器探测区域数据本身，而是采用一个取值范围从0到1的实数，来表述对应区域的可通行的程度。当取值趋近于0时，对应区域趋近于完全不可通行，当取值趋近于1时，对应区域趋近于完全可通行。

不可通行区域：不可通行区域描述的是传感器探测区域中不可以通行的区域。不可通行区域是与可通行区域相反的概念。

车外设备：车外设备是指车辆以外的设备。与车外设备对应的车辆设备，是指与车辆行驶相关的车辆设备，例如车辆固有的设备、为自动驾驶等目的而额外安装的设备。车外设备的典型例子是车外人员所持的移动设备，另一个例子是设置在车外设施上、建筑物中的固定设备。另一个特殊例子是，当一个人员携带着移动设备乘坐在一个车辆中时，如果该移动设备并没有参与该车辆的行驶，那么该移动设备相对于其他车辆来说也属于车外设备。

交通规划装置：交通规划装置可以以硬件或软件模块的方式存在。交通规划装置与车辆或车外设备相关，可以是车辆或车外设备中的一个软硬件装置，也可以是位于车辆或车外设备以外，例如服务器上。每个车辆或车外设备都具有与之对应的交通规划装置（软硬件），这些交通规划装置可以都位于服务器上，可以位于同一台服务器上。位于同一台服务器的多个交通规划装置，可以以多个软件模块的形式存在，所述多个软件模块可以位于同一个程序中。多个软件模块也可以是同一个接口，对外与每个车辆或车外装置交互时，根据交互对象的不同而区分为多个软件模块。

请求、应答和确认：请求、应答和确认是为了在多个车辆或车外设备之间建立信息交互而采取的步骤。由于多个车辆或车外设备并非在同一个控制单元的集中控制之下，而多个车辆或车外设备的关系是多个智能体之间的关系。因此多个车辆或车外设备之间建立联系，需要一个双方或多方中的一方首先发出请求，其他方在收到请求之后进行应答，然后请求方再进行确认从而达成共识的过程。请求、应答和确认类似于通信协议中的三次握手，但其交互的内容涉及数据融合，并非三次握手的简单重复。请求、应答和确认的交互并不限于三次，根据说明书方案，可以多次应答、多次交互，实现多次握手。并且在交互达到一定数量、或满足特定条件时，可以进行特定的处理或启动新的处理过程。

实施例一

图1是非标准道路场景的示意图。

目前的现有技术中，自动驾驶技术主要应用于标准道路场景。标准道路场景下，可以通过规范的道路标线、标识等信息来获取准确的道路信息。

非标准道路场景也同样存在着自动驾驶的强劲需求。非标准道路场景，例如野外环境等自然场景，例如乡村土路等农业环境场景，例如园区内部道路等内部场景，又例如矿山矿井等特定作业场景。非标准道路场景中的道路所在地面往往是不平整的、并且容易发生改变。例如在农业环境场景，道路所在地面有可能会随着车辆碾压、雨水侵蚀而起伏变化；又例如在矿山场景，道路所在地面有可能会随着矿物的堆积而改变。

综合来说，非标准道路场景下的智能交通至少存在存在如下困难：非标准道路场景下，无法利用标准道路场景的道路标线、标识、地图等信息，从而就不存在可供车辆之间、以及车辆和行人之间共同遵守的可见交通标识。从而导致每个车辆或行人会根据自己的观察来选择行驶或行走路线，从而增加了发生交通事故的风险。

图2示出了智能交通的请求方法的示意图。

本实施例提供的智能交通的请求方法，包括如下步骤：

S110交通数据计算步骤：所述交通规划装置获取所述车辆或车外设备的传感器数据，并计算所述车辆或车外设备的交通数据；所述交通数据包括当前位置，还包括以下至少一种：可通行区域、不可通行区域、历史通行路线、拟通行路线；

S120发送请求步骤：所述交通规划装置作为发送方，其他至少一个交通规划装置作为接收方；所述发送方发送请求信息到所述接收方，所述请求信息包括所述交通数据；

S130接收应答步骤：所述发送方接收所述接收方发回的应答信息；所述应答信息包括是否同意发送方的请求信息，还包括以下至少一种：发送方的交通数据的建议值；接收方的交通数据；

S140交通数据调整步骤：根据所述应答信息包括不同意发送方的请求信息，所述发送方根据对方的交通数据调整自己的交通数据；并根据需要再次发送请求信息和接收应答信息；

S150发送确认步骤：根据所述应答信息包括同意发送方的请求信息，所述发送方向接收方发送确认信息，并进行交通规划并执行。

图3示出了智能交通的应答方法的示意图。

本实施例提供的智能交通的应答方法，包括如下步骤：

S210交通数据计算步骤：所述交通规划装置获取所述车辆或车外设备的传感器数据，并计算所述车辆或车外设备的交通数据；所述交通数据包括当前位置，还包括以下至少一种：可通行区域、不可通行区域、历史通行路线、拟通行路线；

S220接收请求步骤：所述交通规划装置作为接收方，接收发送方的请求信息；所述请求信息包括所述发送方的交通数据；

S230发送应答步骤：根据接收到的发送方的请求信息，所述接收方生成应答信息；所述应答信息包括是否同意发送方的请求信息，还包括以下至少一种：发送方的交通数据的建议值；接收方的交通数据；所述接收方将所述应答信息发回所述发送方；

S240接收确认步骤：根据所述应答信息包括同意发送方的请求信息并收到所述发送方的确认信息，所述接收方进行交通规划并执行。

本实施例中，请求方法和应答方法的执行主体，涉及至少一个车辆或车外设备，所述车辆或所述车外设备具有对应的交通规划装置，所述交通规划装置以硬件或软件方式部署于以下位置之一：所述车辆本地、所述车外设备本地、第三方设备处。

车外设备是指车辆以外的设备。与车外设备对应的车辆设备，是指与车辆行驶相关的车辆设备，例如车辆固有的设备、为自动驾驶等目的而额外安装的设备。车外设备的典型例子是车外人员所持的移动设备，另一个例子是设置在车外设施上、建筑物中的固定设备。另一个特殊例子是，当一个人员携带着移动设备乘坐在一个车辆中时，如果该移动设备并没有参与该车辆的行驶，那么该移动设备相对于其他车辆来说也属于车外设备。

假设目前的交通场景中，存在车辆C1，行人设备P1。

交通规划装置可以以硬件或软件模块的方式存在。交通规划装置与车辆或车外设备相关，可以是车辆或车外设备中的一个软硬件装置，也可以是位于车辆或车外设备以外，例如服务器上。每个车辆或车外设备都具有与之对应的交通规划装置（软硬件），这些交通规划装置可以都位于服务器上，可以位于同一台服务器上。位于同一台服务器的多个交通规划装置，可以以多个软件模块的形式存在，所述多个软件模块可以位于同一个程序中。多个软件模块也可以是同一个接口，对外与每个车辆或车外装置交互时，根据交互对象的不同而区分为多个软件模块。

所述车辆或车外设备的交通规划装置，向所述车辆或车外设备的用户进行提示，所述提示包括以下至少一种方式：语音提示、图形图像提示、地图提示。

假设目前的交通场景中，车辆C1的交通规划装置是SC1，行人设备P1的交通规划装置是SP1。

所述交通规划装置SC1执行S110交通数据计算步骤：所述交通规划装置SC1获取所述车辆C1的传感器数据，并计算所述车辆C1的交通数据；所述交通数据包括当前位置，还包括以下至少一种：可通行区域、不可通行区域、历史通行路线、拟通行路线；

所述交通规划装置SC1执行S120发送请求步骤：所述交通规划装置SC1作为发送方，其他交通规划装置SP1作为接收方；所述发送方发送请求信息到所述接收方，所述请求信息包括所述交通数据；

所述交通规划装置SP1执行S220接收请求步骤：所述交通规划装置SP1作为接收方，接收发送方SC1的请求信息；所述请求信息包括所述发送方SC1的交通数据；

上述SC1发送请求、SP1接收请求，可以称为“第1次握手”。

所述交通规划装置SP1还执行步骤S210交通数据计算步骤；S210步骤和S220步骤的执行顺序可以任意设置。一种执行顺序是，S220步骤收到请求之后检测交通规划装置SP1对应的交通数据需要获取或更新，因而在S220步骤之后执行步骤S210。另一种执行顺序是，在收到请求之前，车外设备P1或者交通规划装置SP1已经启动了S210步骤的执行。

具体地，所述交通规划装置SP1还执行步骤S210交通数据计算步骤：所述交通规划装置SP1获取所述车外设备P1的传感器数据，并计算所述车外设备P1的交通数据；所述交通数据包括当前位置，还包括以下至少一种：可通行区域、不可通行区域、历史通行路线、拟通行路线；

所述交通规划装置SP1执行S230发送应答步骤：根据接收到的发送方SC1的请求信息，所述接收方SP1生成应答信息；所述应答信息包括是否同意发送方的请求信息，还包括以下至少一种：发送方的交通数据的建议值；接收方的交通数据；所述接收方将所述应答信息发回所述发送方；

所述交通规划装置SC1执行S130接收应答步骤：所述发送方SC1接收所述接收方SP1发回的应答信息；所述应答信息包括是否同意发送方的请求信息，还包括以下至少一种：发送方的交通数据的建议值；接收方的交通数据；

上述SP1发送应答、SC1接收应答，可以称为“第2次握手”。

情况一、假设SP1的应答信息是“同意发送方的请求信息”。

所述交通规划装置SC1执行S150发送确认步骤：根据所述应答信息包括同意发送方的请求信息，所述发送方向接收方发送确认信息，并进行交通规划并执行；

所述交通规划装置SP1执行S240接收确认步骤：根据所述应答信息包括同意发送方的请求信息并收到所述发送方的确认信息，所述接收方进行交通规划并执行；

上述SC1发送确认、SP1接收确认，可以称为“第3次握手”。

至此，双方SC1和SP1经过3次握手达成一致，双方各自按照达成一致的交通规划执行。

情况二、假设SP1的应答信息是“不同意发送方的请求信息”。

所述交通规划装置SC1执行S140交通数据调整步骤：根据所述应答信息包括不同意发送方的请求信息，所述发送方根据对方的交通数据调整自己的交通数据；并根据需要再次发送请求信息和接收应答信息；

所述交通规划装置SC1执行S120发送请求步骤：所述交通规划装置SC1作为发送方，其他交通规划装置SP1作为接收方；所述发送方发送请求信息到所述接收方，所述请求信息包括所述交通数据；

所述交通规划装置SP1执行S220接收请求步骤：所述交通规划装置SP1作为接收方，接收发送方SC1的请求信息；所述请求信息包括所述发送方SC1的交通数据；

SC1发送请求、SP1接收请求，也可以称为“第3次握手”。注意不同于上述“情况一”中的“第3次握手”（有关“确认”的握手）。

而情况二中的“第3次握手”类似于上述“第1次握手”，是有关“请求”的握手。

随后可能发生的是：

SP1发送应答、SC1接收应答，可以称为“第4次握手”，是有关“应答”的握手。

如果SP1的应答信息为“同意发送方的请求信息”，那么再有一次“确认”握手，就可以达成一致了。

SC1发送确认、SP1接收确认，可以称为“第5次握手”，是有关“确认”的握手。

至此，双方SC1和SP1经过5次握手达成一致，双方各自按照达成一致的交通规划执行。

而如果第4次握手后SP1的应答信息为“不同意发送方的请求信息”，那么将继续“请求”、“应答”握手进行下去，最终有可能是7次握手、9次握手等，才能够达成一致。当然后面的实施例也介绍了在交互达到一定数量、或满足特定条件时，可以进行特定的处理或启动新的处理过程。

上述实施例的有益效果包括：建立了自动化的高效车辆、车外人员设备的多方请求和应答多次握手方式，在没有标准道路标线等人车交通行为规范手段时，通过感知信息的融合，提高了交通效率和交通安全性。通过“请求-应答-确认”的交互方式可以在双方或多方之间建立共识。

本实施例并不限定应用场景和具体实现，其可以根据实际情况确定，此处不再赘述。

本实施例可以单独被实施，也可以与其他实施例一起被实施。

实施例二

本实施例对智能交通方法的车外设备请求和车辆应答的情形进行了说明，其余部分与实施例一相同。

假设目前的交通场景中，存在行人设备P1，车辆C1。

假设目前的交通场景中，行人设备P1的交通规划装置是SP1，车辆C1的交通规划装置是SC1。

所述交通规划装置SP1执行S110交通数据计算步骤：所述交通规划装置SP1获取所述车外设备P1的传感器数据，并计算所述车外设备P1的交通数据；所述交通数据包括当前位置，还包括以下至少一种：可通行区域、不可通行区域、历史通行路线、拟通行路线；

所述交通规划装置SP1执行S120发送请求步骤：所述交通规划装置SP1作为发送方，其他交通规划装置SC1作为接收方；所述发送方发送请求信息到所述接收方，所述请求信息包括所述交通数据；

所述交通规划装置SC1执行S220接收请求步骤：所述交通规划装置SC1作为接收方，接收发送方SP1的请求信息；所述请求信息包括所述发送方SP1的交通数据；

上述SP1发送请求、SC1接收请求，可以称为“第1次握手”。

所述交通规划装置SC1还执行步骤S210交通数据计算步骤；S210步骤和S220步骤的执行顺序可以任意设置。一种执行顺序是，S220步骤收到请求之后检测交通规划装置SC1对应的交通数据需要获取或更新，因而在S220步骤之后执行步骤S210。另一种执行顺序是，在收到请求之前，车辆C1或者交通规划装置SC1已经启动了S210步骤的执行。

具体地，所述交通规划装置SC1还执行步骤S210交通数据计算步骤：所述交通规划装置SC1获取所述车辆C1的传感器数据，并计算所述车辆C1的交通数据；所述交通数据包括当前位置，还包括以下至少一种：可通行区域、不可通行区域、历史通行路线、拟通行路线；

所述交通规划装置SC1执行S230发送应答步骤：根据接收到的发送方SP1的请求信息，所述接收方SC1生成应答信息；所述应答信息包括是否同意发送方的请求信息，还包括以下至少一种：发送方的交通数据的建议值；接收方的交通数据；所述接收方将所述应答信息发回所述发送方；

所述交通规划装置SP1执行S130接收应答步骤：所述发送方SP1接收所述接收方SC1发回的应答信息；所述应答信息包括是否同意发送方的请求信息，还包括以下至少一种：发送方的交通数据的建议值；接收方的交通数据；

上述SC1发送应答、SP1接收应答，可以称为“第2次握手”。

情况一、假设SC1的应答信息是“同意发送方的请求信息”。

所述交通规划装置SP1执行S150发送确认步骤：根据所述应答信息包括同意发送方的请求信息，所述发送方向接收方发送确认信息，并进行交通规划并执行；

所述交通规划装置SC1执行S240接收确认步骤：根据所述应答信息包括同意发送方的请求信息并收到所述发送方的确认信息，所述接收方进行交通规划并执行；

上述SP1发送确认、SC1接收确认，可以称为“第3次握手”。

至此，双方SP1和SC1经过3次握手达成一致，双方各自按照达成一致的交通规划执行。

情况二、假设SC1的应答信息是“不同意发送方的请求信息”。

所述交通规划装置SP1执行S140交通数据调整步骤：根据所述应答信息包括不同意发送方的请求信息，所述发送方根据对方的交通数据调整自己的交通数据；并根据需要再次发送请求信息和接收应答信息；

所述交通规划装置SP1执行S120发送请求步骤：所述交通规划装置SP1作为发送方，其他交通规划装置SC1作为接收方；所述发送方发送请求信息到所述接收方，所述请求信息包括所述交通数据；

所述交通规划装置SC1执行S220接收请求步骤：所述交通规划装置SC1作为接收方，接收发送方SP1的请求信息；所述请求信息包括所述发送方SP1的交通数据；

SP1发送请求、SC1接收请求，也可以称为“第3次握手”。注意不同于上述“情况一”中的“第3次握手”（有关“确认”的握手）。

而情况二中的“第3次握手”类似于上述“第1次握手”，是有关“请求”的握手。

随后可能发生的是：

SC1发送应答、SP1接收应答，可以称为“第4次握手”，是有关“应答”的握手。

如果SC1的应答信息为“同意发送方的请求信息”，那么再有一次“确认”握手，就可以达成一致了。

SP1发送确认、SC1接收确认，可以称为“第5次握手”，是有关“确认”的握手。

至此，双方SC1和SP1经过5次握手达成一致，双方各自按照达成一致的交通规划执行。

而如果第4次握手后SC1的应答信息为“不同意发送方的请求信息”，那么将继续“请求”、“应答”握手进行下去，最终有可能是7次握手、9次握手等，才能够达成一致。当然后面的实施例也介绍了在交互达到一定数量、或满足特定条件时，可以进行特定的处理或启动新的处理过程。

本实施例的情况，多见于行人在非标准道路场景中时，看到来往车辆较多，而主动发起与来往车辆间的自动化请求应答联系的情形。

上述实施例的有益效果包括：建立了自动化的高效车辆、车外人员设备的多方请求和应答多次握手方式，在没有标准道路标线等人车交通行为规范手段时，通过感知信息的融合，提高了交通效率和交通安全性。通过“请求-应答-确认”的交互方式可以在双方或多方之间建立共识。

本实施例可以单独被实施，也可以与其他实施例一起被实施。

实施例三

本实施例对智能交通方法的车辆请求和车辆应答的情形进行了说明，其余部分与实施例一相同。

假设目前的交通场景中，存在车辆C1，车辆C2。

假设目前的交通场景中，车辆C1的交通规划装置是SC1，车辆C2的交通规划装置是SC2。

所述交通规划装置SC1执行S110交通数据计算步骤：所述交通规划装置SC1获取所述车辆C1的传感器数据，并计算所述车辆C1的交通数据；所述交通数据包括当前位置，还包括以下至少一种：可通行区域、不可通行区域、历史通行路线、拟通行路线；

所述交通规划装置SC1执行S120发送请求步骤：所述交通规划装置SC1作为发送方，其他交通规划装置SP1作为接收方；所述发送方发送请求信息到所述接收方，所述请求信息包括所述交通数据；

所述交通规划装置SC2执行S220接收请求步骤：所述交通规划装置SC2作为接收方，接收发送方SC1的请求信息；所述请求信息包括所述发送方SC1的交通数据；

上述SC1发送请求、SC2接收请求，可以称为“第1次握手”。

所述交通规划装置SC2还执行步骤S210交通数据计算步骤；S210步骤和S220步骤的执行顺序可以任意设置。一种执行顺序是，S220步骤收到请求之后检测交通规划装置SC2对应的交通数据需要获取或更新，因而在S220步骤之后执行步骤S210。另一种执行顺序是，在收到请求之前，车辆C2或者交通规划装置SC2已经启动了S210步骤的执行。

具体地，所述交通规划装置SC2还执行步骤S210交通数据计算步骤：所述交通规划装置SC2获取所述车外设备P1的传感器数据，并计算所述车辆C2的交通数据；所述交通数据包括当前位置，还包括以下至少一种：可通行区域、不可通行区域、历史通行路线、拟通行路线；

所述交通规划装置SC2执行S230发送应答步骤：根据接收到的发送方SC1的请求信息，所述接收方SC2生成应答信息；所述应答信息包括是否同意发送方的请求信息，还包括以下至少一种：发送方的交通数据的建议值；接收方的交通数据；所述接收方将所述应答信息发回所述发送方；

所述交通规划装置SC1执行S130接收应答步骤：所述发送方SC1接收所述接收方SC2发回的应答信息；所述应答信息包括是否同意发送方的请求信息，还包括以下至少一种：发送方的交通数据的建议值；接收方的交通数据；

上述SC2发送应答、SC1接收应答，可以称为“第2次握手”。

情况一、假设SC2的应答信息是“同意发送方的请求信息”。

所述交通规划装置SC1执行S150发送确认步骤：根据所述应答信息包括同意发送方的请求信息，所述发送方向接收方发送确认信息，并进行交通规划并执行；

所述交通规划装置SC2执行S240接收确认步骤：根据所述应答信息包括同意发送方的请求信息并收到所述发送方的确认信息，所述接收方进行交通规划并执行；

上述SC1发送确认、SC2接收确认，可以称为“第3次握手”。

至此，双方SC1和SC2经过3次握手达成一致，双方各自按照达成一致的交通规划执行。

情况二、假设SC2的应答信息是“不同意发送方的请求信息”。

所述交通规划装置SC1执行S140交通数据调整步骤：根据所述应答信息包括不同意发送方的请求信息，所述发送方根据对方的交通数据调整自己的交通数据；并根据需要再次发送请求信息和接收应答信息；

所述交通规划装置SC1执行S120发送请求步骤：所述交通规划装置SC1作为发送方，其他交通规划装置SC2作为接收方；所述发送方发送请求信息到所述接收方，所述请求信息包括所述交通数据；

所述交通规划装置SC2执行S220接收请求步骤：所述交通规划装置SC2作为接收方，接收发送方SC1的请求信息；所述请求信息包括所述发送方SC1的交通数据；

SC1发送请求、SC2接收请求，也可以称为“第3次握手”。注意不同于上述“情况一”中的“第3次握手”（有关“确认”的握手）。

而情况二中的“第3次握手”类似于上述“第1次握手”，是有关“请求”的握手。

随后可能发生的是：

SC2发送应答、SC1接收应答，可以称为“第4次握手”，是有关“应答”的握手。

如果SC2的应答信息为“同意发送方的请求信息”，那么再有一次“确认”握手，就可以达成一致了。

SC1发送确认、SC2接收确认，可以称为“第5次握手”，是有关“确认”的握手。

至此，双方SC1和SC2经过5次握手达成一致，双方各自按照达成一致的交通规划执行。

而如果第4次握手后SC2的应答信息为“不同意发送方的请求信息”，那么将继续“请求”、“应答”握手进行下去，最终有可能是7次握手、9次握手等，才能够达成一致。当然后面的实施例也介绍了在交互达到一定数量、或满足特定条件时，可以进行特定的处理或启动新的处理过程。

上述实施例的有益效果包括：建立了自动化的高效车辆、车外人员设备的多方请求和应答多次握手方式，在没有标准道路标线等人车交通行为规范手段时，通过感知信息的融合，提高了交通效率和交通安全性。通过“请求-应答-确认”的交互方式可以在双方或多方之间建立共识。

本实施例并不限定应用场景和具体实现，其可以根据实际情况确定，此处不再赘述。

本实施例可以单独被实施，也可以与其他实施例一起被实施。

实施例四

本实施例对智能交通的请求五应答情况进行了详细说明，其余部分与前述实施例相同。

图4示出了智能交通的请求方法的示意图。主要涉及请求无应答的处理。

本实施例提供的智能交通的请求方法，包括如下步骤：

S110交通数据计算步骤：所述交通规划装置获取所述车辆或车外设备的传感器数据，并计算所述车辆或车外设备的交通数据；所述交通数据包括当前位置，还包括以下至少一种：可通行区域、不可通行区域、历史通行路线、拟通行路线；

S120发送请求步骤：所述交通规划装置作为发送方，其他至少一个交通规划装置作为接收方；所述发送方发送请求信息到所述接收方，所述请求信息包括所述交通数据；

S160无应答步骤：在第一预定时间内未收到所述接收方的应答，所述发送方执行交通执行步骤，并同时继续执行发送请求步骤。

上述实施例的有益效果包括：建立了自动化的高效车辆、车外人员设备的多方请求和应答多次握手方式，在没有标准道路标线等人车交通行为规范手段时，提高了交通效率和交通安全性。对于请求无应答的处理，并没有直接忽视对方，而是一方面继续发送请求，一方面在等待一段时间内才开始审慎的行动，提高了交通安全性。

本实施例可以单独被实施，也可以与其他实施例一起被实施。

实施例五

本实施例对智能交通的应答后未收到确认的情形进行了详细说明，其余部分与前述实施例相同。

图5示出了智能交通的应答方法的示意图。主要涉及应答后未收到确认的处理。

本实施例提供的智能交通的应答方法，包括如下步骤：

S210交通数据计算步骤：所述交通规划装置获取所述车辆或车外设备的传感器数据，并计算所述车辆或车外设备的交通数据；所述交通数据包括当前位置，还包括以下至少一种：可通行区域、不可通行区域、历史通行路线、拟通行路线；

S220接收请求步骤：所述交通规划装置作为接收方，接收发送方的请求信息；所述请求信息包括所述发送方的交通数据；

S230发送应答步骤：根据接收到的发送方的请求信息，所述接收方生成应答信息；所述应答信息包括是否同意发送方的请求信息，还包括以下至少一种：发送方的交通数据的建议值；接收方的交通数据；所述接收方将所述应答信息发回所述发送方；

S250无确认步骤，根据所述应答信息包括同意发送方的请求信息并在第二预定时间内未收到所述发送方的确认信息，所述接收方进行交通规划并执行。

上述实施例的有益效果包括：建立了自动化的高效车辆、车外人员设备的多方请求和应答多次握手方式，在没有标准道路标线等人车交通行为规范手段时，提高了交通效率和交通安全性。对于请求应答“同意发送方的请求信息”后未收到确认的处理，由于所述同意的请求信息来自发送方，因此接收方按照该请求信息进行交通，并不会与发送方产生矛盾，因此在等待一段时间内才开始审慎的行动，提高了交通效率和安全性。

本实施例可以单独被实施，也可以与其他实施例一起被实施。

实施例六

本实施例对智能交通的请求和应答中的根据对方的交通数据调整自己的交通数据进行了详细说明，其余部分与前述实施例相同。

假设目前的交通场景中，存在行人设备P1，车辆C1。

假设目前的交通场景中，行人设备P1的交通规划装置是SP1，车辆C1的交通规划装置是SC1。

所述交通规划装置SP1执行S110交通数据计算步骤；

所述交通规划装置SP1执行S120发送请求步骤；

所述交通规划装置SC1执行S220接收请求步骤；

上述SP1发送请求、SC1接收请求，可以称为“第1次握手”。

所述交通规划装置SC1还执行步骤S210交通数据计算步骤。

所述交通规划装置SC1执行S230发送应答步骤；

所述交通规划装置SP1执行S130接收应答步骤；

上述SC1发送应答、SP1接收应答，可以称为“第2次握手”。

假设SC1的应答信息是“不同意发送方的请求信息”。

所述交通规划装置SP1执行S140交通数据调整步骤：根据所述应答信息包括不同意发送方的请求信息，所述发送方根据对方的交通数据调整自己的交通数据；并根据需要再次发送请求信息和接收应答信息；

所述根据对方的交通数据调整自己的交通数据，包括：

响应于所述应答信息包括所述接收方SC1的交通数据，所述发送方SP1根据所述接收方SC1的交通数据，调整所述发送方SP1的交通数据；所述发送方SP1对调整后的发送方SP1的交通数据进行是否可通行的校验，响应于没有通过校验对所述发送方SP1的交通数据进行回调；

所述调整所述发送方SP1的交通数据，具体包括，

响应于所述接收方SC1的交通数据包括当前位置，所述发送方SP1的交通数据中的拟通行路线去除所述接收方SC1的当前位置；所述发送方SP1的交通数据中的可通行区域去除所述接收方SC1的当前位置；所述发送方SP1的交通数据中的不可通行区域加入所述接收方SC1的当前位置；

响应于所述接收方SC1的交通数据包括拟通行路线，所述发送方SP1的交通数据中的拟通行路线去除所述接收方SC1的拟通行路线；所述发送方SP1的交通数据中的可通行区域去除所述接收方SC1的拟通行路线；所述发送方SP1的交通数据中的不可通行区域加入所述接收方SC1的拟通行路线。

在调整自己的交通数据之后，SP1对调整后的交通数据进行是否可通行的校验，包括：

对调整后的交通数据中的拟通行路线、可通行区域进行校验，所述校验包括以下至少一种：能达到预定目的地，不会发生交通事故（例如造成碰撞）。

校验如果没有通过，SP1对交通数据进行回调，所述回调是将交通数据向能满足校验的方向调整，同时又可以满足SP1与SC1之间协商的要求。

其中一种回调的方式包括：

对所述发送方SP1的交通数据进行恢复，将造成没有通过校验的调整进行撤销，获得对发送方SP1最有利的交通数据；以所述发送方SP1的交通数据的拟通行路线，作为对发送方SP1最不利的交通数据；

根据所述对发送方SP1最有利的交通数据、所述发送方SP1最不利的交通数据为插值区间，对所述插值区间进行第一预定数量的等分插值，依次将插值得到的交通数据，作为回调后的交通数据。

举例来说，如果对发送方SP1最有利的可通行区域为面积100的区域，而对发送方SP1最不利的可通行区域为面积10的区域。

对发送方SP1最不利的可通行区域，例如是SP1的拟通行路线，也就是说，SP1只能在拟通行路线上行走，而不能超出这个路线一步。

那么SP1最开始向SC1请求的是面积100的区域，SP1希望能有尽量广阔的行走范围。但该请求发出后，收到了SC1将请求信息与自己的交通信息对比后，应答信息是“不同意”。

在收到第1次SC1的“不同意”应答信息后，SP1第2次向SC1请求的是面积70的区域，SC1将请求信息与自己的交通信息对比后，应答信息仍然是“不同意”。

在收到第2次SC1的“不同意”应答信息后，SP1第3次向SC1请求的是面积40的区域，SC1将请求信息与自己的交通信息对比后，应答信息是“同意”。此后调整结束，进入确认信息发送和接收的握手阶段。

在所述调整结束之后，所述交通规划装置SP1执行S120发送请求步骤；所述交通规划装置SC1执行S220接收请求步骤；即“第3次握手”。随后SCI发送应答、SP1接收应答，即“第4次握手”。对于第3次握手以及以后的交互，与前述实施例相同。

上述实施例的有益效果包括：建立了自动化的高效车辆、车外人员设备的多方请求和应答多次握手方式，在没有标准道路标线等人车交通行为规范手段时，通过感知信息的融合，提高了交通效率和交通安全性。通过“请求-应答-确认”的交互方式可以在双方或多方之间建立共识。而具体的协调过程则包括“一方不同意时另一方进行调整”的过程，这可以有效地尽快达成共识。

上述调整机制是单方调整，即请求方单方调整，而被请求方（应答方）有时候也需要进行调整，该过程可参见实施例七。

本实施例可以单独被实施，也可以与其他实施例一起被实施。

实施例七

本实施例对智能交通的多次应答均为不同意的情形进行了详细说明，其余部分与前述实施例相同。

实施例六中的调整机制是单方调整，即请求方单方调整，而被请求方（应答方）有时候也需要进行调整，即本实施例的内容。

图6示出了智能交通的应答方法的示意图。主要涉及多次应答均为不同意发送方的请求信息的处理。

本实施例提供的智能交通的应答方法，包括如下步骤：

S210交通数据计算步骤：所述交通规划装置获取所述车辆或车外设备的传感器数据，并计算所述车辆或车外设备的交通数据；所述交通数据包括当前位置，还包括以下至少一种：可通行区域、不可通行区域、历史通行路线、拟通行路线；

S220接收请求步骤：所述交通规划装置作为接收方，接收发送方的请求信息；所述请求信息包括所述发送方的交通数据；

S230发送应答步骤：根据接收到的发送方的请求信息，所述接收方生成应答信息；所述应答信息包括是否同意发送方的请求信息，还包括以下至少一种：发送方的交通数据的建议值；接收方的交通数据；所述接收方将所述应答信息发回所述发送方；

S260多次应答步骤，当所述接收方不同意发送方的请求信息的次数超过第二预定数量时，所述接收方调整所述接收方的交通数据，并将调整后的交通数据放入应答信息，发回给所述发送方。

举例来说，如果对发送方SP1最有利的可通行区域为面积100的区域，而对发送方SP1最不利的可通行区域为面积10的区域。

对发送方SP1最不利的可通行区域，例如是SP1的拟通行路线，也就是说，SP1只能在拟通行路线上行走，而不能超出这个路线一步。

那么SP1最开始向SC1请求的是面积100的区域，SP1希望能有尽量广阔的行走范围。但该请求发出后，收到了SC1将请求信息与自己的交通信息对比后，应答信息是“不同意”。

在收到第1次SC1的“不同意”应答信息后，SP1第2次向SC1请求的是面积70的区域，SC1将请求信息与自己的交通信息对比后，应答信息仍然是“不同意”。

在收到第2次SC1的“不同意”应答信息后，SP1第3次向SC1请求的是面积40的区域，SC1将请求信息与自己的交通信息对比后，应答信息仍然是“不同意”。

假设第二预定数量是2次，那么此时接收方SC1发送“不同意”应答消息已经超出2次，因此共识机制要求接收方SC1调整自己的交通数据，具体来说，SC1调整自己的可通行区域、不可通行区域、拟通行路线，使得SP1提出的面积40的可通行区域可以得到满足。一般来说，是缩减SC1的可通行区域，扩大SC1的不可通行区域，必要时调整SC1的拟通行路线。注意：此时SC1不能接受SP1面积为40的区域，而只能调整自己的交通数据，有可能原因是SP1面积为40的可通行区域，虽然面积已经缩小到40，但其具体分布仍然与SC1的拟通行路线有冲突。因此只能提出自己的交通数据供SP1根据对方的交通数据调整自己的交通数据时参考。

此时SC1将在应答消息中包含自己调整后的交通数据（可通行区域、不可通行区域、拟通行路线）。在收到第2次SC1的“不同意”应答信息、和附加的SC1调整后的交通数据后，SP1将根据SC1调整后的交通数据后，重新调整自己的交通数据。调整自己的交通数据的方式参见实施例六。

上述实施例的有益效果包括：建立了自动化的高效车辆、车外人员设备的多方请求和应答多次握手方式，在没有标准道路标线等人车交通行为规范手段时，提高了交通效率和交通安全性。对于请求应答“不同意发送方的请求信息”的次数超过第二预定数量的处理，说明接收方的策略需要进行调整，因此接收方主动调整自己的交通数据，以适应发送方的需求，提高了交通效率。

本实施例可以单独被实施，也可以与其他实施例一起被实施。

实施例八

本实施例对智能交通的计算交通数据进行了详细说明，其余部分与前述实施例相同。

计算所述车辆或车外设备的交通数据，包括：

所述当前位置的计算步骤是，根据所述车辆或车外设备的定位传感器数据计算，或者通过同时定位与建图技术计算；

所述可通行区域和所述不可通行区域的计算步骤是，确定传感器探测区域，根据传感器数据确定三维点数据，将三维点数据的坐标转换到地面坐标系；根据坐标转换后的三维点数据，拟合高程数据；根据高程数据的以下至少一种信息，计算不可通行区域：地形坡度、地形跨度、车辆越野性能、车辆装载要求；从传感器探测区域中去除不可通行区域，获得可通行区域；

所述历史通行路线的计算步骤是，根据所述车辆或车外设备的定位传感器历史数据计算；

所述拟通行路线的计算步骤是，根据所述车辆或车外设备的可通行区域和/或不可通行区域计算拟通行路线。

上述实施例的有益效果包括：充分利用车载传感器和车外人员设备的传感器，对人车交通环境进行多方多视角的感知，提升了非标准交通场景的信息感知的全面性和准确性。建立了自动化的高效车辆、车外人员设备的多方请求和应答多次握手方式，在没有标准道路标线等人车交通行为规范手段时，通过感知信息的融合，提高了交通效率和交通安全性。

本实施例可以单独被实施，也可以与其他实施例一起被实施。

实施例九

针对上述非标准道路场景的问题，本实施例提供了一种智能交通的请求装置，如附图7所示。

涉及至少一个车辆或车外设备，所述车辆或所述车外设备具有对应的交通规划装置，所述交通规划装置以硬件或软件方式部署于以下位置之一：所述车辆本地、所述车外设备本地、第三方设备处，所述请求装置包括：

交通数据计算模块110：所述交通规划装置获取所述车辆或车外设备的传感器数据，并计算所述车辆或车外设备的交通数据；所述交通数据包括当前位置，还包括以下至少一种：可通行区域、不可通行区域、历史通行路线、拟通行路线；

发送请求模块120：所述交通规划装置作为发送方，其他至少一个交通规划装置作为接收方；所述发送方发送请求信息到所述接收方，所述请求信息包括所述交通数据；

接收应答模块130：所述发送方接收所述接收方发回的应答信息；所述应答信息包括是否同意发送方的请求信息，还包括以下至少一种：发送方的交通数据的建议值；接收方的交通数据；

交通数据调整模块140：根据所述应答信息包括不同意发送方的请求信息，所述发送方根据对方的交通数据调整自己的交通数据；并根据需要再次发送请求信息和接收应答信息；

发送确认模块150：根据所述应答信息包括同意发送方的请求信息，所述发送方向接收方发送确认信息，并进行交通规划并执行。

上述装置的各个模块的有益效果参见前述实施例，此处不再赘述。

值得说明的是，本实施例并不限定应用场景的具体实现，其可以根据实际情况确定，此处不再赘述。

需要说明的是，应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。例如，处理模块可以为单独设立的处理元件，也可以集成在上述装置的某一个芯片中实现，此外，也可以以程序代码的形式存储于上述装置的存储器中，由上述装置的某一个处理元件调用并执行以上处理模块的功能。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起，也可以独立实现。这里所述的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

本实施例可以单独被实施，也可以与其他实施例一起被实施。

实施例十

针对上述非标准道路场景的问题，本实施例提供了一种智能交通的应答装置，如附图8所示。

涉及至少一个车辆或车外设备，所述车辆或所述车外设备具有对应的交通规划装置，所述交通规划装置以硬件或软件方式部署于以下位置之一：所述车辆本地、所述车外设备本地、第三方设备处，所述应答装置包括：

交通数据计算模块210：所述交通规划装置获取所述车辆或车外设备的传感器数据，并计算所述车辆或车外设备的交通数据；所述交通数据包括当前位置，还包括以下至少一种：可通行区域、不可通行区域、历史通行路线、拟通行路线；

接收请求模块220：所述交通规划装置作为接收方，接收发送方的请求信息；所述请求信息包括所述发送方的交通数据；

发送应答模块230：根据接收到的发送方的请求信息，所述接收方生成应答信息；所述应答信息包括是否同意发送方的请求信息，还包括以下至少一种：发送方的交通数据的建议值；接收方的交通数据；所述接收方将所述应答信息发回所述发送方；

接收确认模块240：根据所述应答信息包括同意发送方的请求信息并收到所述发送方的确认信息，所述接收方进行交通规划并执行。

上述装置的各个模块的有益效果参见前述实施例，此处不再赘述。

值得说明的是，本实施例并不限定应用场景的具体实现，其可以根据实际情况确定，此处不再赘述。

需要说明的是，应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。例如，处理模块可以为单独设立的处理元件，也可以集成在上述装置的某一个芯片中实现，此外，也可以以程序代码的形式存储于上述装置的存储器中，由上述装置的某一个处理元件调用并执行以上处理模块的功能。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起，也可以独立实现。这里所述的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

本实施例可以单独被实施，也可以与其他实施例一起被实施。

实施例十一

如图9所示，在本实施例中，一种电子设备600，包括：

至少一个处理器601，存储器608，以及与其他电子设备通信的接口609；所述存储器608存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述电子设备能够执行前述实施例中的方法。

电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本发明的实现。该电子设备可以是上述的第一设备，也可以是车辆控制设备，或者车辆上的控制中心，对此本方案不做限制。

如图9所示，该电子设备还包括：一个或多个ROM602、RAM603、 总线、I/O接口、输入单元606、输出单元607等，以及用于连接各部件的 接口，包括高速接口和低速接口，以及与其他电子设备进行通信的接口。 各个部件利用不同的总线互相连接，并且可以被安装在公共主板上或者根 据需要以其它方式安装。处理器可以对在电子设备内执行的指令进行处理， 包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如，耦合至 接口的显示设备)上显示GUI的图形信息的指令。在其它实施方式中，若 需要，可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使 用。同样，可以连接多个电子设备，各个设备提供部分必要的操作(例如， 作为服务器阵列、一组刀片式服务器、或者多处理器系统)。本实施例中以 一个处理器601为例。

存储器608即为本发明所提供的非瞬时计算机可读存储介质。其中，所述存储器存储有可由至少一个处理器执行的指令，以使所述至少一个处理器执行本发明所提供的方法。本发明的非瞬时计算机可读存储介质存储计算机指令，该计算机指令用于使计算机执行本发明所提供的方法。存储器608作为一种非瞬时计算机可读存储介质，可用于存储非瞬时软件程序、 非瞬时计算机可执行程序以及模块，如本实施例中的方法对应的程序指令/模块。处理器601通过运行存储在存储器608中的非瞬时软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例中的方法。

存储器608可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据自动驾驶车辆的控制的电子设备的使用所创建的数据等。此外，存储器608可以包括高速随机存取存储器，还可以包括非瞬时存储器，例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。在一些实施例中，存储器608可选包括相对于处理器601远程设置的存储器，这些远程存储器可以通过网络连接至数据处理的电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

电子设备的各个部件可以通过总线或者其他方式连接，本实施例中以通过总线连接为例。

输入单元606可接收输入的数字或字符信息，以及产生与数据处理的电子设备的用户设置以及功能控制有关的键信号输入，例如触摸屏、小键盘、鼠标、轨迹板、触摸板、指示杆、一个或者多个鼠标按钮、轨迹球、操纵杆等输入装置。输出单元607可以包括显示设备、辅助照明装置(例如，LED)和触觉反馈装置(例如，振动电机)等。该显示设备可以包括但不限于，液晶显示器(LCD)、发光二极管(LED)显示器和等离子体显示器。在一些实施方式中，显示设备可以是触摸屏。

本实施例可以单独被实施，也可以与其他实施例一起被实施。

实施例十二

根据本实施例提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行根据前述实施例所述方法。

本实施例可以单独被实施，也可以与其他实施例一起被实施。

实施例十三

根据本实施例提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据前述实施例所述的方法。

上述实施例所述的存储有计算机程序的计算机可读存储介质和计算机程序产品，这些计算程序(也称作程序、软件、软件应用、或者代码)包括可编程处理器的机器指令，并且可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。如本文使用的，术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如，磁盘、光盘、存储器、可编程逻辑装置(PLD))，包括，接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。本实施例对其不做具体限定。

本实施例可以单独被实施，也可以与其他实施例一起被实施。

实施例十四

根据本实施例提供了一种自动驾驶车辆，包括上述实施例所述的装置。

可以理解的是，本实施例同样适用于有人驾驶车辆，有人驾驶车辆可以基于获取到的道路信息以提供给驾驶员提示或自动控制等形式辅助控制车辆的运行。其中，有些车辆内设置有行车电脑或车载单元(on board unit，OBU)，有些车辆内搭载有用户终端例如手机，以及持有用户终端的用户等。车辆内的手机、行车电脑或OBU可作为实施上述方案的电子设备。

可以理解的是，本实施例同样适用于智能交通网络中，该智能交通网络中可以包括多辆可以进行无线通信的车辆、和各个车辆进行无线通信的交通控制设备、远程服务器、路侧设备、基站，其中，远程服务器或交通控制设备还可以对交通设施进行控制等等。

本实施例并不对车辆的类型、数量、应用场景进行限定。

本实施例可以单独被实施，也可以与其他实施例一起被实施。

应该理解，本发明描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、专用ASIC(专用集成电路)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数 据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。可以将本发明描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据 服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界 面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。计算系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计 算机程序来产生客户端和服务器的关系。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发明中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本发明公开的技术方案所期望的结果，本发明在此不进行限制。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (6)

1.一种智能交通的请求方法，涉及至少一个车辆或车外设备，所述车辆或所述车外设备具有对应的交通规划装置，所述交通规划装置以硬件或软件方式部署于以下位置之一：所述车辆本地、所述车外设备本地、第三方设备处，所述方法包括：

交通数据计算步骤：所述交通规划装置获取所述车辆或车外设备的传感器数据，并计算所述车辆或车外设备的交通数据；所述交通数据包括当前位置，还包括以下至少一种：可通行区域、不可通行区域、历史通行路线、拟通行路线；所述当前位置的计算步骤是，根据所述车辆或车外设备的定位传感器数据计算，或者通过同时定位与建图技术计算；所述可通行区域和所述不可通行区域的计算步骤是，确定传感器探测区域，根据传感器数据确定三维点数据，将三维点数据的坐标转换到地面坐标系；根据坐标转换后的三维点数据，拟合高程数据；根据高程数据的以下至少一种信息，计算不可通行区域：地形坡度、地形跨度、车辆越野性能、车辆装载要求；从传感器探测区域中去除不可通行区域，获得可通行区域；所述历史通行路线的计算步骤是，根据所述车辆或车外设备的定位传感器历史数据计算；所述拟通行路线的计算步骤是，根据所述车辆或车外设备的可通行区域和/或不可通行区域计算拟通行路线；

发送请求步骤：所述交通规划装置作为发送方，其他至少一个交通规划装置作为接收方；所述发送方发送请求信息到所述接收方，所述请求信息包括所述交通数据；

接收应答步骤：所述发送方接收所述接收方发回的应答信息；所述应答信息包括是否同意发送方的请求信息，还包括以下至少一种：发送方的交通数据的建议值；接收方的交通数据；所述应答信息，是在所述接收方不同意发送方的请求信息的次数超过第二预定数量时，所述接收方根据对方的交通数据调整自己的交通数据，并将调整后的交通数据放入应答信息，发回给所述发送方；

交通数据调整步骤：根据所述应答信息包括不同意发送方的请求信息，所述发送方根据对方的交通数据调整自己的交通数据；并根据需要再次发送请求信息和接收应答信息；

发送确认步骤：根据所述应答信息包括同意发送方的请求信息，所述发送方向接收方发送确认信息，并进行交通规划并执行；

无应答步骤：在第一预定时间内未收到所述接收方的应答，所述发送方执行交通执行步骤，并同时继续执行发送请求步骤。

2.根据权利要求1所述的方法，所述交通数据调整步骤，还包括对调整后的交通数据进行校验，具体包括：

对调整后的交通数据中的拟通行路线、可通行区域进行校验，所述校验包括以下至少一种：能达到预定目的地，不会发生交通事故。

3.根据权利要求2所述的方法，还包括：

响应于没有通过校验对所述交通数据进行回调，以满足校验要求。

4.一种智能交通的应答方法，涉及至少一个车辆或车外设备，所述车辆或所述车外设备具有对应的交通规划装置，所述交通规划装置以硬件或软件方式部署于以下位置之一：所述车辆本地、所述车外设备本地、第三方设备处，所述方法包括：

交通数据计算步骤：所述交通规划装置获取所述车辆或车外设备的传感器数据，并计算所述车辆或车外设备的交通数据；所述交通数据包括当前位置，还包括以下至少一种：可通行区域、不可通行区域、历史通行路线、拟通行路线；所述当前位置的计算步骤是，根据所述车辆或车外设备的定位传感器数据计算，或者通过同时定位与建图技术计算；所述可通行区域和所述不可通行区域的计算步骤是，确定传感器探测区域，根据传感器数据确定三维点数据，将三维点数据的坐标转换到地面坐标系；根据坐标转换后的三维点数据，拟合高程数据；根据高程数据的以下至少一种信息，计算不可通行区域：地形坡度、地形跨度、车辆越野性能、车辆装载要求；从传感器探测区域中去除不可通行区域，获得可通行区域；所述历史通行路线的计算步骤是，根据所述车辆或车外设备的定位传感器历史数据计算；所述拟通行路线的计算步骤是，根据所述车辆或车外设备的可通行区域和/或不可通行区域计算拟通行路线；

接收请求步骤：所述交通规划装置作为接收方，接收发送方的请求信息；所述请求信息包括所述发送方的交通数据；

发送应答步骤：根据接收到的发送方的请求信息，所述接收方生成应答信息；所述应答信息包括是否同意发送方的请求信息，还包括以下至少一种：发送方的交通数据的建议值；接收方的交通数据；所述接收方将所述应答信息发回所述发送方；

接收确认步骤：根据所述应答信息包括同意发送方的请求信息并收到所述发送方的确认信息，所述接收方进行交通规划并执行；

无确认步骤，根据所述应答信息包括同意发送方的请求信息并在第二预定时间内未收到所述发送方的确认信息，所述接收方进行交通规划并执行；

多次不同意应答步骤，当所述接收方不同意发送方的请求信息的次数超过第二预定数量时，所述接收方根据对方的交通数据调整自己的交通数据，并将调整后的交通数据放入应答信息，发回给所述发送方。

5.根据权利要求4所述的方法，所述根据对方的交通数据调整自己的交通数据，包括：

响应于对方的交通数据包括当前位置，自己的交通数据中的拟通行路线去除对方的当前位置；自己的交通数据中的可通行区域去除对方的当前位置；自己的交通数据中的不可通行区域加入对方的当前位置；

响应于对方的交通数据包括拟通行路线，自己的交通数据中的拟通行路线去除对方的拟通行路线；自己的交通数据中的可通行区域去除对方的拟通行路线；自己的交通数据中的不可通行区域加入对方的拟通行路线。

6.根据权利要求4所述的方法，还包括：

所述车辆或车外设备的交通规划装置，向所述车辆或车外设备的用户进行提示，所述提示包括以下至少一种方式：语音提示、图形图像提示、地图提示。

Images