做电机控制这几年测速永远是绕不开的一环。不管是做小车底盘、云台稳像还是搞工业驱动器只要涉及闭环速度反馈的精度就直接决定系统能跑多好。网上讲编码器测速的资料很多但多半只扔个原理图和公式真正能把“定时器编码器模式怎么配”“M法T法到底怎么选”“代码写出来为什么转起来数值乱跳”讲透的少之又少。这篇文章我打算用一套完整的实战流程把STM32配合增量式编码器实现电机精准测速这件事从头到尾拆一遍。内容覆盖硬件接线、定时器配置、核心代码、测速算法选型、滤波处理以及我这些年实际调试中踩过的坑。无论你是刚入手STM32的新手还是已经在做电机控制想优化速度反馈的开发者这都能直接参考。代码部分我会给出完整实现照着抄基本能跑。先说清楚一个观念测速不是单纯数脉冲而是“数对脉冲”加上“算对时间”这两件事都做到位速度才真正测得准。1. 编码器测速的基本原理与方案选型1.1 编码器本质把机械转动变成电脉冲增量式编码器是电机测速最常用的传感器内部有一个码盘码盘上均匀分布着栅格。电机一转码盘跟着转光耦或者霍尔元件就会输出脉冲信号。每转一个栅格输出一个脉冲脉冲的频率就跟转速成正比。这是最朴素的测速思路。但实际使用的增量式编码器几乎都是双通道输出也就是A相和B相两路信号相位差90度。为什么要两路因为单路只能测转速测不了方向。有了A、B两相的相位关系A相在前说明正转B相在前说明反转这样方向也一并解决了。有些编码器还有Z相零位脉冲一圈只出一个用于定位原点测速一般用不上。回到标题里提到的EC11编码器本质就是一种手动旋转的增量式编码器常用于音响音量旋钮、单片机菜单旋钮也常被拿来做低速测速演示。EC11转一下发几个脉冲取决于码盘栅格数量和后端是否做了倍频处理。常见的EC11标称20脉冲每圈但如果用STM32定时器编码器模式采集计数分辨率能翻到80每圈这个后面细说。1.2 测速为什么不能只靠外部中断数脉冲很多新手最常犯的错是用外部中断去数脉冲每次脉冲上升沿触发一次中断在中断里累加计数变量再用定时器固定周期去读取这个变量换算速度。听起来简单但问题很大。电机转速高一点比如1000转每分钟配上200线的编码器每秒产生的脉冲数就是1000/60*200约等于3333个。再考虑倍频可以到13000多个每秒也就是每微秒十几个脉冲。外部中断本身有响应延迟GPIO翻转扫描也有延迟再加上中断服务函数里还有压栈和出栈的开销一旦中断频率过高CPU就被中断占满主循环基本跑不动更别说还要做PID运算。这就是为什么STM32要专门做编码器模式。定时器的编码器接口模式能够利用硬件电路自动根据A、B两相的电平状态组合在一个计数方向上进行加减计数整个过程不需要CPU参与。相当于硬件帮你把脉冲数好了你只需要定时去“查一下账本”就行。这才是测速高效稳定的基础。1.3 主流测速算法M法、T法、M/T法怎么选编码器把转速变成了脉冲序列接下来要解决的就是怎么把脉冲数与时间结合算出一个真实的转速值。行业内主流有三种算法。M法也叫测频法原理是在固定时间窗口内统计脉冲个数用脉冲数除以时间再除以每转脉冲数就得到转速。适合转速较高、单位时间内脉冲数较多的场景因为脉冲数多量化误差占比就小。比如你每1ms查询一次计数转速高时一个周期内能数几百个脉冲误差不明显。但要是低速转动比如几转每秒1ms内可能就一个脉冲甚至没有算出来的速度要么是零要么跳来跳去。T法也叫测周法原理是测量单个脉冲的时间宽度。用定时器的输入捕获功能记录相邻两个脉冲的时间然后用1除以这个时间间隔算出频率。这种方法在低速时特别准因为低速时脉冲间隔长计时分辨率高。但高速时脉冲间隔变短时间测量误差和定时器溢出问题就开始凸显。M/T法就是结合两者既统计脉冲个数又测量最后不完整脉冲的时间间隔理论上全速域都准但实现复杂对硬件和代码要求都高。实际项目里如果转速范围宽、要求高才会用M/T法。做小车、做普通电机调速M法配一个合适的时间窗口再加一个低速判定处理基本够用。这篇文章后续的完整代码里我用的就是M法为主、低速时叠加多周期平均的处理策略实测效果稳定代码复杂度也适中适合绝大多数项目直接用。2. 硬件选型、接线与STM32定时器规划2.1 编码器怎么选从EC11到工业光电编码器做实验或者做样机最常见的编码器就是两类一类是像EC11这样的机械旋转编码器便宜几块钱一个但手感有段落感、存在机械抖动转速测量精度有限适合低速和位置演示另一类是光电增量编码器比如常见的200线、400线、600线、1000线码盘刻线更多输出波形更干净转起来阻力小适合真实电机测速。如果你用的是带减速箱的直流减速电机很多模组本身就带霍尔编码器比如常见的GA12-N20电机减速比从1:30到1:150都有尾部带一个霍尔磁环和两个霍尔传感器输出A、B两相脉冲。这种电机在智能小车项目里非常常见用STM32配合测速非常顺手。选型时重点看一个参数每转脉冲数PPR。这个数值直接决定了测速分辨率。PPR越高每个脉冲对应的角度越小测速越精细但单位时间脉冲数也越多对定时器和中断的要求更高。比如一个电机1秒转10圈配200线编码器A相输出2000个脉冲每秒如果配1000线的就是10000个每秒。STM32定时器编码器模式处理这些脉冲没有任何压力但如果你用外部中断方案就直接崩了。需要注意的是很多电机资料上标的是“编码器线数”有的甚至把A相B相各自输出的脉冲都算进去导致实际每转脉冲数和标称对不上。拿到电机或者编码器建议先手动转一圈通过串口打印计数变化确认真实脉冲数再写进代码。2.2 STM32定时器编码器模式到底是怎么工作的STM32系列单片机里大部分高级定时器和通用定时器都支持编码器接口模式。所谓编码器接口模式简单说就是把定时器的两个输入通道比如CH1和CH2配置成编码器接口让A相接CH1、B相接CH2定时器的计数器会自动根据A、B相位差进行加减计数。这个硬件逻辑相当于内置了一个方向判断器。以TIM3为例当CH1TIM3_CH1对应PA6和CH2TIM3_CH2对应PA7输入正交脉冲信号时计数器的计数方向由两路信号的相对极性自动决定。正转时计数器加反转时计数器减。你完全不需要在中断里去判断电平组合再手动加减变量硬件全都处理了。更关键的是计数分辨率。编码器模式支持1倍频、2倍频、4倍频三种计数方式。什么是倍频就是一个完整的A、B脉冲周期内如果只在A相上升沿计数那一个周期只计1个数这是1倍频如果在A相上升沿和下降沿都计数一个周期计2个数这是2倍频如果在A相和B相的上升沿、下降沿都计数一个周期计4个数这就是4倍频。4倍频处理后20线的EC11变成80线分辨率200线编码器变成800线低速测速精度直接翻四倍。注意在4倍频模式下定时器计数器的最大计数值也相应更快达到如果用16位定时器在极高转速下可能出现溢出这就是后文要讲的处理重点。但绝大多数电机应用场景4倍频配合32位计数模式或者及时读取完全够用。2.3 硬件接线要点与常用端口规划我用的是STM32F103系列CubeMX配置时TIM2、TIM3、TIM4、TIM5这四个定时器都支持编码器模式。实际项目中我一般用TIM3做左电机测速TIM4做右电机测速因为这两个定时器的输入引脚PA6/PA7和PB6/PB7比较方便布线也不跟I2C、USART的主流引脚冲突。接线原则很简单编码器A相输出接定时器输入通道CH1B相输出接CH2。注意编码器是开漏输出还是推挽输出。如果是开漏输出必须接上拉电阻否则信号电平不利于稳定判断。很多EC11模块板载了上拉电阻但裸的旋转编码器不一定有最好用万用表确认一下。供电方面大部分5V供电的编码器模块信号输出高电平是5V。STM32的GPIO耐压虽然在多数情况下能接受但更稳妥的做法是通过分压电阻或者电平转换模块把5V信号降到3.3V。如果你直接把5V信号怼进STM32引脚短时间问题不大长期或者出现浪涌时容易把引脚搞坏。这一点我在初期做实验时吃过亏后来所有编码器信号都过电平匹配。还有一点要提醒编码器信号线尽量用屏蔽线或者双绞线特别是电机和编码器挨得近的时候电机电流变化会产生电磁干扰信号线上容易叠加毛刺。毛刺轻则造成计数抖动重则直接导致方向误判。如果项目空间允许驱动电机线和编码器信号线分开走别绑在一起。2.4 用CubeMX创建工程的基础配置现在新建一个STM32F103C8T6的工程时钟配置到72MHz这个大家应该很熟练了。时钟配好后进入定时器配置界面。我以TIM3为例在Mode选项卡里把Combined Channels设置成Encoder Mode这样TIM3_CH1和TIM3_CH2自动配置为编码器接口输入。配置界面里能看到Encoder Mode的参数选项可以选择Encoder Mode TI1、Encoder Mode TI2、Encoder Mode TI1 and TI2分别对应1倍频、2倍频、4倍频。我们要精准测速直接选TI1 and TI2。Counter Period也就是自动重装载值ARR默认是65535先保持。如果要提高计数上限有的STM32型号支持32位计数模式把Counter Period设成0xFFFFFFFF即可。但要注意CubeMX里对于16位定时器如果你输入一个超过65535的值软件会报错不会自动切到32位模式。这点需要根据你用的具体型号灵活处理。编码器模式配置好后还有一个很重要的事把定时器的中断打开在NVIC Settings里勾选TIM3 global interrupt。这里的定时器中断不是用来数脉冲的而是用来做周期性的速度采样。我习惯配置一个1ms的更新中断每次进中断就读取当前计数器值并清零同时处理速度计算和滤波。这样做read_speed的周期非常稳定计算出来的速度值时间基准统一。串口也要配置一个波特率115200用于打印速度测试数据。配置完成后生成代码进入Keil或者STM32CubeIDE里写逻辑。3. 核心代码实现完整测速代码与注释3.1 计数读取与周期采样的程序框架先说明一下我的程序设计思路定时器编码器模式负责自动计数1ms定时器中断负责“截个图”——读取当前计数器值、清零计数器、保存到全局变量。主循环或者PID周期里再拿这个保存值和采样周期做速度换算。这样做的优势是速度采样周期非常精准不卡在主循环里受其他任务影响。而且计数器清零在定时器中断里完成能够保证每个采样周期内累计的都是这1ms新增的脉冲数不会重复计算也不会漏计。代码层面需要三个核心部分编码器模式初始化、1ms中断回调、速度换算函数。初始化部分CubeMX已经生成好了你只需要在中断回调里加上读取和清零逻辑再自己写一个速度换算的函数就行。3.2 完整代码实现可直接参考使用以下是基于STM32CubeMX生成的工程修改后的核心代码。我尽量把注释写清楚方便直接对照你的工程进行移植。/* 定义两个电机的计数器全局变量 */ volatile int16_t encoder_left_count 0; volatile int16_t encoder_right_count 0; /* 定义电机的物理参数根据实际电机修改 */ #define MOTOR_PPR 200 // 编码器每转脉冲数注意是否已倍频 #define ENCODER_MULTIPLIER 4 // 定时器编码器模式倍频数TI1 and TI2 为4倍频 #define WHEEL_DIAMETER_MM 65.0f // 车轮直径单位mm #define WHEEL_CIRCUM_MM (3.1415926f * WHEEL_DIAMETER_MM) /* 1ms定时器中断回调 */ void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim-Instance TIM3) { /* 读取当前计数值并立即清零 */ encoder_left_count (int16_t)__HAL_TIM_GET_COUNTER(htim3); __HAL_TIM_SET_COUNTER(htim3, 0); } else if (htim-Instance TIM4) { encoder_right_count (int16_t)__HAL_TIM_GET_COUNTER(htim4); __HAL_TIM_SET_COUNTER(htim4, 0); } } /* 根据计数差值换算电机转速单位rpm */ float Motor_Speed_Calc_RPM(int16_t count_tick, float sample_time_s) { float speed_rpm 0.0f; /* 计算每秒脉冲数 */ float pulse_per_sec (float)count_tick / sample_time_s; /* 计算每转总脉冲数 PPR * 倍频数 */ float pulse_per_round (float)MOTOR_PPR * ENCODER_MULTIPLIER; /* 换算转速单位 rpm */ speed_rpm (pulse_per_sec / pulse_per_round) * 60.0f; return speed_rpm; } /* 如果需要线速度单位 m/s */ float Motor_Speed_Calc_MS(float speed_rpm) { /* 线速度 转速(rpm) / 60 * 轮子周长(m) */ return (speed_rpm / 60.0f) * (WHEEL_CIRCUM_MM / 1000.0f); } /* 主循环中读取速度示例 */ void main_loop(void) { int16_t left_tick 0; int16_t right_tick 0; float left_speed_rpm 0.0f; float left_speed_ms 0.0f; while (1) { /* 关闭中断读取防止读取过程中计数器被更新 */ __disable_irq(); left_tick encoder_left_count; right_tick encoder_right_count; __enable_irq(); /* 换算速度和线速度 */ left_speed_rpm Motor_Speed_Calc_RPM(left_tick, 0.001f); left_speed_ms Motor_Speed_Calc_MS(left_speed_rpm); /* 通过串口打印 */ printf(Left: %d tick, %.1f rpm, %.2f m/s\r\n, left_tick, left_speed_rpm, left_speed_ms); HAL_Delay(100); } }代码里需要特别解释几个点。__HAL_TIM_GET_COUNTER和__HAL_TIM_SET_COUNTER是HAL库提供的计数器读取和设置宏操作的是定时器实例的CNT寄存器效率很高。读取后立刻清零目的是让下一个采样周期从零开始累计。很多初学者忘了清零结果速度越算越快就是这个原因。为什么用int16_t而不是uint16_t来存计数因为编码器模式计数是可正可负的反转时计数器减如果读到的值被解释成无符号数负方向的速度就会变成巨大的正值。用int16_t匹配16位定时器的正负范围正反转都能正确判断。对于速度换算sample_time_s传入0.001f也就是1毫秒这是根据定时器中断周期来的。如果你的采样周期改成10ms这里就传0.01f。采样周期越长低速时计数越多速度量化越细腻但速度更新的延迟也越大。实际调PID时需要在实时性和准确性之间找平衡这个后面会在算法部分详细说。还有一点要提醒如果你把定时器配置成32位计数模式那么读取返回的变量类型要改成int32_t否则高位数据会被截断。我之前踩过一次配置了32位模式但用int16_t读速度在高速时周期性跳变到错误值查了很久才发现是类型不对。3.3 为什么计数清零要放在中断里的最后面这个细节很容易被忽略。我把读取和清零放在中断回调的最后面而不是在回调开头是有讲究的。如果在回调开头就清零那么这一个中断周期内如果又进来一个脉冲计数器从0开始计这没问题。但如果读取操作本身耗时而清零之后、读取之前又来了脉冲这个脉冲会被计入下一个周期导致下一个周期多计一个脉冲。虽然单个脉冲影响不大但在高速高精度场景下每一处误差都值得认真对待。我把读取放在前面、清零放在后面的顺序能够保证本次获取的是从上一周期清零后到本周期中断前的完整计数。清零动作本身发生在本周期采样完成之后因此不会影响本次数据也不会让脉冲漏计。这种微小的顺序优化是让数据更干净的关键细节。另外读取与清零之间理论上存在竞争条件如果编码器脉冲更新恰好发生在读取和清除之间理论上会把新旧周期的脉冲混在一起。不过对于这种低频率的硬件计数更新实际发生概率极低且业界通用做法也就是这个顺序跟真正的并发系统相比这里不需要再上临界区保护。4. 测速细节与误差分析从“能转”到“测得准”4.1 倍频下的PPR参数换算别把最终分辨率算错标题热词里提到“EC11编码器转一下发几个脉冲”这是新手最容易混淆的问题。假设EC11标称20脉冲每圈如果你在CubeMX里选的是Encoder Mode TI1 and TI2那么实际计数器每圈走80个计数。这个“80”才是你在代码里真正对应的per_round数值。所以在代码里pulse_per_round不是简单的直接填20而应该是20乘以4等于80。如果把20直接填进去算出来的转速会比真实值大4倍。这一点很多人做小车测速时翻过车明明电机转速看起来不慢串口打印出来却几千转最后发现是倍频没算进去。再举一个常见的例子GA12-N20电机模组很多商家标的参数是“减速比1:30编码器13线”。这里的13线是什么意思呢通常指的是电机轴上霍尔编码器的线数也就是电机转子每转输出13个脉冲。但减速箱输出轴转一圈电机转子本身要转30圈所以输出轴每转脉冲数是13乘以30等于390个如果再做4倍频就是1560个计数每输出轴圈。你要是拿这个电机装小车算轮子线速度时per_round应该填390还是1560取决于你配的倍频模式。建议拿到电机后先用代码打印一个周期的脉冲数手动把输出轴转10圈把计数累加值除以10得到真实的每转计数再写进代码。比看参数盲猜靠谱得多。4.2 M法测速的量化误差和采样窗口设置M法测速的核心公式是n (M / (T * P)) * 60其中M是采样周期内的脉冲计数T是采样周期P是每转脉冲数。从公式可以看出脉冲计数M是整数所以速度的量化分辨率等于每采样周期1个脉冲对应的速度变化。举个例子电机每转800个计数采样周期1ms那么每秒脉冲计数最大是800000。如果转速是10转每秒1ms内产生的计数是8000个量化误差是1/8000约0.0125%相当小。但如果转速低到1转每秒1ms内只有800个计数量化误差变成1/800约0.125%仍然可以接受。如果再低到0.1转每秒1ms内只有80个计数量化误差到1.25%这时候速度反馈就会明显跳动。这种情况下最简单的办法是拉长采样周期。把采样周期从1ms改成10ms低速时的脉冲数直接增加10倍量化误差缩小10倍。代价是速度更新的实时性变差PID如果周期很短会有延迟。折中方案是低速时用T法或者把M法和滤波算法结合用多次平均来平滑跳动。具体项目中我习惯把采样周期设为5ms或者10ms配合一阶低通滤波既保证了稳态精度又没有明显滞后。如果你做的是高速电机1ms采样完全够用如果做的是低速云台建议周期适当加大。4.3 方向判断与计数值溢出处理编码器模式下计数器是一个16位有符号数范围是-32768到32767。如果电机持续一个方向转计数会不断增大直到溢出然后跳变到负值。同理反方向转会向下溢出到正值。如果在读取的瞬间恰好发生溢出速度值会出现一个巨大的尖峰直接让PID产生剧烈抖动。怎么处理最稳妥的办法是用有符号数接收计数器值同时也把溢出考虑进你的速度公式中。比如如果你在1ms采样周期内正常最多只产生几百个计数那么溢出几乎不可能发生在两次读取之间。只有在极端高速、数值接近32767边界时才需要做溢出补偿。对于大多数小车项目能用16位计数器的范围覆盖就可以忽略溢出问题。如果确实转速极高要么把定时器切到32位计数模式要么在溢出中断里维护一个累积变量把高位补回来。后一种做法稍微绕一点但很多工业代码就是这么干的。方向判断还有一个容易踩的坑A相和B相接反了计数器会在正转时递减。很多人在PID闭环里发现正反馈电机越调越猛就是因为方向反了。此时有两种解法一是把接线对调二是在初始化后把计数方向取反。STM32的TIM_EncoderInterfaceConfig有个参数可以设置计数方向也可以简单地在代码里对读数取负号。我习惯硬件上把线接对软件不加负号一是直观二是以后换引脚或者换板子不容易记错。4.4 从转速精度到轮子线速度的换算很多应用比如小车速度闭环最终控制目标不是转速而是线速度。转速到线速度的换算公式非常简单线速度等于转速除以60再乘以轮子周长。轮子周长等于直径乘以π。但这里有个隐蔽的误差源轮子直径会随着轮胎磨损、胎压变化或者负载变形而改变。橡胶轮受力后径向会有一定压缩实际滚动半径小于空载半径。直接拿卡尺量出来的直径计算可能误差有百分之几。比较可靠的做法是让小车在地面跑一段已知距离用编码器累计计数反推实际滚动半径。这个标定方法比任何理论计算都准。我在自己的小车上试过空载直径65mm的轮子实际标定出来等效直径可能只有63mm左右误差约3%。在开环演示时问题不大但闭环速度一上去这个误差就会表现为走直线的偏移或者距离控制不准。5. 数据滤波与稳定性优化速度反馈不抖才算入门5.1 为什么测出来的速度会跳变先做一个实验把电机稳定运行在某个固定转速串口打印出来的速度值不是一条直线而是在一个范围内抖动。这个抖动有几个来源。第一个来源是量化误差前文说过的M法整数脉冲计数导致的速度分辨率限制。第二个来源是机械因素齿轮箱的齿槽效应、电机的换相脉动会让瞬时转速本身就有波动。第三个来源是电磁干扰如果信号线屏蔽不好毛刺会直接造成额外计数。第四个来源说起来很尴尬但也常见是计数溢出速度偶尔出现一个巨大的尖峰。对于大多数闭环控制速度反馈有轻微的抖动是可以接受的PID本身能够通过积分项吸收掉。但抖动过大会激发系统的振荡噪声电机就会发出高频啸叫这在舵机或者精密平台上尤其明显。所以我们需要在软件里对上一步的输出做适当的平滑处理。5.2 滑动平均滤波与一阶低通滤波对比常用的速度平滑方法有两类滑动平均滤波和一阶低通滤波。滑动平均滤波就是从最近N个采样周期的速度值里取平均。比如每10ms采样一次取最近10次速度求平均等效于100ms窗口内的平均速度。优点是逻辑简单、对周期性的噪声抑制效果好缺点是会引入固定的延迟窗口越大延迟越大而且响应突变时存在明显的“拖尾”。一阶低通滤波公式是current_filtered alpha * current_raw (1 - alpha) * last_filtered。alpha越小滤波越强平滑越明显延迟也越大。它的优势在于计算量小只需要一个全局变量保存上一次结果而且参数alpha调整起来很直观一个数从0.01到0.5之间调节就能覆盖从“非常平滑”到“几乎不滤波”的区间。我实际项目的经验是滑动平均滤波在最终速度显示和人机交互上表现更好数字稳定不跳变一阶低通滤波在PID闭环控制中表现更好因为延迟特性更平滑不容易跟PID的高频响应打架。如果你做的是速度闭环建议用一阶低通alpha先取0.2左右然后根据实际响应微调。5.3 一种实用的“自适应死区多重滤波”组合策略在调速要求比较高的场景单纯用一阶低通也可能不够。我常用的一种组合策略是先做一次突变值剔除再做滑动平均最后再叠加一阶低通。步骤看起来多但代码量不大效果却很好。突变值剔除的原理是如果当前原始速度与上一次滤波结果的差值超过某个阈值就认为这一帧数据是干扰或者溢出导致的异常值直接用上一次滤波结果替代。阈值怎么设可以按电机最大加速度来估算比如电机从静止到最大速度需要0.5秒最大速度是1000rpm那么一个10ms采样周期内理论上速度变化不会超过20rpm。把阈值设在50rpm左右既能拦截异常的溢出尖峰又不会阻碍真实的加速响应。滑动平均负责把周期性的机械波动抹平一阶低通负责吸收随机噪声。三级处理下来速度反馈曲线基本是一条平滑的线PID的微分项也不会因为噪声被放大。当然这套组合带来的延迟也更大实际项目里要根据你的控制周期和机械响应特性做取舍。如果是高速高动态响应的场景比如穿越机电机这类重滤波就不适用了。好在做编码器测速的电机系统绝大多数都不是超高速场景。5.4 低通滤波参数选择的实操心得关于alpha怎么调给一个新手可以直接上手的经验值采样周期10ms时alpha取0.2采样周期5ms时alpha取0.1采样周期1ms时alpha取0.02。你会发现一个规律采样周期越短alpha就得越小不然滤波作用不明显。这两个参数本质上是对应时间常数的。一阶低通的时间常数近似等于采样周期乘以(1-alpha)/alpha。比如采样周期10msalpha0.2时间常数大约40ms。如果想要时间常数稳定在40ms左右采样周期改成1msalpha应该约等于0.024。所以alpha不是随便拍的它是跟采样周期挂钩的。如果你想更直观地调参可以这样操作先让电机跑一个阶跃速度指令观察速度反馈曲线的上升过程。如果上升太慢、跟不上指令说明时间常数太大alpha要增大如果曲线毛刺明显、噪声大说明alpha要减小。这个观察法比套公式好理解得多实际调试时也更高效。6. 常见问题与排查技巧实录6.1 计数器读数一直为零A、B相没计数这个现象多半是接线或者引脚配置的问题。先检查A、B相是否接在了定时器对应的CH1和CH2通道注意不同定时器的输入通道有固定的引脚映射比如TIM3_CH1是PA6TIM3_CH2是PA7接反或者接到别的引脚上除非做了重映射否则是不会工作的。其次检查编码器供电。很多编码器模块需要5V供电如果只接了信号线没接电源自然不会有输出。用示波器或者万用表量一下A相对GND的电压手动转动电机看电压有没有在高低电平之间跳变就能很快定位是不是编码器本身没输出。还有一种常见情况你用的是开漏输出的编码器忘了加上拉电阻导致信号线一直被下拉到低电平计数器永远不变化。这个需要对照模块的原理图确认。6.2 正转时计数增加反转时计数也增加这个问题非常经典。定时器编码器模式自带方向判断功能如果正反转计数方向相同说明A、B两相的相位关系不对。多数情况是A相接到了CH2、B相接到了CH1因为编码器模式是根据两路输入组合判断的交换后方向逻辑被反转。更隐蔽的情况是你没有在CubeMX里把两个通道都配置成编码器输入而只是单独开启了两个通道的输入捕获。这样定时器不会工作在与编码器模式相关的组合逻辑下计数方向自然就不对了。记得在CubeMX里选择Encoder Mode而不是把两个通道分别配成Input Capture。如果确认配置正确但方向仍然相反可以简单地在代码里把读取到的计数取负处理。虽然治标不治本但如果你线路已经固定不好改这也是实用方案。6.3 速度数值异常大超出物理极限出现这种问题先检查代码中pulse_per_round这个参数。如果填的不是每转总计数而是只用标称PPR没算倍频数值就会偏大几倍。我之前接手一个项目别人代码里PPR填的200但实际上他CubeMX配置的是4倍频对应每转800个计数打印出来的转速直接是真实值的4倍。还有一种可能电机本身带有减速箱编码器装在电机转子端而不是输出端。你算输出轴转速时必须把减速比考虑进去。比如前面说的GA12-N20减速比1:30如果编码器的脉冲数是按电机转子端算的那么输出轴每转需要30乘以转子的脉冲数才是真正的per_round值。不然算出来的“转速”其实是电机转子的转速比输出轴大了30倍。6.4 静止时速度不为零甚至在缓慢漂移这种现象叫做“零漂”。原因有几个一是编码器信号抖动二是电磁干扰导致毛刺被计数三是机械振动导致码盘微动。如果静止时速度值小范围波动比如正负几rpm可以先加个死区阈值当速度绝对值小于某个值时直接置零。这种方法简单粗暴适用于大多数对低速精度要求不高的场景。如果漂移数值较大就要检查信号线屏蔽和接地看看电机驱动和编码器是否共地有没有将功率地和信号地严格分开。还有一种情况EC11这类机械编码器因为内部有机械触点在手动旋转松开后触点可能振动几下产生几个额外的脉冲。如果是用EC11输入到STM32测速建议在机械结构上装一个稳压装置或者干脆换用光电编码器。6.5 高速时计数突然丢步速度周期性跳变如果低速匀速测试正常高速时出现计数丢步或者数值乱跳优先怀疑计数器溢出。16位计数器最大值327674倍频后高速电机很容易在一次采样周期内累计到接近这个值一旦溢出符号位翻转读数就会从正跳变到负表现为速度瞬间反向。处理的方法把定时器切到32位计数模式或者缩短采样周期。如果你用的STM32型号只支持16位定时器还可以在溢出中断里维护一个高位计数变量把多个计数周期拼接成32位。这个方法虽然麻烦一点但逻辑不复杂网上有现成的代码参考。另外注意读取时要把高位和低位放在同一个临界区内否则可能读到高低位不匹配的错乱数据。6.6 完整测速系统联调时的排查顺序最后分享一个联调时的排查顺序这条路径帮我省了非常多时间。先确认编码器供电和信号输出正常用示波器或者逻辑分析仪看A、B相波形再确认STM32引脚配置正确用CubeMX生成代码后直接用串口打印原始计数值不经过滤波不换算速度手动转动电机看计数值是否随转速变化然后确认方向逻辑正确正转计数增加、反转计数减少再确认倍频和每转脉冲数参数让数值在一个合理的物理范围内最后才加滤波和闭环控制。千万不要一上来就接PID调试如果速度反馈本身是错的后面全是白调。按这条路径走到最后绝大多数问题都能准确定位到某一层。7. 写在最后的几个经验做了这么多年电机控制我最深的体会是测速这件事硬件决定上限软件决定能否接近上限。编码器选型、接线质量、供电稳定这些硬件问题不解决代码写得再花哨也没用。反过来如果硬件已经固定了采样策略、滤波参数、溢出处理这些软件细节就是你能发挥的空间。EC11这种编码器配合STM32的编码器模式做低速演示是我目前见过最便宜、最基础、最适合入门的组合。但如果你要真正做电机测速建议尽早换用带霍尔编码器的减速电机或者光电编码器机械抖动小输出波形干净调试起来省心十倍。做电机控制稳定的速度反馈是控制品质的地基。地基打得稳后面的PID怎么调都顺地基松后面每一步都在为噪声和误差买单。这套代码和调试方法我已经在多个STM32项目里反复用过从简单的两轮小车到云台控制稍作参数调整都能跑。你拿到代码跑起来之后如果遇到问题欢迎对照上面的排查逻辑一步步试尤其是每转脉冲数、倍频、采样周期这三个参数只要这三个对齐了测速系统基本就稳了一大半。