μPoly：首个微手势工具包

《Proceedings of the ACM on Human-Computer Interaction》：μPoly: a First Microgesture Toolkit

　　**摘要**

随着微手势研究的迅速发展，出现了许多具有不同传感器（例如力敏感传感器、IMU）、外形因素（例如手套、戒指）和识别算法（例如特定算法、随机森林）的识别设备。随着识别设备的数量和多样性的增加，能够轻松地在设备之间切换和/或修改可识别的微手势集变得非常重要。为了解决这些挑战，我们提出了μPoly，这是一个基于μGlyph微手势表示法的第一个微手势工具包。μPoly以μGlyph描述的基本微手势作为输入，将这些输入组合起来以识别使用μGlyph描述的复杂微手势。因此，μPoly为微手势事件提供了一个标准。μPoly的设计基于从工具包文献中提取的属性。为了突出这些属性，我们展示了（1）实践者如何在四种场景中使用该工具包，并报告了用户测试结果；以及（2）如何使用μPoly开发应用程序。

**AI摘要（实验性）**

此摘要是使用自动化工具生成的，并非由文章作者编写或审核的。它旨在帮助发现、帮助读者评估相关性，并协助相关研究领域的读者理解该工作。它旨在补充作者提供的摘要，后者仍然是论文的权威版本。点击此处了解详细信息。点击此处对摘要的准确性、清晰度和实用性发表评论。这样做将有助于改进和未来重新生成的版本。要查看此由AI生成的白话文摘要，您必须具有高级访问权限。

**图1. μPoly的概述。**
A) 传感器可以通过不同的通信协议连接到μPoly。
B) 指定的驱动程序将传感器的原始数据转换为低级事件，即使用μGlyph标准描述的基本微手势。
C) 这些事件随后被输入到识别器中。每个识别器都是实现为状态机的μGlyph描述。
D) 被识别的事件随后传输给连接到其中的客户端应用程序。
F) 在示例中，只有第三个传感器被连接。执行了一个释放微手势（??°）。该微手势触发了绿色信号的传播，导致灯光和音乐开启。

**1 引言**

基于微手势的交互研究领域的扩展，已经出现了许多用于检测和识别快速而微妙的手指运动的系统，这些运动被称为微手势。得益于这些新系统，基于微手势的新交互技术已经被设计并测试。特别是，微手势可以在各种环境中实现交互，例如混合现实[9]或移动车辆[16]，无论是否持有所持物体[7, 47]。随着传感器设备和识别算法种类的增加，找到和测试特定环境中最佳的系统变得更加困难。

微手势识别系统在传感器设备和识别算法方面存在很大差异。传感器设备配备了不同的传感器（例如力敏感传感器[52]、IMU传感器[47]、摄像头[45]）和不同的外形因素（例如手套[18, 52]、戒指[6, 51]、手环[14, 43]），而识别算法则采用不同的方法（例如基于阈值的[18, 52]、SVM[6, 53]、随机森林[23, 24]）。每种方法都有其优点和局限性。例如，一些运动跟踪系统可以准确跟踪手指关节，但需要多个摄像头和带有跟踪点的手套[45]。然而，这种检测方式在日常使用中既不实用也不环保。相反，手环似乎更为合适，因为它可以集成到智能手表表带中[4, 14]。然而，这种方法提供的可用传感器数量有限，从而减少了可识别微手势的数量。除了众多的提出的识别系统之外，当前关于微手势的文献还通过进行启发式研究[5, 11, 46, 50, 55]、建立设计空间[10, 25, 48]以及设计和评估基于微手势的交互技术[9, 19, 52, 54]来探索和构建微手势的可能性空间。然而，随着越来越多的研究创建和评估基于微手势的交互技术[9, 19, 52, 54]，设计师和研究人员需要在找到最合适的系统之前测试不同的微手势集以及不同的传感器设备和/或识别算法。尽管有这样的需求，但由于缺乏微手势识别系统的标准以及缺乏快速原型制作和探索的工具，微手势研究的进展受到了阻碍[37]。

为了解决这一挑战，我们提出了μPoly，这是一个为设计师和研究人员设计的微手势识别工具包，旨在降低微手势交互的入门成本和探索难度。μPoly是一个基于状态机的工具包，这些状态机由低级事件驱动。这些低级事件基于最近引入的微手势表示法：μGlyph[10]。μGlyph通过将微手势分解为基本微手势（即具有微手势执行器等属性的生物力学运动）来描述微手势。这些μGlyph基本微手势被用作μPoly中的低级微手势事件的标准。遵守μGlyph标准对于识别系统事件的格式是μPoly的一个核心特性，使得能够轻松且无缝地测试不同的传感器设备和识别算法。这种方法类似于不同鼠标产生任何计算机都能识别的相同鼠标事件的方式。这些低级事件可以组合起来描述更复杂的微手势。为此，μPoly依赖于如图1所示的实现为状态机的μGlyph描述。状态机使我们能够探索大量多样化的微手势集。它们还提供了极大的灵活性，使得修改可识别的微手势集变得更加容易。最后，由于状态机描述了微手势的μGlyph描述，μPoly可以与μGlyph网站μDex[8]一起使用。这允许用户使用文本描述、图像或文章元数据在μDex上搜索微手势，然后简单地将微手势的μGlyph描述复制并粘贴到μPoly中。因此，无论是专家还是初学者都可以使用μPoly和μGlyph形式主义。

本文的主要贡献包括：
- μPoly，一个用于微手势接口设计和快速原型制作的工具包，其识别微手势的延迟比执行微手势本身快两个数量级；
- 七个驱动程序，涵盖了传感器、外形因素和识别算法方面的多样性，以及五个特色应用程序，以展示μPoly的可用性、灵活性和能力。

**2 相关工作**

据我们所知，目前尚不存在专门的微手势工具包。然而，已经存在多种微手势识别系统。我们的相关工作首先涵盖了这些微手势识别系统的多样性，并从三个方面进行了研究：传感器类型、设备外形因素和识别算法。然后，我们介绍了如何使用形式语言对输入（特别是微手势）进行建模。最后，我们提出了文献中关于设计有效工具包的指南。

**2.1 微手势识别系统的多样性**

在设计微手势识别系统时，需要做出三个选择：1）使用的传感器类型；2）这些传感器的放置位置和方式；3）用于处理这些传感器输出的商业算法类型。表1概述了本相关工作中介绍的不同微手势识别系统。

**2.1.1 传感器**

