计算装置及其控制方法与流程

文档序号:17158637发布日期:2019-03-20 00:20阅读:181来源:国知局
计算装置及其控制方法与流程

本公开涉及包括在运输系统中的计算装置,并且更具体地,涉及将驾驶员和乘客彼此连接的计算装置及其控制方法。



背景技术:

一般地,终端可以根据其移动性而分为移动/便携式终端或静止终端。移动终端还可根据用户是否能直接携带该终端而分为手持终端或车载终端。

移动终端已经变得越来越功能化。这些功能的示例包括数据和语音通信、借助相机捕获图像和视频、记录音频、经由扬声器系统播放音乐文件以及在显示器上显示图像和视频。一些移动终端包括支持游戏播放的附加功能,而其他终端被配置为多媒体播放器。最近,移动终端已被配置成接收允许诸如视频和电视节目这样的内容的观看的广播和多播信号。

由于移动终端的改进,开发出各种共享经济服务。共享经济意指可以根据需要尽可能地出租或出借货物、生产设施和服务的经济。

这种共享经济的代表性例子是运输服务。运输服务意指驾驶员使用他/她的车辆将乘客从出发点移动到目的地。作为共享经济的运输服务持续发展,以在作为车辆提供方的任何驾驶员和作为车辆用户的任何乘客之间提供中继。

由包括乘客终端、驾驶员终端和中继乘客终端和驾驶员终端的服务器的运输系统来提供运输服务。

例如,乘客可以使用乘客终端来命令车辆到达特定地点,服务器选择将向乘客提供车辆的驾驶员,并且向所选择驾驶员的驾驶员终端请求预约。所选择驾驶员的驾驶员终端向驾驶员提供服务器的请求,使得可以执行乘客和驾驶员之间的中继。

为了使运输服务能够发挥其作为共享经济的作用,它应该从乘客和驾驶员之间的简单连接推进为使更多的人使用一辆车。

另外,必须开发各种用户界面,以便在提供运输服务的同时,为乘客和驾驶员中的每位提供方便。



技术实现要素:

本公开的一个目的是提供能够解决以上和其他问题的计算装置及其控制方法。

本公开的另一个目的是提供能够提供新型运输服务的计算装置及其控制方法。

本公开的又一个目的是提供包括移动终端的运输系统。

本公开的再一个目的是提供能够不仅向乘客而且向提供运输服务的驾驶员提供便利的移动终端及其控制方法。

为了实现根据本公开的一方面的以上和其它目的,提供了一种用于计算装置的控制方法。该控制方法可以包括以下步骤:基于从驾驶员终端接收的车辆信息注册提供运输服务的车辆;生成包括第一停靠点和第二停靠点的所述车辆的常规路线;将关于所述常规路线的信息发送到所述驾驶员终端,使得所述常规路线显示在所述驾驶员终端的显示器上;以及当从所述驾驶员终端接收到对所述常规路线的批准消息时,向所述车辆发送自主驾驶命令,使得所述车辆沿着所述常规路线执行自主驾驶。

根据另一个实施方式,可以提供一种提供运输服务的应用的车辆控制方法。所述控制方法可以包括:控制安装有所述应用的所述车辆,使得沿着包括第一停靠点和第二停靠点的第一路线反复执行移动和停车;响应于下车请求,当由登上所述车辆的乘客生成下车请求时,搜索下车地点;以及控制所述车辆停在搜索到的下车地点。

根据又一个实施方式,可以提供一种用于控制向乘客终端提供关于运输服务的信息的计算装置的方法。该控制方法可以包括以下步骤:注册包括车辆的第一停靠点和第二停靠点的常规路线;将关于所述常规路线的信息发送到所述乘客终端中的至少一个;当从所述乘客终端中的至少一个接收到关于所述车辆的登乘请求或下车请求时,将与所述登乘请求或所述下车请求对应的预定地点作为第三停靠点添加到所述常规路线;向所述乘客终端中的至少一个发送告知将所述第三停靠点添加到所述常规路线的通知信息;以及向所述车辆发送自主驾驶命令,使得所述车辆以预设顺序沿着所述第一停靠点、所述第二停靠点和所述第三停靠点往返。

根据本公开的一方面,可以提供一种包括上述计算装置的运输系统。

根据按照本公开的运输系统,一种服务器可以基于注册的任一车辆生成常规路线,并且控制所述任一车辆沿着常规路线提供运输服务。在这种情形下,由于确定了路径、停靠点的位置和数目中的至少一个,因此可以更多地增强运输服务的效率。

另外,车辆的管理方可以使用他/她的车辆提供运输服务,但是他/她不自己驾驶,由此通过共享经济创造收益。由于可以随时随地使用他自己所有的驾驶员终端编辑车辆的常规路线,因此能够越来越多地增加提供运输服务的供应方的便利度。

在提供运输服务时,车辆和/或乘客终端可以提供各种用户界面,使得乘客能够在期望的地点下车。车辆没有响应于下车请求停在任意地方,而是可以在考虑到乘客安全并且不引起任何法律问题的情况下,停在许多地点中的被设置为乘客能够下车的下车地点的地点。由于下车地点可以根据车辆和/或乘客而变化,因此可以越来越多地增加用户便利度。

附图说明

附图被包括进来以提供对本发明的进一步理解,附图并入本说明书并构成本说明书的一部分,例示了示例性实施方式并且与本说明书一起用来解释本发明的原理。

在附图中:

图1是例示了根据本公开的实施方式的运输系统的概念图;

图2是例示了根据本公开的实施方式的在图1的服务器中执行的代表性控制方法的流程图;

图3a和图3b是例示了根据本公开的实施方式的图2的控制方法的概念图;

图4是例示了根据本公开的实施方式的在车辆开始沿着常规路线自主驾驶之前的车辆的操作的流程图;

图5是例示了根据本公开的实施方式的根据乘客的登乘请求添加停靠点的操作的流程图;

图6a和图6b例示了根据本公开的实施方式的图5的操作的示例性视图;

图7是例示了根据本公开的实施方式的更新常规路线的控制方法的流程图;

图8a和图8b是例示了当接收到登乘请求时从乘客终端提供的用户界面的示例性视图;

图9是例示了根据本公开的实施方式的沿着常规路线执行自主驾驶的车辆的控制方法的流程图;

图10是例示了根据本公开的实施方式的当新建立新停靠点时通知新停靠点的方法的概念图;

图11a至图11c是例示了根据本公开的实施方式的提供运输服务的运输系统的示例的概念图;

图12是例示了根据本公开的实施方式的下车地点处的车辆的操作的流程图;以及

图13是例示了根据本公开的实施方式的更新预设常规路线的服务器的操作的流程图。

具体实施方式

现在,将参照附图来详细描述根据本文中公开的示例性实施方式。为了参照附图进行简要描述,将为相同或等同的组件提供相同或类似的参考标号,并且将不再重复对其的描述。通常,可以使用诸如“模块”和“单元”这样的后缀来指代元件或组件。本文中使用这样的后缀仅仅是旨在促成对说明书的描述,并且后缀本身不旨在给出任何特定的含义或功能。在本公开中,为了简洁起见,通常省略了相关领域的普通技术人员所公知的内容。使用附图来帮助容易地理解各种技术特征,并且应该理解,本文中呈现的实施方式不受附图的限制。因此,作为在附图中特别阐述的内容的补充,本公开应该被解释为延伸到任何改变、等同和替代。

