北航CoLab团队：让AI机器人真正动起来，不只是"训练好了"

这项由北京航空航天大学CoLab实验室完成的研究，于2026年7月发表，论文编号为arXiv:2607.02646。有兴趣深入了解的读者可以通过该编号在arXiv平台查阅完整论文。

**训练出来了，然后呢？**

机器人领域有一个鲜为人知的窘境。科研人员花费大量时间训练出一个智能机器人策略——也就是让机器人"知道该怎么做"的那个大脑——但当他们兴冲冲地想把这个大脑装进真实机器人身上时，却发现这才是真正麻烦的开始。

打个比方，你煞费苦心地学会了一道复杂菜肴的配方，可到了真正的厨房里，却发现炉灶的旋钮位置不一样、锅的尺寸跟书上写的对不上、计时器还得手动操作……光是把配方转化成实际操作，就已经让人头大了，更别说还要在客人面前优雅地端上桌。机器人部署的处境与此如出一辙。

EVA-Client就是为解决这个"从配方到上桌"的鸿沟而生的。它是一套开源框架，专门负责把训练好的机器人策略顺利搬到真实机器人上，并且把整个过程变得可检查、可重复、可比较。

**一、机器人界的"最后一公里"难题**

近年来，机器人操控领域发展迅猛。各类视觉-语言-动作模型（VLA）、视频-动作模型（VAM）和世界-动作模型（WAM）相继涌现，简单理解就是让机器人能"看图说话再动手"的各种AI大脑。与此同时，openpi、LeRobot、StarVLA等训练框架也日趋成熟，大大降低了训练一个机器人策略的门槛。

然而，训练好策略之后该怎么办，整个行业却像是集体忽视了这个问题。把一个训练好的"大脑"实际接入真实机器人，需要解决一连串的技术难题：机器人硬件的接入与适配、实时动作的调度与执行、延迟补偿、动作平滑处理、执行过程的记录与回放……这些工作通常被每个团队各自实现为临时凑合的脚本，既难以复用，又难以比较。

这个局面造成了三个具体痛点。第一个痛点是"机器人不通用"——不同机器人有各自不同的摄像头、关节状态反馈方式和通信协议，为一台机器人写的部署代码几乎不可能直接用到另一台上。第二个痛点是"执行细节影响结果却难以追踪"——机器人策略执行时，如何把每次预测出的一小段动作序列（专业术语叫"动作块"）拼接成连贯的运动，直接影响任务成败，但这些执行细节往往埋藏在各自的实现里，根本无从比较。第三个痛点是"评估不留证据"——团队通常只是跑几次机器人，凭感觉判断效果好不好，既没有系统记录，也不能事后重现，更谈不上把实际运行数据反哺回去继续训练。

EVA-Client正面回应了这三个痛点，提出了一套统一的解决方案。

**二、EVA-Client是什么，它做了什么**

从架构上看，EVA-Client扮演的是"翻译官加调度员"的角色，坐落在两侧之间：左边是各种策略来源——包括openpi、StarVLA、GR00T、Dream-Zero等AI策略服务器，以及人工遥控操作——右边是真实机器人硬件。EVA-Client从左边接收动作指令，经过一系列处理后，向右边的机器人发出控制命令，同时把机器人反馈回来的观测数据整理好再送回给策略服务器，形成一个完整的闭环。

更重要的是，EVA-Client把整个部署过程包含的三大工作流——调试（Debug）、数据采集（Collect）和评估（Evaluation）——全部整合进同一套框架，让"训练一测试一再训练"的循环不再需要换工具。

整个框架在内部分为五个层次，彼此之间通过简洁的接口通信。传输层负责搬运观测数据和控制命令，机器人描述层声明具体机器人的特征，策略客户端层负责跟AI策略服务器打交道，推理策略层决定如何把一段段预测出的动作平滑地变成连续运动，最上面的界面层提供可交互的网页控制台。因为各层之间只通过小数据结构交换信息，任何一层都可以独立替换，不影响其他层。

**三、各种机器人都能用：硬件适配的奥秘**