微手势由一系列基本生物力学运动组成，例如弯曲、伸展、外展和内收，这些运动可以在接触表面或不接触表面的情况下进行[10]。根据这种微手势分解，传感器可以分为两类。组件传感器可用于识别微手势的特定组成部分，例如基本生物力学运动和/或接触信息。此类传感器包括弯曲传感器[52]（手指运动）、点接触传感器[18, 19, 48]（接触）、线性接触传感器[18, 52, 54]（接触+接触中的运动）或力传感器[52, 54]（接触+力信息）。相比之下，表达传感器可以在不需要独立识别每个组成元素的情况下识别微手势。此类传感器包括摄像头[29, 33, 45, 48]、雷达[23, 32]、IMU传感器[15, 47]、生物阻抗传感器[51]、生物声学传感器[14, 24]或EMG传感器[42, 43]。

**2.1.2 传感设备的外形因素**

传感器已被集成到具有各种外形因素的传感设备中。就像在三种增强现实方法[34]中一样，这些设备可以增强用户、持有的物体或环境。在用户增强方面，已经研究了不同的外形因素。手套——它们便于将传感器放置在感兴趣的区域，如指节或特定关节上。然而，手套具有侵入性，会覆盖手的皮肤表面，从而降低用户的触觉感知。通过在使用连指手套等妥协方案来缓解这一问题，并决定可以连接到手套上的传感器数量。在研究中，手套经常被用作微手势交互研究的临时原型[18, 45, 52, 54]，因为它们比其他解决方案更容易构建。外骨骼——它们允许将传感器放置在手的背面，从而减少设备对用户触觉感知的影响。这种类型的设备可以使用的传感器数量有限。例如，接触传感器和压力传感器不能放置在手的背面。在文献中，这种设备通常与IMU[15, 47]一起使用。手环——它们提供了轻量且侵入性较小的设备。它们似乎是Meta[17]和Apple[4]设想的用于微手势识别的外形因素。在文献中，它们与生物声学传感器[14]、EMG传感器[43]、雷达[23]以及摄像头[53]一起使用。戒指——它们也提供了轻量且侵入性较小的设备。在文献中，它们与线性接触传感器[6]、生物阻抗传感器[51]和摄像头[12]一起使用。

**2.1.3 识别算法**

文献中可以识别两种主要方法：特定算法和机器学习算法。通过战略性地在手背上放置微手势组件传感器，可以将传感器值与μGlyph符号经验性地关联起来。这种特定算法已经与压力传感器和弯曲传感器[52]以及接触传感器[18]一起使用。

第二种方法是使用机器学习算法。这种方法也可以与微手势组件传感器一起使用。例如，Nailz使用用户指甲上的接触传感器[31]。这些传感器用于构建拇指和指甲之间接触的图像，然后使用简单的决策树对这些图像进行分类。在大多数情况下，由于收集了大量信息，这种机器学习方法与微手势表达传感器一起使用。Soliman等人使用卷积神经网络与RGB-D摄像头[48]一起进行检测。Saponas等人首先使用信号处理从EMG传感器提供的信号中提取特征，然后使用支持向量机[42, 43]。SoloFinger最初使用TsFresh[13]从红外相机系统接收的信号中提取特征，然后使用随机森林对信号进行分类和识别微手势。

在这两种情况下，文献中的大多数算法仅使用来自传感器的数据来识别微手势。然而，在某些情况下，可以使用额外的信息。例如，TipText在食指尖端使用接触传感器矩阵创建了一个一键式QWERTY键盘[56]。由于拇指的宽度和键的大小之间的差异，这使得用户会同时按下多个键。因此，TipText使用点接触传感器矩阵和统计解码器将输入的键序列与词典中的单词关联起来，以纠正潜在的错误，类似于智能手机键盘上的自动更正器。

**表1.**Boldu等人[6]，Chan等人[12]，Deyle等人[14]，Dobinson等人[15]，Faisandaz等人[18]，Faisandaz等人[19]，Iravantchi等人[23]，Iravantchi等人[24]，Lee等人[31]，Lien等人[32]，Liu等人[33]，Saponas等人[42, 43]，Sharma等人[45]，Sharma等人[47]，Soliman等人[48]，Song等人[49]，Waghmare等人[51]，Wambecke等人[52]，Way等人[53]，Whitmire等人[54]，Xu等人[56]。传感器组件包括：Flex传感器×，力传感器××，接触传感器××，线性接触传感器×，摄像机×，雷达×，IMU×，声学传感器×，生物阻抗传感器×，EMG传感器×。外形因素包括：手套××，外骨骼×，手环×，物理对象×。识别算法包括：专用算法××，机器学习（决策树、随机森林、k-NN、隐马尔可夫模型、朴素贝叶斯）、卷积神经网络、循环神经网络、统计解码器、SVM等。

根据传感器类型、外形因素和识别软件类型，回顾了微手势文献中使用的识别系统。

2.2 微手势交互建模
Newman提出了一种基于状态机的编程语言，以简化图形交互的开发[39]。此后，研究人员使用不同的形式化方法（如正则表达式[28]、状态机[3]或上下文无关文法[26]）来建模图形交互。这些形式化方法可以作为框架的输入语言。最近，Chaffangeon Caillet等人引入了第一个用于描述微手势的符号系统：μGlyph[10]。根据μGlyph的底层模型，一个微手势至少由四个部分组成：动作、上下文、执行器和表面。动作描述了手指的基本生物力学运动（例如弯曲(?)、伸展(?)、外展(?)或内收(?)。此外，μGlyph还允许表示没有运动(?)的情况。上下文描述了运动是在空气中进行的(○○)还是与表面接触进行的(••)，或者是在表面上进行(○•)还是离开表面(•○)。然后可以将动作和上下文的符号组合起来，以较高抽象层次描述一个微手势。例如，从空中弯曲手指到与表面接触的微手势“触摸”可以用符号?°?表示。

在较低的抽象层次上，μGlyph允许指定动作的执行器和交互表面。执行器可以是手指或手指关节，它作为动作符号的下标表示。例如，用食指进行的触摸可以用i?°?表示。交互表面可以是手的一部分（如另一根手指或指节），也可以是一个物体，用接触符号(•)表示。例如，用食指触摸拇指可以用i?°?(t?)表示。此外，还可以描述其他属性，如压力或幅度。

