1. 为什么说这次 RT-Thread 命题是每个开发者都能上手的工业质检 AI1.1 这个命题的切入点把工业门槛降下来前两天看到 RT-Thread 社区公布了今年的 AI 命题——工业质检 AI我的第一反应是这次选题终于接地气了。过去一提“工业质检”大家脑子里蹦出来的都是高光谱相机、多轴机械臂、几万块的 GPU 服务器、专门做机器视觉的算法团队。这套配置敲下来预算少说六位数起步普通开发者连门槛都摸不着。但 RT-Thread 这个命题的巧妙之处在于它把“工业质检 AI”重新定义成了一个嵌入式工程师能搞定的边缘计算场景一块开发板、一个摄像头、一个训练好的轻量模型直接在 RT-Thread 上跑推理就能完成一个具备实际意义的缺陷检测原型。核心关键词是“边缘”——模型不依赖云端推理在设备本地完成不涉及网络通信、不依赖服务器这也是它适合大量开发者上手的原因。你可能觉得我在夸大其词。我们拆开看“工业质检 AI”到底需要哪些能力图像采集、图像预处理、模型推理、结果输出。这四件事没有一件是算法工程师专属的全部是嵌入式开发者的基本功。图像采集是驱动和 Sensor 接入预处理是内存操作和像素处理推理是把模型文件变成 C 数组喂给推理库结果输出是 GPIO 控制蜂鸣器或者串口打印。哪怕你对神经网络一窍不通只要会调库、会看日志、会搬代码把这个项目跑起来完全没有问题。1.2 你不需要成为算法专家只需要会“搬模型”我见过太多人被“AI”两个字劝退觉得先得去啃三个月反向传播、卷积原理才能碰这类项目。实际上在 2025 年做边缘 AI 开发模型的生产和部署已经高度工具化你在 PC 上用 TensorFlow 或 PyTorch 训练模型转成轻量格式再通过 xxd 命令转成 C 数组丢进 RT-Thread 工程里整个流程跟之前移植一个开源库的难度差不多。真正花时间的不是模型训练而是数据采集和调试部署这些脏活累活——恰恰是嵌入式工程师最擅长的事情。所以我觉得这次命题真正的意义是告诉开发者AI 不是算法岗的专属玩具它已经变成了嵌入式开发工具箱里的一把新扳手。你不会写卷积层一样能拧螺丝。下面我就把这个项目的完整链路从原理到实操拆一遍包括我个人的踩坑记录给准备上车或者正在规划赛题方案的你一个参考。2. 一条完整的工业质检 AI 技术链路从图像采集到缺陷判别2.1 咱们先把“质检 AI”的黑盒打开在动手选硬件之前必须搞清楚系统里每一环节在干什么。工业质检 AI本质上是把“人眼看图找毛病”这件事用摄像头加模型替代掉。整个链路拆开是五个环节采集摄像头把工件表面拍下来形成一帧 RAW 或 RGB 图像。预处理图像缩放、裁剪、转灰度或归一化让图像尺寸和色彩分布达到模型输入要求。推理模型在设备端跑一次前向计算输出缺陷类别和置信度。决策根据置信度和阈值判断这个工件是“OK”还是“NG”。执行把判定结果映射为产线动作——分拣、报警、计数、记录。传统的机器视觉方案里第 3 步通常是人工设计特征加阈值分割你写一段代码提取图像的边缘、面积、灰度均值然后硬编码一个阈值判断缺陷。这套方法的问题在于鲁棒性差车间光照一变、工件摆放角度稍微歪一点原来的阈值就失效了。AI 方案的本质区别是把“人工设计特征和阈值”替换成“从数据里学特征和阈值”。你用几百张带标注的图像喂给网络模型自己总结出划痕、异色、缺料在像素层面的统计规律。部署阶段这个规律被冻结成一组权重参数跟随模型文件一起放进设备。2.2 分类、检测、分割赛题到底该选哪条路工业质检场景里有三类常见任务适合不同结构的模型先搞清楚自己要哪类能少走一半弯路任务类型解决的问题模型输出适用场景资源占用图像分类整个工件是好的还是有缺陷类别标签 置信度坏品率低、单缺陷类型的产线最低MCU 可跑目标检测缺陷在图像哪个位置边界框坐标 类别 置信度需要定位缺陷位置、多缺陷类型中等建议 MPU图像分割缺陷精确到像素轮廓每个像素的类别缺陷形状不规则、需测量面积较高需要 NPU 或 Linux 级硬件对大多数工业质检赛题和原型项目我个人强烈建议从图像分类起步。原因很朴素分类任务在 MCU 上就能跑得动数据标注工作量为零你只需要给照片分目录摆放就行而检测和分割需要画框、画轮廓四百张图能把人标到怀疑人生。尤其是在 RT-Thread 这类嵌入式平台上受限于算力和内存大模型根本不现实轻量分类模型反而是最优解。2.3 先把流程串起来一个螺丝缺陷检测的最小用例给你一个具体场景方便后面理解假设你的产线是装配螺丝偶尔会有螺丝未拧紧或者螺纹滑牙。摄像头俯拍工件每过一个工件触发一次拍照模型判断这帧图是“正常”还是“滑牙”如果是 NGGPIO 拉高驱动红光报警并计数。这个用例最小化到只需要两类数据、一个几十 KB 的模型、一块带有摄像头的板子但五脏俱全做通了以后换成任何缺陷场景都只是换数据的区别。3. 硬件与软件选型基于 RT-Thread 的可行方案3.1 板卡怎么选先看推理能力再看口袋RT-Thread 本身是个实时操作系统内核它可以跑在 MCU 上也可以跑在带有 MMU 的 MPU 甚至低端 Linux 模块上。这给硬件选型留了非常大的空间。我把常见的几类方案按“能跑什么模型”和“成本区间”整理了一张表方便你根据自己手头的板子对号入座硬件类型典型芯片/平台可跑推理框架模型量级成本区间约低端 MCUSTM32F407/F429ESP32-S3NNoM、TinyMaix几十 KB 级别小 CNN30-80 元中端 MCUSTM32H743RA6M4NNoM、TinyMaix、CMSIS-NN100-300 KB80-200 元MCUNPUK210、Luckfox Pico UltraNNoM、TinyMaix、自带 NPU 工具链300KB-1MB40-150 元低端 MPU全志 V3s、瑞芯微 RV1103TensorFlow Lite Micro、RKNN1-3MB50-150 元Linux 板卡树莓派 Zero、香橙派 Zero 2WTensorFlow Lite、ONNX Runtime5-50MB100-300 元如果你是第一次做我首推 ESP32-S3理由有三个第一RT-Thread 对 ESP32-S3 的 BSP 支持非常完善WiFi、摄像头、文件系统组件都是现成的第二它带向量指令加速跑 TinyMaix 里的 MobileNetV1 量化模型实测能在 100ms 左右完成一次推理对原型验证来说是及格线第三整块板子几十块钱烧了不心疼。如果后续想往赛题的高性能方向做瑞芯微 RV1103 这类带 NPU 的芯片是更优解它能把 MobileNetV1 跑到 30ms 以内甚至能跑 YOLO-fastest 做目标检测。缺点是工具链稍微复杂对新手没那么友好。3.2 摄像头与光源这两个细节决定了你的上限很多初学者把精力全放在模型上忽略了成像质量。我要说句得罪人的实话工业质检项目里模型只是下限光源和相机安装才是上限。同样的板子和模型光源摆得好不好识别准确率可以差出二十个百分点一点不夸张。摄像头方面预算有限用 OV2640 或 OV5640 就行选 OV5640 的原因是分辨率更高可以拍到大一点的视野区域给模型留出更多信息。但要注意 OV5640 在 MCU 上跑满分辨率会非常吃力实战中通常 320x240 或 160x160 就已经够用。如果预算宽裕选一款支持 UVC 协议的工业免驱相机也能接入 RT-Thread 的 USB 驱动框架但那是对着产线场景才需要考虑的事做原型验证没必要上。光源是关键中的关键。工业车间最常见的痛点是环境光不稳定上午阳光照进来和下午阴天的色温完全不同同一个工件的灰度直方图差异很大模型训练时没见过这种分布偏移推理就会翻车。解决方案是加一个低成本的环形 LED 光源加漫射板让被测区域的照度基本恒定把环境光干扰压下去。某宝上 40 瓦左右的 LED 环形光源加控制器一百到两百块就能搞定效果立竿见影。我记得很清楚我第一次做 PCB 焊点检测时没加光源室外阴晴变化直接导致误判率从 2% 飙到 15%加了光源后一夜回到 1% 以内。这个教训值一顿火锅。3.3 RT-Thread 侧要提前准备哪些软件组件硬件定了以后就要规划 RT-Thread 的软件配置。不管用 RT-Thread Studio 还是 Env 工具建议至少把这些组件勾上Sensor 框架与摄像头驱动OV2640/OV5640 都有现成驱动包。记得把图像格式配成 JPEG 或 RGB565后续处理内存占用完全不一样。FAL DFS 文件系统把模型文件存到外挂 Flash 或者 SD 卡里运行时直接读取不用把几百 KB 的模型全塞进固件改模型不用重烧固件这对调试效率提升是数量级的。MSH 命令行组件调试神器。通过 finctl 命令手动触发拍照、跑推理、打印耗时比加断点插桩爽太多了。RT-Thread 设备驱动框架GPIO、UART 都用标准设备接口后面换板子的时候应用代码几乎不用动。组件之间有一个容易忽略的坑文件系统初始化必须在调用模型加载 API 之前完成否则会报找不到设备或挂载失败。在main线程里等dfs_mount成功后再进入质检逻辑这个顺序不能反。4. 手把手落地闭环数据准备、模型训练、部署上板4.1 数据采集与标注先凑齐“正常 缺陷”两类很多开发者一想到 AI 就直奔模型训练但我想把节奏按住工业质检项目中数据准备占整个项目 60% 以上的工作量而且直接影响成败。你的模型再牛数据里没有覆盖的缺陷形态部署了也是瞎的。数据怎么采我建议分两步走。第一步固定相机和光源后拍摄 300 到 500 张正常工件图像第二步人为制造缺陷样本——拧歪的螺丝、滴上油渍的 PCB、划了线的金属块——同样拍 300 到 500 张。总样本量控制在 600 到 1000 张即可跑出一个靠谱的基线。样本不需要一次采完可以边跑模型边收集误判样本后续持续增补训练。分类任务不需要画框标注按目录组织就行。我常用的目录结构如下dataset/ ├── train/ │ ├── ok/ # 正常工件图片 │ │ ├── ok_001.jpg │ │ └── ... │ └── ng/ # 缺陷工件图片 │ ├── ng_001.jpg │ └── ... └── val/ ├── ok/ └── ng/有一点必须提醒训练集和验证集要按“生产批次”切分不能随机混合切。什么意思呢假设你今天拍的数据是一台设备、一个光源条件明天换了个位置重拍的图像素分布会有细微差异。如果混着随机切模型在验证集上会显得很准一到现场就露馅。按批次划分验证集能更真实地评估模型的泛化能力。4.2 训练一个轻量分类模型MobileNetV1 裁剪方案实测模型结构上我看过太多人一上来就想用 ResNet50、YOLOv8然后发现模型文件动辄几十 MB板子内存直接爆掉。在嵌入式设备上选型原则是用最小的模型先把链路打通再根据精度诉求往回加复杂度。这里给一个我实测过多次的轻量方案MobileNetV1宽度因子 0.25输入尺寸 128x128三通道彩色图全连接层换成全局平均池化 Dropout 全连接二分类。这个模型参数量不到 20 万INT8 量化后文件大约 80KB 左右是 MCU 上非常舒服的体型。训练脚本基于 TensorFlow代码不算长核心逻辑如下import tensorflow as tf from tensorflow.keras import layers, models def build_model(input_shape(128, 128, 3), num_classes2): base tf.keras.applications.MobileNetV1( input_shapeinput_shape, alpha0.25, include_topFalse, weightsNone, classesnum_classes ) model models.Sequential([ base, layers.GlobalAveragePooling2D(), layers.Dropout(0.2), layers.Dense(num_classes, activationsoftmax) ]) return model model build_model() model.compile( optimizertf.keras.optimizers.Adam(1e-3), losscategorical_crossentropy, metrics[accuracy] )训练时建议打开这三个数据增强水平翻转、亮度扰动、小角度旋转。尤其是亮度扰动它能模拟车间光照的轻微波动帮模型学出光照不敏感的特征对于工业场景非常重要。如果样本量小把epochs设在 15 到 30 之间当验证精度不再上升就停掉避免过拟合。训练完先看val_accuracy理论上 600 张数据、两类问题跑出 95% 以上是很常见的如果太低优先排查光源和图像质量而不是调网络结构。4.3 模型转换与量化从 h5 到 C 数组的一整套流程模型训练完是.h5或者 SavedModel 格式PC 上直接用没问题但板载 MCU 跑浮点模型太奢侈了。这里的关键步骤是PTQ 量化把浮点权重映射到 8bit 整数模型体积缩到约 1/4推理速度提升数倍而精度损失通常在 1-3 个百分点以内完全可接受。转换流程我整理成了命令序列你在 PC 的 Python 环境里依次执行即可# 1. 把 h5 转成 tflite 格式 tflite_convert \ --saved_model_dirsaved_model \ --output_filemodel.tflite \ --input_shapes1,128,128,3 \ --input_arraysinput_1 \ --output_arraysIdentity # 2. 用代表性数据集做 PTQ 量化 python quantize_tflite.py # 3. 转成 C 数组方便直接塞进 RT-Thread 工程 xxd -i model_quant.tflite model_data.cquantize_tflite.py的核心部分是通过tf.lite.TFLiteConverter.from_saved_model加载模型设置optimizations[tf.lite.Optimize.DEFAULT]然后喂入一小部分代表性图像数据来统计激活值范围。这一步要注意代表性数据集最好准备约 100 张覆盖两种类别的图数量太少会导致量化统计不准确。转换完成后务必在 PC 端用tflite_runtime.interpreter跑一遍校验收敛确认量化前后的预测结果一致性再上板。model_data.c的内容就是一个大数组你要做的就是把model_quant.tflite文件复制到工程资源目录作为一个只读文件访问。我自己的习惯是放在板子的外置 Flash 文件系统路径下比如/models/defect_model.tflite这样以后模型迭代只需要通过文件系统替换文件不用重新编译固件。4.4 在 RT-Thread 上创建质检线程代码骨架与关键点部署到 RT-Thread 上核心工作可以拆成三件事读取模型文件、初始化推理器、创建质检线程。这里给一个精简的代码骨架用的是 NNoM 库配合 TensorFlow Lite 解析器的路线#include rtthread.h #include nnom.h #include dfs_posix.h static nnom_model_t *model; static uint8_t *input_buf; static uint8_t *output_buf; static void quality_inspect_thread_entry(void *param) { rt_err_t result; struct rt_sensor_data sensor_data; // 1. 从文件系统加载模型 int fd open(/models/defect_model.tflite, O_RDONLY); if (fd 0) { rt_kprintf(open model failed\n); return; } // 读取模型内容到内存初始化 NNoM model nnom_model_load(fd); close(fd); if (model RT_NULL) { rt_kprintf(load model failed\n); return; } input_buf (uint8_t *)nnom_model_input_buffer(model); output_buf (uint8_t *)nnom_model_output_buffer(model); while (1) { // 2. 触发摄像头采集一帧 rt_device_read(camera_dev, 0, sensor_data, sizeof(sensor_data)); // 3. 图像预处理裁剪、缩放、RGB转RGB888、归一化 preprocess_image(sensor_data.data, input_buf, 128, 128); // 4. 执行推理 nnom_model_run(model); // 5. 解析输出置信度超过阈值则判定缺陷 float ng_score output_buf[1] / 255.0f; if (ng_score 0.6f) { rt_pin_write(NG_LED_PIN, PIN_HIGH); rt_kprintf(NG detected, score%.2f\n, ng_score); } else { rt_pin_write(NG_LED_PIN, PIN_LOW); } rt_thread_mdelay(50); } }这段代码里有几个很隐蔽的坑值得单独说。第一nnom_model_load的返回值一定要检查为 NULL模型文件路径错误或文件系统未挂载都会导致加载失败不检查的话后续调用直接 HardFault排查起来很痛苦。第二输入缓冲区input_buf的尺寸必须严格等于128*128*3RGB565 转 RGB888 时要留意字节序否则你看到的花屏图片喂进去模型输出的置信度全是乱的。第三nnom_model_run执行完后输出缓冲区里是softmax结果但在量化模型里通常表示成 0 到 255 的整数记得像示例里这样除以 255 还原成概率值再做判断。4.5 触发方式轮询还是中断具体工况具体分析产线场景里相机的触发方式直接影响系统设计。最简单的做法是主循环里定时轮询拍摄间隔几百毫秒拍一帧适合演示和原型。如果需要跟产线节拍对齐就得引入外部触发——对射传感器检测到工件到位时拉一个 GPIO 电平中断服务程序里置一个拍照标志位质检线程看到标志位再采集并推理。用 RT-Thread 实现时我建议用rt_sem_take和rt_sem_release做触发信号同步而不是直接在 ISR 里做耗时操作。拍照和推理都是相对耗时的任务全部放在线程上下文里执行。触发信号量相当于是“产线节拍的节拍器”这种方式结构清晰后续加多工位也容易扩展。如果两个工件间隔时间小于一次推理耗时要在前面加排队或缓存否则会丢检。5. 实测定会踩的坑帧率、内存、误判率与调优手段5.1 帧率不等于产线节拍先把账算明白我见过不少开发者拿着 Demo很兴奋地跟我说“我这个推理只要 80ms一秒十几次产线绝对够用。”这里其实偷换了概念。完整的质检节拍不是只有推理时间而是“曝光 读图 预处理 推理 结果输出 IO 动作”的总和。实测下来光从摄像头读一帧 320x240 的 RGB565 图像在 SPI 接口的 OV2640 上就可能要 40ms 以上预处理还要再吃掉十几毫秒。最终一帧的完整周期常常是推理耗时的两倍以上一点不夸张。给你一个实测参考ESP32-S3 跑 MobileNetV1 alpha0.25 量化模型推理耗时约 85ms读图 35ms预处理缩放、格式转换 15ms串口打印结果 5ms。整链路约 140ms折合约 7 FPS。如果你的产线节拍是每秒 4 件这个速度刚好压线如果节拍到每秒 6 件就必须换带 NPU 的芯片或者缩小输入尺寸到 96x96 来提速精度上会有轻微损失但通常可以换。所以先算账再选型别拍脑袋。5.2 内存是 MCU 上最无情的考官MCU 上的内存规划是这种项目最劝退人的地方。拿 STM32F429 举例它的 RAM 通常是 256KB你已经觉得不小了但拆开算一下就会冒汗模型文件本身800KB存放在外置 Flash不占 RAM但加载时如果整包读入就爆了。NNoM 支持边读边解析模型体量在 80KB 以上时建议流式解析。输入图像缓冲区128x128x3 48KB。推理激活缓冲工作内存MobileNet 0.25 大约 80-120KB需要在配置工具里预留。RT-Thread 内核堆 线程栈 文件系统缓存至少 32KB。加起来已经逼近 200KB这还是没算屏幕缓冲、网络协议栈等附加功能的开销。内存优化的常见手段包括把图像采集缓冲区复用为输入缓冲区拍完一帧直接覆盖写将线程栈压到 4KB 以内关掉用不到的功能组件不勾选多余组件高级一点还可以把图像缩小到 96x96 再推理输入缓冲区直接省一半。每一个 KB 都得精打细算但当你把内存压到刚好装下所有模块的那一刻成就感也是真的强。5.3 误判率如何用“拒识”思路提升可用性模型不是神必然有误判。在实际的工业场景里误判分两种把坏的说成好的漏检把好的说成坏的误杀。漏检是安全事故误杀是效率损失。方向不同调优目标也不同。我最想分享的一条实战经验是给你的分类器加一个“不确定”的阈值区。假设模型输出 NG 的置信度是 0.9 表示很可能是缺陷0.3 表示很正常那么中间那一段比如 0.4 到 0.7是什么它可能是你没有训练过的缺陷形态也可能是拍照瞬间的模糊帧。这时候让样品进入“二次人工复检”通道而不是强行归入 OK 或 NG 任意一类反而能让整个系统的可靠性上一个台阶。具体实现就是在分类逻辑里加一个双阈值判断超过上限判缺陷低于下限判正常落在中间标记为“待复检”。这个“拒识”机制的收益在产线实测中非常明显——误杀率降下来了漏检率也没有上升。另一个容易忽略的细节是产品换型。早上检螺丝、下午检垫片模型需要切换。如果把模型 A 和模型 B 都存进文件系统通过 MSH 命令动态切换加载就能支持一条产线快速换型。RT-Thread 的文件系统在这里的价值就体现出来了模型即文件换型即换文件不需要重新编译。5.4 调试工具链MSH 就是你的质检调试台最后聊一下调试工具。这类项目的调试难点在于“不好复现”同一个缺陷灯一偏就不出现了同一张图像模型输出时好时坏。我的做法是让 MSH 承担调试台的角色而不是开关一堆日志宏。在固件里预留这么几条命令MSH_CMD_EXPORT(cap, capture one image and save to /images); MSH_CMD_EXPORT(infer, run inference on /images/test.jpg); MSH_CMD_EXPORT(set_th, set confidence threshold); MSH_CMD_EXPORT(info, show model info and memory usage);通过串口终端我可以随时触发一帧采集、单独跑一次推理、动态调整阈值甚至可以把图像直接写到 SD 卡里回放。这套交互方式的调试效率比反复烧固件高一个数量级。如果板子支持 LCD还能把输入图像实时显示出来直观看到预处理结果是否正常。这些手段放在产线现场的时候能救命。6. 从赛题到产线多工位、数据回流与“什么时候别用 AI”6.1 多工位与上下位机一个更接近真实的系统形态赛题要求大概率是一个单工位原型验证。但如果你去实际工厂待过就会发现产线不会只有一个质检工位一条流水线可能有四五个相机位分别检测不同角度模型可能是分散在每条线上的边缘盒子里的也可能有一个中心服务器汇总所有工位的检测结果。从赛题往真实产线走架构通常会长这样每个工位一个边缘计算盒子上面跑 RT-Thread 或小型 Linux当地完成实时推理每台边缘盒子通过局域网把“OK/NG 结果、置信度、缺陷类别、图像缩略图”上报到中控台中控台负责统计产线良率、按批次回溯缺陷、把新采集的误判样本导出用于下一轮模型迭代。这个闭环的最后一个环节非常关键——产线产生的数据才是模型持续进化的燃料。赛题如果只做到能检出来那是合格线能做到“检出后还能回流训练”这项目一下子就活了也更容易在评审中脱颖而出。6.2 什么时候 AI 不是答案做技术的容易犯“手里有锤子看什么都是钉子”的毛病。我必须补一句冷静话工业质检里有一大批场景传统视觉方案比 AI 更靠谱、更便宜、更可控。举个例子检测传送带上有没有工件遮挡一个光电开关就搞定测量一个精密零件的长度是否在公差内激光位移传感器加阈值判断比任何神经网络都准零件表面有明确的、固定的缺陷位置和形态传统模板匹配或灰度差分在速度和成本上远超 AI。我的判断标准很简单如果缺陷可以通过明确的物理规则描述就优先用传统方案只有缺陷形态复杂、规则写不清楚、检测对象变化频繁的场景才值得上 AI。AI 的优势在于泛化代价是可解释性差、调试成本高、数据依赖强。把这两者结合起来反而能做出更实用的项目比如先用传统视觉做初筛把明显 OK 的工件放行只有疑似样本才进 AI 模型做二次研判这样整个系统的吞吐量和可靠性都能显著提升。这种“传统 AI”的混合裁决策略我认为才是工业质检落地的正确姿势也是这种比赛的加分点。6.3 最后再分享一条实测出来的经验我在调试自己的第一个质检模型时踩过一个很离谱的坑模型在训练集上准确率 99%但一部署到板子上把验证集图片搬过去测试就只有 60%怎么都找不出原因。后来偶然发现我训练时的输入是 TensorFlow 默认的 RGB 通道顺序而板子摄像头出来的 RGB565 转 RGB888 后字节序反了——红色和蓝色通道互换了。模型学的是红色划痕板子喂进去的是蓝色划痕准确率当然崩。这种低级错误非常隐蔽排起来却极其耗时。排查方法是把板子上的输入图像用 MSH 命令直接导出成文件在 PC 上跟训练集图像并排对比。这个习惯我一直保持到现在任何一次模型上板都要先验图再验模型。工业质检 AI 不是一个需要仰望的题目它就是“图像采集 模型推理 工程调试”的配方。赛题给了开发者一个提前接触真实工业场景的机会顺着上面这条路子把链路打通把坑踩平你能收获的不仅是一个能演示的项目更是一套值得带进任何嵌入式 AI 项目的工程手感。
RT-Thread工业质检AI实战：边缘部署轻量模型实现缺陷检测
1. 为什么说这次 RT-Thread 命题是每个开发者都能上手的工业质检 AI1.1 这个命题的切入点把工业门槛降下来前两天看到 RT-Thread 社区公布了今年的 AI 命题——工业质检 AI我的第一反应是这次选题终于接地气了。过去一提“工业质检”大家脑子里蹦出来的都是高光谱相机、多轴机械臂、几万块的 GPU 服务器、专门做机器视觉的算法团队。这套配置敲下来预算少说六位数起步普通开发者连门槛都摸不着。但 RT-Thread 这个命题的巧妙之处在于它把“工业质检 AI”重新定义成了一个嵌入式工程师能搞定的边缘计算场景一块开发板、一个摄像头、一个训练好的轻量模型直接在 RT-Thread 上跑推理就能完成一个具备实际意义的缺陷检测原型。核心关键词是“边缘”——模型不依赖云端推理在设备本地完成不涉及网络通信、不依赖服务器这也是它适合大量开发者上手的原因。你可能觉得我在夸大其词。我们拆开看“工业质检 AI”到底需要哪些能力图像采集、图像预处理、模型推理、结果输出。这四件事没有一件是算法工程师专属的全部是嵌入式开发者的基本功。图像采集是驱动和 Sensor 接入预处理是内存操作和像素处理推理是把模型文件变成 C 数组喂给推理库结果输出是 GPIO 控制蜂鸣器或者串口打印。哪怕你对神经网络一窍不通只要会调库、会看日志、会搬代码把这个项目跑起来完全没有问题。1.2 你不需要成为算法专家只需要会“搬模型”我见过太多人被“AI”两个字劝退觉得先得去啃三个月反向传播、卷积原理才能碰这类项目。实际上在 2025 年做边缘 AI 开发模型的生产和部署已经高度工具化你在 PC 上用 TensorFlow 或 PyTorch 训练模型转成轻量格式再通过 xxd 命令转成 C 数组丢进 RT-Thread 工程里整个流程跟之前移植一个开源库的难度差不多。真正花时间的不是模型训练而是数据采集和调试部署这些脏活累活——恰恰是嵌入式工程师最擅长的事情。所以我觉得这次命题真正的意义是告诉开发者AI 不是算法岗的专属玩具它已经变成了嵌入式开发工具箱里的一把新扳手。你不会写卷积层一样能拧螺丝。下面我就把这个项目的完整链路从原理到实操拆一遍包括我个人的踩坑记录给准备上车或者正在规划赛题方案的你一个参考。2. 一条完整的工业质检 AI 技术链路从图像采集到缺陷判别2.1 咱们先把“质检 AI”的黑盒打开在动手选硬件之前必须搞清楚系统里每一环节在干什么。工业质检 AI本质上是把“人眼看图找毛病”这件事用摄像头加模型替代掉。整个链路拆开是五个环节采集摄像头把工件表面拍下来形成一帧 RAW 或 RGB 图像。预处理图像缩放、裁剪、转灰度或归一化让图像尺寸和色彩分布达到模型输入要求。推理模型在设备端跑一次前向计算输出缺陷类别和置信度。决策根据置信度和阈值判断这个工件是“OK”还是“NG”。执行把判定结果映射为产线动作——分拣、报警、计数、记录。传统的机器视觉方案里第 3 步通常是人工设计特征加阈值分割你写一段代码提取图像的边缘、面积、灰度均值然后硬编码一个阈值判断缺陷。这套方法的问题在于鲁棒性差车间光照一变、工件摆放角度稍微歪一点原来的阈值就失效了。AI 方案的本质区别是把“人工设计特征和阈值”替换成“从数据里学特征和阈值”。你用几百张带标注的图像喂给网络模型自己总结出划痕、异色、缺料在像素层面的统计规律。部署阶段这个规律被冻结成一组权重参数跟随模型文件一起放进设备。2.2 分类、检测、分割赛题到底该选哪条路工业质检场景里有三类常见任务适合不同结构的模型先搞清楚自己要哪类能少走一半弯路任务类型解决的问题模型输出适用场景资源占用图像分类整个工件是好的还是有缺陷类别标签 置信度坏品率低、单缺陷类型的产线最低MCU 可跑目标检测缺陷在图像哪个位置边界框坐标 类别 置信度需要定位缺陷位置、多缺陷类型中等建议 MPU图像分割缺陷精确到像素轮廓每个像素的类别缺陷形状不规则、需测量面积较高需要 NPU 或 Linux 级硬件对大多数工业质检赛题和原型项目我个人强烈建议从图像分类起步。原因很朴素分类任务在 MCU 上就能跑得动数据标注工作量为零你只需要给照片分目录摆放就行而检测和分割需要画框、画轮廓四百张图能把人标到怀疑人生。尤其是在 RT-Thread 这类嵌入式平台上受限于算力和内存大模型根本不现实轻量分类模型反而是最优解。2.3 先把流程串起来一个螺丝缺陷检测的最小用例给你一个具体场景方便后面理解假设你的产线是装配螺丝偶尔会有螺丝未拧紧或者螺纹滑牙。摄像头俯拍工件每过一个工件触发一次拍照模型判断这帧图是“正常”还是“滑牙”如果是 NGGPIO 拉高驱动红光报警并计数。这个用例最小化到只需要两类数据、一个几十 KB 的模型、一块带有摄像头的板子但五脏俱全做通了以后换成任何缺陷场景都只是换数据的区别。3. 硬件与软件选型基于 RT-Thread 的可行方案3.1 板卡怎么选先看推理能力再看口袋RT-Thread 本身是个实时操作系统内核它可以跑在 MCU 上也可以跑在带有 MMU 的 MPU 甚至低端 Linux 模块上。这给硬件选型留了非常大的空间。我把常见的几类方案按“能跑什么模型”和“成本区间”整理了一张表方便你根据自己手头的板子对号入座硬件类型典型芯片/平台可跑推理框架模型量级成本区间约低端 MCUSTM32F407/F429ESP32-S3NNoM、TinyMaix几十 KB 级别小 CNN30-80 元中端 MCUSTM32H743RA6M4NNoM、TinyMaix、CMSIS-NN100-300 KB80-200 元MCUNPUK210、Luckfox Pico UltraNNoM、TinyMaix、自带 NPU 工具链300KB-1MB40-150 元低端 MPU全志 V3s、瑞芯微 RV1103TensorFlow Lite Micro、RKNN1-3MB50-150 元Linux 板卡树莓派 Zero、香橙派 Zero 2WTensorFlow Lite、ONNX Runtime5-50MB100-300 元如果你是第一次做我首推 ESP32-S3理由有三个第一RT-Thread 对 ESP32-S3 的 BSP 支持非常完善WiFi、摄像头、文件系统组件都是现成的第二它带向量指令加速跑 TinyMaix 里的 MobileNetV1 量化模型实测能在 100ms 左右完成一次推理对原型验证来说是及格线第三整块板子几十块钱烧了不心疼。如果后续想往赛题的高性能方向做瑞芯微 RV1103 这类带 NPU 的芯片是更优解它能把 MobileNetV1 跑到 30ms 以内甚至能跑 YOLO-fastest 做目标检测。缺点是工具链稍微复杂对新手没那么友好。3.2 摄像头与光源这两个细节决定了你的上限很多初学者把精力全放在模型上忽略了成像质量。我要说句得罪人的实话工业质检项目里模型只是下限光源和相机安装才是上限。同样的板子和模型光源摆得好不好识别准确率可以差出二十个百分点一点不夸张。摄像头方面预算有限用 OV2640 或 OV5640 就行选 OV5640 的原因是分辨率更高可以拍到大一点的视野区域给模型留出更多信息。但要注意 OV5640 在 MCU 上跑满分辨率会非常吃力实战中通常 320x240 或 160x160 就已经够用。如果预算宽裕选一款支持 UVC 协议的工业免驱相机也能接入 RT-Thread 的 USB 驱动框架但那是对着产线场景才需要考虑的事做原型验证没必要上。光源是关键中的关键。工业车间最常见的痛点是环境光不稳定上午阳光照进来和下午阴天的色温完全不同同一个工件的灰度直方图差异很大模型训练时没见过这种分布偏移推理就会翻车。解决方案是加一个低成本的环形 LED 光源加漫射板让被测区域的照度基本恒定把环境光干扰压下去。某宝上 40 瓦左右的 LED 环形光源加控制器一百到两百块就能搞定效果立竿见影。我记得很清楚我第一次做 PCB 焊点检测时没加光源室外阴晴变化直接导致误判率从 2% 飙到 15%加了光源后一夜回到 1% 以内。这个教训值一顿火锅。3.3 RT-Thread 侧要提前准备哪些软件组件硬件定了以后就要规划 RT-Thread 的软件配置。不管用 RT-Thread Studio 还是 Env 工具建议至少把这些组件勾上Sensor 框架与摄像头驱动OV2640/OV5640 都有现成驱动包。记得把图像格式配成 JPEG 或 RGB565后续处理内存占用完全不一样。FAL DFS 文件系统把模型文件存到外挂 Flash 或者 SD 卡里运行时直接读取不用把几百 KB 的模型全塞进固件改模型不用重烧固件这对调试效率提升是数量级的。MSH 命令行组件调试神器。通过 finctl 命令手动触发拍照、跑推理、打印耗时比加断点插桩爽太多了。RT-Thread 设备驱动框架GPIO、UART 都用标准设备接口后面换板子的时候应用代码几乎不用动。组件之间有一个容易忽略的坑文件系统初始化必须在调用模型加载 API 之前完成否则会报找不到设备或挂载失败。在main线程里等dfs_mount成功后再进入质检逻辑这个顺序不能反。4. 手把手落地闭环数据准备、模型训练、部署上板4.1 数据采集与标注先凑齐“正常 缺陷”两类很多开发者一想到 AI 就直奔模型训练但我想把节奏按住工业质检项目中数据准备占整个项目 60% 以上的工作量而且直接影响成败。你的模型再牛数据里没有覆盖的缺陷形态部署了也是瞎的。数据怎么采我建议分两步走。第一步固定相机和光源后拍摄 300 到 500 张正常工件图像第二步人为制造缺陷样本——拧歪的螺丝、滴上油渍的 PCB、划了线的金属块——同样拍 300 到 500 张。总样本量控制在 600 到 1000 张即可跑出一个靠谱的基线。样本不需要一次采完可以边跑模型边收集误判样本后续持续增补训练。分类任务不需要画框标注按目录组织就行。我常用的目录结构如下dataset/ ├── train/ │ ├── ok/ # 正常工件图片 │ │ ├── ok_001.jpg │ │ └── ... │ └── ng/ # 缺陷工件图片 │ ├── ng_001.jpg │ └── ... └── val/ ├── ok/ └── ng/有一点必须提醒训练集和验证集要按“生产批次”切分不能随机混合切。什么意思呢假设你今天拍的数据是一台设备、一个光源条件明天换了个位置重拍的图像素分布会有细微差异。如果混着随机切模型在验证集上会显得很准一到现场就露馅。按批次划分验证集能更真实地评估模型的泛化能力。4.2 训练一个轻量分类模型MobileNetV1 裁剪方案实测模型结构上我看过太多人一上来就想用 ResNet50、YOLOv8然后发现模型文件动辄几十 MB板子内存直接爆掉。在嵌入式设备上选型原则是用最小的模型先把链路打通再根据精度诉求往回加复杂度。这里给一个我实测过多次的轻量方案MobileNetV1宽度因子 0.25输入尺寸 128x128三通道彩色图全连接层换成全局平均池化 Dropout 全连接二分类。这个模型参数量不到 20 万INT8 量化后文件大约 80KB 左右是 MCU 上非常舒服的体型。训练脚本基于 TensorFlow代码不算长核心逻辑如下import tensorflow as tf from tensorflow.keras import layers, models def build_model(input_shape(128, 128, 3), num_classes2): base tf.keras.applications.MobileNetV1( input_shapeinput_shape, alpha0.25, include_topFalse, weightsNone, classesnum_classes ) model models.Sequential([ base, layers.GlobalAveragePooling2D(), layers.Dropout(0.2), layers.Dense(num_classes, activationsoftmax) ]) return model model build_model() model.compile( optimizertf.keras.optimizers.Adam(1e-3), losscategorical_crossentropy, metrics[accuracy] )训练时建议打开这三个数据增强水平翻转、亮度扰动、小角度旋转。尤其是亮度扰动它能模拟车间光照的轻微波动帮模型学出光照不敏感的特征对于工业场景非常重要。如果样本量小把epochs设在 15 到 30 之间当验证精度不再上升就停掉避免过拟合。训练完先看val_accuracy理论上 600 张数据、两类问题跑出 95% 以上是很常见的如果太低优先排查光源和图像质量而不是调网络结构。4.3 模型转换与量化从 h5 到 C 数组的一整套流程模型训练完是.h5或者 SavedModel 格式PC 上直接用没问题但板载 MCU 跑浮点模型太奢侈了。这里的关键步骤是PTQ 量化把浮点权重映射到 8bit 整数模型体积缩到约 1/4推理速度提升数倍而精度损失通常在 1-3 个百分点以内完全可接受。转换流程我整理成了命令序列你在 PC 的 Python 环境里依次执行即可# 1. 把 h5 转成 tflite 格式 tflite_convert \ --saved_model_dirsaved_model \ --output_filemodel.tflite \ --input_shapes1,128,128,3 \ --input_arraysinput_1 \ --output_arraysIdentity # 2. 用代表性数据集做 PTQ 量化 python quantize_tflite.py # 3. 转成 C 数组方便直接塞进 RT-Thread 工程 xxd -i model_quant.tflite model_data.cquantize_tflite.py的核心部分是通过tf.lite.TFLiteConverter.from_saved_model加载模型设置optimizations[tf.lite.Optimize.DEFAULT]然后喂入一小部分代表性图像数据来统计激活值范围。这一步要注意代表性数据集最好准备约 100 张覆盖两种类别的图数量太少会导致量化统计不准确。转换完成后务必在 PC 端用tflite_runtime.interpreter跑一遍校验收敛确认量化前后的预测结果一致性再上板。model_data.c的内容就是一个大数组你要做的就是把model_quant.tflite文件复制到工程资源目录作为一个只读文件访问。我自己的习惯是放在板子的外置 Flash 文件系统路径下比如/models/defect_model.tflite这样以后模型迭代只需要通过文件系统替换文件不用重新编译固件。4.4 在 RT-Thread 上创建质检线程代码骨架与关键点部署到 RT-Thread 上核心工作可以拆成三件事读取模型文件、初始化推理器、创建质检线程。这里给一个精简的代码骨架用的是 NNoM 库配合 TensorFlow Lite 解析器的路线#include rtthread.h #include nnom.h #include dfs_posix.h static nnom_model_t *model; static uint8_t *input_buf; static uint8_t *output_buf; static void quality_inspect_thread_entry(void *param) { rt_err_t result; struct rt_sensor_data sensor_data; // 1. 从文件系统加载模型 int fd open(/models/defect_model.tflite, O_RDONLY); if (fd 0) { rt_kprintf(open model failed\n); return; } // 读取模型内容到内存初始化 NNoM model nnom_model_load(fd); close(fd); if (model RT_NULL) { rt_kprintf(load model failed\n); return; } input_buf (uint8_t *)nnom_model_input_buffer(model); output_buf (uint8_t *)nnom_model_output_buffer(model); while (1) { // 2. 触发摄像头采集一帧 rt_device_read(camera_dev, 0, sensor_data, sizeof(sensor_data)); // 3. 图像预处理裁剪、缩放、RGB转RGB888、归一化 preprocess_image(sensor_data.data, input_buf, 128, 128); // 4. 执行推理 nnom_model_run(model); // 5. 解析输出置信度超过阈值则判定缺陷 float ng_score output_buf[1] / 255.0f; if (ng_score 0.6f) { rt_pin_write(NG_LED_PIN, PIN_HIGH); rt_kprintf(NG detected, score%.2f\n, ng_score); } else { rt_pin_write(NG_LED_PIN, PIN_LOW); } rt_thread_mdelay(50); } }这段代码里有几个很隐蔽的坑值得单独说。第一nnom_model_load的返回值一定要检查为 NULL模型文件路径错误或文件系统未挂载都会导致加载失败不检查的话后续调用直接 HardFault排查起来很痛苦。第二输入缓冲区input_buf的尺寸必须严格等于128*128*3RGB565 转 RGB888 时要留意字节序否则你看到的花屏图片喂进去模型输出的置信度全是乱的。第三nnom_model_run执行完后输出缓冲区里是softmax结果但在量化模型里通常表示成 0 到 255 的整数记得像示例里这样除以 255 还原成概率值再做判断。4.5 触发方式轮询还是中断具体工况具体分析产线场景里相机的触发方式直接影响系统设计。最简单的做法是主循环里定时轮询拍摄间隔几百毫秒拍一帧适合演示和原型。如果需要跟产线节拍对齐就得引入外部触发——对射传感器检测到工件到位时拉一个 GPIO 电平中断服务程序里置一个拍照标志位质检线程看到标志位再采集并推理。用 RT-Thread 实现时我建议用rt_sem_take和rt_sem_release做触发信号同步而不是直接在 ISR 里做耗时操作。拍照和推理都是相对耗时的任务全部放在线程上下文里执行。触发信号量相当于是“产线节拍的节拍器”这种方式结构清晰后续加多工位也容易扩展。如果两个工件间隔时间小于一次推理耗时要在前面加排队或缓存否则会丢检。5. 实测定会踩的坑帧率、内存、误判率与调优手段5.1 帧率不等于产线节拍先把账算明白我见过不少开发者拿着 Demo很兴奋地跟我说“我这个推理只要 80ms一秒十几次产线绝对够用。”这里其实偷换了概念。完整的质检节拍不是只有推理时间而是“曝光 读图 预处理 推理 结果输出 IO 动作”的总和。实测下来光从摄像头读一帧 320x240 的 RGB565 图像在 SPI 接口的 OV2640 上就可能要 40ms 以上预处理还要再吃掉十几毫秒。最终一帧的完整周期常常是推理耗时的两倍以上一点不夸张。给你一个实测参考ESP32-S3 跑 MobileNetV1 alpha0.25 量化模型推理耗时约 85ms读图 35ms预处理缩放、格式转换 15ms串口打印结果 5ms。整链路约 140ms折合约 7 FPS。如果你的产线节拍是每秒 4 件这个速度刚好压线如果节拍到每秒 6 件就必须换带 NPU 的芯片或者缩小输入尺寸到 96x96 来提速精度上会有轻微损失但通常可以换。所以先算账再选型别拍脑袋。5.2 内存是 MCU 上最无情的考官MCU 上的内存规划是这种项目最劝退人的地方。拿 STM32F429 举例它的 RAM 通常是 256KB你已经觉得不小了但拆开算一下就会冒汗模型文件本身800KB存放在外置 Flash不占 RAM但加载时如果整包读入就爆了。NNoM 支持边读边解析模型体量在 80KB 以上时建议流式解析。输入图像缓冲区128x128x3 48KB。推理激活缓冲工作内存MobileNet 0.25 大约 80-120KB需要在配置工具里预留。RT-Thread 内核堆 线程栈 文件系统缓存至少 32KB。加起来已经逼近 200KB这还是没算屏幕缓冲、网络协议栈等附加功能的开销。内存优化的常见手段包括把图像采集缓冲区复用为输入缓冲区拍完一帧直接覆盖写将线程栈压到 4KB 以内关掉用不到的功能组件不勾选多余组件高级一点还可以把图像缩小到 96x96 再推理输入缓冲区直接省一半。每一个 KB 都得精打细算但当你把内存压到刚好装下所有模块的那一刻成就感也是真的强。5.3 误判率如何用“拒识”思路提升可用性模型不是神必然有误判。在实际的工业场景里误判分两种把坏的说成好的漏检把好的说成坏的误杀。漏检是安全事故误杀是效率损失。方向不同调优目标也不同。我最想分享的一条实战经验是给你的分类器加一个“不确定”的阈值区。假设模型输出 NG 的置信度是 0.9 表示很可能是缺陷0.3 表示很正常那么中间那一段比如 0.4 到 0.7是什么它可能是你没有训练过的缺陷形态也可能是拍照瞬间的模糊帧。这时候让样品进入“二次人工复检”通道而不是强行归入 OK 或 NG 任意一类反而能让整个系统的可靠性上一个台阶。具体实现就是在分类逻辑里加一个双阈值判断超过上限判缺陷低于下限判正常落在中间标记为“待复检”。这个“拒识”机制的收益在产线实测中非常明显——误杀率降下来了漏检率也没有上升。另一个容易忽略的细节是产品换型。早上检螺丝、下午检垫片模型需要切换。如果把模型 A 和模型 B 都存进文件系统通过 MSH 命令动态切换加载就能支持一条产线快速换型。RT-Thread 的文件系统在这里的价值就体现出来了模型即文件换型即换文件不需要重新编译。5.4 调试工具链MSH 就是你的质检调试台最后聊一下调试工具。这类项目的调试难点在于“不好复现”同一个缺陷灯一偏就不出现了同一张图像模型输出时好时坏。我的做法是让 MSH 承担调试台的角色而不是开关一堆日志宏。在固件里预留这么几条命令MSH_CMD_EXPORT(cap, capture one image and save to /images); MSH_CMD_EXPORT(infer, run inference on /images/test.jpg); MSH_CMD_EXPORT(set_th, set confidence threshold); MSH_CMD_EXPORT(info, show model info and memory usage);通过串口终端我可以随时触发一帧采集、单独跑一次推理、动态调整阈值甚至可以把图像直接写到 SD 卡里回放。这套交互方式的调试效率比反复烧固件高一个数量级。如果板子支持 LCD还能把输入图像实时显示出来直观看到预处理结果是否正常。这些手段放在产线现场的时候能救命。6. 从赛题到产线多工位、数据回流与“什么时候别用 AI”6.1 多工位与上下位机一个更接近真实的系统形态赛题要求大概率是一个单工位原型验证。但如果你去实际工厂待过就会发现产线不会只有一个质检工位一条流水线可能有四五个相机位分别检测不同角度模型可能是分散在每条线上的边缘盒子里的也可能有一个中心服务器汇总所有工位的检测结果。从赛题往真实产线走架构通常会长这样每个工位一个边缘计算盒子上面跑 RT-Thread 或小型 Linux当地完成实时推理每台边缘盒子通过局域网把“OK/NG 结果、置信度、缺陷类别、图像缩略图”上报到中控台中控台负责统计产线良率、按批次回溯缺陷、把新采集的误判样本导出用于下一轮模型迭代。这个闭环的最后一个环节非常关键——产线产生的数据才是模型持续进化的燃料。赛题如果只做到能检出来那是合格线能做到“检出后还能回流训练”这项目一下子就活了也更容易在评审中脱颖而出。6.2 什么时候 AI 不是答案做技术的容易犯“手里有锤子看什么都是钉子”的毛病。我必须补一句冷静话工业质检里有一大批场景传统视觉方案比 AI 更靠谱、更便宜、更可控。举个例子检测传送带上有没有工件遮挡一个光电开关就搞定测量一个精密零件的长度是否在公差内激光位移传感器加阈值判断比任何神经网络都准零件表面有明确的、固定的缺陷位置和形态传统模板匹配或灰度差分在速度和成本上远超 AI。我的判断标准很简单如果缺陷可以通过明确的物理规则描述就优先用传统方案只有缺陷形态复杂、规则写不清楚、检测对象变化频繁的场景才值得上 AI。AI 的优势在于泛化代价是可解释性差、调试成本高、数据依赖强。把这两者结合起来反而能做出更实用的项目比如先用传统视觉做初筛把明显 OK 的工件放行只有疑似样本才进 AI 模型做二次研判这样整个系统的吞吐量和可靠性都能显著提升。这种“传统 AI”的混合裁决策略我认为才是工业质检落地的正确姿势也是这种比赛的加分点。6.3 最后再分享一条实测出来的经验我在调试自己的第一个质检模型时踩过一个很离谱的坑模型在训练集上准确率 99%但一部署到板子上把验证集图片搬过去测试就只有 60%怎么都找不出原因。后来偶然发现我训练时的输入是 TensorFlow 默认的 RGB 通道顺序而板子摄像头出来的 RGB565 转 RGB888 后字节序反了——红色和蓝色通道互换了。模型学的是红色划痕板子喂进去的是蓝色划痕准确率当然崩。这种低级错误非常隐蔽排起来却极其耗时。排查方法是把板子上的输入图像用 MSH 命令直接导出成文件在 PC 上跟训练集图像并排对比。这个习惯我一直保持到现在任何一次模型上板都要先验图再验模型。工业质检 AI 不是一个需要仰望的题目它就是“图像采集 模型推理 工程调试”的配方。赛题给了开发者一个提前接触真实工业场景的机会顺着上面这条路子把链路打通把坑踩平你能收获的不仅是一个能演示的项目更是一套值得带进任何嵌入式 AI 项目的工程手感。