与乘客通信的车载系统的制作方法

本发明涉及用于实施与机动车辆的乘客的改进通信的方法和系统。

大多数机动车辆通过物理控制件的使用来与乘客交互。例如，车辆经由物理控制件(例如，踏板和方向盘)驾驶。车辆的各个系统经由物理控制件(例如，气候控制件、音频/视觉系统、窗口、天窗、门锁、座椅位置等等)来控制。

随着技术的改进，越来越期望包括附加的装置来以简单且直观的方式与乘客交互。

技术实现要素：

在一个示例性实施例中，处理车辆中命令的方法包括接收来自用户的通信。该方法进一步包括确定该通信与车辆的健康相关联。该方法进一步包括基于该通信监控车辆。在确定应执行故障消除的情形下，该方法进一步包括设置针对车辆的维护服务。所接收的通信呈选自语音通信或姿势基通信的形式。

除了这里描述的一个或多个特征以外，又一些实施例可包括其中，监控车辆包括收集关于车辆的行为的数据。监控车辆进一步包括收集关于车辆的历史数据。监控车辆进一步包括向用户提示附加的信息。

除了这里描述的一个或多个特征以外，又一些实施例可包括其中，收集历史数据包括收集来自类似车辆的历史数据。

除了这里描述的一个或多个特征以外，又一些实施例可包括其中，设置针对车辆的维护服务包括对车辆进行编程以行驶至维护供应商。

除了这里描述的一个或多个特征以外，又一些实施例可包括使用选自语音输出和视觉输出的方法来与用户通信。

除了这里描述的一个或多个特征以外，又一些实施例可包括其中，确定通信与车辆的健康相关联包括接收来自用户的语音通信。该方法可进一步包括将语音通信转换成机器可读格式。该方法可进一步包括使用机器学习算法来解释语音通信，以确定语音通信是否与车辆的健康相关联。

除了这里描述的一个或多个特征以外，又一些实施例可包括其中，语音通信利用自然语言命令。

在一个示例性实施例中，处理车辆中命令的方法包括接收来自用户的通信。该方法可进一步包括确定该通信与用户的健康相关联。该方法可进一步包括使用通信和/或基于该通信使用位于车辆中的至少一个传感器来监控用户的健康。在确定应将用户运送至紧急医疗设施的情形下，该方法可进一步包括对车辆进行编程以驾驶至紧急医疗设施。通信呈选自语音通信或姿势基通信的形式。

除了这里描述的一个或多个特征以外，又一些实施例可包括其中，监控用户的健康包括确定用户的标识符；收集关于用户的简档数据。监控用户的健康可进一步包括使用机器学习算法来基于用户的通信、简档数据以及传感器数据而向用户询问一系列问题。这些问题经由语音命令来询问。以选自语音通信或姿势基通信的形式来接收对问题的响应。

除了这里描述的一个或多个特征以外，又一些实施例可包括确定是否应将用户运送至紧急医疗设施。基于确定应将用户运送至紧急医疗设施，又一些实施例可包括对车辆进行编程以驾驶至紧急医疗设施。

除了这里描述的一个或多个特征以外，又一些实施例可包括基于确定通信是无意识姿势，确定无意识姿势是对医疗状况的指示。

除了这里描述的一个或多个特征以外，又一些实施例可包括使用选自语音输出和视觉输出的方法来与用户通信。

除了这里描述的一个或多个特征以外，又一些实施例可包括其中，语音通信利用自然语言命令。

在一个示例性实施例中，处理车辆中命令的方法包括：接收来自用户的通信。该方法可进一步包括确定该通信与车辆的驾驶模式相关联。该方法可进一步包括基于该通信来设定驾驶模式。该通信呈选自语音通信或姿势基通信的形式。

除了这里描述的一个或多个特征以外，又一些实施例可包括其中，设定驾驶模式包括确定用户的标识符。设定驾驶模式可进一步包括收集关于用户的简档数据。设定驾驶模式可进一步包括基于该简档数据设定驾驶模式。

除了这里描述的一个或多个特征以外，又一些实施例可包括确定天气状况；以及使用天气状况来设定驾驶模式。

