本申请涉及通信技术领域,尤其涉及一种车辆控制方法、装置、终端设备和介质。
背景技术:
随着通信技术的发展,用户通常可以通过用户终端对车辆中的设施进行远程控制,以在用户上车前可以提前对车辆中的空调等设施进行设置。车辆中的设施如,空调、音响、灯以及收音机等。
例如,在冬天的傍晚,用户可以在上车前,远程将空调设置为26度,并且打开收音机的音乐频道,以及打开车内灯和外置车灯。
但是,这种方式主要依赖于手动控制,在炎热的夏天或寒冷的冬天,用户若在上车前没有提前将车辆内温度调节至舒适的温度,用户可能会感到极度不适,智能化程度较低,操作步骤繁琐,这降低了用户体验。
技术实现要素:
本申请实施例提供一种车辆控制方法、装置、终端设备和介质,用以根据用户驾车出行前的行为特征,预先对车辆的各设施进行自动控制,减少了对人工控制的依赖,简化了复杂的用户操作,提高了用户体验。
一方面,提供一种车辆控制方法,包括:
根据获取的当前的车辆位置信息,确定车辆位置信息所属的常用车辆区域,常用车辆区域根据统计的用户每次停车的历史车辆位置信息确定;
根据车辆区域与出行模型之间的关联关系,获得常用车辆区域对应的出行模型,其中,出行模型基于用户出行数据训练获得;
根据接收的用户出行数据以及出行模型,确定用户的出行概率;
若出行概率大于预设值,则向车载系统发送车辆控制指令。
一方面,提供一种车辆控制装置,包括:
第一确定单元,用于根据获取的当前的车辆位置信息,确定车辆位置信息所属的常用车辆区域,常用车辆区域根据统计的用户每次停车的历史车辆位置信息确定;
获得单元,用于根据车辆区域与出行模型之间的关联关系,获得常用车辆区域对应的出行模型,其中,出行模型基于用户出行数据训练获得;
二确定单元,用于根据接收的用户出行数据以及出行模型,确定用户的出行概率;
发送单元,用于若出行概率大于预设值,则向车载系统发送车辆控制指令。
一方面,提供一种终端设备,包括至少一个处理单元、以及至少一个存储单元,其中,存储单元存储有计算机程序,当程序被处理单元执行时,使得处理单元执行上述任一种车辆控制方法的步骤。
一方面,提供一种计算机可读介质,其存储有可由终端设备执行的计算机程序,当程序在终端设备上运行时,使得终端设备执行上述任一种车辆控制方法的步骤。
本申请实施例提供的一种车辆控制方法、装置、终端设备和介质中,根据获取的当前的车辆位置信息,确定车辆位置信息所属的常用车辆区域,常用车辆区域根据统计的用户每次停车的历史车辆位置信息确定;根据车辆区域与出行模型之间的关联关系,获得常用车辆区域对应的出行模型,其中,出行模型基于用户出行数据训练获得;根据接收的用户出行数据以及出行模型,确定用户的出行概率;若出行概率大于预设值,则向车载系统发送车辆控制指令。这样,根据用户每次驾车出行前的习惯,确定用户当前即将驾车出行时,通过车辆中的车载系统控制车辆内各设施的运行状态,以在用户驾车出行前自动按照用户的喜好等预先控制车辆中的空调等设施,减少了对人工控制的依赖,提高了智能化程度,为用户提供了良好的用户体验。
本申请的其它特征和优点将在随后的说明书中阐述,并且,部分地从说明书中变得显而易见,或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1为本申请实施方式中一种车辆控制系统的架构示意图;
图2为本申请提供的一种车辆控制方法的实施流程图;
图3为本申请提供的一种车辆区域的划分方法的实施流程图;
图4为本申请提供的一种平面划分示意图;
图5为本申请提供的一种出行时间的预估方法的实施流程图;
图6为本申请实施方式中一种车辆控制装置的结构示意图。
具体实施方式
为了在用户驾车出行前,根据用户驾车出行前的行为特征,预先对车辆的各设施进行自动控制,减少对人工控制的依赖,简化复杂的用户操作,提高用户体验,本申请实施例提供了一种车辆控制方法、装置、终端设备和介质。
参阅图1所示,为一种车辆控制系统的架构示意图。车辆架构系统包括用户终端,服务器和车载系统。
用户终端:设置有应用程序,用于:采集用户的运动数据,并将用户的运动数据上传至服务器;接收并向用户呈现服务器推送的服务器消息;向服务器发送控制命令。
例如,当服务器预测用户即将驾车出行时,打开预先配置的车载装置(如,空调和收音机),并向用户终端发送车辆中车载装置当前的状态信息,以提示用户车辆内的相关设施已经启动。当用户想要对车辆内的设施进行控制时,也可以通过用户终端向服务器发送控制命令,以通过服务器控制车载系统。
车载系统:应用于车辆内,采集车辆的车辆位置信息,车辆及各车载装置的状态信息;将采集的数据上传至服务器;接收服务器发送的车辆控制指令等。
车辆的状态信息包括:车辆是否启动,车载装置的运行状态,如空调温度,座椅角度等。
服务器,提供后台服务,包括:记录用户以及用户对车辆预设的控制信息;记录车载系统和用户终端采集的数据,以及根据采集的数据对出行模型进行训练,进而根据出行模型预测用户的驾车行为;根据预测结果以及用户的控制信息,对车辆进行控制。这样,服务器可以基于数据库中记录的数据,分别执行数据通信,学习、预测以及远程控制的任务。包括:通信模块,数据库,学习模块以及控制模块。服务器通过通信模块与车载系统和用户终端进行信息传输,将用户终端和车载系统上传的数据存储至数据库;学习模块根据数据库中的数据进行模型训练,获得出行模型。控制模块根据出行模型,确定用户即将驾车出行时,向车载系统发送控制指令。
参阅图2所示,为本申请提供的一种车辆控制方法的实施流程图。该方法的具体实施流程如下:
步骤200:服务器接收车载系统发送的包含车辆位置信息的车辆消息。
步骤201:服务器确定车辆位置信息所属的常用车辆区域。
具体的,服务器根据划分好的各车辆区域,以及用户当前的车辆位置信息,确定所属的常用车辆区域。
其中,车辆区域是根据统计的用户每次停车的历史车辆位置信息划分的,参阅图3所示,为一种车辆区域的划分方法的实施流程图,服务器划分各车辆区域的具体步骤如下:
步骤300:服务器获取用户每次停车的历史车辆位置信息。
具体的,服务器获取指定时间段(如,最近3个月)内用户每次停车的历史车辆位置信息(如,停车坐标)。
步骤301:服务器对各历史车辆位置信息进行聚类分析,获得各车辆区域。
具体的,服务器对各历史车辆位置信息进行聚类分析,获得各簇历史车辆位置信息,并分别确定每簇历史车辆位置信息的中心位置,以及分别根据每一中心位置以及指定半径,划分各车辆区域。
例如,各历史车辆位置信息依次包括a1,a2,a3,b1,b2和b3。服务器根据聚类分析结果,将a1,a2,a3划分为a类,并将b1,b2和b3划分为b类,并确定a类的中心位置为a4,b类的中心位置为b4。然后,服务器将以a4为圆心,100米为半径的圆形区域范围确定为a车辆区域,将以b4为圆心,100米为半径的圆形区域范围确定为b车辆区域。
这样,就可以根据各历史车辆位置信息,确定用户通常停车的各个车辆区域。
步骤302:服务器对各车辆区域进行筛选,获得筛选后的各车辆区域。
具体的,首先,服务器获取用户分别在每一常用车辆区域中的停车次数。
然后,服务器在各车辆区域中去除停车次数不高于预设次数门限的车辆区域,获得筛选后的各车辆区域。
例如,服务器对20天内的各历史车辆位置信息进行聚类分析,获得15个车辆区域,去除停车次数不高于10次的各车辆区域,剩下4个车辆区域。
又例如,服务器将最近10天内的各历史车辆位置信息作为样本,采用最短距离法对获取的各历史车辆位置信息进行聚类分析,获得各车辆区域,以及各车辆区域内的样本数量,若车辆区域的样本数量低于10个,则判定该车辆区域无效,否则,判定该车辆区域为有效区域。
又例如,服务器设置最小类间1千米,即若车辆位置之间的距离大于或等于1千米则认为属于不同类,接着,根据最小类间对20天内的各历史车辆位置信息进行聚类分析,获得15个车辆区域,筛选出包含的样本数量低于10个的车辆区域,获得4个车辆区域,a,b,c和d。
这样,就可以去除停车次数较少的车辆区域,获得用户停车概率较高的各车辆区域,以减少误差。
步骤202:服务器确定常用车辆区域对应的出行模型,并根据获取的用户出行数据和出行模型,确定用户在常用车辆区域出行的出行概率。
具体的,首先,服务器获取用户最近预设出行时长内的用户出行数据。
其中,用户出行数据至少包括用户的轨迹数据和对设施的操作数据。轨迹数据至少包括:用户位置信息和运动方向,可选的,用户位置信息可以为坐标,运动方向为用户在各指定平面的方向的组合,可选的,各指定平面可以为x,y和z三个坐标轴中每两个坐标轴形成的平面,即x-y平面,y-z平面以及z-x平面。运动方向可以通过用户终端内设置的加速度传感器和陀螺仪传感器进行采集。用户的位置信息可以通过用户终端内设置的定位装置获取的。
例如,轨迹数据为:用户从卧室到达停车场,操作数据为:用户关闭电脑,关闭电视,以及关闭灯光。
其中,用户出行数据是根据以下方式获得的:
用户根据车辆信息(如,标识信息)分别将各自的用户终端(如,智能手机)的指定应用(如,车辆控制应用程序)与车辆进行绑定后,将周期性采集的指定类型的用户出行数据通过上述指定应用发送至服务器。
然后,服务器根据用户轨迹集合和/或操作数据,以及常用车辆区域对应的出行模型,确定用户在常用车辆区域出行的出行概率。
其中,用户轨迹集合是根据以下方式获得的:
首先,服务器可以对获取的用户出行数据进行过滤,以获得过滤后的各用户出行数据。
例如,服务器去除加速度传感器采集的数据中的高频信号,以及去除陀螺仪传感器采集的数据中的低频信号,获得过滤后的用户出行数据。
然后,服务器分别确定过滤后的用户出行数据中每一运动方向所属的方向区域。
其中,方向区域是将每一指定平面进行划分后获得的。可选的,各方向区域可以为将每一指定平面按照指定角度进行均等划分后获得的区域的组合。每一个区域都可以采用相应的编码进行表示。
例如,图4为一种平面划分示意图,参阅图4所示,服务器将x-y平面,y-z平面以及z-x平面,分别按照45度均等划分,获得划分后的各方向区域,并将每一划分后的方向区域进行标号。其中,x-y平面中包含1-8方向区域,y-z平面包含3、7以及9-14方向区域,z-x平面包含1、5、10、13以及15-18方向区域。
这样,就可以将各运动方向按照方向区域(如,东西南北以及高度)进行归类,以便后续数据处理。其中,运动方向为用户的前一个坐标指向后一个坐标的方向。
最后,服务器分别将用户出行数据中每一位置信息与相应的运动方向所属的方向区域进行组合,并分别根据每一驾车出行前的历史用户出行数据对应的各组合,获得每一驾车出行前用户的用户轨迹集合。
这样,就可以将用户的历史用户出行数据,转换为用户轨迹集合,可选的,若方向区域用方向编码表示,运动方式用矢量编码表示,则获得的用户轨迹集合为轨迹的方向链码。
其中,出行模型是根据历史用户轨迹集合和/或历史操作数据训练获得的,可选的,出行模型可以根据获取的各历史用户轨迹集合和/或历史操作数据,迭代计算隐马克尔夫模型的最优参数,进而根据获得的最优参数确定出行模型。
本申请实施例中,仅以根据历史用户轨迹集合确定一类用户在一个车辆区域对应的出行模型为例进行说明,出行模型训练的具体步骤如下:
首先,服务器获取指定类型的各用户对应的车辆数据中包含的车辆位置信息和启动状态,并根据车辆位置信息和启动状态,筛选出一个用户在指定的车辆区域内,每一次启动车辆前预设出行时长内(如,10分钟)的历史用户出行数据。
其中,车辆数据至少包括:车辆位置信息,车辆以及各车载装置的运行状态信息,车辆的状态信息包括:车辆是否启动,车载装置的运行状态,如空调温度,座椅角度等。指定类型可以为学生,白领,家庭主妇或大学生等。
然后,服务器根据历史用户出行数据,获得各用户轨迹集合。
最后,服务器根据获取的各用户轨迹集合,迭代计算隐马克尔夫模型的最优参数,进而根据获得的最优参数确定出行模型。
本申请实施例中,仅以确定一个指定的常用车辆区域对应的出行模型为例进行说明,基于相同的原理,可以确定其它各常用车辆区域对应的出行模型,在此不再赘述。这样,服务器就可以在后续的步骤中,根据用户的行为,以及训练获得的出行模型,预测用户驾车出行的概率。
进一步地,服务器在获得训练后的出行模型后,可以在后续预估过程中,通过周期性采集的用户出行数据和/或操作数据对出行模型进行不断优化。
本申请实施例中,仅以确定一个指定的常用车辆区域对应的出行模型为例进行说明,基于相同的原理,可以确定其它各常用车辆区域对应的出行模型,在此不再赘述。
这样,服务器就可以在后续的步骤中,根据用户的行为,以及训练获得的出行模型,预测用户驾车出行的概率。
步骤203:服务器确定出行概率大于预设值时,向车载系统发送车辆控制指令。
具体的,执行步骤203时,可以采用以下两种方式中的任意一种:
第一种方式为:服务器确定出行概率大于预设值时,直接向车载系统发送车辆控制指令。
第二种方式为:服务器确定当前时间达到符合预设条件,并且出行概率大于预设值时,向车载系统发送车辆控制指令。其中,预设时间可以为根据实际需求设定的。
服务器根据用户预先配置的控制参数,向车载系统发送车辆控制指令。车辆中的车载系统接收到控制指令后,控制车辆内的各设施的运行状态。例如,车载系统根据接收的控制指令,开启空调,并将空调温度设置为26度,以及打开收音机,将收音机调制指定频道。
其中,预设条件可以为指定时间点或指定时间段,也可以为当前时间对应的出行时间概率大于预设时间门限。出行时间概率为用户在一段时间内驾车出行的概率,是根据用户在各车辆区域的历史启动时间确定的用户在各车辆区域中出行周期内每一时间区域内出行的概率。参阅图5所示,为本申请提供的一种出行时间的预估方法的实施流程图,每一车辆区域的出行周期内各时间区域与出行时间概率之间的关联关系是根据以下步骤确定的:
步骤500:服务器根据用户的各历史启动时间,统计获得用户的出行周期。
具体的,服务器根据用户每天在上述指定的车辆区域启动车辆的各历史启动时间,统计用户的出行周期。
其中,用户每天的启动时间按照出行周期循环变化,在一个出行周期内可以包含多种日期类型。用户在不同日期类型中的启动时间规律不同,实际应用中,出行周期也可以根据实际需求进行设定。
可选的,出行周期可以按照以下方式进行设置:
第一种方式为:出行周期为一周,一周内包含周一,周二……周日7种类型的日期类型。
第二种方式为:出行周期为一周,一周内包含日期按照工作日和周末进行2种类型的日期类型。
第三种方式为:出行周期为1年,1年内包含工作日和假期2种类型的日期类型。
步骤501:服务器根据用户每次驾车出行的历史启动时间,按照出行周期对各历史启动时间进行分组。
表1.
例如,参阅表1所示,为一种历史启动时间的分组示例表。常用车辆区域包括a地、b地、c地和d地。服务器根据用户的各历史启动时间,确定出行周期为一周,并且一周内包含周一,周二……周日7种类型的日期类型。服务器采集4周内每天的历史启动时间,并将各历史启动时间按照日期类型以及常用车辆区域进行划分,获得表1所示的各分组。
步骤502:服务器分别针对每一组历史启动时间,进行聚类分析,获得各时间区域。
具体的,首先,服务器分别针对每一组历史启动时间进行聚类分析,并根据聚类分析结果,获得每一组历史启动时间包含的各簇历史启动时间。
接着,服务器分别确定每一簇历史启动时间的中心时间,并分别根据每一中心时间,以及指定区域时长,获得每一中心时间对应的时间区域。
步骤503:服务器分别建立每一车辆区域的出行周期内各时间区域与出行时间概率之间的关联关系。
具体的,首先,服务器统计用户在出行周期内每一时间区域的启动次数,并确定各时间区域的启动次数的最大值。
接着,服务器分别根据用户在每一时间区域的启动次数,与上述最大值的比值,确定用户分别在每一时间区域的出行时间概率。出行时间概率与上述最大值呈负相关,与时间区域内的启动次数呈正相关。
可选的,服务器筛选出出行时间概率高于预设启动门限的各时间区域。
然后,服务器分别建立每一车辆区域的出行周期内各时间区域与出行时间概率之间的关联关系。其中,时间区域包含的时间长度可以根据实际需求进行设定,可选的,可以为1小时。
表2.
例如,参阅表2所示,为时间区域的驾车出行时间概率示例表。a地从周一至周五的各时间区域的中心时间依次为8:01,8:02,8:03,8:00,以及8:03。周六和周日对应的各时间区域由于出行时间概率较小,均被去除。b地从周一至周五的各时间区域的中心时间依次为17:32,17:32,17:33,17:33以及17:34。每一时间区域为中心时间的前后30分钟。
可选的,预设时间为各时间区域的中心时间,或者,预设时间为筛选出的各时间区域内的任意时间点,预设值为数值,例如0.8。例如,筛选出的时间区域为8点-9点,则预设时间可以设置为8点。
这样,就可以根据用户出行前的行走轨迹习惯,操作习惯以及惯常出行时间,判断用户是否即将驾车出行,进而确定用户即将驾车出行时,控制车辆内的各设施的运行状态,以提高用户体验。
例如,当前车辆停放在a地,服务器获取车辆在a地的车辆位置信息,并根据车辆位置信息,获取用户a的出行模型;然后,服务器获取最近10分钟内的用户出行数据和操作数据,并对用户出行数据和操作数据进行预处理,获得用户轨迹集合和操作数据,接着,根据用户轨迹集合和操作数据,采用出行模型确定出行概率为0.9;最后,确定出行概率0.9大于0.8,则判定用户即将出行,根据用户预先配置的控制参数,向车载系统发送用于打开车灯的车辆控制指令。
进一步地,服务器接收车载系统周期性上报的状态响应消息,并向用户的用户终端转发所述状态响应消息。其中,状态响应消息包括车辆内各车载装置的运行状态。这样,服务器就可以根据用户的启动时间,判断用户是否即将驾车出行,进而确定用户即将驾车出行时,根据用户预先配置的控制参数,控制车辆内的各设施的运行状态,以提高用户体验。
进一步地,实际应用中,在发送车辆控制指令时,服务器还可以先判断用户是否已经授权,若授权则发送车辆控制指令,否则,向用户终端发送授权请求消息以请求授权。
进一步地,服务器接收车载系统周期性上报的状态响应消息后,向用户的用户终端转发所述状态响应消息。其中,状态响应消息包括车辆内各车载装置的运行状态;
进一步地,若用户未在预设等待时长内(如,10分钟内)上车,则服务器向用户终端发送关闭车载装置请求消息,并根据接收的用户终端发送的车辆设置响应消息,判断是否关闭车载装置。
本申请实施例中,一种电子设备,包括:一个或多个处理器;以及
一个或多个计算机可读介质,可读介质上存储有用于车辆控制的程序,其中,程序被一个或多个处理器执行时,实现上述实施例中的各个步骤。
本申请实施例中,一个或多个计算机可读介质,可读介质上存储有用于车辆控制的程序,其中,程序被一个或多个处理器执行时,使得通信设备可以执行上述实施例中的各个步骤。
基于同一发明构思,本申请实施例中还提供了一种车辆控制装置,由于上述装置及设备解决问题的原理与一种车辆控制方法相似,因此,上述装置的实施可以参见方法的实施,重复之处不再赘述。
如图6所示,其为本申请实施例提供的一种车辆控制装置的结构示意图,包括:
第一确定单元60,用于根据获取的当前的车辆位置信息,确定车辆位置信息所属的常用车辆区域,常用车辆区域根据统计的用户每次停车的历史车辆位置信息确定;
获得单元61,用于根据车辆区域与出行模型之间的关联关系,获得常用车辆区域对应的出行模型,其中,出行模型基于用户出行数据训练获得;
二确定单元62,用于根据接收的用户出行数据以及出行模型,确定用户的出行概率;
发送单元63,用于若出行概率大于预设值,则向车载系统发送车辆控制指令。
较佳的,发送单元63具体用于:
确定出行概率大于预设值,并且当前时间达到预设时间,则向车载系统发送车辆控制指令。
较佳的,第一确定单元60具体用于:
获取用户每次停车的历史车辆位置信息;
对各历史车辆位置信息进行聚类分析,获得各簇历史车辆位置信息;
分别根据每一簇历史车辆信息,设置相应的车辆区域,并筛选出用户的停车次数高于预设次数门限的各车辆区域。
较佳的,获得单元61具体用于:
获取用户在预设时长内的用户出行数据,用户出行数据至少包括用户的轨迹数据和/或用户的操作数据;
通过出行模型对获取的轨迹数据集合和/或操作数据进行处理,获得用户的出行概率。
本申请实施例提供的一种车辆控制方法、装置、终端设备和介质中,根据获取的当前的车辆位置信息,确定车辆位置信息所属的常用车辆区域,常用车辆区域是根据统计的用户每次停车的历史车辆位置信息确定的;根据车辆区域与出行模型之间的关联关系,获得常用车辆区域对应的出行模型,其中,出行模型是基于用户的用户出行数据训练获得的;根据接收的用户出行数据,以及出行模型,确定用户的出行概率;若出行概率大于预设值,则向车载系统发送车辆控制指令。这样,根据用户每次驾车出行前的习惯,确定用户当前即将驾车出行时,通过车辆中的车载系统控制车辆内各设施的运行状态,以在用户驾车出行前自动按照用户的喜好等预先控制车辆中的空调等设施,减少了对人工控制的依赖,提高了智能化程度,为用户提供了良好的用户体验。
为了描述的方便,以上各部分按照功能划分为各模块(或单元)分别描述。当然,在实施本申请时可以把各模块(或单元)的功能在同一个或多个软件或硬件中实现。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例做出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。