虽然在本文中可以使用术语“第一”、“第二”等来描述各种元件,但这些元件不应该受这些术语限制。这些术语通常只是用于将一个元件与另一个区分开。

当元件被称为与另一个元件“相连接”时,元件可以与该另一个元件连接,或者也可以存在中间元件。相比之下,当元件被称为与另一个元件“直接连接”时,不存在中间元件。

单数表示可以包括复数表示,除非根据上下文它代表绝对不同的含义。

本文中使用诸如“包括”或“具有”这样的术语,并且应该理解,它们旨在指示说明书中公开的几个组件、功能或步骤的存在,并且还要理解,同样可以采用更多或更少的组件、功能或步骤。

根据本发明的实施方式的车辆可以被理解为包括汽车、摩托车等的概念。下文中,将基于汽车来描述车辆。

根据本发明的实施方式的车辆可以是包括用引擎(engine)作为动力源的内燃机车、用引擎和电动机作为动力源的混合动力车辆、用电动机作为动力源的电动车辆等全部的概念。

在下面的描述中,车辆左侧是指车辆驾驶方向上的左侧,车辆右侧是指驾驶方向上的右侧。

车辆100可以包括在驱动力作用下转动的车轮和用于调节车辆100的驾驶(前进、移动)方向的转向设备。车辆100可以是自主车辆。基于用户输入,车辆100可以切换成自主模式或手动模式。例如,基于通过用户界面设备接收的用户输入,车辆可以从手动模式切换成自主模式或者从自主模式切换成手动模式。

车辆100可以基于驾驶环境信息而切换成自主模式或手动模式。可以基于从物体检测设备提供的物体信息来生成驾驶环境信息。例如,基于在物体检测设备中生成的驾驶环境信息,车辆100可以从手动模式切换成自主模式或者从自主模式切换成手动模式。

在一个示例中,基于通过通信设备接收的驾驶环境信息,车辆100可以从手动模式切换成自主模式或者从自主模式切换成手动模式。基于从外部装置提供的信息、数据或信号,车辆100可以从手动模式切换成自主模式或者从自主模式切换成手动模式。

当车辆100以自主模式驾驶时,可以基于操作系统来驾驶自主车辆100。例如,可以基于在驾驶系统、停车驶出系统和停车系统中生成的信息、数据或信号来驾驶自主车辆100。

当以自主模式驾驶车辆100时,自主车辆100可以通过驾驶控制设备接收用于驾驶的用户输入。可以基于通过驾驶控制设备接收到的用户输入来驾驶车辆100。

在车辆100处设置的至少一个处理器生成“车辆驾驶信息”。车辆驾驶信息包括车辆信息和车辆周遭信息。与基于车辆100的框架的车辆的内部有关的信息可以被定义为车辆信息,并且与基于车辆100的框架的车辆的外部有关的信息可以被定义为周遭信息。

车辆信息可以意指关于车辆本身的信息。例如,车辆信息可以包括车辆的驾驶速度、驾驶方向、加速度、角速率、gps(全球定位系统)、重量、乘客数量、制动力、最大制动力、每个车轮的气动、离心力、驾驶模式(自主驾驶或手动驾驶)和停车模式(自主停车、自动停车或手动停车)、用户是否登上车辆和与用户相关的信息。

周遭信息意指与位置在基于车辆的预定范围内的物体有关的信息和与车辆的外部相关的信息。例如,周遭信息可以包括车辆正在其上驾驶的路面的状况(摩擦力)、天气、与前方(或后方)车辆的距离、前方(或后方)车辆的相对速率、当车辆正在其上驾驶的车道弯曲时该弯曲的曲率、车辆周围的亮度、与基于车辆的基准区域(预定区域)中存在的物体有关的信息、物体是否进入/逃离预定区域、用户是否存在于车辆周围和与该用户相关的信息(例如,用户是否是通过认证的)。

另外,周遭信息可以包括周围的亮度、温度、太阳的位置、关于周围物体(人、另一车辆、标志等)的信息、车辆正在其上驾驶的路面的类型、地标、标线信息、驾驶车道信息和为自主驾驶/自主停车/自动停车/手动停车模式所需的信息。

此外,周遭信息还可以包括从车辆100到车辆100周围存在的物体的距离、碰撞的可能性、物体的类型、其中允许停车的停车位、用于标识停车位的物体(例如,停车标线、绳子、另一车辆、墙壁等)等。

车辆驾驶信息不限于如上所述的示例,并且可以包括通过设置在车辆100中的组件生成的所有信息。

图1是例示了根据本公开的运输系统800的概念图。运输系统800包括服务器810、安装有乘客应用822的乘客终端820、安装有驾驶员应用832的驾驶员终端830和安装有车辆应用842的车辆840。

本公开中描述的乘客终端820和/或驾驶员终端830可以包括移动终端、智能电话、膝上型计算机、用于数字广播的终端、pda(个人数字助理)、pmp(便携式多媒体播放器)、导航、触屏平板pc、平板pc、超级本和可穿戴装置(例如,手表型终端(智能手表)、眼镜型终端(智能眼镜)、hmd(头戴式显示器)等)。然而,本领域的人员将注意到,在本实施方式的说明中描述的组合可以适用于诸如数字tv、台式计算机和数字标牌这样的固定终端。终端可以意指乘客终端820和驾驶员终端830中的至少一个。

另外,可以通过分别设置在乘客终端820和驾驶员终端830处的应用执行如下文中所述的用于运输系统的控制方法。具体地,可以由乘客应用822执行乘客终端820的操作,并且由驾驶员应用832执行驾驶员终端830的操作。

服务器810、乘客终端820和驾驶员终端830可以被简称为将执行将在下文中描述的各种实施方式(或控制方法)的“计算装置”。

运输系统800被配置为通过任何驾驶员向任何乘客提供运输服务。可以通过运输系统800执行预约、中继、联络、运输和驾驶员评价。

运输服务的预约意指乘客使用乘客终端820请求去往出发点的车辆。此请求被称为“车辆请求”,并且车辆请求被发送到服务器810。

车辆请求可以包括出发点、乘客想要移动到的目的地、乘客想要使用的车辆类型和服务类型。也就是说,车辆请求包括车辆请求的条件,并且服务器810搜索符合车辆请求的条件的候选车辆并且向搜索到的候选车辆发送预约请求。

出发点可以是乘客设置的地点或者与设置在车辆处的多个停靠点中的至少一个停靠点对应的地点。另外,目的地可以是乘客设置的地点或者与设置在车辆处的多个停靠点中的至少另一个停靠点对应的地点。