除了这里描述的一个或多个特征以外，又一些实施例可包括其中，语音通信利用自然语言命令。

当结合附图时，从以下详细描述中，上述特征和优点以及其它特征和优点显而易见。

附图说明

仅仅借助示例，其它特征、优点以及细节出现在实施例的以下详细描述中，该详细描述参照附图，附图中：

图1是说明能够执行一个或多个实施例的系统的框图；

图2是说明一个或多个实施例的操作的流程图；

图3是说明一个或多个实施例的操作的流程图；

图4是说明一个或多个实施例的操作的流程图；以及

图5是说明一个或多个实施例的操作的流程图。

具体实施方式

以下描述在本质上仅仅是示例性的，且并不旨在限制本发明、其应用或使用。

根据示例性实施例，示出允许车辆能与乘客通信的车载系统的一个或多个实施例。

随着机动车辆变得更为自主，较少需要从人到车辆的物理输入。说明自主驾驶水平的常用标度包括编号为0至5的级别。级别0并不具有驾驶自动化。级别1具有对驾驶员的辅助。级别2具有部分驾驶自动化。级别3具有有条件驾驶自动化。级别4具有高水平的驾驶自动化。以及级别5具有完全驾驶自动化。通常，级别数越高，从人需要越少的输入。

传统的机动车辆利用物理输入来引导机动车辆的操作。这些物理输入包括用于驾驶汽车的输入，例如方向盘和踏板。这些输入还包括车辆的其它系统，例如气候控制件、音频/视觉系统、窗口位置、座椅位置、镜子位置、转弯信号、变速器控制件等等。由于机动车辆在人的控制下，因而还利用物理人为输入来控制汽车的各个系统已变为标准。这可包括用于操作系统的拨号盘、控制杆、旋钮、按钮等等。

随着计算机能力增大，日益期望使用语音命令来控制装置。机动车辆的开发已增大车辆的计算能力并且改变人和车辆之间的关系，以使得语音控制越来越有用。

参照图1，示出说明一个或多个实施例的示例性语音控制系统100的框图。乘客110能够使用语音输入来控制机动车辆的各个系统，且语音控制系统100布置在该机动车辆中。语音控制系统100包括一个或多个语音输入112。语音输入112可包括各种不同输入的一个，包括位于机动车辆的各个部分处的音频麦克风。麦克风产生表示所接收音频的电信号。在电信号转换成数字格式来易于存储和处理之后，这些电信号可以呈数字信号的形式。还可以是例如来自照相机、3d传感器或其它视频传感器的视频输入114，该照相机、3d传感器或其它视频传感器可提供关于视频输入的类似能力。

通信模块120接收电信号并且对这些信号执行各种不同算法的一个。这可包括音频压缩、均衡、声音过滤、噪声控制等等。机动车辆中尤为关注的可以是噪声。相较存在于典型的家庭或录音棚环境，道路噪声和风噪声以更大的程度存在于一些机动车辆中。此外，多个乘客可导致需要将一个语音与其它语音相隔离。对视频信号可进行类似的处理。

通信模块120还执行话语和姿势识别功能。话语识别允许系统能将音频转化成文字，这些文字能以各种不同的方式使用。话语识别的一部分可包括语音简档，该语音简档包含能识别发言者的语音特征。这样，某些车辆的典型乘客可具有一个语音简档，而乘客的女儿具有不同的简档。简档可允许通信模块120能基于每个用户的特征来更可靠地识别每个用户的话语。此外，通信模块120可包括机器学习部件，该机器学习部件允许通信模块120能“学习”并且适应每个用户的说话方式。识别和理解处理器120还可包括关于视频信号的类似能力。例如，姿势可由用户使用并且对于每个用户可能略微不同。因此，识别和理解处理器120的机器学习能力可用于更容易地区分每个用户以及他们的姿势。

通信模块120内还包括与子系统的控制模块130的各个接口，这些子系统可执行用户所请求的功能。这些控制模块130是执行各种不同功能的一个的嵌入式计算机系统，这些功能例如是发动机控制、自主驾驶控制、车辆配置、导航、诊断、远程信息处理、车辆子系统150的控制、反馈模块160的控制等等。车辆子系统150可以是各种不同形式的一种，例如致动器、用于机械系统(例如，节气门、制动器、方向盘、窗口、座椅、天窗、车门、锁等等)的电动机。控制模块130还可包括通信接口，这些通信接口允许系统100能访问诸如因特网的外部计算机系统，或者一个或多个云服务器140以及位于整个机动车辆上的内部计算机系统和存储器。

