EmbodataHub具身智能数据工程平台：从采集到质检，让每一帧数据都值得被训练

针对机器人规模化训练中数据散落、脏数据混入及格式繁杂等痛点，通过标准化流水线打通数据“采、洗、质、导”全流程。系统以多路视频与轨迹同步回放实现“看得见”，以七大质量维度及证据帧检测实现“筛得准”，以LeRobot/HDF5/Zarr等主流格式双向转换实现“导得出”。将依赖人工经验的治理过程工程化，减少试错，让数据集准备从数天走向小时级。

关键数据：7大自动化质量检测维度.3种以上主流格式双向转换.数据集准备“数天→小时级”.标注成本预期“-70%”.多路传感器时序同步对齐

过去两年，具身智能的讨论大多围绕模型：更大的VLA、更多参数、更强泛化。但真正跑过项目的人会发现另一条更朴素的瓶颈——数据采回来了，却说不清哪一条能用。

典型的一天是这样的：遥操作台和采集车产出几十小时多模态录制，文件堆在共享盘和对象存储里；工程师想知道这批数据能不能拿去训新一版策略，唯一手段是逐条播放视频、凭经验判断。数据从几十条涨到几千条，这种方式就失效了——不是人不够努力，而是以文件为单位的组织方式，和模型真正需要的一条完整操作根本不是一回事。

图1：以文件为单位的数据组织vs以Episode为单位的数据组织

更麻烦的是，问题往往不是数据坏了，而是不知道坏在哪：抓取失败、物体中途掉落、机械臂空转，这些轨迹在数值上完全正常，只有画面能说明；相机跑30Hz、关节跑500Hz，晶振漂移加网络延迟，各通道时间戳各说各话，模型学到的因果可能就是错的；某个维度整段超出物理边界，却混在正常分布里；换了训练框架就要重写转换脚本，脚本总在训练跑到一半时崩掉；模型效果不好，团队最常争论的仍是这到底是算法问题还是数据问题。

这些问题最终以三种形式爆发：返工、训练不稳定、验收争议。数据服务公司交了一批数据，客户说有效率不够；训练团队跑了两周，才发现样本里有大量失败片段。

要说明的是，并非所有训练问题都来自数据。模型结构、超参、奖励设计、仿真与真实的差距，同样决定结果。但当规模上来之后，数据的可检查性本身就是一个独立的工程问题——它不该靠某位资深工程师的记忆和手感维持。

这就是质量治理值得被单独拿出来做的原因。

EmbodataHub是TsingtaoAI（霆涛智能）面向具身智能与机器人数据生产打造的数据工程平台。它接手的，是那些原本散落在网盘目录、临时脚本和个人经验里的治理环节，把它们收进一条标准化、可复现、可审计的自动化流水线。

EmbodataHub官网：

https://pub.embodatahub.tsingtaoai.com

它不是清洗脚本的合集，也不是换了皮的文件管理器。区别有三点。

基本单元是Episode，不是文件。平台围绕一条完整操作片段建立统一对象模型：格式解析、过滤器结论、VLM判断、对齐任务、人工决策、回放文件和导出报告，全部可回溯到具体的数据集版本和具体Episode。只有结论挂在Episode上，这条数据当初为什么被判为可用才在三个月后还有答案。

它不只发现异常，还给出可核查的依据。每个结论都带着证据：哪一帧、哪个时间点、哪个视角、哪个维度。

它把质检放回生产流程，而不是流程之外。采集、入库、质检、复核、导出、训练六段衔接，上游的输出就是下游的输入。

主要服务四类人：数据采集与数据服务企业（提升交付质量、减少返工）、机器人算法与训练团队（训练前确认数据可信度）、现场实施与运维（定位采集链路故障）、项目管理者（权限、目录与审计）。这四类人过去在同一个数据集上各说各话，现在至少可以围绕同一份报告讨论。

图2：EmbodataHub产品工作台与整体数据流

图3：质检工作台——Episode索引、清洗Pipeline与质量报告

一次运行，七个维度同步检测，每条Episode得到一个加权综合评分。这是平台技术密度最高的部分，也最容易被写成一张功能表。下面按问题为什么出现→怎么查→结果怎么看来说。

视觉质量。模糊、过曝、欠曝、低对比度、帧冻结、整段视频缺失。平台用拉普拉斯方差判断模糊，用像素均值判断曝光是否合理，用帧间MSE判断画面是否冻结——镜头前一片静止，未必是场景静止，可能只是视频流卡住了。这类缺陷为什么值得单查？因为它在数值通道里完全隐形。关节正常、动作正常、时间戳正常，只有画面糊了。模型学到的是模糊的观测，你却在别处找原因。结论会附带证据帧与时间轴位置，可以直接跳到那一帧看。

