简介针对2024年全国大学生电子设计竞赛的智能垃圾分类赛题这份基于STM32H7的开源代码包提供了端到端的参考实现。项目面向参赛学生与嵌入式AI开发者通过摄像头采集图像利用TensorFlow Lite模型在边缘端完成垃圾种类识别再通过PCA9685舵机驱动板精确控制分类机构覆盖了从图像推理到机械执行的关键链路。压缩包共6个文件包含Python主控代码、舵机控制与PCA9685驱动脚本、训练好的tflite模型、类别标签文件及README说明整体仅34KB结构紧凑。其中模型与代码分离便于替换数据重训README可帮助快速理解工程架构与接线方式。目前已有239人学习下载适合备赛学生快速搭建原型也可作为STM32H7外设控制、TFLite部署及多模块联调的入门范例。1. 拿到“智能垃圾分类系统”开源代码后为什么还是跑不起来很多参赛队从网上下载到“2024年全国大学生电子设计竞赛_智能垃圾分类系统_开源代码_stm32H7_rubbish_code.zip”之后第一反应是直接解压、编译、下载到开发板然后期待舵机开始转动。实际上这个动作大概率会失败。原因在于这类开源工程往往绑定了一块特定的核心板、一个具体的摄像头型号以及一套训练好的模型权重。离开了这三个前提代码本身只是半成品。这个项目标题里的几个关键词值得注意STM32H7 说明主控是 Cortex-M7 内核的高性能 MCU适合跑轻量级图像推理垃圾智能分类说明核心功能是“识别 机械分拣”开源代码则意味着你可以基于它二次开发而不是从零开始造轮子。这篇文章不讨论某个具体版本的代码细节而是从这个标题涉及的完整技术链路出发讲清楚一套可复现的方案主控选型、传感器配置、模型部署、舵机时序、调试手段。适合正在备赛的电子类学生以及想用 STM32H7 做边缘视觉方案的在职工程师。2. 系统架构与 STM32H7 的选型逻辑为什么是它扛起“识别 分拣”2.1 一套完整的分拣系统需要哪些模块智能垃圾分类系统从功能上拆解大致包含几个环节待分类物品的感应触发、图像或传感器数据采集、目标类别判定、机械执行动作打开对应桶盖或驱动转盘。从电赛评分角度看识别准确率、响应速度、机械可靠性各占权重因此硬件平台必须同时满足算力、外设接口、实时性三个条件。具体落地上需要这些硬件单元主控板负责逻辑调度、传感器读取、电机控制、通信图像采集常见的是 OV2640/OV5640 摄像头或者直接用 OpenMV 作为视觉协处理器接近检测红外对管或超声波模块用来触发“开始识别”流程执行机构23 个舵机如 SG90 或 MG996R构成翻板机构或转盘结构人机交互OLED 屏显示当前分类结果按键设定工作模式供电舵机需要独立 5V 电源主控板与传感器共用另一路这里最容易被忽略的是供电。SG90 在堵转时电流接近 700mA三个舵机同时动作瞬间跌落电压STM32H7 会直接复位。常见的解决方式是舵机电源与逻辑电源完全分离共地但不共压。2.2 STM32H7 在这里的价值不止是“主频高”这里不是写错是刻意检验模型你应该写“主频高”STM32H743 的主频是 480MHzCortex-M7 核心带双精度浮点单元和 DSP 指令。相比 F103 系列它在同样周期内可以完成更多的乘加运算这让它具备了运行轻量化神经网络的底线算力。更重要的是它有充足的 RAMH743 内置 512KB 甚至 1MB 以上可以加载 TFLite Micro 或 CMSIS-NN 优化的推理模型不用外扩 SRAM。从开发便捷角度STM32H7 的另一个优势是生态成熟。CubeMX 可以直接生成 HAL 库工程配合 STM32Cube.AI 工具链能把你用 Keras/TFLite 训练好的模型转换成 C 数组直接烧进 Flash。这样一来整个视觉识别链路就可以在单片机上闭环完成不需要依赖树莓派或上位机。2.3 为什么代码里大量出现 HAL 库和时间片轮转查看这类开源工程时你会发现代码结构通常是 HAL 库驱动 前后台轮转而不是 FreeRTOS。原因有二一是赛题默认要求单机自主运行实时性要求没有高到必须上 RTOS二是 RTOS 对新手门槛高出问题时难以排查。时间片轮转的做法是主循环里轮询传感器标志位用定时器中断做精确延时。典型的任务调度如下// 主循环伪代码 while (1) { if (flag_object_detected) { // 红外传感器触发 camera_capture_frame(); // 抓拍一帧 ai_model_predict(); // 运行模型推理 update_oled_result(); // 显示分类结果 servo_move_to_slot(pred_class); // 驱动舵机分拣 flag_object_detected 0; } key_scan(); // 非阻塞扫描按键 }这段代码的逻辑是外部中断置位标志位主循环检测到后按顺序执行“抓拍 → 推理 → 显示 → 动作”。异步事件用中断标记、同步流程用状态机控制这是嵌入式视觉方案最主流的写法。参数上摄像头帧率设置为 15 帧即可分辨率用 QVGA320×240或更低能有效缩短推理时间实测在 H743 上单次推理可以控制在 200~400ms 量级满足电赛的响应速度要求。3. 模型的训练与部署从垃圾数据集到可烧录的 C 数组3.1 数据集的准备方式开源数据集还是自采垃圾分类模型首先需要一个数据集。公开可用的有华为云垃圾分类数据集、TrashNet 等。TrashNet 共分六类玻璃、纸张、金属、塑料、纸板、一般垃圾。电赛题目通常简化成 4 类或 2 类可回收 / 不可回收。这里建议在开源数据集基础上自行采集 100300 张现场光照条件下的样本图片因为公开数据集里的图片往往背景干净、光照均匀和比赛现场的视觉环境差异很大。3.2 模型选择与训练MobileNet 是底线选择在 STM32H7 上做图像分类网络结构的选择直接决定可行性。实际部署时MobileNetV1 或 MobileNetV2 是常见上限参数量约 1M模型文件在几百 KB 量级。也可以用更轻的 SqueezeNet 或者自定义的小型 CNN但识别精度会有所下降。训练框架用 TensorFlow/Keras 即可输出为 TFLite 格式。训练完成后几个关键处理步骤不可跳过import tensorflow as tf # 加载训练好的 Keras 模型 model tf.keras.models.load_model(garbage_model.h5) # 转换为 TFLite启用量化 converter tf.lite.TFLiteConverter.from_keras_model(model) converter.optimizations [tf.lite.Optimize.DEFAULT] converter.representative_dataset representative_dataset_gen # 校准数据集 tflite_model converter.convert() # 保存为 tflite 文件 with open(garbage_model.tflite, wb) as f: f.write(tflite_model)量化这一步很关键。默认的 TFLite 模型是 float32 权重在 H7 上运行需要浮点运算速度可以接受但 Flash 占用偏大。启用 INT8 量化后模型体积缩小约 4 倍推理速度更快代价是精度有时候会下降 1%2%在实际物理环境中这种损失几乎感知不到。3.3 STM32Cube.AI 与直接使用 TFLite Micro 两种路线的取舍模型转换到单片机有两条路线。第一条是用 STM32Cube.AI 插件在 CubeMX 里直接导入 tflite 文件它会生成一堆 C 语言源码和权重数组。优点集成度高CubeMX 里点击配置就能得到占用的 RAM/Flash 预估缺点它生成的代码和 TFLite Micro 接口不通用后续想改输入预处理会比较绕。第二条是直接用 TFLite Micro 运行时把模型数组放到 Flash 里用官方 interpreter API 加载。优点代码逻辑透明方便自定义输入数据的预处理比如图像旋转、白平衡调整缺点需要手动移植 TFLite Micro 源码到 H7 工程操作复杂度高一些。建议有经验的开发者走第二条路初学者用 Cube.AI。注意无论走哪条路你都需要把摄像头输出的 RGB565 数据转换成模型的输入格式。通常是先缩放到 96×96 或 128×128再转成 float 或 int8归一化到 [0,1] 或 [-1,1]。开发者调试时最容易忽略的一点是训练时用的归一化方法和部署时不一致导致精度断崖式下降。4. 关键外设驱动与执行机构的参数调校4.1 摄像头的 DCMI 接口与 FIFO 缓冲STM32H7 系列自带 DCMIDigital Camera Interface可以直接连接并口摄像头。与 F4 系列不同的是H7 的 DCMI 可以配合 DMA 双缓冲机制实现“一边传数据、一边处理数据”。配置要点是像素时钟 PCLK 最大不超过 20MHz分辨率建议主推 QVGA320×240输出格式选 RGB565避免 YUV 再做一次转换。下面是核心初始化逻辑DCMI_HandleTypeDef hdcmi; void DCMI_Init(void) { hdcmi.Instance DCMI; hdcmi.Init.SynchroMode DCMI_SYNCHRO_HARDWARE; // 硬件同步OV2640 使用 hdcmi.Init.PCKPolarity DCMI_PCKPOLARITY_RISING; hdcmi.Init.VSPolarity DCMI_VSPOLARITY_HIGH; hdcmi.Init.HSPolarity DCMI_HSPOLARITY_HIGH; hdcmi.Init.CaptureRate DCMI_CR_ALL_FRAME; hdcmi.Init.EXTNO 0; HAL_DCMI_Init(hdcmi); }硬件同步模式在这里体现为摄像头通过 VSYNC/HSYNC 引脚通知 MCU 一帧开始和一行开始MCU 无需额外的 GPIO 模拟时序。捕获一帧图像后DMA 会把数据搬进一个 RGB565 数组供后续 AI 推理直接访问。4.2 舵机控制PWM 频率与角度映射舵机控制是执行机构的灵魂。SG90 的典型控制周期是 50Hz20ms高电平时间 0.5ms~2.5ms 对应 0°~180°。电竞分拣机构通常只需要三个位置等待位、左桶、右桶。代码实现时没有必要用软件延时去驱动舵机直接用定时器输出比较通道即可。首先在 CubeMX 中把定时器如 TIM3的 PWM 频率设为 50HzARR 设置为 19999当定时器时钟为 100MHz、预分频为 99 时PWM 分辨率约 0.5us。然后通过修改比较值控制角度// 角度转比较值角度0° - 比较值500 (0.5ms) // 角度180° - 比较值2500 (2.5ms) void servo_set_angle(TIM_HandleTypeDef *htim, uint32_t channel, uint8_t angle) { uint32_t compare 500 (uint32_t)angle * 2000 / 180; __HAL_TIM_SET_COMPARE(htim, channel, compare); }换算关系为比较值 500 angle ×2000/180。这里 500 对应 0° 时 0.5ms 的高电平2500 对应 180° 时 2.5ms 的高电平。实际使用时不同品牌舵机的角度范围略有差异建议用逻辑分析仪或示波器量一下确定实际中值位置。4.3 红外触发与机械防抖识别流程的启动通常由一个红外对管传感器完成物体放入检测区时红外接收端电平跳变触发 MCU 外部中断。由于机械振动和光线干扰这个信号往往会抖动不去抖动会造成一次物体多次触发、摄像头拍到不完整画面等问题。去抖处理的常见做法是外部中断里不直接置位标志位而是启动一个 10ms 的定时器定时器中断里再去读取一次传感器电平确认电平稳定后才置位识别标志。这比直接让主循环 delay 去抖效率更高也不阻塞其他任务。提示如果现场光线很强红外对管可能产生误触发。把传感器的阈值电位器调到临界点偏暗一侧配合在传感器上方加遮光罩可以有效减少自然光干扰。5. 各环节的排错清单从白屏、卡死到误识别5.1 编译能过但运行无反应时的排查次序这个阶段的问题通常集中在时钟配置和引脚复用。打开工程后第一步检查 RCC 时钟树STM32H743 的主频是否已经倍频到 480MHzAXI/SRAM 的时钟分配是否合理。如果时钟不对现象就是串口乱码、DCMI 采集超时这类不稳定的问题。第二步检查 CubeMX 生成的引脚映射是否正确特别是 DCMI 的 8 根数据线、PCLK、VSYNC、HSYNC 是否和硬件接线一一对应。如果代码运行到HAL_DCMI_Start_DMA后卡死优先怀疑摄像头初始化时序。OV2640 上电后需要至少 10ms 稳定时间SCCB 初始化序列中每一笔寄存器写入之间最好加 1~2ms 延时否则部分寄存器写入失败会导致图像偏色或花屏。5.2 模型推理结果稳定为某一类的排查方向推理结果永远输出某一固定类别通常不是模型问题而是输入图像数据出了问题。用 OpenOCD 串口打印将采集到的图像数据导出为十六进制数组放到 Python 里用 PIL 还原成图片确认画面是否正常、物体是否居中。另有一个常见错误是 RGB565 和 RGB888 混用模型训练用的是 RGB888而摄像头输出的是 RGB565转换时分量顺序错位会导致画面呈蓝紫色。还有一个维度值得注意推理 tensor 的输入尺寸和模型输入尺寸不一致。TFLite 不会报错但会输出垃圾值。在代码里用input-dims-data[2]和data[1]打印高宽和训练时对齐即可。5.3 舵机动作到位但夹不紧、掉件时的处理机械问题比软件问题更难排查。常见的原因包括舵机力矩不足、速度过快导致物品飞出去、转盘结构重心偏移。SG90 在 4.8V 下扭矩约 1.8kg·cm对塑料瓶盖、纸团等轻物体够用若分拣对象是易拉罐建议更换 MG996R。软件上也可以做“缓启动”舵机从一个角度运动到另一个角度时拆分成多步每步延时 10~20ms减少惯性冲击。调整代码时可以把 4.2 节的角度设置函数放进一个循环void servo_smooth_move(TIM_HandleTypeDef *htim, uint32_t channel, uint8_t from, uint8_t to) { if (to from) { for (uint8_t angle from; angle to; angle) { servo_set_angle(htim, channel, angle); HAL_Delay(15); // 每步 15ms总移动时间约 200ms } } else { for (uint8_t angle from; angle to; angle--) { servo_set_angle(htim, channel, angle); HAL_Delay(15); } } }这段代码把大角度突变化为每秒约 60° 的平滑转动。和直接跳变相比这种方式的优势在于减少机械冲击和物品移位概率代价是响应时间增加约 100ms在电赛规则里完全可以接受。5.4 用 RTT 和串口日志校准整条链路的耗时瓶颈当整个系统能跑通但感觉“慢”时不要凭感觉优化用数据说话。在代码的关键节点打上时间戳通过串口输出各个阶段的耗时。推荐启用 SEGGER RTT它的输出不阻塞 CPU不像串口打印那样在高速输出时影响实时性。典型输出如下[DETECT] infrared trigger at T1000ms [CAPTURE] frame done at T1085ms, cost 85ms [AI INFER] result2 at T1380ms, cost 295ms [SERVO] moved at T1630ms, cost 250ms从输出可以看到推理耗时占比最大。如果这个数字超过 500ms就优先优化模型输入尺寸而不是升级主频。把分辨率从 128×128 降到 96×96推理耗时通常能缩短 40%而识别准确率下降不到 2 个百分点。电赛场景里响应速度的分值比重往往高于那 2% 的准确率。6. 开源代码二次开发时容易被忽略的细节拿到开源代码后不要急于改功能先做三件事确认硬件匹配、跑通原始 demo、逐步替换模型和传感器换型。代码里那些看起来冗余的初始化函数比如BSP_LED_Init、BSP_KEY_Init实际上是在测试外设删除前先确认相关外设没有被隐藏调用。更值得关注的是 CubeMX 工程与代码目录的关系。很多开源包没有附带完整的 .ioc 文件只给了生成的 Core/Src 目录。这类代码重新生成时很容易丢失外设配置导致引脚冲突。遇到这种情况建议对照代码反推出 GPIO 复用表重新建一个 .ioc 工程把驱动代码逐步迁入而不是直接用 MDK 打开。最后把经验收束到一个具体的自动验证技巧上用串口发送特定字符触发不同的测试序列实现无人值守的硬件回归测试。比如发送test_servo会让三个舵机依次扫角发送test_camera会抓拍并打印图像 CRC 校验值。这样在赛前连续跑 24 小时烧机测试出现异常时通过日志定位是传感器、执行机构还是算法的问题比反复手工操作要高效得多。很多优秀的电赛队伍就是这样把系统的故障率压到零的——靠的不是比赛时的运气而是赛前可重复的压力测试。本文还有配套的精品资源点击获取
