CN111242475A - 一种基于最小状态集的无人出租车交互系统及方法 - Google Patents

Abstract

本发明提供一种基于最小状态集的无人出租车交互系统及方法，其中系统包括无人驾驶出租车应用端、车机决策中间层和客户端，其特征在于，还包括云端服务器，所述云端服务器用于实现无人出租车服务数据交换功能，包括数据库、车机接口和应用接口。本发明提出的基于最小状态集的无人出租车交互系统及方法，关注无人出租车的实际运营现状，针对无人驾驶场景，在已经拥有技术完备的无人驾驶智能车辆的基础之上，对出租车服务应用进行系统化的设计，该设计包含：系统的架构、服务器功能组成、数据库内容、接口功能、无人车基础功能定义、车辆状态定义、车辆状态转移及应用基础功能设计等几方面。

Description

一种基于最小状态集的无人出租车交互系统及方法

技术领域

本发明涉及智能汽车的技术领域，具体地说是一种基于最小状态集的无人出租车交互系统及方法。

背景技术

无人驾驶技术的迅猛发展带动了无人驾驶的相关应用的推进。尽管智能驾驶领域的竞争区域白热化，但无人驾驶的各类场景应用仍旧处于起步阶段。无人驾驶中的一个重要的应用场景就是自动驾驶出租车——RoboTaxi。

在国内外，很多公司已经开始试验自动驾驶出租车服务。在大洋彼岸的美国，如Zoox、AutoX、小马智行(Pony.ai)、Waymo等公司，国内，如百度、滴滴等公司都在试验RoboTaxi服务。

当前针对有人驾驶的出行服务应用，如滴滴出行、首汽约车等，乘客实现约车服务主要是通过与司机的应用交互，实现车辆的预约、接单、出行等服务过程。但RoboTaxi服务与之不同，无人驾驶车辆缺少了“司机”对于约车服务的控制，直接使用有人驾驶的出行应用无法使用无人车实现自动出行服务功能。必须对原有约车服务逻辑框架进行改进。

现有无人车的约车(或称招车)系统的技术或已授权专利，或者注重的是应用程序对于无人驾驶车辆的控制设计、或者注重的是约车应用的数据通信服务的设计、再或者是侧重于网络拓扑结构的设计，并没有涉及无人车约车服务应用本身的功能逻辑并针对于实用性、便利性及推广性的设计。

申请号为CN105730453A的发明专利公开一种基于三层架构的智能汽车交互系统，包括:车载信息模块：车载信息模块位于车辆内部，包括图像模块、导航模块、雷达及决策模块；交互中间模块：交互中间层是建立在智能车与移动端之间进行交互的程序，用于对接智能车导航、雷达、图像、决策等各组接口，提供移动端交互程序一个稳定的数据接口；交互中间模块从智能车导航、雷达、图像各组接收车辆数据并进行必要的处理。该系统的缺点是未涉及无人车提供乘客乘坐服务的交互功能设计，不能进行车辆预约、乘坐及去往目的地的交互逻辑设计，不能实现车辆自动运送乘客的无人出租车功能。

申请号为CN201810149216的发明申请公开一种无人驾驶接驳车约车系统及方法，其系统包括智能约车模块，还包括以下模块：用于控制无人驾驶接驳车的汽车控制模块；用于实现无人驾驶功能的无人驾驶接驳车模块；用于处理约车订单的网络约车模块；包括服务器和/或网络通讯模块的网络通讯模块。在无人驾驶接驳车原本具有的自动驾驶功能、停障功能、避障功能等功能的基础上，通过基于云端服务的无人驾驶接驳车约车系统，实现手机约(叫)车服务。该系统缺点是设计了无人驾驶接驳车的约车方法，但接驳车服务与出租车服务有较大区别，接驳车需要在固定线路上行驶，即车辆行驶路线是固定的，且行驶线路上设定固定站点，乘客需在站点约车乘车，因此无人接驳车服务无法代替无人出租车服务。另外，该系统过多关注无人车车本身的硬件设计及接驳功能的实现，对并未涉乘客与车辆的交互逻辑设计，因此也未设计车辆的状态转换，车辆只能在既定线路上运行，站点上下乘客。出现乘客未到达、未上车或多人同时进行约车请求等情况，系统未有考虑。