突变检测。遥操作抖动、控制器异常、数据拼接错误，都会在速度、加速度、jerk上留下痕迹。平台先做中值滤波与Savitzky–Golay平滑抑制噪声，再计算一阶到三阶差分，最后用中位数+MAD（中位数绝对偏差）识别异常跳变——相比均值+标准差，MAD不容易被离群点本身带偏。

• 难点不在算法，而在尺度。装配任务末端位移以毫米计，搬运任务以米计；同一个跳变，在一个任务里是严重缺陷，在另一个任务里是正常换向。阈值不能全局拍定。操作手册的建议是用一组人工标注过的正常样本、边界样本和失败样本校准，每次调整记录旧值、新值、原因与效果——久而久之形成针对不同机器人、不同任务的配置模板。

时间同步。校验三件事：帧间隔与理论fps的偏差、实际时长与理论时长的差异、视频流相对数据流在起止时间上的偏移。多相机、多传感器系统在这一点上格外脆弱。相机30Hz、关节500Hz，两套时钟各自漂移，加上传输延迟，同一次抓取在视频里和曲线里可能差几十毫秒。对人来说不算什么；对模仿学习来说，这意味着模型在学一个错误的因果——它看到手还没到，状态却说已经接触了。

极值检测。基于全数据集的1%/99%分位数与IQR建立物理边界，识别超出正常分布的状态或动作维度。

• 真正的设计难点在豁免：夹爪饱和（一直开到最大或一直闭到底）是完全合法的行为，若当成极值上报，每条抓取数据都会被标红。平台对这类已知合法行为做了专门处理。这也是极值检测和简单阈值告警的区别——前者需要理解数据语义，后者只需要一个数字。单位错误、字段映射错位、传感器漂移，通常在这一步露出马脚：某个维度的整段数值落在物理上不可能的范围里。

运动学一致性。接入机器人的URDF模型，用Pinocchio做正向运动学，由关节状态反算末端位姿，再与数据中记录的末端位姿比对。

• 前提是配置正确：URDF版本、关节名称映射、TCP偏移，任一项错了结论都会失真。但配好之后，它能抓到一类很隐蔽的问题——关节角记录正常、末端位姿记录正常，两者却不自洽。这通常意味着标定过期、坐标系换错，或者数据在转换过程中被改写过。

姿态对齐。位置与朝向来自不同设备、不同标定流程时，往往带着一个固定的旋转偏差。平台用旋转校正矩阵对齐两者，把系统性偏差从随机噪声里分离出来。这类偏差不影响单条轨迹的形状，只影响它相对其它数据的绝对位置。所以很难靠看单条视频发现，却会让多任务联合训练变得别扭。

元数据完整性。六项检查：任务描述是否存在、相机命名是否规范、分辨率是否一致、多视角是否覆盖完整、动作字段是否齐全、Episode结构是否完整。这一项看着最不技术，实际最影响下游。训练脚本读不到相机字段会直接报错；任务描述缺失会让VLM无法评估；多视角不全，某些任务根本无法复现。手册把它放在基础检查里，理由很实际：数据契约的问题应该尽早暴露，而不是等训练脚本崩掉。

七个维度跑完，每条Episode落到三种状态：

图5：七大质量过滤器——七个维度，一次同步体检

分数是加权融合的结果，权重可按任务类型调整：安全相关数据可以调高关键缺陷权重，动作幅度本身很大的任务则要避免把正常运动误判为突变。

规则和统计能走多远？走到画面语义就停了。

一条轨迹可以完全通过前面七项：视频清晰、时间对齐、信号平滑、数值在界内、运动学自洽、元数据齐全。但画面里发生的事可能是：机械臂伸向杯子，夹爪闭合，杯子在抬起过程中滑落。所有数值都正常，任务失败了。这对模仿学习是致命的——模型学到的是抓取动作+物体掉落的完整序列，还被当作成功样本反复强化。

EmbodataHub把视觉语言模型接进质检闭环：从每条Episode抽取关键帧（默认4帧，可调1–12帧，复杂任务可提到8–12帧），连同任务描述一起交给VLM判断成败，模型返回结构化结果success、score、reason，判断理由进入人工审查的证据区。

Prompt不是随手写的一句话。手册建议：明确任务目标、成功条件、失败条件、观察视角、输出格式，以及不确定时怎么办——宁可让模型返回success=false或要求复核，也不要它勉强给一个成功。模板保留{task}占位符，运行时自动替换为该Episode的任务描述；不同机器人、不同任务应各自维护模板，而不是一套模糊Prompt走天下。

结果怎么用，这一点需要说准确：VLM判定失败时，系统把该Episode从通过升级为待审查，而不是直接排除。这是刻意的保守设计——大模型会误判，误删的代价远高于多一道人工确认。VLM结果的权重独立可配，与数值过滤器加权融合，团队可以按自己对模型的信任程度调整它的影响力。

