利用人体姿态估计和本地大型语言模型实现的多模态人机交互

《Advanced Robotics Research》：Multimodal Human–Robot Interaction Using Human Pose Estimation and Local Large Language Models

　　摘要

研究表明，增强的感知和推理能力使社交智能机器人能够做出更明智的决策。在人类感知的交互中，可靠地理解语言和非语言的交流线索至关重要。然而，关于多模态感知如何弥补单一模态的不足，现实世界的证据仍然有限。本研究探讨了结合使用语言和非语言线索来协调机器人导航和运动控制的方法。我们将人体姿态估计流程（用于手势和姿势识别）与虚拟助手流程相结合，并通过本地大型语言模型（LLM）增强自然语言理解能力。该手势模块是为单用户交互设计的，尽管该系统也在有第二参与者的场景中进行了测试。在实验室中，参与者向移动服务机器人提供了手势、姿势和语音指令。系统使用激光雷达（LiDAR）和RGB-D相机进行轨迹跟踪和手势识别，配备麦克风和自然语言处理流程，以及本地LLM来解释语音指令并生成导航指令。性能评估基于运动控制精度和模态之间的冲突解决能力。结果显示，基于手势的指令识别准确率为95%，基于语音的指令识别准确率为93%，并且在多模态仲裁过程中没有出现冲突。这些发现表明，多模态线索可以在嘈杂或遮挡环境中提高可靠性、安全性、效率和鲁棒性。总体而言，本研究提供了一种工程方法，并提供了实证证据，支持在人机交互中使用多模态感知和推理，突显了其在开发无处不在环境中的自主、社交意识助手方面的潜力。

缩写

HRI：人机交互（Human-Robot Interaction）
LLM：大型语言模型（Large Language Model）
FOV：视野（Field of View）
HRC：人机协作（Human-Robot Collaboration）
AI：人工智能（Artificial Intelligence）
ML：机器学习（Machine Learning）
ROS：机器人操作系统（Robot Operating System）
STT：语音转文本（Speech-to-Text）
TTS：文本转语音（Text-to-Speech）
JSON：JavaScript对象表示法（JavaScript Object Notation）
Llama：大型语言模型架构（Large Language Model Architecture）
ASR：自动语音识别（Automatic Speech Recognition）
NLP：自然语言处理（Natural Language Processing）
NLU：自然语言理解（Natural Language Understanding）
BLE：蓝牙低能耗（Bluetooth Low Energy）
WWD：唤醒词检测（Wake-Word Detection）

1 引言

机器人与人类在各种环境（如家庭[1]或办公室[2, 3]）中互动和合作的愿景正变得越来越具体。人机交互（HRI）依赖于有效的沟通，这可以通过使机器人使用多种感知模态来实现社交意识和认知。有效的HRI需要可靠地处理和解释语言或非语言的线索。语言线索要求机器人具备自然语言处理和理解能力，以便通过动作、文本或语音合成来响应[4]。相比之下，非语言线索要求机器人理解来自人类的视觉信号，以指导互动和响应。通过关注结合语言和非语言线索的多模态互动，我们探索了提高人机沟通有效性和自然性的方法。实现这一目标需要机器人具备人类环境意识，这涉及理解人类的姿势和方向，从而提供有关人类活动的信息。理解对话上下文需要由大规模语言知识支持的语言处理能力[5]，这可以通过自动语音识别和使用生成式AI模型的基于提示的互动来实现。尽管HRI领域取得了显著进展，但仍存在重要的研究空白，阻碍了社交智能机器人的发展。当前的机器人系统主要依赖于基本的环境感知和空间意识，通常只能有限地支持解释人类的非语言线索，例如[3, 6]。此外，现有方法往往未能整合人类活动的空间和时间方面，例如站立或行走在人类周围、坐在椅子上、躺在床上、拿起物体以及举手或挥手等[7, 8]。在机器人中整合和融合语言和非语言交互模态的研究空白仍然存在。现有研究通常强调一种模态而忽视另一种模态，尽管它们结合使用可以克服各自的局限性。此外，大多数关于语音-手势整合的工作仅限于综述或虚拟模拟，对实际机器人实现的关注相对较少[5, 9, 10]。这些方面对于准确及时和协调地解释和响应人类行为至关重要。因此，当前的机器人系统在通过融合语言和非语言线索进行解释和互动方面的能力仍然有限，导致HRI效果不佳。为了解决这一限制，我们提出了一个多模态人机交互框架，该框架结合了手势识别、自然语言理解和基于优先级的命令仲裁，以实现安全和实时的机器人控制。我们的研究旨在通过开发和评估一个能够实时识别手势、姿势和语音命令的机器人系统来弥合这些空白，使其能够理解和响应各种人类线索。我们通过研究使用人体姿势和手势以及语音命令作为社交线索，来丰富机器人与人类之间的社交互动。关于非语言线索，我们关注人体的外骨骼2D关键点，包括手腕、肩膀、膝盖、眼睛、耳朵、脚踝和手臂。我们采用深度学习框架来检测和估计这些关键点，创建一个骨骼模型。这种骨骼表示通过确定图像或视频流中的坐标点和关节及其关系来区分不同的人类活动。关于语言线索，我们设计了一个流程，利用自动语音识别（ASR）和大型语言模型（LLM）来解释语音输入并生成结构化的机器人命令。在所提出的系统中，语言理解作为多模态交互流程的一部分，将语音解释与基于手势的控制相结合。该系统围绕边缘驱动的架构设计，确保感知和语言组件的本地处理，避免对外部云服务的依赖，并实现可预测的延迟和实时操作。本文的贡献包括：

- 整合社交线索（如手势和身体姿势），通过自然动作实现服务机器人的直观人类控制。
- 开发实时检测和解释人类社交线索及基于手势控制的方法。
- 将LLM辅助的语音交互作为额外的控制模态进行整合，允许使用本地LLM与机器人进行自然灵活的沟通。
- 提出一种多模态命令仲裁框架，通过基于优先级的多路复用器仲裁融合基于手势和语音的命令，确保模态之间的安全协调和冲突解决。
- 将这些概念和算法整合到现有的面向服务的机器人系统[3]中，使移动机器人能够在没有持续人类干预的情况下执行更复杂的任务。
- 在Ohmni Telepresence Robot上部署所提出的系统，为交互框架提供现实世界的验证平台。
- 在Ohmni Telepresence Robot上对系统进行实验评估，证明其在现实场景中的有效性、鲁棒性和适用性。

本文的其余部分组织如下。第2节介绍最新技术。第3节介绍我们的方法。第4节描述了与物理机器人的实验评估，第5节总结本文。

2 最新技术

我们讨论了与语言和非语言HRI相关的交流线索的工作。特别是，我们关注考虑了用于人类环境意识的姿态识别和基于语音的交互的文献。我们还研究了在系统集成中相关交互模块共存的方法。

2.1 通过人体姿态估计实现人类环境意识

服务机器人需要各种类似人类的感知能力，以识别人类活动或在交互过程中表现出情境和环境意识。人体姿态估计（HPE）对于增强HRI至关重要，因为它涉及使用视觉传感器检测和估计身体关节或部位位置（如肘部、手臂、脚踝、膝盖、臀部和耳朵）的位置，并理解它们与其他人体部位的关联[11–13]。HPE通过姿态识别和分类提供更好的人类环境意识，可用于改善人类与机器人之间的协作和交互[11,14–17]。HPE的应用不仅限于机器人技术，还扩展到增强现实（用于虚拟试穿体验[14]、虚拟现实（用于颠覆性游戏[14]）、医疗保健（用于康复期间的患者运动诊断[14]）、自动驾驶（用于识别行人和骑自行车者[18]）以及监控和安全系统（用于行为分析和人群管理[19, 20]）等领域。HPE主要有三种人体模型：