申请号为CN201810871255的发明申请公开一种基于车联网的网约无人驾驶车辆方法及车联网系统。该系统设计了一套车联网系统，包括用户终端设备、服务服务器、管理服务器、传感网络通信服务器以及感知控制模块，所述感知控制模块以及传感网络通信服务器均安装于无人驾驶车辆中，车辆使用多种传感器以感知车辆本身情况，并实现安全行驶。另外，系统实现了简单的约车功能，即乘车人发送指令，车辆到达乘车人所在地，乘车人上车的过程。该系统的缺点是，无法提供完整的无人驾驶出租车服务，即系统设计中未涉及车辆如何运送乘客到达目的地，如何在乘客离开后开启下一轮服务的功能，因此该系统仅仅实现了网约无人车，不能实现自动驾驶出租车服务。而且，车辆运行依托于系统的车联网平台，对网络实时性要求较高，不利于投入实际运营。

发明内容

为了解决上述的技术问题，本发明提出的基于最小状态集的无人出租车交互系统及方法，关注无人出租车的实际运营现状，针对无人驾驶场景，在已经拥有技术完备的无人驾驶智能车辆的基础之上，对无人出租车服务应用进行系统化的设计，该设计包含：系统的架构、服务器功能组成、数据库内容、接口功能、无人车基础功能定义、车辆状态定义、车辆状态转移及应用基础功能设计等几方面，使用本发明提供的交互系统及方法，可将普通无人车，转变为提供完备服务与最优设计的、可实际运营的无人出租车。

本发明的第一目的是提供一种基于最小状态集的无人出租车交互系统，包括无人驾驶出租车应用端、车机决策中间层、客户端和云端服务器，所述云端服务器用于实现无人出租车服务数据交换功能，包括数据库、车机接口和应用接口。

优选的是，所述数据库为自动驾驶出租车服务最小化数据库，该数据库仅包含车辆信息表、车辆决策数据表和租车订单数据表。

在上述任一方案中优选的是，所述车辆信息表包括事先定义的基本车辆信息、车辆运行数据和车辆状态。

在上述任一方案中优选的是，定义所述车辆状态的方法是将当前状态存储在车辆信息表中。定义无人出租车车辆的基本状态为最小状态集，所述最小状态集仅包含不可约状态、可约状态、已约状态和运营状态。

在上述任一方案中优选的是，所述不可约状态表示该无人驾驶出租车不可预约运营，在车辆因故障、充电、加油或未在运营区等条件下，自动由车机将该状态上传至车辆信息表。

在上述任一方案中优选的是，所述可约状态表示车辆能够提供服务。车辆只有在该状态下，所述客户端能够对车辆进行租车下单服务。

在上述任一方案中优选的是，所述已约状态表示车辆已经被下单，并被乘车人占用，车辆即将行驶到乘车人所在区域，但乘车人并未上车。

在上述任一方案中优选的是，所述运营状态表示乘车人已经上车并准备就绪，车辆将驶向或正在驶向乘车人指定的目的地。

在上述任一方案中优选的是，所述最小状态集的四种状态需按逻辑流程转换，其中所有状态都可转变为所述不可约状态，所述不可约状态只能转换为可约状态，不能直接转换成其他状态。

在上述任一方案中优选的是，当需要扩展更多功能时，通过对所述最小状态集中的某一状态进行细分，生成扩充状态集。

在上述任一方案中优选的是，所述车机接口用于进行所述服务器和所述无人出租车的数据通信，包括以下功能：

①接收来自车机指令转换模块上传的车辆数据，并存储至所述车辆信息表；

②将所述车辆决策数据表中的决策数据下发至所述车机指令转换模块。

在上述任一方案中优选的是，所述应用接口用于实现服务器与终端应用设备数据通信，包括以下功能：

①上传所述车辆信息表中车辆数据给所述客户端进行车辆信息展示；

②获取所述客户端上传的决策数据，并存储至所述车辆决策数据表；

③提供所述客户端对于租车订单的增删改查功能。

