企业官网建设流程全解析

做姿态解算的朋友一定都遇到过这种尴尬：加速度计数据一抖动，角度跟着跳；陀螺仪积分一会儿就开始漂；磁力计更不用提，周围放个螺丝刀航向角都能偏出十几度。数据不是没有，是单看哪一个都没法直接用。X-CUBE-MEMS1 扩展包里的 MotionFX 传感器融合库，就是专门解决这个问题的——它把加速度计、陀螺仪、磁力计的原始数据揉在一起，输出稳定的四元数和欧拉角，一颗 STM32 就能跑，这也是我在多个可穿戴和机器人项目里选择的方案。

这篇笔记就是我调 MotionFX 的完整记录，从环境搭建、API 理解、数据单位换算，到磁力计校准、姿态角验证，再到各种坑的排查思路，一次性讲清楚。无论你用的是官方 Nucleo 扩展板还是自己的传感器模组，这套流程都能直接照着走。

1. MotionFX 是什么、为什么姿态估计离不开它

1.1 加速度计、陀螺仪、磁力计各有毛病

在动笔写代码之前，先把原理摸透。要知道 MotionFX 解决的是什么问题，就得先看三个传感器单独用各自的缺陷。

加速度计测量的是比力，静止时它给出的方向就是重力反方向，所以可以用atan2(acc_y, acc_z)这类公式算出俯仰和翻滚角。但问题在于它分不清“重力”和“运动加速度”，你拿着板子一晃，输出里面混入了线性加速度，角度就乱跳。坐过公交车的人都有体会——起步那一下你感觉车身“后仰”，其实是惯性造成的假象，加速度计也会被这种假象骗。

陀螺仪测的是角速度，对它积分就能得到角度变化。积分的问题大家都懂，零偏不稳定、温度漂移，时间一长角度就慢慢跑偏，几分钟不看它可能已经转了十几度。

磁力计输出的是磁场矢量，可以提供航向参考，但它对环境里的软铁硬铁干扰极其敏感，电机、扬声器、铁质外壳都会让测量结果扭曲，而且单独的磁力计没法给出俯仰和翻滚信息。

所以，三个传感器单独用都靠不住，但它们的误差特性恰好是互补的：加速度计低频准、高频噪；陀螺仪高频准、低频漂；磁力计提供绝对航向基准。融合算法要做的事情，就是在运动过程中用陀螺仪的高频响应撑住姿态，再用加速度计和磁力计在低频段不断修正积分漂移。

1.2 MotionFX 在 X-CUBE-MEMS1 里的定位

X-CUBE-MEMS1 是 ST 官方为 MEMS 传感器推出的软件扩展包，里面不止一个库，除了 MotionFX 之外，还有 MotionMC（磁力计校准）、MotionAR（活动识别）、MotionPM（计步）、MotionGR（手势识别）等一堆中间件。这些库共用一套传感器抽象层，底层读取驱动可以复用，MotionFX 是这套生态里最核心、最常被先跑起来的那个模块。

MotionFX 本质上是一个姿态航向参考系统（AHRS）算法库，它内部实现了带有自适应增益的滤波算法，效果介于传统互补滤波和完整卡尔曼滤波之间。官方一般不公开具体滤波方程，从工程表现来看，它会在静止时增大加速度计修正权重，运动剧烈时降低加速度计权重、更多依赖陀螺仪积分，同时根据磁力计校准质量决定航向修正量的大小。这种“动态调整可信度”的思路，比你在网上找的固定系数互补滤波要聪明不少。

1.3 6轴模式与9轴模式怎么选

MotionFX 支持两种融合模式，这是配置阶段第一个需要做的决定。

6轴模式只使用加速度计和陀螺仪，输出俯仰、翻滚和相对航向变化，没有绝对航向。9轴模式再加入磁力计，输出绝对的航向角。听起来9轴一定比6轴好，实际工程里却不是这么回事。磁力计对环境干扰非常敏感，如果你的设备旁边有电机、电流环路或者金属结构，9轴融合出来的航向可能反而比6轴的积分结果更不稳定。

我的建议是：第一版工程先跑6轴，把加速度计和陀螺仪的链路调通，确认姿态角在静止和运动状态下都合理，然后再决定要不要引入磁力计。这样排查问题的时候变量更少，传感器融合库一旦输出不对劲，你能很快定位是算法参数问题还是数据输入问题。

2. 动手前准备：硬件、软件与工程搭建