1. 骨骼或运动学模型使用由边缘（骨骼）连接的关键点（关节）网络来描述人体[12, 13]。尽管骨骼模型的纹理和形状较为简单，但它足以估计2D和3D姿势。骨骼模型的示例包括Openpose[21]和Alphapose[11]。骨骼模型已通过不同的框架（如Openpose、Alphapose、Halpe和Robot Operating System (ROS)）应用于姿势跟踪、手势检测和机器人控制等各种应用中[16-18]，证明了其多功能性。

2. 平面或轮廓模型使用轮廓来表示人体。它有助于分类和分割对象，包括2D姿势估计[12, 22]。一个例子是DensePose。

3. 体积模型使用三维结构来描述人体的真实结构和纹理，使用圆柱体和圆锥体，适用于精确的3D HPE[12, 22]。示例包括DensePose和Skinned Multi-Person Linear Models (SMPL)。大多数2D和3D HPE方法使用深度学习方法，特别是卷积神经网络（CNN）[11]。单人和多人2D HPE方法有所不同，单人HPE使用回归或热图，而多人HPE采用自上而下或自下而上的方法[11, 20]。自上而下的模型虽然有效，但由于需要对场景中的每个人进行两步检测和姿势估计，计算成本较高，并且难以处理遮挡和重叠个体[13]。相比之下，自下而上的模型在拥挤场景中表现出更好的性能和计算效率，因为它们同时进行检测和姿势估计[13]。虽然这些模型在处理遮挡和重叠方面表现更好，但在低图像分辨率下，关键点检测和姿势估计的准确性较差。在自下而上的模型中，Openpose模型作为一个最先进的框架脱颖而出，为其他自下而上的方法设定了基准。为了更快地进行多人姿势估计，Openpose使用卷积姿态机[23]通过热图和部分亲和力场同时预测身体关键点[11, 13]。Openpose的骨骼模型能够检测137个关键点，提供了详细且高效的人体姿势表示[21]。各种类型的静态或动态手势识别方法也应用于机器人技术中的HRI，依赖于手臂[24, 25]、手[15, 24, 26]、身体[15, 25]或姿势[25]。此前，我们研究了在共享环境中使用多模态大型语言模型（MLLMs）进行上下文感知的人类行为预测[27]。虽然那个框架侧重于通过多模态输入预测人类行为，但当前的工作则利用多模态线索（如手势、姿势和语音）对移动机器人进行直接实时控制。与之更密切相关的是我们之前为Ohmni Telepresence Robot设计的人类检测、跟踪和跟随方法[3]，为这项研究奠定了基础。在这里，我们通过使机器人能够理解和响应可以控制其运动的非语言线索，扩展了这一基础。我们的工作在以下方面与现有研究不同。首先，与上述方法不同，我们的系统集成了实时手势和姿势感知，实现了直观的机器人控制。具体来说，我们使用静态手势和身体姿势来发出运动命令，类似于[15]中介绍的方法。其次，我们的方法依赖于Openpose框架检测的身体关键点，利用相对坐标进行姿势和手势识别，见图1。这种设计决策允许在没有特定任务模型训练的情况下进行手势解释，从而减少了计算开销。第三，我们的方法直接在骨骼关键点上操作，而不是原始图像数据，避免了捕获、标记和训练大量手势图像数据集的需要，这使其不同于[15]等工作。接下来，我们的系统针对办公室助理机器人进行了环境感知的交互设计，使机器人能够解释人类活动并做出适当的运动命令。最后，所提出的多模态交互框架通过基于优先级的命令仲裁整合了手势和语音命令，并部署在Ohmni Telepresence Robot上，证明了该方法在现实世界中的适用性，使我们的工作成为少数利用该机器人进行高级社交交互的研究之一。

2.2 用于机器人的LLM增强型对话界面

早期的语音辅助代理依赖于专家定义的规则和基于意图的模型，这些模型将用户命令映射到预定义的响应[29]。虽然这些系统功能齐全，但它们仅允许有限的交互，将人机通信限制在僵化的输入-输出交换中。这些传统方法已被用于谷歌的Legacy Dialogflow自然语言理解（NLU）平台，在该平台上，交互式虚拟代理可以作为基于语音或文本的响应系统集成到网页、手机或桌面应用程序中，或者用作开发自定义对话代理的平台[4]。最近在对话式AI方面的进展引入了诸如ChatGPT、Gemini和Dialogflow CX之类的系统，这些系统利用概率推理方法实现自然语言处理（NLP）和NLU，通过生成式训练模型以更自然的对话方式生成响应。然而，这样的模型在没有特定任务的指导和示例的情况下，无法自动替代基于意图的传统机器人系统。这是因为机器人历来都是被编程来响应特定的查询短语[30]，因此用户意图仍然需要在上下文中进行解释并转换为结构化的命令。此外，大语言模型（LLMs）是使用大规模互联网数据集进行训练的，因此将它们适配到机器人应用中通常需要提示工程和少量样本学习，并通过示例或领域知识来指导以实现一致的响应。最近的调查强调了LLMs与机器人系统的日益集成，以实现更高级的自然语言理解、复杂的任务完成和更好的决策制定[31]。这些方法通常被归类为通过对话的人机交互（HRI）和通过监督远程操作的人机交互（HRI），我们提出的多模态交互方法可以归入其中。结合意图本体和示例的提示工程已被证明可以使像ChatGPT这样的LLMs从非结构化查询生成结构化的机器人命令，从而减少自然语言指令中的歧义[32]。然而，尽管有提示工程，由于人类交流中的讽刺或反讽、语音转文本（STT）引擎的拼写错误或自然语言中的歧义等因素，误解仍可能发生[30]。因此，对话式AI流程必须包含检测和缓解这些错误的机制。大多数现有工作都集中在使用像ChatGPT[30, 32]和BERT[33]这样的模型来实现机器人智能。然而，这些方法通常依赖于需要付费订阅的基于云的服务，可能会受到网络延迟的影响，并引发对敏感数据暴露的担忧。相比之下，等效的开源LLMs可以本地部署在边缘硬件上。虽然一些先前的研究仍然是概念性的或仅限于模拟环境，但我们的工作将基于LLM的对话组件集成到物理机器人的多模态交互流程中，并评估其在现实世界环境中生成结构化运动命令的能力。

2.3 语言和非语言的人机交互

使用身体语言线索（如眼神接触、手势和面部表情）的交互式交流已被探索来增强HRI，其中身体动作和面部表情与单词或机器人命令相关联[30]。直观的非语言和信息丰富的语言机器人-人类交流也被研究，以在临床中心建立人类和机器人之间的理解和信任[9]。然而，这些研究主要集中在虚拟现实环境和涉及模拟自主机器人的初步实验上。Desiderata的概念被提出，作为结合语言和非语言交流的HRI系统的期望特征集，作为未来系统的概念框架[5]。然而，这项工作主要提供了对完全集成HRI系统的概述和动机。研究还探讨了共享的感知、动作和动作相关语言的神经机制是否可以提高人机交互的效率和自然性[10]。然而，这些研究早于当代的对话式代理，因此没有探索使用现代语言模型进行交互。相比之下，我们的方法将人类上下文意识与由本地LLM驱动的对话代理解释的语音命令相结合，实现了HRI中语言和非语言交流的多模态融合。实验使用Ohmni Telepresence Robot进行，其中命令仲裁机制解决了手势和语音输入之间的冲突，以支持感知和机器人控制。ROS 1框架通过提供面向服务的架构和跨多个节点的分布式处理来支持该系统。为了便于与先前的工作进行比较，表1总结了讨论的方法，并将我们的研究置于更广泛的现有技术范围内。表1. HRI方法、它们的特点和集成方面的总结。

