1. 一条焊缝的AI离普通开发者并不远看到“每个开发者都能做的工业质检AIRT-Thread命题公布”这个标题时我第一反应不是兴奋而是想先给主办方点个赞终于有比赛敢把“工业AI”这块被很多厂商包装得很神秘的地界摊开来放到普通嵌入式开发者面前了。我为什么这么说因为过去两年我参与过几个工业视觉相关的项目发现一个特别讽刺的现象真正到了产线上一线调试的往往是拿着螺丝刀和示波器的嵌入式工程师而不是搞算法的研究员。模型跑不动、掉帧、内存溢出、相机没图像、触发信号丢了……这些糟心事最后全落在嵌入式这端。所以从这个角度讲“工业质检AI”这件事最合适的主体本来就应该是嵌入式开发者而不是那些只会调库调参的人。再说回RT-Thread。这个命题等于把赛道彻底打开了你不用懂复杂的端到端训练不必有昂贵的GPU机器也不需要一个几十万像素的工业面阵相机。它要的是你对系统、对任务、对数据流有清晰的认知然后在一个实时操作系统里把采集、推理、判定、上报这条链路理顺。这和RT-Thread本身的定位也很契合——一个能把硬件资源用到极致、能让你看到系统每一层在干什么的操作系统。这篇文章我就想结合这个命题把我这些年做嵌入式视觉、做RTOS应用、做模型部署的实际经验摊开来聊一聊。从系统启动初始化流程这种最底层的东西到模型怎么塞进MCU、图像数据怎么流转、坑在哪里一路讲到怎么把一次竞赛命题变成一件拿得出手的作品。无论你是刚学会用rt_thread_create创建线程的新手还是在做量产项目的工程师这篇文章应该都能给你一些参考。2. 工业质检在AI赛道里为什么最“亲民”2.1 场景足够聚焦不用一上来就挑战通用智能说实话“AI”这个词被很多人理解偏了。一提AI脑子里全是ChatGPT、自动驾驶、GPT-4o这种巨无霸。但工业质检这个方向恰恰是AI领域里少数“老老实实待在框里”的活。它的任务边界极其清晰判断一个产品“合格还是不合格”框出缺陷在哪个位置或者给缺陷分个类。不存在开放问答不存在长尾语义理解它就是一个图像分类或者目标检测问题。这也意味着一个普通人完全可以用很小的成本触达核心问题。比如检测一个PCB板上的焊点有没有连锡检测一颗螺丝有没有漏装检测一个密封圈的边缘有没有毛刺。这些任务的数据集规模要求远低于自动驾驶几百张到一两千张标注图片就足够训出一个能用的模型了。最关键的算法部分门槛被拉低之后嵌入式端怎么做推理、怎么把结果上报、怎么跟产线联动就成了真正的加分项。2.2 RT-Thread这场命题的巧劲在哪这场竞赛的“巧”在于它没有把目光放在“模型精度99.9%”这种指标上而是强调“每个开发者都能做”。这句话翻译过来就是你不需要顶级实验室的算力也不需要博士级别的算法能力你只需要把一个场景从头到尾做通。我个人认为评委真正想看到的作品有三层第一你对嵌入式系统有掌控力知道任务怎么划分、优先级怎么定、资源怎么分配第二你对视觉处理链路有真实理解不是拿个开源脚本跑一遍就完事第三你能把一个“实验室Demo”变成“能在桌面/小型产线上持续运行”的东西。这三点恰恰是RT-Thread这类RTOS能发挥巨大优势的地方也是普通嵌入式开发者平时积累的看家本领。所以别被“工业AI”四个字吓住。把这个命题拆开看它就是摄像头采集图像 对图像做推理判断 通过RT-Thread的管理调度把整条链路稳定跑起来。这活儿真的每个嵌入式开发者都能干关键是你得知道从哪儿下手。3. 一个能落地的质检装置整体架构怎么搭3.1 图像采集端的选择逻辑做工业质检第一步不是训练模型是把图像拿到手。工业现场用得最多的是GigE接口或CameraLink接口的工业相机但这对于竞赛和个人项目来说成本太高驱动也太复杂。更现实的选择有这么几条路径方案成本区间是否适合MCU平台适合场景OpenMV / 摄像头转接板OV2640/OV5640/GC2141几十到两百元非常适合驱动成熟可DVP或MIPI接入小物体、静态或慢速传输的工件微距检测USB摄像头免驱几十元适合Linux板卡MCU上用得少桌面化演示、稳定光源下的批次检测手机拍摄 离线标注0成本不涉及实时推理只用来做数据集前期数据采集、扩充缺陷样本二手工业面阵相机网口/USB3.0几百到一两千需要Linux或PC参与接近真实产线适合进阶组我个人的建议是如果目标是先把整条链路跑通直接选带DVP接口、RT-Thread下有现成驱动的摄像头模块再配STM32H7系列这种带DMA和DSP的MCU开发速度会快很多。把采集搞定之后后面所有事才有依托。3.2 处理平台与推理框架的匹配工业质检的算法实际跑在哪里决定了你整个项目的技术路线。这里我把最常用的三类平台分开说。第一类是MCU方案比如STM32H743、NXP RT1062、瑞萨RA8这类Cortex-M7或Cortex-M85内核芯片。它们的算力在几百到几千DMIPS之间实际能跑的模型基本是轻量级CNN如MobileNetV2/v3、Tiny YOLO或者一些只有几层卷积的定制小网络。部署上最通用的是TensorFlow Lite Micro输入分辨率一般压到96x96或128x128单次推理耗时在几十毫秒到几百毫秒之间。这类方案的优势是实时性可控、启动快、成本极低适合做单点检测、分拣触发。第二类是Linux板卡方案如树莓派、瑞芯微RK3566/RK3588、全志V3s、爱芯元智AX620等。这类平台可以直接跑OpenCV、NCNN、ONNX Runtime能部署YOLOv5s/v8s这类更实用的检测模型输入分辨率也可以放大到640x640。缺点是系统复杂度上来了要面对Linux驱动、内存管理、断电安全等一系列新问题但开发资料多、容错率高。第三类是MCULinux混合方案即“MCU负责采集和实时控制Linux板卡负责推理”。这是工业项目里特别常见的组合也最能体现系统级设计能力。竞赛作品如果做成这个架构评委通常会更青睐因为它更接近工业真实形态。选型时最核心的判断标准不是“谁算力强”而是“你到底要检测什么、在什么节拍下检测、有没有现成驱动”。我见过太多人一上来就选最强芯片最后卡在底层驱动上动弹不得。所以老老实实先把场景范围缩小再反推平台才是正路。3.3 一条主线从像素到判定结果的数据流不管用哪套平台工业质检应用的数据流都逃不出下面这条链传感器/相机采集一帧图像 → 图像数据从DMA或驱动拷贝到内存缓冲 → 送入预处理灰度化、缩放、归一化 → 进入推理引擎得到输出张量 → 解析输出得到类别与坐标 → 根据业务规则阈值、ROI、时序生成判定结果 → 结果通过串口/网口/IO输出控制或上报这里面每一个箭头在RTOS里都对应一次内存拷贝、一个消息队列、一个信号量或一段临界区保护。很多人调试出问题根本不是模型不行而是数据流在系统里被卡住了。比如DMA缓冲没对齐导致数据被截断比如摄像头线程和推理线程共用一个buffer导致画面撕裂比如推理线程优先级太高占满了CPU导致看门狗复位。所以我建议大家在画自己项目的架构图当然这里不是让你们用流程图软件用文字/表格列清楚就行时一定要标出每一段数据从哪来、到哪去、由哪个线程处理、用多少内存。这个清单列出来系统设计基本就清楚了。这里给一个MCU端的线程划分示例线程名优先级职责与外部通信iv_capture24等待硬件VSYNC采集一帧到ping-pong缓冲发送帧就绪信号量iv_infer20等待信号量执行预处理和推理读取帧缓冲向消息队列发送结果iv_decision18接收结果执行业务规则吐判定串口上报、GPIO输出iv_display10可选显示原图/标注图便于调试写入LCD/串口优先级不是越高越好而是够用就好。采集线程的实时性要求最高所以优先级最高推理是CPU密集型的优先级次之防止它把整个系统饿死判定和显示相对宽松。4. 从系统启动到质检任务RT-Thread应用开发的底层逻辑4.1 启动初始化流程里藏着一切可能的起点前面说到要让系统真正转起来RT-Thread的启动流程是绕不开的。这也是网上被问到烂的“rt-thread 系统的启动初始化流程”面试题的真正来源。理解清楚这条链路不仅面试能过你调试自己的质检程序也会顺手很多。先说最底层。在MDK或IAR工程里Cortex-M内核芯片复位后的第一个入口是汇编文件里的Reset_Handler它干两件事调用SystemInit()初始化时钟然后跳进__main。__main完成C运行环境的准备工作——把RW段从Flash拷到RAM、把ZI段清零然后才进入C语言的main函数。而RT-Thread的main函数长得很规矩里面基本只有一句话rtthread_startup()。这个名字起得直白就是“把RTOS内核启动起来”。rtthread_startup()内部的工作可以拆成这么几步int rtthread_startup(void) { rt_hw_interrupt_disable(); // 关闭中断 rt_hw_board_init(); // 板级初始化时钟、串口、堆等 rt_show_version(); // 打印版本 rt_system_timer_init(); // 系统时钟 rt_system_scheduler_init(); // 调度器初始化 rt_application_init(); // 创建main线程 rt_system_timer_thread_init(); // 定时器线程 rt_thread_idle_init(); // 空闲线程 rt_system_scheduler_start(); // 启动调度永不返回 return 0; }这里有个细节值得注意在调用rt_hw_board_init()之前中断是被关掉的。因为此时内核还没准备好任何中断进来都没法被妥善处理。这个状态一直持续到rt_system_scheduler_start()调度器接管后系统才算真正进入多线程世界。很多入门者喜欢在main函数里直接写业务代码比如初始化摄像头、加载模型之类这不是不行但不符合RT-Thread的推荐用法。正确做法是在main里创建各个业务线程然后让线程自己跑。因为main自身也是一个线程初始线程优先级通常不高你把耗时操作放在里面会影响后续线程的启动时机。4.2 自动初始化机制是怎么回事为什么面试总爱问RT-Thread比较有特色的一个设计是“自动初始化”。它在链接阶段搞了一个魔法通过编译器段属性把一堆初始化函数入口收集到一个连续数组里然后在启动时统一遍历调用。这样各个驱动、组件可以在自己的文件里注册初始化函数而不需要在一个大杂烩里逐个硬编码调用。常见的宏有这些INIT_BOARD_EXPORT(fn); // 板级硬件初始化最先执行 INIT_PREV_EXPORT(fn); // 纯软件初始化无设备依赖 INIT_DEVICE_EXPORT(fn); // 设备驱动初始化 INIT_COMPONENT_EXPORT(fn); // 组件初始化如DFS、LWIP等 INIT_ENV_EXPORT(fn); // 环境变量 INIT_APP_EXPORT(fn); // 应用初始化最后执行说白了这就像你在一家餐厅里当传菜员每道菜初始化函数都贴着标签INIT_XXX_EXPORT后厨链接器把相同标签的菜函数指针放到一个柜子段里出餐时按顺序端上桌。对于做质检项目来说自动初始化机制的实用价值在于摄像头驱动、显示驱动、串口驱动这类东西你都可以用INIT_DEVICE_EXPORT注册让系统在上电后自动把它们找出来。你不用跑去main里一行一行初始化代码整洁度会提升很多。面试时如果被问到“RT-Thread的启动初始化流程”你能把从Reset_Handler到rtthread_startup再到自动初始化各阶段的执行顺序讲出来基本就能过关了。如果还能补一句“自动初始化本质是靠链接脚本里的__rt_init_start和__rt_init_end段来界定函数指针数组区间”那面试官通常会眼前一亮。4.3 质检任务线程的创建与同步怎么设计才不翻车业务线程的创建其实不难难的是线程间同步和内存管理。我用一个实际例子来说。假设你现在要实现这样的逻辑外部光栅传感器触发一次相机拍一张模型判断一次串口上报结果。在RT-Thread里最自然的设计是中断服务例程或者一个极短的高优先级线程发一个信号量拍照线程等着信号量来了就去读帧。帧读完放进一个环形缓冲区推理线程从环读数据做推理推理完把结果压进消息队列。串口线程从消息队列取出结果并上报。这个设计里几个同步原语的选型是有讲究的同步/通信方式典型场景为什么这么选信号量事件触发只要通知“有帧来了”语义简单不携带数据互斥量多个线程都要写同一个串口/DMA缓冲防止数据交叉覆盖注意优先级继承消息队列推理结果、业务指令等带数据的通信天然FIFO能暂存多个结果事件集一个线程要等“采到帧”且“检测到物体”等多条件可读性好避免嵌套信号量这里有一个我在实际项目里踩过的坑信号量使用RT_WAITING_FOREVER时如果触发源异常导致信号迟迟不来拍照线程会一直阻塞之后任何业务都没法推进。所以建议用带超时的等待比如rt_sem_take(sem, rt_tick_from_millisecond(1000))超时后可以做异常计数或报警而不是干等。另一个坑是线程栈大小。视觉任务如果直接把一帧128x128的RGB图像丢到线程栈里就是128 * 128 * 3 49152字节将近48KB。MCU线程栈默认给个两三KB的话瞬间栈溢出。正确做法是把图像缓冲放在全局的内存池或静态数组里线程栈里只放指针和临时变量。5. 把AI模型塞进嵌入式设备实际跑通的路线5.1 先算一笔账RAM、Flash、推理延迟很多人在“部署模型”这一步被劝退是因为心里没底。我建议动手之前先算三笔账模型文件要占多少Flash激活值/中间张量要占多少RAM一次推理要多久。举个例子。假如你用一个8层卷积的小网络输入128x128x3卷积核16/32/64通道模型参数大约在30万到60万之间。如果用float32存储就是1.2MB到2.4MB的Flash。用INT8量化之后直接砍到1/4差不多300KB到600KB。RAM这边主要看最大一层的激活张量。128x128输入下第一层卷积输出可能是64x64x16也就是646416*4float32等于262144字节差不多256KB。如果量化成int8就是64KB。这还没算输入图像缓冲、DMA缓冲和系统其他开销。所以你在选MCU时RAM至少得256KB以上Flash至少1MB才玩得比较舒服。这就是为什么STM32H7432MB Flash1MB RAM是这类项目的入门标配。推理延迟你可以这么估STM32H743跑一个MobileNetV2 96x96输入单帧大约150~400ms。这在“被测物体静止传送带节拍不快”的场景里够用但如果你要检测快速移动的工件就得上Linux板卡或者带NPU的平台了。提前算清楚这账能帮你避免在答辩现场被评委一句“为什么要用这么贵的芯片”问住。5.2 MCU上接TFLite Micro的实际步骤TensorFlow Lite Micro是目前MCU上部署模型最主流的方案。整体接入流程分成模型训练转换和嵌入式端工程集成两段。先看模型转换这一段。你可以在PC上用PyTorch/Keras训练一个质量分类模型合格/缺陷也可以直接用一个预训练模型做迁移学习。训练完成后导出成.tflite格式这一步在Python里通常是import tensorflow as tf # 把训练好的Keras模型转换为TFLite格式 converter tf.lite.TFLiteConverter.from_keras_model(model) converter.optimizations [tf.lite.Optimize.DEFAULT] converter.representative_dataset representative_dataset # 校准图像 tflite_model converter.convert() with open(model_int8.tflite, wb) as f: f.write(tflite_model)注意这里面的representative_dataset是用来做量化校准的很多新手会漏掉这一环。没有它转换出来的INT8模型精度可能掉得很厉害。这个数据集不需要太多图像一百来张充分覆盖光照分布和缺陷类型的图就够。然后是嵌入式端。在RT-Thread下集成TFLite Micro一般步骤是把TFLite Micro的源码目录放进工程或者用RT-Thread软件包直接拉取用xxd -i model_int8.tflite把模型转成C数组塞进Flash在代码里用tflite::GetModel()读取模型创建Interpreter分配Tensor把摄像头采集的RGB图像先缩放到模型输入尺寸做归一化再拷贝到输入Tensor调用interpreter-Invoke()读取输出Tensor拿结果。这段逻辑在MCU端大概是#include tensorflow/lite/micro/all_ops_resolver.h #include tensorflow/lite/micro/micro_interpreter.h #include model_int8_tflite.h static tflite::MicroInterpreter *interpreter NULL; static uint8_t *input_tensor_data NULL; void ai_model_init(void) { static tflite::AllOpsResolver resolver; static uint8_t tensor_arena[150 * 1024]; // 给中间激活值预留的缓冲需要足够大 const tflite::Model *model tflite::GetModel(g_model_data); interpreter new tflite::MicroInterpreter(model, resolver, tensor_arena, sizeof(tensor_arena)); interpreter-AllocateTensors(); input_tensor_data interpreter-input(0)-data.uint8; }代码本身不算复杂真正麻烦的是RAM分配和算子支持。tensor_arena给太小AllocateTensors()会报错给太大系统其他地方就穷了。我的习惯是先给一个保守值比如128KB跑起来观察interpreter-arena_used_bytes()的实际数值再回头调整到“够用余量20%”的水平。5.3 不训练也能出成绩传统图像算法在这里的价值很多人一看到“工业质检AI”就默认必须上深度学习这其实是个误区。在一些缺陷特征非常明确的任务里传统图像处理算法的稳定性、可解释性、资源占用都远胜神经网络。竞赛作品里如果能体现出“算法选型有依据”是很加分的。举几个适合传统算法的场景尺寸检测工件的长宽、孔径、引脚间距用边缘检测阈值比较就能做缺件检测比如电池外壳上必须有贴纸利用色相/亮度阈值统计目标区域的面积占比划痕/脏污检测均匀光照背景下划痕表现为局部灰度突变用差分连通域分析就能拎出来字符/条码识别一些固定位置的印刷错漏用模板匹配或OCR足够。传统算法的好处是实时性极高在MCU上跑个几百帧每秒都没压力而且结果稳定可重复没有“玄学”。我在实际项目里见过不少场景用阈值分割加Blob分析做的检测误判率甚至比拍脑袋训出来的模型还低。你完全可以在竞赛里做“传统视觉为主深度学习做难例复审”的混合方案先用传统算法以极低延迟过滤掉95%的合格品只有疑似缺陷才送进CNN做二次确认。这个设计既体现性能优化能力又体现实战思维评委看了通常会点头。6. 真正做参赛作品时最值得避开的坑6.1 光照一致性比模型本身更值得砸时间我参加过几个现场评审很多团队的作品效果其实不差但一到评委现场演示就翻车最大原因不是算法而是光照变了。同样的工件在实验室LED灯下和活动现场灯光下图像灰度分布完全不同阈值也好、深度学习特征也好全都会漂移。所以在做作品时第一件事就是给采集环境搭一个固定光照装置。两个可调角度LED灯板一个柔光罩十几块钱的事却能省掉你后续一半的调试时间。代码里也不要省预处理这一步尽量对图像做归一化让亮度变化对特征的影响降到最低。6.2 缺陷样本不够怎么办工业场景里一个很现实的问题是合格品一抓一大把缺陷品却少得可怜。你拿不到足够的“坏样本”监督学习就无从谈起。我常用的办法有三类数据增强平移、旋转、亮度变化、添加噪声这是最简单的扩产方式合成缺陷把真实的缺陷图抠出来或者用图像处理工具造一些划痕、污点贴到合格品图上生成训练集改用无监督/半监督思路只拿合格品图像训练一个“正常分布”模型检测时偏离度大的就判为异常。这种方式在缺陷形态不固定的场景里特别管用。竞赛作品不要求你做出一个无敌模型但要求在“数据不充分的条件下依然给出了可靠的方案”。这一条如果会在答辩时讲清楚基本没人敢说你飘。6.3 模型能跑但系统卡顿任务优先级与超时的教训前面说了线程优先级设计我再讲一个真实翻车案例。当初我做一个分拣设备推理线程优先级设得比采集线程还高结果每次推理占用CPU太猛采集线程跟不上画面直接撕裂成两半。查了两天才发现是推理线程里做了一次阻塞式的内存申请rt_malloc在高优先级下不断抢占把相机驱动那边的DMA回调给饿死了。后来我把推理线程的优先级调低并在推理入口用一个计数信号量限制并发帧率不降反升因为不再做无谓的内存竞争了。这里得到一条经验视觉任务的瓶颈常常不是算力不够而是线程间资源协调没做好。另外一个惨痛教训是线程栈溢出。MCU上栈溢出不像PC那样直接蓝屏它往往是“跑着跑着系统随机死机隔一会儿又自己恢复”。后来我查出来是一个图像坐标解析函数里定义了一个大数组把栈压爆了。建议在RT-Thread里打开栈溢出检测CONFIG_DEBUG_STACK并定期用rt_thread_self()-stack_size查看余量别等死机了才追悔。6.4 数据和生产记录是评委最看重的部分最后这条可能很多人想不到。竞赛评审时评委看你的PPT和演示最关心的往往不是算法多炫而是“你能不能证明它稳定可靠”。什么是证明就是数据。我建议从开发第一天就记录这几样东西采集了多少张图缺陷种类分布是怎样的模型训练集、验证集、测试集的精度与召回指标不是只看准确率在MCU上实测的推理延迟、每秒处理帧数、CPU占用率连续运行若干小时的误检/漏检次数以及对应的日志截图。哪怕你的数字不是最好看的能拿出完整测试链路和学习曲线就已经比90%只放“精度99%”截图的队伍强了。工业AI的评审现场最反感的就是“只报喜不报忧”你主动复盘失败样本反而能加分。7. 把“命题”变成“作品”的操作路线图我见过太多人拿到竞赛命题后第一周热血沸腾第二周开始迷路第三周草草交个半成品。为了避免这种结局我给你们一条我自己验证过的时间安排照着做基本能把一个赛题完整走完。7.1 第一周定场景、收数据、先把摄像头点亮别急着训练模型。先用一天时间确定检测对象和判定标准比如“检测一颗螺栓安装后有没有垫片”。判定标准越细分后面越好做。接下来的时间集中精力把摄像头模组接到RT-Thread上能实时显示画面。再每天固定拍两百张图按合格/缺陷分目录归档。这一步如果能按时完成整个项目就等于成功了一半。因为后续所有工作都建立在这个数据流之上。7.2 第二周先上传统算法再引入模型第一版实现我强烈建议先用传统视觉算法把端到端流程跑通。哪怕算法粗糙、只能判个大概也先跑通。因为“端到端流程”比“单个环节的精度”重要得多。你有了一个串通的系统后面再去精准化就像在一栋已经盖好的房子里精装修一样轻松。流程跑通之后再开始准备数据集、训练模型。第二周周末能出一个分辨率不高但有区分度的CNN模型就直接进MCU试跑不追求精度追求“能跑”。7.3 第三周系统整合与演示脚本这一步是竞赛作品的重中之重。把模型、采集、控制、上报全部接起来设定好线程优先级和消息队列深度做一次长时间拷机测试。同时准备一个演示脚本放一个合格品分拣闸口不动作放一个缺陷品闸口动作串口上报“NG”。这比在电脑前反复跑代码有感染力得多。记得把过程中遇到的几个“经典坑”整理成思路图或文档。答辩时你讲“我在排查DMA缓冲错位时是这样定位的”比讲“我的模型用了ResNet50”更有含金量。7.4 后面还能怎么升级如果时间和精力允许可以从这几个方向升级作品每一级都能增加说服力采集端从单相机升级为双相机覆盖工件的正反两面增加历史结果统计在LCD屏或Web端显示每小时的合格率曲线用RT-Thread的OTA组件实现模型文件在线升级——这招一亮出来评委基本会认定你有量产思维把推理结果通过MQTT上报到IoT平台让“工业质检”变成“工业物联网质检”。8. 结语前再真心提醒几句做工业质检AI这件事技术栈跨度确实大既有RTOS内核的调度逻辑又有图像处理和模型部署的内容还有现场工程落地的责任心。但也正因为它跨度大才特别适合拿来当竞赛命题——它能逼着你在一个月内把嵌入式视觉的完整链路打通。这种能力不是靠刷几道“rt-thread面试八股”能获得的必须踩在真实代码和真实硬件上一步一步磨出来。最后分享一个我自己的小技巧把RT-Thread的启动日志完整读一遍。启动日志里每一条[I/xxx]都对应一个初始化模块你真能读懂每一行说明你对系统的掌控已经远超写应用代码的层面了。从Reset_Handler到rt_thread_startup再到你的质检线程被调度进去整条链路的掌控感才是这个命题真正想交给你的东西。