在上述任一方案中优选的是所述车机决策中间层具有将车机数据转换为标准格式、将决策数据转换为车机指令和网络通信中至少一种功能。

本发明的第二目的是提供一种基于最小状态集的无人出租车交互方法，包括使用客户端预约无人出租车，其特征在于，还包括以下步骤：

步骤1：等待所述无人出租车到达；

步骤2：乘坐所述无人出租车前往目的地；

步骤3：到达目的地后在所述客户端上操作任务完成；

所述方法在如第一目的所述的系统上实施。

本发明的第三目的是提供一种基于最小状态集的无人出租车交互方法，包括云服务器接收客户端发送过来的无人出租车交互信息，其特征在于，还包括以下步骤：

步骤1：查找符合条件的无人出租车；

步骤2：指派所述符合条件的无人出租车前往出发地，并将该出租车的车辆信息表中的车辆状态修改为已约状态；

步骤3：到达出发地，当乘客上车时，将该出租车的所述车辆信息表中的车辆状态修改为运营状态；

步骤4：到达目的地，当乘客下车时，将该出租车的所述车辆信息表中的车辆状态修改为可约状态；

所述方法在如第一目的所述的系统上实施。

优选的是，所述条件包括所述车辆状态处于已约状态，并且预计到达出发地的时间最少。

本发明提出了一种基于最小状态集的无人出租车交互系统及方法，对无人驾驶网约车应用服务进行详细的设计，包含了无人车车辆、云端服务器、车机决策中间层和移动应用程序四个层级的具体功能定义，租车运营服务的整个流程设计等，旨在实现功能逻辑完备、便于推广、最优化设计、真正可用的无人车租车运营服务。若设计更多功能，仍旧可以再此设计基础上进行功能扩展。

附图说明

图1为按照本发明的基于最小状态集的无人出租车交互系统的一优选实施例的模块图。

图2为按照本发明的基于最小状态集的无人出租车交互方法的客户端使用方法的一优选实施例的流程图。

图3为按照本发明的基于最小状态集的无人出租车交互方法的服务器应用方法的一优选实施例的流程图。

图4为按照本发明的基于最小状态集的无人出租车交互系统的一优选实施例的系统架构设计图。

图5为按照本发明的基于最小状态集的无人出租车交互系统的如图4所示实施例的系统数据传输设计图。

图6为按照本发明的基于最小状态集的无人出租车交互系统的如图4所示实施例的用最小状态集的租车服务流程与状态转换示意图。

图7为按照本发明的基于最小状态集的无人出租车交互系统的一优选实施例的RoboTaxi状态集示意图。

图8为按照本发明的基于最小状态集的无人出租车交互系统的如图7所示实施例的使用扩充状态集的租车服务流程与状态转换示意图。

具体实施方式

下面结合附图和具体的实施例对本发明做进一步的阐述。

实施例一

如图1所示，一种基于最小状态集的无人出租车交互系统包括无人驾驶出租车应用端100、车机决策中间层110、云端服务器120和客户端130。

出租车应用端100用于与车机决策中间层110进行数据交换。

车机决策中间层110具有将车机数据转换为标准格式、将决策数据转换为车机指令和网络通信中至少一种功能。

云端服务器120用于实现无人出租车服务数据交换功能，包括数据库121、车机接口122和应用接口123。

数据库121为自动驾驶出租车服务最小化数据库，数据库121仅包含车辆信息表、车辆决策数据表和租车订单数据表。车辆信息表包括事先定义的基本车辆信息、车辆运行数据和车辆状态，定义所述车辆状态的方法是将当前状态存储在车辆信息表中。定义无人出租车车辆的基本状态为最小状态集，所述最小状态集仅包含不可约状态、可约状态、已约状态和运营状态。最小状态集的四种状态需按逻辑流程转换，其中所有状态都可转变为所述不可约状态，所述不可约状态只能转换为可约状态，不能直接转换成其他状态。当需要扩展更多功能时，通过对所述最小状态集中的某一状态进行细分，生成扩充状态集

(1)不可约状态表示该无人驾驶出租车不可预约运营，在车辆因故障、充电、加油或未在运营区等条件下，自动由车机将该状态上传至车辆信息表。

