上个月我把树莓派 5 带进车间，打算用它跑自己训练的 YOLOv5 模型，在产线上做简单的工件识别。当时的想法很天真：模型在服务器上已经有七八成的检测精度，板子功耗也就十来瓦，接个摄像头，撑死两三天就能跑起来。结果前后卡了差不多两个星期，问题根本不在算法，全在那些写字楼里做开发的人根本碰不到的破事上：供电、散热、系统、模型部署、网络、存储，每一项都能让板子当场罢课。这篇按我实际踩坑的顺序把六件事一次说透，给同样想把树莓派 5 塞进车间现场的人一个完整交代。
1. 第一件事，供电：5V/5A 的纸面指标在车间里为什么要打个八折
1.1 树莓派 5 为什么突然开始“吃电”了
树莓派 4 时代，官方推荐的电源是 5V/3A，15W 左右基本够用。到了树莓派 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 'temp=C') 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 或者国产的算力棒，插上后推理任务可以卸载到专用 NPU，YOLOv5s 能轻松跑到 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 接板子的 GPIO2，SCL 接 GPIO3，VCC 接 3.3V，GND 接 GND。然后在/boot/firmware/config.txt里启用：
dtoverlay=i2c-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] Description=YOLOv5 Interface Service After=network.target [Service] ExecStart=/usr/bin/python3 /opt/infer/app.py Restart=on-failure RestartSec=5 User=ubuntu WatchdogSec=30 [Install] WantedBy=multi-user.target配合Restart=on-failure，进程意外退出后 5 秒内自动拉起。WatchdogSec=30是给应用的看门狗信号，应用需要定期调用sd_notify报心跳，否则 systemd 视其无响应并重启。这样即使应用内部卡死，也不会让设备静默失联。
6.3 监控与告警：人到不了现场也要心里有数
在车间里，设备出了故障如果没人及时发现，轻则损失一个班次的数据，重则影响产线。我写了一个简单的心跳脚本，每隔一分钟读取 CPU 温度、负载、内存、磁盘和推理服务状态，通过 HTTP POST 发到中控监控平台。中控端设置阈值告警，比如温度超过 85℃、磁盘占用超过 90%、服务心跳超过 2 分钟丢失，就发钉钉或企业微信通知到维护群。
类似的点还可以加一个看门狗脚本，用systemd的WatchdogSec或者独立的硬件看门狗模块，在系统卡死时强制重启。树莓派 5 的现有固件和内核已经支持看门狗驱动，配置好后能在系统无响应时自动硬重启，这是无人值守设备最后一道保险。
这套组合拳下来，设备基本能做到故障就地恢复，维护人员不用天天跑现场。真正需要人工干预的场景，大多是硬件层面的问题，比如电源损坏、网线被拉断、RTC 电池耗尽，而这些都通过监控平台能提前发现。
回头再看这次树莓派 5 进车间的经历，六件事没有一件是算法上的高深难题，全是环境适配的琐碎活儿。如果让我重来一次，顺序一定这样排：先解决供电和散热，再把存储换成 NVMe SSD，最后才谈系统和模型部署。树莓派 5 不是块娇气的板子，但车间的环境也不是办公室，事先把这些“后勤”问题处理干净，后面上线时你会感谢自己省下的那两周时间。
