景区用车方法、服务器和景区通勤车

摘要

本申请实施方式公开了一种景区用车方法、服务器和景区通勤车。所述方法包括：接收叫车信息；所述叫车信息与用户信息相关联；所述叫车信息至少包括上车位置信息；根据叫车信息以及景区通勤车的状态信息，确定目标通勤车以及对应的接车行程信息；其中，所述景区通勤车至少包括摇杆状的方向操纵杆和驻车踏板；针对所述目标通勤车进行用户的用车资格验证，以验证用户是否具有使用该目标通勤车的资格；在验证通过的情况下，向所述目标通勤车客户端发送控制权限通过信息。本申请实施方式提供的景区用车方法、服务器和景区通勤车，可以实现线上叫车功能等，不需专门安排司机来接送，为景区用户提供交通便利，提高用户游览体验，优化景区管理。

说明书

技术领域

本申请涉及交通运输领域，特别涉及一种景区用车方法、服务器和景区通勤车。

背景技术

旅游景区、工业园区、学校等公共场所的传统通勤方式为步行、自行车。为了解决景区(包括旅游景区、工业园区、学校等公共场所)游览路程远、时间长、体力消耗大等问题。通常采用观光巴士来解决上述问题。但是，采用观光巴士的方式对司机和运维人员的需求数量较大。

发明内容

本说明书实施方式提供一种景区用车方法、服务器和景区通勤车，能够一定程度上为景区用户提供交通便利，提高用户游览体验，优化景区管理。

本申请实施方式提供一种景区用车方法，包括：接收叫车信息；所述叫车信息与用户信息相关联；所述叫车信息至少包括上车位置信息；根据叫车信息以及景区通勤车的状态信息，确定目标通勤车以及对应的接车行程信息；所述接车行程信息用于指引所述目标通勤车至所述上车位置信息对应的位置；其中，所述景区通勤车至少包括摇杆状的方向操纵杆和驻车踏板；针对所述目标通勤车进行用户的用车资格验证，以验证用户是否具有使用该目标通勤车的资格；在验证通过的情况下，向所述目标通勤车客户端发送控制权限通过信息。

在一个实施方式中，所述上车位置信息至少包括以下之一，用户当前位置信息，或，用户指定上车位置信息。

在一个实施方式中，所述景区通勤车的状态信息至少包括以下之一：预定状态，空闲状态，充电状态，游览状态，故障状态。

在一个实施方式中，在根据叫车信息以及景区通勤车的状态，确定目标通勤车以及对应的接车行程信息的步骤中包括：至少根据所述上车位置信息，确定至少一辆预选通勤车；计算所述预选通勤车行驶至所述上车位置信息对应位置的时间；将时间最少的路线作为接车行程信息，对应的预选通勤车作为所述目标通勤车。

在一个实施方式中，在至少根据所述位置信息，确定至少一辆预选通勤车至少包括以下一种：根据所述上车位置信息，将指定范围内的处于空闲状态所述景区通勤车作为预选通勤车；或，根据所述上车位置信息，将指定范围内的符合指定条件的处于游览状态所述景区通勤车作为预选通勤车；其中，所述指定条件至少包括该游览状态所述景区通勤车游览行程信息的目标位置信息与所述叫车信息中的目标位置信息相同，且该游览状态所述景区通勤车游览行程信息中未完成的游览行程信息中包含所述上车位置信息，且该游览状态所述景区通勤车的剩余可载客人数大于等于所述叫车信息中的上车人数。

在一个实施方式中，所述用户信息中还包括共同搭乘意愿信息，所述共同搭乘信息用于表征用户与其他用户共同搭乘的意愿；所述指定条件还包括所述用户信息中的共同搭乘意愿信息为愿意共同搭乘信息，且处于游览状态所述景区通勤车对应的当前用户信息中的共同搭乘意愿信息为愿意共同搭乘信息。

在一个实施方式中，在验证通过的情况下，向所述目标通勤车客户端发送控制权限通过信息至少包括以下之一：在接收到所述目标通勤车客户端发送的就位信息和接收到对应的用户客户端发送的用户就位信息的情况下，向所述目标通勤车客户端发送控制权限通过信息；或，根据接收的所述叫车信息，生成第一验证信息；将接收到所述目标通勤车客户端输入的第二验证信息与所述第一验证信息进行匹配；在匹配成功的情况下，向所述目标通勤车发送控制权限通过信息。

在一个实施方式中，在将接收到所述目标通勤车客户端输入的第二验证信息与所述第一验证信息进行匹配的步骤中：在匹配失败的情况下，向所述目标通勤车发送报警信息。

在一个实施方式中，所述方法还包括：根据接收的目标位置信息，形成游览行程信息；将所述游览行程信息发送给所述目标通勤车客户端，以指引所述目标通勤车前往所述目标位置信息对应的目标位置。

在一个实施方式中，所述方法还包括：根据接收的驾驶模式信息，向所述目标通勤车发送对应该驾驶模式的执行指令，以控制所述目标通勤车的驾驶模式；其中，所述驾驶模式的执行指令至少包括以下之一：手动驾驶模式执行指令、自动驾驶模式执行指令；其中，在自动驾驶模式执行指令情况下，所述目标通勤车客户端根据所述游览行程信息控制所述目标通勤车行驶至所述目标位置信息对应的位置。

在一个实施方式中，所述方法还包括：在接收到针对所述目标通勤车的用车完毕信息的情况下，根据所述目标通勤车的当前位置信息，计算归位行程信息；向所述目标通勤车客户端发送归位行程信息，以指引所述目标通勤车归位。

在一个实施方式中，在计算归位行程信息的步骤中包括：根据所述目标通勤车的当前位置信息，确定预设范围内的预设归位点信息；计算所述目标通勤车从当前位置行驶至归位点的时间；将时间最少的路线作为归位行程信息，对应的预选归位点作为目标归位点。

在一个实施方式中，在确定预设范围内的预设归位点信息的步骤中包括：在所述目标通勤车当前电量小于阈值时，将预设范围内的空闲状态的充电桩作为预设充电桩；将带有所述预设充电桩的归位点信息作为所述预设归位点信息。

本申请实施方式还提供一种服务器，包括：存储器和处理器；所述存储器中存储有计算机指令；所述处理器用于执行所述计算机指令实现以下步骤：接收叫车信息；所述叫车信息与用户信息相关联；所述叫车信息至少包括上车位置信息；根据叫车信息以及景区通勤车的状态信息，确定目标通勤车以及对应的接车行程信息；所述接车行程信息用于指引所述目标通勤车至所述上车位置信息对应的位置；其中，所述景区通勤车至少包括摇杆状的方向操纵杆和驻车踏板；针对所述目标通勤车进行用户的用车资格验证，以验证用户是否具有使用该目标通勤车的资格；在验证通过的情况下，向所述目标通勤车客户端发送控制权限通过信息。

