2026 ADI CodeFusion 竞赛 - 基于 MAX32655FTHR 实现本地手势识别控制器

所选任务：任务 1.1 本地手势识别控制器

一、项目描述

本项目基于 MAX32655FTHR 开发板、外接 MPU6050 六轴惯性传感器与 0.96 英寸 I2C OLED，完成了一个可在微控制器本地运行的手势识别控制器。系统面向 WAVE、ROTATE、TAP 三类手势，通过 MPU6050 采集三轴加速度和三轴角速度原始数据，在 Python 端完成数据分析与轻量神经网络训练，再将标准化参数、网络权重和偏置导出为 C 数组，部署到 MAX32655FTHR 上进行实时前向推理。最终识别结果直接显示在 OLED 上，不依赖云端模型。

项目最终使用 90 组训练数据与重新佩戴传感器后独立采集的 30 组测试数据。冻结模型为 Tiny MLP：输入 72 维、隐藏层 16 个神经元、输出 3 类，隐藏层采用 ReLU。独立测试 30 组中正确识别 29 组，准确率为 96.7%；实机从 MCU 判定动作触发到 OLED 完整显示手势名称的响应时间稳定在约 176 ms。

项目核心指标：

二、硬件介绍

1. MAX32655FTHR：作为项目主控，负责 I2C 通信、动作触发判断、短时间窗采样、特征构造、Tiny MLP 前向推理、OLED 显示以及 TMR0 响应时间测量。
2. MPU6050：外接六轴惯性传感器，提供三轴加速度和三轴角速度数据。项目设置为加速度 ±16 g、陀螺仪 ±2000 dps，采样周期约 20 ms（约 50 Hz）。传感器固定在手背靠近中指根部的位置。
3. 0.96 英寸 I2C OLED：SSD1306 兼容 128×64 屏幕，用于显示 READY、WAVE、ROTATE、TAP 以及响应时间。
4. 面包板与杜邦线：用于原型阶段模块连接。本项目未设计自制 PCB。

主要连接关系：MPU6050 与 OLED 共用 I2C2，总线 SCL 接 P0.30，SDA 接 P0.31，均使用 3.3 V 与 GND；MPU6050 地址为 0x68，OLED 默认地址为 0x3C（程序保留 0x3D 兼容检测）。

图 1 最终硬件实物。

三、方案框图与设计思路

图 2 系统方案框图。

设计思路采用“传感器采集 → 动态特征 → 轻量模型 → MCU 本地推理 → OLED 反馈”的链路。与直接使用固定阈值相比，神经网络能够结合多个时间点和多个轴的联合变化，对速度和姿态变化具有更好的适应能力；同时模型尺寸控制在极小规模，使其可以直接部署到资源受限的 MCU 上。

每次识别使用 9 个采样点，其中前两个为触发前样本，第 3 个样本对应触发附近，之后继续采集 6 个样本。以前两个样本的均值作为六轴基线，对每个时间点计算相对 ax、ay、az、gx、gy、gz，并额外计算加速度相对向量模长和角速度相对向量模长，因此每个时间点得到 8 个输入，9×8 共 72 维。训练阶段使用 StandardScaler 标准化，再输入 72→16→3 的 Tiny MLP。部署后 MCU 执行完全相同的特征与标准化流程。

四、原理图、PCB 设计与连接说明

本项目采用模块化原型验证，没有设计自制 PCB，因此按活动要求省略 PCB 设计部分。硬件连接采用面包板与杜邦线完成，核心连接如下：

该方案的优点是结构简单、方便快速验证；缺点是杜邦线和共用 I2C 总线在较大动作时可能受到机械扰动，因此成品形态仍有进一步集成与固定的空间。

五、软件流程图、调试软件说明与关键代码

图 3 MCU 软件流程图。

1. CodeFusion Studio 开发与调试

软件部分使用 CodeFusion Studio 完成 MAX32655 工程配置、编译、下载和调试。I2C2 外设由 CFS 工程配置并在生成的 soc_init.c 中初始化，主程序不重复初始化 I2C，以避免外设状态冲突。项目同时使用串口输出状态、识别类别、MLP logits 与 TMR0 响应时间，便于定位问题。