可通过使用联接于天线的收发器经由包括在控制模块130中的远程信息处理模块来实现与因特网和其他外部计算系统的连接，其中，收发器经由wi-fi或经由全球卫星定位系统(例如，gps或glonass)而使用诸如蜂窝数据协议(例如，4g、lte、utms、wimax等等)的各种不同协议的一种发送和接收信号。

反馈模块160包括允许系统100与用户通信的一个或多个系统。这可包括“信息娱乐系统”、诸如扬声器的音频转换器、诸如显示器屏幕的视觉输出、指示器灯、拨号盘、仪表等等。使用反馈模块160，系统100可向用户指示状态，向用户提供更新和确认。

使用包括系统100的一个或多个实施例，用户通过语音命令的使用可发出各种不同的任务。这些命令可包括容易执行的控制机动车辆的各部件的任务，例如“打开驾驶员一侧的窗户”，“播放莫扎特第5小提琴协奏曲”，“调低汽车的温度”，“打开内部灯”等等。一旦理解语音命令，就容易地执行命令的实施。

这些命令可包括姿势。例如，打开窗户可通过用户的打开手掌的下降运动所指示。在一些实施例中，用于每个命令的姿势可由用户定制。任务可包括一般计算任务，例如访问因特网或者执行通信任务。示例性命令可包括“我的日程安排是什么”，“向sally发送消息”，“谁赢得了1971年的世界大赛”以及可由智能辅助执行的各种其他任务。反馈可使用作为反馈模块160的部件的扬声器和显示器来提供。

在图2中示出说明方法200的流程图。方法200仅仅是示例性的并且并不限于这里示出的实施例。方法200可用在这里并未确切示出或描述的许多不同实施例中。在一些实施例中，方法200的程序、过程和/或活动能以所示出的顺序执行。在其他实施例中，可组合或跳过方法200的程序、过程和/或活动的一个或多个。在一个或多个实施例中，在处理器正执行指令时由该处理器执行方法200。

接收用户的通信(框202)。通信可经由姿势或经由语音进行。分析通信以确定通信是否与车辆健康相关联(框204)。如果否的话，则方法200等待直到接收另一通信为止。

一旦解析并识别通信(框206)，就可发生各种动作。可收集数据，以监控机动车辆的行为(框208)。数据可来自位于整个机动车辆上的各种不同来源。这些来源可包括配置成收集车辆部件行为的数据的传感器。此种数据可例如本地地或者经由云服务器来存储。历史数据可例如本地地或者经由云服务器来检索(框210)。在一些实施例中，历史数据可限制于特定的机动车辆。在一些实施例中，例如出于比较的目的，历史数据可包括其他车辆，以确定子系统是否按期望地执行。可从乘客收集附加的信息(框212)。该信息可以呈使用机器学习算法产生的一系列问题的形式。例如，如果用户已报告来自某个位置的声音或振动，则可询问用户在哪种状况下发出声音或者声音的确切位置。

机动车辆的车辆健康管理(vhm)基于各种标准来判定做法(框214)。框208、210和212处收集的信息可用于确定问题的存在、原因和/或严重程度。如果存在问题(框216)，则可判定做法(框218)。不管是否存在问题，该系统均可向用户作出答复(框220)。答复可呈音频和/或视频的形式。例如，描述问题(或问题的缺乏)的语音指示可通过信息娱乐系统或者经由机动车辆中的一个或多个扬声器来播送。视觉呈现可经由机动车辆中的显示器来作出。视频或音频呈现可描述问题、所建议的做法以及对于输入的请求。在一些情形中，问题可能能够通过用户的动作来固定。在一些情形中，可能建议要访问维修设施。可向用户传递最近维修设施的位置以及可用的预约时间(经由因特网连接检索)。乘客可确实或确认该报告(框222)。