机器人界有个老大难问题：每家机器人的"通信方言"都不一样。EVA-Client的解决思路是"声明式"配置，而非为每台机器人单独编写专属代码。只需要为一台新机器人写一个"机器人描述类"，说明它有哪些关节组（手臂、夹爪、底盘等）、摄像头在哪、用什么话题名称传数据、是否需要运动学计算——框架里的其他所有部分就能自动跟这台机器人协作。

目前框架已经支持的机器人包括Franka机械臂、UR5e、Galaxea R1-lite、AgileX Piper、AgiBot G2和ARX R5，并且仍在持续扩展。这些机器人全都通过同一套通用后端接入，区别仅在于各自的描述类不同。

数据传输方面，框架支持ROS1、ROS2和ZMQ三种传输后端。其中ROS1和ROS2是机器人领域最主流的通信中间件，框架对它们的时间同步做了特别处理：不是简单设定一个容许误差窗口，而是为每个数据流维护一个缓冲队列，每次取数据时精确对齐各流中时间戳最接近的那一帧，如果各流之间找不到共同的时间戳，就等待它们重新同步，而不是将就着用一帧不匹配的数据。这种精确的时间对齐，避免了机器人"看到的"和"当时实际在做的"对不上号的尴尬。ZMQ后端则允许开发者完全不接机器人，只通过一个模拟节点产生假观测数据，就能调试整个推理流程。

另一个关键能力是动作空间的转换。策略模型输出的动作可能是"手末端应该到哪个位置"，而机器人实际接受的命令是"每个关节应该转多少角度"——这两者之间需要"逆运动学"（IK）计算来桥接。框架内置了基于PyRoki的IK求解器，采用Levenberg-Marquardt非线性最小二乘法，在保证手末端轨迹连续的同时，还加了防止关节突变的惩罚项，以及偏向"安全姿态"的正则化约束。每帧动作的IK求解都从上一帧的解出发做热启动，保证整条轨迹的关节角连续变化，避免执行时机器人突然抖动。

**四、从谨慎调试到全速运行：五种执行模式**

EVA-Client把部署过程当作调试活动来设计，提供了一个从最安全到最激进、可以逐步升级的执行模式谱系。

最安全的是"开环仿真"模式：策略产生的动作不会发送给真实机器人，只在网页界面的3D可视化场景里播放出来。这个模式让研究人员可以先确认策略的动作"看起来合理"，完全没有硬件风险。

往前走一步是"真实单块步进"模式：机器人确实会动，但每次只执行一个动作块（可以理解为"迈一步"），执行完就停下来等待人工确认再继续。这样，如果某个动作出了问题，可以精确定位是哪一步预测出了偏差，而不是在连续运动结束后只剩下"不知道哪里出了问题"的迷惑。

更谨慎的是"仿真转真实步进"模式：每个动作块先在3D仿真里预演，人工看完觉得可以才放行到真实机器人执行。这在测试新策略或者在脆弱物品周围操作时尤为有用。

最后是"连续执行"模式，也就是全速实时部署：控制循环以配置的频率持续发出命令，推理策略在后台自动处理动作块的调度和平滑，机器人不间断运动，这是正式任务执行时所用的模式。

整套操作界面通过一个网页控制台呈现，包含五个标签页：调试、采集、评估，以及回放和结果查看。每个标签页共享同一套布局——左侧控制面板、中间Viser渲染的3D场景（实时显示关节状态和执行轨迹）、右侧时间同步的摄像头画面（含俯视和两个腕部视角）。

**五、让机器人动得更顺畅：五种推理策略**

机器人策略的一个特点是每次推理会预测未来一段时间的动作序列，而不是只预测"下一个动作"。可以把这理解为：策略每次给出的不是"接下来动一下"的指令，而是"接下来这一小段时间该怎么动"的脚本。问题在于，推理本身需要时间，当新的动作脚本算出来时，机器人早已执行了若干步，导致新脚本的开头已经过时，结尾也未必能和当前状态自然衔接。

EVA-Client统一实现了五种处理这个问题的策略，并把它们放在同一个配置界面下，方便切换和比较。

最简单的是"同步执行"：算完一段动作脚本就执行完，再算下一段，期间机器人等着，会产生明显的"停顿-运动-停顿"节奏。这种模式调试方便，但对于需要连续流畅动作的任务来说是个硬伤。