车辆类型可以包括与车辆本身相关的类型和与包括在车辆中的物体相关的类型。与车辆本身相关的车辆类型可以是双座汽车、四座汽车和敞篷车,并且与物体相关的类型可以是冰箱、轮椅和伞。例如,当接收到对包括冰箱的双座汽车的请求时,服务器搜索满足车辆类型的车辆。

服务类型可以意指通过车辆提供的服务。这可以包括排他性使用车辆的专用服务以及车辆与任何第三方共享的联合服务。

在本说明书中,一起乘坐被称为乘坐共享,但是也可以被称为车辆共享、汽车共享和拼车。

中继意指服务器810响应于车辆请求而将至少一个车辆指派给请求车辆的一名乘客。具体地,服务器810搜索位置在基于乘客终端820的位置的预定范围内的一个或更多个驾驶员终端,并且向搜索到的驾驶员终端830请求预约。此请求称为“预约请求”。此后,当任何一个驾驶员终端830批准该预约请求时,执行驾驶员终端830和乘客终端820之间的中继。通过中继,完成驾驶员终端830和乘客终端820之间的连接,并且共享用于提供服务的各种信息。例如,可以共享每个终端的位置。

联络意指中继的乘客和驾驶员之间的会合。从完成中继时起到执行登乘之前,在乘客终端820和驾驶员终端830处执行用于联络的各种功能。例如,可以向驾驶员终端830输出从驾驶员终端移动到出发点的路径,并且可以向乘客终端820输出车辆到达出发点所需的剩余时间。

运输意指在完成登乘之后从出发点到目的地的移动。乘客可以在移动时使用他的乘客终端820改变通向目的地的路线或目的地本身,并且设置转乘。在这种情形下,乘客终端820、服务器810和驾驶员终端830有机地操作,使得可以改变路径并且可以经由改变后的路径提供运输服务。

驾驶员评价意指乘客在移动时或者在下车之后执行的评价。例如,可以向乘客终端820输出可以在移动时或者在下车之后评价驾驶员的用户界面。当乘客经由乘客终端820评价驾驶员时,服务器810存储驾驶员的评价,并且可以使用所存储的大数据对驾驶员进行分类。

运输系统800的每个组件彼此有机地组合以处理在每个终端处生成的位置信息,并且可以使用位置信息提供运输服务。运输系统800的每个组件810-830通过网络与每个其他组件进行数据收发,并且有机地协作以执行与运输服务相关的各种功能。

安装在每个组件中的各种应用和/或硬件可以执行运输服务的逻辑。例如,可以通过乘客应用822执行下文中将描述的乘客终端820的操作,并且可以通过驾驶员应用832执行驾驶员终端830的操作。

服务器810被配置为中继乘客终端820和驾驶员终端830。服务器810可以包括乘客数据库、驾驶员数据库和地图数据库。

当从乘客终端820接收到车辆请求时,服务器810可以基于乘客终端820的位置选择满足预定条件的一个或更多个驾驶员终端,并且向所选择的驾驶员终端发送预约请求。在这种情形下,可以选择距离出发点预定距离内的驾驶员终端或者能够在预定时间内移动到出发点的驾驶员终端。

当接收到预约请求的任一个驾驶员终端830批准预约请求时,乘客终端820和驾驶员终端830分别执行被预设用于在乘客终端820和驾驶员终端830之间进行联络的功能。为了执行该预设功能,乘客终端820和驾驶员终端830可以直接收发其位置信息或通过服务器810间接收发其位置信息。

乘客终端820可以输出车辆的位置和到达出发点所需的时间。另外,驾驶员终端830可以输出将车辆引导到出发点的路径通知信息。可以由服务器810或驾驶员终端830计算车辆的移动路径。

当乘客登上车辆时,驾驶员终端830和/或乘客终端820可以向服务器810发送登乘报告。此后,执行到目的地的运输服务,并且用运输距离和运输时间中的至少一个来计算运输的费用。可以根据提供给运输的车辆的类型和/或服务的类型来不同地计算费用。用预先注册的信用卡或电子货币来支付计算出的费用。

运输系统800可以通过安装在车辆840中的车辆应用842控制经由驾驶员终端830注册的车辆840。车辆840意指可以执行自主驾驶的车辆。并且,“注册”意指驾驶员终端的所有者向服务器810公开他对其车辆的权利,使得他的车辆在服务器810的控制下提供运输服务。例如,当通过第一驾驶员终端注册第一车辆时,服务器810可以远程控制第一车辆的自主驾驶以使得第一车辆可以提供运输服务,并且与第一驾驶员终端共享通过远程控制生成的各种信息。

在一个驾驶员终端中可以注册一个或更多个车辆,并且可以通过执行注册的驾驶员终端来控制或者通过服务器810来控制所注册的一个或更多个车辆。驾驶员应用832可以提供用于注册车辆的用户界面以及用于远程控制车辆的用户界面。

将参照图2、图3a和图3b详细地描述如上所述通过运输系统800提供的运输服务。图2是例示了图8的服务器中执行的代表性控制方法的流程图,图3a和图3b是例示了图2的控制方法的概念图。

安装在服务器810中的计算装置执行图2中示出的每个处理。

首先,服务器810基于从驾驶员终端830接收的车辆信息注册将提供运输服务的车辆(s910)。车辆信息从驾驶员终端830发送到服务器810,并且车辆信息可以包括车辆840的类型、车辆840的车辆编号、关于设置在车辆840中的传感器的信息、用于与车辆840通信的通信代码和用于远程控制车辆840的认证密钥中的至少一个。

此外,车辆信息可以包括被设置成使得驾驶员可以排他性使用车辆840的专用时间信息和/或被设置成共享车辆840的共享时间信息。服务器840可以使用专用时间信息和/或共享时间信息来生成车辆840的时间表。

例如,当驾驶员出于通勤目的使用车辆时,可以将上班时间和下班时间设置为驾驶员排他性使用车辆840的专用时区。在这种情形下,服务器810不能在专用时区期间远程控制车辆840,而是可以在除了专用时区之外的剩余时区中远程控制车辆840。在另一种情形下,当设置共享时区时,服务器810可以只在被设置为共享时区的时间内远程控制车辆840。可以通过输入到被设置在驱动器终端830中的用户界面的用户输入来编辑所生成的时间表,或者可以生成与所生成的时间表不同的新时间表。

接下来,服务器810可以生成车辆840的常规路线(s930)。服务器810可以使用车辆840来产生提供运输的常规路线。更具体地,常规路线意指包括第一停靠点和第二停靠点的预设路径,并且车辆840执行自主驾驶,使得沿着常规路线反复地执行移动和停车。

常规路线包括第一停靠点和第二停靠点。第一停靠点和第二停靠点可以是车辆840在其处反复循环的基准点。例如,如图3a中所示,可以针对车辆840产生与第一路径1010对应的第一常规路线。第一常规路线可以包括第一停靠点1012和第二停靠点1014。

当产生第一常规路线时,服务器810可以生成第一常规路线的操作时间表。根据操作时间表,可以针对包括在第一常规路线中的停靠点中的每个停靠点设置不同的到达时间。例如,如图3a中所示,车辆840可以在从十(10)点整到十点三十分停在第一停靠点1012处,并且在从十七(17)点整到十七点三十分停在第二停靠点1014处。

