---
title: DaDu-Corki
link: https://arxiv.org/abs/2407.04292
doi: arXiv:2407.04292
status: "已阅读"
doc_type: paper
tags: [实时VLA, 实时动作生成, Embodied AI, 软硬件协同设计, 轨迹预测, 机器人控制加速]
date: 20260704
---

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

[Paper](https://arxiv.org/pdf/2407.04292)

---

## 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，主要做了三层改动：

1. **算法层：从单帧动作预测变成近未来轨迹预测**
   - Baseline 每次预测下一步 7-DoF action。
   - Corki 每次预测未来一段轨迹，用一条连续轨迹覆盖多个控制步，从而降低 LLM inference 频率。
   - 轨迹长度可以固定，也可以通过 waypoint / curvature / gripper change 做自适应截断。

2. **硬件层：为轨迹到力矩控制设计专用加速器**
   - 输入是轨迹、速度、加速度以及机器人关节状态。
   - 输出是各关节 motor torque。
   - 针对 task space computed torque control (TS-CTC) 中的 forward kinematics、Jacobian、mass matrix、bias force 等模块做数据流加速和中间结果复用。

3. **系统层：让通信和执行流水线化**
   - 轨迹参数下发后，机器人继续执行轨迹。
   - 执行过程中提前采集图像并上传服务器。
   - 通信延迟被隐藏在机器人执行轨迹的时间里。

最终效果：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 等矩阵影响很小，于是可以复用上一周期结果，而不是每次全量重算。

做法是：

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

论文观察到，在不损失控制精度的情况下，可以避免超过 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

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

1. 预测多步轨迹，减少 LLM inference frequency。
2. 专用硬件加速控制计算。
3. 通信与轨迹执行并行，隐藏 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](Streaming-Flow-Policy.md) 是从生成模型角度把动作生成变成沿物理时间的流式更新，目标是让策略每一步都能输出可执行动作。

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 是否过于简单？