本申请实施方式还提供一种计算机存储介质，所述计算机存储介质中存储有计算机程序指令，所述计算机程序指令被执行时实现：接收叫车信息；所述叫车信息与用户信息相关联；所述叫车信息至少包括上车位置信息；根据叫车信息以及景区通勤车的状态信息，确定目标通勤车以及对应的接车行程信息；所述接车行程信息用于指引所述目标通勤车至所述上车位置信息对应的位置；其中，所述景区通勤车至少包括摇杆状的方向操纵杆和驻车踏板；针对所述目标通勤车进行用户的用车资格验证，以验证用户是否具有使用该目标通勤车的资格；在验证通过的情况下，向所述目标通勤车客户端发送控制权限通过信息。

本申请实施方式还提供一种景区用车方法，包括：接收叫车信息；所述叫车信息与用户信息相关联；所述叫车信息至少包括上车位置信息；根据叫车信息以及景区通勤车的状态信息，确定目标通勤车；向所述目标通勤车客户端发送上车位置信息，以用于所述目标通勤车客户端根据所述上车位置信息计算得到接车行程信息，以控制所述目标通勤车行驶至所述上车位置信息对应的位置；其中，所述景区通勤车至少包括摇杆状的方向操纵杆和驻车踏板；针对所述目标通勤车进行用户的用车资格验证，以验证用户是否具有使用该目标通勤车的资格；在验证通过的情况下，向所述目标通勤车客户端发送控制权限通过信息。

本申请实施方式还提供一种服务器，包括：存储器和处理器；所述存储器中存储有计算机指令；所述处理器用于执行所述计算机指令实现以下步骤：接收叫车信息；所述叫车信息与用户信息相关联；所述叫车信息至少包括上车位置信息；根据叫车信息以及景区通勤车的状态信息，确定目标通勤车；向所述目标通勤车客户端发送上车位置信息，以用于所述目标通勤车客户端根据所述上车位置信息计算得到接车行程信息，以控制所述目标通勤车行驶至所述上车位置信息对应的位置；其中，所述景区通勤车至少包括摇杆状的方向操纵杆和驻车踏板；针对所述目标通勤车进行用户的用车资格验证，以验证用户是否具有使用该目标通勤车的资格；在验证通过的情况下，向所述目标通勤车客户端发送控制权限通过信息。

本申请实施方式还提供一种景区通勤车，至少包括：网络通信单元、中控系统、方向操纵杆、驻车踏板；所述中控系统用于控制所述景区通勤车执行对应指令；所述网络通信单元用于接收服务器发送的接车信息，以用于所述中控系统控制所述景区通勤车行驶至用户上车位置信息对应的位置；所述方向操纵杆为摇杆状，用于接收用户的方位指令操作，以向所述中控系统发送对应的方位指令；所述驻车踏板用于根据接收用户的脚踏压力，以向所述中控系统发送对应的刹车信号。

在一个实施方式中，所述接车信息为接车行程信息，所述接车行程信息用于指引所述景区通勤车行驶至用户上车位置信息对应的位置。

在一个实施方式中，所述接车信息为用户上车位置信息，以用于所述中控系统根据所述上车位置信息计算得到接车行程信息，以用于所述中控系统控制所述景区通勤车行驶至所述上车位置信息对应的位置。

在一个实施方式中，所述中控系统还用于根据接收的驾驶模式的执行指令控制该景区通勤车的驾驶模式；其中，所述驾驶模式的执行指令至少包括以下之一：手动驾驶模式执行指令、自动驾驶模式执行指令；在所述中控系统接收的所述驾驶模式的执行指令为手动驾驶模式执行指令的情况下，所述中控系统根据接收的所述方位指令控制该景区通勤车的方向；在所述中控系统接收的所述驾驶模式的执行指令为自动驾驶模式执行指令的情况下，所述中控系统根据游览行程信息控制该景区通勤车行驶至目标位置信息对应的位置。

在一个实施方式中，所述方向操纵杆约束于六个方位角，分别对应前、后、左、右、左前、右前六个方位指令。

在一个实施方式中，所述景区通勤车还包括触摸显示器；其中，所述触摸显示器至少包括第一输入模块、行程展示界面；所述第一输入模块用于供用户输入验证信息，以验证该用户的用车资格；所述行程展示界面用于展示游览行程信息。

在一个实施方式中，所述触摸显示器还包括第二输入模块；所述第二输入模块用于供用户输入目标位置信息，以获取游览行程信息并展示于行程展示界面。

在一个实施方式中，所述触摸显示器还包括第三输入模块；所述第三输入模块用于供用户输入用车完毕信息；所述网络通信单元根据用户输入的用车完毕信息，向服务器发送对应信息，以使所述服务器根据该景区通勤车的当前位置信息，计算归位行程信息；向该景区通勤车客户端发送归位行程信息，以指引该景区通勤车归位。

在一个实施方式中，所述景区通勤车的底盘为六轮六驱动独立悬挂底盘。

在一个实施方式中，所述景区通勤车的前端还布置有摄像头，用于获取前方环境路况信息；所述景区通勤车的周身还布置有至少4个雷达；所述景区通勤车的车顶面前端面和后端面为一体式车篷；其中，前端面的倾斜部安置有挡风玻璃。

由以上本申请实施方式提供的技术方案可见，本申请实施方式提供的景区用车方法、服务器和景区通勤车，可以实现线上叫车功能等，不需专门安排司机来接送，为景区用户提供交通便利，提高用户游览体验，优化景区管理。

附图说明

为了更清楚地说明本申请实施方式或现有技术中的技术方案，下面将对实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施方式提供的一种景区用车系统的示意图；

图2为本申请实施方式提供的一种景区定位示意图；

图3为本申请实施方式提供的一种景区用车方法的流程图；

图4为本申请实施方式提供的一种景区通勤车的结构示意图；

图5为本申请实施方式提供的一种确定接车行程信息的流程图；

图6为本申请实施方式提供的另一种景区用车方法的流程图；；

图7为本申请实施方式提供的另一种景区用车方法的流程图；

图8为本申请实施方式提供的一种确定归位行程信息的流程图；

图9为本申请实施方式提供的另一种景区用车方法的流程图；

图10为本申请实施方式提供的一种景区通勤车的结构示意图；

图11为本申请实施方式提供的一种景区通勤车的三视图；

附图说明：10、方向操纵杆，20、触摸显示器，30、驻车踏板，40、中控系统，50、电池组，52、电量显示模块，54、电池充电触头，60、六轮独立悬挂底盘，70、车篷，72、挡风玻璃，74、超声波雷达，80、防跌落雷达，90、双目摄像头，82、激光雷达，100、防撞梁，110、驱动控制箱，120、座椅，122、安全带。

具体实施方式

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施方式中的附图，对本说明书实施方式中的技术方案进行清楚、完整地描述，显然，所描述的实施方式仅仅是本说明书一部分实施方式，而不是全部的实施方式。基于本说明书中的实施方式，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施方式，都应当属于本说明书保护的范围。

本说明书中的景区不是特指游览景区，而是指需要用车的公共场所。具体的，例如，游览景区、学校、工业园区等。

请参阅图1。本说明书实施方式提供一种景区用车系统。所述景区用车系统可以包括服务器、用户客户端和景区通勤车客户端。