当车辆840从第n停靠点移动到第(n+1)停靠点时,服务器810和/或车辆840可以调节车辆840的速度,使得车辆840在设定的到达时间到达第(n+1)停靠点(其中,n是自然数)。当生成操作时间表时,车辆840依照操作时间表来调节速度,并且在所确定的时间到达每个停靠点。因此,预设了常规路线的操作次数。另外,当没有生成操作时间表时,车辆840在任意时间到达每个停靠点,并且会根据交通状况变化常规路线的操作时间。

另外,当通过驾驶员终端830接收到出发点和目的地时,服务器810可以利用出发点设置第一停靠点,并且利用目的地设置第二停靠点。并且,服务器810可以搜索往返第一停靠点和第二停靠点的路径。搜索到的路径以及第一停靠点和第二停靠点构成常规路线,车辆840沿着该路径操作,并且可以在沿着该路径停在第一停靠点和第二停靠点处之后再次操作。

服务器810可以基于累积在服务器810中的大数据来提取任何地点作为第一停靠点和第二停靠点。换句话讲,服务器810可以将用于生成车辆840的路线的任何地点设置为第一停靠点和第二停靠点,尽管它们不是由用户输入的。例如,当接收到在其中通过驾驶员终端830提供有运输服务的区域时,服务器810可以提取该区域中的存在大量运输服务请求的多个地点,并且将所提取的地点设置为第一停靠点和第二停靠点。

另外,可能存在车辆840将在其上驾驶的许多类型的道路,并且可能还存在根据车辆840的类型允许或不允许驶入的道路。此外,可以根据法律针对道路设置各种禁止事项,并且会存在在预定时间内不允许停车的道路、不允许在其上自主驾驶的道路和不能被用作停靠点的道路。

考虑到车辆840的特性和构成常规路线的道路的特性,服务器810可以计算循环通过出发点和目的地的路径,并且计算位于该路径上并且满足预设条件的至少一个停靠点。并且,服务器810可以使用路径和所提取的停靠点来生成常规路线。

该路径可以根据车辆840而变化,并且包括在常规路线中的停靠点的位置和数目也可以变化。这是因为,当车辆是45座公共汽车和双座电动车辆时,允许操作的道路和允许停车的道路有所变化。

另外,常规路线的路径可以按照工作日而变化。由于服务器810具有使用运输服务的用户的历史,因此可以按照工作日计算使用率(收益率)最大化的不同路径。当车辆840执行自主驾驶时,按照工作日不同地计算路径,并且随着路径变化,添加到常规路线的停靠点会变化。

例如,如图3b中所示,车辆840可以在工作日沿着与第一路径1010对应的第一常规路线执行自主驾驶,并且可以在周末沿着与第二路径1040对应的第二路线执行自主驾驶。当路径改变时,在其处执行停车的停靠点的位置和数目中的至少一个可以变化。

另外,常规路线可以包括至少两个停靠点。在计算出路径之后,可以计算该路径上的满足预设条件的至少一个停靠点。具体地,服务器810在该路径上提取允许车辆840停靠达预定时间的区域。允许停车区域可以是相连的一个区域或者是彼此间隔开的多个区域。并且,允许停止区域可以根据国家、城市和路径而变化。

服务器810使用允许停止区域提取m个停靠点。例如,可以以规则的间隔在路径上提取停靠点。例如,当m为10并且出发点和目的地之间的路径距离为10km时,可以每1km提取一个停靠点,而当m为20时,可以每500m提取一个停靠点。

在另一种情形下,服务器810可以提取m个停靠点,使得常规路线中包括的第(n+1)停靠点可以位于基于第n停靠点的预定范围之外。在这种情形下,m可以是大于2的自然数,n可以是小于m的自然数。当提取了三个停靠点时,可以在路径上将第二停靠点设置在距离第一停靠点超过1km的位置处,可以将第三停靠点设置在距离第二停靠点超过1km的位置处。

m和/或预定范围可以根据路径而变化。例如,当出发点和目的地之间的距离小于10km时,可以提取五个停靠点,并且当出发点和目的地之间的距离是10km至20km时,可以提取10个停靠点。在另一示例中,可以设置第一预定范围,使得可以在观光区域中可以生成更多停靠点,而在如同沙漠的没有人居住的非住宅区中,可以设置第二预定范围以便使得不生成停靠点。

提取停靠点的预设条件可以根据车辆840的类型而变化。具体地,服务器810根据车辆840的类型来选择预设条件当中的任何一个条件,并且根据所选择的任一个条件来提取停靠点。可以在服务器810的数据库中存储并管理至少两个停靠点和包括朝向每个停靠点的路径的常规路线。

接下来,服务器810控制车辆840沿着常规路线执行自主驾驶(s950)。具体地,服务器810可以将常规路线发送到车辆840,然后发送自主驾驶命令,使得车辆840可以沿着常规路线执行自主驾驶。

车辆840以预设顺序往返于常规路线中包括的停靠点。在这种情形下,车辆840执行自主驾驶,要么根据服务器840的控制命令沿着常规路线开始操作,要么在停止操作之后返回车库,或者更新常规路线。

车辆840可以在沿着常规路线执行自主驾驶的同时将驾驶信息发送到服务器810。服务器810可以利用车辆驾驶信息进行监视以检查车辆840是否很好地提供了运输服务,并且在出现问题时远程控制车辆840。

如上所述,根据本公开的运输系统800的服务器810可以基于车辆的特性生成常规路线,并且控制车辆沿着常规路线提供运输服务。在这种情形下,由于确定了路径、停靠点的位置和数目中的至少一个,因此能够增强运输服务的效率。

图4是例示了车辆开始沿着常规路线自主驾驶之前的车辆操作的流程图。

当根据如图2中所述的方法生成常规路线时,服务器810将关于所生成的常规路线的信息发送到驾驶员终端830(s1110)。关于常规路线的信息可以包括依据常规路线的路径、常规路线中包括的停靠点的位置、每个停靠点处车辆840的时间表和当车辆840沿着常规路线操作时的预期收益和成本中的至少一个。

驾驶员终端830显示从服务器810接收的信息(s1120)。驾驶员终端830可以通过从驾驶员应用832提供的执行画面显示关于常规路线的信息。

当服务器810自动生成常规路线时,必须获得车辆840的管理方的批准才能沿着常规路线操作车辆840。因此,驾驶员终端830可以提供用于确认或拒绝对常规路线的批准的用户界面。例如,可以在驾驶员终端830的显示器上显示用于选择“是”或“否”的弹出窗口。当对常规路线进行了批准时,驾驶员终端830将批准消息发送到服务器810(s1130)。

另外,当对常规路线的批准未被进行、被取消或者需要编辑时,驾驶员终端830可以提供能够编辑常规路线的用户界面。并且,可以编辑常规路线,或者基于用户输入生成新的常规路线。例如,可以将用于告知常规路线的路径的地图图像和路径图像一起显示。可以另外在地图图像上显示用于告知停靠点的图形对象。驾驶员终端830可以通过基于触摸输入改变路径、删除现有停靠点、改变现有停靠点的位置或者添加新停靠点来生成新的常规路线。所生成的新常规路线可以被发送到服务器810。