(2)可约状态表示车辆能够提供服务。车辆只有在该状态下，所述客户端能够对车辆进行租车下单服务。

(3)已约状态表示车辆已经被下单，并被乘车人占用，车辆即将行驶到乘车人所在区域，但乘车人并未上车。

(4)运营状态表示乘车人已经上车并准备就绪，车辆将驶向或正在驶向乘车人指定的目的地。

车机接口122用于进行所述服务器和所述无人出租车的数据通信，包括以下功能：①接收来自车机指令转换模块上传的车辆数据，并存储至所述车辆信息表；②将所述车辆决策数据表中的决策数据下发至所述车机指令转换模块。

应用接口123用于实现服务器与终端应用设备数据通信，包括以下功能：①上传所述车辆信息表中车辆数据给所述客户端进行车辆信息展示；②获取所述客户端上传的决策数据，并存储至所述车辆决策数据表；③提供所述客户端对于租车订单的增删改查功能。

客户端130是车辆与用户交互的媒介，被服务人通过客户端130获取并完成无人出租车服务。客户端130需具备车辆信息图形化展示，车辆位置信息的地图展示，订单的增删改查，订单执行时将订单不同状态转换成车辆决策指令等功能。

实施例二

如图2所示，乘客预约无人出租车的方法步骤如下：

执行步骤200，乘客使用客户端登录基于最小状态集的无人出租车交互系统，预约无人出租车，将约车信息通过应用接口发送给云服务器。

执行步骤210，等待所述无人出租车到达。

执行步骤220，乘坐所述无人出租车前往目的地；

执行步骤230，到达目的地后在所述客户端上操作任务完成

实施例三

如图3所示，系统分配无人出租车的方法步骤如下：

执行步骤300，云服务器接收客户端发送过来的无人出租车交互信息。

执行步骤310，查找符合条件的无人出租车，条件包括所述车辆状态处于已约状态，并且预计到达出发地的时间最少。

执行步骤320，指派符合条件的无人出租车前往乘客所在地，并将该出租车的车辆信息表中的车辆状态修改为已约状态。

执行步骤330，到达出发地，当乘客上车时，将该出租车的车辆信息表中的车辆状态修改为运营状态。

执行步骤340，到达目的地，当乘客下车时，将该出租车的车辆信息表中的车辆状态修改为可约状态。

实施例四

目前，随着社会的不断发展，为方便人们出行，越来越多的约车租车服务出现在人们的生活当中。在已有的相关应用(如滴滴出行，首汽约车等)，需要乘车人在移动终端应用APP中输入上车地点以及目的地点，订单提交后，周围的空闲车辆才会由司机进行应答并驾驶前来，最终将用户带至目的地点，完成服务。

上述租车服务应用无法直接使用在基于无人驾驶车辆的租车服务场景中，原因是：无人驾驶车辆并不存在司机，因此没有司机对租车服务整个流程的管理和控制，换句话说，整个租车服务流程并没有司机对于整个约车租车订单的各种操作(如确认接单、到达乘车点、到达目的地等等)，而且也无法实现司机和用户的沟通和交互的设计。

本发明旨在针对无人驾驶场景，在已经拥有技术完备的无人驾驶智能车辆的基础之上，对租车服务应用进行系统化的设计。该设计包含：系统的架构、服务器功能组成、数据库内容、接口功能、无人车基础功能定义、车辆状态定义及应用基础功能定义等几方面。该发明对自动驾驶租车应用服务进行详细的设计，旨在实现功能逻辑完备、便于推广的出行服务，并且更多功能方便再此基础上进行扩展。

本发明内容为基于四层架构的自动驾驶出租车交互设计，设计了自动驾驶出租车——RoboTaxi的一整套基础解决方法，该方法将自动驾驶出租车系统分为四个层级，分别是无人驾驶车辆、车机决策中间层、云端服务器及租车程序，如图4所示。方法对每部分的基本功能进行了详细的定义和描述，另外，对于四个层级协同完成自动驾驶出租车服务的整个过程进行了说明。整个系统四个层级的协同工作，简单的来讲就是，车机决策中间层将车辆信息转换为标准数据发送至云端服务器，云端服务器同时接收来自租车程序的约车指令，并下发给车机决策中间层并转换成车机指令来决策无人车运行。

