基于RT-Thread的工业质检AI：嵌入式模型部署与产线落地

1. 从命题看工业质检AI的底层逻辑1.1 为什么是 RT-Thread 来出这道题最近 RT-Thread 把今年的命题方向定在了工业质检 AI 上口号是“每个开发者都能做”。说实话看到这个命题我第一反应不是“哦又有比赛”而是“这个方向终于到了该让更多人来玩的时候了”。工业质检 AI 说白了就是给产线上的产品找毛病划痕、脏污、缺料、焊点不良、外观变形……过去这些活主要靠人眼后来被大厂用 GPU 服务器加深度学习模型接管成本很高一套系统动辄几十万而且很多方案是集成商垄断的。现在 RT-Thread 把这个方向做成开源生态里的命题意味着一块巴掌大的开发板也能把“图像采集、模型推理、结果判定、现场联动”的质检流程完整跑起来。为什么偏偏是 RT-Thread因为它本身定位就不只是普通 RTOS。RT-Thread 既能在 Cortex-M 这类 MCU 上跑小资源系统也能通过 RT-Thread Smart 走向带 MMU 的处理器甚至适配多核芯片。工业质检恰恰是一个跨 MCU 和 MPU 的典型场景低端产品只需要做 OK/NG 二分类一颗高主频 MCU 就够了复杂缺陷定位要跑目标检测则得靠带 NPU 的 MPU。RT-Thread 想通过这个命题告诉大家端侧 AI 并不是 Linux 的专利RTOS 同样能承担一部分推理任务而且实时性、稳定性、启动速度可能更合适。这个命题对工业视觉行业也有明显冲击。传统的视觉检测系统里算法工程师、嵌入式工程师、电气工程师各管一段沟通成本极高。RT-Thread 的生态里一个开发者可以同时碰驱动、任务调度、模型部署和业务逻辑等于把过去一条需要三四个人的流水线压缩到一个人手里。我接触过不少做视觉集成的朋友他们最大的痛点不是算法精度而是从服务器模型到工业相机再到 PLC 打通的这条链路太长。RT-Thread 出这道题就是想把这个链路文档化、工具化、门槛化。1.2 “每个开发者都能做”到底意味着什么门槛很多人看到“AI 质检”会本能退缩觉得自己算法底子不行。我个人的理解是这个命题要的并不是发明新算法而是具备工程化落地能力。你可以不会手写卷积、不会反向传播只需要能跑熟一个开源检测模型把它导成 RT-Thread 能用的格式再写好预处理、后处理和 IO 联动就已经能交付一个最小可用系统。这就像现在造车不再要求你自己造发动机而是把成熟动力总成装进车架再调好电控和底盘。当然该有的基本功还是绕不过去。嵌入式这边至少得知道怎么建工程、配驱动、用信号量和消息队列出问题时能看日志、能调试算法这边要理解分类和检测的区别知道 INT8 量化后精度可能下降懂得用 ROC 曲线挑阈值。这些都不是硬门槛拿官方 demo 跑一遍基本就能建立信心。但工业质检不是一个纯技术问题它还有一些业务指标需要提前建立概念。比如 OK/NG 判断里的漏检率和误检率漏检是把坏产品放走问题最严重误检是好的产品被拦下来会让产线频繁停机工人也会开始怀疑系统。再比如节拍也就是单个产品允许的检测时间汽车零部件件检测可能卡在 500 毫秒以内手机盖板外观检测可能只有 200 毫秒。这些参数比 mAP 更影响方案选型因为很多通用模型在电脑上精度不错一放到嵌入式设备上就可能超时。2. 一套可落地的工业质检AI方案怎么搭2.1 系统架构先想清楚数据流、任务流、异常流我见过很多人在拿到板子后第一件事就是跑模型结果模型是跑起来了摄像头数据进不来或者外面的剔废气缸压根不会动。做工业质检的第一原则应该是先画数据流再写代码。你可以不太正规地在纸上画几条线工业相机或 RGB 摄像头产生图像经过缓存队列送到预处理模块转换成模型输入的尺寸和通道格式再交给推理线程推理结果出来后经过阈值判断或 NMS 后处理输出到三个方向一是 GPIO 控制继电器或气缸二是串口或网口上报结果三是 LCD 显示给现场工人看。任务流上用 RT-Thread 的线程模型来拆会比较顺手。采集线程负责等帧和拷贝图像推理线程从消息队列里拿帧做处理和预测控制线程负责动作执行显示线程负责界面刷新。线程之间用消息队列和解耦能有效避免图像采集卡顿时整个系统全堵住。我自己习惯的做法是给每个队列定好容量上限比如缓存 3 帧就丢弃老帧而不是无限堆积。工业现场最怕的是掉一只旧产品后面所有产品的检测结果都错位。异常流往往被新手忽略但它在产线上非常重要。掉帧要怎么处理推理超时要怎么办模型输出置信度普遍很低是否要报警这些都应该写进代码而不是靠现场人员盯屏幕。我建议至少加一个软件看门狗线程周期性检查推理线程的“心跳”超过设定时间没更新就重启相关外设或拉高报警 IO。很多嵌入式设备在实验室里跑一个月都不死一到工厂里受电源波动和电磁干扰影响各种怪问题全冒出来异常流设计几乎是救命的。2.2 模型选型分类、检测还是分割以及对应的轻量模型模型选型先看任务是什么。如果只需要判断“这个产品有没有缺陷”典型方案是图像分类模型可以选择 MobileNet 系列、EfficientNet-Lite、GhostNet。这类模型参数少在几十兆主频的 MCU 上也有可能跑起来适合大批量、简单缺陷、检测速度快但不需要定位的场景。如果还要输出缺陷在图像里的位置那就要上目标检测常见的有 YOLO-Fastest、PicoDet、Tiny-YOLO 这类轻量检测网络。检测模型通常需要更大的内存和算力更适合带 NPU 的 MPU 平台不过新出的边缘 NPU 已经把功耗压得很低。还有一类需求是测缺陷面积和形态比如划痕宽度、脏污占比光靠检测框不够需要语义分割。分割模型在嵌入式端相对冷门因为计算量通常很大但 STDC、ESNet 这类轻量分割网络在一些带 NPU 的平台上也能达到实时。选型时不要只看精度排行榜更要考虑部署工具链支不支持。我踩过最大的坑就是从一个开源仓库里挑了个很新的检测模型训练完发现边缘平台上的编译器不支持其中某个算子改模型结构、换导出方式折腾了一周最后换回经典老模型半天就部署完成。可以按下面这张表快速定位方向质检需求目标形式推荐模型方向适合平台产品整体OK/NG判断类别标签MobileNetV1/V2、GhostNet高主频MCU、入门MPU缺陷定位并框出目标框YOLO-Fastest、PicoDet带NPU的MPU缺陷形状/面积测量像素掩膜STDC、ESNet带NPU的中高性能平台多类型细粒度分类类别标签EfficientNet-Lite内存较大的MPU或Linux平台选择的时候还要想清楚输入分辨率工业质检不一定要用 640x640 的大图。大图会显著拉长预处理和推理时间而且在很多场景下缺陷本身只占图像很小区域盲目缩小图又会导致漏检。我的经验是先确认相机视野里产品实际占多少像素再反推模型输入尺寸尽量让缺陷关键特征在输入图上仍能被辨认出来而不是只追求大分辨率。3. 在 RT-Thread 上一步步跑通质检 Demo3.1 环境准备与工程创建如果你用的是官方生态最省事的方式是安装 RT-Thread Studio打开后用板卡 BSP 创建工程。我试过在潘多拉、正点原子、柿饼派这些常用开发板上跑通基础图像采集也在带 NPU 的嵌入式 Linux 板子上通过 RT-Thread 应用层做模型调度。刚开始最容易犯的错误是一下子勾选太多组件导致编译过不了、内存爆炸。建议最小化起步先只保留 RT-Thread 内核、摄像头驱动、串口驱动、显示驱动四类组件。摄像头驱动的选择要特别上心。大部分 MCU 开发板用的是 DCMI 接口摄像头或者 SPI 接口摄像头在 Studio 组件包里能找到现成驱动。MPU 平台往往有 CSI 接口情况会复杂一些可能需要按设备树配置引脚和时钟。这里有一个判断技巧先看板卡 SDK 里有没有摄像头测试例程没有的话说明这个板子的摄像头生态还不成熟后面要花大量时间移植驱动反而拖累 AI 主线的进度。做这个命题选一块摄像头能即插即用的板子效果会好很多。工程创建完之后我强烈建议先做一个最基础的“摄像头出图测试”用 LCD 连续刷新摄像头画面。这步看起来幼稚但能提前暴露很多问题图像是否偏色、是否倒置、刷新率是否够用、DMA 是否稳定。把这些解决干净再往工程里加 AI 模型推理后面排查会省很多力气。3.2 图像采集、预处理与显示图像采集的流程大概是申请帧缓冲等待帧完成信号然后把图像数据交给后续模块。RT-Thread 里可以借助消息队列传递帧地址采集线程只负责把最新的帧地址塞进队列推理线程从队列里取。要注意帧缓冲区通常是 DMA 的产物读写时会碰到内存一致性问题特别是在 Cortex-A 平台上搬运缓存区数据时要做 cache clean 或 invalidate 操作否则会出现花屏、半帧、数据错乱这类诡异现象。预处理是埋坑最多的地方。第一个坑是像素格式。摄像头输出往往是 RGB565模型输入又经常需要 RGB888转换时不能用系统库浮点慢慢算直接在 C 里做位运算查表即可。第二个坑是缩放方式。嵌入端比较推荐 box filter、最近邻这类轻量缩放虽然画面有点锯齿但对模型精度的影响通常小于预期而且速度快很多。第三个坑是归一化。训练时如果用的是 RGB 顺序加 0~1 归一化部署时也要严格保持一致很多模型推理结果乱跳八成是反了通道或者忘了归一化。下面是推理线程里常见的一段核心代码我在不同平台上反复用过类似结构static void inference_entry(void *param) { camera_frame_t *frame NULL; while (1) { rt_mq_recv(frame_queue, frame, sizeof(frame), RT_WAITING_FOREVER); preprocess(frame-buf, input_buf, IMG_W, IMG_H); model_predict(input_buf, result); if (result.score ng_threshold) { rt_pin_write(OUTPUT_IO_PIN, PIN_HIGH); // 触发剔除机构 } report_result(result); // 串口/网络上报 lvgl_draw_result(result); // 屏幕显示 } }显示方面如果你用 LVGL画一个矩形框加一个文本标签就够了不要在这上面浪费太多时间。对现场操作员来说界面上最需要的是“NG”或“OK”的大字反馈以及当前产品的编号或置信度。如果产品一直被拦截他们需要从屏幕上立刻能看出哪里出了问题而不是看到一个黑框。3.3 把模型推理接进质检业务流程算法跑通只算完成三分之一真正的工业质检系统必须把“AI 结果”变成“物理动作”。最直接的做法是把一个 GPIO 引脚配置成输出当检测结果为 NG 时拉高或者拉低再驱动继电器、气缸或报警灯。如果要与 PLC 联动串口协议里可以固定每秒发送一次结果帧用简单帧头校验保证可靠性。更完整的方案可以走 Modbus TCP 或 MQTT但这些更适合放在“边缘网关”层核心检测设备保持轻量。这里我强烈建议用一个状态机来组织业务而不是每个线程各干各的。简易状态机可以这么拆IDLE 状态等待触发信号CAPTURING 状态接收图像INFERENCE 状态运行模型REPORT 状态输出结果并执行动作CLEAR 状态清理缓冲区回到 IDLE。这样一套流程对应一个产品的完整质检周期出现异常时能明确知道卡在哪个环节。节拍控制是另一个容易被忽视的点。有些产线要求一个产品从进到出必须在 300 毫秒内完成检测那从曝光到气缸动作之间的每一步都要算时间预算。最简单的办法是在推理线程里用rt_tick_get()记录各阶段耗时通过串口打印出来。实测我见过一个项目推理只花 80 毫秒但串口打印加 LCD 刷新占了 120 毫秒白白拖慢产能后来把显示频率降到每三帧刷新一次节拍才压下去。4. 实测性能与真实场景效果4.1 三个平台的实测数据对比为了做这个方向很多朋友会纠结“到底选哪块板子”。我把手上不同档位的平台拉出来跑过一轮这里给出一组参考数据。需要说明数值受开发板型号、工具链版本、模型算子实现影响很大不要把它当成绝对性能指标但可以用它建立选型直觉。平台任务模型输入尺寸量化方式模型体积推理耗时说明高主频MCUCortex-M7480MHz缺陷分类MobileNetV1-0.596x96INT8约280KB250~320ms适合简单OK/NG判断入门MPUNPURV1126缺陷检测YOLO-Fastest320x320INT8约3.5MB35~50msNPU推理快整体80~120ms中高性能MPUi.MX 8M Plus缺陷检测PicoDet416x416INT8约5MB90~130ms内存充裕可接多路相机如果你的检测节拍比较宽松比如 500 毫秒一个产品那么一块高主频 MCU 做简单分类完全能顶得住成本可以压到几十块钱级别。但如果存在多种缺陷类型且分布位置不固定还是直接上带 NPU 的 MPU 更稳妥因为它有充足资源跑检测模型同时还能并跑采集、通信和显示任务。功耗也是工业现场很在意的指标。MCU 方案整体功耗一般在 1W 以内很容易用 POE 或者普通工业电源带起来MPUNPU 方案大概在 3~8W 之间部署时最好选带隔离的宽压电源模块。实际项目中电源不稳定导致的模型推理偶发失败比想象中常见不要省这块成本。4.2 玻璃盖板划痕检测的完整案例拿一个我自己跟过的场景举例手机玻璃盖板外观检测主要是找出划痕、气泡、脏污和崩边。这个场景比较典型因为玻璃反光严重对打光要求极高而且缺陷可能很细微。项目期望是单件检测时间不超过 500 毫秒漏检率尽量低于 1%误检率控制在 3% 以内。数据这块现场采集了一千张正常图和五百张缺陷图数量并不算多。通过旋转、翻转、亮度扰动、模糊、随机擦除等增广手段扩到八千张左右标注格式选 PicoDet 支持的格式。训练时用 ImageNet 预训练权重做迁移学习输入分辨率 320x320训练 120 轮mAP 到了 0.89INT8 量化后掉到 0.87属于可接受范围。部署之后第一次拉到产线测试结果并不理想漏检率 2% 左右误检率高达 5%。排查下来问题不在模型而在光和机械位置。玻璃盖板边缘的高光区域被当成了缺陷灰尘颗粒又被漏检。后来把穹顶光源换成低角度条形光调整了相机安装高度和被测物姿态重新标了一部分困难样本漏检率降到 0.5%误检率也压到 1.5%。这个案例给我的感觉特别深算法只占整个系统的两成数据标注、光源设计、机械定位和现场调参才是决定成败的关键。5. 常见问题与排查技巧实录5.1 部署阶段最让人头疼的四个报错嵌入式 AI 项目里的报错不会像服务器上那样给出一大段 Python traceback多数时候只能用串口日志和肉眼一点点找。我整理了一下自己在几个平台上遇到频率最高的四类问题。第一类是模型加载或内存分配失败。常见提示是分配 buffer 失败原因很简单堆空间不够。解决方案可以是调大链接脚本里的堆尺寸也可以关闭不用的组件释放 RAM最简单的则是换更小的模型或降低输入分辨率。如果还不行检查内存碎片使用rt_memory_info()查看堆剩余块必要时换成连续内存池。第二类是摄像头图像花屏、条纹或只显示半帧。这里最大的嫌疑是像素格式和行对齐问题。DCMI 或 CSI 的数据位宽、像素格式必须和摄像头模块配置成一致处理 DMA 缓冲区时还要注意地址对齐比如有些 NPU 要求输入地址 32 字节对齐不对齐就会出乱码。第三类是推理结果全是 NaN 或者置信度乱跳。首先要查预处理数值归一化是不是和训练时一致RGB 和 BGR 顺序是不是反了。其次是量化校准集问题校准集数量太少或者分布太偏INT8 量化后的激活范围估计不准模型输出就会崩掉。尽量用一千张以上覆盖各种场景的图像做校准而不是随便找几十张。第四类是模型转换失败或算子不支持。边缘 NPU 的编译器通常不算完善某些 PyTorch 新算子要么需要替换要么需要用更新版本的工具链。我建议导出 ONNX 后先用onnx-simplifier简化一遍所有带动态 shape 的节点都改成固定 shape这能绕开至少一半的转换报错。5.2 现场部署的避坑心得实验室跑得好到产线就跑偏这是很多嵌入式 AI 项目的普遍命运。第一个要提前想到的是触发方式。实验室里经常用连续采集但现场最好用光电传感器或接近开关做外部触发产品到位时采一帧这样既省算力又能和节拍对齐。触发信号最好加硬件滤波和软件去抖否则信号毛刺会间歇性触发产生半帧图像。第二个是光源。我在玻璃检测案例里栽过跟头连续光源下算法表现正常换到带频闪的 LED 光源后图像里出现横向亮暗条纹模型误检率暴增。解决方案是改用高频率恒流驱动或同步频闪确保相机曝光区间内光强稳定。第三是数据记录。现场出问题时最缺的就是“案发现场”。建议从部署第一天就把每帧图像缩略图、检测结果、置信度一起存到 SD 卡或远程服务器。这样当漏检投诉发生时你可以定位到具体某件产品快速判断是模型问题、光源问题还是机构松动。第四是版本管理。模型文件、量化校准集、训练代码、部署脚本都要纳入版本管理。我有一次为了提升精度重新训练了一轮模型量化用的却是旧的校准集导致精度反而下降查了整整一天才找到原因。把这一步固化下来能省掉大量无效加班。6. 这些东西能给你带来什么以及还能往哪走6.1 这个命题真正锻炼的是什么在我看来RTT 出这道题真正想验证的并不是谁能把 mAP 刷到最高而是谁能把一大团零散的硬件、驱动、模型、业务逻辑整合成一个稳定运行的系统。这会逼着你去理解 RTOS 的任务调度、外设 DMA 数据流、图像格式转换、模型量化部署、嵌入式 GUI、串口网络通信甚至还涉及一部分上位机知识。这些零零碎碎加在一起差不多就是目前嵌入式 AI 工程师日常工作的缩影。如果你是想进入 AIoT 或工业视觉行业的同学这类命题的价值比单纯刷几个比赛榜单要大。招聘时企业更关心你有没有跑通过完整的边缘检测链路踩过哪些坑能不能独立定位问题。一段能讲清楚“为什么模型在这个平台只能跑 40 毫秒、预处理瓶颈在哪、现场误检是怎么降下去的”的经历远比“我在服务器上用 YOLOv8 跑通 demo”有说服力。6.2 从 Demo 到产线的四个扩展方向第一个方向是多工位扩展。一条产线通常不止一个检测工位可以让每个工位都做一个轻量推理再通过串口或网口把结果汇集到边缘网关。网关负责统一给 PLC 下发剔除信号同时向上层系统上报汇总数据。这样整体架构更清晰单点故障也不会拖垮全线。第二个方向是和现有系统打通。拿着结果往 LCD 上一放在项目里只能算演示。真正的工业应用会要求把检测结果写到 MES、SCADA 或 ERP 系统里最常见的协议是 Modbus TCP、OPC UA 和 MQTT。RT-Thread 生态里有现成的网络组件和协议库写一个上报线程并不复杂但会给方案的工程价值增加很多。第三个方向是模型持续迭代。工业缺陷不会一成不变新材料、新工艺、新批次都会让模型失准。比较好的闭环是现场自动收集置信度在阈值附近的样本定期上传到服务器由人工审核后进入训练集重新训练再量化再通过 OTA 或串口更新部署端的模型文件。这一步做好了系统才会越用越准。第四个方向是低代码化。对于一个开发团队来说不可能每次换产品都让算法工程师去改代码、重新烧录。可以基于 RT-Thread 做一个简单的配置界面让现场工程师通过网页或配置文件切换模型、设定阈值、选择 ROI 区域。这样整个系统的适用范围会大大扩展从单条产线复制到多条产线也会更顺利。我自己的体会是工业质检 AI 没有想象中那么高不可攀但也不是随便跑个开源模型就能交付。它考验的是把算法塞进真实物理世界里的工程能力而这恰恰是大多数教程不教、却最有价值的部分。如果你准备上手这个命题别纠结先学哪本教材直接拿一块板子把摄像头画面点亮再让一个分类模型在 RT-Thread 上跑起来你就已经比大多数人领先半步了。