DaDu-Corki

DaDu-Corki: Algorithm-Architecture Co-Design for Embodied AI-powered Robotic Manipulation (Arxiv 2025)

Motivation

现有 Embodied AI / VLA 系统通常以视频帧为单位运行：

\text{Observation} \to \text{LLM/VLM Inference} \to \text{Action} \to \text{Robot Control} \to \text{New Observation}

这个 pipeline 的问题是：

每一帧都要做一次大模型推理，推理延迟和能耗成为主要瓶颈。
LLM inference、机器人控制、数据通信串行累加，端到端 frame latency 很高。
前端感知/规划和后端控制的频率需求不一致，但 frame-by-frame 设计强行让两者同频。
机器人控制本来更自然的单位是轨迹，而不是单帧动作。

论文在 RoboFlamingo 上做 profile：端到端 frame latency 可到 249.4 ms；其中 LLM inference 占 76.9% 延迟和 98.0% 能耗，通信占 19.0% 延迟，控制本身在 baseline 里只占 4.1% 延迟。

因此 Corki 的核心问题不是“如何让 VLM 本身更强”，而是：如何把 LLM 低频规划、机器人高频控制、通信传输拆开，让系统整体满足实时约束。

Contribution

Corki 是一个 algorithm-architecture co-design framework，主要做了三层改动：

算法层：从单帧动作预测变成近未来轨迹预测
- Baseline 每次预测下一步 7-DoF action。
- Corki 每次预测未来一段轨迹，用一条连续轨迹覆盖多个控制步，从而降低 LLM inference 频率。
- 轨迹长度可以固定，也可以通过 waypoint / curvature / gripper change 做自适应截断。
硬件层：为轨迹到力矩控制设计专用加速器
- 输入是轨迹、速度、加速度以及机器人关节状态。
- 输出是各关节 motor torque。
- 针对 task space computed torque control (TS-CTC) 中的 forward kinematics、Jacobian、mass matrix、bias force 等模块做数据流加速和中间结果复用。
系统层：让通信和执行流水线化
- 轨迹参数下发后，机器人继续执行轨迹。
- 执行过程中提前采集图像并上传服务器。
- 通信延迟被隐藏在机器人执行轨迹的时间里。

最终效果：Corki 将 LLM inference frequency 最高降低到 $5.1\times$ ，带来最高 $5.9\times$ speedup；成功率最高提升 13.9%（论文正文表格中在 seen task 的 average job length 上 Corki-5 相对 baseline 提升 17.3%）。

Limitation

Corki 的收益强依赖“未来一段轨迹在当前观测下足够可靠”这个假设。

如果环境快速变化、物体被外部扰动、接触状态变化很频繁，那么长轨迹会降低闭环反馈频率，导致模型错过关键新信息。论文的实验也显示实际执行轨迹越长，速度越快，但准确率不是单调提升：Corki-5 通常比 Corki-9 更稳。

另外，硬件加速部分主要围绕 TS-CTC 和 7-DoF Franka 机械臂展开。它证明了方向有效，但迁移到不同机器人形态、不同控制器、不同动力学建模方式时，硬件设计不一定能直接复用。

Architecture

Baseline: Frame-by-frame Action Prediction

RoboFlamingo 由 VLM 和 policy head 组成：

VLM 输入语言指令和图像序列，输出 vision-language token。
policy head 使用 LSTM 维护时序状态。
输出为 7-DoF action：三维位置变化、三维旋转变化、夹爪开合状态。

训练目标分为两部分：

\mathcal L = \mathcal L_{pose} + \lambda \mathcal L_{gripper}

其中 pose 使用 MSE，gripper 使用 BCE。

这个形式的问题是：数据采集时真实动作本来是一段连续轨迹，但训练时被拆成 30Hz 的离散 action。离散化后模型只对“下一帧”负责，而机器人执行时又需要平滑高频控制。

Basic Corki: Trajectory Prediction

Corki 不再预测单个 action，而是预测近未来轨迹。对前 6 个连续控制变量，用三次函数表示轨迹：

x(t)=a_xt^3+b_xt^2+c_xt+d_x

其他维度同理；夹爪状态仍然是二值变量。

模型真正输出的是每个维度的轨迹参数，而不是每个 frame 的离散 action。训练时不直接监督参数，因为：

数据集通常不直接提供三次轨迹参数，需要额外拟合，会引入误差。
不同参数尺度差异大，不利于网络学习。

