把树莓派5搬进车间的那个下午我原本以为接下来就是插上电源、挂上摄像头、跑一个自己训练好的YOLOv5模型一天内就能看到画面框体和告警日志。毕竟这代板子升级了不少四核Cortex-A76、支持PCIe、双CSI摄像头接口怎么看都像一台能直接干活的边缘计算盒子。现实很快教育了我从装系统到能在流水线上稳定跑检测我前后在六个地方被卡住而且没有一个是高深的算法问题全是环境适配和工程细节。如果你正打算在树莓派5上部署自己训练的YOLOv5模型这篇文章基本可以当一份避坑地图按顺序走能省下很多摸索时间。这个项目的场景很具体在车间做安全帽佩戴检测和禁区闯入告警。树莓派5负责读摄像头画面、跑目标检测、把结果上报到车间局域网里的工控机或PLC侧。整套东西不是研发样机而是每天要被人无视存在的生产辅助设备。最终硬件配置是树莓派5的8GB版本Ubuntu Server 24.04 LTS树莓派官方Camera Module 3模型是YOLOv5s系统盘放在M.2 NVMe固态上。下面要讲的就是这次部署里最折磨人的六件事每一件我都会说清楚当时的现象、排查思路和最终的解决办法。1. 系统选型与安装树莓派5上的Ubuntu到底该怎么选1.1 为什么我最终装了Ubuntu而不是Raspberry Pi OS车间里的视觉联动脚本、MQTT上报逻辑、部分工业协议栈我之前都是在Ubuntu环境上验证过的整套东西直接挪到Ubuntu Server上最省事。树莓派5刚出来那会儿官方系统Raspberry Pi OS已经切到BookwormPython环境默认开启了externally-managed直接用pip往系统Python里装包会被拦下来。加--break-system-packages虽然能强行装但一旦OpenCV、onnxruntime、numpy这些大包之间出现依赖冲突后面排查起来非常费劲。工业项目最怕的就是“今天能跑、明天不能跑”所以我宁可选生态更稳的发行版。Raspberry Pi OS也有它的优势摄像头驱动、外设支持、默认调好的硬件编解码都更完整。但无头服务器场景下Ubuntu Server镜像只有几百MB装完空闲内存占用不到300MB没有桌面环境那一大堆负担。再加上车间里的维护人员对Debian系和Ubuntu系的操作习惯都差不多出问题时查文档也方便最终我选了Ubuntu Server 24.04 LTS arm64版本。如果你的主要用途是纯摄像头和多媒体处理Raspberry Pi OS依然值得考虑但如果你要跑自己训练的视觉模型又要长期维护Ubuntu Server更对路。三个系统选型我做了个对比后面维护的时候一直按这张表取舍系统优点缺点适合场景Raspberry Pi OS Lite官方硬件兼容最好、资源占用低Python包管理限制多、部分工业软件要额外适配以摄像头采集和媒体处理为主的项目Ubuntu Server 24.04 LTS视觉和工业生态成熟、netplan网络管理清晰、LTS支持时间长官方外设驱动需要自己补装无头推理服务器、模型部署Ubuntu Desktop 24.04 LTS调试直观、图形界面方便内存占用高、后台组件多开发调试阶段1.2 镜像烧录和树莓派5的新启动流程烧录工具我用的是Raspberry Pi Imager设备类型选Raspberry Pi 5操作系统选Ubuntu Server 24.04 LTS arm64。烧完之后插卡上电板子没有像树莓派4那样顺利进入系统而是长时间停在彩虹屏。第一反应是怀疑电源因为树莓派5对电流要求高但换了官方电源还是老样子。排查到最后发现是bootloader版本太旧EEPROM里的固件不认识新版镜像里的设备树文件导致内核起不来。树莓派5的启动流程和之前几代不太一样它把启动候选交给EEPROM固件管理不再像以往那样直接无脑读TF卡。处理方式也不复杂如果你手上有一张能进系统的树莓派OS卡就执行sudo rpi-eeprom-update -a更新固件或者用官方SD卡引导工具更新。更新完成后再插上Ubuntu卡启动就正常了。遇到新版镜像起不来时先别怀疑系统坏了先查bootloader版本这个排错顺序能省很多时间。我觉得还有一个值得一开始就做的决定不要在车间长期运行中一直用TF卡。TF卡在频繁写日志、推理缓存、系统更新重载时寿命衰减很快车间温度偏高会加速这个问题。树莓派5原生带PCIe接口转接一块M.2 NVMe固态非常合适系统装在SSD上后随机读写性能比TF卡高一个数量级。我最终给板子配了256GB NVMe连续跑了一周看smart信息几乎没什么磨损这个投资非常值得。TF卡更适合用来做备份和初始引导真正的运行盘交给固态。2. 散热与供电第一个教我重新做人的是温度2.1 树莓派5的功耗上涨和温度墙树莓派5的CPU性能提升很明显代价是满载功耗从树莓派4的7W左右涨到了12W上下。车间夏天温度很容易到35度以上如果机柜里再挤着几台设备环境温度还会更高。我第一次把裸板放在机柜里跑推理测试两三分钟后用vcgencmd measure_temp一看温度直接冲到85℃CPU频率从2.4GHz一路跌到1.2GHz。单帧推理时间从原来的1.4秒暴涨到2.8秒延迟翻倍整个检测系统的实时性直接失去意义。这颗SoC的频率策略非常激进温度一到阈值就开始降频而且是整体性降低。树莓派5不再像树莓派4那样靠被动散热勉强压住主动散热在这个平台上不是可选配置而是必需品。我现在用的是官方Active Cooler散热器主动风扇加铝散热片压得比较稳满载时温度大约在55℃到60℃徘徊风扇噪音在车间环境里几乎听不见。如果你想把设备放进密封机柜那就得确保机柜本身有风道不能靠被动散热片静置否则长时间运行后还是会撞温度墙。温度监控命令是我日常排查用得最多的vcgencmd measure_temp vcgencmd measure_volts vcgencmd get_config int散热安装有一个比较容易踩的坑如果你想自己加外置风扇不要图方便把它接到GPIO的3V3引脚上。GPIO只能提供非常小的电流风扇一启动就会把电压拉垮导致树莓派重启。正确做法是风扇接5V或者独立12V电源中间用一个MOS管或继电器做开关控制这样既不影响系统供电也能在软件里按温度策略启停风扇。2.2 车间供电不能靠手机充电器树莓派5官方要求5V/5A供电这不是随便写写的数字。车间现场最常见的手机充电器是5V/2A或5V/3A接上之后桌面待机看着正常一旦跑起YOLOv5推理、CPU和内存同时拉满瞬时电流一上来充电器就会触发过流保护或者电压塌陷板子重启得非常随机。我一开始没重视这个问题结果半夜板子自己重启了两次第二天一早看日志才发现是电压跌落导致的。后来我换了一台5V/5A带接线端子的工业开关电源电源线用叉形端子压接不能像拧普通电线一样直接塞进端子里。车间里螺丝端子如果压到细铜丝时间一长接触电阻变大电压会不稳定。另外电源适配器最好选用带滤波电容型号车间里电机频繁启停会造成电压波动劣质电源扛不住这种干扰。断电恢复也是无人值守场景里必须考虑的事。开关电源在来电后会自动恢复输出树莓派5插上电也会自动上电启动但应用层不会自动拉起。我的处理方式是给推理进程写systemd服务并设置Restartalways同时加一个轻量看门狗脚本定期检查检测进程和摄像头设备节点是否正常。这样即使断电再来电系统起来后服务也能自动恢复不需要人专门跑到车间去按开机键。3. 摄像头选型与图像采集坑都藏在CSI和USB之间3.1 为什么放弃USB摄像头改走CSI接口一开始我以为USB摄像头插上就能用实际上在树莓派5上跑USB摄像头的体验非常差。车间里USB外设本来就多一个普通USB摄像头插上去带宽和中断会跟其他USB设备抢偶尔还会掉线。驱动栈更是参差不齐有的摄像头在Ubuntu Server下需要插拔一次才能出图有的在长时间运行后会出现“设备忙”的错误重启服务也抢不回来。后来我换成了树莓派官方Camera Module 3走CSI接口直接挂在SoC上不占用USB带宽色彩还原和低光表现也明显比几十块的USB摄像头好。CSI摄像头在树莓派5上还有一个隐形优势它的图像通路是经过ISP处理的CPU不用再额外做白平衡和去马赛克能省下不少算力留给模型推理。装好Ubuntu Server后系统默认不带摄像头应用需要先安装rpicam-appssudo apt update sudo apt install -y rpicam-apps装完之后用rpicam-hello验证摄像头能弹出预览画面就说明相机链路通了。接线时有一个非常容易忽略的细节树莓派5的CSI接口改成了双排线座排线方向和树莓派4不一样金属触点朝外。我第一次按树莓派4的习惯插摄像头完全没有反应后来掰开重新按图标方向插才识别到。排线插反不会烧坏接口但会让排查过程变得非常浪费时间。3.2 libcamera和OpenCV之间怎么衔接Libcamera接管摄像头后传统OpenCV读取方式会遇到问题。cv2.VideoCapture(0)在Ubuntu Server下很可能拿不到图像因为摄像头没有被抽象成普通V4L2节点。你先用v4l2-ctl --list-devices看看有没有/dev/video0节点如果有OpenCV直接读节点就能工作如果没有就需要绕一下。我当时最稳的做法是用rpicam-vid把画面编码成H.264流推到本地TCP端口推理程序再从另一边拉流。这样摄像头采集和模型推理在代码层面完全解耦调试时可以单独看采集端也可以单独跑检测端互不干扰。虽然多了几十毫秒的延迟但对车间里做安全帽检测这种场景来说完全无所谓。一个比较实用的命令组合是让摄像头持续输出到TCP端口rpicam-vid --codec h264 --width 1280 --height 720 --framerate 15 --listen -o tcp://0.0.0.0:8554然后推理端用支持H264拉流的组件去读取这个TCP地址。这样做的好处是摄像头采集进程和推理进程可以独立重启任何一边崩溃都不会连累另一边。如果以后要换摄像头型号只要保证输出H264流就行推理代码不用改。4. 部署自己训练的YOLOv5模型从best.pt到ONNX的几道弯4.1 为什么不能直接把.pt文件拷到树莓派上跑把训练好的best.pt直接拷到树莓派上理论上能跑但工程上很不划算。PyTorch在ARM CPU上没有专门的算子优化推理速度慢内存占用高而且部署环境要装完整PyTorch体积巨大。相比之下ONNX Runtime针对Arm的NEON指令做过优化支持量化部署时只需要onnxruntime一个库就够了。导出ONNX的过程在训练机器上完成不需要在树莓派上进行。如果你的模型是YOLOv5仓库训练出来的直接用官方导出脚本python export.py --weights best.pt --include onnx --opset 12 --simplify导出时建议保持固定输入尺寸。车间摄像头画面分辨率相对固定推理分辨率固定成640x640或者320x320能省下动态尺寸带来的额外计算开销。如果你有大批量图片测试需求固定输入尺寸也能让后续的量化校准更容易。4.2 推理环境搭建和onnxruntime部署树莓派上的Python环境一定要用虚拟环境不要直接往系统Python里塞包。我的部署流程这样走python3 -m venv ~/yoloenv source ~/yoloenv/bin/activate pip install --upgrade pip pip install onnxruntime opencv-python-headless numpyopencv-python-headless比完整OpenCV少了很多GUI依赖树莓派上不需要显示窗口这样装体积最小。onnxruntime会自动选择CPUExecutionProvider你可以用下面这段代码验证当前可用的执行提供程序import onnxruntime as ort print(ort.get_available_providers())推理核心代码并不长关键是要做好输入预处理import cv2 import numpy as np import onnxruntime as ort session ort.InferenceSession(best.onnx, providers[CPUExecutionProvider]) input_name session.get_inputs()[0].name img cv2.imread(frame.jpg) resized cv2.resize(img, (640, 640)) blob cv2.dnn.blobFromImage(resized, 1/255.0, (640, 640), swapRBTrue) out session.run(None, {input_name: blob.astype(np.float32)})[0]输出张量形状一般是(1, 25200, 85)其中25200是三个尺度特征图的预测框总数85是4个坐标加1个置信度再加80个类别分数。后处理部分需要把YOLOv5官方仓库的non_max_suppression函数从PyTorch改成numpy版本步骤就是按置信度过滤、坐标解码、IoU抑制三步。我犯过的一个低级错误是忘记把归一化坐标映射回1280x720原图结果检测框全都偏在图像角落排查了很久才发现是坐标缩放的问题。4.3 性能到底够不够分辨率和量化的取舍树莓派5的CPU推理性能我用同一块板子实测了几个模型配置数据记录如下模型输入分辨率实测帧率说明YOLOv5s640x640约1.2 FPS精度最好只能按需抓拍YOLOv5n640x640约2.8 FPS速度明显提升YOLOv5n320x320约8 FPS接近实时小目标有漏检风险如果车间场景是每3秒抓一帧做安全帽检测YOLOv5n在320分辨率下完全够用。但如果是连续视频流检测CPU推理帧率就不够看了。我当时的优化顺序是先尝试降低输入分辨率再考虑INT8静态量化。量化需要注意校准集的选择必须从现场摄像头抽几百帧不能用训练集或网络图片否则量化后的精度衰减会让你怀疑模型出了问题。如果这些优化都做完了还是追不上需求就该认真考虑外接算力了。树莓派官方后来出的AI Kit用的是Hailo-8L芯片13 TOPS算力常见的YOLOv5模型能跑到30-40 FPS。模型转换工具链比较顺等于给树莓派5装了一个实时的视觉大脑。CPU推理适合低成本、低帧率、按需检测的车间场景要上实时视频分析就绕不开专用AI加速器。5. 网络与远程管理无头模式下的车间存活指南5.1 固定IP和网络安全基线车间里的无头设备最怕IP漂移。如果树莓派用的是DHCP路由器一重启或者交换机端口重新检测分配到的IP可能就变了远程SSH连不上上位机也找不到数据源。我部署前先和负责车间网络的同事确认了IP规划给树莓派一个固定内网地址。Ubuntu下用netplan管理网络最清晰编辑/etc/netplan/01-netcfg.yamlnetwork: version: 2 ethernets: eth0: dhcp4: false addresses: - 192.168.10.66/24 routes: - to: default via: 192.168.10.1 nameservers: addresses: - 192.168.10.1修改完执行sudo netplan apply生效。注意如果在远程SSH会话里执行这一步连接会中断一下最好坐在本地面前操作或者准备好第二条应急通道再改。车间网络一般都有安全要求不要把所有端口都暴露出来。我只开启22端口给运维白名单图像预览端口只绑定在127.0.0.1需要看画面时通过SSH隧道方式访问而不是直接把端口暴露给整个网段。类似Modbus、MQTT这类工业协议如果不需要对外开放就不要监听在0.0.0.0上绑定内网具体IP更稳妥。5.2 远程调试和长任务会话管理无头部署后日常维护全靠SSH。强烈推荐tmux作为长任务会话管理器原因很简单推理任务一跑就是几个小时SSH连接一旦因为网络不稳定或笔记本休眠断开前台进程就会收到SIGHUP信号挂掉。tmux里开的会话独立于SSH连接断线重连后进程还在运行这对远程调试几乎是救命级的功能。基本用法tmux new -s det tmux attach -s det我在det会话里跑推理程序平时不开电脑也能让树莓派自己干活。上线前的重要操作都在tmux里执行这样即使网络抖动也不影响任务继续运行。如果你常用VSCode之类的编辑器也可以配合ssh remote插件但最终真正执行长任务的进程一定要脱离SSH会话这算是一个可以写到团队内部手册里的原则。6. 部署最后一公里从能跑到连续一个月不抽风6.1 systemd服务把无人值守变成可能手动执行python detector.py这种方式不适合车间现场。我最后把所有应用都交给systemd管理开机自动启动崩了自动重启日志统一进journalctl排查问题时一个journalctl -u命令就能看到全部输出。我用的服务配置大致是这样[Unit] DescriptionYOLOv5 factory detector Afternetwork-online.target Wantsnetwork-online.target [Service] Userpi WorkingDirectory/home/pi/detector ExecStart/home/pi/yoloenv/bin/python /home/pi/detector/run.py --config config.yaml Restartalways RestartSec5 EnvironmentPYTHONUNBUFFERED1 [Install] WantedBymulti-user.target部署时最容易忽略的是WorkingDirectory。如果漏配程序里的相对路径读不到模型文件和配置文件服务起来必然失败。用systemd还有一个好处是可以通过RestartSec控制重启间隔避免程序刚启动就崩溃、一秒钟重启几十次的疯狂循环。6.2 检测结果如何送到产线系统里车间里没有显示器检测结果必须传到工控机或PLC侧。我这边最简单的方式是走MQTT工控机上跑一个MQTT broker树莓派每检测到异常就发一条消息。上报代码很直观import paho.mqtt.client as mqtt client mqtt.Client(client_idpi5-cam1) client.connect(192.168.10.50, 1883, 60) client.publish(workshop/alert, {camera:1, type:no_helmet})这里有一个很实际的忠告不要把检测到异常的图片编码成base64塞进MQTT消息里消息会变得非常臃肿QoS一高还会阻塞检测线程。我的做法是异常时把图片保存到本地目录再单独用一个HTTP接口让上位机按需拉取MQTT只负责通知事件。为了让检测和上报解耦我在代码里用了一个队列检测线程只负责把结果放进队列上报线程消费队列并发送消息。这样网络抖动时检测不会卡住上报线程可以等网络恢复后继续发送积压的消息。这个设计虽然简单但避免了“网络一抖摄像头画面就断掉”的连锁反应。6.3 上线前的24小时耐久测试正式上线前我把板子留在车间连续跑了24小时从日志里暴露了好几个白天根本看不出来的问题凌晨某个外设唤醒引发的电流尖峰导致板子重启MQTT broker未启动时连接重试太频繁把CPU占满摄像头在雷雨天气出现过一次断流但服务没有自动恢复。这些问题全部暴露后我针对性改了代码和systemd配置之后才敢让它无人值守。验收阶段我建议记录几个关键指标CPU温度曲线、内存占用、单帧推理耗时、服务重启次数、图片积压数量。用一个小脚本每小时把数据追加到CSV文件后面复盘非常有用#!/bin/bash while true; do echo $(date %F_%T) $(vcgencmd measure_temp) $(free -m | awk NR2{print $3}) /home/pi/logs/runtime.csv sleep 60 done长期稳定运行还有一个容易忽略的坑日志膨胀。journald默认会无限积累日志时间长了会把SSD空间占满。建议在/etc/systemd/journald.conf里设置SystemMaxUse500M之类的上限图片保存目录按日期建子目录定期清理。树莓派5本身性能很强但工业场景里终端稳定性和运维便捷性远比跑分重要这一点怎么强调都不过分。把树莓派5送进车间这一个月我对它的定位反而更清楚了它确实不是工业工控机的完全替代品但作为边缘视觉里性价比极高的一台小盒子只要对照系统、散热、供电、摄像头、模型、运维这六个卡点逐个验收它完全能在生产线上稳定干活。我自己最大的体会是工业场景里最值钱的不是模型本身的准确率而是连续一个月不出幺蛾子的工程能力。如果以后再让我部署一台我会先把无人值守和日志监控做好再考虑推理速度优化。