相关申请的交叉引用
本申请要求于2020年1月10日提交的意大利申请号102020000000319的权益，其申请内容在此通过引用并入本文。
本说明书涉及语音控制系统和方法，并且在特定的实施例中，涉及摩托车语音控制系统和方法。
背景技术：
在摩托车(摩托)市场中仍然广泛流行的方法是考虑手动控制摩托车仪表盘：即，摩托车骑手使用他或她的一只手来控制仪表盘，这几乎不可避免地涉及临时松开或至少更换抓握车把。
尽管很有吸引力并且被需要，但是实现摩托车仪表盘控制的语音识别系统提出了待解决的各种问题和方面，诸如：
在操作期间可能进入麦克风的高噪声水平，
高cpu负载(这表明使用强大的soc)，
预计配备摩托车手的头盔的免提设备的电池持续时间可能减少，
可能与一些区域中缺少网络连接有关，对高级服务的访问减少(或者根本没有访问)，在缺少连接的情况下没有备用解决方案。
技术实现要素：
一个或多个实施例的目标是协助解决这种问题，因此有助于实现可靠的用于摩托车仪表盘控制的语音识别系统。
根据一个或多个实施例，该目标可以借助具有下文提出的权利要求中的功能的系统来实现。
一个或多个实施例可以涉及对应的摩托车。
一个或多个实施例可以涉及对应的摩托车手(摩托车驾驶员)的头盔。
一个或多个实施例可以涉及对应的方法。
权利要求是关于本文例示说明的实施例提供的技术教导的组成部分。
一个或多个实施例提供了基于hw/sw的解决方案，该解决方案可以包括与摩托车车载控制单元(例如，仪表板)组合的“智能”头盔，能够不管网络联机状态如何而提供语音命令，具有使用本地语音识别引擎和基于云的语音识别引擎二者的能力，这可以导致具有成本效益的系统。
一个或多个实施例可以提供混合的解决方案，这有助于在存在或不存在网络可用性的两种情况下操作这种控制单元。
在一个或多个实施例中，系统操作可以由于借助简单语言检测过程检测的语音命令而触发，这可以减少cpu负载，并且因此减少在智能头盔侧上的电池消耗。
一个或多个实施例可以依赖于语音命令，以便更容易地渲染仪表盘控制(对用户更友好)，同时减少cpu使用，这可以导致在智能头盔中电池的持续时间增加。
在一个或多个实施例中，减少的cpu负载可以涉及到醒和触发系统，这是由于第一滤波动作旨在检测在噪音中存在语音。
例如，这可以通过在如下所述的微控制器或微处理器设备上运行涉及约2mips的语音检测过程来发生。
尽管主要有利于头盔安装的布置，但是这还可以有益于安装在摩托车上的控制单元(例如，仪表板)。
一个或多个实施例可以有效地应用于摩托车市场的低成本数字仪表控制系统和高端数字仪表控制系统(例如，仪表板)二者。
一个或多个实施例可以有助于在存在网络可用性的情况下访问基于云的服务，同时还可以有助于多用户交互。
一个或多个实施例可以提供控制系统，其中摩托车的车载控制单元(例如，仪表板)(如下所述，该设计旨在还应用于诸如小型摩托车或摩托自行车的两轮或三轮车辆)可以接收来自用户的语音命令。如本文例示的，该系统可以包括处理器(例如，微控制器)，经由一个或多个无线通信模块(例如，蓝牙)与安装在用户的头盔上的耳机(也配备有无线通信模块)通信。该处理器还经由无线通信模块(例如，智能电话)与网络(诸如互联网)通信，以便执行涉及云服务的功能。
可选择地，该系统还可以与摩托车安装的麦克风协同操作(例如，这仅可以在摩托车没有被驾驶/运行时操作)。
在一个或多个实施例中，经由安装在摩托车手的头盔上的处理器(例如，微控制器/微处理器)的语音检测(仅)可以在检测到语音活动时激活无线传输。
在一个或多个实施例中，这种头盔安装的处理器可以执行一个或多个“唤醒词”的识别过程，(仅)由于这种识别过程的肯定结果而对摩托车安装的处理器进行传输。
因此，基于在头盔处处理的这种语音活动和/或唤醒词的识别，一个或多个实施例可以避免不必要的传输活动，因此有益于能量节约以及延长头盔电池资源的使用寿命。
在一个或多个实施例中，语音命令识别(解释)可以经由在摩托车安装的处理器中实现的“本地”过程和/或经由网络(例如，云)资源而发生，命令解释可能在不存在网络可用性的情况下在本地发生。
在一个或多个实施例中，在存在可用的网络资源的情况下，识别可以以两种方式执行(例如，本地或经由云)，第一(较早的)识别结果可以用于控制目的。
附图说明
现在将仅通过示例，参考附图来描述一个或多个实施例，其中：
图1是根据本说明书的实施例的系统的总体功能图；
图2是根据本说明书的可能的实施例的示例的框图；
图3是根据本说明书的可能的实施例的示例的另一框图；
图4是根据本说明书的可能的实施例的示例的又一框图；
图5是可以应用于根据本说明书的实施例的可能的变型的示例的框图；以及
图6至图8是示出了充当将智能设备与摩托车头盔并联连接的桥的摩托车处理器的框图。
具体实施方式
在以下说明书中，给出了各种具体细节来提供对本说明书的各种示例性实施例的彻底的理解。实施例可以在没有一个或多个具体细节的情况下或者用其他方法、部件、材料等来实践。在其他实例中，没有详细示出已知的结构、材料或操作，以避免混淆实施例的各种方面。整篇说明书中对“一种实施例”或“一个实施例”的引用意味着结合实施例描述的特定的功能、结构或特征被包括在至少一个实施例中。因此，短语“一种实施例”或“一个实施例”可以出现在整篇说明书中的各种地方，并且不一定全都是指同一实施例。此外，特定的功能、结构或特征可以在一个或多个实施例中以任何适当的方式组合。
本文提供的标题/引用仅为了方便，并且因此不解释实施例的保护范围或范围。
例如，一个或多个实施例可以应用于摩托车语音控制系统。
如本文所使用的，名称“摩托车”将应用于适合由驾驶员(摩托车手，通常戴头盔)骑行的自行式两轮或三轮机动车，不考虑摩托车设计中可能存在的各种变化，以适应各种不同的用途。
如本文所使用的，不考虑某一车辆是否符合某个国家或司法管辖区当前适用的法律/法规，因此摩托车的名称均适用。小型摩托车或摩托自行车可以作为本文所使用的摩托车的名称下的车辆的示例。
图1是根据本文例示的实施例的(混合动力)摩托车语音控制系统10的总体示例性视图。
如图1中例示，系统10包括处理电路装置100，处理电路装置100适用于并且被配置为(以本领域技术人员已知的方式)安装在摩托车(摩托)mb上，具有与以下项通信的能力：
由骑摩托车mb的摩托车手佩戴的至少一个“智能”头盔sh：这可以经由无线模块200(例如，蓝牙bt)与装备头盔sh的对应的模块200a进行；如下文所讨论的，可能与由摩托车mb的另一摩托车手(对摩托车mb的另一用户配置的语音控制的可能“量身定制”)或者甚至乘客佩戴的另一智能头盔sh2的可能的通信可以在一个或多个实施例中被考虑；
移动通信设备ue支持数据通信并且提供对网络资源(诸如互联网资源)的访问，例如(如下文所讨论的云数据存储和计算是这种资源的示例)；在一个或多个实施例中，网络连接可以使用智能电话(摩托车手佩戴的智能电话可以是如图1中ue例示的这种设备的示例)作为与无线模块(诸如bt模块200或wifi设备)合作的桥来实现。
在一个或多个实施例中，如本文例示的系统100的操作可以由处理电路装置100充分支持，诸如可以利用意法半导体集团的公司商业可用的accordotm系列的设备(参见st.com)。
此外应该理解的是，在整篇说明书中，对accordotm设备的引用仅用于示例性目的：事实上，一个或多个实施例本身适用于在当前在市场上可获得的各种微控制器(mcu)/微处理器(mpu)平台上实现。
因此，尽管有益于理解实施例，但对accordotm设备的重复引用不应该被理解为(即使是间接地)实施例的限制意义。
accordotm设备是为现有汽车无线电系统提供具有成本效益的微处理器解决方案的设备系列，包括mips高效双核32位arm，包括cortex-r4(图1中的101)以及cortex-m3(图1中的102)处理器能力，armcortex-m3控制器102专用于基于can(图1中的103)的实时车辆接口处理，能够与在车辆(诸如摩托车或托管设备100的摩托车mb)中的电子控制单元(ecu)连接。
嵌入式sram、音频adc和dac(参见图1中的104和105，例如具有支持传感器s(诸如温度、光照或电池充电传感器)的操作的能力)、用于车载无线电和显示音频应用的独立canmcu和嵌入式强大的数字声音处理(图1中的dsp-106)子系统是accordotm系列设备的进一步的有利的功能。
如图1中例示，这些设备还包括诸如一组详尽的公共接口，例如：
uart107和uart108，能够支持在线路lin上与在摩托车mb的车把hb处的车把按钮和操纵杆进行线路通信，
i2s，109，
usb，110
视频输入接口111，
clcd/tsc显示接口112，例如被配置为：经由相关联的2-2.5d存储器布置112a与摩托车mb的仪表盘显示单元d协作，
gpio(通用输入/输出)接口113，例如能够支持装备摩托车mb的led指示器tt(制动，低油位)。
这有助于实现功能丰富的系统以及成本效益的解决方案，该解决方案由完整的软件包支持，允许非常快速的系统实现方式。
因此，accordotm系列设备是适用于管理从模拟输入或数字输入到模拟输出或数字输出的整个音频链的设备的示例，包括数字音频介质解码、各种源之间的采样率转换、智能路由和音频效果/dsp后处理，具有支持基于实时os的低成本系统以及扩展到基于linuxos的高要求应用二者的能力。
总而言之，accordotm设备(诸如，例如，两个设备的组合，accordo2和accordo5)可以具有显示/图形能力、介质和车辆连接能力、以及音频功能，这有助于它们在用于摩托车(包括先前讨论的各种类型的2轮和3轮车)的数字仪表应用中使用。
这可能是由于以下功能造成的，诸如：
管理可视化人机接口(hmi)的能力；
与可用移动设备的连接性；
适用于与车辆(诸如摩托车)连接的车辆接口；
(三个)集成dsp的可用性，最初设计用于音效和擦除码(ec)以及降噪(nr)加速；
从传统头盔接收声音输入的能力，该头盔配备蓝牙通信(市场上已经可获得的)并且与低噪声条件兼容，以及从摩托车中嵌入的本地麦克风接收声音输入的额能力(这种麦克风目前已经用于安全目的，例如有助于紧急呼叫)。
图2至图5是结合图1所讨论的系统10的各种可能实施例的框图示例，其中处理/操作功能以不同的方式被分配到单元100(例如，accordotm设备)。
事实上，在其他实施例中被分配到单元100的某些处理/操作功能可以被分配到其他元件，诸如一个或多个(图4)智能头盔sh、sh2旨在由骑乘同一辆摩托车(诸如mb)的摩托车手在不同时间以可能不同的使用(控制)配置来穿戴。
图2是实施例的示例，其中结合图1所讨论的系统10的处理/操作功能几乎全部被分配到单元100(适用于用先前讨论的accordotm设备实现)，单元100以本领域的技术人员已知的方式安装到在图1中所示的摩托车上(图2至图5中不可见)。
如图2中例示的实施例是系统10的示例，系统10被配置为在“传统”场景下与配备麦克风mic和/或摩托车安装的麦克风mic2的“智能”摩托车手头盔sh结合操作(例如，这仅可以在摩托车未驾驶/运行时操作)，利用在智能头盔中的麦克风mic和/或麦克风mic2能够收集声音消息，例如由摩托车手发出的声音。
例如，如上文所讨论的，这种配备麦克风mic和/或麦克风mic2的头盔目前已经用于安全目的。因此，它们可以被视为摩托车mb的“传统”设备，摩托车mb可能旨在用如本文所讨论的单元100来改装，以便提供根据实施例的语音控制系统。
在如图2中例示的实施例中，单元100可以配备有接收器模块200rx(例如，蓝牙，参见图1中的108、109)以从配备麦克风的智能头盔sh中的同源发射器模块200a和/或从麦克风mic2接收声音消息。如上所述，目前已经使用这种具有相关联的麦克风mic和发射器/接收器模块(例如，蓝牙)的头盔sh，这使得本文不需要提供更详细的描述。
在一个或多个实施例中，不管源是配备麦克风的智能头盔sh还是麦克风mic2，由摩托车手发出的声音消息都可以作为音频流在(混音)节点处被提供给语音活动检测模块302。
这里，可以通过语音活动检测过程来分析音频流，因此有助于检查(如由框304例示)是否检测到语音信号。在后一种情况下(来自304的否定结果n)，系统重新循环到语音活动检测模块302上。
在一个或多个实施例中，语音活动检测过程可以是本领域的技术人员已知的任何类型，可以提供减少cpu使用的功率优化操作。
框306(在304处，系统由于肯定结果y而发展)是可能使用唤醒词引擎(同样是已知类型的)来检测关键词(例如：“alexa”、“siri”、“okgoogle”)以启动语音命令处理的示例。
在306处的唤醒词处理有助于检查(如框308例示)是否检测到唤醒词。在没有检测到唤醒词的情况下(来自306的否定结果n)，系统发展到exit状态。
框310(在308处，系统由于肯定结果y而发展)是对网络连接(例如，互联网)当前是否可用而进行的检查的示例：这可以经由蓝牙200和设备ue(例如，智能电话、热点等)进行。
作为在310处执行的网络可用性的检查的结果，以下请求被发送：
在否定结果n的情况下，在310处(网络不可用)将请求发送到本地语音识别引擎(例如，命令解释器)312；以及
在肯定结果y的情况下，在310处(网络可用)将请求发送到基于网络的语音识别引擎(例如，云命令生成器)314。
在前一种情况(本地引擎)下，在316处是否识别命令的检查被执行。
在316处的否定结果n将会使系统导向exit状态。
相反地，在316处的肯定结果y将会导致对应的动作(立即)被落实。这可以经由汇聚节点318导致控制模块320(例如，图1中的112和113中的任何一个)的激活，这导致在显示器d或任何led指示器tt处，可能地经由发射器模块200tx(例如，诸如蓝牙发射器模块)激活所需的某些功能。
诸如更改页面、示出范围、示出电池充电水平、激活到头盔的音频等功能(仅举几例)，是这种可能的经激活的动作的示例。
在310处考虑的后一种情况(网络连接可用)下，音频命令可以在云命令生成器314处被编码，并且可以使用在图1中例示的网络连接(例如，bt模块200、智能电话、热点)向基于网络的命令识别资源(诸如基于云的命令识别引擎)发送音频命令。
因此，命令识别可以在由c指示的云水平处执行，与本地引擎(诸如312)相比，这可以需要更精密的识别/分类能力。
与基于云的引擎相比，本地引擎(诸如312)可以(仅)寻址命令的子集，例如：
集群页面管理(移动到诊断页面、移动到导航页面、移动到后视相机页面，…)，
信息娱乐特征的激活(电话、接收到的sms或im的语音……)。
通过比较，适用于经由314和200到达的基于云的引擎除了可以管理由本地引擎管理的那些命令外，还可以管理附加命令，例如：
检索信息(交通、天气、新闻，…)，
外部实体的控制，
连接门管理，
智能家居和其他设备。
在319处检查从网络(例如，云c，可以再次经由如图1中例示的bt模块200、智能电话、热点等……)接收到的关于命令是否在云水平c处被识别的响应。
在319处的否定结果n将会再次将系统导向exit状态。
相反，在319处的肯定结果y将导致对应的动作(立即)被落实。
这可以再次经由如上文所讨论的汇聚处理节点318、控制模块320以及发射器模块200tx，例如，在网络(云)水平更强大的命令识别的附带条件可以导致更广泛和更精密的范围的动作被适配为语音控制。
图3和图4是实施例的示例，其中在图2中例示的实施例中分配给单元100的某些处理/操作功能可以被“移动”到其他元件(诸如一个或多个智能头盔sh、sh2)。
因此，在图3和图4(以及图5)中的部件、元件或功能，与已经结合图1和图2描述的部件、元件或功能类似，将用类似的附图标记表示，并且为了简洁起见，这些部件、元件或功能的描述将不再重复。
图3是实施例的示例，其中由于在智能头盔(诸如sh)处以本领域的技术人员已知的方式增加了的处理能力，因此经由adc转换器301在如302和304处再次例示的头盔sh处，对头盔水平数字化的语音信号执行语音活动检测处理(例如，涉及约2mip)，该处理经由adc转换器301，adc转换器301提供由头盔安装的麦克风mic提供的语音信号的数字转换(为简单起见，在图3和图4中假设存在单个头盔安装的麦克风，其中可能安装在摩托车上的麦克风mic2不可见)。
这种方法可以证明有利于减少头盔电池消耗，因为避免了从头盔发射器200a到在单元100中的接收器200rx的不必要的连续信号流(例如，bt)：事实上，只有被检测为语音(304的结果＝y)的音频可以从发射器200a流到接收器200rx。
在如图3中例示的实施例中，在单元100(摩托车侧)中执行的第一处理因此是唤醒词引擎306，随后的处理和活动如先前结合图2所讨论的那样发生。
图4是在两个方向上的实施例的进一步发展的示例：
多用户操作，即头盔控制操作，可能扩展到两个或多个智能头盔sh，sh2(为了简单起见，这里仅举例两个)，例如，可以是不同的摩托车手在不同时间驾驶同一辆摩托车(诸如mb)时佩戴的头盔可以具有不同的使用(控制)配置，
进一步扩大了以智能头盔水平执行的处理的范围/复杂度。
还应该理解的是，沿着如图4中例示的两个方向的开发可以独立进行。
即，在一个或多个实施例中：
如图4中例示的多用户操作可以应用于如图2和图3中例示的系统布局，
类似地，在图2和图3中例示的系统布局上，以智能头盔水平执行的处理范围/复杂性的进一步扩大可以如图4中例示的那样执行，而不需要提供多用户操作。
在后一方面(即，不管是否考虑多用户操作)，在如图4中例示的一个或多个实施例中，除了语音检测处理302、304之外，在306、308处的唤醒词处理也在头盔sh和/或sh处运行。这可进一步降低头盔处的电池消耗，因为在200a与200rx之间的通信活动(例如，蓝牙)被限制于被识别为包含某些唤醒词的语音消息。
这种情况可以有助于实现多用户活动，因为来自不同头盔(诸如sh和sh2)的音频流可以以互斥的方式选择，例如通过针对不同用户考虑不同唤醒词(具有不同唤醒词的多用户)。
在如图4中例示的实施例中，因此在单元100(摩托车侧)中执行的第一处理是在310处执行的对网络可用性的检查，随后的处理和活动如先前结合图2所讨论的那样发生。
图5是可以有助于获得对语音命令的更快响应的实现方式的示例。
在结合如图2中例示的系统布局例示的同时，图5的实现方式还可以应用于如图3和图4中例示的布局(实现或不实现多用户选项)。
此外，在图5中，已经结合先前附图描述的部件、元件或功能的部件、元件或功能用类似的附图标记表示，而不重复这些部件、元件或功能的详细描述。
简要地说，在如图5中例示的实施例中，在312和316处激活本地语音处理不再依赖于在310处执行的网络可用性测试的结果。
在如图5中例示的实施例中，命令被转发用于并行处理两条路径，即在312和316处的本地引擎以及经由314的基于云的引擎c。
在如图5中例示的实施例中，(仅)在后一路径上的处理(例如，在314处的云命令生成器处理)可以以在310处执行的网络可用性测试为条件，系统将进行到exit，在314处不执行任何处理，并且不试图传输到不可用的网络。
如图5中例示的实施例的操作可以基于考虑到后续处理和活动而(例如，在节点318处)选择先前接收到的识别响应(即，首先接收到的识别响应)的标准，。这可以来自312和316处的本地引擎，或者可以来自经由314的基于云的引擎c，具有丢弃从另一引擎接收到后续响应的可能。
这种方法可以有助于获得对语音命令更快的响应。
例如，在存在由本地引擎312(快速)识别的命令的情况下，可以立即执行对应的动作，而无需等待相同命令的(也)可能基于云的识别。
在不存在由本地引擎312识别的命令的情况下，可以依赖更精密的基于云的识别设备(如果可用)。
结合上述实施例或者上述实施例的一些方面的备选方案，图6至图8示出了将智能设备(例如，智能电话、智能手表等)sd与头盔sh并联连接的摩托车处理器100。在这种情况下，如果摩托车处理器100没有配备远程网络启用系统，则智能设备sd可以提供到云c的互联网连接。然后，摩托车处理器100充当在头盔sh与智能设备sd之间的桥。
如图6中所示，关于头盔-摩托车通信，头盔sh将会将摩托车处理器100“视为”标准智能设备，并且利用标准通信协议(bt配置，诸如a2dp、hfp等)。为了从头盔sh获得连续音频流，处理器100可以使用蓝牙免提配置(bthfp)将假呼叫转发到将打开双向音频流的耳机。从摩托车到头盔的音频流可以用于标准用途(音频呼叫)和自定义用途(命令、响应、系统消息等)二者。
关于智能设备-摩托车的通信，智能设备sd可以向摩托车处理器100提供互联网连接。摩托车被“视为”在本地网络中的节点。
如图7中所示，在自定义智能头盔csh的情况下，与摩托车处理器100的通信可以利用能够递送专用服务的自定义通信来增强(例如，仅针对命令打开音频流、发送加速计测量值等)。
如图8中所示，再次关于智能设备-摩托车的通信，具有专用软件(例如，app)的智能设备sd-da还可以与摩托车集成，以提供增强的服务。这些服务可以包括更好的本地语音识别系统(智能设备通常比摩托车处理器具有更多的资源)、信息提供(天气、新闻等)、信息收集(数据记录、诊断等)、固件更新等。
应该理解的是，尽管在各个方面有利，但语音活动检测(如图中302、304处例示)和/或唤醒词检测(如图中306、308处例示)可以不是实施例的强制性特征。不管是在摩托车mb上(例如，在仪表板处)实现还是在“智能”头盔sh、sh2上实现，这都适用。
类似地，尽管如本文例示的实施例可以有利地实现(在摩托车mb上和/或在智能头盔sh、sh2中)语音活动检测(302、304)和唤醒词检测(306、308)二者，以便减少向命令识别功能(本地和/或基于网络)的信号传输，一个或多个实施例甚至可以仅提供正在被实现的那些功能中的一个功能，以便减少向命令识别功能的信号传输。
如本文中例示，用于摩托车(例如，mb)仪表盘语音控制系统(例如，10)可以包括：
接收器电路装置(例如，200rx、300)，被配置为接收语音生成的信号(例如，由mic、mic2提供)，
命令识别电路装置(例如，312、316；314、319)，被配置为从在接收器电路装置处接收到的语音生成的信号中识别出用于摩托车仪表盘的语音生成的命令信号，
命令实现电路装置(例如，320、200tx)，被配置为根据由命令识别电路装置识别的语音生成的命令信号，实现摩托车仪表盘的动作(例如，d、tt)，
其中命令识别电路装置包括：
(本地)命令识别电路(例如，312)，位于朝向命令实现电路装置的第一信号传播路径(例如，312、316、318)中，该命令识别电路被配置为向命令实现电路装置提供由命令识别电路识别的语音生成的命令信号，
网络连接接口(例如，200)，位于朝向命令实现电路装置的第二信号传播路径(例如，314、200、319、318)中，该网络连接接口被配置为：
将语音生成的信号传输到基于网络的语音生成的命令信号识别设备(例如，c)，
从基于网络的语音生成的命令信号识别设备接收，并且向命令实现电路装置提供由基于网络的语音生成的命令信号识别设备识别的语音生成的命令信号。
如本文中例示的摩托车仪表盘语音控制系统可以包括网络可用性节点(例如，310)，该网络可用性节点被配置为检查基于网络的语音生成的命令信号识别设备的可用性，并且由于基于网络的语音生成的命令信号识别设备被检查为不可用(例如，310＝n)，而抑制语音生成的信号朝向网络连接接口传输。
如本文中例示的摩托车仪表盘语音控制系统可以包括网络可用性节点，该网络可用性节点被配置为由于基于网络的语音生成的命令信号识别设备被检查为可用(例如，310＝y)，而抑制语音生成的信号朝向命令识别电路的传播。
在如本文中例示(参见图5)的摩托车仪表盘语音控制系统中，在命令识别电路装置中的第一信号传播路径可以绕过网络可用性节点(310)，其中不管基于网络的语音生成的命令信号识别设备的可用性如何，第一信号传播路径(312、316、318)是打开的(即，提供或有助于)，以将语音生成的信号朝向命令识别电路传播。
如本文中例示的摩托车仪表盘语音控制系统可以包括唤醒词处理电路装置(例如，306、308)，该唤醒词处理电路装置被配置为检测在接收器电路装置处接收的语音生成的信号中至少一个唤醒词的出现，并且(例如，在308处)除了检测到至少一个唤醒词出现的那些语音生成的信号以外，抑制向命令识别电路装置转发语音生成的信号。
如本文中例示的摩托车仪表盘语音控制系统可以包括语音活动检测电路装置(例如，302、304)，该语音活动检测电路装置被配置为检测在接收器电路装置处接收的信号中的语音生成的信号的出现，并且(例如，在304处)除了检测到语音生成的信号出现的信号以外，抑制向命令识别电路装置转发在接收器电路装置处接收的信号(例如，噪声)。
如本文中例示的摩托车仪表盘语音控制系统可以包括语音活动检测电路装置，该语音活动检测电路装置被布置在唤醒词处理电路装置上游，其中语音活动检测电路装置被配置为(例如，在304处)除了检测到语音生成的信号出现的信号以外，抑制向唤醒词处理电路装置转发在接收器电路装置处接收的信号。
在本文中例示的摩托车仪表盘语音控制系统中，接收器电路装置(例如，200rx)可以被配置为从多个源(例如，sh、sh2)接收语音生成的信号，可选择地从多个源中的一个源(sh，相应地为sh2)接收语音生成的信号而不从多个源中的另一个源(sh2，相应地为sh)接收语音生成的信号。
如本文中例示的仪表盘语音控制系统可以用于装配(可能通过改装)如本文中例示的摩托车(例如，mb)。
如本文中例示的摩托车头盔(例如，sh、sh2)可以包括(例如，参见图2至图6的所有图)：
麦克风(例如，mic)，对在头盔处的语音活动敏感，该麦克风根据语音活动生成语音生成的信号，
发射器电路(例如，200a)，被配置为向如本文中例示的仪表盘语音控制系统中的接收器电路装置(例如，200rx)传输语音生成的信号。
如本文中例示的摩托车头盔(例如，参见图3)可以包括语音活动检测电路(例如302、304)，该语音活动检测电路被配置为检测由麦克风根据语音活动而产生的语音生成的信号的出现，并且在由语音活动检测电路装置检测到的由麦克风产生的语音生成的信号不存在的情况下，抑制从发射器电路传输。
如本文中例示的摩托车头盔(例如，参见图4)可以包括唤醒词处理电路装置(例如，306、308)，该唤醒词处理电路装置被配置为检测由麦克风产生的语音生成的信号中至少一个唤醒词的出现，并且除了检测到至少一个唤醒词出现的由麦克风产生的那些语音生成的信号以外，抑制由麦克风产生的语音生成的信号从发射器电路传输。
在如本文例示的摩托车头盔中(例如，再次参见图4)，语音活动检测电路装置可以被布置在唤醒词处理电路装置上游，其中语音活动检测电路装置被配置为，在由语音活动检测电路装置检测到的由麦克风产生的语音生成的信号不存在的情况下，抑制向唤醒词处理电路装置转发信号。
如本文中例示的控制摩托车仪表盘的方法可以包括：
接收(在摩托车处的)语音生成的信号，包括用于摩托车仪表盘的语音生成的命令信号，
从接收到的语音生成的信号中识别出用于摩托车仪表盘的语音生成的命令信号，
提供命令实现电路装置，以根据由命令识别电路装置识别的语音生成的命令信号实现摩托车仪表盘的动作，
其中识别语音生成的命令信号可以包括：
提供命令识别电路，该命令识别电路在位于朝向命令实现电路装置的第一信号传播路径中，该命令识别电路被配置为向命令实现电路装置提供由命令识别电路识别的语音生成的命令信号，
提供网络连接接口，该网络连接接口位于朝向命令实现电路装置的第二信号传播路径中，并且激活网络连接接口以：
将语音生成的信号传输到基于网络的语音生成的命令信号识别设备，
从基于网络的语音生成的命令信号识别设备接收、并且向命令实现电路装置提供由基于网络的语音生成的命令信号识别设备所识别的语音生成的命令信号。
如本文中例示的方法(例如，参见图5)可以包括：
激活朝向命令实现电路装置的第一信号传播路径和第二信号传播路径二者，其中语音生成的命令信号被识别为：
在第一信号传播路径和第二信号传播路径中的仅一条路径处(例如，由于网络/云资源不可用或者本地识别器无法识别某些语音生成的命令)，或者
在第一信号传播路径和第二信号传播路径中较快的一个路径(例如，本地识别器312)处，早于在第一信号传播路径和第二信号传播路径中较慢的一个路径(例如，基于云的识别器c)处，以及
根据由第一信号传播路径和第二信号传播路径中仅一条路径或较快的一个路径所识别的语音生成的命令信号，实现摩托车仪表盘的动作。
在不背离保护范围的情况下，细节和实施例可以仅通过示例而关于本文已经公开的内容而变化。
保护范围由所附权利要求确定。
本文用于企业家、创业者技术爱好者查询，结果仅供参考。