图6：VLM判定失败时升级为待审查

接入有三条路：OpenAI兼容端点（含自建推理服务）、GoogleGemini（如gemini-2.5-flash）、本地推理服务。差别不只是成本：前两者需要把关键帧发到外部端点，第三条路径下画面不出内网。对有保密要求的团队，这个区别往往是选型的决定性因素。

还有一点必须说清：语义评估不能替代人工复核。VLM给的是疑似，人给的是结论。平台把前者做成高效的筛选器，把后者的精力集中到真正存疑的样本上——这才是自动化的正确位置。

一个0.62分，对工程师几乎没有信息量。他会问：哪里扣的分？在第几秒？哪个相机？能不能证明？

EmbodataHub的答案是把每条结论还原成可观察的东西。

图7：Rerun回放——多路相机、轨迹与关节曲线同一条时间轴

Rerun3D回放。选中可疑Episode，一键生成回放：末端三维轨迹、各关节位置与速度曲线、夹爪开合、多路相机视频，全部放在同一条时间轴上，视频与曲线联动，拖到某一帧两边同步。

这一步解决看得见现场。抽象曲线变成一段真实发生的操作：机械臂怎么走、在哪一帧接触物体、夹爪何时闭合。异常不再是数字，而是一个可以复述的动作。

清洗报告与质量分布。报告仪表盘给出Episode总数、总帧数、总时长、帧率与综合评分；分布柱状图按通过/待审/排除三色标注；夹爪维度的交互折线图、Episode时长分布（附均值参考线）也在这里。时长明显偏离的一批数据，往往指向采集流程本身的偏差——比如某天开始所有录制都短了一截。

证据帧与时间轴定位。每条结论都附代表性证据帧与时间轴位置。这带来一个常被低估的好处：争论有了终点。数据团队和算法团队讨论一条数据能不能用时，不必各自播放视频互相说服，指着同一帧说话就行。

Episode级人工复核。在同一界面完成查看、判断、覆盖、留痕，再跳到同状态的下一条，适合批量处理。

自动检测告诉工程师哪里可能有问题，回放和证据帮他判断问题是什么、发生在哪、该怎么处理。这两步之间没有捷径——只给分数的系统，最后都会逼着人重新逐条看视频。

到这里，数据已经检查过、解释过、决策过。接下来的问题是：怎么交给训练那边。

平台当前支持四类主流训练格式的导入与导出：LeRobot（导入v3，导出v3与v2.1两种目录结构）、ACTHDF5（面向ALOHA等双臂操作数据集，导出为文件或目录）、robomimicHDF5（单文件交付）、UMIZarr（导出为.zarr目录或.zarr.zip）。

关于五种格式，需要更准确地理解。宣传口径是五种主流格式双向互转，但导入与导出的具体条目是四类格式、LeRobot分两个版本。此外，平台原生支持ROSbag、MCAP、ZEDSVO2等常用采集格式的接入——这些是采集侧格式，用于把原始录制读进平台，不等同于训练侧导出格式。痛点描述里还出现过RLDS，这个名称目前只出现在行业问题讨论中，不应理解为平台已完整支持它的双向转换。这些边界写清楚，比含糊地凑足五种更有价值。

导出时有几个关键控制点：范围筛选（已勾选/仅通过/仅待审查/仅排除/全部已索引），复核结论直接决定谁进入导出集；人工结论优先，被人工判为通过的样本可以导出，被判为排除的不会因为分数高而漏过；转换报告记录字段映射、元数据完整性与Episode清单，让这批数据是怎么来的变成文件而不是记忆。

手册还建议：先导出一小批做下游训练脚本的兼容性验证，再跑全量；导出后核对文件数、Episode数、字段维度、视频引用与报告是否一致。这几步看着繁琐，但比训练跑到第三天才发现字段对不上要划算得多。

图8：世界模型训练——3DGS场景重建与参数配置

生态侧，平台对接了OpenVLA、LeRobot、FluxVLA等训练体系，以及IsaacLab、UnitreeRLLab、SurRoL等仿真环境。这里要区分两件事：格式互通（数据能被对方脚本读进去，这是已完成的）与深度集成（双方在接口、配置、流程层面做了联合适配）。具体到某个框架做到哪一层，建议在项目沟通时按实际情况确认，而不是默认全部等同。

真实数据与仿真数据在平台上是一视同仁的：统一归档、统一质检、统一导出。团队可以按比例混合两者组装训练集，用合成数据摊薄真机采集成本——但前提是，合成数据也要过同一道质检。

如果文章停在这里，EmbodataHub看起来仍是一个很能查问题的工具。但它真正想解决的是另一个层面的问题：数据治理不该是算法团队的副业。