在本实施方式中，所述服务器可以接收用户客户端发送叫车信息，根据景区内的路线情况，以及景区中的景区通勤车状态信息，进行用车分配，并向景区通勤车接车信息，例如，接车行程信息或者上车位置信息，以指引所述景区通勤车自动前往用户的上车地点，使得景区内所述景区通勤车资源合理分配，实现线上叫车功能，提升用户体验。

在本实施方式中，服务器可以为具有运算和网络交互功能的电子设备；也可以为运行于该电子设备中，为数据处理和网络交互提供业务逻辑的软体。

在本实施方式中，服务器并不具体的数量。其可以为一个服务器，还可以为几个服务器，或者，若干服务器形成的服务器集群。

在本实施方式中，客户端可以包括用户客户端和景区通勤车客户端，所述用户客户端和所述景区通勤车客户端可以向用户展示游览行程信息等。所述景区通勤车客户端可以泛指所述景区通勤车网络通信单元、中控系统、显示器等。

请参阅图2，用户客户端和景区通勤车客户端的定位可以通过景区的路由/智能硬件，发送无线信息，定位客户端。当然还可以是通过客户端的定位系统，GPS实时定位，获得用户客户端或景区通勤车客户端的路径。

在本实施方式中，客户端可以为具有显示、运算和网络访问功能的电子设备。具体的，客户端可以为较为便携式的电子设备。例如，平板电脑、智能手机、数字助理、智能可穿戴设备。同理，所述景区通勤车客户端可以为搭载于景区通勤车上的具有显示、运算和网络访问功能的电子设备。

在本实施方式中，用户可以操作用户客户端提供叫车信息。具体的，例如，用户在用户客户端中点击“叫车”按钮，以向服务器发送叫车信息，当然叫车信息可以附带该用户的用户信息，例如，姓名、手机号等。

在本实施方式中，服务器与客户端直接可以通过特定的协议进行信息交互。例如，服务器可以通过TCP/IP协议(传输控制协议/网际协议Transmission Control Protocol/Internet Protocol)以及超文本传输协议(HTTP，HyperText Transfer Protocol)等协议进行传输；在物理层面，可以通过无线网络等传输。

请参阅图3。本说明书实施方式提供一种景区用车方法，所述方法可以包括以下步骤。

步骤S10：接收叫车信息；所述叫车信息与用户信息相关联；所述叫车信息至少包括上车位置信息。

在本实施方式中，所述叫车信息可以是用户客户端发送的叫车请求信息，用于表征用户的叫车请求。所述叫车信息可以包括上车位置信息、预计上车时间、预计上车人数等。

在本实施方式中，所述上车位置信息用于表征用户想要上车的地点。所述上车位置信息可以是所述用户客户端发送的用户当前位置信息，也可以是用户指定上车位置信息。所述用户指定上车位置信息对应的位置可以是用户从该景区预设有多个上车点中指定的，也可以是用户自行指定的。例如，用户指定景区内某条马路边的一个点作为上车点，通过用户客户端向服务器发送包含该上车点信息的所述叫车信息。当然，也可以将当前该客户端的位置信息作为所述上车位置信息。

在本实施方式中，所述叫车信息与用户信息相关联用于将所述叫车信息与该用户对应。具体的，例如，所述叫车信息可以附带有该用户的姓名、手机号等，以用于后续验证对应的用户使用对应的所述景区通勤车。所述叫车信息或所述用户信息还可以包括共同搭乘意愿信息，所述共同搭乘信息用于表征用户与其他用户共同搭乘的意愿。例如，用户客户端在发送叫车信息时还可以包括有是否愿意拼车的选项。当为“是”时，所述用户客户端向所述服务器发送愿意共同搭乘信息，当为“否”时，所述用户客户端向所述服务器发送对应的不愿意共同搭乘信息。

在本实施方式中，通过服务器与客户端直接可以通过特定的协议进行信息交互，以接收所述叫车信息。用户可以通过用户客户端发送叫车信息。

步骤S12：根据叫车信息以及景区通勤车的状态信息，确定目标通勤车以及对应的接车行程信息；所述接车行程信息用于指引所述目标通勤车至所述上车位置信息对应的位置；其中，所述景区通勤车至少包括摇杆状的方向操纵杆和驻车踏板。

在本实施方式中，所述景区通勤车的状态信息用于表征所述景区通勤车的使用状态。具体的，所述状态信息可以包括：预定状态，空闲状态，充电状态，游览状态，故障状态。其中，所述预定状态可以是指被其他用户预订的状态。例如，所述服务器可以向用户发送附近的至少一辆所述景区通勤车标识，以及其对应的位置信息。用户可以通过该用户客户端发送预订信息，以预订该标识对应的景区通勤车，以防止该景区通勤车被其他人使用。所述服务器在接收到所述预定信息后，将对应的景区通勤车标记为预定状态。所述空闲状态可以是指所述景区通勤车处于空闲待命状态。所述充电状态可以是指所述景区通勤车处于充电中的状态。所述游览状态可以是指所述景区通勤车处于被使用的状态，例如，去接用户或者正载用户游览景区中等。所述故障状态可以是指所述景区通勤车处于故障中的状态。

在本实施方式中，所述接车行程信息可以是指所述目标通勤车行驶至所述上车位置信息对应的位置的路线信息等。所述接车行程信息还可以包括时间信息等。所述时间信息可以包括出发接车时的时间，预计接车时长，预计到达所述上车位置信息对应的位置的时间等。

在本实施方式中，根据叫车信息以及景区通勤车的状态信息，确定目标通勤车以及对应的接车行程信息。具体的，可以是至少根据所述上车位置信息，确定至少一辆预选通勤车；计算所述预选通勤车行驶至所述上车位置信息对应位置的时间；将时间最少的路线作为接车行程信息，对应的预选通勤车作为所述目标通勤车。例如，根据所述上车位置信息的位置，将该位置附近1公里内的所述景区通勤车进行标记，筛选出其中处于空闲状态的所述景区通勤车，作为预选通勤车，通过导航模块计算所述预选通勤车行驶至所述上车位置信息对应位置的时间，将时间最少的路线作为所述接车行程信息，对应的预选通勤车作为所述目标通勤车。当然，在筛选出所述预选通勤车后，可以通过导航模块计算所述预选通勤车行驶至所述上车位置信息对应位置的路程，将路程最短的路线作为所述接车行程信息。当然，也可以是将与所述上车位置信息对应位置距离最近的处于空闲状态的所述景区通勤车作为所述目标通勤车，并计算获得该目标通勤车行驶至所述上车位置信息对应的位置的接车行程信息。

在本实施方式中，根据叫车信息以及景区通勤车的状态信息，确定目标通勤车以及对应的接车行程信息。还可以是所述服务器根据所述上车位置信息的位置，将景区地图信息和指定范围内的空闲状态的所述景区通勤车信息发送给用户客户端，在用户客户端可以展示对应的景区地图和可供选择的空闲状态的所述景区通勤车。用户可以通过选择景区通勤车将其作为所述目标通勤车，所述服务器根据该目标通勤车，计算接车行程信息。