2.3 语言和非语言的人机交互

使用身体语言线索（如眼神接触、手势和面部表情）的交互式交流已被探索来增强HRI，其中身体动作和面部表情与单词或机器人命令相关联[30]。直观的非语言和信息丰富的语言机器人-人类交流也被研究，以在临床中心建立人类和机器人之间的理解和信任[9]。然而，这些研究主要集中在虚拟现实环境和涉及模拟自主机器人的初步实验上。Desiderata的概念被提出，作为结合语言和非语言交流的HRI系统的期望特征集，作为未来系统的概念框架[5]。然而，这项工作主要提供了对完全集成HRI系统的概述和动机。研究还探讨了共享的感知、动作和动作相关语言的神经机制是否可以提高人机交互的效率和自然性[10]。然而，这些研究早于当代的对话式代理，因此没有探索使用现代语言模型进行交互。相比之下，我们的方法将人类上下文意识与由本地LLM驱动的对话代理解释的语音命令相结合，实现了HRI中语言和非语言交流的多模态融合。实验使用Ohmni Telepresence Robot进行，其中命令仲裁机制解决了手势和语音输入之间的冲突，以支持感知和机器人控制。ROS 1框架通过提供面向服务的架构和跨多个节点的分布式处理来支持该系统。为了便于与先前的工作进行比较，表1总结了讨论的方法，并将我们的研究置于更广泛的现有技术范围内。

3 方法

我们描述了所提出的多模态HRI系统。该方法结合了来自人体姿态估计的手势交互和由自然语言理解支持的语音交互。基于优先级的仲裁机制协调两种模态生成的命令，以确保机器人的控制一致性。第3.1节介绍了整体多模态交互框架和命令仲裁机制。第3.2节描述了基于人体姿态估计的手势交互模块，而第3.3节介绍了语音交互模块。

3.1 多模态交互框架

图2展示了多模态命令仲裁工作流程，显示了手势和语音命令在转发给机器人运动控制器之前是如何被处理和优先级排序的。人类输入通过两个并行管道进行处理：一个基于人体姿态估计的手势识别管道和一个基于语音识别和自然语言理解的语音命令处理管道。两个管道都生成运动命令，这些命令由仲裁机制进行评估，该机制根据定义的优先级规则选择活跃的命令流。图2显示了手势优先于语音命令的仲裁逻辑。仲裁逻辑在算法1中进行了总结。在算法中，和分别表示由手势和语音模块生成的速度命令。标志表示是否检测到手势，而表示检测到基于语音的停止命令。当手势活跃时，仲裁机制优先处理手势命令。如果没有手势命令，系统将处理语音命令。系统维护了一个安全覆盖机制，以便当控制返回到语音交互模块时，口语中的停止命令会立即停止机器人；如果在模块进入暂停状态之前有一个活跃的运动命令。手势交互模块处理来自人体姿态估计的视觉输入，并识别映射到机器人运动命令的预定义静态手势。语音交互模块捕获口语命令，使用自动语音识别将其转录，通过集成的LLM解释用户的意图，并生成相应的机器人运动命令。在实现的系统中，这种仲裁机制是在ROS框架内使用多路复用器节点（twist_mux）实现的[34]。手势和语音节点独立地向多路复用器发布速度命令消息。每个输入通道都被分配了一个优先级级别，手势命令的优先级高于语音命令。手势命令被赋予更高的优先级，因为它们可以在动态的人机环境中以更低的延迟被识别，并提供即时的交互通道[19]。多路复用器输出一个统一的速度命令主题（tb_cmd_vel），该主题驱动机器人的差动驱动控制器。为了支持安全的交互，系统还维护了一个上下文感知的控制状态。当在机器人的视野中检测到人类，并且手势模块进入服从状态时，基于语音的运动命令会暂时暂停，而手势控制保持活跃。然而，在此暂停期间，口语中的停止命令仍然可用，以便在优先级返回到语音交互模块时实施。当手势模块返回不服从状态或未检测到人类时，语音交互会自动恢复。

3.2 手势交互模块

手势交互模块通过来自人体姿态估计的手势，实现人类用户和机器人之间的非语言交流。该模块解释机器人摄像头捕获的身体动作，并将其转换为机器人可以执行的运动命令。除了手势识别之外，该模块还评估用户的身体姿势，以确定是否应激活基于手势的交互。这提供了一种基本的上下文门控，防止用户没有面对机器人时机器人发生不必要的动作。手势交互模块依赖于HPE来提取检测到的人体的骨骼结构。此功能是使用来自RGB图像帧的二十五个身体关键点实现的（由OpenPose库提供[21]）。每个关键点对应于一个特定的身体关节，并由其二维图像坐标表示，原点位于图像的左上角。检测到的关节包括面部标志和主要身体关节，如肩膀、肘部、手腕、臀部、膝盖和脚踝。这些关键点形成了人体的骨骼表示，可以用来推断手势和姿势。使用检测到的骨骼结构，系统执行两个感知任务：手势识别和姿势识别。手势识别允许用户通过预定义的手臂动作发出运动命令，而姿势识别确定用户相对于机器人的方向，并控制何时接受手势命令。

3.2.1 手势识别

人体手势识别是使用从OpenPose提取的骨骼关键点来执行的。对于每个人，OpenPose需要一个RGB图像。然后它检测关键点并提供相对于检测到的身体框架的标准化二维关节坐标，如图1所示。每个编号的坐标如下[21]：0 - 鼻子，1 - 脖子，2 - 右肩，3 - 右肘，4 - 右腕，5 - 左肩，6 - 左肘，7 - 左腕，8 - 中间臀部，9 - 右臀部，10 - 右膝，11 - 右脚踝，12 - 左膝，13 - 左脚踝，14 - 左脚踝，15 - 右眼，16 - 左眼，17 - 右耳，18 - 左耳，19 - 左大脚趾，20 - 左小脚趾，21 - 左脚后跟，22 - 右大脚趾，23 - 右小脚趾，24 - 右脚后跟。这些标准化的关键点允许分析对用户规模、身体比例和相机距离的适度变化保持不变。手势分类是使用上身关节（特别是肩膀、肘部和手腕）之间的确定性几何关系来实现的。该方法不依赖于绝对像素阈值，而是评估相对空间关系，如关节的垂直顺序、侧向位移和手臂角度配置。由于骨骼坐标是标准化的，因此当用户在图像中偏离中心或身体大小有适度变化时，得到的手势定义仍然稳健。对于坐着和站立的用户，应用相同的几何关系，因为手势检测仅依赖于在两种配置中都可见的上身关节。只要上身和手臂在相机的视野范围内，就可以保持可靠的手势识别。尽管可以考虑许多人类手势，但我们专注于适合机器人导航控制的手臂定义的手势。因此，我们定义了八个手势：服从、不服从、向前、向后、向左、向右、向前和向左。这些手势在图3中进行了说明。图3显示了系统用于上下文感知交互的手势类别。为了正式描述用于分类的几何关系，我们使用符号表示身体关节和坐标轴。符号和分别表示身体的左侧和右侧，而、、、、和分别对应于手腕、肘部、肩膀、臀部、膝盖和脚踝关节。变量和表示水平和垂直图像坐标。例如，表示左肩的坐标，而表示右手的坐标。根据这种表示法，每个手势都是通过关节坐标之间的布尔关系来定义的。这些逻辑关系决定了手势在当前帧中是处于活动状态还是非活动状态。所有手势类别及其相应的几何条件都在表2中呈现。一旦手势被识别，它就会被映射到一个相应的机器人运动指令。表2. 手势类别及其几何定义。

