编码器速度反馈这件事，我在不同项目里翻过好几次车。最开始做伺服驱动器的时候，我图省事直接对位置做微分算速度，结果低速段抖得没法看，高速段又滞后严重。后来换成硬件定时器测频，噪声倒是小了，但分辨率又不够。再后来我才发现，硬件测量和软件微分压根不是"谁替代谁"的关系，而是两套各有适用边界的方案，选错了，整个速度环都会跟着遭殃。这篇我打算把两种路线的原理、实现、坑点和选型逻辑一次讲清楚，适合正在做电机控制、机器人关节、CNC进给轴或者任何需要编码器速度反馈的朋友参考。

1. 速度反馈为什么不能随手糊弄：控制环的带宽与延迟约束

1.1 速度环在整个控制架构里的位置

绝大多数运动控制系统都是三环结构：电流环在内，速度环居中，位置环在外。电流环负责转矩，速度环负责让电机转速跟上给定值，位置环负责最终定位。速度环的带宽通常比位置环高一到两倍，而电流环又比速度环高一到两倍，这个级差关系决定了速度反馈的质量直接卡住整个系统的动态性能。

速度环的输入是速度给定和速度反馈的差值，经过PI调节器后输出电流给定。如果速度反馈本身有延迟或者噪声，PI调节器就会把这些干扰全部吃进去，表现出来就是转矩波动、异响、甚至振荡。这不是玄学，是控制理论的必然结果：反馈通路上的任何非线性或滞后，都会等价地附加到前向通路上。

1.2 延迟对相位裕度的影响

速度反馈的延迟对系统稳定性的影响，比很多人想象的要大。假设速度环带宽要做200Hz，那么允许的总延迟大约在带宽的十分之一量级，也就是2ms左右。这个延迟包括采样延迟、滤波延迟、计算延迟三部分。软件微分如果只做一阶差分，数学上只有一个采样周期的延迟，听起来不多，但如果你在差分之后再加一个低通滤波器去压噪声，滤波器的相位滞后在带宽频率附近可能就有十几度到几十度，这就逼着你把PI增益降下来。

硬件测量的优势在于，频率到电压的转换或者脉冲周期的测量往往是连续进行的，没有采样保持的步进感，延迟可以做得很小。但硬件方案也有自己的问题：分辨率受限、温漂、非线性，这些后面会细说。总之，速度反馈方案的选择，本质上是延迟、分辨率、噪声三个指标之间的博弈。

2. 软件微分这条路：为什么会翻车，以及怎么救

2.1 数值微分的本质是噪声放大器

软件微分最朴素的做法就是对位置序列做差分：

v[k] = (p[k] - p[k-1]) / Δt

这个公式看着人畜无害，但它的频域特性是一个高通滤波器，增益随频率线性上升。编码器位置输出是离散的整数值，量化误差在±0.5个脉冲之间，如果编码器是1000线、做4倍频解码后每转4000个计数，那么一个计数对应0.09度。假设位置采样周期是1ms，那么量化误差对应的速度噪声就是0.09度/0.001s = 90度/秒，也就是15转每分钟。

这个噪声有多大，取决于你的控制对象。如果是一个几十瓦的小直流电机，额定3000RPM，15RPM的噪声只是0.5%的波动，可能还能接受；但如果是一个低速高精度的转台，额定转速只有10RPM，那15RPM的量化噪声直接就把信号淹没了。这就是软件微分最核心的问题：它把位置量化误差除以时间间隔放大成速度噪声，时间间隔越短，噪声越猛。

2.2 低速段的分辨率死区

软件微分在低速段还有一个更隐蔽的问题，叫分辨率死区。当电机转速很低时，每个采样周期内可能只有0个或1个编码器计数变化。如果连续几个周期都是0变化，微分出来的速度就是0；隔一个周期突然出现1个计数，速度又跳到某个非零值。实际效果就是速度反馈在0和一个固定值之间反复跳变，速度环看到的是一个方波形状的反馈，PI输出跟着抖动，电机在低速段就会一卡一卡的。