在本实施方式中，所述景区通勤车至少包括摇杆状的方向操纵杆和驻车踏板。其中，所述方向操纵杆为摇杆状，用于在手动驾驶模式时，供用户操作以控制方向，提高用户用车趣味性。例如，所述方向操纵杆可以如图4中的操作杆。所述方向操纵杆可以约束于六个方位角，分别对应前、后、左、右、左前、右前六个方位指令。所述驻车踏板用于接收用户的脚踏压力，以向该景区通勤车的中控系统发送对应的刹车信号。

步骤S14：针对所述目标通勤车进行用户的用车资格验证，以验证用户是否具有使用该目标通勤车的资格；在验证通过的情况下，向所述目标通勤车客户端发送控制权限通过信息。

在本实施方式中，针对所述目标通勤车进行用户的用车资格验证可以是指验证用户是否使用了对应的所述目标通勤车，以防止用户上次车，或者用户正在使用的所述景区通勤车被其他用户使用。

在一个实施方式中，验证方式可以是在接收到所述目标通勤车客户端发送的就位信息和接收到对应的用户客户端发送的用户就位信息的情况下，向所述目标通勤车客户端发送控制权限通过信息。具体的，例如，所述目标通勤车在行驶至所述上车位置信息对应的位置时，向服务器发送就位信息以表征该目标通勤车已经到达接车地点。用户在到达接车地点并看到目标通勤车时也可以发送一个用户就位信息表征该用户已经到达接车地点。在服务接收到用户客户端和对应的所述目标通勤车客户端发送的就位信息后，两者匹配，表示已对应，则验证通过。当然，在另一个实施方式中，也可以以用户客户端为基准。例如，用户上车后，根据来接车的所述目标通勤车的车牌号，向服务器发送已上车信息，已上车信息中包含了对应的车牌号信息。所述服务器端将该车牌号信息与该用户对应的目标通勤车的车牌号信息进行匹配，匹配成功，则表明验证成功。

在一个实施方式中，验证方式可以是根据接收的所述叫车信息，生成第一验证信息；将接收到所述目标通勤车客户端输入的第二验证信息与所述第一验证信息进行匹配；在匹配成功的情况下，向所述目标通勤车发送控制权限通过信息。具体的，例如，用户在叫车成功后，服务器针对该叫车信息，生成第一验证信息。所述第一验证信息可以是验证码，如0531”“446322”等，也可以是用户信息，如用户姓名、电话等。在所述第一验证信息为验证码时，所述服务器向该用户客户端发送该验证码，以供用户在所述目标通勤车上进行输入验证。所述目标通勤车可以有输入模块，例如，所述目标通勤车在达到接车地点后，该通勤车的触摸界面上展示验证界面，用于用户在该界面输入用车验证信息，输入的信息作为第二验证信息，并发送给所述服务器，所述服务器将所述第二验证信息与所述第一验证信息进行匹配。匹配成功，则验证通过。

在本实施方式中，在验证通过的情况下，向所述目标通勤车客户端发送控制权限通过信息。在本实施方式中，所述控制权限通过信息用于表征所述目标通勤车已经到达所述上车位置信息对应的位置并接到了对应的用户，可以供用户用车了。例如，可以执行游览功能等。

在本实施方式中，所述服务器可以根据接收的所述叫车信息和所述景区通勤车的状态信息对景区通勤车资源合理分配，并针对所述目标通勤车进行用户的用车资格验证。实现线上叫车功能，不需专门安排司机来接送，为景区用户提供交通便利，提高用户游览体验，优化景区管理。

在一个实施场景中，用户进入了一个景区，他当前位置在景区入口大门，想去景区中的景点A。该用户打开他的手机，进行线上叫车。线上叫车对应的APP绑定该用户的姓名与电话等。

在本场景示例中，用户在线上叫车时，用户客户端可以接收到服务器发送的景区地图以及景区中的所述景区通勤车的位置以及状态。其中，橙色表示该景区通勤车处于预定状态，绿色表示该景区通勤车处于空闲状态，红色表示该景区通勤车处于充电状态，黄色表示该景区通勤车处于游览状态，灰色表示景区通勤车处于该故障状态。用户将其中一个标记为绿色的景区通勤车为目标通勤车。该用户以当前位置为上车位置，以景点A为目标位置通过用户客户端发送所述叫车信息。

在本场景示例中，所述服务器在接收到所述叫车信息后，根据该目标通勤车的位置信息以及用户上车位置信息，计算得到接车行程信息，并发送给该目标通勤车客户端。所述服务器还对应发送一个验证码“435496”给该用户客户端。该目标通勤车客户端在接收到接车信息后，根据接车信息中包含的接车行程信息，自动驾驶至上车位置信息对应的位置。所述目标通勤车在到达所述上车位置信息对应的位置后，停泊等待用户上车。同时所述目标通勤车的显示器显示验证信息输入窗口。

在本场景示例中，用户在登上所述目标通勤车后，在验证信息输入窗口输入“435496”。所述目标通勤车客户端将该信息发送给所述服务器，所述服务器进行匹配，匹配通过，并向所述目标通勤车客户端发送控制权限通过信息。所述目标通勤车在接收到所述控制权限通过信息，在显示界面展示驾驶模式选项：手动驾驶模式、自动驾驶模式。

在本场景示例中，该用户选择了自动驾驶模式。所述服务器在接收到自动驾驶模式信息后，根据所述上车位置信息和目标位置信息，即景点A的位置，计算得到游览行程信息，并发送给该目标通勤车客户端。该目标通勤车客户端根据所述游览行程信息自动驾驶至景点A。

在本场景示例中，在自动驾驶模式时，用户也可以操作图4中所述方向操纵杆。但是不会影响该目标通勤车的行驶路线。

在本场景示例中，用户在到达景点A后，通过用户客户端发送“用车完毕、已下车”信息。所述服务器在接收到该信息后，向根据所述目标通勤车的当前位置信息，即景点A的位置，计算得到最近归位点以及归位行程信息，发送给所述目标通勤车。所述目标通勤车在接收到归位行程信息后，自动驾驶至该归位点停泊。

在本场景示例中，景区内的归位点为预设的车库，可以分为带充电桩的车库、和不带充电桩的临时停车点。每个归位点还具有每个归位点的客户端，可以统计该归位点停车情况，如最大停车数量、当前停车数量、充电桩数量、正在使用的充电桩数量等。每个归位点的客户端向服务器发送该停车情况，以供服务器根据每个归位点的位置、停车情况等，确定所述景区通勤车在用车完毕后的归位点。实现自动归位，避免随地停放，影响环境和秩序，减少对司机和运维人员的需求数量。

在另一个实施场景中，所述景区通勤车客户端具有自主导航系统。所述服务器像目标通勤车发送的接车信息中包含上车位置信息。所述目标通勤车客户端根据该上车位置信息，计算得到接车行程信息，以指引所述目标通勤车前往上车位置信息的位置，同理，在游览和泊车时的行程信息，也可以是在所述景区通勤车客户端侧完成。