因此论文选择监督“轨迹本身”：

\mathcal L_{traj}=\sum_t \|\hat{\xi}(t)-\xi(t)\|_2^2

直觉上，这相当于让模型直接对未来轨迹负责，而不是先把轨迹拆成一堆 frame action 再学习。

Masked Policy Head

因为 Corki 推理时不再每一帧都调用 VLM，训练时也要模拟“视觉信息变少”的情况。

做法是：在输入 token 序列中，把部分真实 vision-language token 替换成 mask embedding。这样 policy head 学到的是：即使中间若干帧没有新 VLM token，也能根据历史 token 和当前隐藏状态继续预测未来轨迹。

这和 BERT 的 mask 思路类似，但目的不是语言建模，而是让机器人策略适应低频感知/规划。

Adaptive Trajectory Length

固定预测长轨迹可以减少推理频率，但会带来开环时间过长的问题。Corki 用 waypoint 机制自适应决定实际执行到哪里。

假设模型一次预测 $N$ 个 step 的轨迹，每个 step 对应一个 waypoint。运行时从近到远检查 waypoint：

如果相邻 waypoint 之间夹爪状态变化，说明可能发生抓取/释放等关键事件，应提前终止轨迹。
如果轨迹局部曲率高，说明机器人正在进行明显转向或状态切换，应提前终止轨迹。
如果轨迹较平滑，则执行更长一段，减少 LLM inference 次数。

论文使用两个几何指标判断高曲率：

相邻轨迹段夹角是否超过阈值（论文中使用 90 度）。
中间点到起终点连线的距离是否超过阈值。

这个策略本质上是在做 accuracy-latency tradeoff：

\text{longer trajectory} \Rightarrow \text{lower inference frequency, higher latency saving}

\text{shorter trajectory} \Rightarrow \text{higher feedback frequency, better robustness}

Closed-loop Control

Basic Corki 在一段轨迹执行完成前是 open-loop 的。为了减少误差累积，论文在轨迹执行过程中随机提前发送图像：

\text{Executing Trajectory} \parallel \text{Capture and Upload Observation}

新图像会先经过 ViT 编码，再和原先的 LLM token 拼接，用来预测下一段轨迹。这样系统仍然不是逐帧闭环，但至少能在轨迹执行期间提前准备下一轮反馈。

Hardware: TS-CTC Accelerator

Corki 的控制模块使用 task space computed torque control (TS-CTC)。输入包括：

参考轨迹 $\xi$ 。
轨迹一阶导 $\dot{\xi}$ 和二阶导 $\ddot{\xi}$ 。
当前关节角 $q$ 和关节角速度 $\dot q$ 。

输出为关节力矩 $\tau$ 。

TS-CTC 的关键计算模块包括：

Forward Kinematics
Jacobian
Task Space Mass Matrix
Task Space Bias Force

这些模块之间有大量中间结果可复用。例如 Jacobian 会复用 forward kinematics 的结果，mass matrix / bias force 又会复用 Jacobian 相关结果。

Corki 的硬件设计包括：

dataflow accelerator：用 FIFO 和 line buffer 串起主要算子，增强流水线并行。
customized circuits：针对 mass matrix、bias force 等模块复用中间数据。
on-chip buffer：尽量避免执行时访问 off-chip DRAM。
micro-controller：处理不同模块延迟不一致带来的 stall。

Application-specific Approximate Computing

论文还利用机器人控制的一个特点：控制频率高，但相邻控制周期中关节状态变化很小。

对于一些关节，小角度运动对 mass matrix / Jacobian 等矩阵影响很小，于是可以复用上一周期结果，而不是每次全量重算。

做法是：

根据每个关节角变化估计对应矩阵是否需要更新的概率。
如果概率超过阈值，就重新计算。
否则复用上一周期结果。

论文观察到，在不损失控制精度的情况下，可以避免超过 51% 的矩阵更新。

System Pipeline

Corki 的运行过程可以简化为：

\text{Server predicts trajectory} \to \text{Robot controller executes high-frequency torque control} \to \text{Camera captures images during execution} \to \text{Server prepares next trajectory}

相比 baseline：

\text{Inference} + \text{Communication} + \text{Control}

Corki 更接近：

\text{Inference every }N\text{ steps} + \max(\text{Communication}, \text{Control Execution})