图 4 CodeFusion Studio 中的最终工程与 main.c。

图 5 在 CodeFusion Studio 中查看导出的 gesture_mlp_model.h。

2. 数据采集与动作触发

系统在 READY 状态下持续读取 MPU6050，并以静止时的基线作为参考。当加速度相对变化模长或角速度相对变化模长超过阈值时，判定动作触发，并立即用 TMR0 记录起始时刻。识别短窗包含 2 个触发前样本、触发样本及后续 6 个样本。

关键参数：SAMPLE_PERIOD_MS = 20、WINDOW_SAMPLES = 9、ACCEL_TRIGGER_THRESHOLD = 2000、GYRO_TRIGGER_THRESHOLD = 2000。

3. 72 维特征构造与 StandardScaler

在 classify_gesture_mlp() 中，首先计算样本 0 和样本 1 的六轴平均值作为 baseline；随后逐点计算六轴相对值，并计算三轴加速度相对向量模长和三轴角速度相对向量模长。得到 72 维特征后，按照训练时保存的 gesture_scaler_mean[72] 和 gesture_scaler_scale[72] 完成标准化。

4. Tiny MLP 本地前向推理

第一层执行 72×16 的矩阵乘加并加上 b1[16]，随后使用 ReLU：小于 0 的值置 0；第二层执行 16×3 的矩阵乘加并加上 b2[3]。由于 Softmax 不改变最大值所在的位置，MCU 端不必计算指数函数，直接对三个输出 logits 取 argmax 即可。模型输出顺序冻结为 ROTATE、TAP、WAVE。

最终导出的模型包括 72 个 mean、72 个 scale、W1(72×16)、b1(16)、W2(16×3)、b2(3)，共 1363 个 float，约 5.32 KiB。

5. TMR0 响应时间测量与 OLED 输出

早期版本尝试使用 Arm DWT 周期计数器，但在当前 CFS/MSDK 运行环境中计数始终为 0，因此改用 MAX32655 的硬件 TMR0。TMR0 使用 60 MHz ISO 时钟、64 分频，以 32 位连续计数方式运行。计时起点为 MCU 判定动作触发，终点为 OLED 完整大字手势名称完成传输。最终实测稳定约 176 ms。

为降低延迟，OLED 显示从“先清屏再绘制”优化为固定 72 列×2 页结果区域：一次定长 I2C 写入即可覆盖 READY 并绘制完整大字手势名称，计时结束后再补充延迟文本。该改动使响应时间从早期约 235～240 ms 降至约 176 ms。

六、模型训练与测试方法

为了避免只在训练数据上得到较高准确率、但实际重新佩戴后性能下降，本项目将训练与最终测试严格分开。

1. 训练数据采集

最终 TRAIN 数据共采集 90 组，其中：

• WAVE：30 组；
• ROTATE：30 组；
• TAP：30 组。

数据采集过程中有意加入了动作变化，而不是只重复一种固定姿势。例如 WAVE 包含正常速度、快速、慢速、不同幅度及轻微倾斜姿态；ROTATE 包含水平、竖直、斜向及自然姿态下的旋转；TAP 则包含不同力度以及桌面、倾斜面等不同支撑表面。

这样设计的目的是让模型学习各类动作的动态变化特征，而不是依赖传感器某一次佩戴时的固定姿态。

2. 独立测试方法

完成训练数据采集后，重新佩戴 MPU6050，并单独采集一组不参与训练的 TEST 数据，用于最终准确率测试。

独立 TEST 共 30 组，WAVE、ROTATE、TAP 各 10 组。测试中同样包含正常、快、慢以及不同手臂方向或敲击方式等情况。

测试过程中，模型参数保持冻结，不再根据 TEST 数据重新调整网络结构或权重。每组数据独立输入最终 Tiny MLP，记录其预测类别，再与实际动作标签进行比较。

这种方法能够比直接在训练数据上统计准确率更真实地反映模型在重新佩戴传感器和动作存在一定变化时的识别能力。

3. 独立测试结果

