108_采集运动数据_观察六轴数据的特点：调试→开发经历

一、任务背景：已完成的工作与目标流程

1. 已完成：MPU 接口层设计
   已完成 MPU 接口层的设计：获取芯片的数据，映射为物理数据。

底层驱动（I2C 读写、原始数据读取）已就绪，为上层提供统一的数据来源。

2. 目标：按方案架构走通姿态解算流程
   得到姿态数据

映射 + 0 偏校准

解算得到欧拉角

该流程与底层无关，属于应用层的数据处理算法。

3. 应用层设计与实现
   建立 app_flight.c / app_flight.h

声明结构体变量，用于存放姿态数据

编写接口 app_flight_get_euler()，完成上述流程的任务

二、调试→二次开发的标准链路
本期核心是讲解“观察问题”的过程，走通如下链路：

调用底层接口，读取原始数据

通过串口打印数据

用 VOFA+ 观察数据波形

根据波形特征定位问题，修改、验证、复盘

这条链路是宝贵的调试→开发经历：先能“看见”数据，才能判断数据是否正确、极性是否符合预期，进而开展二次开发。

三、第一步：调用 Int_MPU6050_Get_Gyro（陀螺仪数据）

1. 调试过程：Bug 1 —— 数值异常偏大
   现象
   串口打印的数据数值很大，例如 I0=65530、I1=19、I2=35。陀螺仪静止时读数本应在 0 附近小幅波动，65530 明显不符合预期。

图片
定位原因
可能的根源：数据本身是负数，但被强转为无符号数据。检查代码发现变量声明为 float 型——问题不在于数值大小，而在于数据类型与原始比特的解析方式不匹配。

解决与验证
将数据类型改为 int16_t 后，数据变为 -7 这类小的负数，符合预期，问题解决。

二次定位与验证
二次定位：无；验证：无。即一次修改即解决，无残留问题。

复盘结论
MPU6050 / MPU9250 这类陀螺仪，寄存器原始数据就是 16 位有符号补码，原始数据必须用 int16_t 接收。

2. 为什么也不能使用 float 型？——解码规则不同
   简单说：解码规则不一样。

当把这 16 个 bit 直接塞进 float 变量，CPU 不会当成 16 位补码整数去解析，而是按照 IEEE 754 单精度浮点数规则解析，得到的是完全不同的数值。

正确理解：float 可以存放整数的数值，但不能直接解释原始二进制比特。

正确做法：必须先把原始二进制翻译成 int16_t 整数，再赋值转换成 float。

补充：I2C 读取两个 8 bit 寄存器时，正确写法是高低字节拼接后强制转换为 int16_t；同一个比特序列，按 uint16_t 解读得到 65530，按 int16_t 解读则为 -6，解读方式不同结果完全不同。

图片
3. 观察数据的极性是否符合目的（二次开发）
俯仰角：前进为正值，符合预期。

偏航角：继续观察验证极性方向，确保后续解算的符号一致。

图片
4. 0 偏现象
出现 0 偏：与摇杆的 ADC 偏移一样，属于物理上的误差，需要在应用层做 0 偏校准。

图片
5. 抖动情况
陀螺仪数据抖动不严重，数据质量较好，可直接用于后续处理。

四、第二步：调用 Int_MPU6050_Get_Accel（加速度计数据）

1. 观察到的现象（Bug 清单）
   0 偏

抖动很严重

Z 轴测量得到的默认值不为 0：加速度为 0 时对应的默认值不为 0

2. 原理解释：为什么静止时加速度读数不为 0
   加速度计原理：$$f=m$$，通过力来反推加速度。

结构模型：小球挂在 2 个弹簧之间，通过某根弹簧受到的力，来反推小球加速度。

静止时，下面的弹簧被压缩，按照它的计算原理，自然就有加速度——实际上物体并没有加速度。

所以说，加速度为 0 时，这个值应该是不为 0 的。

我们测量得到的默认值就是偏移的结果；真实的值如何处理，下一节（109：解决原始数据零点漂移）再讲。

3. 极性判断
   与陀螺仪同理，判断加速度数据的极性是否符合预期，为后续姿态解算的方向一致性做准备。

五、本期小结
调试是开发的第一环节：观察 → 定位 → 验证 → 解决 → 复盘，形成闭环。

数据类型必须与原始比特的解析方式匹配，是嵌入式数据采集的关键坑点。

0 偏与抖动是惯性传感器的常见现象，后续通过 0 偏校准与滤波处理。