更先进的交互也是可能的。作为示例，用户可通知机动车辆中之前并未发生的噪声或振动。用户可以说“我听到来自车辆的右后侧的噪声”，系统会在噪声事件期间注意到该陈述并且可收集到更多数据。系统可存储该陈述，以使得能追踪各种事件。如果可能的话，系统可作出校正。系统可接触维修设施以安排检查。在具有先进自主能力的机动车辆中，机动车辆取决于机动车辆的使用日程而可甚至驾驶至维修设施。

在一个或多个实施例中，驾驶控制也可经由语音或姿势命令来控制。在图3中示出说明方法300的流程图。方法300仅仅是示例性的并且并不限于这里示出的实施例。方法300可用在这里并未确切示出或描述的许多不同实施例中。在一些实施例中，方法300的程序、过程和/或活动能以所示出的顺序执行。在其他实施例中，可组合或跳过方法300的程序、过程和/或活动的一个或多个。在一个或多个实施例中，在处理器正执行指令时由该处理器执行方法300。

例如，用户可设定目的地(框302)。机动车辆可使用卫星导航来确定车辆的当前位置，并且使用地图、实时交通数据，用户偏好(例如，避免收费站、避免高速公路等)等等来确定向目的地的路线(框306)。一旦确定路线，就可取决于车辆的自动化水平来进行各种动作。在使用高水平自动化的车辆中，车辆可在最少的用户输入下开始驾驶至目的地(框308)。对于低水平的自动化(包括完全没有自动化)，可经由扬声器和/或视频显示器来向用户播送向目的地的方向(框310)。

在一个或多个实施例中，车辆可具有多个驾驶模式。这些模式可使用语音或姿势命令来切换。在图4中示出说明方法400的流程图。方法400仅仅是示例性的并且并不限于这里示出的实施例。方法400可用在这里并未确切示出或描述的许多不同实施例中。在一些实施例中，方法400的程序、过程和/或活动能以所示出的顺序执行。在其他实施例中，可组合或跳过方法400的程序、过程和/或活动的一个或多个。在一个或多个实施例中，在处理器正执行指令时由该处理器执行方法400。

在从用户接收通信的情形下(框402)，确定乘客是否请求驾驶模式的切换(框404)。车辆可具有多个驾驶模式。例如，车辆可具有运动模式，具有较稳固的悬架并且在发动机的性能上具有较少限制。车辆可具有经济模式，该模式对性能包含更多限制(例如，避免高的发动机rpm或者快速加速)。可存在附加的模式，例如限制车辆的峰顶速度的城市模式。将通信识别为模式改变请求(框406)。

应理解的是，这些请求无需以特定的形式语言来作出。机器学习可用于将“自然语言”转化成模式改变命令。例如，对于“放轻松”或者使得驾驶“更放松”的请求可解释成从运动模式中改变出来的请求。

模式可取决于驾驶状况。例如，机动车辆中的传感器可确定室外温度。传感器还可确定呈雨水或雪的形式的湿气的存在。沿着传动系的传感器可确定是否可能由于冰而发生打滑。基于驾驶状况，可能使得一些模式对于用户有用或者不可用。例如，运动模式可能在某些温度(由于冰的危险)下或者在雪或雨水的存在下不被允许。

模式可能专用于某些用户。例如，一个用户可能并不期望具有运动模式，而另一用户可能并不期望使用城市模式。用户的各种偏好可本地地或者经由云连接来存储。因此，框406的一部分可确定存在哪个用户并且作出通信。一旦确定作出请求的用户，就可检索用户的简档(框408)。此种检索可来自本地存储器或者来自云存储器。如上所述，机动车辆可能具有多个用户。汽车的每个用户均可具有简档。基于机器学习算法，对于“更多活力”的请求可针对一个用户解释为进入运动模式的请求，但也可针对另一用户解释为进入运动模式以外模式的请求。

用户的简档可用于基于用户的健康状况来定制驾驶模式。易患晕动病的用户可能相比偏好运动模式的另一用户具有更为放松的默认驾驶模式。当前患病的用户(例如，参见图5和附带的文本)还可具有更放松的驾驶模式。

