车间里一台旧工控机坏了维修报价吓人新工控机动辄四五千元。我手里刚好有一台树莓派5心想不就是跑个视觉识别吗这玩意几百块钱CPU理论上也不算弱是不是能顶上去结果理想很丰满现实连扇耳光——从装系统开始到把自训练的YOLOv5模型跑起来再到车间里又脏又乱的电源和高温环境我被六件事硬生生卡了一个多月。这篇文章就按踩坑顺序把这六件事写出来给想把树莓派5搬进车间当“便宜视觉终端”的兄弟们一个参考。我当时的任务其实很简单一条老产线上需要给料框计数和读仪表盘数字原来那台工控机坏了PLC侧的数据要捞出来图像要走一个轻量识别模型。算上摄像头、传感器、继电器预算就一千块。Jetson Orin Nano单板要两千上下二手工控机怕翻新件最后我选了树莓派5。后面的事实证明选型只是最简单的一步真正的难题全在车间现场。1. 为什么车间会需要一台树莓派51.1 维修成本倒逼的选型实验我先说清楚树莓派5并不是什么“工业级”设备它连宽温、防尘、防振这些指标都谈不上。但车间里有一种很现实的需求叫“低成本试错”先花很少的钱验证一套逻辑再决定要不要上正经工控设备。我那台坏掉的工控机是某品牌老款i5维修报价接近两千换新要四五千。而产线上要的只是一路相机、一个TCP通信、一个简单的识别模型负载并不高。把树莓派5当作“边缘盒子”临时顶上去哪怕最后发现不行损失也不大。这是它进车间的最初动机。1.2 树莓派5能不能干视觉活先看纸面数据树莓派5用的是BCM2712四核Cortex-A76最高主频2.4GHz相比树莓派4B的Cortex-A72单核性能提升明显整体算力大概有4B的两到三倍。8GB内存版跑YOLOv5这类轻量模型理论上不是异想天开。我和Jetson入门板做了个简单对比项目树莓派5 (8GB)Jetson Orin Nano (4GB)二手X86工控机价格区间400-600元2000-2500元1500-3000元功耗5-15W7-25W40-100W视觉推理CPU推理低FPS支持GPU/CUDA加速看CPU和显卡社区资料多多但门槛高少工业可靠性低需自行加固中中一台机器加摄像头加电源整套不到一千块比Jetson方案便宜一半还多。而且树莓派的GPIO直接能接继电器、接传感器改造灵活。抱着“反正便宜”的心态我开始往里装系统然后第一个坑就来了。2. 第一个卡点Ubuntu 装上了启动却翻了车2.1 为什么我用 Ubuntu 而不是 Raspberry Pi OS树莓派官方系统Raspberry Pi OS确实最省心开箱即用但车间里我还有其他需求仓库有一批脚本和容器镜像跑在Ubuntu上YOLOv5相关的部署资料也大多是Ubuntu环境统一系统能少背一套命令。另外Ubuntu Server没有桌面内存占用小剩下的全部给推理进程。所以我直接从官网下载了Ubuntu Server arm64镜像。这里要提醒一句树莓派5对Ubuntu的版本有要求太老的版本根本不认识这个板子。Ubuntu 23.10是第一个官方支持树莓派5的版本24.04 LTS则是长期支持版本。我当时图稳直接选了24.04 Server。2.2 彩虹屏、旧固件与EEPROM 升级第一次烧录完插上TF卡上电屏幕卡在彩虹色块指示灯乱闪SSH也连不上。这是典型的“引导固件没读到内核”的现象。查了一圈原因是树莓派5的EEPROM引导固件版本太旧对Ubuntu 24.04的内核支持不完整。树莓派5和4B不一样它的启动过程依赖板载EEPROM中的引导代码不是光换TF卡就完事。解决办法是先把配套的EEPROM固件更新到最新版本。操作分两步用树莓派Imager重新烧录Raspberry Pi OS到一张卡插入树莓派5启动。进入系统后执行sudo rpi-eeprom-update -a sudo reboot顺带一提如果你想直接用外部存储启动比如NVMe SSD需要先确认EEPROM版本里带NVMe boot支持具体看rpi-eeprom-update的返回信息。更新完EEPROM后再烧Ubuntu Server就正常了。2.3 稳定后我才补上的 NVMe 启动TF卡在车间环境里容易出问题一是长时间读写导致性能衰减二是突然断电可能丢文件。Ubuntu跑起来后我又加了块NVMe SSD通过PCIe转接板把系统迁过去。迁移很简单在TF卡系统里把整个根文件系统rsync到SSD再修改/boot/firmware/cmdline.txt里的root路径或者干脆用官方推荐的镜像备份工具。换到NVMe后系统启动时间从原来的40多秒降到15秒左右推理模型从SSD加载也快了。对车间这种“可能随时断电”的环境SSD的稳定性比TF卡强不少。3. 第二个卡点车间电源环境让树莓派5频繁重启3.1 树莓派5的功耗与供电要求树莓派5官方推荐使用27W USB-C电源5V/5A实际跑满负载无外设时功耗大概8-12W接USB摄像头和传感器后能到15W左右。看起来不高但车间里的供电环境远比办公室恶劣。我最初用的是手边一个旧手机快充头标称5V/3A心想应该够。结果一跑推理就随机重启有时候过两三个小时才出问题有时候刚开机十几分钟就再也连不上去现场一看机器已经重启卡死了。后来才明白5V/3A只是它“稳态输出”的参数树莓派5在CPU瞬间满载时会突然拉高电流旧充电头根本扛不住这种瞬态响应电压一掉过阈值芯片就复位重启。3.2 欠压症状与电压核查欠压不是一下子就会爆出来的它的典型症状很隐蔽推理程序偶尔报错摄像头取流中断SSH断连重连后发现系统时间变了状态灯异常闪烁更严重时直接开机卡死排查欠压最直接的办法是看系统自己记的日志。在树莓派上执行vcgencmd get_throttled返回0x0表示一切正常如果出现0x1表示当前正在欠压0x10则表示历史上发生过欠压。我那次返回的是一串非零值基本实锤了。再用万用表测GPIO的5V引脚上电空载时5.1V一跑推理就掉到4.6V左右这就是典型的电源带不动。车间的动力电还有波动几个大功率设备同时启动时整条线的电压都会突然矮一截。3.3 供电整改从插座到电源适配器整改方案说穿了并不复杂换官方27W USB-C电源或者选质量靠谱的工业级5V/5A适配器。电源线尽量短且粗避免线路上额外的压降。如果从控制柜取电建议加一个DC-DC稳压模块把输入波动稳住。有条件就上PoE HAT用交换机的PoE口供电网络和电源一根线解决还能顺便做隔离。我自己最后用的是官方电源然后用一个带浪涌保护的插座单独给它供电不再和车床、焊机共用一路电。整改之后看vcgencmd get_throttled永远是0再也没有随机重启过。车间用电真的不能按实验室插座的标准来。4. 第三个卡点散热问题车间夏天直接降频4.1 为什么树莓派5比4B更烫树莓派5性能提升的代价是发热明显增加。BCM2712在满负荷推理时裸板不加散热片温度几分钟就飙到85°C以上然后触发降频保护。树莓派4B勉强用个铝壳还能压住到5代就不行了。车间环境温度比办公室高得多我放树莓派5的那个电控柜里夏天体感温度45°C以上。同样的负载在车间里热得更快降频更猛。4.2 散热方案实测对比我手头有三套散热方案直接上机器测过散热方案满负荷稳定温度CPU频率状态无散热片88-90°C降频到1.5GHz左右铝壳被动散热78-82°C降频到1.8-2.0GHz官方主动散热器铝片风扇60-65°C几乎稳定2.4GHz看温度和频率用这几条命令vcgencmd measure_temp vcgencmd measure_clock arm官方主动散热器本身不贵装好后能在车间45°C高温下把温度压在65°C左右缺点是有风扇噪音。因为控制柜本来就吵这点声音可忽略。如果放在安静办公环境就得权衡一下。4.3 软件层面的温度兜底硬件散热做完了我还在软件层面加了兜底。在/boot/firmware/config.txt里设了温度限制避免极端情况下烧芯片。同时写了个简单的守护脚本检测到温度超过78°C时自动把推理任务暂停10秒温度降下来再恢复。原理类似“间歇性工作”对计数、读表这类非连续识别场景完全够用。散热这事没有捷径先把风道做好别把设备闷在密闭塑料盒里。车间控制柜如果散热差最好在柜门上开孔加过滤风扇不然什么树莓派都撑不住。5. 第四个卡点自训练的 YOLOv5 模型跑起来像幻灯片5.1 部署路线为什么最终选了 ONNX Runtime我这边模型是用YOLOv5在自己电脑上训练好的专门识别产线上的几种工件。最初的思路最粗放直接在树莓派5上装PyTorch跑.pt权重。结果装了半天一跑发现一帧推理要两三秒根本无法用。后来换成ONNX Runtime这条路才算走通。对比了几种常见的部署方式方案转换难度树莓派5上的推理性能内存占用PyTorch直接跑无需转换约1-3 FPS高ONNX Runtime中等约6-10 FPS中NCNN较高约8-12 FPS中TensorFlow Lite较高约5-8 FPS中Hailo-8 NPU很高30 FPS以上低ONNX Runtime在ARM CPU上的优化做得不错依赖安装也简单。NCNN性能更好但需要额外编译转换步骤多对只想快速上线的我不划算。最终选型ONNX Runtime。5.2 从 .pt 到 .onnx 的转换实操转换过程要用原训练机完成。YOLOv5仓库里自带导出脚本python export.py --weights best.pt --include onnx --opset 12 --img 640这里有几个容易踩的坑如果你改过模型结构比如自定义了检测头导出时可能报错如果训练时用了不同输入尺寸导出时也要保持一致。我的模型是标准YOLOv5s结构只是改了类别数导出还顺利。导出后我用onnx-simplifier简化了一遍去掉冗余节点文件大小和推理速度都有改善。最后在PC上用ONNX Runtime加载测试输出结果和PyTorch基本一致才敢传到树莓派5上。5.3 从 4FPS 到 10FPS 的调优记录第一次在树莓派5上跑ONNX模型640x640输入4线程大概4-5 FPS看着就是幻灯片。经过几轮调整最后稳定在9-10 FPS左右。调整顺序如下输入尺寸从640降到416速度几乎翻倍精度损失对计数场景可接受。把预处理从Python循环改成NumPy向量化和图片缩放单独线程处理省掉每帧的额外开销。推理进程固定4线程不再和摄像头采集线程抢CPU。后处理NMS用简单版本实现避免YOLOv5完整后处理在ARM上消耗过多时间。实际代码里核心就是import onnxruntime as ort sess ort.InferenceSession(best_fp32.onnx, providers[CPUExecutionProvider]) # 输入已经是 1x3x416x416 的float32数组 outputs sess.run(None, {input_name: img_blob})调优的结论是在车间这种场景里10 FPS的识别速度完全够用。料框计数根本不需要连续视频流一秒取一帧就行。如果你硬要追求20 FPS以上那就要考虑NPU加速了。5.4 预算允许的话外挂NPU是另一条路树莓派5支持通过PCIe接AI加速模块比如Hailo-8或者Google Coral。树莓派官方出过一个AI Kit套件搭配Hailo-8跑YOLOv5s实测能到几十FPS。这个方案的好处是CPU占用很低坏处是软件栈更复杂尤其是把你自己的模型量化成Hailo需要的格式要多花不少时间。我的建议是如果项目周期紧、识别频率低就先用CPU推理凑合如果后续有多个识别点要部署直接批量上NPU套件更划算。我自己是因为客户催得急先用CPU版本上线了采购计划里已经在排NPU了。6. 第五个卡点车间网络太野设备一会儿就失联6.1 车间 Wi-Fi 靠不住的真实原因一开始图省事树莓派5用WiFi联网。结果惨痛车间里全是金属货架和设备WiFi信号穿两层铁皮就只剩一格。更麻烦的是车间有自己的无线环境AP漫游切换会断流PLC和电机产生的电磁干扰也让无线稳定性雪上加霜。现象就是SSH连不上程序还在跑但图像数据回传卡死偶尔出现推理进程假死。排查网络真的比排查代码还难。6.2 有线静态IP隔离的最终配置后来我把树莓派5直接插网线到产线交换机再也不用WiFi。静态IP也直接写死在netplan配置里network: version: 2 ethernets: eth0: addresses: - 192.168.20.66/24 routes: - to: default via: 192.168.20.1 nameservers: addresses: [192.168.20.1] wifis: wlan0: dhcp4: no optional: true同时把树莓派划到了独立的VLAN和办公网、PLC控制网做隔离避免车间里乱七八糟的广播风暴把设备搞崩。树莓派5自带的网口是千兆实测跑图像数据传输很稳比WiFi快得多。6.3 断网容错与数据缓存即使有线也保不齐交换机重启、光纤收发器断电。我把应用层改成“断网不丢数据”的模式识别结果先写本地SQLite定时批量上报。MQTT断线自动重连上线后补发离线消息。找个独立脚本每30秒ping网关连续失败就重启网络服务。这套容错设计上线后再也没出现过“设备恢复网络但程序已经死掉”的情况。车间的网络再野也翻不出大浪了。7. 第六个卡点装好之后没人愿意天天重启树莓派7.1 systemd 服务开机自启和崩溃拉起系统装好、模型跑通只完成了一半。真正麻烦的是后期运维——车间工人不会去敲命令设备断电重启后必须自己跑起来程序崩了也必须自己拉起来。我用systemd写了一个服务文件[Unit] DescriptionRPI Vision Detection Service Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple WorkingDirectory/opt/vision ExecStart/usr/bin/python3 /opt/vision/app.py Restartalways RestartSec5 EnvironmentPYTHONUNBUFFERED1 [Install] WantedBymulti-user.targetRestartalways是关键参数只要进程异常退出systemd会在5秒后拉起来。再执行systemctl enable vision开机就会自动启动。这一步解决了“程序崩溃没人管”的问题。7.2 硬件看门狗专注治死机不重启程序崩了systemd能拉起来但如果整个系统卡死systemd也没办法。这时候需要硬件看门狗。树莓派的SoC内置了看门狗开启方法是在/boot/firmware/config.txt里加一行dtparamwatchdogon重启后会出现/dev/watchdog0。在应用层定期“喂狗”如果系统卡死导致喂狗中断看门狗会在几十秒内强制重启整机。我用的一个简单Python喂狗脚本import os, time WATCHDOG_PATH /dev/watchdog0 fd os.open(WATCHDOG_PATH, os.O_WRONLY) while True: os.write(fd, bV) time.sleep(5)注意喂狗脚本一定要和主进程独立运行最好使用单独服务这样即使主进程卡死喂狗脚本还在喂那就白搭了。我把主进程挂了“健康检查”钩子主进程每10秒写一个心跳文件喂狗脚本发现心跳文件超过30秒没更新就主动停止喂狗触发看门狗重启。这套组合拳用了一个季度车间断电恢复再也没人工干预过。7.3 交付给车间前的最后三步正式交付前我还做了三件事把树莓派5装进带透明窗的金属端子盒固定在电控柜内贴好散热片导风罩。在盒子上装一个三色指示灯绿灯运行、黄灯告警、红灯死机配合看门狗逻辑。车间工人看到红灯知道打电话给我不用自己碰设备。用dd做了一份系统全量镜像备份刻到备用的NVMe里。万一这台设备彻底挂了换卡就能顶一个小时左右恢复到可用状态。这三步看起来很土但非常管用。把树莓派5当“家电”交付给车间比给工人发一堆英文文档靠谱得多。8. 写在最后的经验哪些车间适合树莓派5哪些不适合8.1 这几类活树莓派5干得很稳经过这轮折腾我对树莓派5进车间有了清晰的判断。它最适合的场景是料框计数、零件分类、读仪表数字这类低频视觉识别设备状态数据采集和上报的边缘网关需要GPIO控制简单执行器继电器、声光报警的小改造预算敏感、允许低帧率的视觉验证项目这类负载的特点是单次推理时间几百毫秒没关系采集间隔可以设成每1-2秒一拍树莓派5完全扛得住。8.2 这几个场景别省钱上树莓派5不适合的场景我也列出了高速产线视觉检测要求30 FPS以上连续检测的需要长时间无人值守且系统可靠性要求极高的核心工位环境温度超过50°C、没有做任何散热改造的密闭柜体需要工业级认证高温、振动、防尘等的交付项目这些场景老老实实上正经工控机或者Jetson不要为了几百块钱埋雷。树莓派5适合做“辅助工位”和“边缘小脑”不适合当产线心脏。8.3 重新选一次我会先解决哪两件事如果重新来一次我会把供电和散热问题放在系统安装之前解决。当时太乐观以为软件是最难的事实恰恰相反系统装好、模型调通只占了三分之一的工作量剩下的时间全耗在“让设备在车间环境里稳定活着”。六件事捋顺之后核心也就四句话供电给足、散热做好、模型用对、网络稳定再补上开机自启和看门狗树莓派5在车间里完全能当个合格的小工具。它不会像几十万的设备那样金光闪闪但胜在便宜、灵活、坏了不心疼。对我来说这就够了。