任务队列与Worker集群。文件落库触发事件，任务进入异步队列，按优先级调度，由在线注册的Worker执行解析、转换、内容提取，结果回写并同步元数据。节点通过心跳上报在线状态，掉线能被及时发现——这意味着质检可以排队过夜跑，也可以横向加机器顶住交付高峰。平台内置了数据验证、元数据提取、BAG→MCAP转换、视觉SLAM、点云分割等常用处理模板，不必从零编写。

分层组织与检索。数据按项目/任务/文件三级组织，配合标签体系、分类与元数据扩展；面向数据本身还有四层模型：项目→任务→Episode→数据流。跨项目、跨任务的文件与元数据可统一检索，找数据不再靠翻目录。

权限与审计。用户组与角色管理、资源级访问控制，关键操作有权限控制与可追溯日志。生产环境还建议启用HTTPS、上传文件白名单和审计日志——在企业交付场景里，这些往往是准入门槛，而不是加分项。

开放接口与CLI。API密钥体系与开放接口让外部系统程序化接入；命令行工具支持在训练服务器上直接拉取数据集，方便嵌进自动化训练脚本。

图9：数据不出本地——内网部署与源数据只读

部署与数据边界。三种形态：私有自托管（自有服务器或内网物理机）、私有云（自有云账号的VPC内）、本地工作站（单机跑完整流程）。架构上控制与数据分离：业务控制走API网关，大文件走对象存储直连。原始数据集只读，平台不修改你的数据；清洗状态、回放录制、导出文件与报告写入独立的产物目录，随时可回溯、可清理。

关于数据隐私，需要一句更准确的表述：数据不出本地取决于配置，而不是无条件成立。VLM选择本地推理服务时，关键帧不出内网；选择OpenAI兼容端点或Gemini时，关键帧会发送到对应推理服务。两条路径的合规含义不同，选型时应当明确。

以下为说明工作流程的示例场景，操作顺序与平台能力均依据产品资料整理，其中的分数与结论为示意值，不代表真实客户案例结果。

设想一段10分钟的双臂抓取录制：两台相机（overhead与wrist）、关节状态、夹爪开合、任务描述把桌面方块放入右侧料盒。

入库。录制通过本地上传进入平台，系统识别为ACTHDF5结构，读取元数据，切分出多个独立操作片段，生成Episode清单。工程师先核对基础信息：片段数量正常、两台相机齐全、动作维度正确、任务描述存在——没有明显元数据缺口，可以往下走。

质检。先启用视觉质量、突变、时间同步、极值、元数据五项规则过滤器，跑完全量；确认阈值没有大面积误报后，再启用运动学一致性（已配置URDF与关节映射）和多模态对齐；最后对状态为待审查的Episode启用VLM。

图10：清洗报告与质量分布——50条Episode的评分概览

看结果。评分分布大致是：多数样本落在通过区，几条在待审查区，一条被排除。排除的那条问题很具体——wrist相机在中段出现帧冻结，帧间MSE长时间接近零，证据帧直接跳到那一秒。

进单条看证据。一条待审查样本的扣分来自突变检测：抬起瞬间关节速度出现尖峰。打开回放，末端轨迹在那一段有个明显折角，视频里能看到物体在抬起时滑了一下、随后夹爪重新闭合。VLM对这一条的判断是success=false，理由是物体在抬起过程中掉落。两种完全不同的检测方法，指向同一个结论——这条从待审查被确认为失败。

人工决策。审查人将其打为排除，原因写抓取后滑落，任务未完成；另一条只是遥操作轻微抖动的，判断为不影响任务，覆盖为通过，同样留下理由。

导出。选择仅通过，导出为LeRobotv2.1目录结构，同时生成conversion_report.json。训练团队拿到的是一份干净目录、一份Episode清单、一张质量分布图、一份字段映射记录，以及每一条被排除样本的问题类型。

从这批数据开始，这批数据质量如何不再是一个需要开会讨论的问题，而是一份可以附在交付邮件里的文件。

回到开头那个问题：机器人真正缺的是什么？

只看数量，采集成本在下降，数据在变多。但训练真正吃进去的，是那些被检查过、被解释过、被明确判定为可用的片段。从原始采集到可信数据，中间隔着的不是一块更大的硬盘，而是一套能回答这条数据为什么可用的流程。

这也是EmbodataHub想站的位置：把质量判断从个人经验，变成可量化、可追溯、可复用的工程环节；把一次性的数据交付，变成能持续积累、反复引用的数据资产；把散落在脚本和目录里的治理工作，收进一条谁都能看懂、谁都能复查的流水线。

宣传材料里有一个目标值：数据集准备周期从数天走向小时级。前一句是设计目标，实际收益取决于数据规模、硬件配置与业务流程。而让每一帧数据，都值得被训练是产品意图，它说的是：在你把数据交给模型之前，先让它经得起一次检查。