1. 项目概述与需求拆解
1.1 MPU6050这颗传感器，到底难在哪
玩过 stm32 的人，十有八九都碰过 mpu6050 这颗六轴传感器。它便宜、资料多、例程遍地都是，但也正因为用的人多，大家踩过的坑才格外五花八门——尤其是"滤波"这两个字。
很多人第一次接触 mpu6050 时，满怀期待地把加速度计和陀螺仪的原始数据读出来，一打印到串口助手上，当场就懵了：数值跳得像心电图，静止放在桌面上，加速度计的读数也能上下浮动好几十个数。陀螺仪更夸张，明明没动它，角速度输出却时不时飘出一个尖峰。这时候你才明白，为什么网上的教程总是强调"数据要滤波"。
这个项目要解决的问题，就是把这堆"脏数据"洗干净，让 mpu6050 输出的姿态信息真正能用。适合的人群也很明确：刚学会用 stm32 读取传感器原始数据、想做平衡车、四轴、机械臂姿态反馈，或者单纯想把传感器数据用好的同学。
先说结论：滤波不是把数据变"平滑"这么简单，而是在"响应速度"和"噪声抑制"之间找一个平衡点。滤得太狠，数据倒是好看了，但真实动作也被抹掉了；滤得太轻，噪声还在，后续的控制算法照样被带偏。这个平衡点，就是本篇博文要讲的精髓。
1.2 原始数据的噪声构成与影响范围
在动手写滤波函数之前，得先搞清楚一件事：mpu6050 的原始数据里到底有什么噪声？很多人上来就套滤波公式，却不知道自己在滤什么，最后参数调来调去都是瞎蒙。
从实际抓到的数据来看，噪声主要有三个来源：
第一是传感器本身的测量噪声。MEMS 器件的物理结构决定了它天然带有热噪声和机械噪声，加速度计的输出在静止状态下会呈现小幅随机波动，陀螺仪的零偏也会随温度缓慢漂移。这一类噪声在频域上分布较广，属于宽带噪声。
第二是电源纹波和地线干扰。stm32 和 mpu6050 共用电源时，如果电机、舵机或者大功率外设也在同一路电源上，传感器供电会被拉出明显的毛刺。这个噪声往往表现为周期性或突发性的跳变，幅度可以达到正常信号的百分之几甚至更多，频谱上多集中在某个特定频段。
第三是采样过程中的混叠效应。stm32 用 I2C 读取 mpu6050 数据时，如果采样率设置不当，或者读取频率和传感器内部数字低通滤波器的截止频率不匹配，高频噪声会被折返到低频段，变成一个无法用软件轻易去除的"假信号"。
噪声的影响范围也很直观：加速度计的数据稍微抖一点，姿态角在静止时就会晃；陀螺仪零偏漂移，积分出来的角度会以肉眼可见的速度"飞走"。更要命的是，如果这个数据用于 PID 闭环控制，噪声会被控制器放大，轻则电机嗡嗡响，重则系统直接发散。
所以，滤波方案的设计必须同时考虑上述所有噪声源，而不是简单套一个平均数。下面各节会按照从易到难的顺序，把滑动窗口滤波、一阶低通滤波、互补滤波逐个讲透。
2. 滤波算法选型：从简单平均到姿态融合
2.1 滑动窗口滤波模型与适用场景
滑动窗口滤波是很多人用 stm32 处理传感器数据时接触的第一种滤波方案，也是各大热词里最常被提及的"滑动窗口滤波模型"。它的原理非常简单：维护一个固定长度的数据队列（窗口），每次采样到新数据就丢进队尾，同时把队首最旧的数据挤出去，然后对窗口内所有数据求平均，作为当前滤波后的输出。
举个例子：窗口长度设为 10，初始化时队列为空。第 1 次采样，队列只有 1 个数，输出就是这个数；第 5 次采样，队列有 5 个数，输出 5 个数的平均；从第 11 次采样开始，队列始终维持 10 个数，每次输出都是最近 10 次采样的平均值。
用代码来写，最直观的思路是维护一个数组，每次采样后把所有数据左移一位，再算平均值。但这样做的效率太低了，一次滤波要 O(n) 的时间去搬移数据。更高效的做法是用环形缓冲区，维护头指针和尾指针，每次只替换最旧的那个位置，再做一次累加和、减去被替换的旧值、加上新值，时间复杂度降为 O(1)。
滑动窗口滤波的优势在于：实现简单、几乎不需要调参（只需要确定窗口大小）、对周期性噪声有不错的抑制作用。缺点也很明显——它本质上是低通滤波器，延迟和窗口长度成正比。窗口越大，数据越平滑，但实时性越差。如果平衡车需要快速响应倾角变化，窗口太长会直接把控制系统"拖死"。
从实测经验来说，滑动窗口滤波最适合用在变化缓慢、对实时性要求不高的场景，比如温度采集、电池电压检测、按键消抖这类应用。对于 mpu6050 的姿态数据，它可以作为一个初步处理步骤，但不能作为唯一的滤波手段。
2.2 一阶低通滤波（软件方式）与原理解读
如果你搜"滤波算法"，一阶低通滤波（也叫一阶惯性滤波、RC 低通滤波的数字化形式）几乎是必出现的关键词。硬件上有 RC 低通滤波电路，软件上则可以用一条极其简洁的公式复现同样的效果：
( Y[n] = \alpha \cdot X[n] + (1 - \alpha) \cdot Y[n-1] )
其中 ( X[n] ) 是当前采样值，( Y[n-1] ) 是上一次滤波输出，( \alpha ) 是滤波系数，取值范围是 0 到 1 之间。这个公式的含义很直白：当前输出 = 新数据占一点点权重 + 历史输出占大部分权重。( \alpha ) 越小，历史数据占比越大，曲线越平滑，响应越慢；( \alpha ) 越大，越信任新数据，响应越快，但滤波效果越差。
很多初学者拿到这个公式后，第一个问题是：( \alpha ) 到底取多少？这个参数和 RC 滤波电路的截止频率之间，存在一个明确的换算关系。硬件 RC 低通滤波器的截止频率 ( f_c = 1/(2\pi RC) )，数字化之后，如果采样周期为 ( T_s )，那么 ( \alpha = T_s / (T_s + RC) )。反过来，如果希望截止频率为 ( f_c )，可以先用 ( RC = 1/(2\pi f_c) ) 求出时间常数，再由 ( \alpha = T_s/(T_s+RC) ) 计算系数。
举一个具体的例子。mpu6050 的采样周期设为 10ms（即 100Hz），希望低通截止频率在 5Hz 左右。那么 ( RC = 1/(2\pi \times 5) \approx 0.0318s )，( \alpha = 0.01 / (0.01 + 0.0318) \approx 0.239 )。也就是说，alpha 取 0.24 就能滤掉 5Hz 以上的高频分量。这个计算过程非常实用，比靠感觉调参靠谱得多。
一阶低通滤波的适用场景非常广。它计算量极小、只有一个乘法一个加法，在 stm32f103c8t6 这种主频只有 72MHz 的芯片上，跑个几千次都不占什么资源。对于 mpu6050 的加速度计原始数据，一阶低通滤波可以显著降低高频抖动；对于陀螺仪数据，也能有效抑制零偏噪声中的高频成分。但它的问题在于：( \alpha ) 是一个固定值，无法在"响应快"和"平滑"之间自适应切换。如果姿态变化很快，固定的低通滤波会造成明显滞后。
2.3 姿态解算滤波：互补滤波为什么是主流选择
当你要用 mpu6050 做姿态解算时，问题就变得更复杂了——因为这时要处理的不是一个一维数据，而是加速度计和陀螺仪两组数据的融合问题。这也是众多热词里"mpu6050姿态解算"反复出现的原因。
先看两组数据的特性：加速度计测量的是重力加速度在三个轴上的分量，静止时可以通过反正切函数算出俯仰角和横滚角，长期稳定性好、不会飘，但动态响应差——传感器一运动，除了重力以外还会叠加运动加速度，导致角度计算出现明显误差，噪声也比较大。陀螺仪测量的是角速度，对角度的变化响应快、瞬时精度高，但角速度经过积分得到角度时，零偏会随时间累积，造成角度缓慢漂移，长期稳定性差。
互补滤波思路就是：把两种传感器的优势互补起来。高频段信任陀螺仪（因为它在快速变化时更可靠），低频段信任加速度计（因为它在静止时更准确），在频域上做一次"分频融合"。写成公式就是：
( angle = k \times (angle + gyro \times dt) + (1 - k) \times accel_angle )
其中 ( k ) 是互补系数，通常取 0.95~0.99 之间的值。( dt ) 是采样周期。这个公式可以这样理解：陀螺仪积分得到的角度占大头（决定响应速度），加速度计计算的角度占小头（负责把漂移拉回来）。( k ) 越接近 1，越信任陀螺仪，响应越快，但对漂移的纠正越弱；( k ) 越小，加速度计权重越大，角度越不容易漂，但对快速动作的响应就越迟钝。
市面上大量平衡车、四轴飞行器、云台稳定器，用的都是这个思路或其改进版本。互补滤波的计算量比卡尔曼滤波小得多，效果却能在绝大多数场景下逼近卡尔曼滤波，是性价比极高的选择。后面第 4 节会给出完整的 stm32 实现代码。
2.4 开发环境与工具链说明
写 stm32 的滤波程序，开发环境可以选 Keil MDK、STM32CubeIDE 或者 vscode 加插件。很多初学者一上来就被各种"stm32开发环境"的安装过程劝退，这里简单说下我的选择。
我自己的主力组合是 STM32CubeIDE + STM32CubeMX。CubeMX 负责生成初始化代码，CubeIDE 负责编译调试，两条都是免费工具，对 hal 库的支持也最完善。如果你用的是 arm-none-eabi-gcc 工具链，也完全可以在 vscode 里配一套（热词里有"vscode开发stm32"不是没道理），但新手不推荐自己折腾链接脚本，直接用 CubeIDE 最省心。
调试时有个小技巧：把滤波前后的数据通过串口打印出来，在电脑上用串口绘图工具可视化。这一步的价值怎么强调都不过分——你盯着串口助手里的几百行数字，和看着一条平滑的曲线，对滤波效果的判断是完全不同的。推荐用匿名助手上位机或者 VOFA+，前者在无人机圈用得多，后者这几年很火，都支持波形显示。
硬件方面，我用的核心板是 stm32f103c8t6 蓝色 pill 板（热词里"用stm32f103c8t6 hal库模拟iic读取mt6701磁编码器的滤波与校准实战"可以侧面说明这颗芯片的普及度），mpu6050 模块是常见的 GY-521，I2C 接口连接。接线固定四根线：VCC、GND、SCL（PB8）、SDA（PB9）。注意 GY-521 模块的 AD0 引脚决定 I2C 地址，默认接地时地址是 0x68，悬空时也是 0x68，如果读到 0x69，说明 AD0 被拉高了。
3. STM32 工程实现与滤波代码拆解
3.1 工程初始化与 I2C 读取
整个工程的基础是能用 stm32 稳定地读到 mpu6050 的原始数据。用 CubeMX 配置很简单：I2C1 选 PB8/PB9，速率选 400kHz（mpu6050 支持 Fast Mode），串口 1 开 115200 波特率用于输出调试信息，开启一个定时器产生 10ms 中断作为采样节拍。
初始化 mpu6050 时，有几个寄存器必须正确配置。电源管理寄存器 1（0x6B）要写 0x00，目的是让传感器从睡眠模式唤醒；配置寄存器（0x1A）设置数字低通滤波器（DLPF），把带宽设为 94Hz 或 42Hz 都可以，这个设置决定了传感器内部硬件的抗混叠能力；陀螺仪配置寄存器（0x1B）设为 ±2000°/s 量程；加速度计配置寄存器（0x1C）设为 ±2g 量程。量程越大，分辨率越低，如果不做高速运动，±2g 和 ±250°/s 的配置就能获得最佳分辨率。
读取数据的代码用 HAL 库的HAL_I2C_Mem_Read即可。加速度计数据从 0x3B 开始连续 6 个字节，陀螺仪数据从 0x43 开始连续 6 个字节。注意读出来的数据是大端格式，需要自己合并成 int16_t。合并后的原始值要除以灵敏度系数才是物理量：±2g 量程时加速度计灵敏度为 16384 LSB/g，±250°/s 时陀螺仪灵敏度为 131 LSB/(°/s)。这些数值在 mpu6050 数据手册里都有明确标注。
还有一个我自己踩过的坑：I2C 时钟频率不要设得太高。虽然 mpu6050 支持 400kHz，但很多面包板跳线的寄生电容和接触电阻会让高速 I2C 出错，偶尔出现通信失败。如果你发现数据偶尔跳变、或者读回来的数据每隔几十次就错一次，先把 I2C 频率降到 100kHz 试试，往往能解决问题。
3.2 滑动窗口滤波的实现代码
下面是完整的滑动窗口滤波实现，采用环形缓冲区方案，每次滤波的耗时是固定的，不会因为窗口大小变化而波动。
#define SLIDING_WINDOW_SIZE 10 typedef struct { float buffer[SLIDING_WINDOW_SIZE]; uint8_t index; uint8_t count; float sum; } sliding_window_filter_t; void sliding_window_init(sliding_window_filter_t *filt) { memset(filt->buffer, 0, sizeof(filt->buffer)); filt->index = 0; filt->count = 0; filt->sum = 0.0f; } float sliding_window_filter(sliding_window_filter_t *filt, float new_value) { if (filt->count < SLIDING_WINDOW_SIZE) { filt->buffer[filt->count] = new_value; filt->sum += new_value; filt->count++; return filt->sum / (float)filt->count; } filt->sum -= filt->buffer[filt->index]; filt->buffer[filt->index] = new_value; filt->sum += new_value; filt->index++; if (filt->index >= SLIDING_WINDOW_SIZE) { filt->index = 0; } return filt->sum / (float)SLIDING_WINDOW_SIZE; }这段代码的逻辑核心是维护一个累加和sum：每次新数据到来时，先减去窗口中最旧的数据，再加上新数据，这样避免了每采一次样就循环累加全部数据。窗口填满后输出固定为最近 10 次的平均值。
我实测用窗口大小为 10、采样周期 10ms 处理加速度计数据，静止时的抖动从 ±30 LSB 降到 ±10 LSB 左右，效果明显。但前面也说过，窗口太大会引入延迟，所以这个函数适合放在整体滤波链路的"前级"做初步平滑，后面再接其他滤波。
这里有一个取舍大家要清楚：窗口越大，对随机噪声的抑制越强，但对真实信号的跟随越慢。拿静止数据和运动数据做对比测试，运动状态下窗口 10 的峰值信号会被削掉将近一个采样周期的响应速度。如果你的项目需要快速响应（比如飞控），窗口大小建议不超过 5；如果是温湿度类缓变量，窗口 20~50 都没问题。
3.3 一阶低通滤波的实现与参数计算
一阶低通滤波的代码量比滑动窗口还少，核心就是一行公式。
typedef struct { float alpha; float last_output; uint8_t initialized; } lowpass_filter_t; float lowpass_filter(lowpass_filter_t *filt, float new_value) { if (!filt->initialized) { filt->last_output = new_value; filt->initialized = 1; return new_value; } filt->last_output = filt->alpha * new_value + (1.0f - filt->alpha) * filt->last_output; return filt->last_output; }关键参数就是alpha。按照第 2.2 节的公式，如果你用 100Hz 采样率、目标截止频率 5Hz，alpha = 0.01 / (0.01 + 0.0318) ≈ 0.24。如果目标是 2Hz 的截止频率，算出来alpha ≈ 0.11。目标截止频率越低，alpha 越小，曲线越平滑。
在串口绘图工具里观察一阶低通的效果，你会发现它和滑动窗口给人的感觉不太一样：滑动窗口的曲线是"折线感"比较强的平均，一阶低通则是圆润的指数逼近，响应更自然。它的问题在于纯一阶低通对阶跃输入的响应会有一个明显的指数上升过程——数据突然跳变时，滤波输出需要好几个采样周期才能跟上真实值。
这也是为什么我不建议对 mpu6050 的原始数据只用一阶低通就完事。更合理的使用方式是：对加速度计和陀螺仪数据各做一次低通滤波，去除高频毛刺，然后再进入互补滤波的姿态融合环节。这样既利用了低通滤波的平滑特性，又不会让它独当一面。
3.4 三种算法组合的完整滤波链路
我在实际项目里用的滤波链路是这样的：原始数据 → 去除零偏 → 滑动窗口滤波 → 一阶低通滤波 → 互补滤波姿态解算 → 输出角度。
为什么要套这么多层？每一层都有它的职责。去除零偏是为了消除陀螺仪静止时输出不为零的问题，这个在初始化时采样 100 次求平均，作为静态零偏值保存下来；滑动窗口负责抑制突发性尖峰，比如电源波动引起的跳变；一阶低通负责抑制高频随机噪声；最后互补滤波负责融合加速度计和陀螺仪的互补特性，得到稳定的角度值。
这里要特别提醒：多级滤波串联后，总延迟等于各级延迟之和。如果每一级都追求极致平滑，最终姿态数据的响应速度可能会让你无法接受。所以每级的参数要留有余地：滑动窗口窗口别超过 5，一阶低通的 cutoff 别低于 20Hz，靠互补滤波的系数来最终权衡。
一个可以"抄作业"的参数组合：滑动窗口大小为 5，一阶低通 alpha 为 0.6（对应 100Hz 采样下约 20Hz 的截止频率），互补滤波 k 为 0.98。这个组合在我的平衡车项目上表现很稳，响应速度和噪声抑制的平衡比较理想。实际使用时，可以以此为基线，根据你自己的动作频率上下微调。
4. 互补滤波与姿态解算实战
4.1 从欧拉角到四元数：解算前的必要准备
在互补滤波真正动手之前，需要先明确一个概念：你想得到的"姿态"用什么数学形式表示？最直观的是欧拉角（俯仰角、横滚角、偏航角），但欧拉角存在万向锁问题，而且旋转顺序不同会导致同样的角度值对应不同的物理姿态。四元数没有万向锁问题，计算效率也更高，但参数是四个抽象数字，不直观。
对于大部分基于 mpu6050 的应用——比如平衡车、两轮自平衡机器人、云台——其实只需要俯仰角和横滚角，而且不需要全姿态解算。这种情况下直接用欧拉角的简化公式就够了：先用加速度计求初始角度，再和陀螺仪积分融合。偏航角因为缺少磁力计修正，单靠 mpu6050 必然漂移，就不用指望了。
加速度计计算角度，最常用的公式是：
( pitch_acc = atan2(acc_y, sqrt(acc_x^2 + acc_z^2)) \times 180 / \pi )
( roll_acc = atan2(-acc_x, acc_z) \times 180 / \pi )
注意：这里的坐标定义必须和你的 mpu6050 实际安装方向一致。我用的 GY-521 模块默认安装方式（芯片丝印朝上，Y 轴朝前）下，这两个公式成立。如果你的模块竖着装、倒着装，公式里的正负号和轴序都要重新推一遍。初学者最容易在这个环节出问题——角度值突然乱跳、或者正反转方向反了，十有八九是坐标映射没对上。
4.2 互补滤波的核心代码实现
下面是完整的互补滤波实现，以 10ms 定时器中断为采样节拍，滤波结果直接可以用。
typedef struct { float pitch; float roll; float k; float dt; } complementary_filter_t; void complementary_filter_update(complementary_filter_t *filt, float gyro_pitch_rate, float gyro_roll_rate, float acc_pitch, float acc_roll) { // 陀螺仪积分得到当前角度增量 float pitch_gyro = filt->pitch + gyro_pitch_rate * filt->dt; float roll_gyro = filt->roll + gyro_roll_rate * filt->dt; // 互补融合：高频信任陀螺仪，低频信任加速度计 filt->pitch = filt->k * pitch_gyro + (1.0f - filt->k) * acc_pitch; filt->roll = filt->k * roll_gyro + (1.0f - filt->k) * acc_roll; }使用方式是在定时器中断里，先读取原始数据并进行预处理，把陀螺仪的角速度（单位 °/s）和加速度计的角度（单位 °）算出来，然后调用上面的函数。dt必须和实际采样周期一致——如果你用 10ms 定时器，dt = 0.01f。dt不准是角度漂移的重要原因之一。
k的取值对效果影响很直接。取 0.95 时，加速度计的权重是 5%，每 20 个周期（0.2 秒）就能修正一次陀螺仪漂移；取 0.99 时，加速度计权重只有 1%，修正周期拉长到 1 秒。实际测试中，0.98 是一个比较均衡的起点。如果你发现角度曲线毛刺明显（像锯齿波），说明 k 太小，加速度计噪声直接串进来了；如果角度缓慢漂移（整体往上或往下跑），说明 k 太大，修偏能力不足。
还有一个小细节：atan2在 stm32 上运行需要几微秒的时间，放在 10ms 中断里毫无压力。但如果你追求极致效率，可以提前把加速度计角度做成查找表，或者用三角函数的近似算法省掉浮点运算。不过对于 f103 来说，硬件 FPU 虽然没有，但 72MHz 主频跑软件浮点也完全够用。
4.3 静止与动态实测效果对比
为了验证互补滤波的效果，我做了一组对比实验。传感器静止放在桌面上，分别打印以下三种数据：原始加速度计角度（直接由加速度计计算）、纯陀螺仪积分角度、互补滤波角度。
原始加速度计角度的波动范围大约在 ±1.2° 左右，曲线看起来像一条不断抖动的细毛虫——这是加速度计噪声的直接体现；纯陀螺仪积分角度在静止时从 0° 开始，每分钟大约漂移 2°~5°不等，方向还随机，这是零偏积分累积的典型特征；互补滤波角度静止时非常稳定，长时间观测波动不超过 ±0.3°，也没有明显的漂移趋势。
动态测试则更考验响应速度。把传感器绕 X 轴快速转动 90°，然后立刻停止。互补滤波角度可以在 0.1~0.2 秒内跟上真实角度，超调量很小，后续也没有振荡。这比单纯的一阶低通滤波快了 3~4 倍，效果差异肉眼可见。
从这组对比可以得出一个经验：如果你的项目只需要读原始数据做简单的阈值判断（比如"有没有在动"），滑动窗口加一阶低通就够了；如果要做角度的闭环控制，互补滤波基本是底线，再往上才是卡尔曼滤波。
5. 参数整定方法与实测数据记录
5.1 采样率、中断优先级与数据稳定性的关联
滤波效果不仅取决于算法本身，还严重依赖采样节拍的稳定性和中断优先级设置。很多人在这一步栽过跟头：滤波算法写得没问题，但角速度积分的dt抖动很大，最终角度就是稳不住。
用 stm32 定时器产生 10ms 中断时，理论上每次中断的时间间隔都是 10ms，但实际不一定。如果主循环里有耗时的操作（比如串口发送大量数据、OLED 刷新），这些操作可能阻塞在中断执行前，导致中断响应延迟变大。更隐蔽的是，不同中断源之间的优先级较量——如果串口中断优先级比定时器中断还高，串口数据交互频繁时，定时器中断会被挤到后面，dt就会忽大忽小。
解决思路有两个。第一，把采样定时器的中断优先级设到最高（设为 1，数值越小优先级越高），确保采样中断几乎不被抢占；延时姣姣的通讯数据放到主循环中处理，不要在中断里做。第二，不要用固定的dt常量，而是在每次中断里通过读取定时器的计数值，动态计算真实的dt。后者精度更高，但实现起来稍微复杂一点。
另一个常见问题是：在中断里调用 HAL_Delay 函数。这是绝对的禁忌，HAL_Delay 依赖 SysTick 中断，在自制中断里调用会导致整个系统的时间基准错乱。我在一个项目上见过这种写法，后果是串口发送和采样全部乱套，滤波输出呈现一种毫无规律的"脉冲"波形。要延时就在主循环里延，中断里只做该做的事。
5.2 滤波参数调整速查表
这里整理了一份参数整定速查表，是我在不同项目里反复试出来的经验值，可以直接套用。
| 参数 | 推荐范围 | 场景说明 | 调整方向 |
|---|---|---|---|
| 滑动窗口大小 | 3~10 | 越小响应越快，越大越平滑 | 动作频繁取小值，缓变量取大值 |
| 一阶低通 alpha | 0.2~0.8 | 越大越信任新数据 | 响应慢就调大，噪声大就调小 |
| 互补滤波 k | 0.95~0.99 | 越大越信任陀螺仪 | 漂移大就调小，响应慢就调大 |
| 采样周期 | 2~10ms | 越短越利于实时控制 | 控制频率要求高就调短 |
| I2C 速率 | 100~400kHz | 越低越稳定 | 通信异常时优先降低 |
以平衡车为例，我的调法是：先把采样周期定为 5ms（200Hz），滑动窗口取 3，一阶低通 alpha 取 0.5，互补滤波 k 取 0.98。跑起来以后观察串口波形：如果角度曲线在静止时毛刺明显，先把互补滤波 k 往 0.99 调；如果还不行，就把一阶低通 alpha 调小。如果动作响应迟钝，反过来调。每次只改一个参数，改完看波形，别一上来就动三个参数。
5.3 实测数据记录：滤波前后的量化对比
为了让数据更有说服力，我专门用串口记录了两组数据，分别在静止状态和以约 120°/s 的速度匀速翻转传感器。
静止状态（传感器平放在桌面，记录 10 秒）：
| 指标 | 原始加速度计角度波动 | 一阶低通后 | 互补滤波后 |
|---|---|---|---|
| 最大值 (°) | 1.24 | 0.71 | 0.28 |
| 最小值 (°) | -1.08 | -0.62 | -0.19 |
| 标准差 (°) | 0.52 | 0.27 | 0.11 |
动态状态（绕 X 轴翻转 90°，记录整个动作过程）：
| 指标 | 原始加速度计角度 | 一阶低通后 | 互补滤波后 |
|---|---|---|---|
| 响应延迟 (ms) | ~10 | ~60 | ~15 |
| 到达稳定时间 (ms) | ~20 | ~150 | ~80 |
可以看到，一阶低通对静止噪声的抑制效果不错，但动态响应延迟明显变长；互补滤波在保持响应速度的同时，把噪声和漂移都控制在了很低的水平。这也是为什么姿态解算场景里，互补滤波几乎是标准答案。
5.4 关于卡尔曼滤波的补充说明
热词里虽然没有直接出现"卡尔曼滤波"，但聊到姿态解算就绕不开它。如果你想追求比互补滤波更极致的平滑度，可以考虑上卡尔曼滤波。卡尔曼滤波的本质是根据系统模型和观测模型的不确定性，动态计算一个最优权重来融合预测值和观测值。它的参数是过程噪声协方差 Q 和测量噪声协方差 R，调参远比互补滤波复杂，计算量也大一个数量级。
我的建议是：先做好互补滤波，确定你的工程确实无法满足要求后，再考虑卡尔曼。因为两者的效果差距在很多场景下并不明显，但实现的复杂度和调试难度差距很大。如果你只是做平衡车、云台，互补滤波完全够用；如果做高精度的姿态参考系统，才需要卡尔曼或者更高级的滤波算法。
6. 常见问题与排查技巧实录
6.1 通信异常：读不到数据、偶尔丢包
开发 stm32 和 mpu6050 的初期，通信异常是最常见的坑。典型表现是初始化时读 WHO_AM_I（0x75）返回错误值，或者运行过程中数据时不时跳一下。
如果初始化都过不了，优先检查接线：VCC 要接 3.3V，GND 要共地，SCL 和 SDA 有没有接反或者虚接。面包板接触不良是"偶发性故障"的头号嫌疑，我之前有一块 GY-521 插在面包板上，用手轻轻一碰就不通信了，最后发现是排针氧化导致接触电阻变大。解决办法是：所有数据线用短的杜邦线直接连接，尽量别跨接面包板。
如果初始化正常但数据偶尔丢包，多半是 I2C 时序问题。先把 I2C 速率从 400kHz 降到 100kHz，再检查一下两个引脚有没有配置为开漏输出并外接上拉电阻（10k 即可）。stm32f103 内部有上拉，但强度不够，在长线场景下容易出问题。
6.2 数据抖动、毛刺与突发尖峰
当你发现滤波后的数据依然有明显尖峰时，别急着调滤波参数——先判断尖峰是"随机的"还是"周期性的"。随机尖峰多数来自电源（电机启动、舵机转向、WiFi 模块发射瞬间），周期性尖峰多数来自某个外设的中断处理（比如无线模块的数据接收中断）与传感器采样产生了耦合。
处理电源引起的尖峰，硬件上的手段是加去耦电容：在 mpu6050 模块的 VCC 和 GND 之间并联一个 10uF 电解电容和一个 0.1uF 瓷片电容，位置尽量靠近传感器。在 stm32 的 ADC 参考电压引脚上，这个做法同样适用。软件上，可以在尖峰出现的那几个采样周期里做"限幅"处理：如果当前值和上一个滤波输出的差值超过某个物理可实现的最大变化速率，就忽略这个值，用前一个值代替。
比如平衡车倾角变化最快也就是每秒 90°，采样周期 10ms 的话，两个采样点之间角度变化不会超过 0.9°。如果突然出现一个比这个大好几倍的跳变，几乎可以肯定是噪声，直接过滤掉。
6.3 姿态角漂移的排查思路
姿态角漂移，尤其是静止时角度还在慢慢变，是新手最头疼的问题。排查思路要按顺序来：
第一步查dt是否准确。用逻辑分析仪抓一下定时器中断的时间间隔，确认是不是稳定的 10ms。如果中断被其他任务阻塞导致周期性 "卡住"，积分就会引入系统性误差。第二步查陀螺仪零偏补偿是否到位。初始化时采样 100 次陀螺仪求平均，作为零偏减去，这个步骤必不可少；环境温度变化后零偏也会变，所以最好隔一段时间重新校准一次。第三步查互补滤波的 k 是否太大。k 大于 0.995 时，陀螺仪积分占绝对比重，就算有零偏补偿，残余零偏也会缓慢累积，把 k 降到 0.98 左右可以显著改善漂移。
6.4 调试过程中的几个实用技巧
第一，善用串口绘图工具。别只看串口助手的数字，波形可视化能让你瞬间看清噪声的形态。我习惯把滤波前的原始值、滤波后的值、以及真实参考值一起打印出来，三个波形叠加对比，问题一目了然。
第二，为传感器做一个可复现的"标准动作"。比如一个固定的翻转角度、固定速度的来回晃动，方便每次修改参数后进行对照测试。没有标准动作的话，你很难判断改动参数后是变好了还是变坏了。
第三，调参时一次只改一个变量。滑动窗口大小、低通 alpha、互补滤波 k 这三个参数相互影响，同时改会导致根本无法定位是哪个参数引起的波形变化。我调完一个参数后记录下来，跑一组动作，再把波形截图保存，作为参数档案。这个过程虽然繁琐，但对于建立工程经验特别有帮助。
第四，留意上位机和下位机的时钟不同步问题。如果你在串口绘图工具里看到波形有规律的"停顿感"，不一定是滤波的锅，可能只是串口波特率设置不一致导致数据读取丢帧。优先确认波特率、数据位、停止位完全匹配。
6.5 从滤波到完整项目的扩展方向
如果把滤波做扎实了，这个项目可以往很多方向扩展。热词里提到的"基于stm32的智能台灯"可以用姿态数据做手势控制，"stm32控制伺服电机485"可以做机械臂的姿态反馈，"esp8266wifi模块教程stm32"可以把姿态数据无线传到手机端显示，k210与 stm32 通讯则可以把滤波后的结果给视觉处理单元用。
我做过的比较典型的扩展是：把 mpu6050 的滤波输出接入 PID 控制环，做成了一个简单平衡车。滤波延迟和噪声的最终考验就在这类闭环系统里——滤波延迟太大的话，平衡车会持续低频振荡；滤波噪声太大的话，电机驱动会发出尖锐的高频噪声。这两个现象都会逼着你去优化滤波链路，比看任何教程都来得深刻。
我个人在实际操作中的体会是：滤波这件事，写代码只占 20%，剩下 80% 的时间都在调参和观察数据波形。调参不是玄学，核心是理解每个参数的物理意义，再配合波形观察做反馈。多记录、多对比，时间长了自然就有感觉。你手上的 stm32 和 mpu6050 就是最好的实验平台，把这套滤波链路跑通之后，你会对传感器数据处理的整体框架有一个非常扎实的认知，以后再遇到其他传感器，处理思路都能复用。
