从 RSS 2026 操控论文看，学术界和工业界的鸿沟比想象中更大

Photo by Markus Winkler / Pexels

---

为什么仿真里跑得飞快的灵巧手，一到真实产线就各种“掉帧”？RSS 2026 的操控论文我看了一圈，几乎清一色在仿真环境或精心布置的实验室里验证，极少提及“中断延迟”和“实时性要求”这两个嵌入式工程师最头疼的词。

有意思的是，今年明显分成了两派：一派是传统基于模型预测控制（MPC）的优化派，另一派是端到端学习派。MPC 派的论文开始强调将动力学模型简化到能跑在嵌入式处理器上，比如用多项式近似替代完整雅可比，但代价是精度下降，且对传感器噪声敏感。而学习派则更激进，把整个抓取策略塞进一个 50MB 的神经网络，依赖 GPU 推理。

从落地角度看，两派目前都离工业级差一个“中断延迟”。MPC 的实时性瓶颈在优化求解器，即使是简化版，在 STM32 级别的 MCU 上仍无法保证 1kHz 的更新率，而飞控要求 IMU 数据融合至少 500Hz。学习派的推理延迟更不可控，端到端网络输出频率通常只有 20-50Hz，稍微来个意外扰动，后续动作就全错。

我注意到一篇论文很有意思：它用了一个混合架构——先由传统 MPC 生成粗轨迹，再由一个小型残差网络在线修正抓取姿态。这种做法在仿真里提升了 30% 的鲁棒性，但作者没提实际部署时 MCU 的算力能否同时跑两个东西。如果要在 DJI 的 RoboMaster 机械臂上复现，我估计得先砍掉一半的视觉处理，腾出 CPU 时间。

趋势预测：未来 3-5 年，工业界不会接受纯端到端的学习方案，因为“黑箱”无法通过安全认证。但传统 MPC 也扛不住复杂环境。真正的出路是“固化+轻量化”：把感知和控制的规则部分固化到 FPGA 或专用协处理器，把学习部分压缩到 1MB 以下，跑在 RTOS 的实时线程里。RSS 2026 的论文已经有人往这个方向试探，但离成熟还差一个量产级的稳定性和成本控制。

原文链接：https://www.leiphone.com/category/private/7a8PVDUwLrXG8LgX.html