驾驶员终端830将批准消息或所生成的新常规路线发送到服务器810。服务器810基于从驾驶员终端830接收的信息来安排常规路线(s1150)。具体地,当发送批准消息时,安排现有的常规路线,而当发送新的常规路线时,安排该新的常规路线来替代现有的常规路线。

接下来,服务器810将按照新安排的常规路线的自主驾驶命令发送到车辆840(s1160)。并且,车辆840根据自主驾驶命令执行自主驾驶(s1170)。

另外,驾驶员终端830和/或服务器810可以在沿着第一常规路线执行自主驾驶的同时,基于用户输入生成新的第二常规路线。在这种情形下,服务器810将自主驾驶修改命令发送到车辆840,使得车辆沿着第二常规路线执行自主驾驶。

车辆840的管理方可以使用驾驶员终端830设置初始值。初始值意指用于生成常规路线的最小条件,并且可以意指在其中生成常规路线的区域和关于车辆840的车辆信息。服务器810可以基于初始值生成车辆840的常规路线,并且可以通过驾驶员终端830编辑所生成的常规路线。一旦安排了常规路线,车辆840就沿着常规路线执行自主驾驶。

如上所述,车辆840的管理方可以使用车辆提供运输服务,但他自己并不驾驶他的车辆,从而通过共享经济创造收益。另外,因为可以使用他自己所有的驾驶员终端830来编辑车辆840的常规路线,所以能够高度增强提供运输服务的供应方的便利度。

当车辆840执行自主驾驶或者预约自主驾驶时,服务器810可以将关于车辆840的常规路线的信息提供到注册在运输系统中的乘客中的至少一名,使得可以使用车辆840向乘客提供运输服务。

下文中,将参照图5、图6a和图6b详细地描述用于中继乘客和车辆的方法。

图5是例示了根据乘客的登乘请求添加停靠点的操作的流程图,并且图6a和图6b是图5的操作的示例性视图。

服务器810将设置在至少一个车辆中的常规路线发送到乘客终端820(s1210)。例如,乘客终端820可以响应于用户请求而显示乘客应用822的执行画面。在这种情形下,乘客终端820可以向服务器810请求能够在特定区域使用或移动到预定目的地的常规路线信息。预定区域和/或预定目的地可以根据乘客终端820的位置而变化,并且还可以根据输入到乘客终端820的用户输入而变化。

服务器810响应于乘客终端820而搜索可以在预定区域处使用的常规路线,并且将关于搜索到的常规路线的信息发送到乘客终端820。乘客终端820可以基于从服务器810接收的信息来显示至少一条常规路线(s1220)。例如,乘客终端820可以显示包括地图图像的乘客应用822的执行画面,其中在地图图像上可以显示有停靠点图标,所述停靠点图标告知可以供乘客终端820的用户使用的停靠点。乘客终端820的用户可以通过滚动地图图像或者输入出发点和/或目的地来从服务器810获取他自己将使用的常规路线。

接下来,乘客终端820可以将关于任何一个车辆的登乘请求发送到服务器810(s1230)。例如,乘客终端820可以基于用户输入来设置出发停靠点和目的地停靠点中的至少一个,并且可以向服务器810发送用于请求运输服务的车辆请求消息。

服务器810搜索与车辆请求消息对应的任辆车辆,并将搜索到的车辆指派给乘客终端820。换句话讲,服务器810可以选择将向乘客终端820的用户提供运输服务的任一车辆。当车辆840被选定为该任一车辆时,服务器810将关于车辆840的登乘请求发送到车辆840(s1240)。

如图6a和图6b中所示,将描述以下情况:针对车辆840设置与第一停靠点1012对应的第一常规路线,并且第一常规路线包括第一停靠点1012和第二停靠点1014。

接下来,服务器810确定生成登乘请求的乘客是否能够使用包括在车辆840的第一常规路线中的现有停靠点。具体地,服务器810可以确定乘客能否在第一停靠点1012和第二停靠点1014中的任一个处进行登乘。

例如,根据是否可以在预定时间内从乘客终端820所处的位置步行移动到现有停靠点,可以确定使用现有停靠点的可能性。在另一示例中,可以根据乘客的行李量、乘客的年龄或乘客有残疾或无残疾来确定是否可以使用现有停靠点。当可以使用现有停靠点时,服务器810控制车辆840,使得乘客终端820的用户可以在现有停靠点处登上车辆840。

另外,当不可以使用现有停靠点时,服务器810可以将与登乘请求对应的第三停靠点添加到车辆840的第一常规路线(s1250)。服务器810可以将与登乘请求对应的预定地点作为第三停靠点添加到第一常规路线。具体地,服务器810可以基于登乘请求中包括的预定地点来搜索基准范围内的至少一个候选停靠点。并且,可以将搜索到的候选停靠点中的任一个作为第三停靠点添加到常规路线。预定地点可以是乘客终端820的用户所设置的出发点或者乘客终端820的当前位置。

服务器810可以将基准范围分类为允许车辆840停在其中达预定时间的允许停车区域和不允许车辆840停在其中达预定时间的不允许停车区域。在这种情形下,允许停车区域和/或不允许停车区域可以根据车辆840的类型和乘客终端820的用户特性而变化。

并且,服务器810可以提取允许停车区域的一个地点作为候选停靠点。为了使乘客终端820的用户的移动最小化,可以将从允许停车区域上的预定地点起算的移动距离最短的地点设置为候选停靠点。

当搜索到多个候选停靠点时,服务器810可以将关于候选停靠点的信息发送到乘客终端820,使得可以选择多个候选停靠点中的任一个。乘客终端820可以提供候选停靠点的清单,并且基于用户输入选择任一个候选停靠点并将其发送到服务器810。将所选择的任一个候选停靠点作为第三停靠点添加。

另外,服务器810可以根据是否搜索到候选停靠点向乘客终端820发送不同的消息。具体地,当在基于预定地点的基准范围内没有搜索到候选停靠点时,可以向乘客终端820发送无停靠点添加消息,并且当搜索到候选停靠点时,可以向乘客终端820发送告知搜索到的停靠点的通知消息。当接收到无停靠点添加消息时,乘客终端820的用户可以用其他搜索条件来搜索,并且当接收到通知消息时,乘客终端820可以在新设置的第三停靠点处登上车辆840。

另外,服务器810可以在添加第三停靠点时,在不改变车辆840的第一常规路线中包括的第一路径的情况下,将第一路径上的一个地点作为第三停靠点添加。例如,如图6a中所示,可以在预定地点1300处接收登乘请求。在这种情形下,服务器810可搜索可以最快地(或者最方便地)从第一路径1010上的预定地点移动到的一个地点,并且将所选择的这个地点作为第三停靠点1016添加。

在另一示例中,如图6b中所示,服务器810可以在不顾及第一路径1010的情况下,将基于预定地点1300的基准范围内的一个地点1016作为第三停靠点添加。并且,服务器810可以计算包括第一停靠点至第三停靠点的第二路径1011,并且控制车辆沿着第二路径1011而非第一路径1010执行自主驾驶。