云端服务器、无人车、车机决策中间层及租车程序四部分的基本说明如下：

1.云端服务器：实现无人出租车服务数据交换功能，该部分包含数据库、出租车车机接口和出租车应用接口三部分。

定义数据库部分为自动驾驶出租车服务最小化数据库。该数据库仅包含车辆信息表、车辆决策数据表、租车订单数据表三个表。其中车辆信息表在事先定义基本的车辆信息外，车辆运行数据来自于车机通过接口上传的车辆实时运行数据；车辆决策数据表用于存储车辆决策指令；约车订单数据表用于存储租车订单数据。该数据库在保证自动出租车实现服务的同时，最小化的设计为该系统信息存储和数据运算提供最轻量化、最便捷解决方法，可以降低数据冗余度、减小系统资源开销、提升处理速度以及便于扩展。

出租车车机接口(简称车机接口)承担服务器和车辆数据通信的任务，主要功能包含两部分：①接收来自车机指令转换系统上传的车辆数据，并存储至车辆信息表；②承担车辆决策数据表中决策数据下发至车机指令转换系统的任务。

出租车应用接口(应用接口)实现服务器与终端应用设备数据通信的功能。主要功能包含：①上传车辆信息表中车辆数据给应用程序进行车辆信息展示；②获取应用程序上传的决策数据，并存储至车辆决策数据表；③提供应用程序对于租车订单的增删改查功能。

两种针对自动驾驶出租车设计的接口能够专门针对出租车应用提供必要的技术保障。

2.无人车：即无人驾驶车辆，为自动驾驶出租车的车辆本身。无人出租车车辆需具备基本的无人驾驶功能(路径规划、避障等)。普通的无人驾驶车辆无需进行复杂的系统改造，便可投入该自动出租车系统运营。

3.车机决策中间层：该部分主要功能包含车机数据转换为标准格式、决策数据转换为车机指令、网络通信三部分。无人车的导航、图像、雷达数据由于格式差异，无法直接上传至服务器，因此车机决策中间层将上述数据转换为标准数据格式，通过网络通信模块上传至服务器；服务器下发的决策指令发送至车机决策中间层，转换为决策指令引导无人车运行。

3.租车程序(移动应用APP)：车辆与用户交互的媒介，被服务人通过移动应用程序获取并完成无人出租车服务。该应用程序需具备车辆信息图形化展示，车辆位置信息的地图展示，订单的增删改查，订单执行时将订单不同状态转换成车辆决策指令等功能。

整个系统的数据传输流转设计如图5所示。

在包含了以上四个层级的无人出租车系统后，整个无人出租车营运服务基本设计如下：

定义车辆状态，并将当前状态存储在车辆信息表中。定义无人出租车车辆的基本状态为最小状态集，且至少包含：不可约、可约、已约、运营四种状态。无人车的状态切换大部分需由用户操作订单来实现。其中：

不可约状态：表示车辆不可预约运营，在车辆因故障、充电、加油或未在运营区等条件下，由车辆在以上条件下，自动由车机将该状态上传至车辆信息表，也可由车辆管理者或平台管理员进行设置。车辆在该状态下，应用程序无法查询到车辆或无法对车辆进行租车下单操作。

可约状态：表示车辆可以提供服务。车辆只有在该状态下，应用程序才可以对车辆进行租车下单服务。

已约状态：表示车辆已经被下单，并被乘车人占用。车辆即将行驶到乘车人所在区域，但乘车人并未上车。

运营状态：表示乘车人已经上车并准备就绪，车辆将驶向或正在驶向乘车人指定的目的地。

根据以上最小状态集定义，无人出租车服务的整个过程如下：

①车机决策中间层获取车辆状态信息，若在故障、充电或不适合运营时，直接发送“不可约”状态给服务器；除此之外，发送“可约”状态。

②车辆在“可约”状态下，可提供出租车服务。乘车人可使用APP查询车辆信息，乘车人在当前位置选择(或输入)去往的目的地后，进行“下单确认”操作。

