上个月我把树莓派 5 带进车间打算用它跑自己训练的 YOLOv5 模型在产线上做简单的工件识别。当时的想法很天真模型在服务器上已经有七八成的检测精度板子功耗也就十来瓦接个摄像头撑死两三天就能跑起来。结果前后卡了差不多两个星期问题根本不在算法全在那些写字楼里做开发的人根本碰不到的破事上供电、散热、系统、模型部署、网络、存储每一项都能让板子当场罢课。这篇按我实际踩坑的顺序把六件事一次说透给同样想把树莓派 5 塞进车间现场的人一个完整交代。1. 第一件事供电5V/5A 的纸面指标在车间里为什么要打个八折1.1 树莓派 5 为什么突然开始“吃电”了树莓派 4 时代官方推荐的电源是 5V/3A15W 左右基本够用。到了树莓派 5芯片换成了四核 Cortex-A76主频能跑到 2.4GHz官方直接推荐 27W 的 USB-C 电源也就是 5V/5A。注意这个变化不是厂商拍脑袋而是 A76 核心在高负载下的瞬态电流确实比以往大很多。四颗核心同时满载再插上摄像头和 USB 设备瞬间电流飙到 4A 以上一点都不夸张。我在办公室开发时用的是官方电源一切正常。把板子搬进车间后图方便直接从工位旁边的开关电源接了一路 12V再用一个 DC-DC 模块降到 5V刚开始跑起来也没问题。结果一挂上摄像头做实时推理两三分钟就自动重启一次完全没法用。那会儿还不知道是供电问题怀疑是系统崩了折腾了好几天。如果你也遇到“跑着跑着突然重启”“USB 设备随机掉线”“开机后无线网卡找不到”这类现象优先怀疑电压。1.2 用一条命令确认是否欠压树莓派的固件里内置了电源管理芯片欠压是会记录的。登录板子后运行vcgencmd get_throttled返回值是一个十六进制数。我这边卡的时候输出是0x50002。这个值的含义需要拆开看bit0为 1 表示当前正在欠压bit1为 2 表示历史上发生过欠压bit16为 1 表示当前处于温度限制导致的降频状态。我那次看到0x50002说明欠压发生过而且温度也快顶到墙了两个问题同时存在。再配合看实时电压vcgencmd measure_volts正常情况下核心电压在 4.9V 以上。如果测出来长期低于 4.8V基本可以断定供电不足。这是我在现场排障时最常用的一套组合拳比拿万用表量还直观。1.3 车间供电的三个落地做法车间的供电环境和办公室完全是两个世界。大功率设备启停、电机变频、电焊机工作都会造成母线电压瞬时跌落。我这次卡住的直接原因不是 DC-DC 模块标称能力不够而是它在负载突变时输出电压跌落导致树莓派瞬间掉电重启。后来我做了三个调整单独走一路电源。给树莓派配了一个独立 5V/5A 的工业电源不和产线其他设备共用一个接线端子排避免其他设备启动时把电压拉低。输出端并联电容。在树莓派的电源输入脚附近并了一个 1000μF 的电解电容和一个 0.1μF 的陶瓷电容吸收瞬态浪涌。电解电容负责“蓄水”陶瓷电容负责滤高频噪声两个配合能明显缓解瞬间压降。用 INA219 模块做实时监测。我在电源线上串了一个 INA219 电流电压检测模块通过 I2C 读实时电压电流记录到日志里。这样既能确认问题是否解决也能在后续排查其他故障时提供数据。提示树莓派 5 的 USB-C 接口支持 PD如果你用 PD 充电头供电请选支持 5V/5A 输出档位的很多普通手机充电头虽然标的 20W 甚至 30W但走的是 9V/12V 协议5V 档位只有 2A根本喂不饱。供电这件事处理完后重启问题消失了但紧接着迎来了第二个麻烦——温度。2. 第二件事散热YOLOv5 一跑起来温度直接教我做人2.1 不看温度表的被动散热方案都是自欺欺人树莓派 4 时代就有不少“加个散热片就行”的说法到了树莓派 5这套经验基本失效。四核 A76 满载时的发热量比上一代大了不少被动散热片在办公室常温下还能应付日常桌面场景但拿到持续跑推理的车间环境完全不行。我的测试环境是室温 28℃ 的车间角落无主动风扇只加了一块铝制散热片。跑 YOLOv5 推理持续十分钟后用vcgencmd measure_temp看 SoC 温度稳定在 87℃ 以上这还是没装任何外壳的情况。温度一上来系统会自动降频从 2.4GHz 一路掉到 1.8GHz 甚至更低推理时延从几百毫秒拉到一秒以上帧率直接腰斩。这和我之前遇到的“重启”叠加在一起让我一度以为是代码写得有问题直到发现get_throttled里出现了温度限制位才反应过来。在车间里尤其是夏天不通风的控制柜环境温度本身就高板子散热只会更差。2.2 实测不同散热方案的表现我试过几种方案简单列个对比方案满载稳定温度说明裸板铝散热片87℃ 左右持续推理会降频官方主动散热器62℃ 左右带风扇日常足够铝壳内置风扇58℃ 左右适合有粉尘的车间铝壳纯被动80℃ 以上不推荐实测下来带风扇的主动散热几乎是必须的。官方主动散热器性价比高但我这边车间粉尘比较大风扇直接裸露容易积灰最后选了带防尘网的铝壳加内置温控风扇方案。2.3 温控风扇的脚本与部署风扇不能一直全速转噪音大寿命也短。我用一个最简单的温控脚本每 10 秒读一次温度超过 70℃ 开风扇降到 55℃ 关风扇再用 systemd 托管起来开机自启。#!/bin/bash # /usr/local/bin/fan_control.sh while true; do temp$(vcgencmd measure_temp | tr -d tempC) temp_int${temp%%.*} if [ $temp_int -ge 70 ]; then echo 255 /sys/class/leds/led0/brightness # 实际风扇控制引脚按你的接线调整 elif [ $temp_int -le 55 ]; then echo 0 /sys/class/leds/led0/brightness fi sleep 10 done上面脚本里我用系统 LED 代替了风扇控制引脚示例实际接法取决于你用的风扇模块。如果你用 GPIO 控制 MOSFET 驱动风扇就把 echo 的目标改成对应 PWM 接口。这类脚本很简单但能避免风扇 7x24 小时满转车间环境下寿命延长不少。注意控制柜内通风比散热片本身更重要。我见过有人给板子上了最好的散热器却把柜门关得死死的周围全是 40℃ 热风再好的散热器也白搭。加一道强制排风风道比在板子上堆散热器更有效。3. 第三件事系统层Ubuntu 24.04 装好只是万里长征第一步3.1 为什么选 Ubuntu 而不是树莓派 OS关于树莓派 5 上装 Ubuntu我一开始就没犹豫直接选了 Ubuntu 24.04 LTS。原因很实际团队平时用的都是 Ubuntu Server对 apt、systemd、netplan 这些工具熟车间离线环境需要的离线 apt 仓库、内网镜像维护Ubuntu 生态里资料更多。树莓派 OS 当然也能跑但它是桌面向的很多服务器习惯的配置方式在里面都是另一套逻辑对于要长期无人值守的设备我更愿意用自己熟悉的系统。3.2 烧录后的第一道坎SSH 登录不进去我用树莓派 Imager 烧好 Ubuntu Server 24.04 LTS 后把 SD 卡插进板子上电结果 SSH 连不进去。第一反应是网络没配好折腾了一会儿才意识到问题出在系统默认配置上。Ubuntu Server 镜像烧录后默认用户是ubuntu密码在首次登录时必须修改。更坑的是默认情况下 OpenSSH 服务是关闭的或者说不允许密码登录直接进。解决办法有两个一是在烧录时用树莓派 Imager 的高级选项提前设置好用户名、SSH 密钥和无线网络二是烧录后手动挂载 SD 卡的 boot 分区在 user-data 文件里写入 SSH 公钥和初始配置。我在第二次烧录时用 Imager 的“高级选项”直接配置了静态 IP、SSH 公钥和默认用户一次到位。这里给个建议如果你要批量部署多块同样的板卡提前把所有账号、网络、时区在烧录阶段写好能省掉后面每块卡都插显示器手动配置的麻烦。3.3 换卡如换机SD 卡选型直接影响整体体验树莓派 5 对 SD 卡的要求比树莓派 4 更苛刻。我一开始用的是一张以前树莓派 4 上用的普通 A1 卡跑 Ubuntu 安装时装包就经常卡死读写速度上不去系统响应明显迟钝。后来换成 A2 级别、带 V30 标识的高速卡情况才好转。SD 卡在树莓派 5 上不仅仅是容量问题随机读写性能直接决定系统流畅度。A1 卡随机读写 IOPS 低在 apt 安装、日志写入这类大量小文件操作时非常吃力。建议直接按官方兼容列表里推荐的型号买不要贪便宜。如果你已经决定长期在车间跑建议直接考虑后面讲的 NVMe SSD 方案SD 卡只当引导盘。3.4 新系统落地前的五个检查项在把任何应用部署到树莓派 5 之前我建议先花半小时把这几件事过一遍更新固件和系统apt update apt upgrade如果系统包里有rpi-eeprom也顺手更新一下 bootloader树莓派 5 早期批次固件对 PCIe 和风扇控制支持不完整更新固件能规避很多玄学问题。确认 I2C、UART 等接口是否启用。用sudo raspi-config在 interface options 里打开 I2C后面接传感器和 RTC 模块都要用。设置时区和时间同步。车间内网可能无法访问外网时间服务器先把时区设对并预留内网 NTP 同步配置。检查get_throttled返回值确保没有欠压和降频记录。用htop和free -h看一下当前负载和内存占用确认在正常范围。这五项都过了再开始装应用否则后面出问题你很难分清是系统没配好还是软件跑崩了。4. 第四件事模型部署训练花了三天部署花了五天4.1 模型转换链路的选择我在服务器上用 YOLOv5 训练了一个针对车间工件的检测模型导出权重后拿到树莓派 5 上跑。这里第一个教训是不要在板子上直接装 PyTorch 然后把权重文件丢进去跑这条路能走但效率极低而且坑多。板端推理有几种路线我实际对比后选了 NCNN 方案方案能否直接跑 PyTorch 权重预期帧率640 输入部署难度板端装 PyTorch CPU能约 2 FPS高ONNX Runtime需先导出 ONNX约 3-4 FPS低NCNN需导出 ONNX 再转约 5 FPS中我的推荐是先导出 ONNX再用 NCNN 做推理引擎。原因很简单ONNX Runtime 安装一个 pip 包就能用适合快速验证NCNN 更适合嵌入式场景多线程和内存占用优化更好长期运行更稳。导出 ONNX 时注意在 YOLOv5 的 export 脚本里设置固定输入尺寸和 opset 版本python export.py --weights best.pt --include onnx --opset 12 --img 640导出后用onnxsim做一遍计算图简化和onnx2ncnn转换后者会输出.param和.bin两个文件NCNN 推理时加载这两个文件即可。4.2 aarch64 上装 PyTorch 的坑如果你还是想在板端用 PyTorch 做验证或二次开发提前告诉你这有多痛。树莓派 5 是 ARM64 架构Ubuntu 24.04 自带的 Python 版本比较新PyTorch 官方对 ARM Linux 的轮子支持一直不太齐全。直接pip install torch大概率会拉到不合适版本或者编译到一半失败。即使装上了CPU 推理速度也很感人。我实测 YOLOv5s 模型、640×640 输入在纯 PyTorch CPU 下只有 2 FPS 左右完全达不到产线视频流实时检测需求。换成 NCNN 加多线程后能到 5 FPS 上下如果把输入缩到 416 或 320可以跑到 7 FPS 左右。这个差距主要来自计算图优化和内存复用PyTorch 在 PC 上有 CUDA 加速时非常好用但在 ARM CPU 上属于大材小用。4.3 模型压缩的取舍帧率不够时我第一反应是换轻量化模型。YOLOv5n、YOLOv5s 的差异很大我把模型切成 YOLOv5s 并配合量化在精度和速度之间找了个平衡点。NCNN 支持 FP16 和 INT8 量化。FP16 最简单导出时顺手就能开几乎无精度损失。INT8 需要准备一组校准图片量化后模型体积缩小四倍速度也能再提一些但 mAP 会掉一到三个百分点看你的检测任务是否允许。我这边做的是常见工件识别类别少、特征明显INT8 完全可以接受帧率从 5 FPS 提到了接近 8 FPS。4.4 如果帧率还是不够树莓派 5 的核心性能上限摆在那里纯 CPU 推理想跑实时视频流只能靠外部加速器。市场上有 USB 接口的 AI 加速棒比如 Google Coral 或者国产的算力棒插上后推理任务可以卸载到专用 NPUYOLOv5s 能轻松跑到 30 FPS 以上。另一个方向是直接用树莓派 5 的 PCIe 接口接一张 M.2 AI 加速卡性能更强但价格和开发成本也上去了。我的建议是先量化再换模型结构最后才考虑加硬件。加速器需要额外供电、散热和驱动适配在车间恶劣环境下多一个部件就多一个故障点不是必须的话尽量少加。5. 第五件事网络与时间车间里“连得上”和“连得好”是两回事5.1 工控网和办公网之间的墙我在办公室远程调试树莓派 5 时觉得网络根本不是事。到了车间才发现很多工厂的网络是隔离的产线上的工控设备在一个网段办公电脑在另一个网段中间有防火墙控制。我从办公室 SSH 到车间板子完全不通。后来找 IT 申请了防火墙白名单和路由放行才从办公网通过一台跳板机进入车间网段。这里建议各位提前和现场 IT 确认网络拓扑不要假设“有网线就能通”。车间网络里往往还没有 DHCP固定静态 IP 是常态得提前问好可用 IP 段、网关和 DNS。树莓派 5 的 Wi-Fi 在车间里也是个大坑。金属控制柜对无线信号的屏蔽效果非常明显我实测在柜内信号强度只有 -70dBm 左右断断续续最后直接拉了根网线用千兆有线连接稳定性立刻提升了几个量级。能上有线绝不无线这是车间部署的第一原则。5.2 树莓派 5 没有板载 RTC重启后时间直接穿越这个坑非常隐蔽而且会引发一连串奇怪问题。树莓派 5 和很多开发板一样没有板载 RTC 芯片系统时间完全依赖 NTP。如果车间内网无法访问外网断电重启后系统时间会回到初始状态。我遇到过的情况是板子重启后日志时间倒退了几十天导致日志排查时顺序错乱HTTPS 请求因为证书时间校验失败报错定时任务在错误的时间触发引发了误告警。解决方法是外接一个 DS3231 RTC 模块。接线很简单模块的 SDA 接板子的 GPIO2SCL 接 GPIO3VCC 接 3.3VGND 接 GND。然后在/boot/firmware/config.txt里启用dtoverlayi2c-rtc,ds3231启用后通过i2cdetect -y 1检查模块是否被识别再配置开机自动从 RTC 读取时间。如果连 RTC 模块都没有还有一个折中方案在车间内网架一台 NTP 服务器板子开机后第一时间从内网 NTP 同步只要板子不断电太久时间基本可控。两种方案结合最稳RTC 保底NTP 校准。5.3 数据回传与定时任务落地识别结果要回传到车间中控。我当时用 HTTP POST 把检测结果类别、置信度、时间、图片路径推到中控服务器。这个做起来不复杂但要想清楚断网怎么办。车间网络波动不可避免我在板子本地用 SQLite 存了一份结果网络恢复后由定时任务补传避免现场数据丢失。用cron定时上传时注意时间准不准。如果 RTC 没配置cron会在系统时间错误时乱触发或者不触发。把时间同步搞定后再配定时任务顺序不要反。6. 第六件事长期运行别让一张 SD 卡毁掉整个上线6.1 频繁断电下SD 卡是最容易死掉的部件树莓派 5 支持从 NVMe SSD 启动但很多人初期图省事还是用 SD 卡。车间里频繁断电、意外掉电对 SD 卡是致命的ext4 文件系统在掉电瞬间写入损坏的概率很高。我测试期间那张 SD 卡在经历几次意外断电后系统直接起不来了用读卡器挂到电脑上一看分区表一片混乱。处理办法有三个层次。最彻底最推荐的是给树莓派 5 配一块 M.2 NVMe SSD 转接板把系统装在 SSD 上。树莓派 5 的 PCIe 支持 Gen3 x1实际读写速度比 SD 卡快好几倍而且 SSD 对掉电的容忍度高很多。如果暂时不想加硬件就退而求其次把日志和临时文件放到内存盘里减少对 SD 卡的写入。我用过一个叫 log2ram 的工具原理是启动时创建一块内存盘放/var/log定期同步回 SD 卡。实测效果很明显日常运行中 SD 卡的写入量降到极低。另一个思路是直接启用只读文件系统把根分区挂成只读运行时的写操作全部重定向到内存里的 tmpfs。这个方法更适合调度较固定的设备能极大延长 SD 卡寿命但应用软件需要注意不要往/etc或/var乱写。6.2 用 systemd 把服务守护起来车间设备要求无人值守应用必须能做到“死了自己拉起来、拉不起来就重启系统”。我这边把推理服务写成了 systemd 单元关键配置如下[Unit] DescriptionYOLOv5 Interface Service Afternetwork.target [Service] ExecStart/usr/bin/python3 /opt/infer/app.py Restarton-failure RestartSec5 Userubuntu WatchdogSec30 [Install] WantedBymulti-user.target配合Restarton-failure进程意外退出后 5 秒内自动拉起。WatchdogSec30是给应用的看门狗信号应用需要定期调用sd_notify报心跳否则 systemd 视其无响应并重启。这样即使应用内部卡死也不会让设备静默失联。6.3 监控与告警人到不了现场也要心里有数在车间里设备出了故障如果没人及时发现轻则损失一个班次的数据重则影响产线。我写了一个简单的心跳脚本每隔一分钟读取 CPU 温度、负载、内存、磁盘和推理服务状态通过 HTTP POST 发到中控监控平台。中控端设置阈值告警比如温度超过 85℃、磁盘占用超过 90%、服务心跳超过 2 分钟丢失就发钉钉或企业微信通知到维护群。类似的点还可以加一个看门狗脚本用systemd的WatchdogSec或者独立的硬件看门狗模块在系统卡死时强制重启。树莓派 5 的现有固件和内核已经支持看门狗驱动配置好后能在系统无响应时自动硬重启这是无人值守设备最后一道保险。这套组合拳下来设备基本能做到故障就地恢复维护人员不用天天跑现场。真正需要人工干预的场景大多是硬件层面的问题比如电源损坏、网线被拉断、RTC 电池耗尽而这些都通过监控平台能提前发现。回头再看这次树莓派 5 进车间的经历六件事没有一件是算法上的高深难题全是环境适配的琐碎活儿。如果让我重来一次顺序一定这样排先解决供电和散热再把存储换成 NVMe SSD最后才谈系统和模型部署。树莓派 5 不是块娇气的板子但车间的环境也不是办公室事先把这些“后勤”问题处理干净后面上线时你会感谢自己省下的那两周时间。
)
)
