树莓派 5 的性能确实猛四核 A76 拉到 2.4GHz。但把它弄进车间跑自训的 YOLOv5 模型装 Ubuntu 只是第一步真正卡住我的全是平时想不到的破事。项目本身不复杂产线上装一套视觉检测用自己训练的 YOLOv5 模型识别工件缺陷树莓派 5 负责采集图像、跑模型、输出结果。本来计划三天部署完成实际从装箱起整整两周半才稳定下来。卡住我的不是模型精度也不是算法设计是六件小事供电、散热、系统、模型部署、相机触发、数据落盘。这篇不炫技全是现场记录每一件都会讲现象、原因、解决办法和坑位。如果你也想把树莓派 5 用到车间、仓库或者任何工业现场这份记录能帮你省下一两个星期。1. 进车间前我的整体设计与选型思路1.1 为什么偏偏选树莓派 5做视觉检测的方案其实不少。NVIDIA Jetson Orin Nano 性能更强但那阵子缺货且贵开发资料也比较分散x86 迷你主机随便一台都能跑可机房或者机柜里塞一台带风扇的电脑功耗和体积摆在那里做一个工位的成本也压不下来。树莓派 5 的好处是整套都齐板子、电源、SSD、摄像头几百块能配出一套而且 GPIO 可以直接接光电传感器和继电器省掉了一个额外的 IO 采集盒子这在预算紧张的项目里是很实在的加分项。更关键的是软件路线的判断。自训练的 YOLOv5 模型只要推理框架选对四核 A76 上做实时检测是有戏的。我在开发台上先验证过一轮PyTorch 直接推理只有不到 1 FPS但是换了轻量级推理框架之后能到 10 FPS 以上这个前提一旦成立选型就说得通了。如果当初模型再大一点比如 YOLOv5m 或者精度要求更高的 YOLOv8、RT-DETR结论就得改成 Jetson。所以我的建议是树莓派 5 适合小目标、单路相机、轻量模型这样的小型检测场景不适合多路视频或者超大模型的工业视觉服务器。1.2 车间环境下不得不在意的四件事把开发台上跑通的方案搬进车间完全是换了一种生存环境。我提前列了四个和实验室不一样的点结果每一个都成了后面翻车的导火索。第一是电源。车间里 380V 电机的启停很频繁电网电压会跟着波动普通 USB 充电器在电压跌落时几乎没有任何缓冲能力。第二是散热。夏天车间环境温度能到 35℃ 以上树莓派 5 满载时的发热明显比树莓派 4 高出一大截被动散热基本压不住。第三是网络和运维。现场不可能给你配一个显示器加键盘一切操作都靠远程网络一断就得整个人跑进车间。第四是防护。车间里有灰尘、震动、金属碎屑裸板直接暴露在外面迟早要出问题不是短路就是信号干扰。这四条后面全部以我没预料到的方式爆发了。下面把这六件事逐件说清楚每一件都对应一个真实翻车现场。2. 现场卡住我的六件事逐一拆开讲2.1 供电不是插上电源适配器就能跑第一件事也最朴素——供电。树莓派 5 官方要求 5V/5A 的 USB-C我用的 8GB 版本在满载时可以轻松跑到 20W 以上。一开始我图省事拿了块普通手机充电头去顶结果流水线一启动电控柜旁边的大电机一吸合系统就直接重启。重启一次推理服务要重新拉起来中间几十个工件没检测到这种事故在产线上是不可能被接受的。我用万用表盯了 USB-C 口上的电压空载 5.1V 一切正常电机启动瞬间掉到 4.5V 左右虽然只持续了不到一秒但树莓派 5 内部的电源管理芯片只要检测到欠压就会立刻重启或者干脆锁死。这事分两个层面一是电源本身带载能力太弱、纹波太大二是外部电网的冲击没有任何缓冲就传了进来。我的解决办法分两步。先用导轨式工业电源5V/5A 规格替代消费级充电器这类电源的调整率和纹波指标完全不在一个级别然后在供电入口加了一个小型直流 UPS 模块里面电容组足够扛过几百毫秒的电压缺口。处理完之后再查vcgencmd get_throttled欠压标志位就再也没出现过。这里提醒一句树莓派 5 的 USB-C 线材电阻也会造成可观的压降换了电源还不稳先检查那根线是不是正经的 5A 线。2.2 散热温度墙比想象中来得快得多第二件事是散热。开发台在空调房25℃我用一个铝壳被动散热跑 YOLOv5温度能压在 82℃ 左右勉强不降频。进了车间完全两样环境温度先给你加了十度推理又是满负载的活四核 A76 全部顶在 2.4GHz 上跑不到两分钟就撞上 85℃ 的温度墙主频被一路降下来推理时间从 80 毫秒变成 140 毫秒以上检测节拍跟不上产线开始连续漏检。散热方案我后来换成了铝合金外壳加一个 5V 涡轮风扇气流从进风口进来直接吹过散热片排出去温度从 85℃ 压到 65℃ 上下。这里有条重要的经验风扇不要接到 3.3V 引脚上长期转也不要指望系统默认的 PWM 策略能管好它。我在 config.txt 里配了 gpio-fan 的 dtoverlay设定温度阈值比如 50℃ 开启、45℃ 关闭让风扇按需求转既安静又不容易进灰堵转。还有一个细节很容易被忽略防尘。金属粉尘和纤维絮一旦糊住散热片风冷效果断崖式下降。我在机箱进风口贴了一层粗滤棉每周用压空吹一次一个月拆开清一次。温度记录显示加了防尘措施之后风扇转速和 CPU 温度都稳定了很多不再出现运行几天后性能下降的情况。2.3 系统树莓派 5 安装 Ubuntu 的坑第三件事听上去最简单装系统。我选的是 Ubuntu 24.04 LTS 而不是官方树莓派系统原因很实际团队其他服务器都是 Ubuntu部署脚本、systemd 服务、网络配置可以直接复用aarch64 的软件生态也完整。但树莓派 5 装 Ubuntu 的第一个坑出在启动介质上。一开始我把 Ubuntu Server 写在 128GB 的 A2 高速 SD 卡里。开发台用着完全正常到车间就不行了供电波动那几次SD 卡上的文件系统连续报错有一次直接进不了系统。现场没有显示器排查只能靠串口和猜反复折腾了两天。后来我确定要换 NVMe SSD因为树莓派 5 的 PCIe 接口可以接 M.2 硬盘NVMe 在掉电保护和抗写入方面比 SD 卡强得多系统从上面启动稳定性肉眼可见提升。让树莓派 5 从 NVMe 引导并不是插上就能用关键一步是更新启动 EEPROM。先用 SD 卡进系统执行sudo rpi-eeprom-update把 bootloader 升到最新再用sudo rpi-eeprom-config确认引导顺序里包含了 NVMe。然后我用整盘复制的方式把 SD 卡系统搬到 NVMe改好 fstab 的 PARTUUID拔卡重启完成迁移。这个过程中最容易被忽略的就是没有先更新 EEPROM结果系统明明写进了 NVMe树莓派 5 却完全不认直接开机失败。换完 NVMe 之后建议用lspci -vvv看一眼 PCIe 协商速率如果跑在低速档位接口或者排线大概率没装好。2.4 模型自训练 YOLOv5 上车后的性能问题第四件事是最核心的树莓派 5 上部署自己训练的 YOLOv5 模型。模型是在 GPU 机器上用 YOLOv5s 结构、640 输入训练的精度在线但搬到树莓派上一跑性能完全不够。我先在 Ubuntu 上装了 PyTorch 的 aarch64 CPU 版本单张 640 的图推理一次要 1.2 秒以上加载模型还得等十几秒1 FPS 不到的实时性对产线来说等于摆设。然后换成 ONNX Runtime把best.pt导出成 ONNX速度提升到 3 FPS 左右还是不够。最后用 NCNN 才解决转成 NCNN 格式再做 INT8 量化。给一个直观的对比数据推理方案单帧耗时实际效果PyTorch CPU (aarch64)1200ms 以上无法实时ONNX Runtime (CPU)330ms 左右勉强但节拍不够NCNN FP32180ms 左右可用于原型验证NCNN INT8 量化70ms 左右现场最终方案12~15 FPS转换流程本身不复杂在 PC 上用yolo export modelbest.pt formatonnx imgsz640 opset12导出 ONNX再用 ncnn 工具链转成 param 和 bin然后做算子融合和 INT8 量化。量化后模型体积从 14MB 降到 5MB 上下推理速度直接翻倍。但量化不是免费的坑在精度。第一次量化完我的模型 mAP 掉了差不多两个点现场误检率高到不能接受。问题根源是校准集选错了我用的是训练集里的白底图片而现场是复杂背景加车间光照。解决办法是用现场实拍的气源图做校准集换完之后误检率立刻回落。如果你的项目对精度极其敏感又不想做量化可以退一步用 FP32 并把输入从 640 降到 416能换一点速度但整体性价比远不如 INT8。另外说一句实战建议实时推理尽量用 C。Python 层的数据拷贝在视觉任务里会白白吃掉几十毫秒别在这上面省钱。我最终的推理程序是 C 写的NCNN 模型加载、推理、后处理全在一个进程里完成Python 只负责业务逻辑和 PLC 通信。2.5 相机触发采集与流水线同步第五件事是集成里最容易被低估的环节。相机装在流水线上方树莓派 5 在旁边的机柜里中间隔了几米原来的 CSI 软排线长度根本不够。我试过长一点的 CSI 排线结果车间电磁环境一复杂图像就开始花屏、撕裂、掉帧视觉系统的可信度直接崩塌。后来我把相机换成了 USB 接口的工业相机线材换成带磁环的线信号问题基本消失但新的问题来了USB 相机的采集时序抖动变大。检测需求是光电传感器检测到工件到位的瞬间相机抓拍一张清晰图片然后立刻推理。USB 相机从收到命令到真正出帧延迟抖动经常有几十甚至几百毫秒这种不可控的时序和产线节拍是硬冲突靠 sleep 对齐根本不可靠。我最后的方案是时间戳对齐。相机用 V4L2 的缓冲队列不停抓帧每帧记录硬件时间戳放进环形队列GPIO 上接光电传感器用 libgpiod 监听下降沿触发到达时记录一个高精度时间戳后台程序去环形队列里找离触发时间最近的帧来推理。实测下来几百毫秒的抖动被完全吸收每帧都能抓到接近触发时刻的画面比任何命令-响应方式都稳。接线这里我额外提醒车间光电传感器输出大多是 24V 电平树莓派 GPIO 只能承受 3.3V直接接必烧。我加了一片光耦把 24V 侧和 3.3V 侧完全隔离触发信号经光耦转成干净电平再进 GPIO。这个细节处理不好轻则误触发重则 GPIO 口报废换一块树莓派 5 事小产线停机的损失才是大头。2.6 运维数据落盘与远程管理的坑第六件事看似最没有技术含量实际最折磨人。检测每过一个工件都要记录时间、合格与否、缺陷类别和置信度一天下来几万到十几万行记录。我最初直接往 SQLite 里写结果一次现场断电数据库文件损坏几天的数据全没了。车间不比办公室断电、急停、设备维护关机都是家常便饭数据落盘必须按最恶劣情况设计。我现在是这么做的结果写入 NVMe 上的 SQLite开启 WAL 模式和PRAGMA synchronousFULL每 500 次写入做一次 checkpoint另起一个看门狗脚本每 10 秒检查一次推理进程的心跳文件异常就重启服务。这样即使偶尔断电最多损失最后一次未提交的事务拿不回当天前前后后的数据完整性还是能保证的。远程运维方面树莓派 5 装在机柜里没有显示器我的做法是固定网段 IPSSH 密钥登录日志用 journald 转发到主控服务器模型更新直接 scp 覆盖再重启服务。systemd 服务的Restartalways一定要设置并且要实测过进程被异常杀掉后能自动拉起来。我还开启了内核硬件看门狗在 systemd 配置里加上RuntimeWatchdogSec14系统如果假死会自动硬重启不用你专门跑一次车间去按电源键。3. 实操过程与核心环节实现3.1 Ubuntu 24.04 安装与 NVMe 引导迁移把这套环境复现出来并不难我按自己实际操作顺序整理一遍。先准备树莓派 5建议 8GB 版本、M.2 HAT、一块 NVMe SSD、一张 32GB SD 卡当临时启动盘。用 Raspberry Pi Imager 把 Ubuntu Server 24.04 镜像写到 SD 卡开机进系统后先更新系统包然后安装 M.2 HAT插好 NVMe SSD连接 PCIe FPC 排线。注意排线有正反面卡扣要按紧安装不到位系统识别不到硬盘。接着更新 EEPROM 和引导顺序。执行sudo rpi-eeprom-update -a升级 bootloader再用sudo rpi-eeprom-config -e把 BOOT_ORDER 调整成 NVMe 优先。这一步必须做很多人换完 NVMe 起不来就是卡在这里。系统迁移我用的是整盘复制sudo dd if/dev/mmcblk0 of/dev/nvme0n1 bs4M statusprogress复制完成后用sudo blkid查看 NVMe 的 PARTUUID对应修改 fstab。然后关机、拔 SD 卡、重新开机用nvme list和lspci -vvv确认硬盘识别正常。最后配置 netplan 固定 IP开启 SSH关掉 ModemManager 这些用不到的服务打开 systemd watchdog系统层面就算稳定了。3.2 YOLOv5 模型转换与 NCNN 部署模型转换的完整链路可以这么走。在 PC 上先导出 ONNX 文件yolo export modelbest.pt formatonnx imgsz640 opset12然后在 PC 上使用 ncnn 转换工具把 ONNX 转成 NCNN 的 param 和 bin 两个文件再用ncnnoptimize做算子融合生成优化后的模型。如果要做 INT8 量化需要用现场实拍图片生成校准集执行ncnn2table生成校准表再执行ncnn2int8得到量化模型。这里量化的校准集一定用车间实际拍摄的画面不要用训练集图片否则精度掉得很快。在树莓派 5 上编译 NCNN 时我用了一组针对 A76 核心优化的编译参数git clone https://github.com/Tencent/ncnn cd ncnn mkdir build cd build cmake -DCMAKE_BUILD_TYPERelease \ -DCMAKE_CXX_FLAGS-O3 -mcpucortex-a76 \ -DNCNN_VULKANOFF -DNCNN_BUILD_EXAMPLESON .. make -j4编译完成后把转换好的模型文件放到树莓派上用 NCNN 自带的 yolov5 示例程序跑通一次确认输出和 PC 上一致再进行业务封装。注意类别数量和自定义类别名要在读取模型时对应上否则后处理结果全错。3.3 推理服务的稳定化与性能调优模型能跑起来之后还有一个从能跑到跑得稳的过程。我做了三件比较关键的调优。第一是 CPU 绑定。四核 A76 上我把 NCNN 推理线程绑定到 CPU 2 和 3 两个核心上把采集、GPIO 监听、心跳上报这类系统任务放在 CPU 0 上避免互相争抢。同时把 CPU 调成 performance 模式保证推理时主频不会因为省电策略掉下来。第二是启动预热。模型刚加载完第一次推理会比较慢因为涉及大量内存分配和算子初始化。我在服务启动流程里加了一轮空跑预热把首次推理的延迟从启动阶段挪到后台正式检测的第一个工件就是正常速度。第三是内存控制。树莓派 5 内存够大不代表可以随意挥霍我把 swap 调低到 10控制推理进程常驻内存的上限并关闭不必要的桌面服务和后台定时任务。部署之后连续观测了两周推理服务的波动非常小没有出现内存泄漏导致重启的情况。4. 现场问题排查与避坑技巧4.1 问题速查表把这次踩过的坑整理成一张表现场遇到同类问题可以直接照着查。现象直接原因解决办法随机重启日志提示欠压电源带载不足市电波动换 5V/5A 工业电源加直流 UPS 模块推理变慢主频降低温度墙触发降频主动风冷加 gpio-fan 温控SD 卡文件系统损坏无法启动供电波动SD 写入可靠性差换 NVMe SSD更新 EEPROM 引导推理只有 1 FPSPyTorch 直接推理转 ONNX/NCNN做 INT8 量化INT8 后误检增多量化校准集和现场差异大用现场实拍图生成校准集图像花屏、撕裂长 CSI 排线受电磁干扰换 USB 工业相机加磁环屏蔽抓拍时机不准USB 相机响应延迟抖动时间戳对齐环形缓冲取最近帧GPIO 烧毁或误触发24V 信号直连 3.3V GPIO加光耦隔离断电后数据库损坏SQLite 默认同步模式WAL 模式加 synchronousFULL系统假死需要现场重启长期运行不稳定硬件看门狗加 systemd 自动重启4.2 几条只有实际跑过之后才会明白的经验上产线之前一定要拷机。我最开始把系统搬到车间空跑了 72 小时前 24 小时就把供电和散热的问题揪出来了。如果直接接产线问题爆发的时间点一定是最忙的时候一边赶产量一边排障才是最难受的。保留一套冷备份。系统镜像、EEPROM 配置、模型文件、部署脚本、fstab、netplan 配置打包放在文件服务器上。现场板子坏了不用排查直接换新板恢复我实测从拆机到恢复运行半小时不到。给调试留串口。别只依赖 SSH 和无线网络车间环境对无线信号很不友好。我在机箱前面板留了一根 USB 转 TTL 串口线系统彻底起不来的时候串口是唯一靠谱的调试通道。不要裸板运行。金属粉尘、潮湿、震动随便一样都够你头疼。至少给板子喷三防漆最好用一个正经的工业铝合金外壳。风扇进风口加滤棉定期清理这比买再贵的散热器都管用。配置一定要版本化。现场调试、模型迭代都会改配置时间一长连自己都会忘了改过哪里。我在板子上建了 git 仓库每次调整都提交一次回滚非常方便。更关键的是我在每张推理结果里都带上了模型版本号和当前阈值参数这样排查历史误检时永远能查出来是哪一版模型、哪一组参数做出的判断。最后再说一点个人的体会。这次项目里树莓派 5 的硬件本身反而很争气没出过岔子真正考验人的是把消费级设备按工业级标准来用。供电、散热、隔离、运维每一步都是在给这台小电脑补一层工业外衣。我那套设备现在已经在产线上稳定跑了两周多每天两班倒推理服务零重启。如果让我总结一条最值得分享的技巧那就是现场调试时把vcgencmd get_throttled的输出直接写进日志每次巡检扫一眼欠压和热降频的历史一目了然。这个习惯帮我提前发现过两次电源接触不良每次都省下了大半天排查时间。 
长河君 · 2026/10/31 1:04:49 · 阅读 1.2k 树莓派5工业视觉部署实战：从供电到模型量化的完整记录
树莓派 5 的性能确实猛四核 A76 拉到 2.4GHz。但把它弄进车间跑自训的 YOLOv5 模型装 Ubuntu 只是第一步真正卡住我的全是平时想不到的破事。项目本身不复杂产线上装一套视觉检测用自己训练的 YOLOv5 模型识别工件缺陷树莓派 5 负责采集图像、跑模型、输出结果。本来计划三天部署完成实际从装箱起整整两周半才稳定下来。卡住我的不是模型精度也不是算法设计是六件小事供电、散热、系统、模型部署、相机触发、数据落盘。这篇不炫技全是现场记录每一件都会讲现象、原因、解决办法和坑位。如果你也想把树莓派 5 用到车间、仓库或者任何工业现场这份记录能帮你省下一两个星期。1. 进车间前我的整体设计与选型思路1.1 为什么偏偏选树莓派 5做视觉检测的方案其实不少。NVIDIA Jetson Orin Nano 性能更强但那阵子缺货且贵开发资料也比较分散x86 迷你主机随便一台都能跑可机房或者机柜里塞一台带风扇的电脑功耗和体积摆在那里做一个工位的成本也压不下来。树莓派 5 的好处是整套都齐板子、电源、SSD、摄像头几百块能配出一套而且 GPIO 可以直接接光电传感器和继电器省掉了一个额外的 IO 采集盒子这在预算紧张的项目里是很实在的加分项。更关键的是软件路线的判断。自训练的 YOLOv5 模型只要推理框架选对四核 A76 上做实时检测是有戏的。我在开发台上先验证过一轮PyTorch 直接推理只有不到 1 FPS但是换了轻量级推理框架之后能到 10 FPS 以上这个前提一旦成立选型就说得通了。如果当初模型再大一点比如 YOLOv5m 或者精度要求更高的 YOLOv8、RT-DETR结论就得改成 Jetson。所以我的建议是树莓派 5 适合小目标、单路相机、轻量模型这样的小型检测场景不适合多路视频或者超大模型的工业视觉服务器。1.2 车间环境下不得不在意的四件事把开发台上跑通的方案搬进车间完全是换了一种生存环境。我提前列了四个和实验室不一样的点结果每一个都成了后面翻车的导火索。第一是电源。车间里 380V 电机的启停很频繁电网电压会跟着波动普通 USB 充电器在电压跌落时几乎没有任何缓冲能力。第二是散热。夏天车间环境温度能到 35℃ 以上树莓派 5 满载时的发热明显比树莓派 4 高出一大截被动散热基本压不住。第三是网络和运维。现场不可能给你配一个显示器加键盘一切操作都靠远程网络一断就得整个人跑进车间。第四是防护。车间里有灰尘、震动、金属碎屑裸板直接暴露在外面迟早要出问题不是短路就是信号干扰。这四条后面全部以我没预料到的方式爆发了。下面把这六件事逐件说清楚每一件都对应一个真实翻车现场。2. 现场卡住我的六件事逐一拆开讲2.1 供电不是插上电源适配器就能跑第一件事也最朴素——供电。树莓派 5 官方要求 5V/5A 的 USB-C我用的 8GB 版本在满载时可以轻松跑到 20W 以上。一开始我图省事拿了块普通手机充电头去顶结果流水线一启动电控柜旁边的大电机一吸合系统就直接重启。重启一次推理服务要重新拉起来中间几十个工件没检测到这种事故在产线上是不可能被接受的。我用万用表盯了 USB-C 口上的电压空载 5.1V 一切正常电机启动瞬间掉到 4.5V 左右虽然只持续了不到一秒但树莓派 5 内部的电源管理芯片只要检测到欠压就会立刻重启或者干脆锁死。这事分两个层面一是电源本身带载能力太弱、纹波太大二是外部电网的冲击没有任何缓冲就传了进来。我的解决办法分两步。先用导轨式工业电源5V/5A 规格替代消费级充电器这类电源的调整率和纹波指标完全不在一个级别然后在供电入口加了一个小型直流 UPS 模块里面电容组足够扛过几百毫秒的电压缺口。处理完之后再查vcgencmd get_throttled欠压标志位就再也没出现过。这里提醒一句树莓派 5 的 USB-C 线材电阻也会造成可观的压降换了电源还不稳先检查那根线是不是正经的 5A 线。2.2 散热温度墙比想象中来得快得多第二件事是散热。开发台在空调房25℃我用一个铝壳被动散热跑 YOLOv5温度能压在 82℃ 左右勉强不降频。进了车间完全两样环境温度先给你加了十度推理又是满负载的活四核 A76 全部顶在 2.4GHz 上跑不到两分钟就撞上 85℃ 的温度墙主频被一路降下来推理时间从 80 毫秒变成 140 毫秒以上检测节拍跟不上产线开始连续漏检。散热方案我后来换成了铝合金外壳加一个 5V 涡轮风扇气流从进风口进来直接吹过散热片排出去温度从 85℃ 压到 65℃ 上下。这里有条重要的经验风扇不要接到 3.3V 引脚上长期转也不要指望系统默认的 PWM 策略能管好它。我在 config.txt 里配了 gpio-fan 的 dtoverlay设定温度阈值比如 50℃ 开启、45℃ 关闭让风扇按需求转既安静又不容易进灰堵转。还有一个细节很容易被忽略防尘。金属粉尘和纤维絮一旦糊住散热片风冷效果断崖式下降。我在机箱进风口贴了一层粗滤棉每周用压空吹一次一个月拆开清一次。温度记录显示加了防尘措施之后风扇转速和 CPU 温度都稳定了很多不再出现运行几天后性能下降的情况。2.3 系统树莓派 5 安装 Ubuntu 的坑第三件事听上去最简单装系统。我选的是 Ubuntu 24.04 LTS 而不是官方树莓派系统原因很实际团队其他服务器都是 Ubuntu部署脚本、systemd 服务、网络配置可以直接复用aarch64 的软件生态也完整。但树莓派 5 装 Ubuntu 的第一个坑出在启动介质上。一开始我把 Ubuntu Server 写在 128GB 的 A2 高速 SD 卡里。开发台用着完全正常到车间就不行了供电波动那几次SD 卡上的文件系统连续报错有一次直接进不了系统。现场没有显示器排查只能靠串口和猜反复折腾了两天。后来我确定要换 NVMe SSD因为树莓派 5 的 PCIe 接口可以接 M.2 硬盘NVMe 在掉电保护和抗写入方面比 SD 卡强得多系统从上面启动稳定性肉眼可见提升。让树莓派 5 从 NVMe 引导并不是插上就能用关键一步是更新启动 EEPROM。先用 SD 卡进系统执行sudo rpi-eeprom-update把 bootloader 升到最新再用sudo rpi-eeprom-config确认引导顺序里包含了 NVMe。然后我用整盘复制的方式把 SD 卡系统搬到 NVMe改好 fstab 的 PARTUUID拔卡重启完成迁移。这个过程中最容易被忽略的就是没有先更新 EEPROM结果系统明明写进了 NVMe树莓派 5 却完全不认直接开机失败。换完 NVMe 之后建议用lspci -vvv看一眼 PCIe 协商速率如果跑在低速档位接口或者排线大概率没装好。2.4 模型自训练 YOLOv5 上车后的性能问题第四件事是最核心的树莓派 5 上部署自己训练的 YOLOv5 模型。模型是在 GPU 机器上用 YOLOv5s 结构、640 输入训练的精度在线但搬到树莓派上一跑性能完全不够。我先在 Ubuntu 上装了 PyTorch 的 aarch64 CPU 版本单张 640 的图推理一次要 1.2 秒以上加载模型还得等十几秒1 FPS 不到的实时性对产线来说等于摆设。然后换成 ONNX Runtime把best.pt导出成 ONNX速度提升到 3 FPS 左右还是不够。最后用 NCNN 才解决转成 NCNN 格式再做 INT8 量化。给一个直观的对比数据推理方案单帧耗时实际效果PyTorch CPU (aarch64)1200ms 以上无法实时ONNX Runtime (CPU)330ms 左右勉强但节拍不够NCNN FP32180ms 左右可用于原型验证NCNN INT8 量化70ms 左右现场最终方案12~15 FPS转换流程本身不复杂在 PC 上用yolo export modelbest.pt formatonnx imgsz640 opset12导出 ONNX再用 ncnn 工具链转成 param 和 bin然后做算子融合和 INT8 量化。量化后模型体积从 14MB 降到 5MB 上下推理速度直接翻倍。但量化不是免费的坑在精度。第一次量化完我的模型 mAP 掉了差不多两个点现场误检率高到不能接受。问题根源是校准集选错了我用的是训练集里的白底图片而现场是复杂背景加车间光照。解决办法是用现场实拍的气源图做校准集换完之后误检率立刻回落。如果你的项目对精度极其敏感又不想做量化可以退一步用 FP32 并把输入从 640 降到 416能换一点速度但整体性价比远不如 INT8。另外说一句实战建议实时推理尽量用 C。Python 层的数据拷贝在视觉任务里会白白吃掉几十毫秒别在这上面省钱。我最终的推理程序是 C 写的NCNN 模型加载、推理、后处理全在一个进程里完成Python 只负责业务逻辑和 PLC 通信。2.5 相机触发采集与流水线同步第五件事是集成里最容易被低估的环节。相机装在流水线上方树莓派 5 在旁边的机柜里中间隔了几米原来的 CSI 软排线长度根本不够。我试过长一点的 CSI 排线结果车间电磁环境一复杂图像就开始花屏、撕裂、掉帧视觉系统的可信度直接崩塌。后来我把相机换成了 USB 接口的工业相机线材换成带磁环的线信号问题基本消失但新的问题来了USB 相机的采集时序抖动变大。检测需求是光电传感器检测到工件到位的瞬间相机抓拍一张清晰图片然后立刻推理。USB 相机从收到命令到真正出帧延迟抖动经常有几十甚至几百毫秒这种不可控的时序和产线节拍是硬冲突靠 sleep 对齐根本不可靠。我最后的方案是时间戳对齐。相机用 V4L2 的缓冲队列不停抓帧每帧记录硬件时间戳放进环形队列GPIO 上接光电传感器用 libgpiod 监听下降沿触发到达时记录一个高精度时间戳后台程序去环形队列里找离触发时间最近的帧来推理。实测下来几百毫秒的抖动被完全吸收每帧都能抓到接近触发时刻的画面比任何命令-响应方式都稳。接线这里我额外提醒车间光电传感器输出大多是 24V 电平树莓派 GPIO 只能承受 3.3V直接接必烧。我加了一片光耦把 24V 侧和 3.3V 侧完全隔离触发信号经光耦转成干净电平再进 GPIO。这个细节处理不好轻则误触发重则 GPIO 口报废换一块树莓派 5 事小产线停机的损失才是大头。2.6 运维数据落盘与远程管理的坑第六件事看似最没有技术含量实际最折磨人。检测每过一个工件都要记录时间、合格与否、缺陷类别和置信度一天下来几万到十几万行记录。我最初直接往 SQLite 里写结果一次现场断电数据库文件损坏几天的数据全没了。车间不比办公室断电、急停、设备维护关机都是家常便饭数据落盘必须按最恶劣情况设计。我现在是这么做的结果写入 NVMe 上的 SQLite开启 WAL 模式和PRAGMA synchronousFULL每 500 次写入做一次 checkpoint另起一个看门狗脚本每 10 秒检查一次推理进程的心跳文件异常就重启服务。这样即使偶尔断电最多损失最后一次未提交的事务拿不回当天前前后后的数据完整性还是能保证的。远程运维方面树莓派 5 装在机柜里没有显示器我的做法是固定网段 IPSSH 密钥登录日志用 journald 转发到主控服务器模型更新直接 scp 覆盖再重启服务。systemd 服务的Restartalways一定要设置并且要实测过进程被异常杀掉后能自动拉起来。我还开启了内核硬件看门狗在 systemd 配置里加上RuntimeWatchdogSec14系统如果假死会自动硬重启不用你专门跑一次车间去按电源键。3. 实操过程与核心环节实现3.1 Ubuntu 24.04 安装与 NVMe 引导迁移把这套环境复现出来并不难我按自己实际操作顺序整理一遍。先准备树莓派 5建议 8GB 版本、M.2 HAT、一块 NVMe SSD、一张 32GB SD 卡当临时启动盘。用 Raspberry Pi Imager 把 Ubuntu Server 24.04 镜像写到 SD 卡开机进系统后先更新系统包然后安装 M.2 HAT插好 NVMe SSD连接 PCIe FPC 排线。注意排线有正反面卡扣要按紧安装不到位系统识别不到硬盘。接着更新 EEPROM 和引导顺序。执行sudo rpi-eeprom-update -a升级 bootloader再用sudo rpi-eeprom-config -e把 BOOT_ORDER 调整成 NVMe 优先。这一步必须做很多人换完 NVMe 起不来就是卡在这里。系统迁移我用的是整盘复制sudo dd if/dev/mmcblk0 of/dev/nvme0n1 bs4M statusprogress复制完成后用sudo blkid查看 NVMe 的 PARTUUID对应修改 fstab。然后关机、拔 SD 卡、重新开机用nvme list和lspci -vvv确认硬盘识别正常。最后配置 netplan 固定 IP开启 SSH关掉 ModemManager 这些用不到的服务打开 systemd watchdog系统层面就算稳定了。3.2 YOLOv5 模型转换与 NCNN 部署模型转换的完整链路可以这么走。在 PC 上先导出 ONNX 文件yolo export modelbest.pt formatonnx imgsz640 opset12然后在 PC 上使用 ncnn 转换工具把 ONNX 转成 NCNN 的 param 和 bin 两个文件再用ncnnoptimize做算子融合生成优化后的模型。如果要做 INT8 量化需要用现场实拍图片生成校准集执行ncnn2table生成校准表再执行ncnn2int8得到量化模型。这里量化的校准集一定用车间实际拍摄的画面不要用训练集图片否则精度掉得很快。在树莓派 5 上编译 NCNN 时我用了一组针对 A76 核心优化的编译参数git clone https://github.com/Tencent/ncnn cd ncnn mkdir build cd build cmake -DCMAKE_BUILD_TYPERelease \ -DCMAKE_CXX_FLAGS-O3 -mcpucortex-a76 \ -DNCNN_VULKANOFF -DNCNN_BUILD_EXAMPLESON .. make -j4编译完成后把转换好的模型文件放到树莓派上用 NCNN 自带的 yolov5 示例程序跑通一次确认输出和 PC 上一致再进行业务封装。注意类别数量和自定义类别名要在读取模型时对应上否则后处理结果全错。3.3 推理服务的稳定化与性能调优模型能跑起来之后还有一个从能跑到跑得稳的过程。我做了三件比较关键的调优。第一是 CPU 绑定。四核 A76 上我把 NCNN 推理线程绑定到 CPU 2 和 3 两个核心上把采集、GPIO 监听、心跳上报这类系统任务放在 CPU 0 上避免互相争抢。同时把 CPU 调成 performance 模式保证推理时主频不会因为省电策略掉下来。第二是启动预热。模型刚加载完第一次推理会比较慢因为涉及大量内存分配和算子初始化。我在服务启动流程里加了一轮空跑预热把首次推理的延迟从启动阶段挪到后台正式检测的第一个工件就是正常速度。第三是内存控制。树莓派 5 内存够大不代表可以随意挥霍我把 swap 调低到 10控制推理进程常驻内存的上限并关闭不必要的桌面服务和后台定时任务。部署之后连续观测了两周推理服务的波动非常小没有出现内存泄漏导致重启的情况。4. 现场问题排查与避坑技巧4.1 问题速查表把这次踩过的坑整理成一张表现场遇到同类问题可以直接照着查。现象直接原因解决办法随机重启日志提示欠压电源带载不足市电波动换 5V/5A 工业电源加直流 UPS 模块推理变慢主频降低温度墙触发降频主动风冷加 gpio-fan 温控SD 卡文件系统损坏无法启动供电波动SD 写入可靠性差换 NVMe SSD更新 EEPROM 引导推理只有 1 FPSPyTorch 直接推理转 ONNX/NCNN做 INT8 量化INT8 后误检增多量化校准集和现场差异大用现场实拍图生成校准集图像花屏、撕裂长 CSI 排线受电磁干扰换 USB 工业相机加磁环屏蔽抓拍时机不准USB 相机响应延迟抖动时间戳对齐环形缓冲取最近帧GPIO 烧毁或误触发24V 信号直连 3.3V GPIO加光耦隔离断电后数据库损坏SQLite 默认同步模式WAL 模式加 synchronousFULL系统假死需要现场重启长期运行不稳定硬件看门狗加 systemd 自动重启4.2 几条只有实际跑过之后才会明白的经验上产线之前一定要拷机。我最开始把系统搬到车间空跑了 72 小时前 24 小时就把供电和散热的问题揪出来了。如果直接接产线问题爆发的时间点一定是最忙的时候一边赶产量一边排障才是最难受的。保留一套冷备份。系统镜像、EEPROM 配置、模型文件、部署脚本、fstab、netplan 配置打包放在文件服务器上。现场板子坏了不用排查直接换新板恢复我实测从拆机到恢复运行半小时不到。给调试留串口。别只依赖 SSH 和无线网络车间环境对无线信号很不友好。我在机箱前面板留了一根 USB 转 TTL 串口线系统彻底起不来的时候串口是唯一靠谱的调试通道。不要裸板运行。金属粉尘、潮湿、震动随便一样都够你头疼。至少给板子喷三防漆最好用一个正经的工业铝合金外壳。风扇进风口加滤棉定期清理这比买再贵的散热器都管用。配置一定要版本化。现场调试、模型迭代都会改配置时间一长连自己都会忘了改过哪里。我在板子上建了 git 仓库每次调整都提交一次回滚非常方便。更关键的是我在每张推理结果里都带上了模型版本号和当前阈值参数这样排查历史误检时永远能查出来是哪一版模型、哪一组参数做出的判断。最后再说一点个人的体会。这次项目里树莓派 5 的硬件本身反而很争气没出过岔子真正考验人的是把消费级设备按工业级标准来用。供电、散热、隔离、运维每一步都是在给这台小电脑补一层工业外衣。我那套设备现在已经在产线上稳定跑了两周多每天两班倒推理服务零重启。如果让我总结一条最值得分享的技巧那就是现场调试时把vcgencmd get_throttled的输出直接写进日志每次巡检扫一眼欠压和热降频的历史一目了然。这个习惯帮我提前发现过两次电源接触不良每次都省下了大半天排查时间。