为了解决停顿问题，"异步预取加线性重叠混合"策略让推理在后台线程里持续运行，同时主控制循环以机器人控制频率持续发出命令。当新的动作脚本到来时，框架先丢弃开头那些对应于已执行时间步的过时动作，然后在新旧脚本的重叠时间窗口内做线性混合——越靠近重叠区开头，越信任旧脚本；越靠近重叠区结尾，越信任新脚本。这样，动作轨迹在脚本交接处不会出现跳变。

"ACT风格时序集成"策略来自一篇有影响力的机器人学习工作（ACT），其思路是不丢弃任何已有的预测，而是让所有覆盖当前时间步的历史预测都参与投票，用指数加权平均来决定最终执行的动作。越老的预测权重越大——这个设定承袭自ACT的原始设计，出发点是认为更早、更稳定的预测通常更可靠。

"朴素异步替换"策略作为对照基线：新来的动作脚本直接替换整个缓冲区，不做任何混合，但通过时间戳偏移来补偿延迟。它的存在是为了让研究人员在对比实验中剥离"混合平滑"这个变量的贡献。

第五种是"实时分块（RTC）"策略：这种方法在客户端把已提交执行的动作脚本打包发回给策略服务器，服务器在生成新预测时会以此为约束条件，保证新预测与机器人当前正在执行的内容天然衔接，而不是事后缝合。客户端收到服务器的新预测后，还会再做一次线性混合作为最后的平滑保险。

这五种策略的选择对任务成败有实质影响。论文展示了两个对比鲜明的真实案例：在乒乓球接球这种高动态任务里，同步执行导致机器人因为每次推理时的停顿而根本来不及追球，换成异步策略后球就能打起来了；在叠衣服这种需要长时间连贯操作的任务里，异步策略的重叠混合则保持了整条动作轨迹的平滑稳定。

**六、数据采集：遥控操作直接变训练素材**

EVA-Client不只是"用策略驱动机器人"，它同样支持反过来"用人驱动机器人来采集数据"。采集模式（Collect）利用完全相同的控制台、机器人描述和传输后端，只是数据来源从AI策略变成了人工遥控。

操作方式是人手持一个"领导臂"，机器人上的"跟随臂"实时镜像模仿，同时框架逐帧记录机器人的实测状态和所接收的命令动作，两者都同时以关节角度和末端位姿的形式保存。录制开始前有明确的激活步骤，不会意外开始录制。

采集到的数据直接以LeRobot格式输出，这是一种业界通用的机器人学习数据格式：每步的观测和动作存成列式表格，摄像头画面存成H.264视频，附带数据集元数据。为了满足这种格式要求固定帧率的规定，框架在存储时把时间戳规整为精确等间隔，同时另存一列保留原始采集时刻，两者都不丢。

采集完成后，框架会对每一段录制进行质量检查，包括时间戳是否单调递增、摄像头帧是否完整、向量维度是否正确、数值是否有限、视频和数据表长度是否一致。有问题的片段不会被静默删除，而是把有问题的字段补零后保留，并标注问题原因，让研究人员有机会审查处理。操作员随后可以在控制台里以开环回放的方式逐帧检查整段录制，打上通过或不通过的标记，也可以附上文字备注，整个过程不会改动原始轨迹数据。

**七、让评估留下证据：可追溯的评估系统**

如果说数据采集是"生产素材"，评估就是"检验成果"——而EVA-Client把评估过程变成了有据可查的系统流程，而不是靠印象打分。

评估在"场景"层面组织。每个场景对应一种物体摆放方式加一条任务指令，并列出若干"里程碑"——也就是任务执行过程中的关键节点，例如"成功抓取物体"、"成功放置到目标位置"等。每次运行后，操作员对照里程碑列表逐项评分，而不是笼统地打一个通过/不通过。这样得到的是一个有层次的"过程分"，而不是单一的二元结果，可以更细致地分析策略在哪个步骤出了问题。

每次试验的结果都被持久化存储：按（场景、位置、试验次序）三元组索引，记录里程碑结果、得分、持续时长、文字备注，并通过一个视频片段标识符与对应的录像绑定，即使重启会话也不会错位。从这些结构化记录出发，系统可以自动计算每个场景的成功率和每个检查点版本的汇总统计，不需要人工再整理。