这个问题靠滤波是压不下去的。你可以在微分之后加一个截止频率很低的低通滤波器，但代价是相位滞后急剧增加，速度环带宽被压缩得很厉害。我在某个转台项目里试过，把低通滤波器的截止频率压到5Hz，噪声倒是没了，但位置环做一个阶跃响应，速度反馈要慢悠悠跟上去，整机性能完全不可用。

2.3 换个思路：M法、T法、M/T法的本质

要救软件微分，不能只在差分公式上打转，要换测量策略。工程上常用的三种测速方法，本质上都是在处理"量化噪声和时间窗口"这对矛盾：

• M法（测频法）：固定时间窗口内数编码器脉冲个数。高速时精度高，低速时分辨率差，和直接微分的问题一样。
• T法（测周法）：测量相邻两个脉冲之间的时间间隔。低速时精度高，高速时因为脉冲间隔太短，定时器分辨率不够，误差反而变大。
• M/T法：同时测量固定时间窗口内的脉冲数和最后一个脉冲的时间，结合起来。低速时用T法的优势，高速时用M法的优势，是全范围性能最均衡的软件方案。

M/T法的公式看起来简单，但实现细节不少。关键是"最后一个脉冲的时间戳"要准，这要求编码器脉冲输入能够触发硬件捕获中断。如果你用的MCU没有输入捕获功能，M/T法就退化成M法。所以你看，所谓"软件微分"其实并不纯粹是软件的事，做到后面还是得依赖硬件资源。

3. 硬件测量：把测速从"算"变成"看"

3.1 专用F/V转换芯片的用法与局限

硬件测速最经典的一类方案是频率-电压转换芯片，用锁相环原理把输入脉冲的频率线性转换成模拟电压。这类芯片内部有一个电荷泵和一个比较器，脉冲频率越高，输出的平均电压越高。芯片外围只需要几个电阻电容，电路非常简洁，适合老式变频器和伺服驱动器的早期产品。

但这类芯片的局限性也很明显。首先是响应速度：为了滤除脉冲本身的纹波，输出端必须接一个较大的滤波电容，这会把转换的带宽压到几十赫兹以下。其次是温漂和非线性：电荷泵的充放电精度受温度和电压影响，精度通常只有百分之一左右，做高性能速度环是不够的。我用过这类芯片做闭环，结果是低速时输出纹波小，但动态响应慢得像在糖浆里游泳。

3.2 定时器输入捕获：硬件辅助的隐含测速

更常用也更可靠的做法，是用MCU的定时器输入捕获功能来实现T法测速。把编码器的脉冲信号接到定时器的捕获通道上，让硬件自动记录每个脉冲到达时的计数值。软件只需要在捕获中断里读一下时间戳，做一次减法，就能得到精确的脉冲周期。

这种方式的关键在于定时器的时钟频率。假设定时器时钟是100MHz，编码器线数1000，4倍频后4000个计数每转，那么每个计数对应的速度就是1转/4000计数。对于1RPM的转速，脉冲频率是4000/60≈66.7Hz，周期是15ms，对应时间戳差值是1.5M个定时器计数，分辨率轻松达到0.01RPM量级。这是软件微分完全做不到的精度。

不过定时器捕获方案有个死穴：高速时脉冲间隔太短。如果电机转速到6000RPM，脉冲频率到了400kHz，周期2.5微秒。定时器必须在2.5微秒内完成一次捕获、读值和中断处理，CPU占用率会非常可观。这种情况下要么换更高性能的MCU，要么就必须退回到M法。

3.3 FPGA并行测速：多通道高性能的答案

如果同时测量多个轴的编码器速度，MCU的中断处理能力就会成为瓶颈。这时候FPGA方案的优势就出来了：每一个轴分配一个定时器捕获模块，完全是硬件并行，不占用CPU时间。FPGA内部对每一个编码器通道做4倍频解码、增量计数、周期捕获，CPU只需要在需要的时候读一下寄存器就行。