2.1 硬件选型和I2C接线

运动传感器融合不是高算力需求，市面上任何一颗带 FPU 的 STM32 跑 MotionFX 都够用。我经常拿来做验证的是 NUCLEO-L476RG 开发板，搭配 X-NUCLEO-IKS01A2 扩展板，这套组合在 ST 官方生态里最省心，CubeMX 里勾选之后驱动代码基本是自动生成的，适合第一次接触 MotionFX 的人。

如果你用的是自己的板子，注意传感器要接在同一个 I2C 总线上，一般加速度计/陀螺仪（LSM6DSO、LSM6DSL 这一类）和磁力计（LIS2MDL、LIS3MDL）都支持 I2C 或 SPI。我优先推荐 SPI 接口，尤其当你的系统里 I2C 总线上挂了很多设备时，SPI 的时序更干净，抗干扰能力更强。不过官方示例默认是 I2C，图省事可以把 I2C 速度配置为 400kHz 快速模式，MotionFX 对数据实时性要求不苛刻，只要不在同一时刻被其他高负载设备抢占总线就好。

自研板要注意传感器坐标轴方向。MotionFX 库默认假设传感器坐标轴和设备坐标轴完全重合，如果你的 PCB 上传感器旋转了 90 度放置，姿态角输出方向就会错。这个问题后面第 5 章会详细讲，核心是用MX_MotionFX_SetOrientation()配置坐标转换矩阵。

2.2 STM32CubeMX 配置与 X-CUBE-MEMS1 安装

工程搭建我直接说最快路径。

第一步，打开 STM32CubeMX，在 Help 菜单的 Manage embedded software packages 里找到 STMicroelectronics 分类，安装 X-CUBE-MEMS1 扩展包。版本选最新的稳定版即可，注意 CubeMX 版本不要太老，不然扩展包管理器可能识别不到新版本。

第二步，新建工程，选好 MCU 型号，在 Pinout & Configuration 视图里把 I2C1 使能。

第三步，在 Software Packs 一栏找到 X-CUBE-MEMS1，勾选 MotionFX。如果你打算做磁力计校准，把 MotionMC 也一起勾上。这里有个容易被忽略的点：MotionFX 库的运行依赖 MotionMC 输出的磁力计校准参数，虽然 MotionFX 也内置了简易校准接口，但最好用 MotionMC 做专门的椭球拟合，精度完全不一样。

第四步，在 Middleware and Software Packs 里可以看到 MotionFX 的配置选项，保持默认就行，入门阶段不需要动任何参数。时钟树配置通常自动生成没问题，生成工程之前确认一下 I2C 时钟源有没有被正确分配。

第五步，Project Manager 设置好工程名和工具链（STM32CubeIDE、Keil 或 IAR 都行），点击生成代码。

2.3 生成工程后需要补什么

CubeMX 生成完的代码可以直接编译，但距离真正跑出姿态还有两步要走。

第一，确认Middlewares/ST/STM32_MotionFX_Library目录下的源码有没有被添加到编译路径里。CubeMX 偶尔会把这个目录漏掉，或者只把部分 .c 文件加入工程，编译报 undefined reference 的时候十有八九就是这个原因。

第二，检查传感器底层驱动。CubeMX 在勾选 X-CUBE-MEMS1 时，如果识别到官方扩展板，会自动加入对应的 BSP 驱动；如果你用的是自研板，CubeMX 不会帮你生成传感器初始化代码，需要自己写 I2C/SPI 的寄存器配置。我第一次用自研板时就在这一步卡了两天，CubeMX 生成了 MotionFX 代码却没生成任何传感器驱动，编译倒是能过，运行起来数据全是零。

3. MotionFX 核心 API 与数据流向

3.1 初始化：Init 和 Initialize 的区别

MotionFX 的初始化代码在 CubeMX 生成后通常是这样的：

MX_MotionFX_Init(MOTIONFX_ENGINE_DISABLE); MX_MotionFX_Initialize();

这两个函数名字看着像，作用完全不同。MX_MotionFX_Init()是 X-CUBE-MEMS1 业务层做的平台适配初始化，参数 MOTIONFX_ENGINE_DISABLE 表示不使用平台相关的附加功能，比如 Sensor Fusion 之外的活动识别联动。MX_MotionFX_Initialize()才是算法库本身的初始化，内部会分配内存、设置默认参数、把内部状态机归位。

