129、运动控制中的软件架构：分层设计

运动控制中的软件架构：分层设计

从一次半夜的电机啸叫说起

凌晨两点，车间里只剩示波器的荧光。我盯着那根诡异的电流波形——电机在低速运行时发出刺耳的啸叫，像指甲划过黑板。PID参数调了无数遍，滤波器换了好几种，问题依旧。直到我打开同事留下的代码，发现他把电流环、速度环和位置环的所有计算全部塞进了一个2000行的中断服务函数里。

那一刻我明白了：不是算法不行，是架构烂了。

运动控制软件最容易被忽视的陷阱，就是以为只要算法对，代码怎么写都行。直到你遇到高频噪声、实时性抖动、或者像我这样半夜被电机“骂”醒。

为什么必须分层？一个血泪教训

先说说那次事故的根源。那个中断函数里，电流采样、坐标变换、PID计算、速度估算、位置插补全部串行执行。看起来逻辑清晰，但问题在于：

• 电流环需要1kHz以上的更新率，而位置环可能只需要100Hz
• 速度估算需要低通滤波，但滤波器的计算延迟会直接影响电流环的响应
• 一旦位置环出现异常（比如限位触发），整个中断被阻塞，电流环直接失控

这就是典型的“一锅烩”架构。运动控制天然存在不同时间尺度的任务：电流环是微秒级，速度环是毫秒级，位置环是十毫秒级。把它们强行绑在一起，就像让F1赛车和拖拉机跑同一赛道。

分层架构的黄金法则：时间尺度隔离

我现在的做法，简单粗暴但有效：按时间常数分层，每层独立运行，层间通过接口通信，绝不跨层调用。