手势 定义 组合/输出
Obey

Disobey

Forward

Backward

Left

Right

ForwardandRight

ForwardandLeft

这些手臂手势作为功能，人们用它们来指挥机器人的运动。一旦我们的系统识别出手势，就会触发相应的命令。算法2展示了详细过程。

3.2.2 姿势识别
除了手势检测之外，我们的方法还执行姿势识别，以确定用户相对于机器人的方向。我们使用OpenPose检测到的身体关节的二维坐标来定义五种静态姿势，包括向前站立、侧向站立、向后站立、向前坐姿和侧向坐姿，如图4所示。

3.2.3 实现
我们使用Ohmni Telepresence机器人，其照片如图5所示。该机器人的硬件包括一个4核64位Intel Atom AAEON UP Board CPU，运行频率高达1.92 GHz，1 GB RAM和16 GB存储空间。机器人使用无线（WiFi和BLE）连接以及USB扩展插槽进行通信和外围设备连接。鉴于我们希望通过提高其感知能力来自动化Ohmni Telepresence机器人，我们使用其Wi-Fi适配器与其他边缘计算设备通信，并通过其USB连接添加LiDAR和Kinect 360 RGB-D相机来弥补硬件的局限性。特别是，我们安装了YDLIDAR X4来提高机器人姿态估计、定位和碰撞检测的鲁棒性。Kinect 360 RGD-B相机包含一个RGB传感器、一个深度传感器、一个麦克风和一个垂直旋转系统。我们利用其RGB传感器提供准确的骨骼跟踪。Kinect相机的RGB和深度传感器可以以640*480像素的分辨率工作，并且能够以每秒30帧的速度捕获图像，深度传感器能够检测到最远5米的物体距离[35]。Kinect单目相机可以以1280*960分辨率和15帧每秒的速度捕获图像，这适用于检测静态物体，但不足以检测移动物体。因此，图像分辨率越低，物体检测的帧率就越高。Kinect传感器由AC-DC电源适配器供电，因此我们必须修改其电源供应，使用ANKER 2000mAh电源银行和USB电压转换器使其便携并能够安装在移动机器人上[36]。此外，我们还连接了一台配备NVIDIA GTX 1650 Ti GPU的Intel Core i7-10750H笔记本电脑作为边缘设备，用于数据处理，特别是HPE使用的图像帧。GPU计算核心对于运行NVIDIA Compute Unified Device Architecture（CUDA）工具包和实时处理相机图像帧是必需的。最后，我们还添加了一个外部电池来为LiDAR和Kinect相机供电，以改善能源管理。Lidar为用户与手势模块的交互提供了距离信息。为了平衡系统的计算开销、实时处理和能源管理，初始传感器数据收集和预处理在笔记本电脑和机器人之间分配。软件架构包括通信和控制，基于ROS，ROS节点分布在计算设备上。由于感知传感器和计算单元在软件和硬件支持方面的限制，我们在笔记本电脑上使用了Ubuntu 20.04和ROS Noetic。由于OpenPose库与Ubuntu 20.04上的ROS OpenPose包装器之间存在兼容性问题，我们在运行Ubuntu 18.04和ROS Melodic的Docker容器中托管了ROS OpenPose包装器[37]。我们使用Docker Compose构建了容器，这使得可以安装所有依赖项，包括Freenect ROS驱动程序和NVIDIA CUDA，以发现Kinect相机并处理相机帧。另一个必要的依赖项是NVIDIA Container Toolkit，它允许在构建的容器中启用CUDA并在笔记本电脑上使用NVIDIA GPU。我们使用系统的姿势和手势识别组件实现自主导航任务。在这种情况下，我们使用两个手势来触发导航命令。一旦手势被识别，机器人的自主导航模块就会从初始位置生成到两个目标位置的路径。在机器人前往选定的目标之前，用户会给出相应的命令，从而启动人机交互（HRI）任务[25, 38]。这里省略了自主导航模块的详细描述，因为它遵循了我们之前工作中的实现[3]。

3.3 语音交互模块
语音交互模块使用户能够通过自然语言命令与机器人进行口头交流。机器人麦克风捕获语音输入，并通过模块化的 speech and language understanding 流程对其进行处理，将非结构化的语音转换为结构化的机器人控制命令。算法4展示了语音交互模块的处理过程。该流程包括四个主要阶段：自动语音识别、自然语言理解、命令执行和反馈生成。在第一阶段，模块将用户的语音输入转录成文本。然后将结果转录文本传递到第二阶段，其中本地LLM分析文本输入并提取预期的机器人命令。生成的命令通常对应于运动动作，例如前进、转弯、停止、启动导航或聊天响应。运动命令作为速度或导航消息在ROS框架内传输给机器人控制接口。

如3.1节所述，语音交互模块在多模态仲裁机制下运行。因为语音处理的延迟比手势识别长，所以在同时交互时手势命令具有优先权。当手势交互处于活动状态时，基于语音的运动命令会暂时暂停，以避免机器人的动作冲突。此外，可以使用的“Stop”语音命令可以停止机器人之前发出的基于语音的运动命令，确保在语音交互模块重新激活之前的安全操作。因此，语音交互模块通过提供灵活的口头接口来补充基于手势的交互，允许用户使用自然语言与机器人交流，同时保持与多模态命令仲裁框架的集成。

3.3.1 自然语言处理
为了实现第一阶段，该模块集成了一种轻量级的设备内置NLP组件用于关键词检测。这个组件有两个关键功能。首先，它使用唤醒词检测（WWD）来监听用户的唤醒词，从而将系统从休眠状态切换到活动状态。激活后，该组件（其STT单元）会在十秒内预期语音输入。一旦接收到输入，它将语音音频转录成文本等效形式。然后组件返回休眠状态并等待关键词触发。这样，只有当听到唤醒词时，组件才会激活流程，从而节省资源并避免误触发。应当注意的是，语音输入错误很可能会直接影响下游LLM的推理[30]。

3.3.2 自然语言理解
为了实现第二阶段，该模块通过本地LLM集成了一个NLU组件。与依赖固定命令模板的传统基于意图的语音助手不同，这个组件可以解释从简单关键词到更复杂短语或句子的各种用户输入。因此，它负责根据提示中提供的知识进行意图分类，系统定义的意图包括移动、旋转、停止或聊天。该组件还负责从用户输入中生成或提取实体，如距离、方向和旋转角度。最后，NLU组件生成与提供的知识一致的结构化JSON输出，供命令编排组件使用。

3.3.3 命令编排器
命令编排器解释语言理解流程产生的结构化动作输出，并将它们路由到相应的执行模块。该组件解析生成的JSON命令，并将它们映射到相应的机器人动作，如平移、旋转或对话响应。这个抽象层将高级交互命令与机器人的底层执行机制分开。因为系统操作的是物理机器人，所以监控运动执行是必不可少的。因此，命令编排器通过ROS Odometry主题从机器人的差动驱动中收集里程计数据。利用这些信息，系统记录每个运动命令后的机器人的初始和最终姿态及方向。这使得能够测量相对于命令目标的平移和旋转位移，从而评估由里程计漂移等因素引起的运动误差。通过这种方式，我们可以获得关于机器人移动了多少米或转过了多少角度的精确细节。

3.3.5 实施

3.3.5.1 硬件