这些是描述基本微手势的基本符号，换句话说，就是一个执行器在一个表面上进行的一个动作。为了组合多个动作、执行器或表面，μGlyph使用了三种组合符号：序列(;)、并发(//)和选择(|)。例如，用食指和中指触摸拇指可以用i // m?°?(t?); i // m??°表示。

作为交互设计者，在选择使用哪种识别系统时，会遇到几个挑战：
- 确保传感器能够在使用场景下工作。例如，两部分接触传感器[18]不能在没有增强物体的情况下与手持物体一起使用。
- 选择适合使用场景的外形因素的传感设备。例如，手套适用于设计摩托车上的微手势，但可能不适用于智能家居场景。
- 验证系统能否识别所需的微手势集。由于每个系统都是整体识别微手势，而不是作为低级事件的组合来识别，因此很难在不重新训练整个系统的情况下扩展微手势集。

为了解决这些挑战，我们提出了μPoly这一工具包，它使用基本微手势作为低级事件输入到状态机中以识别组合微手势。在描述μPoly之前，我们回顾了工具包所需具备的属性，作为μPoly设计的指导原则，以及这些属性在现有手势工具包中是如何得到支持的。

2.3 设计工具包
许多论文描述了成功工具包的属性[21, 37, 40]。Ledo等人总结了关于如何评估工具包的文献[30]。在本节中，我们将介绍微手势工具包需要具备的属性，以解决上述挑战。我们确定了工具包的五个重要属性：
- 降低开发难度（P visc[21, 37, 40]：微手势工具包应使测试新的识别系统和微手势集更加快速。
- 降低技能门槛（P skill[21, 37, 40]：微手势工具包应使初学者更容易实现微手势交互，特别是通过将文献中的常见微手势封装成可编程对象来简化使用。
- 高扩展性（P ceil[21, 37, 40）：微手势工具包应允许使用任何微手势集和识别系统，包括未来的系统。
- 依赖通用基础设施（P infra[21, 40）：微手势工具包应使用通用的数据结构和编程语言来简化开发。
- 便于快速原型设计（P proto[21, 37]：微手势工具包应便于识别系统和基于微手势的应用程序的原型设计。
此外，我们还将考虑[21, 37]中的其他指导原则：
- 简洁的API（P concis[21]：微手势工具包应使用简洁的API，促进人们对微手势的理解。
- 封装成功的设计（P encap[21]：微手势工具包应封装成功的微手势以便于使用。
- 协调多个通信设备（P coord[37]：微手势工具包应便于协调多个识别系统。

接下来，我们将回顾之前的手势工具包，以检查它们是如何实现这些属性的。

2.4 现有的手势工具包
Yanghee等人[38]提出了一个用于识别空中手势的框架。这些手势需要同时识别多个属性，如手臂运动、手部方向和手部形状。这些属性是异构的，因为有些属性（如手部方向和形状）可以随时捕获，而有些属性（如手臂运动）需要随时间捕获。为了并行识别这些异构属性，他们提出了使用彩色Petri网，这是一种常见的并行事件管理结构[P infra]。用户可以将空中手势视为这些属性的组合[P concis]。
Gesture Kniter是一个用于设计混合现实中的手势交互的工具包[36]。Gesture Kniter提供了一个原始动作库[P encap]，即基本的手部动作，可以通过组合这些动作来创建更复杂的手势识别器。使用这种方法，设计者不需要为每个想要使用的手势创建一个识别器，而是可以通过视觉脚本轻松组合原始识别器来识别组合手势[P skill]。如果库中没有所需的原始动作，用户可以通过向摄像头演示该动作来创建新的原始动作[P ceil]。通过Gesture Kniter，用户可以将手势视为一系列基本手势，从而支持创意新手势的实现[P concis]。
GRT是一个为C++创建的手势工具包[20]。该工具包提供了轻松测试每个手势的不同识别算法的能力[P visc]。类似Gesture Kniter，GRT基于一组可以链接在一起的核心模块，这有助于在基本手势识别器的基础上构建更复杂的手势识别器[P skill]。最后，GRT支持通用的C++代码架构[P infra]。
Proton[28]和Proton++[27]是使用正则表达式识别多触手势的框架。这些正则表达式使用一组预定义的符号和布局来表示触摸事件及其属性[P concis]。为了处理多触手势中发生的并行事件，Proton提供了正则表达式的图表视图，其中垂直对齐的事件必须同时发生。这些元素使得描述任何多触手势成为可能[P ceil]。
TouchID工具包[35]旨在简化探索新的桌面触摸交互，依赖于不同的手部部位/侧面和用户识别[P ceiling]。该工具包包含一个视觉编辑器以简化手势声明[P skill]，以及一个基于常用事件/订阅者模型的API来接收关于手势和手部部位的通知[P infra]。
SoD-Toolkit[44]通过整合融合引擎使协调多个传感设备变得容易[P coord]。同一个融合引擎还可以通过整合现有设备和新型传感器的数据来原型设计新设备[P proto]。

表2. 不同工具包的属性总结：
| 论文 | 降低开发难度（P visc） | 降低技能门槛（P skill） | 高扩展性（P ceil） | 依赖通用基础设施（P infra） | 简洁的API（P concis） | 封装成功设计（P encap） | 协调多个设备（P coord） |
|---------------|--------------|-------------------|-----------------|------------------|-----------------|-----------------|
| Colored Petri-Net | ? | ? | ? | ? | ? | ? | ? |
| Gesture Kniter | ? | ? | ? | ? | ? | ? |
| GRT | ? | ? | ? | ? | ? | ? |
| Proton | ? | ? | ? | ? | ? | ? |
| TouchID Toolkit | ? | ? | ? | ? | ? | ? |
| SoD-Toolkit | ? | ? | ? | ? | ? | ? |

表2总结了所介绍的手势工具包/框架的属性。?和？?是根据我们对论文的理解得出的，因为它们没有明确描述这些属性。

在下一节中，我们将介绍μPoly是如何设计来支持这些属性的。

3. μPoly的基本概念
μPoly是一个微手势工具包，它允许轻松快速地测试不同的识别系统、传感设备和识别算法，以及微手势集。在μPoly的具体情况下，识别算法只识别基本微手势，然后将这些基本微手势作为低级事件输入到状态机中，如图1所示。在本节中，我们将介绍μPoly的设计，并解释它如何使用低级事件和状态机进行操作。在下一节中，我们将详细介绍如何使用μPoly。

3.1 μPoly的设计
遵循文献中的工具包设计原则[21, 37, 40]，μPoly的设计如下：
1. 降低开发难度（P visc）：μPoly基于μGlyph这一微手势符号系统，作为标准，便于在不同识别系统之间轻松切换，并将它们连接到任何基于微手势的应用程序。
2. 高扩展性（P ceil）：μPoly使用μGlyph描述的基本微手势作为输入，允许用户将它们组合成组合微手势。此外，μPoly允许开发者创建新的识别系统，并将其添加到μPoly中。
3. 降低技能门槛（P skill）：由于μGlyph是一种专家级符号系统，μPoly包含一个常用微手势库，以简化初学者使用μGlyph的过程，并提供了一个μGlyph可视化编辑器，无需编码即可创建自定义的微手势表达式。
4. 依赖通用基础设施（P infra）：μPoly使用事件/订阅者WebSocket架构来通知微手势的检测，允许任何第三方应用程序集成基于微手势的交互。
5. 便于快速原型设计（P proto）：μPoly还可以模拟基本或组合微手势，以便在没有识别系统的情况下测试一组微手势或应用程序。

图2. 微手势状态机的示例。左边：状态机表示向内滑动：?°?; ???; ??°。右边：状态机表示敲击拇指或敲击食指和中指：(t?°?; t??°) | (i//m?°?; i//m??°)。

3.2 μPoly模型
为了检测微手势，μPoly依赖于表示基本微手势的低级事件和表示组合微手势的状态机。

3.2.1 低级事件
为了介绍低级事件，让我们先来看一个非常常见的例子：鼠标点击。处理鼠标点击时，开发者可以访问两种类型的三个事件：两个低级事件（按下和释放），以及一个组合事件（点击），即一个按下低级事件后跟一个释放低级事件。在现有的微手势识别系统中，开发者只能访问高级事件。特别是对于依赖机器学习的系统，系统被训练来识别组合微手势，而不能识别构成这些组合微手势的基本微手势或低级事件。然而，正如GestureKnitter[36]所解释的，通过训练识别基本微手势及其不同特征（例如触发微手势的身体部位或微手势期间的压力大小），可以提高灵活性，使基本微手势识别器能够组合起来以识别组合微手势。这种方法对于微手势特别有趣。许多微手势共享相同的基本微手势，如μGlyph文章[10]的附录所示。例如，考虑一组常见的微手势：轻敲(?°?; ??°)、向内滑动(?°?; ???; ??°)和向外滑动(?°?; ???; ??°)。这些微手势由4个基本微手势组成：?°?, ??°, ???, ???。这4个基本的微手势可以被重新组合来识别至少10种不同的微手势：触摸（?°?）[11]、释放（??°）[55]、轻敲（?°?；??°）[45]、向内拖动（???）[45]、向前拖动（???）[45]、向内滑动（?°?；???；??°）[52]、向前滑动（?°?；???；??°）[52]、向内拖放（???；??°）[55]、向前拖放（???；??°）[55]以及旋转（???；???）[55]。

3.2.2 状态机
状态机方法特别适合于微手势交互，因为这些交互涉及幅度小、速度快且有时很微妙的动作。虽然身体手势通常可以包含幅度不同的多种物理动作（这使得将身体手势分解为基本元素变得困难），但正如μGlyph [10]中所解释的，微手势仅依赖于少数固定的生物力学动作（手指弯曲 ?、伸展 ?、外展 ? 和内收 ?）以及一些特征（例如，食指是否接触）。与身体手势相比，微手势的识别所需的基本词汇量大大减少。因此，我们将微手势的管理与鼠标事件的管理进行了类比。实际上，如果我们进一步发展前一节中已经引入的这种类比，鼠标按下和释放就是生物力学动作，而左键和右键则是它们的特征。因此，就像管理鼠标和触摸事件一样[3, 27, 28]，我们使用由生物力学动作和特征组成的基本微手势的状态机。状态机将描述基本微手势的序列，即复合微手势，由于我们依赖μGlyph来描述基本微手势，每个状态机都可以通过复合微手势的μGlyph描述来表示。因此，μGlyph描述可以被视为描述复合微手势的正则表达式。图2展示了两个状态机及其相关的μGlyph描述的例子。

总体而言，μPoly使用基本微手势作为输入，这使得从一个识别系统切换到另一个识别系统变得容易（P?visc），并且可以简单地通过添加或调整相应的μGlyph表达式来即时添加或修改被识别的微手势集合（P?ceil）。

图3. μPoly面板用于选择识别系统

μPoly分为两个部分：核心和图形用户界面（GUI）。μPoly的核心是使用Node.js开发的。它负责与传感器设备和应用程序通信以及管理状态机。用户界面是使用Vue.js开发的。用户界面用于通过提供选择识别系统、指定要识别的微手势以及连接到应用程序的界面来简化核心配置。如果需要，μPoly可以在没有用户界面的情况下运行。核心和用户界面可以使用Electron编译成可以在计算机或智能手机上使用的应用程序。所有的源代码、二进制文件和文档都是开源的，可以在项目仓库网页2上找到。

接下来，我们将介绍开发人员和从业者如何配置和使用μPoly。我们将描述分为3个主题：设置现有的识别系统或新的识别系统（图1的A部分和B部分）、指定微手势识别器（图1的C部分）以及设置第三方客户端应用程序（图1的D部分和E部分）。

4.1 选择新的识别系统
图4. μPoly面板用于调试识别系统

μPoly的主要目标之一是使用户能够轻松地在不同的识别系统之间切换。要使用某个识别系统，用户首先需要将传感器设备连接到安装了μPoly的计算机上。连接类型取决于设备的通信协议（例如，串行端口使用USB电缆）。一旦设备 connect，就可以在系统中进行配置：用户必须从现有的驱动程序下拉菜单中选择相应的驱动程序，并设置连接属性（例如，使用哪个串行端口），见图3。驱动程序包括将传感器设备的原始数据转换为低级事件（即基本微手势）的通信协议和识别算法。对于同一传感器设备，可以实现具有不同识别算法的不同驱动程序。因此，测试不同的微手势识别算法等同于测试不同的驱动程序。此外，多个识别系统（可能是相同类型的）可以同时运行。因此，μPoly也可以作为协调多个识别系统的工具使用（P?coord）。

4.2 开发新的识别系统
要将新的识别系统集成到μPoly中，开发者首先需要为他们的传感器设备实现一个驱动程序。这是一个集成到μPoly中的JavaScript对象类。每个驱动程序将设备传输的原始数据流转换为基本微手势流，然后可以通过μPoly的状态机管道进行处理。在他们的驱动程序中，开发者指定了设备与μPoly之间使用的通信协议。μPoly提供了简化常用通信协议（[9, 52]）使用的方法，例如串行端口、WebSocket和BLE。虽然会添加其他通信协议的方法，但开发者也可以通过手动添加相应的库来使用其他通信协议。为了帮助实现驱动程序，我们提供了一个通用框架类以及每种通信协议的一个框架类（见文档3）。我们还为7种现有的传感器设备提供了7个驱动程序，其中包括来自已发表论文的两种[9, 18]、一种用于HoloLens 2手势跟踪系统[1]的驱动程序、一种用于Google Mediapipe [2]的驱动程序，以及三种来自未发表论文的手套驱动程序。其中一些驱动程序在应用程序部分中有介绍。为了便于驱动程序调试，μPoly提供了打印和图形显示传感器设备传输的实时原始值的方法，见图4（P?proto）。μPoly还显示了作为低级事件输出的基本微手势。这些事件的结构受到了μDex [8]中μGlyph数据结构的启发，μDex是一个包含100多种微手势的在线数据库。然而，我们使用了一个更简单、更简洁的结构，因为我们只需要关注低级事件（P?concis）。μPoly的文档3中展示了该结构的示例。

最终，任何用于识别微手势的传感器和识别器都可以通过适应识别器产生的输出格式来与μPoly一起使用。更多细节可以在项目仓库网页2上找到。

4.3 声明要识别的微手势
图5. 输入μGlyph描述的视觉编辑器。图6.

为了便于使用μPoly，用户可以从集成库或μDex中选择现有的微手势。

μPoly使用μGlyph符号来定义要识别的微手势。为了指定微手势识别器，μPoly嵌入了一个μGlyph表达式的视觉编辑器，如图5所示。这个视觉编辑器允许用户输入符合μGlyph符号的任何表达式。由于μGlyph符号是为专家用户设计的，μPoly整合了两个功能（见图6），旨在降低使用门槛。首先，μPoly提供了一个包含按名称和图像描述的常见微手势的库，用户可以直接使用而无需编写相应的μGlyph表达式（P?encap）。其次，μPoly使用与μDex [8]相同的数据结构来表示μGlyph描述。它让用户可以访问一个包含从文献中提取的100多种微手势的数据库，这些微手势可以通过复制粘贴μGlyph描述直接导入μPoly。它还允许用户通过文本描述、图像描述、作者、论文等信息来浏览这些微手势。因此，即使μPoly基于专家级符号，用户也不需要了解它（P?skill）。相比之下，熟悉μGlyph的用户可以使用视觉编辑器来添加微手势，包括以前从未使用过的微手势（P?ceil）。最后，μGlyph表达式用于直观地表示内部状态机。对于设备提供的每个新的基本μGlyph微手势（即低级事件），视觉反馈会告诉用户状态机当前的活跃状态，见图7。为了简化软件开发并避免受设备实现时间表的限制，μPoly可以模拟任何低级事件以测试状态机的覆盖范围和转换，例如识别状态机之间的潜在冲突（见文档3）。此外，如果需要，可以并行使用多个状态机。然而，这就需要仔细设计微手势映射，以避免同时触发多个微手势事件。这种方法遵循了触摸和鼠标事件的典型行为，即点击也会触发按下和释放事件。

图7. μPoly提供了每个状态机当前状态的视觉反馈：绿线表示成功的转换，橙线表示潜在的转换。完整的μGlyph表达式下方的线表示微手势是否正在等待潜在的转换（橙线）或已被识别（绿线）。

4.4 订阅和接收微手势
一旦配置好了设备和微手势，用户就可以通过WebSocket和JSON格式使用订阅机制将识别的微手势传输到第三方应用程序。WebSocket和JSON可以很容易地在多种编程语言中实现[4(P?infra)]。特别是，多个应用程序可以同时连接。在这种架构中，μPoly充当WebSocket服务器，第三方应用程序充当WebSocket客户端。WebSocket服务器是使用socket.io实现的。

5. 使用μPoly的场景和应用
μPoly可以用于开发任何支持基于微手势交互的应用程序。应用示例包括汽车中的交互[16]、驾驶舱中的交互[52]以及混合现实中的交互[9, 54]。在本节中，我们描述了两个场景：增强现实中的菜单控制和视频播放器控制。在本节的最后，我们展示了我们实现并提供的一些应用程序，这些应用程序可以在不进行额外安装的情况下直接开始使用μPoly。

5.1 场景1：使用μPoly开发AR应用
本场景中描述的应用程序受到了Chaffangeon Caillet等人[9]未来工作的启发。开发该应用程序所涉及的各个步骤展示了工具包所期望的功能，如相关工作中的“设计工具包”部分所述。附带的视频演示了这些步骤。
Vic是一名为HoloLens 2开发AR应用程序的软件开发者。她最近发现微手势是一种很有前景的AR新方式。Vic想要使用微手势来控制她的应用程序中的菜单。她发现了μPoly，它可以使用HoloLens 2的摄像头来识别微手势。首先，她在Unity中创建了她的应用程序原型。然后，Vic通过WebSocket将她的Unity应用程序连接到μPoly，重用了她在之前的研究项目中使用的WebSocket代码片段[9, 41]（P?infra）。Vic现在需要决定她想要使用哪些微手势。她浏览了μDex目录，并选出了潜在的候选微手势。由于不知道μGlyph，Vic直接从μDex复制相应的表达式到μPoly中。由于她在计算机上开发应用程序，她想使用计算机的摄像头进行一些快速测试。因此，她从μPoly预打包的驱动程序列表中选择了Google MediaPipe，并在计算机的摄像头前执行了这些微手势。

修改微手势集——在探索和重用了几个μDex中的微手势描述后，Vic现在想要指定自己的微手势（P?ceil）。使用μGlyph，她了解到微手势是由一系列低级基本微手势组成的（P?concis）。因此，她开始为微手势的中间步骤集成视觉和音频反馈。她首先关注她的轻敲微手势（?°?；??°），这个微手势用于点击按钮。她希望按钮在按下时亮起（?°?），并在释放时发出声音（??°）。为了检测这些微手势的中间步骤，她在μPoly中创建了两个新的识别器，复制了两次轻敲的μGlyph识别器（图9A）。在这两种情况下，她都简化了手势表达，只保留了必要的基本微动（按压或释放）。然而，她无需修改识别系统或μPoly应用程序代码。然后，她将这两种识别器添加到她的HoloLens应用程序μPoly的websocket订阅中（P visc）。图9。场景1：使用μPoly开发AR应用程序。A）Vic定义了一个点击动作及其两个组成部分的微动：按压和释放。与这些微动相关联的状态机会并行运行。B）在AR应用程序中，点击会触发一个按钮。按压和释放的微动提供视觉反馈，表明在点击过程中按钮被按下然后释放。C）Vic定义了两个设备：带有Mediapipe的HoloLens 2内置摄像头和一个定制的戒指。D）用户同时使用这两个设备。

在HoloLens上部署 – 现在Vic已经确定了她的微动集，她接着在HoloLens上部署她的应用程序。她首先添加了HoloLens 2摄像头的预包装驱动程序（P visc），并指定了连接HoloLens 2摄像头的websocket（图9 b）。然后她请测试员Charlie尝试使用该应用程序（图9 c）。Charlie注意到，为了确保HoloLens能够稳定地检测到她的微动，她必须将双手放在摄像头前。几分钟后，由于长时间举手，她开始感到疲劳（所谓的“大猩猩手臂”效应[22]）。Vic得出结论，HoloLens摄像头不适合长时间检测微动。她希望用户能保持放松的姿势，比如手臂自然下垂。她需要探索另一种方法。

测试和原型不同的识别系统 – Aure是Vic团队中的一名硬件开发者，他建议测试两种新的形式因素：一种受[52]启发的手套，另一种受[6]启发的戒指。在原型开发完成后，Aure的下一步是为μPoly开发两个驱动程序。Aure阅读了文档，通过串行连接查看了其他预包装驱动程序的源代码，并在已实现的串行连接基础上分叉了驱动程序示例。她使用μPoly对设备原始数据的可视化来实现和调试她的驱动程序，确保驱动程序正确集成到μPoly中（P proto）。在尝试了这两种设备后（图9 d），她认为戒指的干扰较小，尽管它不能识别Vic为应用程序设想的所有微动。

使用两种识别系统 – Vic和Aure讨论后找到了一个合适的折中方案：同时使用戒指和HoloLens摄像头来检测微动（图9C）。戒指虽然只能识别一部分微动（例如轻触而不是滑动），但可以在放松的姿势下使用，并且能识别应用程序中最常用的微动。而偶尔的微动（例如滑动）可以被HoloLens摄像头稳定地识别。

5.2 场景2：使用μPoly实现连续控制
本场景描述的应用程序展示了该工具包的更复杂用法。有关此应用程序实现的更多信息，请参阅μPoly的文档6。

离散控制 – Grace是一家视频流媒体公司的开发者。她的任务是规划一些可以通过下一代可穿戴设备启用的视频播放器控制。她发现微动，特别是滑动动作，是可行的候选方案。因此，她设置了一个使用文献中的手套的视频播放器原型来测试映射（P proto）。在测试了从手套到视频播放器的流程后，她在μPoly中设置了向外滑动（?°?;???;??°）和向内滑动（?°?;???;??°）的识别器。她将这两个微动连接到导航功能上。当接收到间隔小于200ms的连续N次向外滑动（或向内滑动）时，分别快速前进（5秒（N = 1）、10秒（N = 2）、30秒（N = 3）、1分钟（N = 4）...

连续控制 – 虽然对结果感到满意，但她仍然希望避免状态机中的物理重复和超时，以便在每次滑动后立即发送命令。因此，她决定像使用鼠标拖动一样分解滑动动作。她在μPoly中禁用了向外滑动和向内滑动的识别器，并设置了四个新的识别器：按压（?°?）、向外滑动（???）、向内滑动（?°?）和释放（??°）（P visc）。然后她在应用程序中连接了这四个微动。当检测到按压动作时，她会统计接收到的向外和向内滑动的次数，并相应地更新视觉反馈（“向前/向后跳跃X秒？”），并在释放时触发跳跃。这种方式不仅只需要一次滑动，还允许实时（双向）精细控制跳跃的距离。

结合控制 – Grace更倾向于第二种方案。然而，在她看来，第一种方案对于音量控制来说也不错。与她的导航需求不同，音量可以线性控制。使用第一种方案时，每次滑动可以直接将音量增加或减少10%，并且不需要超时。因此，她重新启用了向外滑动和向内滑动的识别器（P visc），并将它们连接到了音量控制器，并调整了所有识别器，使得音量现在可以通过食指滑动来控制，而导航则通过中指滑动来控制（P proto）。

5.3 现有应用程序
除了用于用户测试的应用程序（例如音乐播放器，在后续的评估部分中）外，我们还开发了另外两个应用程序：一个键盘绑定器和一个VLC控制器。为了能够直接使用μPoly进行原型设计，这两个应用程序都被直接集成到了μPoly中。第一个应用程序允许用户将微动与键盘按键关联起来。因此，可以通过微动触发Keynote或PowerPoint等应用程序。第二个应用程序是利用VLC API开发的，让用户可以通过微动来控制VLC。这个应用程序需要安装VLC并配置其Lua接口。

最终，由于这两个集成应用程序和预包装的MediaPipe驱动程序，μPoly可以无需开发识别系统或应用程序即可直接进行测试。

6 μPoly评估
为了评估μPoly，我们进行了多次评估，涵盖了Ledo等人[30]总结的文献中的四种评估策略。我们已经介绍了两种类型的评估：
- 第1种类型（即演示、个别实例等）通过描述上一节中的应用程序场景和现有应用程序；
- 第4种类型（即启发式评估）通过描述文献中的工具包属性（如P visc、P skill、P ceiling、P infra、P proto、P concise、P encaps和P coord）是如何融入μPoly设计的。

在本节中，我们介绍了另外两种评估：第2种类型（即使用情况、早期使用研究和反馈）和第3种类型（即性能）。表3总结了我们对μPoly的评估。

6.1 早期使用研究（类型2）
我们对μPoly的每个部分进行了三项早期使用研究，测试了μPoly工具包的三个方面（设备、识别器、使用方式）。这些研究的目的是为了发现μPoly在人机交互（HCI）实践者使用时可能遇到的任何障碍或问题。

开发新的识别系统
我们进行了初步测试，以确保可以使用现有的文档为μPoly创建驱动程序。我们联系了两位微动研究人员（一位来自学术界，一位来自工业界），他们各自开发了一个微动识别系统。他们已经熟悉μGlyph，但不熟悉μPoly。我们要求他们将已开发的识别系统适配并集成到工具包中。两人都成功为HoloLens 2和Mediapipe创建了驱动程序。虽然构建初始识别系统花费了大约一周时间，但为μPoly创建驱动程序只花了2-3天。这些经历和反馈告诉我们，为新的设备直接编写驱动程序并不一定会增加任务的复杂性，将现有的驱动程序转换为μPoly生态系统是完全可行的。此外，他们的评论帮助我们修复了μPoly设备界面上的一些小错误，并澄清了关于如何编写驱动程序的文档部分内容。两位研究人员都对μPoly表示兴趣，并随后被邀请成为本文的合著者，因为我们提议将他们的作品作为预包装驱动程序集成到μPoly中。

声明可识别的微动
我们进行了初步测试，以确保用户可以在不了解μGlyph符号的情况下声明微动以供识别。我们招募了一名之前从未从事过微动工作的博士生。我们首先向她介绍了微动的概念和μPoly的概述。然后使用官方的μGlyph教程（大约15分钟）。测试的目的是让参与者编写两个最常见的微动：轻触和滑动，以及使用微动功能（如特定的手指）。我们设置了一只能够检测这两个微动的手套及其相应的驱动程序。μPoly还被配置为可以与外部自定义音乐播放器应用程序通信（见图10）。这个音乐播放器是一个简单的HTML/JavaScript网站，可以从本地目录加载免费使用的歌曲。我们提供了一个简单的API来控制音乐应用程序（例如，一个名为toggle_play的事件来控制播放/暂停功能）。我们没有解释视觉微动编辑器，让参与者通过试错来发现它，并用手套实时测试她的表达。总体而言，参与者在1小时30分钟内（包括介绍和15分钟的教程）成功编写了所有指定的微动（即除了拇指之外的所有手指的轻触和滑动）。我们要求参与者在实验过程中大声思考。主要困难与μGlyph中的变量使用有关，但参与者都独立克服了这些问题。值得注意的是，尽管有文档可用，参与者在实验过程中并未使用它。根据我们的观察和参与者的反馈，我们修复了μPoly中μGlyph编辑器中的几个错误。

图10. 我们在测试中使用的自定义音乐播放器应用程序，用于声明微动。

订阅和接收微动
我们进行了两项初步测试，以确保可以将μPoly与遵循特定事件标准的现有应用程序关联起来。对于第一项测试，我们联系了当地一个生活实验室的工程师。这个实验室专注于家庭自动化，运营着一个集成了智能家电的完整公寓的平台。这些家电是通过生活实验室定制的API控制的，该API遵循openHAB标准。这项测试的目的是将μPoly连接到这个API。识别系统和微动识别器已经在μPoly中设置好了。参与者需要创建一个应用程序，将μPoly的输出连接到公寓的API上。参与者研究了几小时，创建了一个Python服务器来控制灯光和电动百叶窗。除了检索并调整了一些基本的python示例外，参与者没有报告任何特殊问题。

对于第二项测试，我们联系了一名从事协作机器人技术的硕士生。作为实习的一部分，他需要将微动识别器连接到ROS节点上以控制机器人。我们提供了已经实现识别器的手套以及μPoly的文档。在两个工作日内，硕士生成功连接了手套，描述了微动，并实现了一个可以通过websocket连接到μPoly的ROS节点。硕士生报告没有任何问题。

6.2 μPoly性能：测量微动检测延迟（类型3）
我们进行了初步测试，以验证μPoly引入的延迟及其将微动分解为基本μGlyph事件的过程。进行了两项测试：一项是在同一台笔记本电脑上同时运行μPoly和应用程序，另一项是在通过WLAN连接的不同的计算机上分别运行μPoly和应用程序。6.2.1 单台计算机上的延迟。在第一个测试中，我们使用了一个安装在上手套上的触觉开关13，并由Arduino微控制器控制。手套通过USB电缆和串行端口与μPoly相连。当按钮被按下时，手套会发出事件△°?，当按钮释放时，会发出事件??°。在μPoly中，我们使用了一个单状态机来识别轻敲（?°?；??°）动作。一旦识别到该动作，就会通过WebSocket将该微动作事件传输到我们定制的音乐应用程序中。该应用程序与μPoly运行在同一台计算机上。使用这种设置，我们在手套按钮上执行了5次轻敲微动作，每次之间相隔几秒钟。每次轻敲都会激活音乐应用程序的取消静音/静音按钮。我们使用iPhone 8在慢动作模式下（每秒240帧）录制了手套（使用小棒进行轻敲操作的过程）以及显示音乐应用程序的屏幕。我们还记录了μPoly接收串行端口数据的时间和发送WebSocket消息的时间。首先，我们确保视频以每秒240帧的速度录制。然后我们测量了每次轻敲的时间：（1）按钮第一次被按下到按钮第一次被释放之间的时间（ttap）；（2）按钮第一次被释放到屏幕显示音量变化之间的时间（tevent）。根据UNIX时间戳，我们计算了从收到最后一条串行数据（即按钮被按下的事件）到发送WebSocket消息之间的时间（tproc）。平均ttap时间为310毫秒（标准差=121毫秒），平均tevent时间为42毫秒（标准差=9毫秒），平均tproc时间为0.8毫秒（标准差=0.4毫秒）。总体而言，在最佳情况下（即网络延迟最小化时），μPoly的延迟比网络延迟低一个数量级，而网络延迟又比执行一个基本微动作所需的时间低一个数量级。6.2.2 多台计算机上的延迟。在第二个测试中，我们将μPoly的延迟与商业解决方案进行了比较，并且采用了更现实的配置，即μPoly和应用程序不在同一台计算机上运行。我们使用了HoloLens 2头显，它原生支持按压微动作（?°?(t?)作为主要的交互技术。HoloLens通过WiFi使用WebSocket发送和接收事件。参与者佩戴头显，并在虚拟圆圈变绿时执行拇指-食指按压动作。为了确保参与者无法预测何时执行微动作，圆圈每2到4秒会随机变为另一种颜色，其中变为绿色的概率为0.5。共进行了24次尝试。我们记录了圆圈变绿时的HoloLens时间戳、HoloLens按压微动作事件被应用程序接收的时间，以及μPoly按压事件被应用程序接收的时间。为了避免刺激响应中的任何偏差（例如CPU负载），我们同时记录了这两种情况的时间。执行按压动作平均需要596.5毫秒（标准差=83.4毫秒，使用μPoly），平均需要516毫秒（标准差=86.2毫秒，使用HoloLens识别）。考虑到HoloLens识别按压微动作没有延迟，516毫秒代表了从圆圈变绿到实际执行按压动作的反应时间。因此，80.5毫秒的差异代表了网络延迟，即HoloLens和μPoly之间的往返通信时间，因为之前的实验显示μPoly的处理时间约为1毫秒。6.2.3 总体结果。总的来说，μPoly在识别微动作时的主要延迟来自输入和输出的网络处理。然而，这种延迟仍然比执行一个基本微动作所需的时间低一个数量级。因此，μPoly引入的延迟似乎是非累积的，因为在一系列基本微动作（e1;…;en）中，μPoly会在物理上完成当前微动作ei的执行之前分析完每个基本事件ei + 1。总体延迟不受微动作长度的影响，仅取决于通信延迟。7 讨论、局限性和未来工作。我们已经展示了μPoly可以与各种具有不同传感器（接触传感器、力传感器和摄像头）、不同设备形态（手套、戒指、增强现实环境）以及不同识别算法（自定义算法、机器学习）的识别系统一起使用。我们还展示了两种开发者（硬件开发者和软件开发者）如何使用μPoly创建基于微动作的交互。在本节中，我们将介绍μPoly已经取得的成果和未来的发展方向。7.1 集成缺失的μGlyph属性。μGlyph是一种表示法，包含多种符号，可以在多个抽象层次上描述微动作。μGlyph还包括通过因式分解或封装描述的部分来减少描述大小的高级技术。目前μPoly还没有包含μGlyph的所有属性，因此不能完全支持μGlyph在实现基于微动作的交互中的表达能力。在这个初始版本中，μPoly确实集成了所有手指、动作和组合符号。然而，μPoly在如何使用组合符号方面有一些限制。OR（或AND）组合只能在公式内部或不同动作符号之间使用。例如，OR组合公式i | m?°?需要写成x ∈ {i|m}, x?°?。这不会影响μGlyph的表达能力，因为μGlyph的作者已经建议引入这些变量以避免潜在的歧义。同样，AND组合i // m?°?需要写成i?°?//m?°?。这也不会影响μGlyph的表达能力，因为在μGlyph中，AND组合被用作因式分解的高级技术。μGlyph可以用来描述手部除手指以外的其他部分，如指节或手指关节。μPoly可以识别不同的指节和手指侧面，但目前很少有微动作研究使用这些功能[53]。μGlyph还可以描述压力、幅度和持续时间等属性。μPoly还不能完全识别利用这些属性定义的微动作，例如压力用Hi、Md和Lo表示，幅度用Cl、Ha和Op表示。当这些符号被集成到μPoly中时，用户需要指定驱动程序类中每个符号对应的传感器值阈值。尽管压力和幅度符号尚未被识别，但μPoly已经可以识别变化（例如20%→50%）或变化幅度（例如30%），这些都用百分比表示。持续时间也在μPoly中得到了实现，但尚未集成到μGlyph编辑器中。最后，μGlyph允许通过封装一系列低级事件来定义自定义事件。这些自定义事件在识别2D绘图时非常有用，例如在空气中画一个圆?°°。然而，μPoly目前还不支持这些功能。这个扩展需要为低级事件添加一个新的属性，因此封装将在驱动程序级别进行管理。为解决这个问题，另一个设想的解决方案是在定义新的μPoly识别器时允许使用μPoly识别器引用（即递归使用识别器）。这个解决方案允许用户直接创建自己的封装μGlyph表达式，而无需修改μPoly的源代码。截至本文撰写时，μPoly可以识别μDex中引用的121个微动作中的97个（80%）。7.2 在μPoly中集成校准模块。许多识别系统在使用前需要校准。例如，在M[eye]cro[52]中，需要根据每个用户调整自定义算法的压力阈值。实际上，传感器值的范围会随着手的大小和手套的拉伸程度而变化。对于像Mocap15这样的数据手套，用户需要执行某些手势来校准设备。为了让μPoly作为一个独立的微动作识别应用工作，我们需要在μPoly中集成一个校准用户界面。可以使用几种方法，例如通过iframe集成外部Web应用，或者在μPoly的设备选项卡中提供创建自定义UI组件的功能。表3. 类型策略我们做了什么结果Ref1 demonstration，个别实例，超出描述描述了μPoly开发了应用程序?完整的函数描述第4节?相关的应用场景第5节?带有完整文档和视频演示的工具包?示例应用程序（音乐播放器、键盘绑定器、VLC遥控器）第5.32节使用、早期使用研究、反馈μPoly初始用户测试?创建驱动程序：需要2-3天的时间来完全理解μPoly的输入格式，并为其现有的识别系统创建适配的驱动程序第6.1节?在没有μGlyph先验知识的情况下使用μPoly：大约1小时30分钟的时间来编写并测试多个微动作，仅使用官方μGlyph教程作为学习基础第6.1节?在第三方应用程序中接收微动作：成功地将μPoly连接到自动化家居系统，无需任何外部帮助（例如用微动作控制灯光等）第6.13节性能轻敲的延迟测试（执行时间约为310毫秒）?在单台计算机上（网络延迟最小）：μPoly延迟（约1毫秒）< 网络延迟（约42毫秒）第6.2.1节?在多台计算机上：与集成商业解决方案（Hololens 2）相比，网络延迟约为81毫秒第6.2.2节?总体而言：μPoly延迟< 微动作执行时间第6.2.3节基于文献中的5个属性P?visc、P?ceil、P?skill、P?infra和P?proto的启发式方法?P?visc：基于μGlyph标准的微动作描述第3.1节?P?ceil：μGlyph允许将基本微动作组合成更复杂的微动作?μPoly支持添加新的识别系统第3.1节?P?skill：集成了常用微动作的库?+ 视觉编辑器，避免编写代码第3.1节?P?infra：事件/订阅者WebSocket架构第3.1节?P?proto：μPoly支持模拟微动作第3.1节我们工具包评估策略及其结果的总结。7.3 改进多个识别系统的协调性。已经有研究结合了来自多个传感器的信息来提高微动作识别的准确性[48]。使用μPoly，可以通过创建连接到多个传感器的驱动程序来实现这一点。除了在传感器级别的协调外，μPoly还可以协调多个识别系统。在当前版本的μPoly中，用户可以同时连接多个识别系统。上一节中的AR应用展示了一个使用两个识别系统的用例，但每个设备识别不同的基本微动作。因此，多个识别系统的协调仍然有限。由于μPoly与每个设备单独通信，可以确定基本微动作或低级事件来自哪个设备。这一功能将使我们能够根据设备过滤基本微动作或低级事件。基于这一功能，我们设想在μPoly中实现两种类型的协调：•首先，可以选择用于每个状态机的识别系统。用户需要为每个μGlyph描述选择识别系统，例如使用复选框列表。这种一级控制可以用来根据识别系统区分微动作，例如区分左手和右手的微动作；•其次，可以选择用于每个状态机转换的识别系统。这种二级控制可以用来结合来自两个不同设备的事件。一个潜在的应用场景是双手微动作，其中微动作由双手互补地执行。7.4 对μPoly的进一步评估。我们已经使用了文献中确定的四种策略对μPoly进行了测试，如表3所示。在本研究中，我们主要关注了μPoly的核心功能。作为未来工作的一部分，我们将与用户一起对μPoly的用户界面进行更全面的评估。这些评估不会影响μPoly的核心原则，但会改进与μPoly界面交互的人体工程学设计。需要提醒的是，使用μPoly工具包并不是强制性的。最终，我们计划通过开源发布该工具包来推动μPoly的全面评估，从而使社区能够为其做出贡献并进一步开发它。由于μPoly是一个涉及学术界和工业界的合作项目，一些未参与μPoly开发的开发者已经在使用该工具包来开发应用程序，例如实现自动驾驶汽车中基于微手势的交互功能，以及另一种利用微手势在增强现实中滚动文档的功能。

**8. 结论**
在本文中，我们介绍了μPoly——首个专为促进基于微手势的交互研究和快速原型设计而设计的工具包。μPoly具有三大优势：1）能够轻松切换不同的微手势识别系统；2）可以方便地修改需要识别的微手势集；3）能够轻松与第三方应用程序集成。为了实现这些优势，μPoly基于μGlyph微手势表示法[10]进行开发。借助这个工具包，μGlyph朝着成为描述微手势事件的软件工程标准又迈出了一步。虽然μPoly将支持并推动微手势交互领域的研究，但我们希望μPoly的核心概念能够被整合到现有的开发套件中，比如已经支持基本微手势事件（如捏合手势）的HoloLens 2的MRTK开发套件。

**致谢**
本项工作部分得到了法国国家研究机构（ANR）项目MIC（ANR-22-CE33-0017）的支持。