多个不同版本的模型可以在同一个会话内依次评估。切换"当前模型"时，框架透明地重新连接到新模型端点，在完全相同的场景设置下重新运行，确保不同模型的评估在同等条件下进行，结果可以直接对比。

日志记录方面，EVA-Client对每次运行记录三条平行的动作时间序列：策略原始输出的逐块预测、经过推理策略处理后的平滑动作，以及最终实际发给机器人的执行动作。每个时间步都标注了来自哪个动作块。有了这三条记录，如果机器人动作出现问题，研究人员可以精确定位是策略预测本身有误、还是平滑处理引入了偏差、还是执行层做了什么改变。

评估结果通过一个只读网页查看器展示，无需连接机器人或策略服务器即可访问。它提供每个检查点的统计数据、每个场景的细分结果，以及跨检查点的并排对比视图，每条评分记录都链接到对应的视频片段和里程碑详情。

**八、现有局限与未来规划**

诚实地说，EVA-Client目前也有几处尚待完善的地方。首先，它是部署基础设施，不是策略本身，也不是基准测试集，论文中展示的任务表现是真实部署观察，而非严格控制变量的对照实验。其次，摄像头支持目前主要面向基于ROS的机器人，非ROS机器人的图像采集还依赖各自的中间件。逆运动学求解器针对串联机械臂设计，其他形态（如人形机器人、移动底盘）需要额外的描述类和运动学模型。

在后续规划中，团队提出了四个方向。一是强化学习数据闭环：把评估运行产生的轨迹和结果标签直接用作强化学习或在线微调的素材，而不只是被动记录。操作员在运行中途接管并纠正机器人动作的"人在环中"采集模式也属于这一方向。二是层级策略支持：让EVA-Client能够托管高层规划器和底层控制器组成的层级策略，规划器通过挂钩接口下发子目标，执行状态可以上报。三是精细数据标注：在采集模式里增加对长时程任务的分段标注功能，把一段完整录制切分为带标签的子任务单元，让同一批数据在更细粒度上被复用。四是扩展机器人形态：把支持的机器人扩展到人形机器人和移动底盘，通过同一套描述类注册机制接入。

归根结底，EVA-Client想解决的问题说起来很简单：机器人AI的训练工具已经很成熟了，但把训练好的AI真正跑在实体机器人上的那套工具，长期处于"各做各的临时方案"的状态。这套框架试图填上这个空白，让部署、调试、采集、评估这几件事能在同一个地方、以可重复的方式完成，让不同团队对不同机器人跑不同策略的实验结果有了可比性的基础。

一个有意思的引申问题是：当部署标准化之后，机器人研究的"可重复性危机"会不会有所缓解？毕竟，如果两个团队报告同一个策略在同一类任务上的成功率截然不同，现在终于有了一个工具可以帮助追溯差异是来自策略本身、还是部署方式的不同。对这个问题感兴趣的读者，可以通过arXiv上的编号2607.02646找到完整论文，里面有更详细的技术细节和系统设计说明。

Q&A

Q1：EVA-Client支持哪些机器人型号？

A：EVA-Client目前支持Franka、UR5e、Galaxea R1-lite、AgileX Piper、AgiBot G2和ARX R5这六款机械臂。添加新机器人只需编写一个"机器人描述类"，说明关节组、摄像头位置和通信话题即可，不需要修改框架其他部分，后续还计划扩展到人形机器人和移动底盘。

Q2：EVA-Client的五种推理策略有什么区别，应该怎么选？

A：五种策略的核心区别在于推理和执行是否并行，以及如何处理前后两段动作预测的衔接。同步执行最简单但会产生停顿；异步预取用线性混合消除接缝；ACT风格时序集成对所有历史预测加权平均；朴素异步替换是只补偿延迟不混合的基线；实时分块从源头让服务器保证前后衔接。高动态任务通常需要异步策略，调试阶段适合同步执行。

Q3：EVA-Client采集的数据是什么格式，能直接用于训练吗？

A：EVA-Client采集的数据以LeRobot格式输出，这是机器人学习领域的通用格式，包含列式存储的观测与动作数据表、H.264摄像头视频和元数据文件。openpi、StarVLA、GR00T等主流训练框架都能直接读取这种格式，采集完成后不需要额外转换就可以送入训练。