最终测试结果如下：

30 组独立测试数据中共正确识别 29 组，总体准确率为 96.7%。唯一的错误样本为一次慢速 ROTATE，被模型判断为 WAVE。原报告中现有的混淆矩阵即来自这组独立 TEST。

这一结果达到任务要求的识别准确率指标，也说明加入不同速度、姿态和使用条件的数据后，模型相比早期只针对固定动作采集的数据具有更好的泛化能力。

图 6 Python 端训练与独立测试可视化，包含混淆矩阵。

4. 实机响应时间测试

除了离线准确率外，本项目还在 MAX32655FTHR 实机上测试了完整识别链路的响应时间。

程序使用 MAX32655 的硬件定时器 TMR0 进行计时：

1. 系统处于 READY 状态并持续读取 MPU6050；
2. 当传感器数据超过动作触发阈值时，记录 TMR0 起始计数；
3. 继续完成短时间窗采样；
4. 构造 72 维输入特征并完成标准化；
5. 在 MAX32655 上执行 Tiny MLP 前向推理；
6. 将最终 WAVE、ROTATE 或 TAP 结果写入 OLED；
7. OLED 完整显示手势名称后记录结束计数。

因此，本项目所说的“响应时间”特指：

MCU 判定动作已经触发 → OLED 完整显示识别类别

而不是从肉眼观察到手刚开始发生微小运动的时刻起算。

早期程序由于 OLED 需要整屏清除并重新绘制，完整链路延迟约为 235～240 ms。之后将显示过程优化为固定区域定长写入，并使用 TMR0 进行稳定计时，最终实机测试时响应时间稳定在约 176 ms，低于任务要求的 200 ms。原报告记录的优化过程及计时定义与此一致。

七、实物演示及测试过程

最终实物由 MAX32655FTHR、MPU6050 六轴惯性传感器和 0.96 英寸 OLED 构成。MPU6050 固定在手部靠近中指根部的位置，开发板和 OLED 通过杜邦线连接。设备上电并完成初始化后，OLED 显示 READY，随后即可进行手势识别。

图 7 MPU6050 模块及固定方式。

1. 实物测试流程

每次实物测试按照以下过程进行：

1. 给 MAX32655FTHR 上电，等待系统进入 READY 状态；
2. 保持正常佩戴方式执行 WAVE、ROTATE 或 TAP；
3. MPU6050 连续采集三轴加速度和三轴角速度；
4. 程序检测到动作触发后自动截取短时间窗；
5. MAX32655FTHR 在本地完成特征处理和 Tiny MLP 推理；
6. OLED 显示最终识别类别及响应时间；
7. 系统重新返回待识别状态，继续进行下一次测试。

整个识别过程均直接运行在 MAX32655FTHR 上。

2. 三类手势演示

实物测试分别验证以下三类动作：

• WAVE：自然进行左右挥手；
• ROTATE：以前臂方向为轴旋转手部并返回；
• TAP：手指在桌面或其他支撑表面完成敲击动作。

测试时 OLED 能够在动作触发后直接显示相应的 WAVE、ROTATE 或 TAP。实机识别与独立 TEST 的结果相符，在正常定义的动作范围内三类手势能够较稳定地区分。

图 8 ROTATE 手势识别实物演示。画面中可同时看到手部传感器、MAX32655FTHR 和 OLED 结果。

3. 测试结果说明

结合独立数据集测试和实机演示，本项目最终达到以下结果：

需要说明的是，目前作品仍属于模块化原型。MPU6050 与 OLED 共用 I2C2，并使用杜邦线连接；当动作幅度过大、明显拉扯线材时，偶尔可能造成 OLED 或 I2C 状态异常，需要复位重新初始化。正常演示动作范围内系统通信较稳定，不影响任务功能验证。

八、遇到的难点及解决方法

难点 1：离线高准确率不等于实机可用

早期使用较长窗口和决策树时，离线测试曾得到很高的准确率，但部分特征实际上利用了静态姿态差异，重新佩戴或改变姿态后泛化能力明显下降。进一步缩短窗口后，第一版依赖首尾差值的规则在 MCU 实机上甚至出现约 42% 的低准确率。

