CN117104179A - 一种车辆控制系统、方法、电子设备及介质 - Google Patents

Abstract

一种车辆控制系统、方法、电子设备及介质，涉及现实增强技术领域。该车辆控制系统包括：电子设备、车辆；电子设备用于获取场景图片，场景图片包括真实车辆；基于真实车辆在场景图片中的位置信息，展示以场景图片为背景的虚拟车辆；响应于用户对虚拟车辆的操作，向车辆发送第一指令；车辆用于执行第一指令，得到执行结果，向电子设备发送执行结果；电子设备用于根据执行结果，展示执行第一指令后的虚拟车辆。通过增强现实技术使得控制车辆可视化，用户细致化的操作可对车辆完成精准的控制，还可以在摄像实景位置展示车辆并测量前后距离等，从而使得电子设备与车辆的交互设计更自动化、人性化、精准化，同时也更利于数字车钥匙功能的扩展与升级。

Description

一种车辆控制系统、方法、电子设备及介质

技术领域

本申请涉及现实增强技术领域，尤其涉及一种车辆控制系统、方法、电子设备及介质。

背景技术

数字车钥匙是安装在智能手机、电子手表、电子手环等电子设备中的数字版车钥匙，电子设备可以通过数字车钥匙对车辆进行控制，完成无实体钥匙解锁汽车、发动行驶、控制车内温度等操作，从而提升用户的用车体验。

目前的几种主流数字车钥匙主要有：蓝牙低能耗(BluetoothLowEnergy，BLE)车钥匙、近场通信(NearFieldCommunication，NFC)车钥匙、超宽带(UltraWideBand，UWB)车钥匙。无论使用哪种数字车钥匙，都是在电子设备上绑定车辆的信息和标识后，以点击电子设备的应用软件中的传统按键的形式，控制汽车的后备箱、喇叭、车窗等部件。然而，传统按键不够美观，且对车辆的控制通常不够精准，无法做到控制车辆功能的细致化，导致用户体验感较差。

发明内容

本申请的目的在于：提供一种车辆控制系统、方法、电子设备及介质，能够通过用户细致化的操作即可对车辆完成更精准的控制，提升用户的体验感。

第一方面，本申请公开了一种车辆控制系统，该车辆控制系统包括手机、PAD、大屏等电子设备和车辆。电子设备用于获取场景图片，场景图片包括真实车辆；基于真实车辆在场景图片中的位置信息，展示以场景图片为背景的虚拟车辆；响应于用户对虚拟车辆的操作，向车辆发送第一指令；车辆用于执行第一指令，得到执行结果，向电子设备发送执行结果；电子设备用于根据执行结果，展示执行第一指令后的虚拟车辆。由此，通过增强现实技术使得控制车辆可视化，用户细致化的操作可对车辆完成精准的控制，还可以在摄像实景位置展示车辆并测量前后距离等，从而使得电子设备与车辆的交互设计更自动化、人性化、精准化，同时也更利于数字车钥匙功能的扩展与升级。

第二方面，本申请公开了一种车辆控制方法，应用于手机、PAD、大屏等电子设备，该方法包括：获取场景图片，场景图片包括真实车辆；基于真实车辆在场景图片中的位置信息，展示以场景图片为背景的虚拟车辆；响应于用户对虚拟车辆的操作，向车辆发送第一指令，以便车辆执行与第一指令对应的操作；展示执行第一指令后的虚拟车辆。由此，通过增强现实技术使得控制车辆可视化，用户细致化的操作可对车辆完成精准的控制，还可以在摄像实景位置展示车辆并测量前后距离等，从而使得电子设备与车辆的交互设计更自动化、人性化、精准化，同时也更利于数字车钥匙功能的扩展与升级。

在一些可能的实现方式中，真实车辆在场景图片中的位置信息通过以下方式获得：获取真实车辆在场景图片中的光感信息；根据光感信息，确定真实车辆在场景图片中距离参照点的距离信息；根据距离信息，获取真实车辆在场景图片中的位置信息。

在一些可能的实现方式中，真实车辆在场景图片中的位置信息通过以下方式获得：获取真实车辆在场景图片中距离参照点的距离信息；根据距离信息，获取真实车辆在场景图片中的位置信息。由此，即可获取真实车辆在场景图片中的位置信息，展示更精准的数字车钥匙界面上的图片，进而达成通过增强现实技术使得控制车辆可视化，用户细致化的操作可对车辆完成精准的控制，还可以在摄像实景位置展示车辆并测量前后距离等，从而使得电子设备与车辆的交互设计更自动化、人性化、精准化的有益效果。

在一些可能的实现方式中，虚拟车辆通过以下方式获得：根据真实车辆的信息获取虚拟车辆，真实车辆的信息包括真实车辆的品牌及型号、发动机号、唯一识别码中的一种或多种。

在一些可能的实现方式中，虚拟车辆通过以下方式获得：基于场景图片，获取真实车辆的长度样本数据；基于长度样本数据获取虚拟车辆。由此，可以获得更精准的虚拟车辆，进而达成通过增强现实技术使得控制车辆可视化，用户细致化的操作可对车辆完成精准的控制，还可以在摄像实景位置展示车辆并测量前后距离等，从而使得电子设备与车辆的交互设计更自动化、人性化、精准化的有益效果。

在一些可能的实现方式中，基于真实车辆在场景图片中的位置信息，展示以场景图片为背景的虚拟车辆，包括：获取真实车辆在场景图片中的位置信息；判断位置信息的个数是否大于或等于个数阈值；若是，则基于真实车辆在场景图片中的位置信息，展示以场景图片为背景的虚拟车辆。由此，可以获取更精准的场景作为背景，进而达成通过增强现实技术使得控制车辆可视化，用户细致化的操作可对车辆完成精准的控制，还可以在摄像实景位置展示车辆并测量前后距离等，从而使得电子设备与车辆的交互设计更自动化、人性化、精准化的有益效果。

在一些可能的实现方式中，在基于真实车辆在场景图片中的位置信息，展示以场景图片为背景的虚拟车辆之前，方法还包括：电子设备向车辆发送信息同步请求，信息同步请求中包括虚拟车辆的模型信息和鉴权信息，鉴权信息包括数字钥匙、身份认证信息中的一种或多种；电子设备接收车辆基于鉴权信息和模型信息反馈的响应信息，响应信息用于表示车辆与电子设备之间的信息是否已经同步。

第三方面，本申请公开了一种电子设备，包括处理器和存储器；存储器用于存储计算机执行命令；处理器用于执行存储器存储的计算机执行命令，使得处理器执行如第二方面中的车辆控制方法。

第四方面，本申请公开了一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序或指令，当计算机程序或指令被运行时，实现如第二方面中的车辆控制方法。

第五方面，本申请提供了一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行如第一方面中的车辆控制方法。