调试的时候有个小技巧：如果怀疑 MotionFX 状态不对，可以在主循环里随时调用MX_MotionFX_Reset()重新初始化算法状态，传感器驱动和外设不需要重新配置。这个函数在开发阶段非常常用——你想让系统从“当前姿态”重新开始解算，或者从静止姿态重新校准，直接调它就行。

3.2 输入数据结构：单位决定成败

MotionFX 的输入数据结构是MX_MotionFX_Input_t，我见过太多人在这上面栽跟头：字段名看懂了，但单位没换算对，出来的姿态完全不对。

实际项目中至少要填充以下字段：

单位换算这个坑，用 LSM6DSO 举例。量程配置为 ±4g 时，数据手册给出的灵敏度是 0.122 mg/LSB，也就是每个 LSB 对应 0.000122g。你从寄存器读出来的原始值，要乘上 0.000122 才是 MotionFX 要的 g 值。陀螺仪同理，量程 ±2000dps 时灵敏度是 70 mdps/LSB，乘以 0.07 得到 dps。如果你写代码时惯性思维把加速度当成了 m/s²，那 MotionFX 内部会把重力加速度当成 9.8g 来算，一切融合系数全都乱了，静止时的俯仰角会偏到离谱。

磁力计更麻烦。LIS2MDL 的内部量程是 ±50 高斯，输出的是无符号整数换算后有符号数，灵敏度大约是 0.0015 uT/LSB。MotionFX 要求 mGauss，就需要先把 uT 乘以 10 转成 mGauss。不同磁力计芯片转换关系不同，务必以数据手册和芯片驱动源码为准，别套用别的芯片的系数。

time_stamp 字段也值得单独说。MotionFX 后续版本统一使用毫秒，但早期版本的注释里可能有不同的说明。最稳妥的做法是看安装目录下的motion_fx.h头文件注释，或者用定时器中断直接给HAL_GetTick()的值。只要保证两次调用之间的时间戳差值接近真实时间间隔，算法就能正确估计角速度积分步长。

3.3 Update 与输出：四元数到欧拉角

算法核心调用每次只需要一个函数：

MX_MotionFX_Update(&output, &input, &output, &status);

第一次看到这个签名的人通常会困惑：为什么输出参数同时出现在第二个和第三个位置？官方解释是output作为本次输出的同时，也会作为上一次状态的输入参与内部迭代，所以同一个结构体指针传入两个位置是合法的，这是库的惯用法。

每次 Update 之后，output 结构体里的 quaternion[4] 就是最新的姿态四元数。四元数虽然数学上很优雅，但人眼没法直观理解，实际工程中还是要转成欧拉角显示。使用 ZYX 顺序（先偏航、再俯仰、最后翻滚）的转换公式：

#define RAD2DEG (180.0f / 3.14159265358979f) float q0 = out.quaternion[0]; float q1 = out.quaternion[1]; float q2 = out.quaternion[2]; float q3 = out.quaternion[3]; float roll = atan2f(2.0f * (q0 * q1 + q2 * q3), 1.0f - 2.0f * (q1 * q1 + q2 * q2)) * RAD2DEG; float pitch = asinf(2.0f * (q0 * q2 - q3 * q1)) * RAD2DEG; float yaw = atan2f(2.0f * (q0 * q3 + q1 * q2), 1.0f - 2.0f * (q2 * q2 + q3 * q3)) * RAD2DEG;

特别注意asinf()的输入范围。四元数标准化后，2.0f * (q0 * q2 - q3 * q1)理论上不会超出 [-1, 1]，但浮点累计误差会偶尔让它变成 1.0000001，此时asinf()会返回 NaN。稳妥的做法是在调用前做一次饱和处理：

float sinp = 2.0f * (q0 * q2 - q3 * q1); if (sinp > 1.0f) sinp = 1.0f; if (sinp < -1.0f) sinp = -1.0f; float pitch = asinf(sinp) * RAD2DEG;

4. 完整实操：从传感器原始数据到稳定姿态

4.1 传感器驱动配置与数据读取

传感器驱动的写法依赖具体芯片，我给一个 LSM6DSO + LIS2MDL 组合的参考配置。

首先是加速度计和陀螺仪的量程与输出速率：