用FPGA还有一个附带的好处，就是可以同时保留M法和T法的测量能力，让上层软件随时切换。我在一个四轴机器人控制器里就是这么做的：四路编码器信号进FPGA，FPGA每1ms刷新一次各轴的速度寄存器，CPU完全感觉不到测速这个环节存在。代价是，如果只是为了测速去上一颗FPGA，成本多半是划不来的。这个方案适合本身就需要FPGA做插补或者多轴同步的项目。

4. 硬碰硬对比：分辨率、延迟、噪声、成本四个维度

4.1 一张表看懂两种路线的真实差距

这张表里最值得玩味的是"测量延迟"这一行。软件微分看上去只有一两个采样周期的延迟，但为了压噪声加上低通滤波器之后，实际等效延迟可能超过硬件方案。硬件F/V转换看似延迟很大，但因为它是连续模拟量，如果不用额外滤波，它的响应其实是即时的。问题在于绝大多数应用都要在输出端加滤波，所以这个优势也会被抵消一部分。

4.2 从控制环的角度重新审视噪声与延迟

做速度环选型，不能只看测量指标，要看它对闭环带宽的影响。拿一个具体的例子算一笔账：编码器1000线，4倍频后4000计数/转，采样周期1ms。

如果采用M法测速，每个周期最多数到约66个脉冲，速度分辨率是1/66×额定转速，约1.5%额定转速。这时候你就不可能做高带宽的速度环，因为反馈信号本身就是粗颗粒的，PI增益稍微调大一点就会把量化噪声放大到电流环里。

如果采用T法测速，假设电机在10RPM的低速下，脉冲间隔15ms，定时器100MHz，测量分辨率可以达到0.001RPM以下。噪声不再来自量化，而是来自定时器本身的抖动。这时候速度环的带宽限制就不是分辨率，而是更新频率：每15ms才能更新一次速度值，速度环带宽最多做到几十赫兹。

这两种情况对比下来你会发现，M法适合高速高带宽，T法适合低速高精度，这就是为什么实际伺服驱动器普遍采用M/T法进行全范围测量，算法层面看是软件，但依赖的却是硬件的捕获能力。所以"硬件测量vs软件微分"这个命题，真正的分界线不是"用不用硬件"，而是"测量机制是否与脉冲到达时刻同步"。

5. 选型实战：三个真实场景的取舍案例

5.1 低速高精度转台：T法是唯一解

有个转台项目，要求转速范围0.1到60RPM，速度精度要求在0.01RPM以内。编码器用了17位绝对值编码器，131072线，分辨率本身完全够。如果用软件微分，在0.1RPM时每秒只转动大约13个计数，采样周期1ms时大部分周期的微分结果是0，速度反馈会周期性跳变，系统根本无法稳定运行。

这个场景下只有T法可行。每相邻两个编码器计数之间的时间间隔，在0.1RPM时大约74ms，用100MHz定时器去测，时间戳分辨率为10ns，换算成速度分辨率远高于0.001RPM。实际测试中，速度波动曲线非常干净，PI控制器的积分项也不会因为反馈跳变而产生周期性的过冲。这个案例的教训是：低速项目的速度反馈方案，几乎可以直接根据"每秒脉冲数"来判断该不该用T法。

5.2 高速伺服主轴：M法配合硬件捕获

另一个场景是高速主轴，额定转速12000RPM，编码器2500线，4倍频后1万计数/转，每秒脉冲频率200kHz。这个频率下定时器捕获中断每5微秒触发一次，普通MCU根本处理不过来，T法直接出局。

我用的是M法：固定1ms的测量窗口，统计窗口内收到的脉冲数。1万计数/转乘以12000RPM除以60，每个窗口大约是200个计数，分辨率是0.5%额定转速，也就是60RPM。对高速主轴来说这个分辨率够用，速度环PI参数也按这个分辨率来整定，系统稳定运行没有问题。如果还想提高分辨率，可以把编码器换成5000线的，或者把测量窗口从1ms加到2ms，但代价是更新率下降，速度环带宽要相应降低。