在另一个实施场景中，用户选择了手动驾驶模式，所述景区通勤车的方向操纵杆可以往6个方向推拉，分别对应前、后、左、右、左前、右前六个方位指令。所述景区通勤车还包括驻车踏板用于根据接收用户的脚踏压力，以向所述中控系统发送对应的刹车信号。根据接收的脚踏压力，所述景区通勤车进行刹车，急刹对应于急促的脚踏压力信息，缓刹对应于缓慢的脚踏压力信息。用户通过操作该方向操纵杆和该驻车踏板控制该目标通勤车，进行游览。该目标通勤车的显示器可以展示游览行程信息。省略了复杂的转向结构，提高了操纵体验，节省方向盘的位置的空间。

在一个实施方式中，所述上车位置信息至少包括以下之一，用户当前位置信息，或，用户指定上车位置信息。

在本实施方式中，用户当前位置信息用于表征用户的当前位置，用户指定上车位置信息用于表征用户指定上车位置。有时候用户的当前位置可能不在马路边，或其他不方便上车的位置。例如，用户还在工业园区里的办公楼A里，预计10分钟后想在办公楼A的门口上车。所述景区通勤车只能行驶至办公楼A的门口，则在该场景中，用户发送的所述叫车信息包括的上车位置信息为用户指定上车位置信息。

通过上述实施方式，可以提供用户灵活的叫车方式，满足用户的用车需求。

在一个实施方式中，所述景区通勤车的状态信息至少包括以下之一：预定状态，空闲状态，充电状态，游览状态，故障状态。

在本实施方式中，所述预定状态可以是指被其他用户预订的状态。例如，所述服务器可以向用户发送附近的至少一辆所述景区通勤车标识，以及其对应的位置信息。用户可以通过该用户客户端发送预订信息，以预订该标识对应的景区通勤车，以防止该景区通勤车被其他人使用。所述服务器在接收到所述预定信息后，将对应的景区通勤车标记为预定状态。所述空闲状态可以是指所述景区通勤车处于空闲待命状态。所述充电状态可以是指所述景区通勤车处于充电中的状态。所述游览状态可以是指所述景区通勤车处于被使用的状态，例如，去接用户或者正载用户游览景区中等。所述故障状态可以是指所述景区通勤车处于故障中的状态。

通过上述实施方式，可以将景区通勤车进行分类，以合理安排所述景区通勤车资源，降低运维成本。

请参阅图5。在一个实施方式中，在根据叫车信息以及景区通勤车的状态，确定目标通勤车以及对应的接车行程信息的步骤中可以包括以下步骤。

步骤S20：至少根据所述上车位置信息，确定至少一辆预选通勤车。

在本实施方式中，所述预选通勤车可以是指初步筛选的通勤车，以进一步筛选得到目标通勤车。例如，将所述上车位置信息对应位置方圆200米或500米内的处于空闲状态的所述景区通勤车作为所述预选通勤车。当然也可以将处于游览状态且行程即将经过用户上车位置的景区通勤车作为所述预选通勤车。

步骤S22：计算所述预选通勤车行驶至所述上车位置信息对应位置的时间。

步骤S24：将时间最少的路线作为接车行程信息，对应的预选通勤车作为所述目标通勤车。

本实施方式通过先筛选预选通勤车，进一步得到目标通勤车，以获得一种合理分配使用所述景区通勤车的方法，节约资源。

本实施方式中的相关术语可以参见前述实施方式对照解释，在此不再赘述。

在一个实施方式中，在至少根据所述位置信息，确定至少一辆预选通勤车至少包括以下一种：根据所述上车位置信息，将指定范围内的处于空闲状态所述景区通勤车作为预选通勤车；或，根据所述上车位置信息，将指定范围内的符合指定条件的处于游览状态所述景区通勤车作为预选通勤车；其中，所述指定条件至少包括该游览状态所述景区通勤车游览行程信息的目标位置信息与所述叫车信息中的目标位置信息相同，且该游览状态所述景区通勤车游览行程信息中未完成的游览行程信息中包含所述上车位置信息，且该游览状态所述景区通勤车的剩余可载客人数大于等于所述叫车信息中的上车人数。

在本实施方式中，所述游览行程信息表示指引所述景区通勤车从上车位置到目标位置的行程规划信息，可以包括游览路线、预计游览时间、预计到达时间等。所述游览行程信息可以分为已完成的游览行程信息和未完成的游览行程信息。所述已完成的游览行程信息可以表示已经完成游览部分的行程信息。所述未完成的游览行程信息可以表示已经剩余游览部分的行程信息。

本实施方式通过将一部分游览状态的所述景区通勤车作为筛选对象，可以实现拼车效果，进一步节约资源。

本实施方式中的相关术语可以参见前述实施方式对照解释，在此不再赘述。

在一个实施方式中，所述用户信息中还包括共同搭乘意愿信息，所述共同搭乘信息用于表征用户与其他用户共同搭乘的意愿；所述指定条件还包括所述用户信息中的共同搭乘意愿信息为愿意共同搭乘信息，且处于游览状态所述景区通勤车对应的当前用户信息中的共同搭乘意愿信息为愿意共同搭乘信息。

在本实施方式中，所述共同搭乘信息用于表征用户与其他用户共同搭乘的意愿。所述共同搭乘信息可以是包含在用户客户端发送的所述叫车信息中。

通过本实施方式，在安排所述景区通勤车用车时，可以将用户是否愿意拼车的意愿考虑在内。防止不愿意拼车的用户搭乘他人或被他人搭乘。可以提高用户体验。

在一个实施方式中，在验证通过的情况下，向所述目标通勤车客户端发送控制权限通过信息至少包括以下之一：在接收到所述目标通勤车客户端发送的就位信息和接收到对应的用户客户端发送的用户就位信息的情况下，向所述目标通勤车客户端发送控制权限通过信息；或，根据接收的所述叫车信息，生成第一验证信息；将接收到所述目标通勤车客户端输入的第二验证信息与所述第一验证信息进行匹配；在匹配成功的情况下，向所述目标通勤车发送控制权限通过信息。

在本实施方式中，验证方式可以是在接收到所述目标通勤车客户端发送的就位信息和接收到对应的用户客户端发送的用户就位信息的情况下，向所述目标通勤车客户端发送控制权限通过信息。具体的，例如，所述目标通勤车在行驶至所述上车位置信息对应的位置时，向服务器发送就位信息以表征该目标通勤车已经到达接车地点。用户在到达接车地点并看到目标通勤车时也可以发送一个用户就位信息表征该用户已经到达接车地点。在服务接收到用户客户端和对应的所述目标通勤车客户端发送的就位信息后，两者匹配，表示已对应，则验证通过。再例如，用户上车后，根据来接车的所述目标通勤车的车牌号，向服务器发送已上车信息，已上车信息中包含了对应的车牌号信息。所述服务器端将该车牌号信息与该用户的目标通勤车的车牌号信息进行匹配，匹配成功，则表明验证成功。