/* 加速度计 ±4g，陀螺仪 ±2000dps，ODR 104Hz */ lsm6dso_xl_set_full_scale(dev_ctx, LSM6DSO_4g); lsm6dso_gy_set_full_scale(dev_ctx, LSM6DSO_2000dps); lsm6dso_xl_set_odr(dev_ctx, LSM6DSO_XL_ODR_104Hz); lsm6dso_gy_set_odr(dev_ctx, LSM6DSO_GY_ODR_104Hz);

量程选择有讲究。加速度计量程太小容易在剧烈运动时削波，量程太大又损失分辨率，±4g 是平衡点。陀螺仪量程直接给到 ±2000dps，绝大多数手持设备、机器人场景都够用，量程大一点牺牲分辨率换可靠性，值得。

读取数据并转换为标准单位：

lsm6dso_acceleration_raw_get(dev_ctx, raw_acc); // raw_acc 是 int16_t[3] lsm6dso_angular_rate_raw_get(dev_ctx, raw_gyro); // raw_gyro 是 int16_t[3] /* 灵敏度：±4g 时 0.122 mg/LSB → 0.000122 g/LSB */ input.acceleration[0] = raw_acc[0] * 0.000122f; input.acceleration[1] = raw_acc[1] * 0.000122f; input.acceleration[2] = raw_acc[2] * 0.000122f; /* 灵敏度：±2000dps 时 70 mdps/LSB → 0.07 dps/LSB */ input.angular_velocity[0] = raw_gyro[0] * 0.07f; input.angular_velocity[1] = raw_gyro[1] * 0.07f; input.angular_velocity[2] = raw_gyro[2] * 0.07f;

磁力计读取类似，但要注意 LIS2MDL 的数据输出格式比较特殊，它的寄存器输出是无符号整数，需要先转成有符号数再乘灵敏度。ST 官方 BSP 驱动里已经封装好lis2mdl_magnetic_raw_get()，直接调用就行。

4.2 陀螺仪零偏校准

MotionFX 有内置的陀螺仪偏差管理，但前提是它必须能在静止状态下自动评估。如果你的设备一上电就开始运动，或者 MotionFX 的状态标志没有正确设置，零偏补偿效果就会很差。我的习惯是在算法启动前主动做一次陀螺仪零偏校准。

原理非常简单：设备静止不动时，陀螺仪的读数理论上全为 0，但实际上每个轴都有一个固定偏置，这个偏置会在积分过程中线性累积。采样几百个点求平均，就得到了每个轴的零偏值。之后在送入 MotionFX 之前先把零偏减掉。

#define GYRO_CALIB_SAMPLES 200 float gyro_offset[3] = {0.0f}; void gyro_calibration(void) { int32_t sum[3] = {0}; for (int i = 0; i < GYRO_CALIB_SAMPLES; i++) { int16_t raw[3]; lsm6dso_angular_rate_raw_get(dev_ctx, raw); sum[0] += raw[0]; sum[1] += raw[1]; sum[2] += raw[2]; HAL_Delay(10); } gyro_offset[0] = (float)sum[0] / GYRO_CALIB_SAMPLES * 0.07f; gyro_offset[1] = (float)sum[1] / GYRO_CALIB_SAMPLES * 0.07f; gyro_offset[2] = (float)sum[2] / GYRO_CALIB_SAMPLES * 0.07f; }

校准期间一定要把板子放在桌面上别动，任何微小的振动都会污染平均值。200 个样本大概需要 2 秒，够用了。校准完成后把 offset 减掉再填入 MotionFX 的 input 结构体。

4.3 磁力计校准：不能跳过的一步

磁力计校准是整个流程里最容易被跳过、但影响最大的一步。如果你不做校准，9 轴模式下的航向角会出现整体偏移和随姿态变化的非线性误差，而且这种误差是算法没法自行修正的。

MotionMC 库是专门做磁力计校准的，算法比常见的“转几圈求最大最小”要复杂得多——它用椭球拟合来估计硬铁偏移、软铁缩放和旋转矩阵。使用时在 CubeMX 里把 MotionMC 也勾选上，初始化后循环调用：

