企业官网建设流程全解析

树莓派 5 的性能确实猛，四核 A76 拉到 2.4GHz。但把它弄进车间跑自训的 YOLOv5 模型，装 Ubuntu 只是第一步，真正卡住我的全是平时想不到的破事。项目本身不复杂：产线上装一套视觉检测，用自己训练的 YOLOv5 模型识别工件缺陷，树莓派 5 负责采集图像、跑模型、输出结果。本来计划三天部署完成，实际从装箱起整整两周半才稳定下来。卡住我的不是模型精度，也不是算法设计，是六件小事：供电、散热、系统、模型部署、相机触发、数据落盘。这篇不炫技，全是现场记录，每一件都会讲现象、原因、解决办法和坑位。如果你也想把树莓派 5 用到车间、仓库或者任何工业现场，这份记录能帮你省下一两个星期。

1. 进车间前，我的整体设计与选型思路

1.1 为什么偏偏选树莓派 5

做视觉检测的方案其实不少。NVIDIA Jetson Orin Nano 性能更强，但那阵子缺货且贵，开发资料也比较分散；x86 迷你主机随便一台都能跑，可机房或者机柜里塞一台带风扇的电脑，功耗和体积摆在那里，做一个工位的成本也压不下来。树莓派 5 的好处是整套都齐：板子、电源、SSD、摄像头，几百块能配出一套，而且 GPIO 可以直接接光电传感器和继电器，省掉了一个额外的 IO 采集盒子，这在预算紧张的项目里是很实在的加分项。

更关键的是软件路线的判断。自训练的 YOLOv5 模型，只要推理框架选对，四核 A76 上做实时检测是有戏的。我在开发台上先验证过一轮：PyTorch 直接推理只有不到 1 FPS，但是换了轻量级推理框架之后能到 10 FPS 以上，这个前提一旦成立，选型就说得通了。如果当初模型再大一点，比如 YOLOv5m 或者精度要求更高的 YOLOv8、RT-DETR，结论就得改成 Jetson。所以我的建议是：树莓派 5 适合小目标、单路相机、轻量模型这样的小型检测场景，不适合多路视频或者超大模型的工业视觉服务器。

1.2 车间环境下不得不在意的四件事

把开发台上跑通的方案搬进车间，完全是换了一种生存环境。我提前列了四个和实验室不一样的点，结果每一个都成了后面翻车的导火索。

第一是电源。车间里 380V 电机的启停很频繁，电网电压会跟着波动，普通 USB 充电器在电压跌落时几乎没有任何缓冲能力。第二是散热。夏天车间环境温度能到 35℃ 以上，树莓派 5 满载时的发热明显比树莓派 4 高出一大截，被动散热基本压不住。第三是网络和运维。现场不可能给你配一个显示器加键盘，一切操作都靠远程，网络一断就得整个人跑进车间。第四是防护。车间里有灰尘、震动、金属碎屑，裸板直接暴露在外面，迟早要出问题，不是短路就是信号干扰。

这四条后面全部以我没预料到的方式爆发了。下面把这六件事逐件说清楚，每一件都对应一个真实翻车现场。

2. 现场卡住我的六件事，逐一拆开讲

2.1 供电：不是插上电源适配器就能跑

第一件事也最朴素——供电。树莓派 5 官方要求 5V/5A 的 USB-C，我用的 8GB 版本在满载时可以轻松跑到 20W 以上。一开始我图省事，拿了块普通手机充电头去顶，结果流水线一启动，电控柜旁边的大电机一吸合，系统就直接重启。重启一次，推理服务要重新拉起来，中间几十个工件没检测到，这种事故在产线上是不可能被接受的。

我用万用表盯了 USB-C 口上的电压：空载 5.1V 一切正常，电机启动瞬间掉到 4.5V 左右，虽然只持续了不到一秒，但树莓派 5 内部的电源管理芯片只要检测到欠压就会立刻重启或者干脆锁死。这事分两个层面：一是电源本身带载能力太弱、纹波太大，二是外部电网的冲击没有任何缓冲就传了进来。

我的解决办法分两步。先用导轨式工业电源（5V/5A 规格）替代消费级充电器，这类电源的调整率和纹波指标完全不在一个级别；然后在供电入口加了一个小型直流 UPS 模块，里面电容组足够扛过几百毫秒的电压缺口。处理完之后再查vcgencmd get_throttled，欠压标志位就再也没出现过。这里提醒一句：树莓派 5 的 USB-C 线材电阻也会造成可观的压降，换了电源还不稳，先检查那根线是不是正经的 5A 线。

2.2 散热：温度墙比想象中来得快得多

