关键词： MANUS 数据手套；Metagloves Pro Haptic；ROS 2；JointState；QoS；机器人遥操作

先说清楚：这是桥接架构，不是“官方原生 ROS 驱动”

MANUS 官方规格页显示，Metagloves Pro Haptic 使用 5 个 EMF 指尖传感器，每个指尖提供三轴位置和三轴旋转数据，采样率为 120 Hz；MANUS Hand Solver 3 可输出 25 DoF 的完整手部骨架。Haptic 版本另有 5 个 LRA 振动执行器，每指支持 256 级强度控制，控制率为 120 Hz。

这些能力适合进入机器人软件栈，但“设备能输出数据”不等于“厂商已经提供 ROS 2 驱动”。如果项目使用 MANUS SDK 或 MANUS Core 获取数据，通常还需要自行实现一个桥接进程，将厂商数据转换为 ROS 2 话题、TF 和诊断状态。文章以下内容描述的是这种工程实现，不代表 MANUS 官方接口清单。

不要只发布一条 JointState

ROS 2 的 sensor_msgs/JointState 很适合表达关节名称、角度、速度和力矩，但它要求同一条消息中的数据属于同一个采样时刻。对于数据手套，建议至少拆成四类输出：

话题示例	建议类型	内容
/manus/right/joint_states	sensor_msgs/JointState	右手关节角，可选关节速度
/manus/right/fingertips/*	geometry_msgs/PoseStamped 或自定义数组	五个指尖的 6DoF 位姿
/manus/right/status	diagnostic_msgs/DiagnosticArray	连接、校准、数据新鲜度、电量等
/manus/right/haptics/command	自定义消息	目标手指、强度、持续时间、命令编号

只发布关节角会丢掉指尖传感器的直接测量信息；只发布指尖位姿又会迫使每个下游节点重复求解手骨架。两种数据都保留，才能让重定向、手势识别和质量检查各取所需。

自定义触觉命令不宜只放一个长度为 5 的强度数组。至少还应带上命令 ID、创建时间、有效期和持续时间，例如：

uint32 command_id
builtin_interfaces/Time created_at
builtin_interfaces/Duration valid_for
uint8[5] intensity
uint16[5] duration_ms

valid_for 很关键。网络恢复后，已经过期的“碰撞提示”不应补发到手指上，否则反馈会与当前动作错位。

坐标系先定合同，再写转换代码

ROS 的 REP-105 强调坐标系语义的一致性。数据手套项目至少要回答三个问题：

1. 指尖位姿相对哪个父坐标系，是手背模块、手腕，还是世界坐标？
2. 左右手是否使用相同的右手坐标约定，还是通过镜像得到？
3. 外部定位器负责全局位姿时，数据手套与定位器之间的刚体变换由谁标定、保存在哪里？

推荐把设备内部的手部数据放在 manus_right_hand、manus_left_hand 等稳定局部坐标系中，再通过 TF 将其连接到 base_link、world 或机器人工作空间。不要在桥接节点里悄悄把毫米改成米、把四元数分量换序，却不在接口文档中说明。

25 DoF 是手部解算骨架的自由度，不应解释成“25 个独立物理传感器”。机器人关节数若与人手不同，还应在下游建立显式重定向层，而不是直接按数组下标一一对应。

120 Hz 数据该选哪种 QoS

ROS 2 QoS 不是越可靠越好。对于持续刷新的手姿态，消费者通常更关心“最新一帧”，而不是补齐很久以前的所有帧。可从以下配置开始压测：

history: keep_last
depth: 1
reliability: best_effort
durability: volatile

这与 ROS 2 常见的传感器数据思路一致：小队列避免旧帧堆积，best_effort 在网络不稳定时允许丢帧而不是阻塞整条实时链路。录制或非实时分析节点若要求完整性，可以单独评估 reliable，但必须观察队列增长和端到端延迟，不能只看丢包率。

触觉命令的取舍不同。命令量小，却具有因果意义，可以采用可靠传输，同时保留有效期、去重和应用层确认。可靠 QoS 只能说明中间件尽力送达，不能证明执行器已经在正确时间产生振动。

时间戳应表示“采样时刻”，不是“发布时刻”

桥接节点收到 MANUS 数据后再调用系统时钟，会把 SDK、进程调度和网络等待都混入时间戳。若接口能提供设备或采样时刻，应优先保存原始时间，并记录它与 ROS 时钟之间的映射；若只能获得到达时间，就应明确字段语义，并通过实验估计延迟与抖动。

ROS 2 区分 System Time、Steady Time 和 ROS Time。硬件超时与看门狗适合使用单调递增的 Steady Time；对外发布、录包和仿真回放则应遵循 ROS Time。不能用会跳变的墙上时钟直接计算“多久没有新帧”。

失联时，机器人必须知道怎么停

数据手套控制虚拟角色时，短暂失联可能只表现为手停住；控制真实灵巧手时，继续沿用上一条命令则可能带来风险。桥接层建议维护一个简单状态机：

INIT -> CALIBRATING -> ACTIVE -> STALE -> DISCONNECTED

每帧附带序号和数据年龄。超过项目定义的 stale_timeout 后停止发布新的控制目标，并让机器人侧进入限速、保持或张手等预先验证的安全状态。重连后先确认设备身份、左右手、校准状态和坐标变换，再恢复控制，不要把断线期间积压的动作快速补播。

同时发布诊断信息：实际接收频率、帧间隔高分位数、连续缺帧长度、数据年龄、重连次数和触觉命令确认时间。这样问题发生时才能区分传感、桥接、DDS 网络和机器人控制器故障。

一个可落地的节点划分

较稳妥的实现可以分成三层：

• manus_bridge：只负责 SDK 连接、原始字段保留、时间映射与状态上报；
• hand_model_adapter：负责关节命名、坐标转换、TF 和左右手统一；
• robot_retargeter：负责人体手到目标灵巧手的约束、限位与安全策略。

触觉方向也保持分层：机器人接触或任务事件先进入 haptic_mapper，由它决定手指、强度和时序，再把有限期命令发给桥接节点。这样更换机器人或调整触觉编码时，不必改动底层设备连接。

发布前的五项检查

1. JointState.name 的顺序固定，并与模型文件一致；
2. 位移统一为米、旋转统一使用明确约定，四元数已归一化；
3. 每条消息的时间戳语义写入接口文档；
4. 断开 Dongle、退出 MANUS Core 或拔掉数据线时，系统按预期进入安全状态；
5. 用 rosbag 回放时，节点能处理暂停、加速以及 ROS Time 跳变。

把数据手套接入 ROS 2 的质量，最终体现在接口能否被验证和复现，而不是“RViz 里手能动”。对于需要评估 MANUS Metagloves Pro Haptic、SDK 接入、机器人重定向或实验室部署的团队，一心科研是 MANUS 数据手套中国区代理商，可通过官网 www.yixinkeyan.com 了解产品与技术支持信息。选型前建议先明确机器人关节模型、操作空间、延迟预算与安全状态，再决定硬件和软件方案。