③“下单确认”操作使APP自动生成订单，并将乘客当前所在位置信息及去往的目的地信息打包成订单记录，通过应用接口发送给云端服务器，并存储在数据库租车订单数据表中。服务器自动将接收到订单的车辆修改成“已约”状态，以使其他乘车人不能再预约该车辆。

④服务器自动取出最新更新的订单数据，首先将该订单中乘客所在地位置信息打包成决策指令，通过车机接口发送给车辆。

⑤车辆接收到决策指令，自动行驶到乘客所在地。

⑥乘客进入车辆后，通过APP确认“已上车”，APP将车辆状态修改为“运营”状态，并发送给服务器。服务器自动将订单中乘客去往的目的地信息构建成决策指令，通过车机接口发送给车辆。

⑦车辆接收到决策指令，自动行驶到乘客去往的目的地。

⑧乘客到达目的地后，通过APP确认“已到达目的地”，APP自动将车辆状态修改为“可约”状态。此时车辆空闲，并可开始接受下一轮租车服务。

⑨车辆在非“可约”的状态下，乘客取消约车，车辆状态均会转换为“可约”状态。

以上四种状态为实现无人出租车服务的最小状态集，可以满足最基本的乘运需要。需要说明，无人出租车的最小状态集的四种状态，需按逻辑流程转换，如图6所示，其中所有状态都可转变为“不可约”状态(由于车辆本身故障等问题)，但“不可约”状态只能转换为“可约”状态，不能直接转换成其他状态。如需要扩展更多功能，可对最小状态集某一状态进行细分成扩充状态集实现。

实施例五

图7所示为无人出租车服务的最小状态集及状态细分后的扩充状态集，其中扩充状态集可根据实际需求选择使用。扩充状态集为自动出租车实际运营服务提供更为严谨的功能设计。使用扩充状态集的无人出租车服务过程(如图8所示)如下：

①车机决策中间层获取车辆状态信息，若在故障、充电或不适合运营时，直接发送“故障”或“充电”状态给服务器。

②若车辆适合运营，设定车机决策中间层发送“固定区域可约”或“全路段可约”状态至服务器。

③车辆在“固定区域可约”状态下，若乘车人不在该固定区域内，车辆不可提供服务；若乘车人在该固定区域内或车辆在“全路段可约”状态下，可提供出租车服务。乘车人可使用APP查询车辆信息，乘车人在当前位置选择(或输入)去往的目的地后，进行“下单确认”操作。

④“下单确认”操作使APP自动生成订单，并将乘客当前所在位置信息及去往的目的地信息打包成订单记录，通过应用接口发送给云端服务器，并存储在数据库租车订单数据表中。服务器自动将接收到订单的车辆修改成“已约出发”状态，以使其他乘车人不能再预约该车辆。

⑤服务器自动取出最新更新的订单数据，首先将该订单中乘客所在地位置信息打包成决策指令，通过车机接口发送给车辆。

⑥车辆接收到决策指令，自动行驶到乘客所在地，乘车人可通过应用程序APP确定“车辆已到达”，车辆立即切换为“已约到达”状态，车辆门锁自动开启，乘车人可以上车。车辆门锁自动开启锁闭可使非乘车人不能进入车辆，保证自动驾驶出租车的运营安全。设定定时器，若乘客操作超时，车辆状态自动切换到最初的“固定区域可约”或“全路段可约”状态，并可开始接受下一轮租车服务。

⑦乘客进入车辆后，通过APP确认“已上车”，APP将车辆状态修改为“运营运行”状态，并发送给服务器。车辆在该状态下，车辆门锁自动锁闭，保证乘车人安全。服务器自动将订单中乘客去往的目的地信息构建成决策指令，通过车机接口发送给车辆。设定定时器，若乘客操作超时，车辆状态自动切换到最初的“固定区域可约”或“全路段可约”状态，并可开始接受下一轮租车服务。

⑧车辆接收到决策指令，自动行驶到乘客去往的目的地。