解决方法： 不再只围绕某一固定佩戴姿态采数据，而是重新设计动作定义与数据集，主动加入快慢、幅度、前臂方向、敲击表面等变化，并使用 baseline-relative 动态特征。最终采用 Tiny MLP，将多轴、多时间点信息联合建模，独立 re-wear TEST 达到 96.7%。

难点 2：如何把“Python 里的神经网络”真正部署到 MCU

最初神经网络对于项目而言仍像一个黑盒。训练完成后，如果 MCU 还依赖 Python 或大型运行时，就失去了本地边缘部署的意义。

解决方法： 将 StandardScaler 的 mean/scale、两层网络 W1/b1/W2/b2 全部导出为 C 常量数组，在 main.c 中手工实现与 Python 一致的标准化、矩阵乘加、ReLU 和 argmax。这样 MCU 上的所谓“AI 推理”最终就是有限数量的浮点乘加运算，模型约 5.32 KiB，不需要云端服务。

难点 3：响应时间超出 200 ms

早期 9 点短窗 + OLED 完整刷新时，触发到显示约 235～240 ms，主要耗时并非 MLP，而是后触发采样等待和 OLED I2C 传输。

解决方法： 使用 TMR0 明确定义和测量触发到 OLED 的链路；同时把 OLED 的 timed path 改为固定结果区域的定长写入，不在计时路径中整屏清屏和二次重绘。最终稳定约 176 ms。

难点 4：计时工具本身失效

DWT 周期计数器版本出现 OLED 恒显示 0 ms，说明计时方式在当前运行环境中并未实际工作。

解决方法： 改用 MSDK 官方 TMR 驱动配置 TMR0，并加入约 100 ms 延时自检，确认硬件定时器计数正确后再用于正式测量。

难点 5：共享 I2C 与原型连接的稳定性

MPU6050 与 OLED 共用 I2C2，且采用较长杜邦线和手部可动传感器。偶发大动作时可能出现 E_BUSY/E_BAD_STATE 或 OLED 状态异常。

解决方法： 在驱动层加入有限次数重试并尽量减少计时关键路径中的 I2C 操作。当前比赛原型在正常动作范围内通信较稳定；后续仍应加入 SCL 脉冲总线恢复、外设软复位和更可靠的硬件连接。

九、对本次活动的心得体会

这次项目最大的收获不是单独学会某一个 API，而是第一次把“传感器数据采集、数据集设计、模型训练、嵌入式部署、实机验证和延迟优化”串成了一条完整链路。尤其是在模型从离线结果到真实 MCU 部署的过程中，我体会到数据分布和测试方法往往比单纯更换算法更重要：如果训练数据只覆盖固定姿态，模型即使离线准确率很高，也可能在重新佩戴后迅速失效；真正有意义的准确率需要独立测试数据来验证。

同时，这次项目也让我更具体地理解了神经网络在 MCU 上的形态。训练好的 Tiny MLP 并不是一个神秘的“大模型文件”，最终只是标准化参数、权重和偏置；本地推理则是一系列可见的乘法、加法、ReLU 与比较操作。这种从 Python 到 C 的转化让我对边缘 AI 的工程实现有了更直观的认识。

CodeFusion Studio 在工程配置、代码组织、编译下载和 MAX32655 外设开发中提供了统一环境。对于初次接触 MAX32655 的使用者，如果活动后续能够提供更多 TinyML、本地传感器推理、TMR/DMA 等典型示例，以及更明确的响应时间测量口径，会更有利于参赛者把重点放在算法与系统设计上。同时也建议提供一个 I2C 超时/总线恢复的官方示例，帮助处理原型阶段常见的外设异常。

总体而言，本项目已经完成了从想法到可运行作品的闭环：三类手势能够在 MAX32655FTHR 上独立识别，独立测试准确率达到 96.7%，实机触发到 OLED 完整结果显示约 176 ms。虽然当前仍是面包板与杜邦线原型，但它已经证明了轻量神经网络在资源受限 MCU 上进行实时惯性手势识别的可行性。