在本实施方式中，验证方式也可以是根据接收的所述叫车信息，生成第一验证信息；将接收到所述目标通勤车客户端输入的第二验证信息与所述第一验证信息进行匹配；在匹配成功的情况下，向所述目标通勤车发送控制权限通过信息。具体的，例如，用户在叫车成功后，服务器针对该叫车信息，生成第一验证信息。所述第一验证信息可以是验证码，如0531”“446322”等，也可以是用户信息，如用户姓名、电话等。在所述第一验证信息为验证码时，所述服务器向该用户客户端发送该验证码，以供用户在所述目标通勤车上进行输入验证。所述目标通勤车可以有输入模块，例如，所述目标通勤车在达到接车地点后，该通勤车的触摸界面上展示验证界面，用于用户在该界面输入用车验证信息，输入的信息作为第二验证信息，并发送给所述服务器，所述服务器将所述第二验证信息与所述第一验证信息进行匹配。匹配成功，则验证通过。

本实施方式用于验证用户是否登上对应的该用户的所述目标通勤车，防止出现对应错误。造成用车错误。例如，需要搭乘的人，被其他人搭乘走。再例如，用户A叫了景区通勤车a自动驾驶至景点A1，用户B叫了景区通勤车b自动驾驶至景点B1，用户A上了用户B的车，用户B上了用户A的车，达到了对方想要的目的地。

本实施方式中的相关术语可以参见前述实施方式对照解释，在此不再赘述。

在一个实施方式中，在将接收到所述目标通勤车客户端输入的第二验证信息与所述第一验证信息进行匹配的步骤中：在匹配失败的情况下，向所述目标通勤车发送报警信息。

在本实施方式中，在匹配失败的情况下，向所述目标通勤车发送报警信息。所述目标通勤车在接收到所述报警信息后，可以通过报警装置发出警报，以提醒用户上错车了。

请参阅图6。在一个实施方式中，所述方法还包括以下步骤。

步骤S30：根据接收的目标位置信息，形成游览行程信息。

步骤S32：将所述游览行程信息发送给所述目标通勤车客户端，以指引所述目标通勤车前往所述目标位置信息对应的目标位置。

在本实施方式中，所述目标位置信息用户表征用户想要去的目标地点。所述目标位置信息可以是用户在一开始时与叫车信息一起发送，包含于叫车信息内。也可以是用户在登上所述目标通勤车后，通过目标通勤车想所述服务器发送。所述服务器根据目标位置信息，通过导航系统模块，计算得到游览行程信息，发送给所述目标通勤车客户端，以指引所述目标通勤车前往所述目标位置信息对应的目标位置。

本实施方式中的相关术语可以参见前述实施方式对照解释，在此不再赘述。

当然在另一种实施方式中，计算所述游览行程信息也可以直接在所述目标通勤车客户端完成。例如，用户在登上所述目标通勤车后，在所述目标通勤车的显示器输入目标位置信息。所述目标通勤车的导航模块，根据当前位置和目标位置，计算得到所述游览行程信息等。

在一个实施方式中，所述方法还可以包括：根据接收的驾驶模式信息，向所述目标通勤车发送对应该驾驶模式的执行指令，以控制所述目标通勤车的驾驶模式；其中，所述驾驶模式的执行指令至少包括以下之一：手动驾驶模式执行指令、自动驾驶模式执行指令；其中，在自动驾驶模式执行指令情况下，所述目标通勤车客户端根据所述游览行程信息控制所述目标通勤车行驶至所述目标位置信息对应的位置。

在本实施方式中，所述驾驶模式信息用于表征用户想要设定的架势模式。所述驾驶模式信息可以与所述驾驶模式的执行指令对应，手动驾驶模式执行指令、自动驾驶模式执行指令。所述驾驶模式信息可以是用户通过所述用户客户端发送，也可以是用户通过所述目标通勤车客户端发送。具体的，例如，用户客户端界面展示“手动模式”和“自动模式”两个选项供用户选择，用户可以选择其中之一，在用户确认后，所述用户客户端向所述服务器发送对应的所述驾驶模式信息。同理，用户也可在所述目标通勤车客户端操作。此处不作具体赘述。

在本实施方式中，所述目标通勤车在接收到所述手动驾驶模式执行指令时，用户可以通过所述方向操纵杆以控制该目标通勤车的移动。所述目标通勤车在接收到所述自动驾驶模式执行指令时，用户对所述方向操纵杆的操作并不能转换成控制该目标通勤车的移动的指令。

本实施方式中的相关术语可以参见前述实施方式对照解释，在此不再赘述。

请参阅图7。在一个实施方式中，所述方法还可以包括以下步骤。

步骤S40：在接收到针对所述目标通勤车的用车完毕信息的情况下，根据所述目标通勤车的当前位置信息，计算归位行程信息。

步骤S42：向所述目标通勤车客户端发送归位行程信息，以指引所述目标通勤车归位。

在本实施方式中，所述用车完毕信息用于表征用户已用车完毕。所述用车完毕信息可以通过用户客户端发送，也可以是通过所述目标通勤车客户端发送，还可以是所述服务器的处理器自行判定。具体的，例如，用户在到达目标位置后，通过用户客户端发送“用车完毕、已下车”信息。再例如，用在在到达目标位置后，通过该目标通勤车的显示界面，点击“用车结束”，以向所述服务器发送用车完毕信息。再例如，所述目标通勤车在到达所述目标位置后，通过重力感应器，获取该目标通勤车的载物或载人重量数据，当重量数据为0时，向服务器发送“用户已到达、且已下车”信息，以及对应的影像信息。所述服务器在接收到信息后，将其确定为用车完毕信息。

在本实施方式中，所述归位点为可以为预设的车库，所述车库可以分为带充电桩的车库、和不带充电桩的临时停车点。每个归位点还可以具有每个归位点的客户端，可以统计该归位点停车情况，如最大停车数量、当前停车数量、充电桩数量、正在使用的充电桩数量等。每个归位点的客户端向服务器发送该停车情况，以供服务器根据每个归位点的位置、停车情况等。所述服务器可以根据每个归位点的位置、停车情况、以及所述目标通勤车的当前位置信息，计算归位行程信息。并向所述目标通勤车客户端发送归位行程信息，以指引所述目标通勤车归位。

当然，在另一个实施方式中，计算归位行程信息的客体也可以是在所述景区通勤车客户端。例如，服务器将景区每个归位点的位置、停车情况等发送给每台所述景区通勤车。所述景区通勤车在用车完毕后通过接收到的每个归位点的位置、停车情况等计算得到目标归位点，并通过导航模块自动导航至该归位点。

通过本实施方式，可以实现自动归位，避免随地停放，影响环境和秩序，减少对司机和运维人员的需求数量。

请参阅图8。在一个实施方式中，计算归位行程信息可以包括以下步骤。

步骤S50：根据所述目标通勤车的当前位置信息，确定预设范围内的预设归位点信息。

步骤S52：计算所述目标通勤车从当前位置行驶至归位点的时间。

步骤S54：将时间最少的路线作为归位行程信息，对应的预选归位点作为目标归位点。

本实施方式提供一种计算归位行程信息的方式，先通过筛选得到预选归为点，在预选归为点中，将归位用时最少的预选归位点作为目标归位点，对应的路线作为归位行程信息。通过该方法可以合理安排所述景区通勤车归位，节约资源。