⑨车辆到达乘客订单目的地后，乘客通过APP确认“已到达目的地”，车辆自动设置成“运营到达”状态，并发送至服务器，车辆门锁自动开启，乘客可下车。该设置可使乘客在下车过程中，保证车辆不被下一位约车乘客约到车辆而意外启动，保证承运安全。

乘客下车并通过APP确认“已下车”或“订单(支付)完成”，整个租车服务结束。此时，车辆状态修改为“固定区域可约”或“全路段可约”状态，车辆空闲，并可开始接受下一轮租车服务。设定定时器，若乘客在此步骤操作超时，车辆状态自动切换到最初的“固定区域可约”或“全路段可约”状态，并可开始接受下一轮租车服务。

本实施例中仅列举了几种对于最小状态集中的状态进行扩展的方式，在实际应用中，可针对具体的情况对最小状态集中的状态进行不同方向或类别的扩展，不局限于本实施例中列举的内容。

为了更好地理解本发明，以上结合本发明的具体实施例做了详细描述，但并非是对本发明的限制。凡是依据本发明的技术实质对以上实施例所做的任何简单修改，均仍属于本发明技术方案的范围。本说明书中每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似的部分相互参见即可。对于系统实施例而言，由于其与方法实施例基本对应，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

Claims (10)

1.一种基于最小状态集的无人出租车交互系统，包括无人驾驶出租车应用端、车机决策中间层、客户端和云端服务器，其特征在于，所述云端服务器用于实现无人出租车服务数据交换功能，包括数据库、车机接口和应用接口。

2.如权利要求1所述的基于最小状态集的无人出租车交互系统，其特征在于，所述数据库为自动驾驶出租车服务最小化数据库，该数据库仅包含车辆信息表、车辆决策数据表和租车订单数据表。

3.如权利要求2所述的基于最小状态集的无人出租车交互系统，其特征在于，所述车辆信息表包括事先定义的基本车辆信息、车辆运行数据和车辆状态。

4.如权利要求3所述的基于最小状态集的无人出租车交互系统，其特征在于，定义所述车辆状态的方法是将当前状态存储在车辆信息表中，

定义无人出租车车辆的基本状态为最小状态集，所述最小状态集仅包含不可约状态、可约状态、已约状态和运营状态。

5.如权利要求4所述的基于最小状态集的无人出租车交互系统，其特征在于，所述不可约状态表示该无人驾驶出租车不可预约运营，在车辆因故障、充电、加油或未在运营区等条件下，自动由车机将该状态上传至车辆信息表。

6.如权利要求4所述的基于最小状态集的无人出租车交互系统，其特征在于，所述可约状态表示车辆能够提供服务，

车辆只有在该状态下，所述客户端能够对车辆进行租车下单服务。

7.如权利要求4所述的基于最小状态集的无人出租车交互系统，其特征在于，所述已约状态表示车辆已经被下单，并被乘车人占用，车辆即将行驶到乘车人所在区域，但乘车人并未上车。

8.如权利要求4所述的基于最小状态集的无人出租车交互系统，其特征在于，所述运营状态表示乘车人已经上车并准备就绪，车辆将驶向或正在驶向乘车人指定的目的地。

9.一种基于最小状态集的无人出租车交互方法，包括使用客户端预约和乘坐无人出租车，其特征在于，还包括以下步骤：

步骤1：等待所述无人出租车到达；

步骤2：乘坐所述无人出租车前往目的地；

步骤3：到达目的地后在所述客户端上操作任务完成；

所述方法在如权利要求1所述的系统上实施。

10.一种基于最小状态集的无人出租车交互方法，包括云服务器接收客户端发送过来的无人出租车交互信息，其特征在于，还包括以下步骤：

步骤1：查找符合条件的无人出租车；

步骤2：指派所述符合条件的无人出租车前往出发地，并将该出租车的车辆信息表中的车辆状态修改为已约状态；

步骤3：到达出发地，当乘客上车时，将该出租车的所述车辆信息表中的车辆状态修改为运营状态；

步骤4：到达目的地，当乘客下车时，将该出租车的所述车辆信息表中的车辆状态修改为可约状态；

所述方法在如权利要求1所述的系统上实施。

Images