相较于现有技术，本申请具有以下有益效果：

本申请公开了一种车辆控制系统、方法、电子设备及介质，通过增强现实技术可以使得数字车钥匙控制车辆可视化，通过用户细致化的操作即可对车辆完成更精准的控制，还可以在摄像实景位置展示车辆并测量前后距离等，从而使得电子设备与车辆的交互设计更自动化、人性化、精准化，同时也更利于数字车钥匙功能的扩展与升级。

附图说明

图1为本申请实施例提供的一种主流数字车钥匙解决方案示意图；

图2为本申请实施例提供的一种电子设备的硬件结构示意图；

图3为本申请实施例提供的一种电子设备的软件结构示意图；

图4A为本申请实施例提供的一种车辆控制方法的解决方案示意图；

图4B为本申请实施例提供的一种车辆控制方法的整体架构示意图；

图5A为本申请实施例提供的一种车辆与数字车钥匙配对的方法信令图；

图5B为本申请实施例提供的一种现实增强的方法流程图；

图6为本申请实施例提供的一种启动应用的界面示意图；

图7为本申请实施例提供的一种身份认证的界面示意图；

图8为本申请实施例提供的一种配对成功的界面示意图；

图9为本申请实施例提供的一种车辆控制的方法流程图；

图10为本申请实施例提供的一种AR指令的界面示意图；

图11为本申请实施例提供的一种电子设备的相机页面示意图；

图12为本申请实施例提供的一种电子设备的图库页面示意图；

图13为本申请实施例提供的一种真实场景中虚拟车辆的界面示意图；

图14为本申请实施例提供的一种车辆检修的解决方案示意图。

具体实施方式

本申请说明书和权利要求书及附图说明中的术语“第一”、“第二”和“第三”等是用于区别不同对象，而不是用于限定特定顺序。

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

为了下述各实施例的描述清楚简洁，首先给出相关技术的简要介绍：

现实增强技术，是一种基于计算机实时计算和多传感器融合，实时地计算摄像影像的位置及角度并加上相应图像的技术将现实世界与虚拟信息结合起来的技术，通过将虚拟信息叠加到真实信息上，给人提供近似真实世界感受的体验。这种技术的目标是在屏幕上把虚拟世界套在现实世界并进行互动，已经在娱乐、军事和影视中得到广泛应用。比如，视频通话过程中，在通话者面部实时叠加帽子等虚拟场景，以增强通话者的场景内容，实现提高视频对话的趣味性。

数字车钥匙是安装在智能手机、电子手表、电子手环等电子设备中的数字版车钥匙，车主可以通过数字车钥匙实现无实体钥匙解锁汽车、发动行驶、控制车内温度等操作，极大地提升了用户的用车体验。

参见图1，该图为本申请实施例提供的一种主流数字车钥匙解决方案示意图。目前的几种主流数字车钥匙主要有：蓝牙低能耗(BluetoothLowEnergy，BLE)车钥匙、近场通信(NearFieldCommunication，NFC)车钥匙、超宽带(UltraWideBand，UWB)车钥匙。

BLE车钥匙是指在距离车辆较近的情况下，可以使用电子设备的蓝牙功能，在应用软件中进行车辆控制的一种数字车钥匙。BLE车钥匙通常在空旷场地15米范围内使用，其功耗低、技术成熟，但其性能会因使用的手机、环境干扰等因素而有所不同。

NFC车钥匙是指将带有NFC功能的电子设备靠近汽车车身的某个部位的刷卡感应区域(比如B柱、外后视镜的刷卡感应区域等)，无需完全贴合即可感应解锁的一种数字车钥匙。和BLE车钥匙相比，NFC车钥匙可以在电子设备没电的情况下正常运行。

UWB车钥匙是指只需靠近车辆就能够将车辆布置的多个锚点与电子设备相结合，以实现车辆近距离精确空间感知的一种数字车钥匙。利用车辆空间感知，车辆可以自主判断并控制车辆，以实现智能控制。

目前，无论使用哪种数字车钥匙，都是在电子设备上绑定自己车辆的信息和标识后，以点击电子设备的应用软件中的传统按键的形式，控制汽车的后备箱、喇叭、车窗等部件，并且车辆的落锁和解锁主要以距离(信号强度)感应、NFC接触芯片等来实现。

然而，传统按键不够美观，且对车辆的控制通常不够精准，无法做到控制车辆功能的细致化，导致用户体验感较差。

有鉴于此，本申请公开了一种车辆控制系统、方法、电子设备及介质，通过增强现实技术使得数字车钥匙控制车辆可视化，通过用户细致化的操作即可对车辆完成更精准的控制，还可以在摄像实景位置展示车辆并测量前后距离等，从而使得电子设备与车辆的交互设计更自动化、人性化、精准化，同时也更利于数字车钥匙功能的扩展与升级。

首先，介绍本申请实施例中提供的示例性电子设备100。在一些实施例中，电子设备100可以是手机、平板电脑、桌面型计算机、膝上型计算机、手持计算机、笔记本电脑、超级移动个人计算机(ultra-mobilepersonalcomputer，UMPC)、上网本、以及蜂窝电话、个人数字助理(personaldigitalassistant，PDA)、增强现实(augmentedreality，AR)设备、虚拟现实(virtualreality，VR)设备、人工智能(artificialintelligence，AI)设备、可穿戴式设备、车载设备、智能家居设备和/或智慧城市设备，本申请实施例对该电子设备100的具体类型不作特殊限制。参见图2，该图为本申请实施例提供的一种电子设备的硬件结构示意图。

如图2所示，电子设备100可以包括处理器110，内部存储器120，天线1，天线2，移动通信模块130，无线通信模块140，传感器模块150，显示屏160，摄像头170等。其中传感器模块150可以包括触摸传感器151、距离传感器152、接近光传感器153、环境光传感器154等。

