车间里的机器视觉改造，我们一开始是奔着工业相机加工控机去的，结果预算被砍了两轮。后来团队里有人提出用树莓派 5 顶一顶，理由是单板机性能足够、生态成熟、替换成本低。当时我对这事持保留态度——毕竟树莓派从 4B 开始就常被人说"跑 demo 可以，落生产环境不行"。但树莓派 5 出来后形势确实变了，PCIe 接口、更强的 CPU、官方 NPU 套件，让它有了点边缘小服务器的意思。于是我们真把它搬进了车间，然后就被现实教育了。
从装 Ubuntu 到部署自己训练的 YOLOv5 模型，从开机到连续运行，前前后后卡在六件看似不大、但每一个都能让你耗掉一两周的事情上。这篇文章就是完整的踩坑记录，包含排查思路、实测数据和最终能稳定跑起来的干活配置。如果你也在琢磨把树莓派 5 用在工业现场做视觉检测、设备状态识别这类场景，这篇应该能帮你省下不少时间。
1. 供电是第一个暗坑：车间电源环境与树莓派 5 的"娇贵体质"
1.1 为什么树莓派 5 比前代更容易在车间翻车
树莓派 5 的性能提升是实打实的，四核 A76、频率拉到 2.4GHz，跑 YOLOv5s 推理时的整体功耗比 4B 高出一大截。官方推荐的电源规格是 5V/5A，也就是 25W。很多人觉得"5V/5A 不是随便一个充电头都能给吗"，这话在办公室成立，在车间就是灾难。
车间里面最常见的供电来源是开关电源（SMPS）或者带长距离走线的插座回路。这些电源有两个特点：一是电压纹波大，二是动态响应差。当树莓派 5 在 CPU 满载、NPU 推理、摄像头采集同时进行时，瞬时电流可以冲到 3A 以上。这时候如果电源本身压降厉害，或者线缆太细太长，树莓派的输入电压会跌破 4.5V。后果不是当场关机，而是两个非常隐蔽的症状：USB 外设随机掉线、系统莫名其妙重启。
我一开始根本没往供电想，因为系统日志里没有任何异常错误，就是每隔几小时重启一次。后来用万用表并联在 5V 引脚上观察才看到，负载一起来电压就掉到 4.35V 左右。树莓派 5 的电源管理芯片虽然没有当场断电保护，但低压会让 PMIC 进入欠压状态，表现就是"死给你看"。
1.2 供电排查的具体方法
这里分享下我的排查链路，供遇到类似问题的人参考：
- 第一步，看硬件指示灯。树莓派板载的红色电源 LED 在欠压时会闪烁，但我实际观察发现闪烁并不明显，尤其在工业照明环境下很容易忽略。
- 第二步，查系统日志和电压寄存器。在终端输入
vcgencmd pmic_read_adc可以直接读取 PMIC 采集的电压值；更简单的是用vcgencmd get_throttled，返回结果里 bit0 表示欠压发生过。我遇到的情况就是返回值不为 0，说明欠压已经触发了。 - 第三步，排除法换电源。用官方 27W USB-C 电源替换车间原有的适配器，同时把线缆换粗，电压问题直接消失。
1.3 车间供电的可靠方案
经过这次教训，我在车间部署时对供电做了三条规定：电源必须用带稳压输出的工业 DIN 导轨电源（比如明纬 HDR-15-5 这类，5V 输出，纹波控制在 50mV 以内）；接线长度控制在 1.5 米以内，使用 18AWG 以上的线缆；在树莓派 5 的 5V 和 GND 引脚上并联一颗 100µF 电解电容和一颗 0.1µF 陶瓷电容，辅助吸收瞬态波动。这套组合用下来，再也没有出现过无故重启的情况。
注意：树莓派 5 的 USB-C 供电口虽然支持标准 PD，但不是所有 PD 充电头都能兼容。有些 PD 头在协商电压时跳变过快，反而会触发树莓派的输入保护。工业现场优先选直流稳压电源，别贪方便用手机充电头。
2. 散热不是"装个风扇"那么简单：工位粉尘与长期运行的压力测试
2.1 树莓派 5 的发热量到底有多夸张
树莓派 5 的 CPU 在满负荷编译或者跑推理时，裸奔十分钟就能冲到 90°C 以上。90°C 是树莓派 5 默认的软降频阈值，到了这个温度系统会把 CPU 频率往下压，推理帧率肉眼可见掉一截。我在给 YOLOv5 模型做压力测试的时候，连续跑 4 小时之后发现 FPS 从初始的 8 掉到了 5 左右，一查温度传感器，已经贴着 92°C 跑了半天。
问题是车间环境比办公室恶劣得多。很多工位附近有粉尘、油雾，你不可能开个普通小风扇对着板子吹，粉尘进到散热鳍片里反而会形成隔热层，越吹越热。
2.2 三种散热方案的实测对比
我前后试过三种散热方案：纯被动散热片、官方 Active Cooler（带风扇）、以及把树莓派 5 放进铝合金密闭壳再外接工业级散热风扇。
| 散热方案 | 空载温度 | 满载温度 | 噪音 | 粉尘适应性 |
|---|---|---|---|---|
| 纯铜散热片（无风） | 52°C | 88°C | 无 | 一般，鳍片积灰后散热效率下降 |
| 官方 Active Cooler | 45°C | 76°C | 中 | 差，风扇进灰后噪音增大且风量下降 |
| 铝合金壳+外接 6025 风扇 | 41°C | 63°C | 低 | 优，风道独立，板子不直接接触粉尘 |
最终我选用的是铝合金壳加外接风扇的方案，风扇不直接对着板子吹，而是通过外壳的散热鳍片带走热量。实测下来满负载温度稳定在 63°C 左右，CPU 全程跑满 2.4GHz，没有触发一次降频。这里有个关键点：散热方案必须和部署场景一起考虑，只看室温是不够的，还得看灰尘累积速率、维护周期、是否允许风扇噪音。
2.3 一个容易忽略的散热细节
树莓派 5 的 CPU 和无线网卡芯片在 PCB 的同一侧，无线模块对高温也很敏感。我在测试中发现，当散热方案不给力时，Wi-Fi 模块的信号强度会周期性衰减，SSH 远程连接频繁断开。这一点在后面的网络问题排查中也造成了干扰。所以做温度压测的时候建议连 Wi-Fi 一起测，别只盯着 CPU 频率。
3. 别再让 SD 卡背锅：启动方式与存储方案的工业级改造
3.1 树莓派 5 启动链路的变化
树莓派 5 在启动方式上和前代有个重要区别：它板载了 4MB SPI Flash 用于存放启动固件，启动模式的优先级和配置逻辑变了。默认情况下它仍然尝试从 SD 卡启动，但如果你插了 NVMe SSD 或者 USB 存储，可以按住特定按键强制进入 USB 启动模式。树莓派 5 的引导芯片出厂固件版本直接决定了对 NVMe 的支持情况，所以拿到板子第一件事是先更新 EEPROM 固件，命令是sudo rpi-eeprom-update。
这个步骤很多人会跳过去，但如果你想用 NVMe SSD 启动，旧固件可能会在开机时反复重启或者找不到引导设备。我刚开始用树莓派 5 配 NVMe 扩展板时就被这个问题坑过，一度以为是扩展板兼容性问题。
3.2 SD 卡在车间为什么撑不过两个月
SD 卡在工业场景下有致命的弱点：一是磨损均衡算法面对大量小文件读写时效率低下，二是热插拔和突然断电容易造成文件系统损坏。车间里的树莓派如果跑视觉检测，模型文件和日志文件会被频繁读写，再加上现场工人偶尔直接拔电源（这个问题后文会详细说），SD 卡通常撑不过两个月就出坏块。坏块的表现是先频繁报 I/O error，然后整个文件系统变成只读，最后彻底无法启动。
所以从第一台设备部署开始，我就决定弃用 SD 卡。树莓派 5 的 PCIe 接口可以转接 NVMe SSD，实测下来顺序读写能到 800MB/s 以上，随机读写比 SD 卡提升几十倍，系统启动时间从 40 秒压到了 12 秒，模型加载速度也快了一倍。
3.3 SSD 启动的系统配置要点
我用的是树莓派 5 官方 PCIe 扩展板加一块 128GB 的 NVMe SSD，系统选择是 Ubuntu 24.04 LTS（热搜词里的"树莓派5安装ubuntu"指的就是这个方向）。安装过程这里不赘述，有几个必须注意的点：
- 在
raspi-config里把 root 文件系统的挂载参数改成discard，否则 SSD 的 TRIM 指令无法生效，长期使用会产生写放大； - 内核参数里加上
nvme_core.default_ps_max_latency_us=0，防止 SSD 在低功耗状态切换时出现 I/O 延迟尖刺。这个参数不加的话，偶尔会出现推理任务卡顿几十毫秒的情况，在视觉检测场景中会被判定为漏检； - 日志分区不要放在默认的 root 分区里。我单独划了一个 4GB 的 tmpfs 挂到
/var/log，重启自动清空，避免日志持续写 SSD 加速磨损。
4. "卡在部署上"的第一道坎：YOLOv5 模型上机的选型误区
4.1 树莓派 5 的 GPU 为什么跑不了 CUDA
这是我在项目初期最大的天真想法。树莓派 5 的 GPU 是 VideoCore VII，基于 V3D 驱动，走的是 OpenGL ES / Vulkan 那套图形栈，和 NVIDIA 的 CUDA 体系完全是两个世界。所以你在 PC 上训练好的 YOLOv5 PyTorch 模型，不能指望直接往树莓派上一放就能跑，更别说什么 GPU 加速推理。
那树莓派 5 的 GPU 能干吗？理论上可以通过 GLES API 做通用计算，但实际开发效率极低，YOLOv5 这种卷积网络在上面跑起来比 CPU 还慢。真正能让模型在树莓派 5 上跑出实用速度的，只有两条路：一是针对 ARM CPU 的推理引擎优化，二是外接树莓派官方 AI Kit（基于 Hailo-8L NPU）。
4.2 我踩过的部署路线：从 ONNX 到 NCNN 再到 Hailo
最初我用 ONNX Runtime 的 CPU 版本直接推理，把 YOLOv5s 转成 ONNX 格式，跑 640×640 输入，FPS 只有 3.5 左右。这个速度用来实时检测根本不够，但如果你只是做拍一张照片再分析的场景，倒也能对付。后来换成 NCNN，它对 ARM 平台做了汇编级优化，同样条件下 FPS 提升到 8 左右。这个提升主要来自 NCNN 的算子融合和特定的 ARM NEON 指令优化，直接用官方 ONNX Runtime 是享受不到这些优化的。
真正让我满意的方案是接树莓派官方 AI Kit，也就是 Hailo-8L NPU。这块 NPU 有 13 TOPS 的算力，跑 YOLOv5s 能达到 30 FPS 以上。Hailo 的模型转换流程是这样的：先用 Hailo Dataflow Compiler 把训练好的 PyTorch 模型（或 ONNX 模型）编译成 HEF 格式，再在树莓派上通过 HailoRT 运行时调用。
这里最大的坑是 Hailo 编译器对模型算子有严格要求。我一开始用自己训练的 YOLOv5s，里面加了几个自定义的注意力模块，编译时 Hailo 直接报 op 不支持。后来尝试用 Hailo 官方提供的 YOLOv5 模板作为基础，把自己训练的数据集重新训练一轮，才成功编译并部署。所以如果你打算用树莓派 AI Kit，最稳妥的路线是：先在 Hailo 支持的模型结构范围内做训练，再考虑后期优化，别先训完再试图转换。
4.3 量化与精度实测
Hailo-8L 默认跑的是 INT8 量化模型。量化过程会带来精度损失，这是绕不开的。我在自己的数据集上做了 mAP 对比：
| 模型格式 | mAP@0.5 | 推理耗时 | 备注 |
|---|---|---|---|
| PyTorch FP32（PC） | 92.4% | - | 训练基线 |
| ONNX FP32（树莓派 CPU） | 92.4% | 285ms | 精度无损 |
| NCNN FP32（树莓派 CPU） | 92.3% | 125ms | 精度基本无损 |
| Hailo INT8（NPU） | 90.1% | 28ms | 精度下降 2.3% |
2.3% 的精度损失在大多数检测场景下可以接受，如果对低置信度目标特别在意，可以在后处理阶段把置信度阈值适当降低来弥补。
另外一个经验是：量化校准集的数据分布越接近真实场景越好。我第一次用训练集的子集做校准，部署后发现夜间工位灯光下的检测率明显下降，换成现场采集的图片重新校准之后就正常了。这个细节直接决定了模型在车间环境下的实际表现。
5. 远程运维才是真正的大坑：网络、显示与自动化部署
5.1 车间 Wi-Fi 为什么不可靠：固定 IP 与有线网络
一开始我们图省事，给每台树莓派都配了 Wi-Fi。车间里有金属货架、叉车、电机，Wi-Fi 信号被遮挡干扰得很厉害，连接断断续续。这个问题的排查难度在于，网络断开和散热问题会导致同样的症状——SSH 掉线、远程推理服务无响应——让人很难一眼定位是网络还是系统问题。
后来我用了一个笨但有效的办法：把树莓派全部改成有线网络接入车间工业交换机，并在路由器上为每台设备绑定固定 IP。树莓派 5 的有线网口支持千兆，跑推理任务传输图片完全够用。Wi-Fi 只保留在调试阶段用，正式部署一律走有线。
网线选择上也有讲究，车间环境尽量用工业级屏蔽网线（SFTP 或 STP 类型），普通家用网线在电机干扰下偶尔会出现 CRC 错误导致重传，虽然不至于断网，但会让远程传输大文件的速度慢很多。
5.2 无头部署的 SSH/VNC 坑
树莓派 5 跑 Ubuntu 后，第一次开机如果不接 HDMI 显示器，很容易一头雾水。Ubuntu 的默认镜像里 SSH 服务默认是关闭的（树莓派 OS 支持通过放一个ssh空文件到 boot 分区来开启，Ubuntu 不认这个机制）。我在 Ubuntu 24.04 上实现无头部署的做法是：烧录镜像后，把 SD 卡（或 SSD）插回电脑，挂载 boot 分区，编辑network-config和user-data文件（Ubuntu 的 cloud-init 机制），在里面提前写好 Wi-Fi 或静态 IP 配置以及 SSH 公钥，这样上电就能直接 SSH 连进去。
VNC 这块我踩过一个更大的坑：树莓派 5 的 Ubuntu 镜像默认没有开启 wayvnc 或者 x11vnc，需要手动安装并配置桌面环境。如果只是为了看推理画面的可视化结果，别折腾 VNC，直接在浏览器里开一个轻量的 HTTP 视频流服务（比如用 MJPG-streamer 搭配 Flask），反而稳定得多。我自己后来把检测画面做成了一个内网网页，手机上就能看，完全替代了 VNC 的需求。
5.3 批量刷机与镜像定制
车间里如果有多台树莓派 5，一台台手动装环境效率太低了。我建议在完成一台设备的系统配置和模型部署之后，直接把整张 SSD 做成镜像文件，然后用树莓派 Imager 的"自定义镜像"功能批量刷到其他设备上。这一步有几个细节：
- 刷镜像前要清掉 SSH host key、改掉机器名，否则多台设备在同一网段会冲突；
- 用
hostnamectl set-hostname改完机器名后，/etc/hosts也要同步改，否则 sudo 解析时会卡几十秒； - 批量刷完后用 Ansible 或者简单的 shell 脚本统一改静态 IP、时区、NTP 服务器。我有一次漏改了 NTP，导致 3 台设备系统时间漂移了几分钟，推理结果的时间戳串到了错误的生产批次上，排查了整整一个下午。
6. 停电与断电：工业场景最容易被忽略的系统稳定性设计
6.1 意外断电如何让树莓派 5 变砖
树莓派 5 用 NVMe SSD 启动后，断电情况下的健壮性比 SD 卡好很多，但依然有变砖风险。末班车断电最危险的时间点有两个：一是 SSD 正在写入日志或模型权重文件时，二是文件系统 journal 正在回放时。如果连续断电次数多，即使 SSD 本身没坏，文件系统也可能进入不可修复状态，只能重新刷机。
车间现场的断电防不胜防。我遇到过工人为了换工装直接拉掉整个工位电闸的，也遇到过车间供电回路跳闸导致 4 台树莓派同时断电的。这类问题不能靠"跟工人强调别断电"解决，必须在系统层面做防御。
6.2 只读文件系统与掉电保护
我最终采用的方案是让 root 文件系统以只读方式挂载，配合 overlayfs 把运行时产生的写操作映射到内存分区。这样无论怎么断电，系统镜像本身都不会被写坏。需要持久化的数据（比如模型文件、配置、检测日志），单独挂载一个带sync选项的 data 分区，并且接受"断电时最后一次写入可能丢失"的现实。对视觉检测场景来说，这个取舍完全合理——宁可丢失最后几秒的日志，也不能让整台设备变砖。
具体实现：在/etc/fstab里把 root 分区加ro参数，使用systemd的tmpfs挂载/var和/etc下的可变目录（或者用一个 overlay 脚本统一处理）。这套做法在嵌入式 Linux 领域很成熟，但在树莓派社区讨论得不多，属于"没人告诉你但非常管用"的工业部署经验。
另外硬件层面我加了一块 UPS 小模块，不需要维持太久，能撑住 5 秒就行，给系统一个安全关机的窗口。我用的是树莓派专用的 UPS HAT（比如 Geekworm X728 之类），设置成 AC 断电后延时 10 秒自动关机，这样批量断电时每台设备都能从容地落盘退出。
6.3 断电恢复与自启动策略
设备重启后要能自动恢复工作，不能等人去现场手动敲命令。这里有两个层次的自启动：
第一层是 systemd 服务。把推理程序注册为 systemd service，设置Restart=always和RestartSec=5，保证程序崩溃或系统重启后自动拉起。
第二层是硬件看门狗。树莓派 5 支持通过watchdog内核模块使用板载看门狗定时器（BCM2712 内置）。我在/etc/watchdog.conf里配置了喂狗间隔和超时时间，一旦系统卡死超过 30 秒，看门狗会强制重启硬件。这一步非常关键，因为推理程序偶尔会因为驱动 bug 进入死循环，如果没有看门狗，系统就一直卡在那里，远程运维完全失效。
最后补一个经验：部署前一定要测试"重复断电 20 次"。 我在正式上线前拿一台样机反复断电，结果第一次测试就暴露了一个问题：某些第三方库在系统异常退出后留下的锁文件，会在下次启动时导致程序拒绝运行。后来所有服务启动前都加了一层锁文件清理逻辑，这个隐患才算彻底排除。建议你也把这种暴力测试纳入验收流程，工业现场的环境比任何测试实验室都残酷，宁可提前把它蹂躏坏了，也别让它上线后突然罢工。
树莓派 5 在车间里站住脚之后，我最大的体会是：单板计算机进工业现场，最难的从来不是算法和代码，而是供电、散热、存储、网络这些"基建活"。它们每一项单独拎出来都不复杂，叠在一起就能把你拖进无底洞。如果重新来一遍，我会先按这篇文章的顺序把六件事全部验证完，再开始碰模型部署，能少走很多弯路。