第二件事是散热。开发台在空调房，25℃，我用一个铝壳被动散热跑 YOLOv5，温度能压在 82℃ 左右，勉强不降频。进了车间完全两样，环境温度先给你加了十度，推理又是满负载的活，四核 A76 全部顶在 2.4GHz 上跑，不到两分钟就撞上 85℃ 的温度墙，主频被一路降下来，推理时间从 80 毫秒变成 140 毫秒以上，检测节拍跟不上产线，开始连续漏检。

散热方案我后来换成了铝合金外壳加一个 5V 涡轮风扇，气流从进风口进来，直接吹过散热片排出去，温度从 85℃ 压到 65℃ 上下。这里有条重要的经验：风扇不要接到 3.3V 引脚上长期转，也不要指望系统默认的 PWM 策略能管好它。我在 config.txt 里配了 gpio-fan 的 dtoverlay，设定温度阈值，比如 50℃ 开启、45℃ 关闭，让风扇按需求转，既安静又不容易进灰堵转。

还有一个细节很容易被忽略：防尘。金属粉尘和纤维絮一旦糊住散热片，风冷效果断崖式下降。我在机箱进风口贴了一层粗滤棉，每周用压空吹一次，一个月拆开清一次。温度记录显示，加了防尘措施之后，风扇转速和 CPU 温度都稳定了很多，不再出现运行几天后性能下降的情况。

2.3 系统：树莓派 5 安装 Ubuntu 的坑

第三件事听上去最简单，装系统。我选的是 Ubuntu 24.04 LTS 而不是官方树莓派系统，原因很实际：团队其他服务器都是 Ubuntu，部署脚本、systemd 服务、网络配置可以直接复用，aarch64 的软件生态也完整。但树莓派 5 装 Ubuntu 的第一个坑，出在启动介质上。

一开始我把 Ubuntu Server 写在 128GB 的 A2 高速 SD 卡里。开发台用着完全正常，到车间就不行了：供电波动那几次，SD 卡上的文件系统连续报错，有一次直接进不了系统。现场没有显示器，排查只能靠串口和猜，反复折腾了两天。后来我确定要换 NVMe SSD，因为树莓派 5 的 PCIe 接口可以接 M.2 硬盘，NVMe 在掉电保护和抗写入方面比 SD 卡强得多，系统从上面启动，稳定性肉眼可见提升。

让树莓派 5 从 NVMe 引导并不是插上就能用，关键一步是更新启动 EEPROM。先用 SD 卡进系统，执行sudo rpi-eeprom-update把 bootloader 升到最新，再用sudo rpi-eeprom-config确认引导顺序里包含了 NVMe。然后我用整盘复制的方式把 SD 卡系统搬到 NVMe，改好 fstab 的 PARTUUID，拔卡重启完成迁移。这个过程中最容易被忽略的，就是没有先更新 EEPROM，结果系统明明写进了 NVMe，树莓派 5 却完全不认，直接开机失败。换完 NVMe 之后建议用lspci -vvv看一眼 PCIe 协商速率，如果跑在低速档位，接口或者排线大概率没装好。

2.4 模型：自训练 YOLOv5 上车后的性能问题

第四件事是最核心的：树莓派 5 上部署自己训练的 YOLOv5 模型。模型是在 GPU 机器上用 YOLOv5s 结构、640 输入训练的，精度在线，但搬到树莓派上一跑性能完全不够。

我先在 Ubuntu 上装了 PyTorch 的 aarch64 CPU 版本，单张 640 的图推理一次要 1.2 秒以上，加载模型还得等十几秒，1 FPS 不到的实时性对产线来说等于摆设。然后换成 ONNX Runtime，把best.pt导出成 ONNX，速度提升到 3 FPS 左右，还是不够。最后用 NCNN 才解决：转成 NCNN 格式再做 INT8 量化。

给一个直观的对比数据：

转换流程本身不复杂：在 PC 上用yolo export model=best.pt format=onnx imgsz=640 opset=12导出 ONNX，再用 ncnn 工具链转成 param 和 bin，然后做算子融合和 INT8 量化。量化后模型体积从 14MB 降到 5MB 上下，推理速度直接翻倍。

但量化不是免费的，坑在精度。第一次量化完，我的模型 mAP 掉了差不多两个点，现场误检率高到不能接受。问题根源是校准集选错了：我用的是训练集里的白底图片，而现场是复杂背景加车间光照。解决办法是用现场实拍的气源图做校准集，换完之后误检率立刻回落。如果你的项目对精度极其敏感，又不想做量化，可以退一步用 FP32 并把输入从 640 降到 416，能换一点速度，但整体性价比远不如 INT8。

