FOC里最恶心的事，不是磁编码器不准，而是你永远在“低速安静”和“高速不迟”之间二选一

做 FOC 写到后面，很多人都会碰到一个很拧巴的现实：磁编码器不是不能用，也不是精度表上不好看，而是一旦真的进环路，它最折磨人的往往不是“准不准”，而是“慢不慢、抖不抖”。

AS5600 这类器件本身就带可编程的快/慢数字后处理滤波；类似 KTH5701 这类数字三轴 Hall 器件，也是在测量性能、功耗和读取方式之间做平衡。问题不在于它们有没有角度输出，而在于这些角度进了 FOC 以后，噪声和延迟会立刻变成两个互相掐架的东西。

低速最烦的，往往不是角度本身，而是速度一下子脏了

很多人第一次上磁编码器，看到的是角度值还能看，真正炸毛的是速度值。因为低速下你最常见的写法就是

这一步本质上是在做差分。只要角度有量化、抖动、总线读取时刻不稳，或者内部滤波让更新节奏不那么“干脆”，这些小误差都会在速度估计里被放大。AS5600 本身就是 12 位角度器件，同时内部还有可配置的数字后处理滤波；SimpleFOC 社区里围绕 AS5600 的一个典型抱怨，就是“角度能用，但 velocity 很容易变得 noisy / unstable”。这不是软件平白无故造出来的噪声，而是“角度链路不够干净”在速度差分里被放大了。

所以低速时你看到的“电机在抖”，很多时候并不完全是电机本体在抖，而是编码器角度链路的颗粒感、抖动和更新不确定性，经过速度估算以后，被放大成了控制器眼里的“速度噪声”。这也是为什么很多人一上低通、卡尔曼、滑动平均，表面上马上就“顺”了。

可你一把它滤顺了，高速又开始变迟

问题真正恶心的地方在这里：你低速刚把噪声压下去，高速又开始觉得电机“肉”“闷”“发热”“不跟手”。

根子很简单。滤波压掉的是高频噪声，同时也带来了相位滞后。 AS5600 的 datasheet 写得很直接：它有快滤波和慢滤波两套行为，快滤波是为了 step response，慢滤波是为了 noise；而且 step response 最后还要等两个完整采样周期，才能落到慢滤波决定的最终值上。这个表述已经说明问题了：你想更安静，就得接受更慢的响应；你想更快，就得接受更吵的输出。

放到 FOC 里，这个“更慢”不是抽象概念，而是直接变成电角度相位滞后。只要总延迟是 ，电角速度是 ，那相位落后大致就是

速度一高、极对数一多，这个账就会很难看。你在低速区加的那点滤波，到了高速区，常常就会变成电流环和速度环都在“追一个已经过去了的角度”。这时候电机不是不转，而是开始不利索、效率变差、发热变重，严重一点就会出现很明显的动态退化。这个因果链条，FOC 写久了的人都很熟。

I2C不是原罪，但它确实很容易把问题放大

很多人喜欢一句话把锅全甩给 I2C，说“I2C 不适合 FOC”。这么说太粗了，但也不是完全没道理。

先说客观事实：AS5600 支持 Fast-mode Plus I²C，从 datasheet 看，最大 SCL 频率是 ，纸面上并不算慢。可 FOC 里真正要命的，不是“总线理论最高能跑多快”，而是角度链路是不是足够确定。内部角度更新节奏、主控轮询时刻、任务调度、总线事务长度、速度差分窗口，这些东西只要凑在一起不够稳，最后都会在速度估计和相位滞后上体现出来。开发社区里对 AS5600 的一句非常典型的话就是：I2C is slow and will limit your performance compared to using a SPI based sensor。这个说法不算严谨的学术结论，但非常符合一线开发者的实际体感。

所以真正该说的是：I2C 不是不能闭环，而是它更容易把“角度更新不够确定、低速差分更脏、高速链路更迟”这些问题摊开来。 你拿它做旋钮、做慢速位置环、做人机输入，体验可能很好；你拿它硬扛高动态 FOC，链路里那些原本就存在的小毛病，马上就会被放大。这个差别，不在“有没有角度”，而在“这条角度链路能不能又快又稳地喂给控制器”。

换成更强一点的数字磁传感器，也不是自动通关

有人会说，那我别用 AS5600 这种旋钮味太重的器件，换成更灵活一点的，比如 KTH5701，不就好了？

这当然比最简角度器件更有空间。按昆泰芯公开口径，KTH5701 是数字输出三轴线性 Hall 芯片，支持 I2C 或 SPI，从原始磁场数据里结合软件算法提取运动信息；datasheet 也写了 continuous sensing mode、single mode、wake-up & sleep mode 等多种模式。问题是，这不代表它天然就是一条“零等待、零抖动、专为高带宽 FOC 准备好的角度流”。官方应用描述里，它更明确地提到的是 joystick、knob、displacement measurement 这类场景。

更关键的是它的读取机制。KTH5701 的 datasheet 写得很明白：在 continuous sensing mode 下，INT 低的时候芯片正在测量，这时主机不能读回结果；必须等 INT 拉高，表示一次测量完成后，才能 read back；而且测量间隔和单次测量时长还受工作模式、启用轴数及采样配置影响。换句话说，这是一条“测量—完成—读回”的链路，而不是你想什么时候取角度，就一定能在同一时刻拿到一个最新样本的链路。

这并不是说 KTH5701 不好，而是说：哪怕器件本身更灵活，只要你的链路还是“离散测量 + 主控读回 + 软件估算速度”，那个老问题就不会凭空消失。 它也一样会遇到低速想压噪、高速又怕迟的矛盾。只不过你可以用更多配置和接口，把这件事做得比低成本旋钮类器件更可控。

所以这事最恶心的地方，根本不是“磁编码器不准”

真正恶心的点，其实是这个：

你想让低速安静，就得接受一点迟；你想让高速不迟，就得接受一点吵。

这不是哪家算法工程师太菜，也不是开源库天生有坑，而是传感器前端、内部滤波、总线读取、速度估算和控制带宽一起构成的系统性交易。AS5600 这种器件把这个交易表现得尤其明显，所以开发者社区里围绕它的争议一直很多；而像 KTH5701 这种更灵活的数字 Hall 方案，虽然给了你更多接口和模式选择，但只要底层还是“测量—读回—软件解算”的结构，这笔账就还是要算。

所以做 FOC 真正该先问的，往往不是“这颗磁编码器精度几位、分辨率多少”，而是三句更残酷的话：

这条角度链路的总延迟是多少？ 这条角度链路的更新时刻稳不稳？ 这条角度链路在你要的速度区间里，到底是“更像传感器”，还是“更像一个经过了好几层加工才喂给控制器的角度值”？

前者决定你高速是不是还能跟得上，后者决定你低速是不是还能看得顺。 而你真正的痛苦，常常就是两边都想要，最后发现只能二选一。