MX_MotionMC_Initialize(); while (1) { /* 用户拿着板子，绕三个轴缓慢转8字 */ MX_MotionMC_Update(&mc_output, &input, &mc_status); if (mc_status.calibration_accuracy >= 3) { MX_MotionMC_GetCalibrationData(&mag_cal); // 保存校准结果 MX_MotionFX_SetMagCalibrationData(&mag_cal); break; } }

校准精度calibration_accuracy是 0 到 3 的等级，3 表示拟合结果很好。实际操作时要让板子绕三个轴都尽量覆盖全姿态，转动速度不用太快但一定要“够厚”——想象把板子贴在球面上滚动，保证磁力计在各方向上都能采样。这个过程持续几十秒到一分钟，具体看你的手法。

校准结果建议保存到 Flash 里。下次启动时直接读取并调用MX_MotionFX_SetMagCalibrationData()，不需要每次开机都重新校。磁力计校准对使用环境很敏感，在办公室里校准的数据拿到电机旁边用，航向角又会偏，这属于正常现象，工程上通常把校准流程做成开机后可选操作。

4.4 融合启动流程与初始姿态设置

MotionFX 从零开始融合时，默认初始四元数是单位四元数，也就是“水平且航向为 0”。如果你的设备启动时是歪着放的，融合输出会从水平状态慢慢收敛到真实姿态，这段时间内角度误差可能很大。对很多实时系统来说，这种“慢慢收敛”是不可接受的。

解决办法是启动时先利用加速度计估算初始俯仰和翻滚角，反算初始四元数，再启动融合。从欧拉角构造四元数的公式（ZYX 顺序）：

static void euler_to_quat(float roll, float pitch, float yaw, float *q) { float cr = cosf(roll * 0.5f), sr = sinf(roll * 0.5f); float cp = cosf(pitch * 0.5f), sp = sinf(pitch * 0.5f); float cy = cosf(yaw * 0.5f), sy = sinf(yaw * 0.5f); q[0] = cr * cp * cy + sr * sp * sy; q[1] = sr * cp * cy - cr * sp * sy; q[2] = cr * sp * cy + sr * cp * sy; q[3] = cr * cp * sy - sr * sp * cy; }

启动流程是这样：先静止采集加速度计数据，取平均后算出roll = atan2f(acc_y, acc_z)、pitch = -atan2f(acc_x, sqrtf(acc_y*acc_y + acc_z*acc_z))。然后把初始 yaw 设为 0，把三个角代入上述函数得到四元数，最后在MX_MotionFX_Update()之前调用MX_MotionFX_Reset()，重置之后在下一个周期把初始四元数写入 output。

很多精简代码里没有这一步，直接用默认单位四元数启动，结果就是开机瞬间姿态会“甩”一下再回来。做无人机或者机器人这类对启动姿态敏感的设备，这一步必不可少。

4.5 主循环的调用代码

整体框架我用定时器中断保证调用频率稳定，而不是在 while(1) 里轮询，这对融合精度很重要。

static MX_MotionFX_Input_t input; static MX_MotionFX_Output_t output; static MX_MotionFX_Status_t status; static uint32_t timestamp_ms = 0; void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim->Instance == TIM6) { timestamp_ms++; /* 读取传感器并转换成标准单位 */ read_sensor_data(&input); input.time_stamp = timestamp_ms; /* 陀螺仪零偏补偿 */ input.angular_velocity[0] -= gyro_offset[0]; input.angular_velocity[1] -= gyro_offset[1]; input.angular_velocity[2] -= gyro_offset[2]; /* 传感器坐标方向调整（默认不变） */ MX_MotionFX_Update(&output, &input, &output, &status); /* 四元数转欧拉角后，发送到上位机或本地显示 */ quaternion_to_euler(output.quaternion); } }

这里把MX_MotionFX_Update()放在定时器中断里，而不是主循环里，是因为库要求调用间隔尽量均匀。假如主循环里有一段耗时操作（比如串口打印浮点数），下一次调用的时间戳偏差就会被算法当作真实运动，姿态角出现抖动。用定时器中断后，时间戳和实际调用时刻是对齐的。

定时器中断频率选多少？MotionFX 官方推荐 100Hz 左右。传感器 ODR 我设成 208Hz，但中断只每 10ms 取一次最新值，这样每次取到的都是接近当前时刻的数据，而不是等待传感器数据就绪后才去读，延迟更低。

5. 调参与性能优化实测

5.1 时间戳一致性：最容易被忽视的精度杀手

前面提到过time_stamp字段，这个字段直接影响 MotionFX 内部对角速度积分步长的估算。如果时间戳数值和实际调用间隔不符，姿态解算的角速度权值就是错的。

一个典型错误是直接使用HAL_GetTick()作为时间戳，然后在 while(1) 里轮询调用。HAL_GetTick()返回的是系统上电以来的毫秒数，单独看没问题，但如果你在某个循环里执行了阻塞操作，下一次读取的时间戳差值可能是 10ms，实际已经过去了 50ms，MotionFX 会以为角速度变化很慢，积分出来的角度就偏小。

