ODrive 8kHz控制环：时基链路与FOC计算全解析

1. 为什么 8 kHz 是 ODrive 控制环的“心跳”很多人第一次翻 ODrive 固件源码看到TIM_1的初始化代码时都会愣一下为什么偏偏是 8 kHz为什么不是 10 kHz、20 kHz 这种看起来更“整”的数字我当初也是带着这个疑问一路从main.c追到tim.c再追到axis.cpp里的run_control_loop才把这条链路彻底理顺。先说结论8 kHz 不是随便拍的它是“电流环带宽需求”和“MCU 算力预算”之间反复权衡后的产物。ODrive 用的是 STM32F405主频 168 MHz带 FPU。FOC 电流环要在一个 PWM 周期内完成采样两相电流、Clarke 变换、Park 变换、两个 PI 调节器、反 Park 变换、SVPWM 占空比计算、更新 CCR 寄存器。这一套下来在 168 MHz 的 M4 上大概需要 8~12 微秒。如果控制频率定在 8 kHz周期是 125 微秒CPU 占用率大约 8%~10%留足了余量给 USB 通信、编码器解码、位置环和上位机协议解析。如果硬拉到 20 kHz周期只剩 50 微秒光电流环就吃掉 20% 以上的 CPU再加上编码器中断和 USB 中断很容易出现控制抖动甚至丢步。另一个关键因素是电流采样窗口。ODrive 用的是低侧分流电阻加运放方案采样必须发生在 PWM 下桥臂导通的特定时刻。8 kHz 对应 125 微秒周期配合中心对齐 PWM 模式采样窗口可以放在计数器溢出点附近避开开关噪声。如果频率太高采样窗口被压缩ADC 采样保持时间不够电流波形会失真FOC 解算出来的角度和力矩都会抖。还有一点容易被忽略8 kHz 正好是很多工业伺服驱动器的兼容频率。你拿 ODrive 去替换一台老伺服驱动器时上位机发的指令频率、编码器反馈的更新率往往就在这个量级附近匹配起来最省事。所以这个数字背后是硬件、算法、生态三方面共同作用的结果不是拍脑袋定的。提示如果你打算改控制频率别只改TIM_1的预分频和重装载值还要同步检查current_sense的采样时刻配置、encoder的定时器输入捕获分频以及axis里位置环和速度环的积分限幅。牵一发动全身。2. 从系统时钟到 TIM_1时基链路是怎么搭起来的2.1 时钟树168 MHz 是怎么喂给定时器的STM32F405 的时钟树不算复杂但 ODrive 的配置有几个地方和 CubeMX 默认生成的不太一样。系统时钟源是 8 MHz 外部晶振经过 PLL 倍频到 168 MHz。APB1 总线挂在 42 MHzAPB2 挂在 84 MHz。这里有个坑当 APB 预分频系数不为 1 时定时器时钟会自动倍频。APB1 分频系数是 4所以挂在 APB1 上的定时器实际时钟是 42 MHz × 2 84 MHzAPB2 分频系数是 2挂在 APB2 上的定时器实际时钟是 84 MHz × 2 168 MHz。TIM_1 挂在 APB2 上所以它的计数时钟是168 MHz。这个数字很关键后面算预分频和重装载值都要用到。我见过有人照着 CubeMX 默认配置改代码结果定时器频率差了一倍电机转起来像得了帕金森根源就是没注意这个自动倍频机制。2.2 中心对齐模式为什么不用边沿对齐ODrive 的 TIM_1 配置成中心对齐 PWM 模式Center-Aligned Mode计数器从 0 数到 ARR 再数回 0一个完整周期产生两次比较匹配。这样做的好处有三个第一PWM 波形对称谐波集中在开关频率的偶数倍附近对电机绕组和电流采样的干扰更小。边沿对齐模式下PWM 上升沿和下降沿不对称电流纹波更大采样时刻不好选。第二采样窗口天然落在计数器溢出点。中心对齐模式下计数器到达 ARR 时有一个短暂的“平顶”区域此时下桥臂全部导通分流电阻上的电流就是母线电流采样最干净。ODrive 的current_sense就是在这个时刻触发 ADC 注入通道的。第三死区时间插入更方便。中心对齐模式下互补 PWM 的死区可以对称地加在上升沿和下降沿两侧避免上下桥臂直通。ODrive 的TIM_1配置里DeadTime设的是0x1F对应大约 500 纳秒这个值是根据 IGBT 或 MOSFET 的开关特性算出来的不是随便填的。2.3 预分频与重装载值8 kHz 的精确计算现在来算具体参数。TIM_1 时钟 168 MHz目标 PWM 频率 8 kHz。中心对齐模式下PWM 频率 定时器时钟 / (2 × ARR × (PSC1))。ODrive 的配置是PSC 0ARR 10500。代入公式168,000,000 / (2 × 10500 × 1) 8000 Hz。正好 8 kHz。为什么选 10500 而不是 10499 或 10501因为 168 MHz 除以 2 再除以 8 kHz 等于 10500整除。如果 ARR 不是整数PWM 频率会有微小偏差长期运行会导致控制环和上位机指令不同步。ODrive 在tim.c里直接写死了这个值注释里也标了“8 kHz center-aligned”。注意如果你用的是 STM32F103 这类主频 72 MHz 的芯片同样的 8 kHz 需要ARR 4500PSC 0。但 F103 没有 FPU跑 FOC 会吃力很多这也是为什么 ODrive 选 F405 的原因之一。3. 中断优先级与执行时序8 kHz 环里谁先谁后3.1 中断向量表里的“座次排位”ODrive 固件里和 8 kHz 控制环相关的中断主要有三个TIM_1 更新中断TIM1_UP_TIM10_IRQHandler、ADC 注入通道转换完成中断ADC_IRQHandler、以及编码器定时器的输入捕获中断。这三个中断的优先级配置直接决定了控制环的实时性。在freertos.c或main.c的 NVIC 配置里TIM_1 更新中断的抢占优先级设的是1ADC 中断设的是0最高编码器捕获中断设的是2。为什么这么排因为 ADC 采样必须在 PWM 周期内尽快完成晚了电流值就失效了TIM_1 更新中断负责触发控制环计算优先级次之编码器捕获中断频率最高但实时性要求相对低可以稍后处理。我实测过如果把 TIM_1 和 ADC 的优先级调换电机在低速时会出现明显的力矩波动示波器上看电流波形有周期性畸变。原因就是 ADC 采样被延迟采到的不是母线电流而是续流电流FOC 解算角度偏了。3.2 一个 125 微秒周期内的完整时序把时间轴拉出来看一个 8 kHz 周期内发生的事情是这样的T0 微秒TIM_1 计数器到达 ARR更新事件触发。硬件自动将 ADC 注入通道的触发源指向这个事件。T0.5 微秒ADC 开始采样采样保持时间约 0.5 微秒转换时间约 1 微秒。T2 微秒ADC 转换完成触发 ADC 中断。在中断里读取ADC-JDR1和JDR2得到两相电流原始值。T3 微秒TIM_1 更新中断触发如果使能了。在中断里调用axis-run_control_loop()执行 FOC 全部计算。T10 微秒FOC 计算完成新的占空比写入TIM_1-CCR1/2/3。T125 微秒下一个周期开始循环往复。实际代码里ODrive 把 ADC 中断和 TIM_1 更新中断合并处理了在ADC_IRQHandler里直接调用控制环省去了一次中断切换开销。这个优化很关键省下来的 1~2 微秒在 125 微秒周期里占比不小。3.3 中断里的“不能做的事”在 8 kHz 中断里有几件事绝对不能做浮点除法、动态内存分配、串口打印、Flash 擦写。浮点除法在 M4 上是软件模拟的一次要几十个周期动态内存分配会引入不确定延迟串口打印在中断里调用会阻塞Flash 擦写会暂停 CPU 取指。ODrive 的代码里中断服务函数只做最核心的 FOC 计算和 PWM 更新其他事情全部丢到主循环或低优先级任务里。我踩过一个坑在调试时往中断里加了一句printf看电流值结果电机直接失控。后来查明白printf底层调用了HAL_UART_Transmit里面有超时等待把 125 微秒的周期撑爆了。正确做法是用DAC或GPIO翻转配合示波器看波形或者用SEGGER RTT这种非阻塞调试手段。4. 控制环里的 FOC 计算8 kHz 内要跑完哪些步骤4.1 电流采样与 Clarke 变换ADC 读回来的是两个原始值对应 A 相和 B 相的下桥臂分流电阻电压。首先要做零漂校准在电机未通电时采一批样本取平均作为零点偏移。ODrive 在current_sense.cpp里有个calibrate()函数上电时自动执行把偏移量存到全局变量里。然后做 Clarke 变换I_alpha I_aI_beta (I_a 2*I_b) / sqrt(3)。这里有个细节ODrive 用的是等幅值变换而不是等功率变换系数是2/3而不是sqrt(2/3)。等幅值变换的好处是电流幅值和实际相电流一致方便做限幅和保护。代价是功率计算时要多乘一个系数但 ODrive 里功率不是控制环的核心所以这个取舍是合理的。4.2 Park 变换与角度来源Park 变换需要电角度。ODrive 的电角度来自编码器electrical_angle encoder_angle * pole_pairs phase_offset。编码器角度是机械角度乘以极对数得到电角度再加上校准得到的相位偏移。这个相位偏移在encoder_offset_calibration里测出来存到配置里。Park 变换公式I_d I_alpha * cos(theta) I_beta * sin(theta)I_q -I_alpha * sin(theta) I_beta * cos(theta)。ODrive 用arm_sin_cos_f32查表算三角函数比标准sinf/cosf快很多。实测下来查表法一次只要 20 个周期左右标准库函数要 100 多个周期。4.3 两个 PI 调节器与解耦I_d和I_q分别进入两个 PI 调节器。I_d的目标值通常是 0表贴式电机I_q的目标值来自速度环或位置环的输出。PI 调节器的输出是V_d和V_q。这里有个容易被忽略的点反电动势解耦。电机旋转时q轴电流会产生反电动势耦合到d轴d轴电流也会耦合到q轴。如果不做解耦高速时电流跟踪会变差。ODrive 在foc.cpp里加了前馈解耦项V_d -omega * L_q * I_qV_q omega * L_d * I_d omega * flux_linkage。其中omega是电角速度L_d、L_q是电感flux_linkage是磁链。这些参数在电机校准阶段测出来。4.4 反 Park 变换与 SVPWMV_d、V_q经过反 Park 变换得到V_alpha、V_beta再送入 SVPWM 模块计算三相占空比。SVPWM 比正弦 PWM 的母线电压利用率高 15% 左右同样的母线电压能输出更大的力矩。SVPWM 的计算过程先判断V_alpha、V_beta落在哪个扇区然后计算相邻两个基本矢量的作用时间最后合成占空比。ODrive 用的是七段式 SVPWM每个周期内开关管切换 6 次谐波性能最好。计算出来的占空比写入TIM_1-CCR1/2/3硬件自动生成互补 PWM 和死区。整个 FOC 计算在 168 MHz 的 M4 上大约耗时 8 微秒加上 ADC 采样和中断开销一个周期总共占用 12~15 微秒CPU 占用率 10% 左右。这个余量足够跑 USB 通信和上位机协议。5. 实测中容易翻车的几个细节5.1 定时器时钟配置错误导致频率翻倍这是最常见的坑。CubeMX 生成代码时APB1 和 APB2 的预分频系数如果设成 1定时器时钟不会倍频如果设成 2、4、8、16定时器时钟自动乘 2。ODrive 的SystemClock_Config里 APB1 分频 4、APB2 分频 2所以 TIM_1 时钟是 168 MHz。如果你自己移植代码时把 APB2 分频改成 1TIM_1 时钟变成 84 MHz同样的 ARR 值下 PWM 频率变成 4 kHz控制环直接乱套。排查方法用示波器测 PWM 输出引脚看周期是不是 125 微秒。如果不是先查RCC-CFGR寄存器的 PPRE1 和 PPRE2 位再查TIM_1-PSC和TIM_1-ARR。5.2 中断优先级配置冲突FreeRTOS 里configMAX_SYSCALL_INTERRUPT_PRIORITY设的是 5意味着优先级高于 5 的中断不能调用 FreeRTOS API。ODrive 把 ADC 中断设成 0、TIM_1 设成 1都高于 5所以中断里不能调用xQueueSendFromISR之类的函数。如果你在中断里调了系统会直接卡死或触发configASSERT。正确做法中断里只做数据采集和计算把结果写到全局变量然后通过一个优先级低于 5 的软件中断或任务通知来触发后续处理。ODrive 就是这么干的ADC_IRQHandler里只更新current_meas结构体主循环里的axis任务负责读取和下发指令。5.3 电流采样时刻偏移中心对齐模式下采样时刻应该落在计数器溢出点附近。但如果你改了ARR或PSC采样时刻可能偏移到开关噪声区。表现是电流波形毛刺大电机发热严重。调整方法在current_sense的初始化代码里找到 ADC 注入通道的触发配置确认触发源是TIM_1_TRGO或TIM_1_CC4。如果是TIM_1_CC4还要检查CCR4的值是否在溢出点附近。ODrive 默认用TIM_1_TRGO触发点固定在溢出事件最省心。5.4 编码器定时器分频不匹配编码器接口用的定时器通常是 TIM_2、TIM_3、TIM_4也要配置时基。如果编码器线数是 4096电机极对数是 7电角度分辨率就是 4096×728672 个计数每电周期。8 kHz 控制环下每个周期电角度变化量在低速时很小编码器定时器的计数频率要足够高才能分辨。ODrive 把编码器定时器的PSC设成 0ARR设成 65535让它自由计数靠 32 位软件扩展来记录多圈位置。如果你把编码器定时器的PSC设大了低速时角度分辨率不够电机会出现“爬行”现象——给定一个很小的速度指令电机要么不动要么突然跳一下。排查时用odrivetool读encoder.pos_estimate看低速时数值是否连续变化。6. 从 8 kHz 延伸出去还能怎么调6.1 提高控制频率的代价与收益有人会想既然 8 kHz 是权衡结果那我把频率提到 16 kHz 或 20 kHz是不是控制更平滑答案是收益有限代价不小。提到 16 kHz周期从 125 微秒缩到 62.5 微秒FOC 计算时间不变8 微秒CPU 占用率从 10% 涨到 13%看起来还能接受。但 ADC 采样窗口被压缩采样保持时间从 0.5 微秒缩到 0.25 微秒信噪比下降电流波形反而更差。而且开关损耗随频率线性增加MOSFET 发热更严重。我的建议除非你的应用对力矩纹波有极端要求比如直驱云台、精密力控否则 8 kHz 足够。真要提先确认电流采样运放带宽和 ADC 采样保持时间跟得上再考虑散热。6.2 降低控制频率的适用场景反过来如果你用的是大功率电机开关损耗是主要矛盾可以把频率降到 4 kHz。周期变成 250 微秒FOC 计算时间占比降到 4%MOSFET 发热明显改善。代价是电流纹波增大低速时力矩波动更明显。适合风机、水泵这类对平稳性要求不高的负载。改频率时除了TIM_1的ARR还要同步改current_sense的采样窗口、encoder的滤波系数、以及controller里的 PI 参数。PI 参数和采样周期强相关周期变了参数不调系统要么振荡要么响应迟钝。6.3 用滴答定时器做辅助时基ODrive 里还有一个SysTick定时器配的是 1 kHz用来做任务调度和时间戳。它和 8 kHz 控制环是独立的互不干扰。但如果你要在控制环里做长时间积分比如位置环的积分项可以用SysTick的计数来扩展时间基准避免 32 位定时器溢出问题。具体做法在SysTick_Handler里维护一个 64 位全局变量global_time控制环里读这个变量做时间差分。这样即使 8 kHz 定时器溢出多次时间戳也不会回绕。ODrive 的axis里位置环积分就用了类似机制。7. 我个人在移植和调试中的几点体会把 ODrive 的 8 kHz 控制环移植到其他 STM32 芯片上最花时间的不是 FOC 算法本身而是时基链路的对齐。我试过用 STM32F103 跑同样的代码主频 72 MHzARR改成 4500PWM 频率对了但 FOC 计算时间涨到 20 微秒125 微秒周期里占比 16%再加上 F103 没有 FPU浮点运算全靠软件模拟实际占用超过 40%电机一转就抖。后来换了 F407主频 168 MHz带 FPU和 F405 基本一致才跑顺。另一个体会是不要迷信示波器上的 PWM 波形。波形好看不代表控制环正常。我遇到过 PWM 波形完美但电机发热严重的情况最后查出来是电流采样时刻偏了 2 微秒采到了开关噪声。后来养成习惯调完 PWM 一定要用odrivetool看current_meas的波形确认电流采样干净再往下调。最后分享一个小技巧如果你不确定中断优先级配置对不对可以在ADC_IRQHandler入口翻转一个空闲 GPIO用示波器测这个 GPIO 的高电平宽度。正常应该在 10~15 微秒。如果超过 20 微秒说明中断里做了不该做的事或者被更高优先级中断打断了。这个方法比看代码猜快得多。