可以理解的是，本实施例示意的结构并不构成对电子设备的具体限定。在另一些实施例中，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件，软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(applicationprocessor，AP)，调制解调处理器，图形处理器(graphicsprocessingunit，GPU)，图像信号处理器(imagesignalprocessor，ISP)，控制器，视频编解码器，数字信号处理器(digitalsignalprocessor，DSP)，基带处理器，和/或神经网络处理器(neural-networkprocessingunit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。例如，在本申请中，处理器110可以获取场景图片，场景图片包括真实车辆；基于真实车辆在场景图片中的位置信息，展示以场景图片为背景的虚拟车辆；响应于用户对虚拟车辆的操作，向车辆发送第一指令，以便车辆执行与第一指令对应的操作；展示执行第一指令后的虚拟车辆。由此，通过增强现实技术使得控制车辆可视化，用户细致化的操作可对车辆完成精准的控制，还可以在摄像实景位置展示车辆并测量前后距离等，从而使得电子设备与车辆的交互设计更自动化、人性化、精准化，同时也更利于数字车钥匙功能的扩展与升级。

其中，控制器可以是电子设备的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integratedcircuit，I2C)接口，集成电路内置音频(inter-integratedcircuitsound，I2S)接口，脉冲编码调制(pulsecodemodulation，PCM)接口，通用异步收发传输器(universal asynchronousreceiver/transmitter，UART)接口，移动产业处理器接口(mobileindustry processorinterface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户标识模块(subscriberidentitymodule，SIM)接口，和/或通用串行总线(universalserialbus，USB)接口等。

I2C接口是一种双向同步串行总线，包括一根串行数据线(serialdataline，SDA)和一根串行时钟线(derailclockline，SCL)。在一些实施例中，处理器110可以包含多组I2C总线。处理器110可以通过不同的I2C总线接口分别耦合触摸传感器151等。例如：处理器110可以通过I2C接口耦合触摸传感器151，使处理器110与触摸传感器151通过I2C总线接口通信，实现电子设备100的触摸功能。基于电子设备100的触摸功能，在用户触摸电子设备所显示的应用图标后，电子设备可以启动该应用。

UART接口是一种通用串行数据总线，用于异步通信。该总线可以为双向通信总线。它将要传输的数据在串行通信与并行通信之间转换。在一些实施例中，UART接口通常被用于连接处理器110与无线通信模块140。

MIPI接口可以被用于连接处理器110与显示屏160等外围器件。MIPI接口包括摄像头串行接口(cameraserialinterface，CSI)，显示屏串行接口(displayserialinterface，DSI)等。在一些实施例中，处理器110和摄像头170通过CSI接口通信，实现电子设备的拍摄功能。处理器110和显示屏160通过DSI接口通信，实现电子设备的显示功能。例如，电子设备基于显示功能，能够显示相关界面。

GPIO接口可以通过软件配置。GPIO接口可以被配置为控制信号，也可被配置为数据信号。在一些实施例中，GPIO接口可以用于连接处理器110与摄像头170，显示屏160，无线通信模块140，传感器模块150等。GPIO接口还可以被配置为I2C接口，I2S接口，UART接口，MIPI接口等。

可以理解的是，本实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备的结构限定。在本申请另一些实施例中，电子设备也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

电子设备的无线通信功能可以通过天线1，天线2，移动通信模块130，无线通信模块140，调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。电子设备中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

内部存储器120可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器120的指令，从而执行电子设备的各种功能应用以及数据处理。内部存储器120可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储电子设备使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器120可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universalflashstorage，UFS)等。处理器110通过运行存储在内部存储器120的指令，和/或存储在设置于处理器中的存储器的指令，执行电子设备的各种功能应用以及数据处理。

移动通信模块130可以提供应用在电子设备上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块130可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noiseamplifier，LNA)等。移动通信模块130可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块130还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块130的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块130的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。

调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过显示屏160显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器110，与移动通信模块130或其他功能模块设置在同一个器件中。

