树莓派 5 进车间这件事我在项目群里吐槽过一句话开发板上电能跑 demo和产线上连续运行三个月不闹脾气是两个完全不同的世界。当时我们车间临时要加一个轻量视觉检测节点专业工控机不仅贵货期还长手头正好有几块树莓派 5就决定先拿它顶上去。结果从电源、系统、模型部署到数据回传一路磕磕绊绊整整一周才让它在产线上站稳。这篇就把那段时间卡住的六件事按顺序复盘一遍。如果你也想在车间、仓库或者类似的工业现场用树莓派 5 做视觉检测、设备状态识别或者简单的数据采集这篇应该能帮你少走不少弯路。先给结论树莓派 5 干轻量视觉完全够用但它不像开发板那样上电就能稳定跑真正费时间的反而是那些看起来不起眼的周边问题。1. 进场前的盘算为什么是树莓派 5 而不是工控机先说清楚头顶上为什么顶着“临时”两个字。当时的需求是给一台老设备加装视觉判断产品到位后拍照识别一个微小缺陷结果通过 IO 给到 PLC决定继续走还是拦截。产线不允许长时间停机改造控制柜里空间又有限所以设备的物理尺寸、功耗、部署位置都有硬约束。工控机方案当然考虑过带独立 GPU 的型号随便一问就是大几千上万而且订货周期让人等不起。NVIDIA Jetson 系列性能确实更合适但那个阶段的供货和价格也不理想。树莓派 5 的优势很直接体积小、功耗低、货源相对稳定性能虽然不算强但比树莓派 4 提升明显尤其是 CPU 和 PCIe 接口这两个点对跑推理和接固态硬盘都友好得多。另一个关键点是非技术因素这个项目定位本身就是验证性的。管理层不希望在一个不确定的试点方案上投入太多树莓派 5 的成本结构让试错成本几乎可以忽略。我也做好了心理准备——它可能撑不住长期高负载但只要能在验证周期内稳定跑起来后续再决定要不要迁移到更专业的平台上。当时我给自己列了一个问题清单后来的经历证明这六件事几乎全部踩中车间的电源环境是否满足树莓派 5 对供电质量的要求系统选 Ubuntu 还是官方 Raspberry Pi OS各自有什么坑自训练的 YOLOv5 模型如何高效部署到 ARM CPU 上推理结果怎么和产线 PLC 打通而不是只在屏幕上画框高温粉尘环境下如何保证长时间运行不降频、不死机人不在现场时怎么远程排查问题和恢复服务下面一件一件说。2. 第一件事车间电源环境比想象中脏得多2.1 现象电机一启动板卡就重启树莓派 5 官方要求 5V/5A 的 USB-C 供电从参数上看20W 出头的功耗不算高。但车间和办公室完全是两个世界。我们的检测工位旁边就有一台变频器驱动的电机启动瞬间同一回路上的电压会被拉低有时候甚至会出现明显的闪变。第一次上电测试我用的是一个普通 65W 氮化镓充电头单独给树莓派供电空载跑系统、跑 YOLOv5 推理都正常。结果一联动产线电机启动的那一瞬间树莓派直接重启了。查/var/log/syslog能看到系统在异常掉电前的记录内核日志里最后几条全是文件系统相关的错误明显是电压瞬跌导致板子进入了掉电复位。这里要补一个基础知识树莓派 5 的供电电路对输入电压比较敏感USB-C 口虽然名义上支持 PD 协商但很多消费级充电头在负载突变时电压跌落控制做得并不好。普通手机充电器在纹波和瞬态响应上根本没有为这种持续负载优化过。2.2 处理工业电源加独立回路解决思路很朴素不要和省钱较劲直接用工业级电源。我换了一台明纬的 5V/5A 工业开关电源并且从控制柜的 24V 母线上单独引了一路通过一个 DC-DC 模块降压到 5V 给树莓派供电。这样做的核心逻辑是让树莓派的供电回路和电机、变频器回路彻底隔离避免大电流设备启停时拉低电压。换完电源之后做了几组验证设备空载启动、带载启动、连续启停多次树莓派的系统日志里没有再出现电压异常记录。我还用示波器挂在 5V 输出端看过电机启动瞬间的电压跌落从原来的接近 4.2V 改善到了基本保持在 4.9V 以上。对于树莓派 5 来说这个余量已经足够。另外还有一个小细节值得提树莓派 5 默认的电源管理策略里如果检测到输入电压低于阈值会在日志里反复刷“under-voltage”警告但不会主动重启。真正导致重启的往往是瞬态掉电时间过长超出了板载电容的保持时间。所以如果你也遇到“偶发性重启”但日志里没有明显报错先怀疑供电环境别急着怀疑系统。2.3 额外收获让断电后能自动恢复车间里难免有计划内停电。一次停电后再来电如果设备是自动运行的我们希望树莓派能自己开机而不是等人工去按电源按钮。树莓派 5 的config.txt里有一个power_off_on_halt参数默认情况下系统正常关机后板子会保持在待机状态需要手动短接或者重新上电才能启动。我在/boot/firmware/config.txt里加了这样一行power_off_on_halt1这个参数的作用是当系统执行关机命令后板卡不会完全断电而是进入一种类似开机就绪的状态外部供电恢复时能够自动拉起来。实测下来市电恢复后树莓派会自动进入系统配合后面说的 systemd 自启服务整个检测节点做到了无人值守开机。3. 第二件事Ubuntu 装在树莓派 5 上没那么省心3.1 安装 24.04 时反复卡在引导阶段系统选型上我直接选了 Ubuntu 24.04 LTS 的 arm64 版本主要原因是团队对 Ubuntu 的环境更熟apt 源、systemd、Python 生态都更顺手。官方 Raspberry Pi OS 当然也不错而且对新硬件的适配往往更快但考虑到后续要装一堆依赖还要和公司现有的 Ubuntu 服务器统一管理方式我还是选择了 Ubuntu Server 版不装桌面环境纯命令行跑服务。安装过程本身没太多好说的用树莓派官方的 Raspberry Pi Imager 写卡选 Ubuntu 镜像填好 SSH 公钥就能启动。真正卡住我的是“写卡后无法稳定引导”这一个问题。第一次用了一张用了很久的 32GB SD 卡前几次启动都没问题后来每次开机都会在引导阶段随机卡住有时候卡在 U-Boot有时候直接黑屏。排查了很久最后确认是 SD 卡本身的随机读写质量不行。树莓派 5 的 SD 卡接口走的是 UHS-I对卡的素质要求比树莓派 4 时代更高老卡、杂牌卡、甚至在别的设备上格式化过的卡都容易出现这种概率性引导失败。换了一张新的高速卡之后问题彻底消失。3.2 系统盘选型从 SD 卡切到 NVMe虽然换了新 SD 卡能稳定引导但用着用着又发现一个问题apt 更新、日志写入和模型推理同时发生的时候系统会明显变卡IO 等待非常高。原因不复杂SD 卡本质上是 Flash 介质随机小文件写入性能很差而 Linux 系统恰恰有大量小的日志、临时文件写入动作两者叠加就是卡顿。树莓派 5 正好有 PCIe 2.0 接口可以接 NVMe SSD。我买了一个 M.2 HAT 和一块 128GB 的 NVMe 固态把系统整个迁移过去之后体验完全不一样。启动时间从接近半分钟压缩到十几秒apt upgrade也不会再让系统卡到无法操作日志写满也没压力。这里我的建议是如果你准备在树莓派 5 上跑任何“正经”项目直接把系统装到 NVMe 上不要把 SD 卡当作系统盘来规划。SD 卡可以作为备份、存档或者放一些无关紧要的静态资源但系统、日志、模型文件都放在 NVMe 上能省掉后续大量莫名其妙的 IO 问题。多说一句树莓派 5 的 NVMe 是通过 HAT 板转接的买的时候注意选支持树莓派 5 的型号供电和固件兼容性都要确认别只看便宜。3.3 系统分区与 swap 的一点建议树莓派默认内存型号如果只有 4GB 或者 8GB跑 YOLOv5 推理加多个后台服务时内存压力还是存在的。Ubuntu 安装时默认的 swap 分区往往偏小建议手动加大。我分配了一个 8GB 的 swap 文件虽然性能不能和物理内存比但至少能避免内存紧张时进程被 OOM Killer 随机干掉。另外最好把/var/log/journal设置为持久化存储不然重启后系统日志全丢排查问题非常被动。设置持久化日志也很简单编辑/etc/systemd/journald.conf把Storagepersistent打开。4. 第三件事自训 YOLOv5 模型部署到 ARM CPU 才是真正的坑4.1 三种推理路径的选择为什么不用原版 PyTorch模型方面我们内部已经用 YOLOv5 训练了一个针对特定缺陷的小模型训练用的是带 GPU 的台式机训练集规模不大模型结构是默认的 YOLOv5s输入尺寸 640×640。训练不是重点重点是怎么把这套东西弄到树莓派 5 上跑起来。最初的想法很直接在树莓派上直接装 PyTorch把.pt权重文件 copy 过去用torch.hub加载然后推理。实际上这条路也能走通PyTorch 官方的 ARM 版 wheel 包可以安装但问题有两个一是 torch 和 torchvision 体积大、依赖多在设备上安装非常慢二是在 CPU 上直接跑 PyTorch 的模型加载和推理性能其实一般因为 PyTorch 默认的推理路径有大量多余开销并不适合这种资源受限设备。所以我部署时选择了另一条路导成 ONNX然后用 ONNX Runtime 推理。ONNX Runtime 针对 ARM CPU 做过不错的优化支持多线程、图优化而且安装包只有几十 MB比 PyTorch 全家桶轻太多。导出过程很简单YOLOv5 的仓库本身就提供了导出脚本python export.py --weights best.pt --include onnx --dynamic导出时最好加上--dynamic参数这样后续调整输入尺寸更方便。到了树莓派上安装onnxruntime的 ARM64 版本之后写一个简单的推理脚本把前处理、推理、后处理三步分开计时就能看到性能瓶颈在哪里。4.2 实际压测数据与可行的优化手段先给一个真实的性能预期默认 YOLOv5s输入 640×640在树莓派 5 上不做任何优化单张图片推理耗时大约在 250ms 到 300ms 之间也就是 3 到 4 FPS。如果检测目标是远程连续视频流这个速度完全不够看。但对于产线“到位拍照检测”这种离散触发场景只要单张检测耗时控制在可接受范围内速度压力就没那么大。不过我还是做了一轮优化最后把推理时间压缩到了 150ms 左右效果还是很明显的。几个关键手段降低输入尺寸。我们把输入从 640 降到 384甚至部分场景直接降到 320。检测的缺陷在图像里占的比例不算小降低分辨率后精度影响不大但速度几乎翻了倍。这一步收益最大代价也最小。限制 ONNX Runtime 的线程数。树莓派 5 的四个核心如果全部让 ONNX Runtime 占满系统其它服务就会卡死。通过intra_op_num_threads设置为 3或者干脆设置为 2推理速度并没有明显下降但系统响应保留了很多余量。不要贪多四个线程跑推理并不会比两个线程快多少反而会耗尽 CPU。开启图优化。ONNX Runtime 的sess_options.graph_optimization_level ORT_ENABLE_ALL这一步是白捡的性能什么都不用改推理时间能再降 10% 左右。后处理直接在 NumPy 里做。YOLOv5 默认的 NMS 实现依赖较大改成轻量的后处理函数后单张后处理的时间从几十毫秒降到几毫秒。import onnxruntime as ort import numpy as np so ort.SessionOptions() so.intra_op_num_threads 3 so.graph_optimization_level ort.GraphOptimizationLevel.ORT_ENABLE_ALL session ort.InferenceSession(best.onnx, so, providers[CPUExecutionProvider])这些优化做完之后我们实际上已经把树莓派 5 的推理能力摸到了底。如果你是做连续的视频流识别那我不建议在这个平台上跑 YOLOv5s 以上的模型更不要想着跑 YOLOv5m 或者更大如果是事件触发式的单帧检测这个平台完全够用。4.3 必须承认的瓶颈什么时候该换设备树莓派 5 上的 CPU 推理有一个绕不开的边界小目标检测和密集目标检测非常消耗时间。如果项目的检测画面里目标数量很多或者目标很小在 320×320 输入下容易出现漏检这种情况下加大输入尺寸又会让推理时间暴涨陷入一个两难局面。遇到这种情况我的建议是果断换平台。树莓派 5 的优势是低成本、低功耗、部署灵活但它本质上是通用 CPU 推理和带 NPU 或者 GPU 的设备不在一个量级。如果你发现自己一直在调输入尺寸、调模型结构、调后处理才勉强满足需求那就说明硬件选型已经不适合项目了再往下抠性能会浪费大量时间。对我们这个项目来说检测目标是单一、占比较大、数量不多所以树莓派 5 的算力绰绰有余。这也算是选型时最需要想清楚的一件事不要盲目相信开发板的“AI 能力”把你的真实检测场景拆开估算一下单帧耗时和系统余量再做决定。5. 第四件事模型跑通了怎么让产线“听”推理结果5.1 车间触发链路Modbus、MQTT 和本地 systemd模型在树莓派上跑通只是第一步。真正的需求是产品到位树莓派收到信号拍照推理再把结果给到 PLC。整套链路必须跟产线的节拍走不能让人一直盯着屏幕。我设计的链路是这样的PLC 侧按照产线流程在设备到位时通过 Modbus TCP 往树莓派发送一个触发信号。树莓派上跑了一个 Python 进程监听这个信号收到后立刻调用摄像头拍照送入 ONNX Runtime 推理得出结果后再通过 Modbus TCP 或者 MQTT 发回去。PLC 根据结果决定放行还是拦截。MQTT 在这里起到了一个很好的解耦作用。我把推理结果统一发布到一个主题上比如line1/vision/result内容是 JSON 格式包含时间戳、检测结果、置信度。这样无论 PLC、上位机还是数据看板都可以订阅同一个主题不用为每个端单独设计通信协议。进程管理上直接上 systemd 服务。写一个.service文件指定启动命令、工作目录、自动重启策略然后用systemctl enable让它开机自启。这样即使进程崩了系统也会自动拉起来而不是等巡检的人发现。5.2 让重启后能自己爬起来开机自启与看门狗车间设备最忌讳“悄悄死掉”。树莓派 5 上如果只是跑一个前台 Python 脚本某天脚本因为一个异常退出后检测节点就形同虚设产线也照常走拦截功能完全失效。这种故障是最隐蔽的也是最危险的。我做了三层防护。第一层是 systemd 的Restartalways配置进程异常退出后系统会在几秒内自动重启它。第二层是写了一个简单的看门狗脚本定期检查检测进程的 PID 和最后的活动时间如果发现超过一定时间没有收到心跳就强制重启相关服务。第三层是给检测结果打上时间戳如果 PLC 连续接收到超时或者异常数据就自动把产线切成“放行”模式并报警宁可不拦截也不能让产线死掉。这里有一个值得注意的点视觉检测本身是概率模型误判和漏判都是不可避免的。在车间场景里你要在部署之前就和工艺、质量的人说清楚“拦截条件”和“放行条件”分别是什么否则一旦出现误判责任就说不清了。我们当时约定的是“有缺陷嫌疑就拦截”宁可多拦截几次导致人工复检也不要放走真正的缺陷品。5.3 推理结果示例一个最小的 JSON 载荷给一个最小化的结果 payload 示例方便你理解整个通信链路{ timestamp: 2025-06-14T09:23:11.482Z, node: line1-vision-01, task_id: t-20250614-0012, result: ng, confidence: 0.973, class_id: 1, trigger: modbus-1 }PLC 收到这个 JSON 之后按照约定好的字段解析即可。如果你的 PLC 不擅长处理 JSON也可以直接在树莓派上做一次转换最终通过 Modbus 线圈写入一个布尔值合格写 0不合格写 1。PLC 那边只需要读线圈状态逻辑非常简单。6. 第五件事散热、灰尘与长时间运行的可靠性斗争6.1 板卡发热与降频的真实影响树莓派 5 的功耗比树莓派 4 高CPU 全速跑 YOLOv5 推理时功耗能到 20W 左右。在工厂车间这种环境里夏季车间温度能到 35°C 甚至更高板卡周围又没有良好通风任何一个被动散热片都顶不住。我们的设备装在控制柜里柜内本身就有变频器和其他发热器件温度更高。初期用的是一个普通的铝制散热片加外壳风扇结果跑模型半小时后主板温度报警系统自动降频推理速度肉眼可见地变慢。用vcgencmd measure_temp读到的温度已经 80°C 多这还是在节流之前。降频以后的推理耗时翻倍直接会让产线节拍抖动。这里要说清楚一个概念树莓派的温度阈值是有层级设计的。温度到 80°C 之前会开始轻微降频再高会强制降到一个很保守的频率保护硬件。CPU 频率一旦下来ONNX Runtime 的推理时间立刻恶化而消费者的感知往往是“树莓派越来越慢”其实是散热跟不上。6.2 一套不算雅观但有效的主动散热方案我给树莓派 5 换了一套主动散热方案一个 5V 的涡轮风扇直吹 CPU 散热片同时在控制柜的进风口加了一层可换的防尘滤棉排风口加了一个机柜风扇往外抽风形成负压气流。这套方案的效果非常直接温度从满载的 85°C 降到了 65°C 左右推理耗时恢复稳定也没有再出现系统层面的降频降速。代价是噪音大了点风扇本身也需要定期检查好在这种工业环境本来就不在乎这点声音。防尘滤棉是很容易被忽略的细节。车间粉尘多如果风扇直接抽风几个月后散热鳍片会积满灰散热效率大幅下降然后又是一轮降频。滤棉成本极低两周换一次既干净又省事。我还加了一个温度日志脚本每隔五分钟记录一次 CPU 温度写到本地日志文件这样如果某天又出现变慢的问题先把温度曲线调出来看排查效率高很多。6.3 环境数据记录与每周重启策略长时间运行的设备定期重启有时是好事可以清理内存碎片、释放句柄、重新加载系统资源。我在 cron 里加了一个每周凌晨的重启任务选在产线不生产的时段执行。实测下来这种固定节奏的重启对系统稳定性有明显的正面作用尤其是树莓派这种内存不算富裕的设备。不过重启策略一定要避开生产时间否则就是人为制造故障。当时我设置的是每周日凌晨 3:00 重启这个时间点产线基本不会运行即使重启后系统启动有问题还有几个小时可以处理不会影响到白天生产。7. 第六件事人不在车间怎么处理现场意外7.1 建立远程访问通道先保证能连上最怕的场景是半夜接到值班电话说“检测节点不动了”但你人在几十公里外。所以从一开始远程访问能力就是硬需求而不是可选项。我没有用复杂的公网方案采用的是最简单也是最稳妥的一种在办公室有一台固定公网 IP 的服务器作为跳板树莓派主动建立一个 SSH 反向隧道到这台服务器上人在任何地方先连接到跳板机再通过这个通道 SSH 到车间树莓派。这种“设备主动向外连接”的模式避开了车间网络没有公网 IP 的问题也规避了在防火墙上开放大量端口的风险。为了让这个隧道保持活跃写了一个 systemd 服务来维护它断开就自动重连同时用 autossh 这类工具保证 SSH 隧道不中断。只要树莓派本身还能跑这个通道就基本不会断。7.2 事故自恢复与告警机制远程能连上解决的是“能修”的问题但更理想的是“不让它发生”。我设置了几个简单的监控和告警项检测进程掉线超过 3 分钟发送告警到企业微信群板卡温度超过 80°C发送告警并写入日志磁盘剩余空间低于 2GB发送告警树莓派自身 uptime 异常比如意外重启通过重启记录日志判断。告警只是通知真正解决现场故障多数还是要靠重启。我们的树莓派接了一个智能电源管理的继电器开关如果远程 SSH 完全没有响应可以通过跳板机控制这个电源模块做一次硬断电重启。这个机制救过我很多次尤其是遇到 SSH 隧道本身挂掉又没自动拉起的情况只能通过断电重启来解围。7.3 现场阶段的诊断习惯远程排查问题的核心不是工具多花哨而是日志够不够全。我给树莓派配置了持久化 systemd journal并且把所有服务的关键运行信息都写入了自定义日志文件。遇到问题第一件事是看日志根据时间窗口检索一般都能定位到是模型卡住、内存不足还是通信超时。另外建议现场把串口调试线留一根在控制柜里。树莓派 5 的 UART 串口在系统无法启动时能帮上大忙可以通过串口查看引导日志。我们当时就遇到过一次系统分区异常SSH 无法连接最后通过串口进系统修复了文件系统避免了一次需要把设备拆回办公室的麻烦。8. 事后复盘如果重新入场我会改掉这几个设计项目跑通之后回过头看整个流程有几个地方如果当初就意识到能省掉好几天的折腾。一开始就上 NVMe不要犹豫。在 SD 卡上浪费的时间比一块 NVMe SSD 贵多了。树莓派 5 的 PCIe 接口就是用来干这个的。电源方案提前一步到位。直接按工业电源选型别把消费级充电头带进车间。供电环境不好判断的话先挂示波器看几天再决定。模型尺寸和输入分辨率要基于真实场景评估。不要因为训练时习惯用 640部署时也硬跑 640。把你的目标大小、出现数量、允许的误报漏报率算清楚再决定输入尺寸。通信协议越简单越好。一开始我只用 Modbus TCP后来加 MQTT 纯粹是为了让其他系统也能读结果。如果只是单一 PLC 对接一个协议就够了多个协议意味着多个维护点。给树莓派留一个“硬开关”。智能电源模块虽然贵一点但能让你远程处理硬死机问题这个钱花得值。所有服务配置成 systemd 管理。不要用 nohup 或者 screen 跑服务那在开发时可以在车间里就是定时炸弹。最后谈谈我的个人体会。树莓派 5 进车间这件事技术难度并不高每一个单点问题拆开看都很简单难得是它们会一起出现供电不稳、系统引导失败、模型跑不动、通信断连、散热不行、远程失联任何一环掉链子都会让整个检测节点变成摆设。真正花时间的是把这些零散的问题串起来形成一套“即使我不在现场也能自恢复”的机制。如果你也准备做类似的事情建议按我上面说的顺序层层排查先解决供电和系统再部署模型再打通通信最后做可靠性加固。别一上来就急着调模型参数前面的坑不填后面再优化模型都是白干。