另外说一句实战建议：实时推理尽量用 C++。Python 层的数据拷贝在视觉任务里会白白吃掉几十毫秒，别在这上面省钱。我最终的推理程序是 C++ 写的，NCNN 模型加载、推理、后处理全在一个进程里完成，Python 只负责业务逻辑和 PLC 通信。

2.5 相机：触发采集与流水线同步

第五件事是集成里最容易被低估的环节。相机装在流水线上方，树莓派 5 在旁边的机柜里，中间隔了几米，原来的 CSI 软排线长度根本不够。我试过长一点的 CSI 排线，结果车间电磁环境一复杂，图像就开始花屏、撕裂、掉帧，视觉系统的可信度直接崩塌。

后来我把相机换成了 USB 接口的工业相机，线材换成带磁环的线，信号问题基本消失，但新的问题来了：USB 相机的采集时序抖动变大。检测需求是光电传感器检测到工件到位的瞬间，相机抓拍一张清晰图片，然后立刻推理。USB 相机从收到命令到真正出帧，延迟抖动经常有几十甚至几百毫秒，这种不可控的时序和产线节拍是硬冲突，靠 sleep 对齐根本不可靠。

我最后的方案是时间戳对齐。相机用 V4L2 的缓冲队列不停抓帧，每帧记录硬件时间戳放进环形队列；GPIO 上接光电传感器，用 libgpiod 监听下降沿，触发到达时记录一个高精度时间戳；后台程序去环形队列里找离触发时间最近的帧来推理。实测下来，几百毫秒的抖动被完全吸收，每帧都能抓到接近触发时刻的画面，比任何"命令-响应"方式都稳。

接线这里我额外提醒：车间光电传感器输出大多是 24V 电平，树莓派 GPIO 只能承受 3.3V，直接接必烧。我加了一片光耦把 24V 侧和 3.3V 侧完全隔离，触发信号经光耦转成干净电平再进 GPIO。这个细节处理不好，轻则误触发，重则 GPIO 口报废，换一块树莓派 5 事小，产线停机的损失才是大头。

2.6 运维：数据落盘与远程管理的坑

第六件事看似最没有技术含量，实际最折磨人。检测每过一个工件都要记录时间、合格与否、缺陷类别和置信度，一天下来几万到十几万行记录。我最初直接往 SQLite 里写，结果一次现场断电，数据库文件损坏，几天的数据全没了。车间不比办公室，断电、急停、设备维护关机都是家常便饭，数据落盘必须按最恶劣情况设计。

我现在是这么做的：结果写入 NVMe 上的 SQLite，开启 WAL 模式和PRAGMA synchronous=FULL，每 500 次写入做一次 checkpoint；另起一个看门狗脚本，每 10 秒检查一次推理进程的心跳文件，异常就重启服务。这样即使偶尔断电，最多损失最后一次未提交的事务，拿不回当天前前后后的数据完整性还是能保证的。

远程运维方面，树莓派 5 装在机柜里没有显示器，我的做法是固定网段 IP，SSH 密钥登录，日志用 journald 转发到主控服务器，模型更新直接 scp 覆盖再重启服务。systemd 服务的Restart=always一定要设置，并且要实测过进程被异常杀掉后能自动拉起来。我还开启了内核硬件看门狗，在 systemd 配置里加上RuntimeWatchdogSec=14，系统如果假死，会自动硬重启，不用你专门跑一次车间去按电源键。

3. 实操过程与核心环节实现

3.1 Ubuntu 24.04 安装与 NVMe 引导迁移

把这套环境复现出来并不难，我按自己实际操作顺序整理一遍。

先准备树莓派 5（建议 8GB 版本）、M.2 HAT、一块 NVMe SSD、一张 32GB SD 卡当临时启动盘。用 Raspberry Pi Imager 把 Ubuntu Server 24.04 镜像写到 SD 卡，开机进系统后先更新系统包，然后安装 M.2 HAT，插好 NVMe SSD，连接 PCIe FPC 排线。注意排线有正反面，卡扣要按紧，安装不到位系统识别不到硬盘。

接着更新 EEPROM 和引导顺序。执行sudo rpi-eeprom-update -a升级 bootloader，再用sudo rpi-eeprom-config -e把 BOOT_ORDER 调整成 NVMe 优先。这一步必须做，很多人换完 NVMe 起不来就是卡在这里。

系统迁移我用的是整盘复制：sudo dd if=/dev/mmcblk0 of=/dev/nvme0n1 bs=4M status=progress，复制完成后用sudo blkid查看 NVMe 的 PARTUUID，对应修改 fstab。然后关机、拔 SD 卡、重新开机，用nvme list和lspci -vvv确认硬盘识别正常。最后配置 netplan 固定 IP，开启 SSH，关掉 ModemManager 这些用不到的服务，打开 systemd watchdog，系统层面就算稳定了。