本实施方式中的相关术语可以参见前述实施方式对照解释，在此不再赘述。

在一个实施方式中，在确定预设范围内的预设归位点信息的步骤中包括：在所述目标通勤车当前电量小于阈值时，将预设范围内的空闲状态的充电桩作为预设充电桩；将带有所述预设充电桩的归位点信息作为所述预设归位点信息。

在本实施方式中，将所述目标通勤车当前电量考虑到用车归位中，以规划所述归位行程信息，可以使所述景区通勤车及时充电。

在一个实施方式中还提供一种服务器，包括：存储器和处理器；所述存储器中存储有计算机指令；所述处理器用于执行所述计算机指令实现以下步骤：接收叫车信息；所述叫车信息与用户信息相关联；所述叫车信息至少包括上车位置信息；根据叫车信息以及景区通勤车的状态信息，确定目标通勤车以及对应的接车行程信息；所述接车行程信息用于指引所述目标通勤车至所述上车位置信息对应的位置；其中，所述景区通勤车至少包括摇杆状的方向操纵杆和驻车踏板；针对所述目标通勤车进行用户的用车资格验证，以验证用户是否具有使用该目标通勤车的资格；在验证通过的情况下，向所述目标通勤车客户端发送控制权限通过信息。

所述存储器可以是用于保存信息的记忆设备。在数字系统中，存储器可以是能保存二进制数据的设备；在集成电路中，存储器可以为一个没有实物形式的具有存储功能的电路，如RAM、FIFO等；在系统中，具有实物形式的存储设备也可以叫存储器，如内存条、TF卡等。所述存储器包括但不限于随机存取存储器(Random Access Memory,RAM)、只读存储器(Read-Only Memory,ROM)、缓存(Cache)、硬盘(Hard DiskDrive,HDD)或者存储卡(MemoryCard)。所述存储器可以用于存储计算机程序指令。网络通信单元可以是依照通信协议规定的标准设置的，用于进行网络连接通信的接口。

本实施方式中的相关术语可以参见前述实施方式对照解释，在此不再赘述。

在一个实施方式中，还提供一种计算机存储介质，所述计算机存储介质中存储有计算机程序指令，所述计算机程序指令被执行时实现：接收叫车信息；所述叫车信息与用户信息相关联；所述叫车信息至少包括上车位置信息；根据叫车信息以及景区通勤车的状态信息，确定目标通勤车以及对应的接车行程信息；所述接车行程信息用于指引所述目标通勤车至所述上车位置信息对应的位置；其中，所述景区通勤车至少包括摇杆状的方向操纵杆和驻车踏板；针对所述目标通勤车进行用户的用车资格验证，以验证用户是否具有使用该目标通勤车的资格；在验证通过的情况下，向所述目标通勤车客户端发送控制权限通过信息。

本实施方式中的相关术语可以参见前述实施方式对照解释，在此不再赘述。

在一个实施方式中，还提供一种景区用车方法，至少包括以下步骤。

步骤S60：接收叫车信息；所述叫车信息与用户信息相关联；所述叫车信息至少包括上车位置信息。

步骤S62：根据叫车信息以及景区通勤车的状态信息，确定目标通勤车。

步骤S64：向所述目标通勤车客户端发送上车位置信息，以用于所述目标通勤车客户端根据所述上车位置信息计算得到接车行程信息，以控制所述目标通勤车行驶至所述上车位置信息对应的位置；其中，所述景区通勤车至少包括摇杆状的方向操纵杆和驻车踏板。

步骤S66：针对所述目标通勤车进行用户的用车资格验证，以验证用户是否具有使用该目标通勤车的资格；在验证通过的情况下，向所述目标通勤车客户端发送控制权限通过信息。

在本实施方式中，确定所述目标通勤车后，所述目标通勤车客户端可以根据所述上车位置信息计算得到所述接车行程信息，即计算接车行程信息的客体为所述目标通勤车客户端。

本实施方式中的相关术语可以参见前述实施方式对照解释，在此不再赘述。

在一个实施方式中，还提供一种服务器，包括：存储器和处理器；所述存储器中存储有计算机指令；所述处理器用于执行所述计算机指令实现以下步骤：接收叫车信息；所述叫车信息与用户信息相关联；所述叫车信息至少包括上车位置信息；根据叫车信息以及景区通勤车的状态信息，确定目标通勤车；向所述目标通勤车客户端发送上车位置信息，以用于所述目标通勤车客户端根据所述上车位置信息计算得到接车行程信息，以控制所述目标通勤车行驶至所述上车位置信息对应的位置；其中，所述景区通勤车至少包括摇杆状的方向操纵杆和驻车踏板；针对所述目标通勤车进行用户的用车资格验证，以验证用户是否具有使用该目标通勤车的资格；在验证通过的情况下，向所述目标通勤车客户端发送控制权限通过信息。

在一个实施方式中，还提供一种景区通勤车，至少包括：网络通信单元、中控系统、方向操纵杆、驻车踏板；所述中控系统用于控制所述景区通勤车执行对应指令；所述网络通信单元用于接收服务器发送的接车信息，以用于所述中控系统控制所述景区通勤车行驶至用户上车位置信息对应的位置；所述方向操纵杆为摇杆状，用于接收用户的方位指令操作，以向所述中控系统发送对应的方位指令；所述驻车踏板用于根据接收用户的脚踏压力，以向所述中控系统发送对应的刹车信号。

在本实施方式中，所述网络通信单元可以是与不同的通信协议进行绑定，从而可以发送或接收不同数据的虚拟单元。例如，所述网络通信单元可以是负责进行web数据通信的单元，也可以是负责进行FTP数据通信的单元，还可以是负责进行邮件数据通信的单元。此外，所述网络通信单元还可以是实体的通信接口或者通信芯片。例如，其可以为无线移动网络通信芯片，如GSM、CDMA等；其还可以为Wifi芯片、蓝牙芯片等。

在本实施方式中，叫车信息可以是用户客户端发送的叫车请求信息，用于表征用户的叫车请求。所述叫车信息可以包括上车位置信息、预计上车时间、预计上车人数等。对应的，服务器发送的接车信息可以是用于指引目标通勤车接车的信息。其中，所述目标通勤车可以是服务器计算确定的去接送用户的景区通勤车。所述接车信息可以包括上车位置信息、接车行程信息、预计接车到达时间、预计上车人数等。

在本实施方式中，所述中控系统根据接收的指定信息执行对应的指令以控制所述景区通勤车。在搭载有自主导航模块时，所述中控系统还可以控制所述景区通勤车自主导航至指定地点。

在本实施方式中，所述方向操纵杆为摇杆状，用于接收用户的方位指令操作，以向所述中控系统发送对应的方位指令。所述方向操纵杆可以位于所述景区通勤车第一个座位前方右手位。在手动驾驶模式时，用户以对所述方向操作杆进行操作以控制方向，提高用户用车趣味性。例如，所述方向操纵杆可以如图4中的操作杆。所述方向操纵杆可以约束于六个方位角，分别对应前、后、左、右、左前、右前六个方位指令。所述景区通勤车通过所述方向操纵杆省略了复杂的转向结构，提高了操纵体验，节省方向盘的位置的空间。