解决思路有两条。一是严格使用定时器中断触发，中断里给timestamp_ms加 1，这样数值永远是等间隔的，这时候用它当时间戳完全可靠。二是如果你只能轮询，那就用外部时间源的实际值，不要自己构造间隔。

5.2 融合频率与传感器ODR怎么配合

MotionFX 的调用频率建议保持在 30Hz 到 200Hz 之间。低于 30Hz，高频运动信息丢失严重；高于 200Hz，运算量增大且超采样收益递减。

传感器 ODR 和融合频率不需要完全一致。比如传感器 ODR 设成 208Hz，MotionFX 每 10ms 调用一次（100Hz），相当于每两次传感器数据取一次最新值，完全没问题。但反过来，传感器 ODR 是 100Hz，MotionFX 调用频率却设成 200Hz，第二次调用时取到的还是上一次的旧数据，等于白算一次，还会让时间戳和实际数据不匹配。

我的推荐组合：传感器 ODR 104Hz 或 208Hz，融合调用频率 100Hz。定时器中断里读传感器 FIFO 或者读当前寄存器，保证每次 Update 前有足够新的测量值。

5.3 内存占用和算力平台的取舍

MotionFX 库的代码不算小，加上调试信息，Flash 占用大概在 20KB 到 40KB 之间，RAM 占用主要看输出数据结构，大约几 KB。Cortex-M4 及以上平台跑起来毫无压力，开 FPU 之后效果更好。

Cortex-M0 这类没有浮点单元的内核也能编译通过，但浮点运算会退化成软件模拟，速度明显下降。如果非要在 M0 上跑，建议把融合频率降到 50Hz，传感器数据在送入前先做滤波处理，降低 MotionFX 高频噪声对运算资源的消耗。

编译优化级别对 MotionFX 的运行性能影响非常大。我实测在 -O0 优化级别下，一次MX_MotionFX_Update()调用耗时比 -O2 下多了几乎一倍。如果主循环还干别的事，尽量把优化级别开到 -O2 以上，MotionFX 在 -O2 下的行为是正常的，不会出现奇怪问题。

6. 常见问题排查与坑位清单

6.1 姿态跳变但静止时正常

典型现象是设备静止时输出平稳，但一动起来姿态就会出现瞬间跳变，回静止后又恢复正常。

优先查加速度计数据里是否混入了线性加速度。MotionFX 无法区分重力和运动加速度，如果运动加速度很大（比如快速冲击或振动），融合输出自然会有瞬间波动，这属于原理限制。如果跳变幅度大到几十度，就是另一个问题——确认加速度计单位是 g，而不是 m/s² 或原始 LSB 值。

另一个常见来源是数据读取失败。I2C 总线时序不稳会偶发读到 0xFFFF，MotionFX 拿到异常值后会在一个周期内输出剧烈跳变。排查办法是在read_sensor_data()里加入有效性检查，连续读到相同异常值就丢弃这一帧。这个坑在自研板布线不良时尤其常见。

6.2 航向角漂移

航向角缓慢漂移是磁力计相关问题的典型表现。

先确认 MotionFX 确实运行在 9 轴模式，并且磁力计校准数据已经正确加载。再检查mag_calibration_accuracy，这个值代表库对当前磁场干扰的评估，当环境磁场变化超出加载的校准矩阵覆盖范围时，精度值会下降，MotionFX 也会自动减少磁力计权重，航向角漂移会变得明显。

如果 6 轴模式的航向角也在漂移，那是陀螺仪零偏没补干净。检查零偏校准样本数是否足够，或者零偏是否存在温度漂移。工程上可以在设备长时间静止时，利用 MotionFX 的状态标志触发重新校准。

6.3 编译和链接问题

CubeMX 生成工程后编译报 undefined reference，九成是 MotionFX 库源码没有加入编译。检查工程里有没有MotionFX_Manager.c、motion_fx.c这些文件，没有就手动添加Middlewares/ST/STM32_MotionFX_Library目录。

还有一类问题是头文件路径缺失。CubeMX 项目里 MotionFX 相关的 include 路径有时只加了一部分，编译时找不到motion_fx.h。到 Project Properties -> C/C++ General -> Paths and Symbols 里确认路径是否完整，不行就手动加上。