为了提升实时性能并消除对云服务的依赖，所有导致机器人动作的数据处理都在机器人系统的边缘设备上完成。对于语音输入，我们使用带有降噪功能的耳机麦克风或笔记本电脑麦克风。对于语音输出，我们使用可以放置在机器人上的便携式扬声器。此外，我们在一台HP Elite台式电脑上部署了一个本地大型语言模型（Local LLM），作为我们的边缘AI服务器。该服务器配备了Intel i5-12500 CPU、NVIDIA RTX 3060 12GB GPU和DDR5-32GB RAM。我们选择这种消费级硬件，特别是NVIDIA GPU，以确保快速加载和高效处理量化的本地大型语言模型，而较大的RAM容量则为模型提供了足够的空间，使其完全驻留在内存中。我们在笔记本电脑上协调构成虚拟助手（VA）系统的各个组件。由于数据处理分布在机器人、桌面服务器和笔记本电脑之间，VA流程在笔记本电脑上不会消耗太多计算资源。这种分布式设计不仅实现了实时性能，还减轻了单个处理单元所固有的硬件和功耗限制，并进一步支持了与物联网（IoT）基础设施的无缝集成。

3.3.5.2 ROS

我们倾向于使用开源或自行实现的软件来推动边缘智能，因为这种方法减少了对外部API的依赖，避免了重复的集成成本，提高了实时响应性，增强了数据隐私，并允许灵活定制模型和算法以满足系统需求。ROS框架作为语音交互模块各组件之间的通信方式。这些组件以ROS节点的形式出现。ROS管理消息在系统中的传输逻辑，并保证了系统的服务质量（QOS）。在我们的实现中，我们使用了ROS 1框架，因为我们的分布式系统中的大多数模块都是基于ROS 1的。

3.3.5.3 Porcupine和Google语音转文本引擎

我们分别使用Picovoice的WWD引擎（称为Porcupine）和Google的STT API来实现WWD和STT节点。Picovoice是一个支持设备上虚拟助手（VA）的网络服务[39]。Porcupine是一个轻量级的设备上语音检测引擎，用于关键词识别。我们需要使用Picovoice网络服务器上的神经网络接口训练推理引擎来识别单词或短语，然后将模型下载并部署到边缘设备上。唯一的缺点是该网络服务需要一个验证密钥，以便在边缘设备上使用单个模型实例。用于激活VA流程的唤醒词是“Hello-Kai”，这也是机器人的名称。另一方面，Google STT API用于语音转文本[40]。一旦接收到用户的语音，它会被转录成相应的文本格式，准备传输到边缘AI服务器。作为我们系统的松耦合端，Porcupine唤醒词和Google STT引擎可以被类似的服务替代，例如开源的唤醒词服务或Whisper或VOSK STT引擎。这两种服务没有网络API依赖性或限制，可以进一步减少VA模型的延迟。

3.3.5.4 Ollama、Open WebUI和Llama 3.1:8B

我们在边缘AI服务器上部署了Open WebUI AI平台。Open WebUI是一个可扩展的AI解决方案，设计为离线运行，并支持与Ollama和OpenAI兼容的API集成。Ollama是一个用于在边缘设备上运行大型语言模型（LLM）的框架，它提供了运行、管理和操作LLM的API，并将其集成到定制应用程序中。Ollama框架支持使用GPU、CPU和NPU加速器进行LLM推理。我们部署了一个包含Ollama框架的Open WebUI Docker容器。Open WebUI提供了一个类似于OpenAI的直观Web界面，用于管理本地LLM。OpenWebUI通过服务器地址和端口号连接到Ollama，以暴露所有下载的模型。Open WebUI还提供了一个Web API密钥，可以与自定义应用程序一起使用。我们使用这个API密钥来统一访问本地和基于云的LLM。Llama 3.1:8B是一个先进的、量化的、开源的推理用LLM，我们在系统中部署了它。由于硬件限制，我们无法使用405B模型；因此，我们的系统在准确性和性能上有所折中，但获得了内存节省和推理时响应时间的提升。在第4节中，我们还将使用Llama 3.1:8B生成JSON数据的系统性能与使用OpenAI的ChatGPT 3.5 Turbo进行了比较，后者需要付费订阅。

3.3.5.5 反馈机制

我们使用ElevenLabs的eSpeak API或pyttsx3 TTS引擎来接收机器人执行动作后的可听反馈。eSpeak合成器提供逼真的AI声音，但需要互联网连接，而pyttsx3可以离线工作，从而避免了延迟，但听起来有些机械。在我们的系统中，geometry_msgs和nav_msgs/Odometry提供了评估机器人运动性能所需的反馈。机器人的姿态（位置和方向）使用geometry_msgs/Pose或PoseStamped表示，这些数据指定了它在给定时间的空间位置。为了跟踪随时间的变化，我们使用了nav_msgs/Odometry消息，因为它包含了来自轮式编码器或其他机载传感器的姿态和速度估计。通过将我们的运动抽象发出的geometry_msgs/Twist命令与相应的里程计输出进行比较，我们可以量化机器人对其预定轨迹的跟随精度。从里程计获得的位移捕捉了位置变化，而速度场提供了实时运动反馈。这种组合使我们能够测量平移和旋转的精度，为提供关于我们的移动和旋转抽象有效性的反馈奠定了基础，这些反馈通过TTS以可听形式传递给我们。由于我们处理的是物理机器人，因此机器人的安全以及人类的安全也是我们实现的重要组成部分。LLM可能会生成可能导致事故的移动机器人速度值；因此，我们的抽象和反馈机制处理了这些安全关键事件并通知我们。

3.3.5.6 提示工程

为了提高性能，我们应用了[32]中描述的提示工程技术。我们进一步通过在LLM中嵌入机器人身份、将其部署在地面机器人上，并优先使用Llama 3.1:8B来推动边缘智能来实现这一点。从知识库生成符合结构化的JSON命令。这个过程依赖于强大的提示工程来确保JSON文本生成的准确性，消除LLM的幻觉，并使生成的文本与机器人控制中的上下文特定值保持一致。类似的非结构化短语作为人类发出的指令可能会有不同的语义含义，需要根据上下文来理解，以便被重新生成为适当的结构化命令。在我们的案例中，我们考虑了与四个非结构化命令相关的意图和实体，即移动、旋转、停止或聊天。我们的意图“move”、“rotate”和“stop”具有以下参数，它们取特定的值：线速度、距离、角速度、角度和方向。我们使用这些意图和实体来创建一个知识库，LLM在创建结构化JSON数据时应遵循这个知识库。然而，仅有提示和所需的知识库是不够的，还需要示例和说明模型的限制，否则LLM将无法生成所需的JSON数据来输出所需的动作或任务[30]。此外，LLM在接收到任务提示时有时会出现幻觉。为了提高我们系统中LLM的性能，在提示中包含了以下修改：（1）LLM是一个地面机器人，应该这样称呼自己，而不是作为LLM；（2）LLM被告知它具有移动和旋转的能力，但它不能飞行；（3）LLM被编程为在认为任务超出其能力时通知用户；（4）LLM被指示用“Kai”这个名字来标识自己，它是一个物理机器人，并且位于大学实验室中；（5）机器人被指示在聊天响应中不要超过两句话；（6）如果用户提出的问题与机器人的能力无关，就用简单的聊天来回答。虽然基于轻量级嵌入的分类器对于将固定话语映射到封闭的命令集是有效的，但所提出的系统必须解释变体的自然语言输入并生成结构化的运动意图。在实践中，用户会用不同的措辞发出语义等效的命令（例如，“向前移动”、“继续前进”、“缓慢前进”或“一直移动直到我说停止”）。本地LLM执行语义规范化和结构化JSON生成，使其能够应对释义的变异性、部分STT错误和组合指令。这种设计还允许在未来扩展命令词汇表，而无需重新训练专用的分类器，这在基于嵌入的方法中是必需的。以下是我们的LLM提示的知识库：

