2. 性能指标定义：延迟、抖动、吞吐量与确定性
各位工程师朋友，咱们开始聊正题。
做运动控制，说白了就是在跟时间赛跑。你发出的指令，电机能不能准时响应？响应得稳不稳？系统能同时处理多少任务？这些问题的答案，就藏在四个核心指标里：延迟、抖动、吞吐量、确定性。
我刚开始做实时系统那会儿，也踩过不少坑。有一次调试一台六轴机器人，明明指令发得挺快，可末端执行器就是抖得厉害。查来查去，最后发现是网络延迟抖动在作怪。嗯，从那以后，我对这几个指标就格外上心了。
2.1 延迟：你的指令到底慢在哪？
延迟，就是从一个事件发生到系统做出响应所经过的时间。在运动控制里，我习惯把它拆成三段来看：
- 通信延迟：指令从上位机传到控制器的时间。比如EtherCAT总线，一个周期也就几十微秒。
- 计算延迟：控制器处理指令、跑算法的时间。轨迹插补、PID计算都算在内。
- 执行延迟：驱动器把控制信号变成电机转动的过程。包括PWM更新、电流环响应。
测量方法其实不复杂。我常用的办法是在发送指令时打一个时间戳，在电机编码器反馈回来时再打一个。两个时间戳一减，就是端到端的延迟。
实际案例：
我曾经调试一个激光切割平台，发现切割圆角时总有个小偏差。用示波器一量，从PC发指令到驱动器响应，延迟竟然有2.3ms。后来优化了EtherCAT的DC同步机制，降到了0.5ms以内，问题就解决了。
测量小技巧：
用示波器测延迟时，记得把GPIO引脚拉高作为触发信号。这样能精确到纳秒级。别光靠软件打时间戳，软件本身就有不确定性。
2.2 抖动：稳定比快更重要
抖动，说白了就是延迟的波动。你想想看，如果每次延迟都是1ms，那还好办。可如果有时候0.5ms，有时候2ms，系统就乱套了。
我见过最典型的例子：某台贴片机，取放周期要求10ms。平均延迟只有0.8ms，看起来不错。可抖动达到了±0.6ms，结果就是贴片位置忽左忽右，良品率直线下降。
抖动的测量方法：
- 连续采集N次延迟数据（N建议取1000以上）
- 计算最大值与最小值的差，这就是峰峰值抖动
- 计算标准差，这是均方根抖动
// 抖动测量伪代码
uint32_t latency_samples[1000];
for (int i = 0; i < 1000; i++) {
uint64_t t1 = get_timestamp();
send_command();
wait_for_response();
uint64_t t2 = get_timestamp();
latency_samples[i] = (uint32_t)(t2 - t1);
}
// 计算峰峰值抖动
uint32_t jitter_pp = max(latency_samples) - min(latency_samples);
// 计算标准差
float mean = average(latency_samples);
float variance = 0;
for (int i = 0; i < 1000; i++) {
variance += (latency_samples[i] - mean) * (latency_samples[i] - mean);
}
float jitter_rms = sqrt(variance / 1000);
注意：
抖动测量时，要排除系统启动阶段的数据。刚上电那会儿，缓存还没预热，延迟往往偏大。等系统运行稳定了再采集，数据才有参考价值。
2.3 吞吐量：别让系统堵车
吞吐量，就是单位时间内系统能处理多少任务。在运动控制里，我通常关注两个维度：
| 维度 | 定义 | 典型值 |
|---|---|---|
| 指令吞吐量 | 每秒能处理多少条运动指令 | 1000-10000条/秒 |
| 轴吞吐量 | 系统能同时控制多少轴 | 4-128轴 |
| 数据吞吐量 | 每秒能处理多少传感器数据 | 10-100 MB/s |
测量吞吐量，我习惯用压力测试法。先发少量指令，然后逐步增加，直到系统出现丢包或超时。那个临界点，就是系统的最大吞吐量。
避坑指南：
我曾经测试一款运动控制卡，标称能控制32轴。可实际跑到24轴时，EtherCAT总线就开始丢包了。后来发现是CPU的PCIe带宽不够。所以，标称值只能参考，实际测试才是王道。
2.4 确定性：可预测才是硬道理
确定性，是实时系统的灵魂。它指的是：在给定的条件下，系统每次的行为都是可预测的。
举个例子：你要求系统每1ms执行一次位置环。如果延迟是0.3ms，抖动是±0.05ms，那这个系统就有很好的确定性。但如果延迟有时候0.3ms，有时候1.5ms，那确定性就很差。
我判断一个系统是否具有确定性，主要看三点：
- 最坏情况执行时间（WCET）：所有任务在最差条件下的执行时间。这个值必须小于控制周期。
- 时序可重复性：同样的输入，每次输出的时序是否一致。
- 中断响应时间：从中断触发到中断服务程序开始执行的时间，必须稳定。
我的经验：
提高确定性，最有效的方法是减少中断嵌套和关中断的时间。我一般要求关中断时间不超过10微秒。另外，把实时任务绑定到独立CPU核上，也能大幅提升确定性。
2.5 四个指标的关系
这四个指标不是孤立的。它们之间相互影响：
- 延迟大了，吞吐量自然上不去。因为每个任务占用的时间变长了。
- 抖动大了，确定性就差了。你没法预测下一个任务什么时候完成。
- 为了提高吞吐量，你可能需要降低延迟。但过度优化延迟，反而可能引入抖动。
我个人的经验是：在运动控制中，确定性优先，抖动次之，延迟再次，吞吐量最后。为什么？因为运动控制讲究的是「准时」，而不是「快」。你哪怕慢一点，只要每次都准时，系统就能稳定运行。
总结一下：
延迟看的是速度，抖动看的是稳定，吞吐量看的是容量，确定性看的是可靠。这四个指标，就是衡量实时系统性能的四个维度。下次你调试运动控制系统时，不妨从这四个角度去分析问题，往往能事半功倍。
公众号:蓝海资料掘金营，微信deep3321