当将第三停靠点添加到第一常规路线时,服务器810可以向车辆840发送自主驾驶修改命令,使得车辆840可以以预设顺序沿着第一停靠点至第三停靠点往返。车辆840可以响应于自主驾驶修改命令而修改驾驶路线,并且沿着修改后的路径执行自主驾驶(s1260)。

此外,服务器810可以向乘客终端820发送告知第三停靠点被添加到车辆840的第一常规路线的通知消息,并且乘客终端820可以显示通知信息(s1270)。

当第三停靠点被添加到常规路线时,车辆840以预设顺序沿着第一停靠点至第三停靠点往返。也就是说,新的停靠点被添加到第一常规路线。当服务器810向注册在其他运输系统中的其他乘客终端提供关于第三停靠点的信息时,开始使用第三停靠点进行新的运输服务。

根据本公开,当自主驾驶车辆和乘客实时连接并且迅速建立了新的停靠点时,能够更高效地提供运输服务并且能够创造新的收益。

另外,服务器810可以基于累积存储在其中的大数据来更新车辆840的常规路线。服务器810针对车辆840的常规路线记录使用每个停靠点的人数,并且基于所记录的信息来计算使用率。

图7是例示了用于更新常规路线的控制方法的流程图。

服务器810可以分析包括在车辆840的常规路线中的停靠点的使用率(1410)。可以按工作日和按时间来分析使用率,并且提取与使用率低于基准的至少一个停靠点有关的工作日和/或时间。

接下来,服务器810可以从常规路线中删除使用率低于基准的至少一个停靠点(1430)。换句话讲,当使用第三停靠点的人数在预定时间内低于基准时,可以从常规路线中删除第三停靠点。例如,当第三停靠点的使用率低于基准时,可以从常规路线中完全删除第三停靠点。在这种情形下,车辆840以预设顺序沿着第一停靠点和第二停靠点自主地往返。

在另一示例中,只有当第三停靠点的使用率在特定工作日的特定时间低于基准时,才可以仅在一定时间段内从常规路线中删除第三停靠点,使得车辆840在特定工作日的特定时间不停在第三停靠点处。

服务器810不仅可以分析每个停靠点的使用率,而且可以分析常规路线本身的使用率。当使用常规路线的人数低于最小基准时,服务器810可以向车辆840发送待用命令,使得车辆840不执行自主驾驶并且停在预定地点。也就是说,车辆840可以只在存在超过预定水平的使用时才执行自主驾驶,而当不存在使用时,可以等待在预定地点。

另外,还可以根据用成本收益定义的收益率从常规路线中删除至少一个停靠点或者进行更新。

图8a和图8b是例示了当接收到登乘请求时从乘客终端提供的用户界面的示例性视图。

如图8a和图8b中所示,在乘客终端820的显示器上显示乘客应用822的执行画面。执行画面包括地图图像以及位置图标1510,位置图标1510告知乘客终端820在地图图像上的当前位置。此外,执行画面可以包括被配置为输入目的地或乘客人数的用户界面。

乘客终端820基于通过用户界面输入的用户输入来设置至少一个条件,并且将所设置的条件发送到服务器810。服务器810基于该条件搜索至少一辆车辆,并且将关于搜索到的车辆840的常规路线的信息发送到乘客终端820。

乘客终端820可以基于从服务器810接收到的信息,告知可以接收去往目的地的运输服务的至少一个停靠点1520。当选择了至少一个停靠点1520时,可以显示将提供去往目的地的运输服务的车辆的服务信息。服务信息可以包括与指示外观的车辆的图像、车辆的预期到达时间、剩余座位、去往目的地的移动路径、使用费用和可供预约的座位中的至少一个有关的信息。

另外,如图8b中所示,可以针对不存在停靠点的地点在乘客终端820处生成停靠点添加请求。例如,当向不存在停靠点的地点施加长触摸时,可以针对被施加长触摸的地点生成停靠点添加请求。

在这种情形下,如图5中所示,确定是否可以使用现有停靠点,并且当现有停靠点可供使用时,可以显示移动到现有停靠点的通知信息。

当将新的第三停靠点替代现有停靠点添加到常规路线时,可以在乘客终端820的显示器上显示导向第三停靠点的通知信息。

当在现有路线上的一个地点处产生第三停靠点时,不引起附加费用,但是当因新建立了第三停靠点而应该改变现有路线时(或者,当在并非现有路线上的一个地点的地点处产生第三停靠点时),会产生附加费用。当产生附加费用时,该附加费用可以被包括在通知信息中。可以与新添加的路线的距离成正比地计算附加费用。

希望使用运输服务的人可以通过他自己的乘客终端820容易且快速地请求车辆,并且另外也可以请求添加新的停靠点。

另外,车辆840沿着由服务器810生成的常规路线执行自主驾驶。将参照图9详细描述用于控制安装在车辆840中的提供运输服务的应用的车辆的方法。

图9是例示了沿着常规路线执行自主驾驶的车辆的控制方法的流程图,图10是例示了当新建立新停靠点时用于告知新停靠点的方法的概念图。通过安装在车辆840中的应用执行图9中描述的控制方法,并且可以由设置在车辆840中的至少一个处理器执行该应用。该应用可以是已在图1中描述的车辆应用842。这里,“安装在车辆840中”可意指它被安装在操作系统中,其中所述操作系统控制在车辆840中设置的至少一个硬件,或者“安装在车辆840中”可意指它被存储在设置在车辆840中的存储器中。

控制在车辆840中设置的至少一个处理器,使得沿着包括第一停靠点和第二停靠点的第一路线反复执行移动和停车(s1610)。车辆840通过自主驾驶沿着第一路线移动,并且停在第一停靠点和第二停靠点中的一个处,使得乘客能够登乘。

车辆840的驾驶车道和/或驾驶速度可以根据驾驶信息而变化,但是驾驶方向遵循第一路线。并且,当到达第一停靠点和第二停靠点时,车辆840执行停车达预定时间。该预定时间可以根据实施方式而变化,并且可以被延长,直到预约登乘的乘客登上车辆840。

接下来,当已登上车辆的乘客生成下车请求时,搜索下车地点(s1630)。可以通过各种媒介将下车请求输入车辆840。例如,可以通过设置在车辆840中的麦克风接收诸如“letmegetoffhere(让我在这里下车)”这样的语音命令。在另一示例中,可以通过设置在车辆840中的触摸屏和/或按钮(或响铃)接收与下车请求相对应的触摸输入和/或推动输入。又例如,下车消息可以从乘客所有的乘客终端被接收到车辆840。换句话讲,下车消息可以由乘客所有的乘客终端生成,然后被车辆840的通信单元接收。

当乘客终端820感测到用户登上车辆840时,乘客终端可以提供能够生成下车消息的菜单或下车图标。根据用户是否登上车辆840,下车图标可以从乘客终端的显示器中消失。当向下车图标施加触摸时,乘客终端可以生成下车消息并且将它发送到车辆840或服务器810。

