从脉冲到转速：浮点运算如何让电机“呼吸”更顺畅
你有没有遇到过这样的场景？一台伺服电机在低速运行时，明明指令平稳，输出却像卡顿的视频一样“一顿一顿”的。排查半天硬件、电源、编码器接线，最后发现——问题竟出在一行看似无害的整数除法上。
这正是我们在开发永磁同步电机（PMSM）控制系统时常踩的坑：用整数算转速，看着省资源，实则埋下了控制抖动、响应迟滞的隐患。今天，我们就以一个真实的工程案例为切口，深入聊聊单精度浮点数转换是如何在电机转速反馈中“力挽狂澜”的。
为什么整数算不好转速？
先别急着上浮点，我们得明白——痛点在哪。
假设你用的是1024 PPR的增量式编码器，控制器每1ms采样一次。理想情况下，电机转一圈要产生1024个脉冲。但在低速区呢？比如电机每秒只转半圈，那每毫秒平均只有0.5个脉冲。这意味着什么？
现实是残酷的：脉冲是离散的，你不可能读到“0.5个脉冲”。
于是，在连续几个采样周期里，pulse_count可能是0, 1, 0, 1, 0……这种跳跃直接导致计算出的转速在0 rpm和某个正值之间来回跳变——这就是典型的量化非线性。
传统做法是拉长采样周期或改用T法测速，但这又会牺牲动态响应。更糟的是，当你把这些跳变的整数转速丢进PID控制器，轻则输出震荡，重则系统发散。
出路在哪？提升分辨率。而最自然的方式，就是换赛道——从整数域，跨入浮点域。
单精度浮点：不只是“带小数点”的数字
说到浮点，很多人第一反应是“耗性能”“占内存”。但如果你还在用 Cortex-M3 或更早的平台这么想，那没问题；可如今主流的Cortex-M4F、M7 都集成了硬件FPU，浮点加减乘除基本能做到单周期完成。
这时候，float不再是负担，而是精度与效率的平衡点。
IEEE 754 单精度浮点用32位表示一个实数：
- 1位符号
- 8位指数（偏移127）
- 23位尾数（隐含前导1）
它的表达能力有多强？
可以表示从 ±1.18×10⁻³⁸ 到 ±3.4×10³⁸ 的数值，有效十进制位约6~7位——这对转速反馈绰绰有余。哪怕电机从1 rpm爬到10万rpm，全程无需担心溢出或下溢。
更重要的是，它能让微小变化“被看见”。
回到前面的例子：当pulse_count = 1，时间差timer_ticks = 1000（即1ms），PPR=1024，定时器频率1MHz：
// 整数算法（陷阱！） rpm = (1 * 60 * 1000000) / (1024 * 1000); // ≈ 58 rpm // 下一周期 pulse_count=0 → rpm=0 // 转速在0和58之间跳变，误差高达100%而换成浮点：
float delta_pos = 1.0f / 1024.0f; // ≈ 0.000976 圈 float delta_t = 0.001f; // 1ms float speed_rps = delta_pos / delta_t; // ≈ 0.976 rps → 58.59 rpm虽然结果看起来差不多，但关键在于：这个值是可以连续变化的。当实际转速缓慢上升，delta_pos可以是 0.000976、0.001953、0.002930……对应的转速也会平滑过渡，不再跳跃。
这才是闭环控制真正需要的“真实感”。
浮点不是终点，滤波才是艺术
有了高分辨率的原始转速，是不是就能直接喂给控制器了？别急，现实世界还有噪声。
机械振动、电磁干扰、编码器信号边沿抖动，都会让pulse_count出现异常跳变。哪怕只是多计了一个脉冲，瞬时转速可能飙升几百rpm——这对PI控制器来说，简直是“误判敌情”。
所以，滤波是必须的。但滤波也是一把双刃剑：滤得太狠，延迟大，响应慢；滤得太轻，噪声穿透过，系统抖。
我们常用的一阶低通滤波器，结构简单却极为实用：
$$
y[n] = \alpha \cdot x[n] + (1 - \alpha) \cdot y[n-1]
$$
其中 $\alpha$ 控制“记忆长短”：
- $\alpha = 1$：完全不过滤，输出等于输入
- $\alpha = 0.1$：输出主要依赖历史值，抗噪强但滞后明显
在实际调试中，我们会根据控制带宽选择初始值。例如对于响应要求较高的伺服系统，$\alpha$ 设为 0.2～0.3 比较合适。
代码实现也极其简洁：
static float filtered_speed = 0.0f; #define FILTER_ALPHA 0.2f float smooth_speed(float raw) { if (!isfinite(raw)) return filtered_speed; // 防NaN/Inf传播 filtered_speed = FILTER_ALPHA * raw + (1.0f - FILTER_ALPHA) * filtered_speed; return filtered_speed; }注意这里加了个isfinite()检查。这是嵌入式开发的老经验：任何外部输入都可能是坏的。一旦出现Inf或NaN，不拦截就会污染整个控制链路，甚至烧MOS。
完整链路实战：从编码器到FOC
在一个典型的 FOC（磁场定向控制）系统中，转速反馈链路如下：
编码器 → 定时器编码模式 → 脉冲差分 → 浮点转速计算 → 数字滤波 → 速度环PI → 扭矩指令 → FOC电流环 → PWM整个流程中，所有中间变量统一使用float类型传递，形成所谓的“浮点控制域”。
这意味着什么？
- 不再需要Q格式缩放：以前调PID参数，你得知道“这个Kp其实是放大了2^10倍”，现在可以直接用物理单位（如 rpm/V）理解；
- 算法复用性强：同一套滤波、观测器、前馈逻辑，可以直接迁移到不同型号电机，只需改几个参数；
- 调试直观：通过串口打印
speed_rpm，看到的就是真实转速，不用再手动换算。
而且，得益于现代MCU的FPU支持，这段计算开销极低。以STM32H7为例，上述浮点运算+滤波总共耗时不足10μs，完全可在1ms中断内轻松完成。
性能与安全：浮点使用的边界感
当然，自由是有代价的。即便有FPU，我们也得保持清醒：
✅ 推荐做法：
- 所有传感器输入（位置、电流、电压）尽早转为物理量
float - 控制算法内部全程使用浮点
- 输出PWM前再转回定点（若驱动接口要求）
❌ 避免行为：
- 高频中断中频繁调用
sqrt()、sin()等复杂函数（即使有FPU也慢） - 在栈上定义大型
float[]数组（易导致栈溢出） - 忽视
NaN和Inf的检测
另外，如果你用的是没有FPU的MCU（如某些Cortex-M0+），也不要绝望。GCC 提供软浮点库，配合-ffast-math编译优化，也能实现可接受的性能，只是实时性需严格评估。
写在最后：从“能转”到“转得好”
很多工程师初期只关心“电机能不能转起来”，但真正的挑战在于：“它能不能平稳地、精确地、安静地转起来”。
单精度浮点数转换，表面看是个数据类型的选择，实则是控制系统思维方式的升级。
它让我们摆脱了“怕溢出”“怕截断”的焦虑，把精力集中在更重要的事情上：
- 如何设计更好的观测器？
- 如何引入前馈提升响应？
- 如何实现多电机协同同步？
当你的系统开始用float表达世界，你会发现，控制不再是“凑合可用”，而是可以被精细雕琢的艺术。
未来，随着AI控制、自适应算法在电机领域的渗透，浮点运算将不再是“可选项”，而是必备基础设施。无论是无人机飞控的姿态解算，还是电动汽车电驱的能量优化，背后都离不开这一粒粒“带着指数的小数”。
所以，下次当你面对转速抖动束手无策时，不妨回头看看那行整数除法——也许，换个f后缀，世界就平滑了。
如果你在项目中遇到类似问题，欢迎留言交流。你是继续坚守定点，还是已经全面拥抱浮点？