5.3 多轴机器人：FPGA方案的综合账

多轴机器人关节通常要求在宽速度范围内都有良好表现，而且六个轴同时工作，中断压力很大。如果每个轴的测速都靠MCU中断，CPU光是处理捕获中断就占掉了30%以上，留给轨迹插补的时间被严重挤压。

这个场景最终选择了FPGA：六路编码器解码、计数、测周全部在FPGA内部完成，固定1ms刷新一次速度值到双口RAM，CPU这边只做一个内存读取。整个方案额外增加的成本只有一颗低端FPGA，但换来的是CPU负载大幅下降、各轴速度测量完全同步、还能顺便实现硬件限位保护逻辑。从项目整体成本看，这样的投入是划算的。

6. 几个容易让人反复踩坑的细节

6.1 4倍频解码必须在测速之前做

编码器输出的A、B两路正交信号，通过边沿检测可以识别出4种状态变化，计数分辨率提升4倍。这个操作既影响位置精度也影响测速精度，必须在测速逻辑之前完成。如果你只是对单路脉冲计数，没有做正交解码，那么在死点附近抖动时计数器会来回跳动，速度值会出现正负交替的假信号。做正交解码之后，抖动只会导致计数在相邻值之间来回微调，速度反馈虽然仍然有噪声，但至少不会出现方向翻转的剧烈误差。

6.2 速度环里的滤波要卡着带宽来选

无论哪种测速方案，输出速度值之后几乎都要加滤波，但滤波器的截止频率必须根据速度环带宽来定。一个常见的错误是把滤波截止频率设得很低来追求好看的波形，结果速度环带宽被滤波器压死，系统动态性能严重下降。比较合理的做法是：先确定目标速度环带宽，以此为依据设定滤波截止频率，通常是带宽的5到10倍，这样滤波对相位裕度的影响可以被PI参数吸收掉一部分。

6.3 单位与量纲的一致性

测速方案的实现细节里，单位换算的错误率非常高。有人在代码里直接比较"每秒脉冲数"和给定值，忘了乘或除4倍频系数；也有人在把定时器时间戳转换为速度时，把定时器时钟频率算错了，导致所有速度值整体偏移一个数量级。我习惯的做法是所有变量统一使用内部单位，完全避免了"定时器时钟产品差异"这类配置上的意外。位置用计数个数，时间用定时器计数个数，速度就表示为"计数/定时器计数"，只在最外层转换为用户需要的RPM或者rad/s。

6.4 方向判别与零速附近的处理

有些测速实现会在电机启动的瞬间出现速度极性跳变，原因是零速附近的位置噪声导致方向误判。解决办法是在编码器解码层做数字滤波：只有连续采集到一定数量的同向边沿变化，才更新实际计数方向。这个细节看似微小，但对速度环在零速附近的稳定性影响很大。特别是在有负载扰动的情况下，方向误判会导致PI输出符号错误，系统出现"僵持-弹开"的抖动。

7. 最后再分享一点个人的体会

我做了这么多编码器测速的案子，最大的感受是：不要一上来就选方案，先拿计算器算清楚你要覆盖的转速范围、需要的分辨率、允许的延迟，然后再反过来看哪种方法能同时满足这三个约束。如果低速分辨率不够，无脑堆滤波器只会让系统变钝；如果高速中断压力大，别硬扛，换个测速原理比优化中断服务程序高效得多。

在实际项目中，我最后常常会做一个"混合型"方案：低速时用T法，高速时自动切到M法，切换点设定在两个方法误差相差不大的转速附近。这种方案实现起来并不复杂，关键是"软件架构上预留测速策略的可替换接口"。硬件测量和软件微分不是单选题，真正的高手是让两套机制在各自的优势区间轮流上场。