基于上述信息，确定期望的配置(框410)。之后，改变机动车辆的配置(框412)。此种配置改变能以现在已知的各种方法或者未来开发的那些方法的一种发生。如上所述，配置改变可包括改变机动车辆的悬架特征、改变机动车辆的发动机以及机动车辆的其它子系统。

该系统可向用户作出状态报告(框414)。答复可呈音频和/或视频的形式。例如，描述新模式的语音指示可通过信息娱乐系统或者经由机动车辆中的一个或多个扬声器来播送。视觉呈现可经由机动车辆中的显示器来作出。乘客可确实或确认报告并且指示他是否对模式改变感到满意(框416)。如果否的话，则系统可返回至框410。否则，系统可等待框402中的附加输入。

在一个或多个实施例中，能针对用户的生理健康。在图5中示出说明方法500的流程图。方法500仅仅是示例性的并且并不限于这里示出的实施例。方法500可用在这里并未确切示出或描述的许多不同实施例中。在一些实施例中，方法500的程序、过程和/或活动能以所示出的顺序执行。在其他实施例中，可组合或跳过方法500的程序、过程和/或活动的一个或多个。在一个或多个实施例中，在处理器正执行指令时由该处理器执行方法500。

在接收用户的通信的情形下(框502)，能检查通信，以确定通信是否关于健康问题(框504)。如果否的话，则操作可在框502处重新开始，其中，系统等待来自用户的附加通信。如上所述，用户的通信可呈音频命令或身体姿势的形式。可使用各种不同语音识别算法的一个来处理音频命令，以将话语转化成命令(框506)。如上所述，音频命令可以是自然语言或会话语言。也就是说，代替用户使用特定命令(例如，“发起健康协议”)，用户以与向他人说话的相同方式说话。语言识别协议解析自然语言，并且确定用户针对每个语音命令意指的内容。

框506的一部分包括确定哪个用户作出请求。一旦已确定用户，就可检索用户的简档(框508)。这可来自本地存储器或者来自云存储器而发生。用户的简档可包括关于用户的各种信息，包括健康问题和慢性病症。在一些实施例中，系统可联接于一个或多个传感器。这些传感器可包括跟踪用户的生命体征的可佩戴传感器，例如血压、脉冲、体温等等。

如果用户的通信是请求前往医院(框510)，则经由机动车辆的音频和/或视频系统来发出确认(框520)。之后，计算向最近的合适医疗设施的路线(框522)。在自动化车辆的情形中，发起路线。

如果用户的通信并不请求前往医院，则可基于用户的通信向用户询问一系列问题(框530)。这些问题基于一个或多个机器学习算法以及用户的通信而产生。例如，如果用户感到晕眩，可向用户询问关于他最后吃了什么、他已晕眩多长时间或者他可能经历的其他症状的一系列问题。传感器可用于监控用户的健康。如上所述，传感器可包括由用户使用的可佩戴传感器，并且还可包括位于整个机动车辆上的传感器。使用对问卷和传感器的响应，能确定诊断(框532)。基于诊断的严重程度，可确定用户是否需要进行至紧急医疗设施(框534)。如果是的话，操作可进行至框520。否则，经由机动车辆的音频和/或视频系统来作出通知(框536)。然后，可再次询问用户他是否希望进行至紧急医疗设施(框538)。如果是的话，操作可在框520处重新开始。否则，操作可在框502处重新开始。

在一些实施例中，可存在对用户的持续监控。例如，如果用户已指示了某组症状，则可监控合适的传感器，以确定用户的条件是否恶化。可监控诸如照相机和三维传感器的视频传感器，以确定用户是否需要辅助。例如，经历突然运动的用户可能有癫痫发作。用户的简档可指示用户是否易受到癫痫影响，这会允许系统能更密切地监控这些类型的运动。

虽然上文公开已参照示例性实施例进行了描述，但本领域技术人员会理解的是，可作出各种改变且等同物可替代本发明的元件，而不会偏离本发明的范围。此外，可作出许多修改，以使得特定情况或材料适应于本发明的教示，而不会偏离本发明的基本范围。因此，本发明并不旨在限制于所公开的特定实施例，而是会包括落在本发明范围内的所有实施例。