下车消息可以包括请求下车的预定地点。例如,当通过按下设置在车辆840中的按钮产生下车请求时,不包括该预定地点,并且应用可以将车辆840的当前位置设置为预定地点。在另一示例中,当接收到语音“letmegetoffoverthere(让我在那里下车)”时,可以搜索乘客做出手势的地方,并且可以将搜索到的地点设置为预定地点。

此外,当输入纬度和经度、输入地址、输入能够指定地址的电话号码并且指定地图上的一个地点时,这对应于包括预定地点的情况。

当在基于预定地点的基准范围内存在包括在常规路线中的停靠点时,应用将对应的停靠点设置为下车地点。

另外,当不存在包括在常规路线中的停靠点时,可以将并非停靠点的地点设置为下车地点。在这种情形下,应用可以在基于预定地点的基准范围内搜索车辆840可以停在其中的允许停车区域,并且将允许停车区域的一个地点设置为下车地点。这么做是考虑乘客的安全并且禁止车辆进行任何违法行为。

当下车请求中包括请求在其处下车的预定地点时,可以基于预定地点搜索允许停车区域,并且当不包括预定地点时,可以基于车辆搜索允许停车区域。

下车地点可以根据车辆840的类型和乘客的特性中的至少一个而变化。例如,当车辆840是45座公共汽车或2座汽车时,可以搜索不同的下车地点。在另一示例中,当乘客是残疾人时,可以将满足残疾人下车条件的地点设置为下车地点。

接下来,车辆应用842控制车辆840停在搜索到的或设置的下车地点。可以在停在下车地点之前输出告知下车的通知消息。当剩余距下车地点的基准距离或基准时间时,可以输出下车消息。

下车通知消息可以包括下车地点、与下车地点的距离、下车时收取的费用和下车地点处的停靠点的名称中的至少一个。可以通过安装在车辆840中的麦克风或者设置在计划下车的乘客的乘客终端820中的显示器或扬声器来输出下车通知消息。

当登上车辆840的多名乘客当中的任一名乘客生成下车消息时,可以向请求下车的该任一名乘客的乘客终端输出告知下车的通知消息。例如,服务器810可以在车辆840停在下车地点之前向乘客终端820发送用于输出下车消息的命令。在另一示例中,乘客终端820可以计算到下车地点的剩余距离和/或剩余时间,并且在停在下车地点之前输出通知消息。又例如,车辆840可以在停在下车地点之前向乘客终端820发送用于输出下车通知消息的命令。

另外,应用可以建立用下车地点定义的第三停靠点(s1670)。这是因为,在乘客请求在其处下车的地点处频繁且反复地产生停车和下车,将该下车地点作为新停靠点添加以便持续吸引乘客。

应用可以自己建立第三停靠点,或者请求服务器810建立第三停靠点。下文中,尽管为了说明而将描述由应用建立第三停靠点的情况作为示例,但是服务器810可以替代应用建立第三停靠点。

应用可以通过响应于下车请求而搜索候选停靠点并且将搜索到的候选停靠点作为第三停靠点添加到常规路线来将第三停靠点添加到现有常规路线。

当搜索到多个候选停靠点时,应用可以利用先前执行登乘和下车的历史来选择任一个候选停靠点。通过大数据来管理历史,并且可以选择根据历史统计数据被乘客使用的概率最高的任一个候选停靠点。

应用可以生成包括第三停靠点的新路线。具体地,应用可以生成包括第一停靠点和第二停靠点以及用下车地点定义的第三停靠点的第二路线。在这种情形下,应用可以控制车辆840沿着第二路线而非第一路线反复移动和停车。当生成第二路线时,与第一路线相比,车辆840的驾驶路径可以有所变化,并且关于第二路线的信息可以被发送到服务器810并且被存储在其中。

另外,当添加第三停靠点或者生成新常规路线时,应用可以在设置在车辆840中的显示器上显示告知第三停靠点和/或新常规路线的路线图像。例如,如图10中所示,车辆840可以包括显示器1710。可以在显示器1710上显示地图图像,并且可以在地图图像上显示告知第三停靠点的位置的文本、图形对象和视频中的至少一个。

此外,应用可以向乘客终端发送相关信息,使得第三停靠点和/或路线图像可以显示在登上车辆840的乘客的乘客终端的显示器1720上。

应用可以与位于预定半径内的终端共享位置信息,并且在车辆840正在移动时搜索该位置信息的至少一个终端。当搜索到至少一个终端时,搜索到的终端被视为登上车辆840的乘客的终端,并且第三停靠点和/或路线图像被发送到搜索到的终端。

由于服务器810中继将提供运输服务的车辆840和乘客终端820,因此可以基于从车辆840和乘客终端820接收到的信息来确定乘客终端820是否位于车辆840内。当乘客终端820位于车辆840内时,可以将相关信息发送到乘客终端820,使得路线图像和/或第三停靠点可以显示在乘客终端820上。

如上所述,车辆840不仅可以通过停在乘客所期望的位置来帮助乘客从车辆下车或登上车辆,而且可以将该位置作为新停靠点添加。通过添加新停靠点,乘客可以持续使用他在其处下车或登乘的地点。

图11a至图11c是例示了提供运输服务的运输系统的示例的概念图。将参照图11a至11c更详细地描述使用请求用于朝向预定目的地移动的运输服务的乘客终端820、向乘客终端820提供运输服务的车辆840以及中继乘客终端820和车辆840的服务器810来提供运输服务的实施方式。

如图11a中所示,当感测到超过基准速度(例如,20km/h)的移动时,乘客终端820可以向服务器810和/或车辆840发送登乘确认请求。换句话讲,使用如gps这样的位置信息计算乘客终端820的移动速度,并且当速度超过基准速度时,检查用户是否登上车辆840。

响应于登乘确认请求,服务器810和/或车辆840将车辆840的移动路径与乘客终端820的移动路径进行比较,确定乘客终端820的用户是否无误地登上车辆840。当乘客终端820的用户并未登上车辆840时,乘客终端840输出告知登乘了错误运输工具的通知消息。可以通过视觉、听觉和触觉方式中的至少一种来输出通知消息。

此外,乘客终端820可以向乘客终端820的显示器显示紧急下车图标,使得乘客登上的车辆可以停车。当向紧急下车图标施加触摸时,乘客终端820向乘客登上的车辆发送停车请求,并且车辆可以响应于停车请求而停在预定地点。乘客终端820可以将从预定地点到预定目的地的替换路径随地图图像一起输出。

另外,当乘客终端820无误地登上车辆840时,乘客终端820可以将告知车辆840的操作路径的路径图像显示于乘客终端820的显示器。

车辆840通过设置在车辆840中的相机接收图像,并且使用该图像来确定乘客是否坐在座位上。当通过预约预留了座位时,确定乘客是否坐在预留座位上。车辆840保持停车状态直到乘客坐在座位上,并且在就座完成时开始自主驾驶。