无线通信模块140可以提供应用在电子设备上的包括无线局域网(wirelesslocalarea networks，WLAN)(如无线保真(wirelessfidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(globalnavigationsatellitesystem，GNSS)，调频(frequencymodulation，FM)，近距离无线通信技术(nearfieldcommunication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块140可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块140经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块140还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

在一些实施例中，电子设备的天线1和移动通信模块130耦合，天线2和无线通信模块140耦合，使得电子设备可以通过无线通信技术与网络以及其他设备通信。所述无线通信技术可以包括全球移动通讯系统(globalsystemformobilecommunications，GSM)，通用分组无线服务(generalpacketradioservice，GPRS)，码分多址接入(codedivisionmultipleaccess，CDMA)，宽带码分多址(widebandcodedivisionmultipleaccess，WCDMA)，时分码分多址(time-divisioncodedivisionmultipleaccess，TD-SCDMA)，长期演进(longtermevolution，LTE)，BT，GNSS，WLAN，NFC，FM，和/或IR技术等。所述GNSS可以包括全球卫星定位系统(globalpositioningsystem，GPS)，全球导航卫星系统(globalnavigationsatellitesystem，GLONASS)，北斗卫星导航系统(beidounavigationsatellitesystem，BDS)，准天顶卫星系统(quasi-zenithsatellitesystem，QZSS)和/或星基增强系统(satellitebasedaugmentationsystems，SBAS)。

电子设备通过GPU，显示屏160，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏160和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

触摸传感器151，也称“触控器件”。触摸传感器151可以设置于显示屏160，由触摸传感器151与显示屏160组成触摸屏，也称“触控屏”。触摸传感器151用于检测作用于其上或附近的触摸操作。触摸传感器151可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏160提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器151也可以设置于电子设备100的表面，与显示屏160所处的位置不同。

距离传感器152，用于测量距离。电子设备100可以通过红外或激光测量距离。在一些实施例中，测距场景，电子设备100可以利用距离传感器152以实现测距。

接近光传感器153可以包括例如发光二极管(LED)和光检测器，例如光电二极管。发光二极管可以是红外发光二极管。电子设备通过发光二极管向外发射红外光。电子设备使用光电二极管检测来自附近物体的红外反射光。当检测到充分的反射光时，可以确定电子设备附近有物体。当检测到不充分的反射光时，电子设备可以确定电子设备附近没有物体。电子设备可以利用接近光传感器153检测用户手持电子设备贴近耳朵通话，以便自动熄灭屏幕达到省电的目的。接近光传感器153也可用于皮套模式，口袋模式自动解锁与锁屏。

环境光传感器154用于感知环境光亮度。电子设备可以根据感知的环境光亮度自适应调节显示屏160亮度。环境光传感器154也可用于拍照时自动调节白平衡。环境光传感器154还可以与接近光传感器153配合，检测电子设备是否在口袋里，以防误触。

显示屏160用于显示图像，视频等。显示屏160包括显示面板。显示面板可以采用液晶显示屏(liquidcrystaldisplay，LCD)，有机发光二极管(organiclight-emittingdiode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrixorganiclightemitting diode的，AMOLED)，柔性发光二极管(flexlight-emittingdiode，FLED)，Miniled，MicroLed，Micro-oled，量子点发光二极管(quantumdotlightemittingdiodes，QLED)等。在一些实施例中，电子设备可以包括1个或N个显示屏160，N为大于1的正整数。

电子设备的显示屏160上可以显示一系列图形用户界面(graphicaluserinterface，GUI)，这些GUI都是该电子设备的主屏幕。一般来说，电子设备的显示屏160的尺寸是固定的，只能在该电子设备的显示屏160中显示有限的控件。控件是一种GUI元素，它是一种软件组件，包含在应用程序中，控制着该应用程序处理的所有数据以及关于这些数据的交互操作，用户可以通过直接操作(directmanipulation)来与控件交互，从而对应用程序的有关信息进行读取或者编辑。一般而言，控件可以包括图标、按钮、菜单、选项卡、文本框、对话框、状态栏、导航栏、Widget等可视的界面元素。

摄像头170用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(chargecoupleddevice，CCD)或互补金属氧化物半导体(complementarymetal-oxide-semiconductor，CMOS)光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给ISP转换成数字图像信号。ISP将数字图像信号输出到DSP加工处理。DSP将数字图像信号转换成标准的RGB，YUV等格式的图像信号。在一些实施例中，电子设备可以包括1个或N个摄像头170，N为大于1的正整数。

另外，在上述部件之上，运行有操作系统。例如苹果公司所开发的iOS操作系统，谷歌公司所开发的Android开源操作系统，微软公司所开发的Windows操作系统等。在该操作系统上可以安装运行应用程序。

电子设备的操作系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的Android系统为例，示例性说明电子设备的软件结构。

参见图3，该图为本申请实施例提供的一种电子设备的软件结构示意图。本申请实施例以分层架构的Android系统为例，示例性说明电子设备100的软件结构。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用层(Applications,APP)、框架层(Framework,FWK)、硬件抽象层(HardwareAbstractionLayer,HAL)和内核层(Kernel)。

应用程序层可以包括一系列应用程序包。在一些实施例中，应用程序层可以包括数字车钥匙、相机等应用程序。

框架层为应用层的应用程序提供应用编程接口(applicationprogramminginterface,API)和编程框架，在该框架层可以包括一些预先定义的函数。在一些具体的实现方式中，框架层可以包括摄像模块301、光感模块302、定位模块303、采集模块304、AR图像处理模块305、AR手势解析模块306、车辆指令解析模块307、通信模块308。

在一些示例中，用户在打开应用程序数字车钥匙APP后，可以在数字车钥匙APP上基于框架层的摄像模块301或采集模块304通过摄像头170进行拍照操作，从而将拍摄的图片作为场景图片，进而建立真实场景与显示屏160之间的映射关系。

在一些示例中，可以在数字车钥匙APP上基于框架层的光感模块302通过接近光传感器153、环境光传感器154进行光感定位，从而获取真实场景下的车辆与各个参照点的位置信息。

在一些示例中，可以在数字车钥匙APP上基于框架层的定位模块303通过天线1、移动通信模块130、天线2和无线通信模块140进行定位，以直接获取真实场景下的车辆与各个参照点的位置信息。

在一些示例中，可以在数字车钥匙APP上基于框架层的AR图像处理模块305，在数字车钥匙APP的显示界面上基于距离等信息，等比例展示真实场景以及真实场景中的虚拟车辆。

在一些示例中，可以在数字车钥匙APP上基于框架层的AR手势解析模块306，响应于用户在数字车钥匙APP的显示界面上操作虚拟车辆的任意部件(如外划车门、下划车窗、点击后备箱等)，从而对触碰的部件与动作手势进行解析分析，并将该触碰部件与动作手势组装为操作指令。

在一些示例中，可以在数字车钥匙APP上基于框架层的车辆指令解析模块307，将上述解析后的触碰的部件与动作手势组装为操作指令，并通过通信模块308将该操作指令经由云服务器发送至车辆的车载控制器，以使车辆完成与操作指令对应的状态操作。示例性的，若操作指令中的触碰部件为车门，动作手势为外划，那么车辆端对应的状态操作则为开启车门。

硬件抽象层定义硬件“驱动”的接口，降低安卓操作系统与硬件的耦合度。

内核层负责管理系统的进程、内存、设备驱动程序、文件和网络系统，决定着系统的性能和稳定性。

需要说明的是，本申请实施例虽然以Android系统为例进行说明，但是其基本原理同样适用于基于iOS、Windows等操作系统的电子设备100。

参见图4A，该图为本申请实施例提供的一种车辆控制方法的解决方案示意图。其中，数字车钥匙401以应用软件的形式集成于电子设备100上。云服务器402是有一定性能和存储空间的中枢服务器，用于向车辆403的车载控制器404下发从电子设备100的数字车钥匙401收集的操作指令、向电子设备100回传状态操作完成指令以反馈车辆403对从操作指令的服从结果、对电子设备100和车辆403进行鉴权管理以及记录电子设备100的操作指令日志等。可以理解的是，若无需对电子设备100和车辆403进行鉴权管理以及记录电子设备100的操作指令日志，即可使电子设备100和车辆403直接通信车控数据和车辆状态，而无需经由云服务器402转达。

在电子设备100经由云服务器402绑定车辆403成功并配对完成后，数字车钥匙401的显示界面上可以显示虚拟的车辆403。随后，用户可以采集照片或视频，并利用计算机视觉处理方法将虚拟的车辆403等比例依附于照片或视频中的真实场景，即，用户可以通过数字车钥匙401的显示界面直接看到虚拟的车辆403以及车辆403所处的真实场景，并且可以通过操作虚拟的车辆403的任意部件来实现对车辆403的对应部件的相应状态操作。

随后，响应于用户对数字车钥匙401的显示界面中虚拟的车辆403的不同操作，电子设备100会将该操作作为操作指令发送至云服务器402。该操作可以是对车控数据进行操作，例如点击显示界面中虚拟的车辆403的空调，以将车辆403的空调调整至26℃(摄氏度)；该操作也可以是对车辆状态进行操作，例如点击显示界面中虚拟的车辆403的车门后向外滑动，以将车辆403的车门打开等。对于具体的操作及其对应的操作指令，本申请不做限定。

云服务器402在接收到电子设备100发送的操作指令后，再将该操作指令同步至车辆403。在车辆403在接收到云服务器402发送的操作指令后，车载控制器404完成该操作指令对应的状态操作(例如调整空调温度、打开车门等)，并再经由云服务器402将该状态操作的结果同步至电子设备100，进而可以在数字车钥匙401的显示界面上展示该状态操作的结果给用户。

参见图4B，该图为本申请实施例提供的一种车辆控制方法的整体架构示意图。电子设备100的数字车钥匙401可以包括摄像模块301、光感模块302、定位模块303、采集模块304、AR图像处理模块305、AR手势解析模块306、车辆指令解析模块307、通信模块308。云服务器可以鉴权服务模块407、存储服务模块408、日志服务模块409。车辆403的车载控制器404可以包括车载通信模块405、车辆控制模块406。

电子设备100的数字车钥匙401基于摄像模块301、光感模块302、定位模块303、采集模块304，通过摄像头170、距离传感器152、接近光传感器153、环境光传感器154等硬件，接收现实中的环境和物体作为真实场景，并得到真实场景中的信息数据(例如光感信息、位置信息等)。电子设备100的数字车钥匙401基于AR图像处理模块305，可以基于上述信息数据在电子设备100的数字车钥匙401的显示界面上展示虚拟的车辆403以及该车辆403所处的真实场景。随后，响应于用户在数字车钥匙APP的显示界面上操作虚拟车辆的任意部件，数字车钥匙401的AR手势解析模块306可以对触碰的部件与动作手势进行解析分析。接着，数字车钥匙401的车辆指令解析模块307将上述解析后的触碰的部件与动作手势组装为操作指令，并通过通信模块308将该操作指令经由云服务器402发送至车辆403的车载控制器404的车载通信模块405。在车载控制器404的车辆控制模块406在做出与操作指令对应的状态操作后，再将状态操作完成指令发送至电子设备100的数字车钥匙401的通信模块308。

云服务器402的鉴权服务模块407用于管理授权的车辆与电子设备，识别指令操作的发送端和接收端的身份数据。存储服务模块408用于存储用户生成的车钥匙，用户可以随时同步属于自己的车钥匙与数据，减少电子设备100本地设备的存储量。日志服务模块409用于记录用户的操作日志和车辆403的反馈记录，通过操作日志和反馈记录可以减少事故与错误的发生。

参见图5A，该图为本申请实施例提供的一种的车辆与数字车钥匙配对的方法信令图。该方法包括：

S501：数字车钥匙启动。

在电子设备100中安装数字车钥匙APP，并在数字车钥匙APP上注册账号后，电子设备100即可启动数字车钥匙401。其中，数字车钥匙401可以用于控制车辆的解锁、上锁、启动车辆、打开/关闭后备箱、打开/关闭空调、调节空调温度、打开/关闭座椅加热、打开/关闭车窗、闪灯、鸣笛、通风等操作。

参见图6，该图为本申请实施例提供的一种启动应用的界面示意图，该场景中包括电子设备100，以电子设备100为智能手机为例进行说明。图6中，电子设备100可以呈现人机交互界面。用户为电子设备100解锁后，电子设备100可以向用户呈现桌面600，该桌面600包括多种应用程序的图标，例如，相机的图标、手电筒的图标、数字车钥匙的图标601等。用户可以对应用的图标触发操作，例如点击、长按、滑动等。电子设备100接收到用户触发的操作后，即可启动相应的应用。在一种实施例中，用户可以直接点击电子设备100的桌面600中的数字车钥匙的图标601，从启动数字车钥匙应用，进入数字车钥匙401的应用界面。

参见图5B，该图为本申请实施例提供的一种现实增强的方法流程图，该现实增强的方法即为完成现实增强显示的底层逻辑。该增强现实的方法整体使用ARCore进行AR移动端(即电子设备100)的开发，当用户移动电子设备100时，ARCore能够了解其周围的真实场景并以数字方式模拟该真实场景。

需要说明的是，“数字车钥匙启动”这一操作对应的底层逻辑为S5001步骤的“新建Android项目”，以及S5002步骤的“安装GoogleARCore和SceneformSDK”。其中，GoogleARCore和SceneformSDK是完成增强现实的主要安装包，这两者是实现AR应用的基础。

S502：数字车钥匙响应于绑定请求，解析车辆模型。

绑定请求即为将车辆403与电子设备100的数字车钥匙401绑定，从而可以在数字车钥匙401的显示界面上显示虚拟的车辆403的请求。响应于用户在电子设备100上提交的绑定请求，数字车钥匙401开始解析车辆403的模型。

在一些具体的实现方式中，数字车钥匙401可以通过对车辆拍照的方式获取车辆模型，从而进一步解析车辆模型。具体的，可以通过定位照片中的车辆样本，从而对车辆样本的数据进行采集后，利用上述车辆样本的数据作为模型参数绘制出车辆模型。示例性的，车辆样本的数据(即模型参数)可以包括：车辆的外形数据(例如是轿车、货车或客车)、车辆的颜色数据以及车辆的大小数据等。

在另一些具体的实现方式中，数字车钥匙401还可以根据车辆信息获取车辆模型，从而进一步解析车辆模型。示例性的，该车辆信息可以是车辆的品牌及型号、车辆的发动机号、车辆的唯一识别码(UniversallyUniqueIdentifier，UUID)等。在一些实现方式中，由于车辆的发动机号、车辆的UUID都是一长串数字，用户在输入车辆信息的过程中容易出错。因而为了避免输入车辆信息出错，可以基于车辆的发动机号以及UUID生成电子码(如二维码或条形码)，并将生成的电子码显示给用户(比如显示在车辆的中控屏幕上)，以便用户扫码该电子码后即可自动输入车辆信息。

需要说明的是，若数字车钥匙401是根据车辆信息获取车辆模型，那么S502的操作对应的底层逻辑为S5003的“根据车辆车型参数使用3DMAX绘制车辆模型”。即，数字车钥匙401支持的车辆型号应当与合作车企达成协议，利用3DMAX或者其他3D模型根据合作车企提供的轮毂特征信息和车型特征信息(例如车辆轮毂、车辆外形、车辆款式、车标和车型特征等信息)等车辆信息利用绘制软件进行模型制作，或者由合作车企直接提供车辆模型，最终将模型导入数字车钥匙401中。

在另一些具体的实现方式中，数字车钥匙401还可以直接对电子设备100中存储的车辆模型进行解析，或，数字车钥匙401下载云服务器402中的车辆模型后对该车辆模型进行解析。需要说明的是，还存在很多解析车辆模型的方法，对于具体的解析车辆模型的方法，本申请不做限定。

S503：数字车钥匙存储车辆模型。

在执行S502的解析车辆模型的操作后，数字车钥匙401可以将该车辆模型存储至电子设备100的本地内存，从而在此次配对断开后，可以更方便快捷进行下一次配对。

需要说明的是，“数字车钥匙存储车辆模型”这一操作对应的底层逻辑为S5004步骤的“将模型.obj等文件复制到项目中”。其中，.obj文件是一种3D模型文件格式。

S504：数字车钥匙向云服务器发起信息同步请求。

信息同步请求附带了502步骤中获取的车辆模型，数字车钥匙401向云服务器402发送信息同步请求的目的是：确定车辆模型中的各类模型参数均正确。示例性的，车辆模型参数可以是车辆的外形数据(例如是轿车、货车或客车)、车辆的颜色数据以及车辆的大小数据等。

在一些具体的实现方式中，电子设备100的数字车钥匙401向云服务器402发起的信息同步请求中除了车辆模型，还可以附带数字钥匙、身份认证信息等鉴权信息。鉴权指的是验证用户是否拥有访问的权利，即云服务器402判断数字车钥匙401是否可以同步车辆403端的准确参数。当云服务器402鉴权成功后，云服务器402再向车辆403发起与数字车钥匙401向云服务器402发起的信息同步请求相对应的信息同步请求，以使数字车钥匙401和车辆403可以完成信息同步。

具体的，身份认证信息可以是个人通用身份标识码(PersonalIdentificationNumber，PIN)、指纹、人脸、虹膜、骨传导，以及基于行为的认证等。可以理解的是，当鉴权方式是身份认证鉴权方式时，数字车钥匙401需要先采集到用户输入的生物特征或者其他认证数据。在此过程中，数字车钥匙401可以生成身份认证界面，以告知其本次执行的身份认证的用途。同时，身份认证界面还可以显示引导信息，以引导用户完成身份认证。

参见图7，该图为本申请实施例提供的一种身份认证的界面示意图。该场景中包括电子设备100，以电子设备100为智能手机为例进行说明。图7中，电子设备100可以呈现身份认证界面700。在该身份认证界面700中，中间区域中的提示文字及图片用于告知用户，本次身份认证为指纹识别，且此身份认证是用于信息同步。下方区域的按键用于提示用户可以进行人脸识别或取消验证。

可以理解的是，云服务器的效果是鉴权存储数据，以判定数字车钥匙401是否可以同步车辆403端的准确参数。若不需要鉴权存储数据，而直接使数字车钥匙401同步车辆403端的准确参数，则可以直接使数字车钥匙401向车辆403发起信息同步请求。

S505：云服务器鉴权数据并存储车辆模型。

在一些具体的实现方式中，若数字车钥匙401发起的信息同步请求中附带第一数字钥匙，那么云服务器402可以通过对比该第一数字钥匙和云服务器402存储的第二数字钥匙，来验证数字车钥匙401是否可以同步车辆403端的准确参数。在正常情况下，第一数字钥匙和第二数字钥匙是可以相互匹配的，若第一数字钥匙和第二数字钥匙如果匹配成功，则说明比对成功，云服务器402判定数字车钥匙401可以同步车辆403端的准确参数，并执行S506及后续操作；如果第一数字钥匙和第二数字钥匙匹配不成功，则说明比对失败，云服务器402判定数字车钥匙401不可以同步车辆403端的准确参数，需要返回至S501重新开始配对。

在另一些具体的实现方式中，若数字车钥匙401发起的信息同步请求中附带身份认证，云服务器402可以通过采集到用户输入的密码、生物特征或者其他认证数据，然后与预先存储的密码、生物特征或者其他认证数据进行比较，从而可以生成用户身份认证结果。若采集到的认证数据与预先存储的认证数据相匹配，则说明比对成功，云服务器402判定数字车钥匙401可以同步车辆403端的准确参数，并执行S506及后续操作；若采集到的认证数据与预先存储的认证数据不匹配，则说明比对失败，云服务器402判定数字车钥匙401不可以同步车辆403端的准确参数，需要返回至S501重新开始配对。

需要说明的是，还存在很多鉴权数据的方法，对于具体的存储数据的方法，本申请不做限定。上述鉴权数据的过程均在云服务器402的鉴权服务模块407中执行。鉴权服务模块407用于管理授权的车辆与电子设备，识别指令操作的发送端和接收端的身份数据。

在云服务器402鉴权数据后，云服务器还将信息同步请求中的车辆模型保存至云服务器402的存储服务模块408中。存储服务模块408用于存储用户生成的车钥匙、车辆模型等，用户可以随时同步属于自己的车钥匙与数据，减少电子设备100本地设备的存储量。

S506：云服务器向车辆发起信息同步请求。

当云服务器402鉴权存储数据成功，判定数字车钥匙401可以同步车辆403端的准确参数后，云服务器402会向车辆403发起信息同步请求，以同步车辆403的信息。当车辆403收到云服务器402发送的信息同步请求，即为车辆403与数字车钥匙401配对成功。

车辆403与数字车钥匙401配对成功后，数字车钥匙401的显示界面上即会显示车辆403的信息。参见图8，该图为本申请实施例提供的一种配对成功的界面示意图。图8中，电子设备100可以呈现配对成功界面800。该配对成功界面800可以展示汽车车牌号、虚拟的车辆(车辆模型)、以及AR指令按键801、场景导入按键802等功能插件。

可以理解的是，若用户需要将虚拟的车辆403(车辆模型)等比例依附于真实场景，即通过数字车钥匙401的显示界面直接看到虚拟的车辆403以及车辆403所处的真实场景，则可以在点击场景导入按键802后，执行下述的S901及后续的步骤。若用户不需要看到车辆403所处的真实场景，而直接操作虚拟的车辆403的任意部件来实现对车辆403的对应部件的相应状态操作，则可以在点击AR指令按键801后，执行下述的S904及后续的步骤。

参见图9，该图为本申请实施例提供的一种车辆控制的方法流程图，应用于车辆403与数字车钥匙401配对成功后。该方法包括：

S901：数字车钥匙获取场景图片序列。

场景指的是车辆403现实中所处的真实场景，场景图像序列中包含的所有场景图像均为车辆403在真实场景中的不同角度的图像。该场景图像可以是RGB图像，也可以是其他格式的图像，对于具体的图像格式，本申请不做限定。该场景图片序列可以是对场景视频进行抽帧处理后拆分形成的图像帧序列，也可以是两张及以上的场景图像组成的序列。

在一些可能的实施方式中，可以针对车辆403使用电子设备100拍摄视频后，利用OpenCV软件对该视频进行视频抽帧处理，例如可以选取间隔5帧的图像作为关键帧图像，并以关键帧图像序列作为场景图像序列。需要说明的是，还可以是选取间隔3帧、10帧及其他帧数的图像作为关键帧图像，对于具体的帧数，本申请不做限定。

在另一些可能的实施方式中，也可以针对车辆403使用电子设备100拍摄两张及以上的照片，并以上述照片作为场景图像序列。需要说明的是，该照片可以是一系列不同方位的电子设备同时进行拍摄的照片，也可以是单个电子设备进行移动拍摄的照片，对于具体的拍摄方法，本申请不做限定。

参见图8，用户可以在进入配对成功界面800后，点击场景导入按键802，进入如图10所示的界面。参见图10，该图为本申请实施例提供的一种AR指令的界面示意图。电子设备100可以呈现AR指令界面1000。进入AR指令界面1000后，该AR指令界面1000显示相机按键1001和图库按键1002，用户可以通过点击相机按键1001进入电子设备100的相机插件，或通过点击图库按键1002进入电子设备100的图库插件。

参见图11，该图为本申请实施例提供的一种电子设备的相机页面示意图。在点击相机按键1001进入电子设备100的相机插件后，可以显示相机页面1100。该相机页面1100包括图库按键、镜头翻转按键、拍摄按键1101等。用户可以点击相机页面1100中的拍摄按键1101拍摄多张场景图片以作为场景图片序列。

参见图12，该图为本申请实施例提供的一种电子设备的图库页面示意图。在点击图库按键1002进入电子设备100的图库插件后，可以显示图库页面1200。用户可以对图库页面1200中的图片进行点击的操作，从而选择多张场景图片作为场景图片序列。

S902：数字车钥匙进行光感定位，以获取位置信息。

在一些具体的实现方式中，数字车钥匙401可以通过电子设备100硬件结构中的接近光传感器153和/或环境光传感器154获取当前的光感信息，再根据获取到的当前光感信息进行光感定位，以获取真实场景下的车辆403与真实场景中各个参考点的位置信息。其中，接近光传感器153是一种使用电磁场、光和声音检测反射光的存在与否的传感器。当检测到充分的反射光时，可以确定电子设备100附近有物体。当检测到不充分的反射光时，可以确定电子设备100附近没有物体。环境光传感器154是一种通过感知周围光照强度，实时输出电信号的一种传感器。需要说明的是，对于具体的参照点的位置和个数，本申请不做限定。

在另一些具体的实现方式中，数字车钥匙401可以通过检测场景图片序列中的亮度测算出光感信息，再根据获取到的光感信息进行光感定位，以获取真实场景下的车辆403与真实场景中各个参照点的位置信息。需要说明的是，对于获取当前光感信息的方法，本申请不做限定。

可以理解的是，数字车钥匙401还可以通过电子设备100硬件结构中的距离传感器152直接获取真实场景下的车辆403与真实场景中各个参照点的距离信息。随后，再根据距离信息，确定车辆在场景中的位置信息。需要说明的是，对于具体的获取位置信息的方法，本申请不做限定。

需要说明的是，“数字车钥匙获取进行光感定位，以获取位置信息”这一操作对应的底层逻辑为S5005步骤的“通过com.google.ar.core.session创建管理AR系统”，以及S5006步骤的“通过com.google.ar.core.ImageMedata和com.google.ar.core.LightEstimate获取图像捕获的数据和真实场景光照的估计信息”。

S5005中，通过com.google.ar.core.session创建管理AR系统需要在应用的Activity中的onCreate方法中创建Session和Config。其中，Session是ARCore的管理类，ARCore的打开、关闭、视频帧的获取等都是通过Session来管理。Config可以用来存放一些配置信息，如平面的查找模式、光照模式等信息都是记录在该类中。

S5006中，通过com.google.ar.core.ImageMedata和com.google.ar.core.LightEstimate获取图像捕获的数据和真实场景光照的估计信息的同时，可以加载之前导入项目中的车辆模型，并创建arFragment来托管当前场景。随后，可以根据HitResult创建锚点，锚点是真实世界中一个固定的位置和方向，锚点的位置会随着手机摄像头的位置的变化而变化，从而实现相对意义上的“位置不变”。

S903：数字车钥匙基于场景图片、位置信息和车辆模型展示真实场景中的虚拟车辆。

在获取到位置信息后，数字车钥匙401可以将该位置信息和S503中存储的车辆模型与场景图片进行整合，以展示真实场景中的虚拟车辆。参见图13，该图为本申请实施例提供的一种真实场景中虚拟车辆的界面示意图。图13中，电子设备100可以呈现真实场景中虚拟车辆的界面1300。该界面中的车辆即为汽车车钥匙解析并存储的车辆模型，该界面中的树木即为真实场景中的树木，并且该界面中的车辆与真实场景与现实中的车辆与真实场景的比例相同。

在一些具体的实现方式中，在展示真实场景中的虚拟车辆之前，数字车钥匙需要判断获取到的位置信息是否足够将车辆模型与位置信息、场景图片进行整合。示例性的，可以判断获取到的位置信息的个数是否大于或等于预设的个数阈值。若获取到的位置信息的个数大于或等于预设的个数阈值，那么数字车钥匙获取到的位置信息足够将虚拟车辆与位置信息进行整合；若获取到的位置信息的个数小于预设的个数阈值，那么数字车钥匙获取到的位置信息无法将虚拟车辆与位置信息进行整合。

需要说明的是，“数字车钥匙基于位置信息展示真实场景中的虚拟车辆”这一操作对应的底层逻辑为S5007步骤的“通过com.google.ar.core.Frame实时更新AR系统”以及S5008步骤的“通过GLSurfaceView视频渲染并显示”。即，在电子设备100更新AR系统后，获取到的真实场景将从锚点发散，并根据车辆模型等资源文件创建节点以及GLSurfaceView对象。GLSurfaceView将与图形渲染的上下文关联，最终将视频渲染到屏幕并显示出虚拟车辆与真实场景的结合。

S904：响应于用户的操作，数字车钥匙获取操作指令。

当真实场景中的虚拟的车辆403(车辆模型)显示在电子设备100的显示屏上后，用户可以操作虚拟的车辆403的任意部件，如车门、车窗、后备箱等。数字车钥匙会对用户触碰的部件与动作手势进行解析分析，并将该触碰部件与动作手势组装为操作指令。

示例性的，用户若点击虚拟车辆的车门后进行向外的滑动，则该操作指令中的触碰部件为车门、动作手势为向外滑动；用户若点击虚拟车辆的后备箱后进行向下的滑动，则该操作指令中的触碰部件为后备箱、动作手势为向下滑动。

需要说明的是，“响应于用户的操作，数字车钥匙得到操作指令”这一操作对应的底层逻辑为S5009步骤的“使用GestureDetector根据触碰的坐标与虚拟车辆坐标，获取用户的操作指令”。即，当用户触摸屏幕和虚拟的车辆403时，Sceneform会将触摸事件传递至连接到节点与真实场景的事件处理程序和侦听器，再通过GestureDetecto对点按(选择)、拖动(移动)、双指张合(缩放)和倾斜(旋转)手势的支持。根据触摸的点位，计算出操作动作，并将动作封装成可传输的数据包，即操作指令。

S905：数字车钥匙将操作指令发送至云服务器。

数字车钥匙401在组装完成操作指令后，将该操作指令同步至云服务器402。需要说明的是，“响应于用户的操作，数字车钥匙得到操作指令”这一操作对应的底层逻辑为S5010步骤的“将操作指令传输至云服务器”。

S906：云服务器鉴权数据并存储操作指令。

云服务器402可以将S905步骤中获取到的操作指令保存至云服务器402本地的日志服务模块409中。日志服务模块409用于记录用户的操作日志和车辆的反馈记录，通过日志可以减少事故与错误的发生。

需要说明的是，S906步骤中云服务器402鉴权数据的方式与S505中云服务器402鉴权数据的方式相同，这里不再赘述。

S907：云服务器将实际操作指令发送至车辆。

云服务器402在获取操作指令后，再将该操作指令发送至车辆403，从而使得车辆403的车载控制器404可以执行与操作指令相对应的状态操作。

可以理解的是，上述S906的步骤和S907的步骤在实际执行时不分先后顺序，即云服务器402存储操作指令和将操作指令发送至车辆403两个步骤之间不分先后顺序。

S908：车辆执行与操作指令对应的状态操作。

该状态操作是与操作指令相对应的操作。示例性的，如果操作指令中的触碰部件为车门、动作手势为向外滑动，那么车辆403的车载控制器404则会自动开启车门；操作指令中的触碰部件为发动机、动作手势为点击，那么车辆403的车载控制器404则会自动开启发动机。

S909：车辆组装表征状态操作完成的完成指令。

在车辆403执行与操作指令对应的状态操作后，车辆403会组装表征状态操作完成的完成指令。

S910：车辆将完成指令发送至云服务器。

在车辆403组装表征状态操作完成的完成指令后，将该完成指令发送至云服务器402。

S911：云服务器鉴权数据并存储完成指令。

云服务器402可以将S909步骤中获取到的完成指令保存至云服务器402本地的日志服务模块409中。日志服务模块409用于记录用户的操作日志和车辆的反馈记录，通过日志可以减少事故与错误的发生。

需要说明的是，S910步骤中云服务器402鉴权数据的方式与S505中云服务器402鉴权数据的方式相同，这里不再赘述。

S912：云服务器将完成指令发送至数字车钥匙。

云服务器402在获取完成指令后，再将该完成指令发送至电子折欸100的数字车钥匙401，从而使得数字车钥匙401得知车辆403已经完成状态操作。

可以理解的是，上述S911的步骤和S912的步骤在实际执行时不分先后顺序，即云服务器402存储完成指令和将完成指令发送至数字车钥匙401两个步骤之间不分先后顺序。

S913：数字车钥匙展示与完成指令对应的状态。

此时，数字车钥匙401的显示界面上即可显示与车辆403的状态操作相对应的状态。示例性的，若此时车辆403的后备箱已经开启，那么数字车钥匙401的显示界面上的虚拟的车辆403的后备箱也需要开启。

本申请公开了一种车辆控制方法，通过增强现实技术使得数字车钥匙控制车辆可视化，通过用户细致化的操作即可对车辆完成更精准的控制，还可以在摄像实景位置展示车辆并测量前后距离等，从而使得电子设备与车辆的交互设计更自动化、人性化、精准化，同时也更利于数字车钥匙功能的扩展与升级。

进一步地，参见图14，该图为本申请实施例提供的一种车辆检修的解决方案示意图。由该图可知，通过电子设备100中的现实增强投影的车辆模型，用户能够完全掌控车辆403的整体结构、状态等。当通过对车辆403设置各类传感器、感应器时，用户能够通过电子设备100查看车辆403的当前各个部件、零件状况，能够在大数据分析指导下，自行根据车辆模型上的零件位置与透视结构图，拆解车机并维修。并且，还可以在自动驾驶技术的辅助下，通过用户将车辆投影在指定位置后，车辆403将自动停入指定位置，为用户提供便利。

此外，本发明提出的基于现实增强技术的数字车钥匙401还支持对当前场景的测距，当用户需要在某位置停车时，可以通过手机摄像收集场景数据，并经过运动追踪的并行测距过程来计算场景内障碍物的位置，结合车辆各类参数进行组合分析，得出是否能够停车的结论。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序或指令，当所述计算机程序或指令被运行时，实现上述方法实施例中电子设备100执行的各个功能或者步骤。

本申请另一实施例还提供了一种包含指令的计算机程序产品。当该计算机程序产品在计算机或处理器上运行时，使得计算机或处理器执行上述任一个方法中的一个或多个步骤。

Claims (10)

1.一种车辆控制系统，其特征在于，所述车辆控制系统包括：电子设备、车辆；

所述电子设备，用于获取场景图片，所述场景图片包括真实车辆；基于所述真实车辆在所述场景图片中的位置信息，展示以所述场景图片为背景的虚拟车辆；响应于用户对所述虚拟车辆的操作，向所述车辆发送第一指令；

所述车辆，用于执行所述第一指令，得到执行结果，向所述电子设备发送所述执行结果；

所述电子设备，用于根据所述执行结果，展示执行所述第一指令后的虚拟车辆。

2.一种车辆控制方法，其特征在于，应用于电子设备，所述方法包括：

获取场景图片，所述场景图片包括真实车辆；

基于所述真实车辆在所述场景图片中的位置信息，展示以所述场景图片为背景的虚拟车辆；

响应于用户对所述虚拟车辆的操作，向车辆发送第一指令，以便所述车辆执行与所述第一指令对应的操作；

展示执行所述第一指令后的虚拟车辆。

3.根据权利要求2所述的方法，其特征在于，所述真实车辆在所述场景图片中的位置信息通过以下方式获得：

获取所述真实车辆在所述场景图片中的光感信息；

根据所述光感信息，确定所述真实车辆在所述场景图片中距离参照点的距离信息；

根据所述距离信息，获取所述真实车辆在所述场景图片中的位置信息。

4.根据权利要求2所述的方法，其特征在于，所述真实车辆在所述场景图片中的位置信息通过以下方式获得：

获取所述真实车辆在所述场景图片中距离参照点的距离信息；

根据所述距离信息，获取所述真实车辆在所述场景图片中的位置信息。

5.根据权利要求2所述的方法，其特征在于，所述虚拟车辆通过以下方式获得：

根据所述真实车辆的信息获取虚拟车辆，所述真实车辆的信息包括所述真实车辆的品牌及型号、发动机号、唯一识别码中的一种或多种。

6.根据权利要求2所述的方法，其特征在于，所述虚拟车辆通过以下方式获得：

基于所述场景图片，获取所述真实车辆的长度样本数据；

基于所述长度样本数据获取虚拟车辆。

7.根据权利要求2所述的方法，其特征在于，基于所述真实车辆在所述场景图片中的位置信息，展示以所述场景图片为背景的虚拟车辆，包括：

获取所述真实车辆在所述场景图片中的位置信息；

判断所述位置信息的个数是否大于或等于个数阈值；

若是，则基于所述真实车辆在所述场景图片中的位置信息，展示以所述场景图片为背景的虚拟车辆。

8.根据权利要求2所述的方法，其特征在于，在基于所述真实车辆在所述场景图片中的位置信息，展示以所述场景图片为背景的虚拟车辆之前，所述方法还包括：

所述电子设备向所述车辆发送信息同步请求，所述信息同步请求中包括虚拟车辆的模型信息和鉴权信息，所述鉴权信息包括数字钥匙、身份认证信息中的一种或多种；

所述电子设备接收所述车辆基于所述鉴权信息和所述模型信息反馈的响应信息，所述响应信息用于表示所述车辆与所述电子设备之间的信息是否已经同步。

9.一种电子设备，其特征在于，包括处理器和存储器；

所述存储器，用于存储计算机执行指令；

所述处理器，用于执行所述存储器存储的计算机执行指令，使得所述处理器执行如权利要求2-8中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序或指令，当所述计算机程序或指令被运行时，实现如权利要求2-8中任一项所述的方法。