{
"action": "move", "params": {"linear_speed": linear_speed, "distance": distance, "is_forward": is_forward},
"action": "rotate", "params": {"angular_velocity": angular_velocity, "angle": angle, "is_clockwise": is_clockwise},
"action": "sequence", "params": {"actions": sequence_of_actions},
"action": "stop",
"action": "simple_chat", "params": "provide feedback"
}

以下是伴随LLM所需的示例性少量学习提示，这些提示需要符合知识库中的动作：

- 向前移动
提示：
• （向前移动1米。）
• （请向前移动一米。）
JSON动作：
{"action": "move", "params": {"linear_speed": 0.2, "distance": 1, "is_forward": true}}

- 向右旋转
提示：
• （顺时针旋转45°。）
• （向右转45°。）
JSON动作：
{"action": "rotate", "params": {"angular_velocity": 30, "angle": 45, "is_clockwise": true}}

- 向后移动并右转
提示：
• （向右转然后向前移动3米。）
• （向右转3米然后前进。）
JSON动作：
{"action": "sequence", "params": {"actions": [
{"action": "rotate", "params": {"angular_velocity": 30, "angle": 90, "is_clockwise": true}},
{"action": "move", "params": {"linear_speed": 0.2, "distance": 3, "is_forward": false}}
]}

- 简单聊天：自我介绍
提示：
• （你能做什么？）
• （你能告诉我你的能力吗？）
• （我需要知道你能做什么！）

LLM使用这四类示例来检查JSON生成的准确性：简单聊天提示、动作提示、不可能提示和零样本提示。简单聊天提示询问机器人简单的问题，如“你好，你叫什么名字，你能做什么？”或“你在哪里，你是什么？”这类测试确保LLM以简单的聊天方式响应。动作提示确保LLM使用正确的命令，如方向、距离、速度和角度。它测试简单的案例，如“向前移动1米”，以及边缘案例，如“请再往前走一点”，“旋转两次”，以及“重复上一个命令”。不可能提示向机器人提出它无法完成的任务，如“过来”，“去做我的晚餐”，或“跳两米高”。这确保机器人不会生成它未被教授的动作，并且会以简单聊天的方式响应。零样本提示测试机器人是否能够利用一些数学和推理来推理目标值，例如“以0.3米/秒的速度向前移动3秒”或“只是向前移动3秒”。综合提示包含了机器人需要执行的多个动作，例如：“向前移动两米，然后旋转90度，再向后移动一米。”我们的附加提示还包括机器人可以产生的线性和角速度的最大值，以防止机器人因速度过快而倾倒、发生事故或受到损坏，如[32]中所述。

3.3.5.7 用于语义推理的本地大语言模型（Local LLM）

Llama 3.1:8B被用作与GPT 3.5-Turbo进行对比的本地大语言模型，在理论上对其与其他Llama 3开源模型的优势进行了比较，如表3所示。所有模型都是具有指令能力的模型；因此，它们能够遵循指令，例如更可靠地解析命令以形成JSON数据，这比仅文本形式的对应模型更好。表3. Llama 3模型与GPT 3.5的基准比较。

3.3.5.7 用于语义推理的本地大语言模型（Local LLM）

Llama 3.1:8B被用作与GPT 3.5-Turbo进行对比的本地大语言模型，在理论上对其与其他Llama 3开源模型的优势进行了比较，如表3所示。所有模型都是具有指令能力的模型；因此，它们能够遵循指令，例如更可靠地解析命令以形成JSON数据，这比仅文本形式的对应模型更好。表3. Llama 3模型与GPT 3.5的基准比较。

通过我们的实验中的手动验证，我们能够确定大语言模型（LLM）产生的结构化JSON输出的准确性与其从非结构化语音转文本（STT）引擎接收的输入文本之间的关系。我们将其称为STT正确性相关性（r），它衡量了STT的正确性与有效JSON生成之间的关联强度。这是使用皮尔逊相关系数计算的，在这种情况下，对于二进制值，称为phi（φ）相关系数。phi（φ）相关系数在公式（1）中表示：

(1)

其中，表示语音转文本（STT）的正确性（1=正确，0=错误），表示JSON的有效性（1=有效，0=无效），表示多次试验的平均值。phi（φ）相关系数的范围在...

部署
本地
本地
本地
云API

参数
8.0B
3.21B
3.21B
20B

上下文长度
128K
128K
128K
16K

嵌入长度
4096
3072
3072
4096

量化
Q4_K_M
Q4_K_M
FP16
—

能力
完成，工具
完成，工具
完成，工具

存储大小
4.9 GB
2 GB
6.4 GB

RAM容量
6.9 GB
4 GB
8.5 GB

推理成本（每100万个令牌）
0
0
0
0.50（输入）- 1.5（输出）

推理（Arc Challenge - Zero Shot）
83.4
78.6
78.6
83.7

MMLU
73
63.4
63.4
69.8

参考文献
[41]
[42]
[43]
[44]

通过我们的实验中的手动验证，我们能够确定大语言模型（LLM）产生的结构化JSON输出的准确性与其从非结构化语音转文本（STT）引擎接收的输入文本之间的关系。我们将其称为STT正确性相关性（r），它衡量了STT的正确性与有效JSON生成之间的关联强度。这是使用皮尔逊相关系数计算的，在这种情况下，对于二进制值，称为phi（φ）相关系数。phi（φ）相关系数在公式（1）中表示：

(1)

其中，表示语音转文本（STT）的正确性（1=正确，0=错误），表示JSON的有效性（1=有效，0=无效），表示多次试验的平均值。phi（φ）相关系数的范围在...

4 实验评估

为了展示我们多模态交互方法的有效性和性能，我们在现实环境中进行了各种实验。我们在斯图加特大学Universitaetsstrasse 38号的计算机科学大楼内的Living Lab进行了实验。该空间被几位同事用作办公环境，为评估所提出的系统提供了实际有人居住的环境。Living Lab提供了适当的照明条件和清晰的导航路径，非常适合部署和测试我们在实验中使用的增强型Ohmni Telepresence Robot。以下我们将描述每个实验的设置、指标和结果以及讨论。

4.1 参与者和数据收集

4.1.1 伦理和同意

实验评估涉及10名参与者。不需要伦理批准，所有涉及人类受试者的程序都符合机构伦理指南。所有参与者都被告知研究的目的，并在参与前提供了知情同意。这包括明确同意收集视频和音频数据以及将匿名数据用于研究和出版目的。没有收集或存储任何可识别个人身份的信息，所有程序都符合人类受试者研究的机构指南。

4.2 单个人手势识别和姿势检测

该实验通过评估单用户交互场景中的手势识别和姿势检测性能来评估所提出系统的感知和交互能力。实验要求机器人检测人的姿势和方向，并对其视野范围内的人提供的手势做出反应。除了感知任务外，机器人还能够在测试设施内自主移动并跟随人的手势，前提是其路径上没有障碍物。手势检测、姿势检测和手势触发导航的实验在一天内完成。

4.2.1 实验设置

实验在之前描述的Living Lab环境中进行。手势模块由4名参与者互动。在测试期间，相机分辨率最初设置为160×160像素，允许HPE管线以大约每秒30帧的平均速率进行手势和姿势识别。手势检测实验要求机器人识别视野范围内的人和相应的手臂手势。我们设置识别手势交互模块中定义的所有八个手势。每个手势执行50次，以确定手势被正确识别的频率。手势识别的一个主要要求是用户面对机器人时的姿势检测。具体来说，姿势检测确保在激活手势识别之前人的眼睛在相机框架内可见，如算法2中所述。姿势检测实验评估机器人识别相对于机器人的人的姿势和方向的能力。我们考虑了姿势交互模块中定义的所有五个姿势类别。每个姿势测试了50次，以确定姿势被正确识别的频率。

4.2.2 识别准确性结果

在实验过程中，我们记录了手势和姿势检测模型的准确预测标签和错误预测标签的数量。结果以混淆矩阵的形式展示在图6和图7中。这些矩阵总结了每个预测标签的精确度，并允许计算模型的识别准确性。手势检测模型的准确率为95%，而姿势检测模型的准确率为98%。

4.2.3 与基于深度学习的手势识别的比较

我们将我们的手势识别方法与使用AlexNet进行静态手势检测的深度学习方法进行了比较[15]。参考工作评估了一个室内设置，该设置可以检测和预测以下静态手臂手势：As You Were、Attention、Move Forward、No Gesture、Stop、Turn Left和Turn Right，用于控制无人地面车辆。比较重点关注模型准确性、所需的训练数据量以及训练模型所需的时间。与深度学习方法不同，我们的手势识别方法不需要训练样本，因为手势检测基于从OpenPose骨骼表示中提取的身体关节之间的几何关系。因此，我们利用了已经训练好的OpenPose模型的HPE能力。比较结果展示在表4中。

4.2.4 系统性能和计算成本

作为一种基于视觉的方法，手势和姿势检测的性能可能会受到照明条件、图像分辨率以及用户和相机之间的距离等因素的影响。如表4所示，手势检测模型不需要针对每个手势标签改变手部位置。尽管使用相对较低的图像分辨率，模型仍实现了良好的识别准确性。然而，在使用深度学习技术的大规模手势识别系统中，通常需要更长的训练时间和更大的数据集以及手臂位置的显著变化，以提高模型准确性并支持更复杂的手势集，例如手语识别中使用的手势。为了在运行机器人导航堆栈的同时保持实时操作，实验期间降低了姿势和手势识别的图像分辨率。在128×96像素的图像分辨率下，系统的平均资源利用率为大约85%的GPU（3GB GPU内存）和60%的CPU（2GB CPU内存）。这种配置允许姿势和手势识别以大约每秒15帧的速率运行，而不影响算法准确性。将图像分辨率提高到256×256像素可以提高检测准确性，但会将GPU利用率提高到大约93%。这 negatively 影响了导航堆栈的处理性能和系统的整体实时操作。OpenPose框架还提供手部关键点检测和面部关键点检测。然而，结合这些额外的关键点会增加姿态估计流程的计算成本。由于我们的手势定义主要依赖于上半身关节，因此在当前实现中未使用这些额外的关键点。

4.3 多个人手势识别

我们进一步研究了在多个参与者存在的情况下手势识别模块的鲁棒性。在现实环境中，机器人可能会同时观察到几个人，这会在识别预期的交互伙伴时引入歧义。因此，该实验评估了系统在忽略机器人视野内的干扰因素的同时正确识别活跃手势者的能力。

4.3.1 实验设置

实验使用与单个人手势识别评估相同的环境设置进行。每个实验涉及两个参与者在机器人的视野范围内：一个作为活跃的手势者，另一个作为场景干扰者。系统在256×256像素的图像分辨率下运行，实现了大约每秒20帧的平均人类姿势估计率。评估了八种不同的交互场景。在每个场景中，活跃参与者执行了三种手势试验（Move Forward、Move Backward和Turn Left）。总共进行了24次测试。干扰者根据场景表现出不同的行为，包括静止站立、静止坐着、执行随机运动、复制活跃参与者的相同手势、执行冲突的有效手势、产生非有效手势（背景运动）、站在与机器人不同的距离、部分遮挡活跃手势者或执行无关的挥手手势。

4.3.2 识别结果

多个人手势实验的结果总结在表5中。表格报告了正确的主体识别率、手势识别准确率、由干扰者引起的干扰率以及机器人动作执行的成功率。当干扰者保持静止、坐着、执行随机运动、站在与活跃手势者不同的距离或执行与活跃用户相同的手势时，机器人成功执行了预期的动作，成功率为100%。然而，在涉及手势冲突或遮挡的场景中，性能下降。在这些情况下，系统尝试同时解释来自两个参与者的手势，导致手势分类不正确和机器人动作不稳定。因此，当干扰者与活跃手势者重叠或同时执行冲突手势时，机器人动作的成功率降至0%。

4.3.3 在干扰因素下的交互性能

为了进一步评估系统在多用户交互条件下的行为，我们计算了不同场景下的精确度、召回率和F1分数值。结果展示在表6中。在只有一个参与者提供手势且干扰者保持静止或执行无关运动的场景中，系统实现了100%的精确度和召回率，表明当单个活跃手势者清晰可见时，手势检测是可靠的。在两个参与者执行相同手势的场景中，系统实现了高召回率（100%），但精确度降低（50%），导致F1分数为66.7%。这表明系统成功检测到了有效的手势，但有时会错误地归因于干扰者执行的手势。**场景**

| 精确度（%） | 召回率（%） | F1分数 |
|-----------|-----------|---------|
| 闲置（单一手势） | 100 | 100 | 100 |
| 坐着的分心物 | 100 | 100 | 100 |
| 随机运动分心物 | 100 | 100 | 100 |
| 相同手势（2个用户） | 50 | 100 | 66.7 |
| 冲突手势 | 0 | 0 | 0 |
| 在遮挡/重叠期间 | 0 | 0 | 0 |

**4.3 失败案例讨论**
实验表明，当只有单个参与者与机器人主动交互或分心物表现出被动行为时，系统表现可靠。然而，多个主动手势的存在显著影响了识别性能。冲突的手势会导致机器人动作的波动，因为系统试图同时响应多个有效的命令。同样，遮挡或用户重叠会降低识别准确性，因为手势分类所需的骨骼关键点部分被隐藏。系统还会忽略那些没有站立和面向前方姿势的个体的手势，因为必须看到双眼才能激活手势交互。这些结果表明，额外的用户消歧机制（如持续姿势跟踪或基于注意力的过滤）将提高多参与者交互环境中的鲁棒性。

**4.4 多模态手势-语音命令仲裁**
该实验评估了基于手势的命令和基于语音的命令结合用于机器人控制的效果。目标是评估命令识别的可靠性、命令执行的正确性以及两种输入模式同时激活时仲裁机制的有效性。

**4.4.1 实验设置**
实验再次使用配备了差动驱动和轮式里程计的Ohmni Telepresence Robot进行。实验中，单个参与者发出手势和语音命令。手势模块和语音模块共享六个运动命令：向前走、向后走、向右转、向左转、向前走并右转、向前走并左转。手势模块还支持“服从”和“不服从”命令，而语音模块支持“停止”命令。“停止”和“服从”命令的作用类似，使机器人保持活跃但静止的状态，直到发出运动命令。“不服从”手势会禁用进一步的手势命令，直到重新激活。实验进行了30次，每种共享的运动命令各5次试验。在试验中交替使用命令来源（手势或语音），以评估多模态仲裁机制的鲁棒性。

**4.4.2 仲裁性能结果**
为了评估系统的仲裁行为，我们记录了检测到的冲突案例数量、选定的命令来源以及仲裁决策是否正确。仲裁日志和汇总统计数据显示，系统在所有试验中都保持了正确的仲裁行为。检测到六种手势和语音命令同时发出的冲突场景。在所有六种情况下，仲裁机制都成功选择了手势命令作为控制来源，冲突解决的成功率为100%。这些结果表明，仲裁机制确保了两种交互模式之间的兼容性，同时防止了机器人动作命令的冲突。

**4.4.3 延迟和冲突解决**
还记录了两种交互模式的延迟测量结果。手势识别流程的平均延迟为15.2毫秒，而语音流程的平均延迟为1317.4毫秒，主要是由于语音识别和语言模型处理。由于手势命令的识别速度明显快于语音命令，因此在仲裁机制中手势输入被赋予更高的优先级。当检测到手势命令而语音命令正在执行时，语音命令会暂时暂停，然后执行手势命令。此外，系统允许基于语音的“停止”命令中断之前执行的语音命令，即使语音流程被暂停，这样机器人也不会在手势模块不再具有优先控制权时恢复活动。这种机制确保了机器人可以立即停止，为人机交互提供了额外的安全保障。

**4.4.4 与单模态基线的比较**
为了评估多模态交互的实际优势，我们将提出的系统与仅使用手势控制和仅使用语音控制的单模态基线进行了比较。比较的目的是确定结合两种模式是否提供了超出单个界面性能的可测量好处。表格9总结了多个指标的结果，包括识别准确性、延迟、任务完成率、命令冲突率和紧急停止成功率。结果显示，单个模式达到了可比的识别准确性，手势交互的延迟显著低于语音交互。多模态系统保持了两种模式的优点，同时引入了防止命令冲突的仲裁机制。特别是，手势优先机制由于其低识别延迟，能够快速中断正在进行的动作，而语音界面提供了灵活的自然语言命令输入。因此，结果表明多模态控制提供了单一模式无法实现的互补功能。

**4.5 安全停止机制的鲁棒性**
为了评估系统在超出名义操作条件下的鲁棒性，我们在代表性的退化场景下评估了语音交互模块的行为。这些场景包括背景声学噪声和用户语音输入的变化，这两者都可能影响STT转录和LLM生成的结构化JSON命令。

**4.5.1 实验设置**
为了评估基于语音的STOP机制在复合或破坏性指令下的鲁棒性，我们进行了五次中断测试。在每种情况下，一个运动命令后立即跟随一个STOP或Halt指令。实验旨在确定机器人是否能够在到达命令目标位移或旋转之前安全地中断运动。成功的试验定义为机器人在没有超调或继续执行STOP命令后安全终止运动。

**4.5.2 中断性能结果**
在五次测试中，系统在四种情况下成功中断了运动（75%）。一个失败案例是由于STT识别错误，导致停止指令未被正确解释。在另一个案例中，尽管STOP命令最终被执行，但STT识别错误影响了运动命令的转录。这些实验展示了由背景声学噪声和用户语音输入变化引起的几种退化场景。语音到文本的输出可能受到诸如语调、发音清晰度、说话时长和用户发音差异等因素的影响。中断测试的结果总结在表10中。表格报告了原始人类命令、用于语音捕获的硬件、生成的STT转录、语言模型解释的命令、达到的运动目标、中断延迟以及STOP命令是否成功停止了机器人。

**4.6 本地和云LLM的命令生成比较**
该实验评估了本地部署的LLM与基于云的模型在提供可靠的结构化命令生成方面的能力。目标是评估JSON输出的一致性、响应延迟以及语音识别质量对命令生成的影响。

**4.6.1 实验设置**
实验设置与之前的评估部分相同，系统部署在Ohmni Telepresence Robot上。6名参与者与边缘部署的LLaMA 3.1 8B模型和基于云的GPT-3.5 Turbo模型进行了交互，以生成来自口语机器人命令的结构化JSON输出。在控制流程中，运动命令通过ROS执行，而LLM将识别到的语音转换为包含意图（例如，移动或旋转）和目标参数（例如，距离或旋转）的结构化命令输出。实验包括平移和旋转运动命令。参与者发出口语命令来指示机器人向前移动、向后移动或顺时针/逆时针旋转。每个命令都明确指定了运动意图以及目标参数，如行驶距离或旋转角度。对于两种LLM，我们使用了相同的口语命令进行了24次试验。目的是确定每个模型生成的有效JSON输出的频率。

**4.6.2 JSON生成性能结果**
表格11展示了本地LLM和基于云的LLM之间的定量比较。结果表明，本地LLMa 3.1模型的JSON有效性率为92.86%，与GPT-3.5 Turbo的96.43%相当。这表明本地LLM可以生成适合机器人控制的结构化命令输出，尽管准确性略有下降。

**4.6.3 延迟和STT影响分析**
延迟测量显示，本地LLM的响应延迟（1.15秒）低于基于云的模型（2.21秒）。在需要快速响应用户命令的机器人应用中，较低的延迟特别有益。相比之下，本地LLaMA模型观察到的0.6939相关系数表明，JSON的有效性不仅受到STT（语音转文本）准确性的影响，还受到模型内部语言解释能力的影响。这种差异源于LLaMA 3.1对短语和词序的语义敏感性。例如，STT输出“Move Ford 1 meter”始终产生了正确的JSON目标值，而“Move to meters backwards”则导致目标值不完整。这些观察结果表明，JSON的有效性取决于转录质量以及识别出的短语与模型交互过程中使用的提示示例的匹配程度。两项改进可以进一步提高JSON生成的准确性：（i）改进语音识别和自然语言处理流程，通过拼写纠正和规范化常见的语音识别错误（例如将“ford”纠正为“forward”，将“to”纠正为“two”）来减少转录错误；（ii）扩展提示示例，以改善语言模型对运动命令的理解。最后，使用本地LLM可以显著降低运营成本，并消除对云API调用的需求。在我们的实验中，使用GPT-3.5 Turbo生成命令的估计成本为0.0356美元，而本地LLaMA模型则无需支付API使用费用。由于LLM推理被应用于机器人系统的多个组件中，避免重复的云调用可以带来显著的运营节省，同时还能提高延迟并保护数据隐私。

5 结论

我们研究了使用ROS 1框架处理、通信和模块间冲突仲裁的多模态手势和语音导航控制，以实现物理机器人的控制。通过结合口头和非口头交流线索，我们展示了移动机器人上人机交互的改进。手势和姿态检测是通过OpenPose模型实现的，而语音交互则通过由WWD、STT引擎和本地托管的LLM组成的语音交互模块实现的。这种方法减少了延迟，避免了API成本，并实现了与GPT-3.5 Turbo相当的运动命令生成准确性。我们的评估显示，尽管LLM可以从错误的输入中推断出正确的输出，反之亦然，但它仍然容易出错，即使输入正确也是如此。实验验证了该系统在实时操作中的可行性，并指出了算法的准确性限制。虽然我们的结果在受控的办公环境中显示出较高的准确性，但还需要在不同的照明条件、更广泛的手势集以及不同自然语言下进行进一步验证。这些因素可能会影响手势识别和结构化文本生成的性能，未来的工作将扩展我们的评估以解决这些问题。评估的另一个方向是在更具挑战性的场景下测试人机交互系统的鲁棒性，包括桌子或笔记本电脑、纸张等手持遮挡物造成的部分遮挡，这些因素可能会降低上半身的识别能力。此外，我们计划结合姿态跟踪以实现持续的单用户交互，并通过集成语义地图和地形图来扩展环境感知能力。这将使机器人能够理解高级导航目标（例如“去充电站”），并在办公环境中支持更自然的语音协作。此外，我们打算进行用户研究，以更深入地了解认知工作负载、用户体验和系统可用性在真实办公环境中的表现。我们还计划在动态多人条件下进行系统压力测试。

致谢

我们感谢Vinayak Vishwas的贡献，他在应用系统架构研究所完成了他的硕士学位论文，并进行了有助于当前研究的评估工作。在准备这项工作时，作者使用了ChatGPT 5.3来润色自撰文本。使用该工具后，作者根据需要对内容进行了审阅和编辑，并对作品内容负全责。

资金支持

部分由德国学术交流服务（DAAD）和尼日利亚石油技术发展基金（PTDF）提供。

财务披露

无报告。

利益冲突

作者声明没有利益冲突。