车辆840可以将告知自主驾驶时的指南的注意图像输出到车辆840的显示器。另外,车辆840可以将欢迎乘客登乘的欢迎图像输出到车辆840的显示器。欢迎图像可以包括从服务器810接收的作为乘客的个人信息的名字和简档照片中的至少一个。一旦完成了注意图像和/或欢迎图像的再现,就开始自主驾驶,并且车辆840可以在进行再现时保持停车状态。

当在乘客登乘的状态下开始自主驾驶时,车辆840响应于乘客的下车请求而搜索下车地点。车辆840可以以各种方式接收下车请求的输入。例如,如图11b中所示,可以通过车辆840的麦克风输入诸如“letmegetoffinfrontofthetrafficlampoverthere(让我在那里的交通灯前面下车)”这样的语音命令。

车辆840可以响应于下车请求而将基于车辆840所处位置的预定区域分类成允许停车区域和不允许停车区域。否则,车辆840可以通过服务器810接收关于允许停车区域的信息,或者从存储在车辆840的存储器中的地图数据中搜索允许停车区域。在这种情形下,允许停车区域和不允许停车区域可以根据车辆840的类型和乘客的特性而变化。

车辆840搜索停车区域中的候选地点。当车辆840的常规停靠点中包括的任一个停靠点和搜索到的候选地点在基准距离内时,将该任一个停靠点而非搜索到的候选地点设置为下车地点。在另一种情况下,将候选地点设置为下车地点。

当设定了下车地点时,可以在车辆840的显示器上显示告知下车的下车通知消息。下车通知消息也可以显示在乘客终端820的显示器上。

当在预定区域内不包括停靠点并且不存在允许停车区域时,可以引导车辆840的常规路线中包括的停靠点当中的位置距离车辆840最近的停靠点。另外,车辆840和/或乘客终端820可以提供告知允许停车区域或不允许停车区域的地图图像。

可以控制车辆840停在常规路线中包括的停靠点当中的乘客的停车或登乘被预约的停靠点达预定时间,并经过乘客的停车或登乘未被预约的停靠点。这旨在防止因车辆停在乘客的停车或登乘未被预约的停靠点而会出现的燃料损耗。

此外,车辆840可以包括路线图像,路线图像指示地图图像上的车辆840的常规路线中包括的停靠点。可以突出显示被安排停在其处的停靠点或被安排经过其处的停靠点,使得可以在路线图像上将被安排停在其处的停靠点和被安排经过其处的停靠点彼此区分开。

当在路线图像上选择了任一个停靠点时,生成关于所选择停靠点的下车请求。当选择了并非停靠点的任何地点时,如图11c中所示,车辆840基于所选择的地点搜索下车地点,并且可以将搜索到的地点作为第三停靠点添加。当地图图像和/或路线图像也显示在乘客终端820上时,基于所施加的触摸选择下车地点,并且可以将所选择的下车地点作为第三停靠点添加到车辆840的常规路线。

在提供运输服务时,服务器810和/或乘客终端840提供各种用户界面,使得乘客可以在期望的地点下车。车辆840并未响应于下车请求而停在任意地点,而是在考虑到乘客安全的情况下停在不发生法律问题的地点,也就是说,该地点被设置为允许停车的区域中的下车地点。下车地点根据车辆840和/或乘客而变化,使得可以提高用户便利度。

图12是例示了下车地点处的车辆的操作的流程图。如图12中所示,当任何乘客生成下车请求时,车辆840的车辆应用842响应于下车请求而保持停在停靠地点处(s1910)。在这种情形下,车辆应用842控制车辆840停车,直到有任何乘客从车辆840下车。

车辆840可以使用设置在车辆840中的各种传感器来确定是否有任何乘客从车辆840下车。例如,车辆840可以分析从设置在车辆840中的相机接收的图像,并确定是否有任何乘客下车。又例如,可以使用设置在车辆840的座椅中的重量传感器来确定是否有任何乘客从车辆840下车。

另外,车辆840可以通过与乘客终端820共享位置信息来确定是否有任何乘客从车辆840下车。可以基于从任何乘客的乘客终端接收的位置信息来确定是否有任何乘客从车辆840下车。具体地,当基于车辆840的位置设置预定区域并且乘客终端820的位置离开该预定区域时,可以确定有乘客从车辆840下车。

在确认有乘客从车辆840下车之后,控制车辆840移动到下一个停靠点。当在过去一定时间之前未确认有任何乘客在下车地点下车时,车辆应用842可以向服务器810发送下车确认请求。服务器810可以响应于下车确认请求而向乘客终端820进行电话呼叫或者发送请求下车的消息。尽管如此,当未确认有乘客下车时,车辆应用842可以控制车辆840移动到最近的警察局或消防站,将其视为紧急情况。

另外,车辆应用842可以基于从设置在车辆840中的至少一个处理器接收的信息来确定车辆840是否处于自主驾驶的状态。例如,当燃料不足以移动到下一个停靠点时或者至少一个传感器出现故障时,可以确定自主驾驶处于不可用状态。

当自主驾驶不可用时,车辆应用842控制车辆840停在允许停在其处达预定时间的一个地点。并且,车辆应用842将可以是可替换的转乘信息发送到登上车辆840的乘客的乘客终端,并且可以输出接收到的转乘信息。转乘信息可以包括替换运输工具和用于从车辆840将停在其处的停靠地点移动到每个乘客的目的地的替换路径。服务器810可以使另一自主驾驶车辆移动到停靠地点,以便乘客转乘。

图13是例示了更新预设常规路线的服务器的操作的流程图。在提供运输服务时,累积并存储登乘历史和/或下车历史。换句话讲,服务器810可以基于从乘客终端820和/或车辆840发送的信息来存储登乘历史和/或下车历史(s2010)。

接下来,服务器810可以基于所存储的历史来更新车辆840的常规路线(s2030)。例如,当使用特定停靠点的乘客的人数在预定时间段内小于基准时,服务器810可以从常规路线中删除特定停靠点。又例如,当使用特定停靠点的乘客的人数在预定时间段内大于基准时,可以向常规路线指派新车辆,使得该新车辆可以沿着常规路线执行自主驾驶。

可以通过大数据管理历史,并且可以通过历史统计数据计算乘客的使用率。服务器810可以基于使用率来将新的停靠点添加到常规路线,改变常规路线的路径,或者删除包括在常规路线中的现有停靠点。因此,可以提供高效率的运输服务。

可以使用上面存储有指令以供处理器执行这些程序来执行本文中提出的各种方法的机器可读介质来实现各种实施方式。可能的机器可读介质的示例包括hdd(硬盘驱动器)、ssd(固态盘)、sdd(硅盘驱动器)、rom、ram、cd-rom、磁带、软盘、光学数据存储装置、本文中提出的其它类型的存储介质及其组合。如果需要,机器可读介质可以按照载波(例如,互联网上的传输)的形式来实现。处理器可以包括移动终端的控制器。因此,其具体实施方式不应该被理解为在任何方面是限制性的,而是被视为是例示性的。应当通过对所附权利要求的合理解释来确定本发明的范围,并且落入本发明的等同范围内的所有改变都被包括在本发明的范围内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1