3.2 YOLOv5 模型转换与 NCNN 部署

模型转换的完整链路可以这么走。在 PC 上先导出 ONNX 文件：

yolo export model=best.pt format=onnx imgsz=640 opset=12

然后在 PC 上使用 ncnn 转换工具，把 ONNX 转成 NCNN 的 param 和 bin 两个文件，再用ncnnoptimize做算子融合，生成优化后的模型。如果要做 INT8 量化，需要用现场实拍图片生成校准集，执行ncnn2table生成校准表，再执行ncnn2int8得到量化模型。这里量化的校准集一定用车间实际拍摄的画面，不要用训练集图片，否则精度掉得很快。

在树莓派 5 上编译 NCNN 时，我用了一组针对 A76 核心优化的编译参数：

git clone https://github.com/Tencent/ncnn cd ncnn && mkdir build && cd build cmake -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_CXX_FLAGS="-O3 -mcpu=cortex-a76" \ -DNCNN_VULKAN=OFF -DNCNN_BUILD_EXAMPLES=ON .. make -j4

编译完成后，把转换好的模型文件放到树莓派上，用 NCNN 自带的 yolov5 示例程序跑通一次，确认输出和 PC 上一致，再进行业务封装。注意类别数量和自定义类别名要在读取模型时对应上，否则后处理结果全错。

3.3 推理服务的稳定化与性能调优

模型能跑起来之后，还有一个从"能跑"到"跑得稳"的过程。我做了三件比较关键的调优。

第一是 CPU 绑定。四核 A76 上，我把 NCNN 推理线程绑定到 CPU 2 和 3 两个核心上，把采集、GPIO 监听、心跳上报这类系统任务放在 CPU 0 上，避免互相争抢。同时把 CPU 调成 performance 模式，保证推理时主频不会因为省电策略掉下来。

第二是启动预热。模型刚加载完第一次推理会比较慢，因为涉及大量内存分配和算子初始化。我在服务启动流程里加了一轮空跑预热，把首次推理的延迟从启动阶段挪到后台，正式检测的第一个工件就是正常速度。

第三是内存控制。树莓派 5 内存够大不代表可以随意挥霍，我把 swap 调低到 10，控制推理进程常驻内存的上限，并关闭不必要的桌面服务和后台定时任务。部署之后连续观测了两周，推理服务的波动非常小，没有出现内存泄漏导致重启的情况。

4. 现场问题排查与避坑技巧

4.1 问题速查表

把这次踩过的坑整理成一张表，现场遇到同类问题可以直接照着查。

4.2 几条只有实际跑过之后才会明白的经验

上产线之前一定要拷机。我最开始把系统搬到车间空跑了 72 小时，前 24 小时就把供电和散热的问题揪出来了。如果直接接产线，问题爆发的时间点一定是最忙的时候，一边赶产量一边排障才是最难受的。

保留一套冷备份。系统镜像、EEPROM 配置、模型文件、部署脚本、fstab、netplan 配置，打包放在文件服务器上。现场板子坏了不用排查，直接换新板恢复，我实测从拆机到恢复运行半小时不到。

给调试留串口。别只依赖 SSH 和无线网络，车间环境对无线信号很不友好。我在机箱前面板留了一根 USB 转 TTL 串口线，系统彻底起不来的时候，串口是唯一靠谱的调试通道。

不要裸板运行。金属粉尘、潮湿、震动，随便一样都够你头疼。至少给板子喷三防漆，最好用一个正经的工业铝合金外壳。风扇进风口加滤棉，定期清理，这比买再贵的散热器都管用。

配置一定要版本化。现场调试、模型迭代都会改配置，时间一长连自己都会忘了改过哪里。我在板子上建了 git 仓库，每次调整都提交一次，回滚非常方便。更关键的是，我在每张推理结果里都带上了模型版本号和当前阈值参数，这样排查历史误检时，永远能查出来是哪一版模型、哪一组参数做出的判断。

最后再说一点个人的体会。这次项目里树莓派 5 的硬件本身反而很争气，没出过岔子，真正考验人的是把消费级设备按工业级标准来用。供电、散热、隔离、运维，每一步都是在给这台小电脑补一层"工业外衣"。我那套设备现在已经在产线上稳定跑了两周多，每天两班倒，推理服务零重启。如果让我总结一条最值得分享的技巧，那就是：现场调试时把vcgencmd get_throttled的输出直接写进日志，每次巡检扫一眼，欠压和热降频的历史一目了然。这个习惯帮我提前发现过两次电源接触不良，每次都省下了大半天排查时间。