在本实施方式中，所述驻车踏板用于接收用户的脚踏压力，以向该景区通勤车的中控系统发送对应的刹车信号。所述驻车踏板被踩下时，通过传感器将刹车信号传递到中控系统，中控系统发出刹车信号给轮毂电机，进行电磁刹车制动。省去了复杂的机械刹车结构，提高刹车灵敏性和使用寿命。

请参阅图4、图10、图11，为本事实施方式提供的一种景区通勤车示例。在本示例中，所述景区通勤车包括方向操纵杆，触摸显示器，驻车踏板，中控系统，电池组，电量显示模块，电池充电触头，六轮独立悬挂底盘，车篷，挡风玻璃，超声波雷达，防跌落雷达，双目摄像头，激光雷达，防撞梁，驱动控制箱，座椅，安全带。所述景区通勤车采用六轮六驱动独立悬挂底盘技术，能够适应不同的工作环境(如不同坡度的地面、草坪、石子路等)。所述景区通勤车具有自动导航部署、自主规划路径、手动遥控和远程遥控能力，并具有自动充电功能。

在本示例中，用户可以通过用户客户端可以远程叫车，服务器确定目标通勤车，该目标通勤车自动驾驶到设定位置接驳，用车完毕可以自动驾驶回到设定位置(车库、充电桩等)。

在本示例中，所述景区通勤车使用方向操纵杆替代传统方向盘转向，方向操纵杆有前、后、左、右、左前、右前六个方位指令，通过电子传到底盘的所述中控系统，所述中控系统根据指令驱动整车做出相应运动。

在本示例中，所述景区通勤车的驻车踏板使用电磁制动，驻车踏板被踩下时，通过传感器将刹车信号传递到中控系统，中控系统发出刹车信号给轮毂电机，进行电磁刹车制动。

在本示例中，用户可以自定义游览路线，所述景区通勤车的自动导航模块可以依靠特定算法，自动驾驶达到目的地；驾驶过程中可自动避障，避免发生不必要的危险；车辆使用完毕可自动归位，有序摆放。

在本示例中，用户可以用户也可以手动操纵所述景区通勤车到达目的地或者游玩。

在一个实施方式中，所述接车信息为接车行程信息，所述接车行程信息用于指引所述景区通勤车行驶至用户上车位置信息对应的位置。

在本实施方式中，所述接车行程信息已由服务器侧计算得到，可以减轻所述景区通勤车客户端侧的计算压路，可以降低所述景区通勤车侧中控系统的压力。

在一个实施方式中，所述接车信息为用户上车位置信息，以用于所述中控系统根据所述上车位置信息计算得到接车行程信息，以用于所述中控系统控制所述景区通勤车行驶至所述上车位置信息对应的位置。

在本实施方式中，所述接车行程信息为用户上车位置信息，对应的，所述景区通勤车中控系统可以通过该用户上车位置信息计算得到所述接车行程信息，并根据所述接车行程信息，控制所述景区通勤车行驶至对应的上车点。

在本实施方式中，所述接车行程信息由所述景区通勤车客户端侧计算得到，可以减轻服务器侧计算压力。

在一个实施方式中，所述中控系统还用于根据接收的驾驶模式的执行指令控制该景区通勤车的驾驶模式；其中，所述驾驶模式的执行指令至少包括以下之一：手动驾驶模式执行指令、自动驾驶模式执行指令；在所述中控系统接收的所述驾驶模式的执行指令为手动驾驶模式执行指令的情况下，所述中控系统根据接收的所述方位指令控制该景区通勤车的方向；在所述中控系统接收的所述驾驶模式的执行指令为自动驾驶模式执行指令的情况下，所述中控系统根据游览行程信息控制该景区通勤车行驶至目标位置信息对应的位置。

在本实施方式中，所述驾驶模式的执行指令用于确定驾驶模式。所述驾驶模式的执行指令可以是用户在用户客户端输入的发送给服务器的驾驶模式信息，服务器根据该驾驶模式信息发送给对应所述景区通勤车的所述驾驶模式的执行指令。所述驾驶模式的执行指令也可以是用户操作所述景区通勤车对应模块以得到。例如，所述景区通勤车上有驾驶模式开关，用户针对该开关进行操作，以选择对应的驾驶模式。再例如，所述景区通勤车的触摸显示器的界面提供有驾驶模式选项以供用户选择。此处不做具体赘述。

在一个实施方式中，所述方向操纵杆约束于六个方位角，分别对应前、后、左、右、左前、右前六个方位指令。

在本实施方式中，所述方向操纵杆可以分别向前、后、左、右、左前、右前推拉，以对应前、后、左、右、左前、右前六个方位指令。

在一个实施方式中，所述景区通勤车还可以包括触摸显示器；其中，所述触摸显示器至少包括第一输入模块、行程展示界面；所述第一输入模块用于供用户输入验证信息，以验证该用户的用车资格；所述行程展示界面用于展示游览行程信息。

在一个实施方式中，所述触摸显示器还可以包括第二输入模块；所述第二输入模块用于供用户输入目标位置信息，以获取游览行程信息并展示于行程展示界面。

在一个实施方式中，所述触摸显示器还包括第三输入模块；所述第三输入模块用于供用户输入用车完毕信息；所述网络通信单元根据用户输入的用车完毕信息，向服务器发送对应信息，以使所述服务器根据该景区通勤车的当前位置信息，计算归位行程信息；向该景区通勤车客户端发送归位行程信息，以指引该景区通勤车归位。

在一个实施方式中，所述景区通勤车的底盘为六轮六驱动独立悬挂底盘。

在一个实施方式中，所述景区通勤车的前端还布置有摄像头，用于获取前方环境路况信息；所述景区通勤车的周身还布置有至少4个雷达；所述景区通勤车的车顶面前端面和后端面为一体式车篷；其中，前端面的倾斜部安置有挡风玻璃。

在本实施方式中，所述摄像头用于获取前方环境路况信息，以平稳安全行驶。在本实施方式中，该一体式车篷结构简单，安装简单，用户上下车也方便，同时具备一定的挡雨挡太阳的功能，比较适合景区通勤车，

本说明书中的各个实施方式均采用递进的方式描述，各个实施方式之间相同相似的部分互相参见即可，每个实施方式重点说明的都是与其他实施方式的不同之处。

本说明书实施方式中提及的服务器，可以是具有一定运算处理能力的电子设备。其可以具有网络通信端子、处理器和存储器等。当然，上述服务器也可以是指运行于所述电子设备中的软体。上述服务器还可以为分布式服务器，可以是具有多个处理器、存储器、网络通信模块等协同运作的系统。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片2。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog2。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本说明书可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本说明书的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本说明书各个实施方式或者实施方式的某些部分所述的方法。

虽然通过实施方式描绘了本说明书，本领域普通技术人员知道，本说明书有许多变形和变化而不脱离本说明书的精神，希望所附的权利要求包括这些变形和变化而不脱离本说明书的精神。