机器人关节的实时总线：250 微秒周期是怎么稳住的

编译自 MDPI Actuators 2025, 14(2), 84　·　开放获取 CC BY 4.0

半主动假肢的脚踝要在一次摆动相里完成姿态调整。人正常行走时摆动相只有几百毫秒，这段时间里通信、计算和执行都得做完。摆不到位，脚就会磕在地上。留给通信协议的时间，按毫秒算已经算宽裕了。

威斯康星大学麦迪逊分校机械工程系的 Kieran M. Nichols、Rebecca A. Roembke 与 Peter G. Adamczyk 在 Actuators 上给出了一个具体做法：用一块树莓派 4 直接承载 CANopen over EtherCAT 主站，把两台无刷直流电机驱动器管起来，位置指令周期压到 250 微秒。这篇文章真正有分量的地方不是硬件有多便宜，而是它把"实时性究竟由什么决定"拆开量了一遍。

一块单板计算机同时管三件事

硬件清单不长。控制器是树莓派 4，博通 BCM2711 四核 Cortex-A72、4 GB LPDDR4 内存、超频到 2.0 GHz，它的板载以太网口直接充当通信物理层。两台 Elmo Gold Twitter 驱动器各带一台 Faulhaber 3216W012BXTHIEF3-1024L 无刷直流电机，电机后面接 22GPT 十四比一减速箱，额定扭矩 0.532 Nm，额定转速 4.59 转每秒。整机由 12 V 锂电池供电，升压到 24 V 供应使能信号，5 V 供霍尔传感器，树莓派自己靠一级降压从 12 V 取 5 V。

机械侧是一个两轴万向节加两个相对电机轴倾斜 5 度的楔形凸轮，通过蜘蛛联轴器与电机轴相连，脚板用现成的假肢部件。踝角调节范围在矢状面与额状面各 0 到 10 度。

协议栈选的是 CANopen over EtherCAT。EtherCAT 规定数据怎么传，CANopen 规定数据怎么定义，两者叠起来既有确定性传输，又有现成的对象字典。主站用开源的 SOEM，控制模式选循环同步位置模式，也就是驱动器按固定周期接收位置指令并同步执行。参数配置走服务数据对象，实时数据走过程数据对象，前者慢速、后者逐周期刷新。

抖动从哪里来，又靠什么压下去

决定周期稳不稳的是分布式时钟同步。Linux 侧的时钟要与驱动器的时钟对齐，误差来自调度抖动、以太网中断处理、内存拷贝这些零碎开销。作者把内核换成带 PREEMPT 实时补丁的 Debian LinuxCNC 镜像，内核版本 4.19.71 加 rt24 补丁，再把处理器核心分工固定下来：0 号核跑内核，1 号和 2 号核跑通用任务与程序，3 号核专门跑时钟同步的实时线程，2 号核同时承担通信线程。核隔离与绑核靠 isolcpu 与 taskset 完成。

光有实时内核还不够。同步线程每次等待时都要做一次比例积分补偿：比例误差是上一周期实际耗时与指令周期的差，积分误差在比例误差的正负号上累加。补偿增益定得不合适，周期会来回过冲；定得太保守，误差又收不回来。

作者把三个变量做成扫描：比例增益取 0.02、0.1、0.5，积分增益取 0.002、0.01、0.05，指令周期取 250、500、1000 微秒，一共七组配置，每组跑七次。结果差得很明显。以比例 0.1、积分 0.01、周期 250 微秒为基准组，实际周期 249.65 微秒，平均抖动 0.35 微秒，最大绝对抖动 60.96 微秒，周期标准差 6.59 微秒，处理器占用 13.37%。把比例增益提到 0.5、积分保持 0.01、周期仍是 250 微秒，实际周期变成 249.98 微秒，平均抖动降到 0.02 微秒，最大绝对抖动 46.40 微秒，标准差 4.51 微秒，处理器占用 12.48%。三项指标同时变好，这是整篇文章最漂亮的一组数据。

图1　实时控制链路的分层结构与处理器核心分配（依据原文第 3 节绘制）

周期放宽反而更费处理器。指令周期 500 微秒时占用升到 36.81%，1000 微秒时是 26.67%，最大绝对抖动涨到 119.3 微秒。作者的解释是周期越长，同步线程的等待窗口越宽，被其他任务抢占的概率反而上升。这说明实时系统里周期不是越长越省力，合适比宽松更重要。

图2　七组时钟同步参数下的抖动与处理器占用（依据原文表 3 绘制）

250 微秒周期下的运动账

运动性能的测试方式是 33 种预设踝配置随机重复九轮，总共 297 次动作指令，其中 6 次因卡滞被剔除，有效样本 291 次。95% 上升时间平均 0.128 秒，标准差 0.037 秒；稳定时间按速度降到每秒 1 度以下判定，平均 0.193 秒，标准差 0.076 秒。最终角度误差在矢状面平均 0.107 度、额状面平均 0.153 度，都落在 0.2 度以内。

把这组数字放回场景里看。稳定时间中位数 0.185 秒，最大值 0.45 秒。摆动相要留出余量，中位数决定常规步态能不能跟上，最大值才是设计边界。文章的目标是让假肢在单个摆动相内完成调整，从数据看中位数够用，长尾还得靠控制器侧再优化。

和工控机比，差在哪一格

作者把结果和已有平台做了对照。一台英特尔 i3 系统在同样 250 微秒周期下最大抖动约 64 微秒，平均抖动 0.008 微秒，标准差 23 微秒，处理器占用 3.8%；另一台英特尔 i7 驱动的协作机器人在 1000 微秒周期下最大抖动 10 微秒。本系统最大绝对抖动 46.40 微秒，平均抖动 0.02 微秒，介于两者之间。

差距的来源可以解释。最大抖动由最坏情况下的调度延迟决定，与处理器绝对性能、内存带宽、中断延迟都有关，树莓派这类单板计算机在这一点上天生吃亏；平均抖动反映常态，靠实时补丁和核心隔离就能压得很低。这也解释了为什么作者把落点定在 250 微秒，而不是继续往 100 微秒压。

硬件之外还有一层意义。过去做这类实时控制，通常要用带 EtherCAT 从站芯片的专用控制器，或者上工控机加实时内核。用通用单板计算机加开源主站把这件事做成，成本结构会变，调试链也会变。文章没有回避代价：安全停止与安全扭矩关断这两个功能在实验里是关闭的，说明样机距离合规产品还有距离。