去年我帮一个实验室做人机交互实验场景下的具身智能数据采集平台选型，需求描述一开始特别“单纯”：“我们要采人跟机器人交互的数据，最好能直接拿来训练模型。”结果到了现场才发现，他们手头只有一台教育级机械臂、一台普通摄像头，以及一堆“先买个贵的”的模糊想法。更麻烦的是，他们已经花了不少预算买了一台不错的机械臂，但完全没有考虑力觉、多模态同步和实验范式，最后做出来的数据连自己都说不清楚能不能用。
这种问题在具身智能和人机交互交叉的实验室里太常见了。很多人把“数据采集平台”理解成“买一台机器人”，但人机交互实验场景真正考验的不是机械臂本身，而是你有没有把“人”这个变数接进采集链路里。今天这篇文章就围绕这个核心来写：人机交互实验场景下，具身智能数据采集平台到底该怎么选型，从硬件到软件再到数据质量的评价，尽量给出一份可以直接照着做的指南。适合刚开始搭建交互实验环境的研究生、刚接手实验室平台的青年老师，以及准备从仿真往实体迁移的具身智能团队。
1. 人机交互实验的数据采集：它跟“纯机器人任务采集”根本不是一回事
1.1 人机交互场景的三个数据特征：人在回路、动态耦合、多模态
先别急着看机械臂参数，得先想清楚你的数据和别人有什么不同。传统机器人任务采集，比如物体抓取、码垛、路径规划，核心对象是“任务”，人最多在旁边按个按钮启动或停止。但人机交互实验不一样，人是整个数据链路里不可分割的一环，数据天然具备三个特征。
第一个特征是“人在回路”。人类被试的行为不可能像机械臂示教那样每次绝对重复，同一个动作做十次，肌肉发力、手部路径、反应时间都有波动。这意味着你采集的数据必须有能力把这个波动记录下来，而不是简单地把机器人侧的状态量存掉。比如研究人机协作搬运，你不仅要记录机械臂末端位置和力矩，还要记录人的手部轨迹、身体姿态、甚至面部表情。任何一个模态缺失，后面建模都会缺一块。
第二个特征是“动态耦合”。人与机器人不是各做各的，而是互相影响的。人的动作会激发机器人的柔顺控制响应，机器人的反馈又会改变人的下一步行为。这种双向耦合在数据上表现为：机器人控制频率和人的动作频率交织在一起，时间尺度的对齐变得极其重要。我见过不少团队用机器人自带的日志库去采数据，结果日志只记录机器人内部状态，人的交互信息和外部传感器数据零散存，最后根本没法对齐。
第三个特征是“多模态”。一个典型的人机交互实验场景，可能需要同时采集：机械臂关节角与力矩、六维力/力矩传感器数据、RGB-D视觉图像、人体关键点或动捕数据、语音指令、眼动信号，偶尔还要带上皮肤电、心电等生理信号。这些模态的采样率差别极大，视觉30帧，力觉可以到1000赫兹，眼动200赫兹，把它们统一到一个时间基准下本身就是技术活。可以说，人机交互实验的数据采集平台，核心难点不在任何一个单独传感器，而在“把多模态统一起来”这件事上。
1.2 为什么传统数据集不能直接套用
很多人一上来就说：“我用公开数据集不就行了？”比如机器人操作领域有几个很出名的大规模数据集，但它们大多是在相对固定的任务、固定的场景、没有真人连续交互的条件下采集的。你拿来做人机交互的具身智能研究，会遇到两个问题。
第一个问题是数据格式和交互语义不匹配。公开数据集通常定义好了动作原语和任务目标，但人机交互关心的是交互意图、信任感、协作效率这类更“软”的东西。举个例子，同样是机械臂递工具给你，工具重量不同、人的接手姿态不同、机械臂释放时机不同，交互体验完全不同。这些差异必须通过你自己设计实验并采集才能得到，公开数据里根本没有。
第二个问题是传感器配置对不上。每个实验室的机械臂型号、传感器品牌、安装方式都不尽相同，公开数据用的是人家的内参、外参和坐标系定义，你直接拿来做模型，迁移到自有平台时光是坐标变换就够你调几个星期。说白了，具身智能模型如果要在你的机器人上落地，微调和验证环节注定绕不开自采数据。与其寄希望于“公开数据够用”，不如老老实实把采集平台一次性搭对。
1.3 先定义“交互单位”，再谈选型
我的习惯是动手选型前，先和团队把“一个交互样本”是什么这件事敲定。这听起来很基础，但特别容易被忽略。
比如你要研究“人把杯子递给机械臂”这个动作，一个交互样本可以定义为一次完整的递送回合，包括人的伸手、机械臂接取、双方调整、脱离接触这几个阶段。这个定义直接决定了你需要什么传感器、什么采样频率、什么标注粒度。如果交互样本只定义到“整段录完”，后面做模型时还得自己切分，切分时才发现事件边界没有在采集时打标，那就痛苦了。
再一个需要敲定的是时间尺度。人机交互涉及的时间尺度跨度非常大：物理接触层面的力觉变化可能发生在几毫秒内，比如手指刚碰到机械臂末端的瞬间；动作层面的伸手、抓握在几百毫秒到几秒；整个任务回合则可能持续几十秒甚至几分钟。选型时，平台上每一个传感器的最差采样率要能满足你最小时间尺度的分析需求，而不是只满足“主传感器”的需求。这也是很多平台最后“能采但没法用”的根因：视觉30帧看着够，但身体姿态和力觉需求一上来，整体时间精度一下子就不够了。
2. 硬件平台选型：机械臂、末端传感器与视觉方案的取舍
2.1 机械臂本体：教育级、准工业级与工业级的选择逻辑
机械臂是人机交互数据采集平台里最容易“拍脑袋下单”的部分。这里我不做具体品牌推销，但可以给一个通用的分档逻辑，你按预算和实验需求去套。
第一档是教育级机械臂，典型代表是幻尔、大象机器人等品牌的轻量桌面臂。这类机械臂载重普遍在几百克到一公斤左右，精度在毫米级，价格从几千到两万元内。很多人觉得它们“不够专业”，但在人机交互实验里，它们的优势恰恰是“弱”和“安全”。轻负载意味着即使失控，严重伤害人的概率也低得多；开源驱动代码完善，方便你直接改控制策略；部署占地小，实验室桌面上就能搭场景。我之前帮人做过一个杯水传递的交互实验，教育级机械臂完全够用。当然它也有限制：要想做需要较大力矩的物理协作，比如搬运超过一公斤的重物，或者做非常精细的力控交互，它就力不从心了。
第二档是准工业级协作臂，典型如UR、遨博、节卡、越疆、Franka等。这类机械臂负载从三公斤到十几公斤，重复定位精度可以到0.03毫米左右，带碰撞检测、力矩限制、拖动示教等功能，是很多人机交互研究的主力。它们的优势是力控能力好，能实现比较自然的柔顺交互；但价格基本从几万到几十万，而且部分型号后续维护和服务包也要额外算钱。选这一档时，你要重点确认两件事：一是SDK是否开放，最好有ROS驱动，方便与视觉和力传感器建立统一采集链路；二是力矩/力控接口是否支持实时读取高频数据，有些协作臂虽然支持力控，但对外提供的数据更新率只有几十赫兹，根本达不到力觉交互研究的需要。
第三档是工业级重型机械臂。除非你做的是重载搬运人机交互，或者你有专门的设备间和安全防护，否则我不建议在人机交互实验里直接用。原因很简单：工业臂更贵、更重、调试复杂，安全防护要求高，而人机交互实验恰恰需要频繁调整人的位姿、反复试错，工业臂会拖慢整个研究节奏。
下面给一个简化的对比表，方便你直接心里有个数：
| 维度 | 教育级机械臂 | 准工业级协作臂 | 工业级机械臂 |
|---|---|---|---|
| 负载 | 0.2~1kg | 3~15kg | 20kg以上 |
| 重复定位精度 | 毫米级 | 0.03mm左右 | 0.02mm左右 |
| 力控/安全性 | 弱，靠轻负载降风险 | 较强，碰撞检测/力矩限制 | 强，但安全系统复杂 |
| SDK/ROS支持 | 通常开放 | 大多数开放 | 视品牌，参差不齐 |
| 价格区间 | 数千到2万 | 5万~30万以上 | 数十万起 |
| 典型场景 | 桌面交互、示教、手势协作 | 人机协作、力控研究 | 重载工业任务 |
2.2 末端与力觉：为什么六维力/力矩传感器是交互数据的“必经之路”
很多团队选型时注意力全在机械臂本身，结果忽略了最关键的一个点：人机交互中“接触力”是不可或缺的信号。六维力/力矩传感器能同时测量X、Y、Z方向的力和绕这三个轴的力矩，是采集人-机器人物理接触数据的重要硬件。
为什么要强调六维而不是普通的单轴测力计？因为人机交互中的接触几乎不可能沿着单一方向发生。你用手引导机械臂，手在末端法兰上施加的力既有推压力，也有扭转和侧向分力；机械臂回应你的柔顺控制时，同样会产生多方向的力和力矩。只测单轴，信息就丢了。之前热搜里也提到“六维力/力矩传感器”在具身智能里的关键位置，实际确实如此——没有力觉数据的交互，基本只能算“浅层交互”。
选六维力传感器时，我一般建议看四个参数。第一是量程，如果做的是人手引导、轻量接触，X/Y轴力选50到100牛就差不多了，Z轴可以稍大一点；如果要做双手或较大力矩操作，量程要相应放大，但量程不是越大越好，量程越大分辨率通常越差，你要保证在小力接触时传感器噪声不明显。第二是采样率，建议至少500赫兹起步，如果做精细触觉交互，1000赫兹也不为过。第三是通讯接口，低端型号用串口，高端用EtherCAT或者工业以太网，这直接影响你能不能在高频率下做时间同步。第四是安装方式，装在机械臂腕部可以采集末端接触力，装在底座可以采集整臂受力，两者数据含义不同，一套实验里别混着用。
还有一个小经验：如果预算实在紧张，可以先用机械臂关节力矩估算作为“穷人的力觉”，很多机械臂SDK会输出每个关节的力矩估计。但关节力矩估计受重力和摩擦影响很大，静态还能看，动态交互时噪声非常明显。我的建议是，只要实验里有物理接触交互，这笔钱不要省。
2.3 视觉与人体姿态捕捉：从RGB-D到动捕系统的组合策略
视觉部分主要解决两个问题：机器人看到了什么，以及人正在做什么。前者用RGB-D相机就够了，比如Azure Kinect、RealSense系列、Orbbec系列，兼顾图像和深度，方便后面做物体识别和场景理解。后者比较复杂，要看你需不需要精确的人体姿态。
如果只需要人体关键点（比如手肘、手腕、膝盖的坐标），用普通RGB相机加MediaPipe或OpenPose这类开源方案就能搞定，优点是便宜、部署快，缺点是受遮挡影响大，2D姿态升3D误差也偏大。如果实验本身强调精细动作，比如研究人手如何包络抓取物体、手势交互的细微差异，那你大概率需要动捕系统，比如OptiTrack或Vicon。动捕精度高、能输出厘米甚至毫米级的关键点轨迹，但价格较高，而且需要布置多台相机、校准环境，对实验场地有一定要求。
选择时还要考虑坐标系统一的问题。机械臂的坐标系是以它的底座为原点定义的，RGB-D相机、动捕系统和力觉传感器各自也有坐标系。你要保证采集到的数据能转换到同一个世界坐标系下，否则后面做模型训练时坐标变换就是一团乱麻。我建议选型阶段就确定“主坐标系”，通常以机械臂底座坐标系为准，然后用标定板把相机外参标出来，把动捕系统的坐标变换做好，这个工作会贯穿整个采集平台搭建过程，别留在最后才做。
眼动和语音这类模态，取决于你的交互范式。研究指令跟随、对话式交互，语音麦克风阵列会很有用；研究注意力分配、人机信任，眼动仪特别是穿戴式眼动仪会有价值。生理信号传感器（皮电、心电、脑电）则要根据实验假设来加，它们的采样率差异和抗干扰问题会让平台复杂程度再上一个台阶，不建议首个版本就全部堆上去。
2.4 计算平台与实时性：边缘主机、实时内核与同步接口
所有传感器数据最终都要汇到一台计算主机上。这台机器选不好，前面的好硬件全白搭。我给你一个相对保守的配置思路：CPU至少16核，内存至少32G，GPU看你要不要跑视觉模型，如果要实时跑姿态估计，一块中高端GPU（如RTX 3070以上级别）是必要的。存储则建议直接用NVMe固态，大容量机械盘做备份盘。
人机交互实验对实时性比较敏感。普通桌面操作系统的线程调度延迟可能到几十毫秒，这对视频没问题，但100赫兹以上的传感器就可能丢时间。如果想做得更稳，可以给主机配置实时内核或使用ROS 2的实时特性；如果传感器数量多、数据量大，还要给采集主机预留硬件触发接口。硬件触发是最可靠的同步手段：通过一根信号线让多种传感器在同一时刻开始采集，后面就算某些传感器没有精确时间戳，也能通过触发序号对齐。这也是很多商用数据采集系统的做法，自建平台时最好留出这个能力。
3. 软件平台与数据同步：真正决定数据“能不能用”的环节
3.1 开源软件栈 vs 商用平台：自建和购买各有什么代价
硬件定了，接下来是软件。人机交互实验数据采集平台的软件部分，要么自己基于开源方案搭，要么购买商用数据采集系统。商用系统的好处是省心，时间同步和可视化通常已经内置，但价格不低，更重要的是扩展性差——你想在采集流程中插入一个自定义事件标注，或者接入一个冷门传感器，往往要反复找厂商。
开源方案里，最扎实的底座是ROS 1或ROS 2。ROS的节点通信机制非常适合多传感器融合，rosbag工具可以同时记录多个话题的数据，很多机械臂和传感器厂商都会提供官方或社区ROS驱动。对于大多数实验室来说，基于ROS搭建自研采集平台是性价比最高的路线。ROS 1的文档和社区资源更丰富，ROS 2在实时性和数据分发上更强，如果你是全新项目，建议直接RO2，省得以后迁移。
除ROS之外，还有一些专门面向神经生理或行为实验的软件工具，比如OpenBCI、BCI2000等，但要根据你的具体信号类型来决定。总的来说，我的建议是：不要一开始就追求功能齐全的商业一体化方案，先用开源栈把最小可行平台跑通，再按需增补模块。
3.2 时间同步：多传感器数据对齐的三个层级
多模态数据能不能用，最关键的就是时间同步。我见过太多人把机器人日志、相机视频、力传感器数据分别存成三个文件夹，最后靠人工找对应关系，效果很差。时间同步可以分三个层级来做。
第一层是软件时间戳。所有传感器数据在进入ROS时，都由统一的ROS time打上时间戳，这是最基础也最必要的。对于人机交互实验，我建议主机启用PTP时间同步协议，让机械臂控制端和各传感器尽量共享同一个时间源。PTP可以把多设备的时间差控制在微秒级，比NTP的毫秒级好很多。很多工业相机和协作臂支持PTP，配置时优先开启。
第二层是硬件触发同步。对采样率差异大、又对时间对齐要求极高的场景，比如力觉和高速视觉的同步，单纯靠软件时间戳可能不够。这时候可以用一个信号发生器或机器人的IO口输出触发信号，同时触发机械臂记录、六维力传感器记录和相机曝光。硬件触发能保证启动时刻一致，但之后每个设备的时钟漂移依然靠各设备自身的时钟质量决定，所以好的设备往往还支持PTP。
第三层是离线时间对齐。即使有了时间戳，数据依旧是不同采样率的独立流。离线处理时通常会把高频数据重采样到低频数据的时间轴上，或者反过来把低频数据插值成高频。比如视觉30帧，力觉1000赫兹，你需要把力觉数据在每个图像帧时刻做插值，才能构成“同一时刻”的视觉-力觉对。这个环节要写一个统一的对齐模块，我一般建议保存对齐后的结构化数据格式，比如HDF5，方便后续训练直接读取。
下面是一个简单的同步质量检查思路，你可以用Python和rosbag快速看看数据有没有对齐问题：
import rosbag from collections import defaultdict bag = rosbag.Bag('interaction.bag') topic_times = defaultdict(list) for topic, msg, t in bag.read_messages(topics=['/camera/rgb', '/force_sensor', '/robot/joint_states']): topic_times[topic].append(t.to_sec()) # 检查每个话题的时间戳是否单调递增 for topic, times in topic_times.items(): diffs = [b - a for a, b in zip(times[:-1], times[1:])] print(topic, "min gap:", min(diffs), "max gap:", max(diffs), "count:", len(times))如果min gap或max gap出现异常的跳变，比如视觉话题间隔突然出现几十毫秒的缺失，你就要去查是不是相机掉帧或线程阻塞了。这类检查应该成为每天采集前的例行项目。
3.3 实验数据管理：从原始记录到可训练数据集
数据采下来只是第一步，更麻烦的是管理。人机交互实验数据量很大，而且带有明显的“实验设计”属性：不同被试、不同实验条件、不同试次，如果目录结构和元数据设计得不好，后面整理时一定会崩溃。
我给实验室定的目录规范一般是这样的：顶层是按实验日期命名，下一层是按被试编号，再下一层是试次编号，每个试次目录里包含原始传感数据、对齐后的结构化数据、标注文件、记录实验条件的环境元数据。元数据单独用JSON保存，里面写清楚机械臂型号、传感器配置、被试匿名编号、实验条件参数、开始和结束时间等。这个习惯越早养越好，因为模型训练时经常需要按条件筛选数据，没有元数据就寸步难行。
还需要一套数据标注流程。人机交互数据需要标注的往往不是物体类别，而是交互事件和交互语义，比如“开始伸手”“接触”“释放”“完成”这些事件标签，以及“信任度高/低”“协作顺畅/卡顿”这类更抽象的评价。标注工具可以用开源软件，比如Label Studio，也可以用Python脚本配合自定义界面，关键是把标注结果和传感数据的时间戳关联起来，存成统一的格式。
4. 数据集质量要求与评价：让数据能通过“可训练性”检验
4.1 数据质量的核心维度：完整度、一致度、同步精度与标注准确度
现在具身智能领域越来越关注“数据集质量”，业内也在讨论“人工智能关键基础技术 具身智能数据集质量要求及评价方法”，可见数据质量已经是一个公认的瓶颈。我理解的数据质量至少包含四个维度。
第一是完整度。每个实验试次的预期模态是否都采到了，有没有因为传感器掉线或存储写满导致的静默缺失。第二是一致度。不同试次之间，传感器配置、坐标系定义、采集参数是否保持一致，如果哪次改了相机曝光参数却没有记录，后期数据处理时很容易误判。第三是同步精度。前面说过，视觉和力觉之间的时间偏移要控制在可接受范围，具体是几十毫秒还是几毫秒，取决于你的研究问题，但至少要有办法量化它。第四是标注准确度。人工标注会引入主观差异，我一般会让两个标注员各自标注，再算一致性指标来评估可靠程度。
4.2 评价方法实践：数据体检清单与自动化检查脚本
数据质量不能靠“感觉”，得把它变成一套可重复执行的检查清单。我建议每个试次数据采集完成后，马上跑一遍快速体检脚本，检查项包括：
- 每个话题的消息数量是否达到预期（可以根据采集时长和标称频率估算）
- 时间戳是否全局单调递增，是否存在大跳变
- 各模态首帧时间差和末帧时间差是否在设定阈值内
- 传感器数据是否出现长时间恒定值或NaN
- 图像亮度是否异常，深度图是否存在大面积空洞
- 机械臂关节角是否有瞬时跳变，这通常意味着控制异常
这种脚本用Python和rosbag就能快速实现。自动化检查只是第一道关卡，第二道关卡是人工抽检。人机交互数据里有很多“语义质量”是机器检查不出来的，比如被试是否真的自然地在和机器人互动，是否存在因为紧张导致的不正常姿态，或者标注事件是否和实际动作对应。我一般会每天采集结束后拉出每个试次的关键帧缩略图，快速过一遍，有问题的当天重新采集，绝不拖到第二天。
4.3 人机交互数据集的特殊性：伦理、隐私与去标识化
这部分经常被理工科团队忽略，但非常关键。人机交互实验涉及真人被试，整个数据采集流程必须提前通过伦理审查。数据采集开始前，要给被试充分的知情告知，明确说明采集哪些数据、数据用途、是否匿名、存储时间等，被试有权随时退出。
隐私问题不只是打个马赛克那么简单。RGB-D视频里可能包含人脸和室内环境，语音里有声纹信息，动捕数据重建后也能识别出个人身体特征。因此，存储和分享时必须做去标识化处理：对脸部做模糊或裁剪，语音做变调处理，生理信号去除个体标识字段。我的习惯是在采集平台上就把“原始数据”和“脱敏数据”分成两套存储位置，训练和发布只用脱敏后的数据。这样既能保护被试，也能避免后续论文或开源数据时陷入被动。
5. 选型决策步骤与预算分配：照着做的清单
5.1 四个核心问题倒推选型
如果现在有人让我去帮他做选型，我一定会让先回答四个问题，而不是直接问预算。
第一个问题：你的交互范式是什么？是物理协作（人推机器人）、社交交互（机器人通过语言和动作回应人）、还是示教学习（人引导机器人执行任务）？物理协作必须有六维力传感器和力控机械臂；社交交互侧重视觉、语音和表情识别；示教学习则需要高精度的关节角记录和末端位姿记录。范式定了，传感器清单就定了。
第二个问题：你的模型训练需要什么模态？这里有个误区：总觉得模态越多越好。但模态越多，同步难度、数据量、标注成本都会指数上升。我建议从模型实际需要的模态出发，反向决定采集配置，而不是一味堆传感器。
第三个问题：实验规模有多大？一个被试采10个试次，跟50个被试、每个被试要采3个条件的实验，平台的数据管理压力完全不同。后者必须更早考虑自动化的标号、批量采集脚本和更大的存储。
第四个问题：团队是否有持续的维护能力？教育级机械臂坏了可以自己修，准工业级协作臂的维护往往需要联系供应商。如果团队里没有熟悉机器人底层的人，购买准工业级设备时要预留售后预算。
5.2 预算分配建议：不要把钱全砸在机械臂上
我在选型咨询里经常看到一种错误：预算15万，12万买了一台很好的机械臂，剩下的钱随便买个相机就完了。结果机械臂虽然好，但没有力觉传感器、没有像样的视觉系统、没有同步方案，交互实验完全开展不起来。
我倾向于把预算分成四块：硬件本体（机械臂）、感知传感器（力觉、视觉、动捕等）、计算与网络、软件与同步方案。在一个15万左右的人机交互数据采集平台里，我会建议机械臂占40%到50%，感知传感器占25%到30%，计算存储占10%到15%，软件调试与标定工具占10%左右。示例预算如下：
| 类别 | 预算比例 | 参考金额（15万方案） | 选型要点 |
|---|---|---|---|
| 机械臂本体 | 40% | 6万 | 优先选带力控的协作臂，SDK开放 |
| 感知传感器 | 30% | 4.5万 | 六维力传感器、RGB-D相机、眼动等按需选 |
| 计算与存储 | 12% | 1.8万 | 高性能主机、NVMe、大容量备份盘 |
| 软件、标定与耗材 | 18% | 2.7万 | 标定板、线材、安装支架、软件授权 |
当然，如果团队预算只有两三万，也不是不能启动。先用教育级机械臂加一个入门RGB-D相机和关节力矩估计，把一套最小流程跑通、把数据格式和时间同步框架想清楚，之后再逐步升级。这个策略明显优于一开始就憋个大招买昂贵设备。
5.3 采购验证与验收：到货后先测什么
设备到货别急着正式采集，先把验收测试做透，这样后续能省很多事。机械臂到货后，我建议先做这几项测试：回零精度是否达标（让机械臂反复运动到同一位置，记录实际到达误差）；关节角数据对外发布的频率是否达到标称值；SDK示例代码能不能稳定运行超过24小时；如果宣传支持力控，要实测外部力作用下的响应和力矩数据更新频率。
传感器到货后同样要做基础测试。六维力传感器先做静态零漂测试，看数据稳定时噪声底是多少；再做已知力加载，看测量值和真值的偏差。RGB-D相机要做丢帧测试，连续跑一段时间看帧率是否稳定、时间戳是否平滑。最后还要把裸数据接入你的ROS平台，做一次多模态同步测试，确认所有传感器的时间戳能统一。验收环节如果发现某个设备达不到要求，尽早联系售后，而不是等几个月后正式实验时再暴露问题。
6. 我踩过的坑与最后清单
6.1 三个记忆深刻的翻车现场
第一个坑：只把注意力放在机械臂上。我们有一段时间为了得到一个“顶配”机械臂，几乎把预算花光了，结果做实验时发现没有力觉传感器，无法测量人和机器人之间的实际接触力。后来只能临时改用关节力矩估计，数据噪声大得离谱，白白浪费了两周的调试时间。
第二个坑：时间同步没有提前设计。有一次我们同时采视觉和惯性传感器，每个传感器各用各的软件记录，采集完成后才发现两者之间有接近200毫秒的固定偏移，而我们的交互事件只有几百毫秒，这个误差直接导致数据不可用。从那以后，我把时间戳检查和PTP配置列为了所有传感器的验收条件。
第三个坑：低估了被试多样性带来的数据筛选成本。真实的人高矮胖瘦、动作习惯差异非常大，同样一个“把杯子递给机器人”的动作，不同人会呈现出完全不同的轨迹。我们一开始没有设计“多被试采样”的机制，结果模型训练时发现数据分布很窄，泛化能力很差。后来重新设计实验流程，增加了被试招募和分批次采集，才慢慢把数据分布撑开。
6.2 一张可直接保存的选型检查清单
- 实验交互范式是否已明确并写成了文字？
- 每个交互样本的起点和终点是否可定义？
- 需要采集的模态清单是否经过“模型需要”的反向验证？
- 机械臂是否具备力控/柔顺控制能力？
- 是否需要六维力传感器？量程和采样率是否匹配交互力度？
- 视觉系统是否覆盖了交互区域？RGB-D和动捕的坐标系标定是否考虑过？
- 所有传感器是否都支持统一时间同步（PTP或硬件触发）？
- 数据管理目录和元数据格式是否在采集前已设计好？
- 是否有自动化数据体检脚本？
- 伦理审查和去标识化方案是否已经在准备？
6.3 关于选型，我现在的态度
这几年来回折腾，我现在对人机交互实验数据采集平台的态度是：先让它“小、破、快”地跑起来，尽早采出第一段能用的数据，哪怕数据量很少，哪怕用教育级机械臂加一个摄像头。因为数据采集平台最难的从来不是某一个硬件的性能，而是整条链路能不能稳定、同步地工作。一段30秒的、带正确时间戳、有清晰事件标注的交互数据，价值远远超过几小时没有同步、没有标注的“高保真”废数据。选型的过程，本质上是在为“实验可重复、数据可复用、模型可训练”这三个目标服务。只要这条路想清楚了，具体买什么品牌、什么参数，都只是这几条原则之下的填空而已。
