做具身智能研究这两年我最大的感触就是数据采集这一环被严重低估了。大家兴致勃勃地讨论算法结构、模型参数量、仿真环境但真正走进实验室对着真机一天天采数据的时候问题全冒出来了——示教时末端抖动导致动作轨迹不干净相机和机械臂的时间戳对不上采了好几个星期的数据拿来训练模型换个场景就失灵。这些问题不是偶然翻车而是非标准化采集必然带来的代价。我们团队在高校科研所从零搭建了一套标准化具身智能数据采集实验方案从硬件选型、标定流程、软件框架到数据质量测评完整走了一遍。这篇文章就把整套方案的思路、关键步骤和踩过的坑整理出来打算做实机数据采集的具身智能方向研究生、实验室负责人、算法工程师看完基本可以直接照着搭一套不用再重复我们折腾半年的弯路。1. 为什么数据采集必须标准化而不只是能跑通1.1 具身智能训练数据到底特殊在哪先明确一个基本判断具身智能和传统视觉、NLP任务的最大区别在于训练数据必须包含连续的物理交互过程而不是静态的文本和图像。一个拿起杯子放到托盘的高质量训练样本需要同时记录多路视觉信息第三视角相机、腕部相机RGB和深度两路、机械臂各关节的角位置角速度力矩、末端执行器的空间位姿变化轨迹、夹爪的开合状态和时间点以及任务描述、被操作物体的语义信息。这些数据不是一张图片加一个标签那么简单而是完整的观测-动作-结果时序闭环。这个特性决定了数据采集不是拍脑袋就能完成的工作。前期如果缺乏规范后期训练阶段就是灾难。我们实验室早期也犯过这个错误每个人各搞一套采集方式做导航的用rosbag记录激光和里程计做操作的人自己写个python脚本存h5py做遥操作的干脆录屏再手工对齐时间。表面上数据都能采下来但等到合并训练时各种隐蔽问题集中爆发排查成本极高。1.2 非标准化采集的三大连锁问题第一个是坐标系混乱。有的数据记录的是相机坐标系下的位置有的用的是机械臂基座坐标系甚至有的数据里混入了没有明确说明的中间坐标系。模型训练时怎么学都学不对最后排查代码才发现是坐标系定义不一致。这个坑很隐蔽因为单看一段数据完全感觉不到问题一合并就露馅。第二个是时间戳错位。视觉采集30帧关节状态采100Hz各记各的时间戳下游做时间对齐时发现相机帧和关节状态差了200多毫秒。对精密操作来说这个误差足以让模型学到完全错误的映射关系——你以为是看到杯子在左边然后往左抓实际上模型学到的是看到杯子的时候手已经伸到右边了。第三个是任务语义缺失。数据文件里只有数字张量和图像没有记录这是哪个任务、哪个操作者、哪个场景、任务期望的最终状态是什么。后期做数据筛选时根本没法判断一段数据是好是坏训练出的模型一旦在复杂任务上表现不稳定你连哪个环节出了问题都定位不到。这些连锁问题在采集阶段几乎发现不了全部要等训练评测阶段才爆发。所以我们在搭建第二版方案时达成了一个共识数据采集必须按工程标准来做而不是按科研临时脚本的方式做。2. 标准化采集平台的硬件设计与选型2.1 机器人本体的选型先想清楚你要解决什么问题硬件选型是整个方案的基石选错了后面全要推倒重来。具身智能数据采集平台按形态分大致有三类固定基座机械臂、移动机械臂、人形机器人。实验室要根据研究目标来选不要盲目追新。我们团队主要做桌面级操作任务最终选择了固定基座的六自由度协作机械臂作为核心平台。选型时重点比较了UR5e、Franka Emika Panda和国内几款协作臂。这里分享几个关键参数和对比逻辑对比维度UR5eFranka Panda低成本国产臂以部分型号为例自由度676有效负载5kg3kg3-5kg重复定位精度±0.03mm±0.1mm±0.05mm左右力控/拖拽示教支持支持部分支持ROS生态非常成熟比较成熟参差不齐采购周期短较长短预算中高高中低最终选UR5e的核心原因不是参数最好而是ROS生态成熟、采购周期可控、拖拽示教手感好。做数据采集平台软件社区的成熟度比参数上的一点点差异重要得多因为采集端需要和视觉、力传感、遥操作等模块深度集成生态不好光是驱动调试就能耗掉一个月。这里有一个特别值得提醒的点负载预算一定要留足余量。UR5e标称负载5kg但我们的腕部装了六维力传感器、腕部相机、夹爪和若干线缆之后末端总重接近1.8kg再加上操作物体的重量和运动时的惯性冲击已经接近负载上限的40%。如果再做快速移动任务机械臂会因为过载报警频繁停机采集节奏被完全打乱。后来我们重新优化了末端工装尽量走轻量化路线。建议做选型时把末端所有附件重量加起来再乘以1.5的安全系数去对照负载参数。2.2 传感器配置与安装规范数据采集平台的核心传感器是RGB-D相机、力/力矩传感器和关节编码器。相机负责视觉观测力传感器负责交互力感知关节编码器负责运动状态。下面是我们最终采用的配置清单传感器/组件型号/方式数量安装位置用途RGB-D相机Intel RealSense D435i2第三视角斜上方 腕部环境观测与近端操作细节六维力传感器ATI Mini451机械臂末端法兰与夹爪之间记录与物体交互时的力/力矩夹爪Robotiq 2F-851力传感器下方执行抓取与操作IMU可选内置或外置2基座和末端辅助状态估计与验证相机安装位置是硬件设计里最容易忽略但又最影响数据质量的环节。第三视角相机要同时覆盖操作台面和机械臂工作空间安装高度建议离操作面0.8到1.2米俯视角度30到45度尽量避免视差导致的遮挡。腕部相机则要尽量靠近夹爪中心光轴方向与夹爪闭合方向保持一致这样才能在看得到目标物体的同时也拍到夹爪接近物体的过程。安装时还要考虑照明条件。我们实验室顶部是荧光灯工作时会在物体表面形成高光深度相机对高光区域会直接丢深度值。后期我们加了两块柔光板把地面反射光打散深度图像质量立刻提升了不少。环境中如果有大面积反光物体金属托盘、亚克力盒子建议做哑光贴膜处理否则深度数据会有很多孔洞。2.3 标定流程一步懒都不能偷硬件装好之后标定是决定数据是否可用的分水岭。标定做得不仔细后续所有数据基本都是废的。我们的标定流程分为三步相机内参标定、手眼标定、基座与世界坐标系对齐。相机内参标定使用标准棋盘格通过采集不同位姿下的棋盘图像用OpenCV的calibrateCamera标定。这块有个重要经验标定完的相机焦距参数要固定下来写入配置文件采集程序中禁止再动态修改。我们曾经在一次实验前为了优化视角手动改了相机焦距导致整个批次数据的内参和实际图像不匹配重投影误差暴涨最后只能重新采集。手眼标定解决的是相机在机械臂末端坐标系下的位姿问题。我们采用eye-in-hand布置即相机固定安装在机械臂末端标定求解AXXB问题。操作时让机械臂带动相机从多个角度观察固定在台面上的标定板至少采集15到20组数据使用开源工具包计算得到转换矩阵。标定结果用重投影误差验证误差超过2个像素就要重新标定。基座与世界坐标系的对齐我们用的是棋盘格作为世界系参考。将棋盘格固定在工作台面上的固定位置测量出它相对于机械臂基座的位置和姿态记录下来作为该任务批次的标准坐标系。每个新任务开始前统一检查目标物体和棋盘格的位置关系确保不同时间段采集的数据处于同一个世界系下。注意标定记录必须有日志包括标定时间、标定板型号、标定误差、操作人员。后期如果发现某批次数据异常日志能帮你快速定位是标定问题还是运行问题。3. 数据采集软件架构与实施流程3.1 统一数据协议与存储格式硬件标准化做完接下来是软件架构。我们参考了当前主流开源具身智能数据集的设计思路定义了一套统一的数据协议核心目标是一个数据文件包含所有需要的信息且结构完全一致。观测空间定义如下camera_third_rgb第三视角RGB图像分辨率1280x720帧率30fpscamera_third_depth第三视角深度图像对齐RGB后存储16bitcamera_wrist_rgb腕部RGB图像分辨率1280x720帧率30fpscamera_wrist_depth腕部深度图像joint_positions7维关节角度或6维取决于机械臂帧率50Hzjoint_velocities关节角速度ee_pose末端位姿位置xyz 四元数xyzw帧率50Hzwrench六维力/力矩数据fx, fy, fz, mx, my, mz帧率100Hzgripper_state夹爪开合宽度0到1范围帧率50Hz动作空间定义则根据采集方式略有不同但最终统一为关节位置增量delta joint position 夹爪开合状态。这样不同采集方式得到的数据在动作表示层面完全一致方便下游训练。存储采用HDF5格式每个任务样本对应一个.h5文件。HDF5的优势是支持层级结构和高效压缩且大部分深度学习框架都能直接读取。内部组织方式如下# 伪代码展示HDF5数据结构 with h5py.File(task001_demo003.h5, w) as f: obs f.create_group(observations) obs.create_dataset(camera_third_rgb, datargb_frames) # (T, H, W, 3) obs.create_dataset(camera_third_depth, datadepth_frames) obs.create_dataset(joint_positions, datajoint_pos) acts f.create_group(actions) acts.create_dataset(joint_positions_delta, datajoint_delta) acts.create_dataset(gripper_state, datagripper) meta f.create_group(metadata) meta.attrs[task_id] put_cup_on_tray meta.attrs[operator] operator_A meta.attrs[date] 2024-06-18 meta.attrs[scene] lab_bench_A meta.attrs[ee_pose] ee_pose_data # 补充存储完整末端位姿文件命名规范也要统一任务编号_演示序号_时间戳.h5。例如task001_demo003_20240618_143025.h5。这样从文件名就能快速定位任务来源、第几条演示、采集时间。元数据里除了任务、操作者、日期还建议记录环境信息例如操作台编号、光照条件、物体初始状态描述和任务成功标准这些信息在做数据筛选和下游评测时非常关键。3.2 遥操作采集的三种主流模式标准化平台需要支持多种数据采集模式因为不同任务适合不同的遥操作方式。我们主要使用三种动觉示教拖拽示教机械臂处于力控/零力模式人手直接握住末端拖拽到目标位置。这是最简单、最直观的采集方式适合形状简单、路径不需要极高精度的任务例如抓取、放置、推操作。优点是上手快、硬件成本低缺点是拖拽过程中人手抖动会被机械臂记录进数据而且对微小、精细动作的控制力不如其他方式。为了减少人手抖动我们总结出的经验是拖拽速度要稳、动作分段做每完成一步路径暂停一下再继续比连续快速拖拽出来的数据质量好得多。主从遥操作一台主机械臂由操作者控制从机械臂跟随主臂运动。经典的代表方案是ALOHA这种双臂结构用高精度的主臂映射到从臂实现对复杂动作的精细控制。我们后来搭建了一套主从双臂平台主臂是UR5e从臂是另一台UR5e中间通过TCP通信同步目标位姿。这种方式比动觉示教更适合双臂协调任务比如双手打开瓶盖、双手搬运大物体但硬件成本高了一倍调试复杂度也明显增加。主从映射时要注意控制频率如果主臂状态发布频率和从臂跟随频率不匹配会出现明显的运动滞后和抖动我们最终把主臂状态发布频率设在250Hz从臂接收指令频率在125Hz实测效果比较稳定。VR/头显遥操作操作者戴VR头显通过手柄映射机械臂末端运动。这种方式的优势是操作者视角和机械臂视角分离适合远程采集和危险场景。但配套系统建设和标定工作量较大我们用VR方式时发现手柄的位姿漂移问题很突出每10分钟就需要重新对齐一次坐标系所以目前只在远程任务中启用常规桌面任务还是以前两种为主。三种方式的选择逻辑很简单任务精度要求越高、越精细越建议用主从遥操作任务类型越简单、频次越高动觉示教效率更高远程采集或特殊场景再考虑VR方案。无论哪种模式最终输出的数据格式必须统一。3.3 时间同步与数据质量实时监控时间同步是软件架构里最容易翻车的地方。多个传感器各有各的时钟如果不做统一采集下来的每一条观测都带着不确定的延迟。我们的做法分三个层级硬件触发优先。对支持硬触发的相机如RealSense系列通过GPIO触发线把外部触发信号同步给所有相机确保多路相机在同一时刻曝光。这样可以从根本上解决相机之间帧对齐的问题。所有传感器统一使用同一台时间服务器NTP/PTP。机械臂控制器、力传感器采集板、工控机都通过局域网时间同步时钟误差控制在1毫秒以内。每次采集前写一个时间校准脚本来检查各设备时间偏差偏差超过5毫秒就停止采集并重新同步。相机帧和关节状态的关联采用最近邻匹配即每条关节状态记录对应时间戳最近的一帧图像。深度相机的曝光延迟需要软件补偿我们在实践中发现RealSense的RGB和深度流之间本身就存在几个毫秒的偏移需要在驱动层设置对齐参数。数据质量实时监控是标准化采集流程的安全网。我们写了一个采集监控页面采集过程中实时显示各路相机预览画面、机械臂关节轨迹曲线、力传感器波形、当前时间同步偏差、每秒采集帧数。一旦发现帧率掉到设定值以下、同步偏差超过阈值、或者某路传感器断连系统会立刻发出警告。第一次发现这个问题是在某天下午连续采集两个小时之后相机因为过热开始自动丢帧但采集程序没有报错导致那批数据全都是缺帧的。后来加入了温度监控和帧率告警才避免类似情况。4. 数据质量测评体系与指标体系4.1 数据质量的多维评估方法数据采完之后不能直接拿去训练必须先做一轮质量评估。我们把评估指标分为四类完整性、一致性、多样性和时序质量。完整性是最基础的检查项。统计每个数据文件中各传感器的时间长度、帧率、缺失帧比例。一个合格样本的标准是所有传感器时长一致误差小于200毫秒缺失帧比例小于2%没有出现长时间断流超过500毫秒的跳变。如果达不到直接判为不合格不进入训练集。一致性关注的是标注与观测是否匹配。比如任务描述为将红色水杯放到托盘中心那么数据里必须能看到红色水杯从初始位置移动到托盘中心的过程且夹爪在恰当时间点闭合。这一步需要人工或者半自动的回放检查我们会随机抽取10%到20%的数据进行可视化回放看观测画面和任务描述是否吻合。多样性衡量的是数据集中不同情况覆盖程度。具身智能数据只覆盖成功轨迹是远远不够的如果所有演示都是同一条路径、同一个初始位置模型就过拟合了。我们会统计不同初始物体位置的数量、不同操作者之间的速度差异、不同光照条件如果自然环境变化的话并用动作向量分布来检查多样性。一个简单直观的做法是把每条演示的关节轨迹投影到二维主成分空间看数据点是否分布松散如果密集堆在一起说明演示模式太单一。时序质量关注动作本身的平滑度和合理性。我们计算关节位置序列的差分和二阶差分用加速度突变来检测抖动。如果拖拽示教数据中关节加速度出现大量尖峰说明操作过程存在明显抖动需要剔除或者重新采。这个指标对下游模仿学习影响很大模型会对高频抖动产生过拟合导致真实部署时出现奇怪的高频振颤。质量维度核心指标合格标准评估方式完整性缺失帧比例、时长一致性2%所有流时差200ms脚本自动统计一致性任务描述与观测匹配度抽检合格率≥95%人工回放抽检多样性初始状态覆盖、动作空间分散度覆盖≥20种初始状态统计分析时序质量关节加速度尖峰、动作平滑度尖峰比例1%算法检测4.2 基于下游任务的评测数据到底行不行前面的质量指标是数据自检真正有说服力的是把数据喂给模型看下游任务表现。我们内部建立了一套评测流程每次数据大规模更新后都会跑一遍选取一个稳定的模仿学习基线模型早期用ACT后来也会用Diffusion Policy在全部数据上训练固定训练超参数和随机种子训练轮数保持一致在固定的测试场景上评测统计任务成功率、平均完成时间和失败模式分布。为了对比数据版本的价值我们会设置一个小规模参照组比如从全量数据中随机抽取50条演示训练一个模型再用全量数据训练一个模型对比两者的成功率差距。这个操作能直观反映新增数据对性能的贡献。如果新增数据后成功率没有明显提升就要排查是不是新增数据多样性不足或者质量不达标而不是继续盲目扩量。评测的环境要保持和采集环境尽量一致但又不能完全一样。我们在评测时会把物体初始位置做轻微扰动观察模型对位置变化的鲁棒性。如果模型稍微挪动一下杯子位置就失败说明训练数据可能存在很严重的过拟合需要补充更多样化的初始位姿数据。4.3 数据规模与模型性能的量化关系很多研究生会问一个问题到底要采多少条数据才够我们的经验是分阶段扩量先采50条演示跑通评测流程验证数据协议、训练代码、评测环境全部正确再扩大到200条观察成功率是否有明显上升之后再按200条为一个批次递增每次递增后跑评测。这个过程能画出一条数据量-成功率曲线曲线的拐点可以帮你判断当前任务的饱和状态。以我们最常用的桌面抓取放置任务为例从50条扩展到200条时测试成功率从40%提升到75%提升幅度很大。但从200条扩展到400条时成功率只从75%提升到了82%。这说明200到300条已经接近该任务的数据饱和点继续增加纯同分布数据边际收益很低。这时候正确的投入方向是增加场景多样性换背景、换物体类型、换光照而不是继续采同样的任务。数据采集成本也要纳入计算。按我们团队的经验一条长度为5到8秒的桌面操作演示从摆好物体、启动采集、执行操作、保存数据到复位平均需要2到3分钟。一个人专注采半天4小时有效时间大概能采80到120条合格演示。按这个速度要在两周内凑齐500条数据至少需要3到4个操作者轮换还必须有专人负责质量抽检和设备维护。这个工作量在搭方案之前就要做好心理准备。5. 实战中的常见问题与避坑经验5.1 硬件层面的坑手眼标定误差是最容易积累的问题。我们曾经因为夹爪安装座加工公差偏大导致腕部相机相对法兰的位姿每次拆装后都发生轻微变化标定结果隔几天就失效采集出的数据投影误差越来越大。后来我们给相机加装了定位销保证每次安装位置固定标定一次可以稳定使用很长时间。如果你的相机需要频繁拆装务必注意机械定位结构不要只靠螺丝紧固。相机过热是长时间采集的头号敌人。RealSense连续工作两小时后内部温度升高会自动降低帧率甚至丢帧而且不报错。解决方案是加装主动散热风扇、定时休息每采集1小时休息15分钟监控程序里增加温度读取和帧率告警。我们甚至在硬件布局时把相机放在机械臂工作区边缘避开机械臂动作产生的热气流实测减少了5到8摄氏度的温升。线缆管理看起来是小问题实际影响巨大。机械臂反复运动时穿过中空轴或从侧方走线的线缆会被频繁弯折几个月后就会出现内部断芯导致间歇性丢数据。我们后来把所有线缆改为高柔性拖链线并在机械臂关节处预留了回弯半径线缆故障率下降了很多。力传感器和相机的线缆尤其脆弱建议准备备件。5.2 软件层面的坑数据损坏和丢失是最让人崩溃的问题。早期采集程序在保存HDF5文件时如果中途断电或程序崩溃整个文件可能损坏且无法打开。后来我们改成先写临时文件采集结束后再重命名为正式文件的机制并且每小时自动备份一次。即便如此还是要坚持每天采集结束后做一次数据完整性校验脚本扫描发现问题当天回溯解决。坐标系命名混乱是团队协作时最容易出现的软件问题。我们的机器人有多个坐标系机械臂基座、法兰、末端工具、相机、世界系。每个人在写代码时可能用不同的命名习惯base、base_link、BASE、link0。一旦混用数据含义就完全变了。我们的做法是制定一张坐标系总表定义每个坐标系的名字、父坐标系、yaml配置里的字段名代码里强制使用统一常量不充许在代码里手动写数字或字符串。时间同步还有一个隐藏坑系统休眠唤醒后时钟会漂移。我们有一台工控机在长时间无人值守时进入休眠唤醒后所有传感器时间戳都出现了几百毫秒的偏移但程序没有报错。后来在采集启动脚本里加了时间偏移自动检测偏差超过阈值就拒绝启动采集。5.3 流程管理层面的坑数据采集团队通常不止一个人操作者之间的差异会造成数据分布偏移。有人拖拽速度快有人慢有人习惯先调整夹爪角度再下降这些都会影响训练。我们的做法是制定一份《采集操作规范》写清楚每个任务的执行步骤、速度要求、失败后如何处理、何时需要重新采集。新操作者上岗前必须进行两次试采集由经验丰富的人审核通过后才能正式参与采集。任务描述不一致也很常见。同一个把杯子放到托盘上不同人写的语义可能是place cup on tray、put the cup in the tray、将杯子放到托盘三种。下游训练和大模型微调时这种不一致会严重干扰语义理解。我们的元数据模板里预设了任务描述字段的固定格式要求每条数据的任务描述必须严格从任务清单中复制粘贴不允许多写或少写。最后强烈建议建立数据版本管理机制。我们每采集完一批数据就打个版本号记录数据量、质量指标、评测结果、采集团队成员。这样当模型效果波动时可以快速回溯到某个数据版本复现实验。我们用的是最简单的目录版本记录表管理方式不需要复杂的系统但坚持记录比工具本身更重要。写在最后几个小建议这套标准化方案前前后后调整了大半年踩过的坑远比文章里写的多。如果只让我分享三条最核心的经验第一硬件选型和标定一定要在正式采集前完全稳定下来不要在采集过程中反复更换硬件配置否则产出的数据相互之间不可比非常浪费。第二数据质量评估和采集要同步进行不要等采完几千条再去筛一定要小批量采、尽快评测、及时纠偏这样才能保证最终数据集的可用性。第三流程文档和版本记录要跟数据本身同等对待科研团队人员流动性大没有记录的数据过两个月就没人说得清楚是怎么来的了。这篇文章覆盖了从硬件平台搭建、软件框架设计到数据质量测评的完整链路希望能给正在组建具身智能数据采集实验方案的高校团队一些参考。方案没有唯一正确答案关键是想清楚自己的任务需求然后尽量做标准化、可复现、可追溯。祝大家采集顺利数据都干净可用。