也就是同时减少大模型调用次数，并把通信延迟藏到轨迹执行时间里。

Experiments

Setup

Base Model：RoboFlamingo
Dataset / Environment：Calvin
Tasks：34 个任务，覆盖移动物体、开关、抽屉推拉、旋转物体、抬起物体等
Robot：7-DoF Franka Emika Panda
Inference：NVIDIA V100
Control baseline：Intel i7-13700 CPU
Hardware prototype：Xilinx Zynq-7000 SoC ZC706 FPGA
Metrics：
- success rate
- average job length（一个 job 中最多连续完成 5 个任务）
- trajectory RMSE / maximum trajectory distance
- latency / energy

Variants

Corki 每次预测 9 个 future steps，但实际执行长度可变：

Corki-1 / 3 / 5 / 7 / 9：固定执行对应 step 数。
Corki-ADAP：通过 waypoint identification 自适应选择执行长度。

Accuracy

Seen tasks 中：

RoboFlamingo average job length：2.916
Corki-5 average job length：3.421
Corki-ADAP average job length：3.200

Unseen tasks 中：

RoboFlamingo average job length：2.480
Corki-5 average job length：2.824
Corki-ADAP average job length：2.827

整体趋势：

Corki 大多数配置都优于 baseline。
Corki-5 通常是固定步长中表现最好的配置。
Corki-9 在 seen task 仍然可用，但在 unseen task 上低于 baseline，说明长开环轨迹会伤害泛化和反馈能力。
Corki-ADAP 在 unseen task 上略优于 Corki-5，说明根据曲率/夹爪变化动态缩短轨迹是有效的。

Trajectory Error

论文报告 Corki 平均降低 25.0% 轨迹误差。

但 trajectory error 和 success rate 并不完全一致。原因是：

轨迹误差只反映末端运动趋势，不能完整衡量任务完成。
gripper 状态对成功率很关键，但不完全体现在连续轨迹误差中。
有些任务只要关键接触/抓取点正确，即使轨迹略偏也能成功。

Latency / Energy

主要性能收益来自三部分：

预测多步轨迹，减少 LLM inference frequency。
专用硬件加速控制计算。
通信与轨迹执行并行，隐藏 communication latency。

论文在摘要中报告最高 $5.9\times$ speedup，LLM inference frequency 最高降低 $5.1\times$ ，成功率最高提升 13.9%。

My Takeways

和 Action Chunking 的区别

Corki 看起来也像 action chunking：一次预测未来多个 step。但它更强调“轨迹”而不是“动作序列”：

Action Chunking 预测的是离散动作序列 $a_{t:t+H}$ 。
Corki 预测的是连续轨迹参数 $\xi(t)$ ，再由控制器生成高频 torque。

这使它更接近机器人控制里的传统分层结构：

\text{low-frequency planner} \to \text{trajectory} \to \text{high-frequency controller}

对实时 VLA 来说，这个抽象比直接预测 action token 更贴近执行系统。

和 Streaming Flow Policy 的关系

Streaming Flow Policy 是从生成模型角度把动作生成变成沿物理时间的流式更新，目标是让策略每一步都能输出可执行动作。

Corki 是从系统角度把动作输出变成轨迹，并且让轨迹执行、感知上传、下一轮推理重叠。

二者的共同点是都在反对“完整生成一个 chunk 后再执行”的笨重方式：

Streaming Flow Policy 关心动作分布和生成过程。
Corki 关心实时系统 pipeline 和硬件控制链路。

如果结合起来，一个比较自然的方向是：用 Streaming Flow / diffusion policy 生成近未来轨迹，但运行时仍然采用 Corki 这种通信-执行重叠 pipeline。

轨迹预测是一种更机器人友好的监督

这篇论文最有价值的观点之一是：机器人数据天然是轨迹，而 frame-by-frame action 是人为切出来的监督形式。

如果真实采集过程本来是连续控制，那么把它拆成 30Hz action 会丢失平滑性和全局几何结构。Corki 直接监督轨迹，可能不只是加速，也让模型更容易学到动作趋势。

这点和很多 VLA 论文的方向有差异：不少工作优先解决 tokenization、action chunk、diffusion/flow generation，而 Corki 回到机器人控制的基本单位：trajectory。

疑惑

用三次函数拟合轨迹，这对相对平滑的末端移动足够，但对接触丰富的 manipulation 是否过于简单？