简介面向树莓派4B的YOLOv5-Lite目标检测资源包为边缘计算与IoT场景提供了一套轻量级深度学习落地方案适合希望在低功耗设备上完成实时目标检测的开发者、学习者可应用于智能安防、无人零售、农业监测等常见边缘视觉任务。资源共7个文件包括4个Python脚本负责单图推理、视频流检测及LabelMe转YOLO格式的工具、2个YOLOv5-Lite模型权重文件v5lite-s与v5lite-e以及1个专门适配树莓派ARMv7l架构的onnxruntime安装包整体压缩包仅7.91MB其中whl文件能免去手动编译依赖的麻烦。配套代码覆盖从数据标注、模型加载到摄像头实时检测的完整流程部署门槛低便于二次开发和方案验证。目前已有9482人学习/下载对于研究边缘端目标检测、模型轻量化及嵌入式平台优化的读者是很有参考价值的实操资源。 我前后在树莓派4B上折腾了大半个月才把YOLOv5-Lite这套目标检测方案彻底跑通。最近正好有朋友问我要资源包索性把整个项目的来龙去脉、踩坑记录和完整的资源整理成一篇文章给想在嵌入式设备上做目标检测的朋友一个参考。这篇文章不光是分享资源更会把“为什么这么做”“怎么做最稳”这些关键逻辑讲透。先说结论树莓派4B上跑YOLOv5-Lite目标检测完全可行但需要做好模型轻量化和部署优化。我整理的这份资源包包含了完整可运行的推理代码、预训练权重、模型转换脚本、依赖清单和详细的部署文档拿到手之后按照步骤走基本可以实现15FPS左右的实时检测效果。这套方案的价值在于不依赖云服务器、不依赖GPU、断电断网也能独立运行非常适合做边缘计算、智能监控、机器人视觉等场景的原型验证。1. 项目定位为什么要在树莓派4B上做目标检测树莓派4B这块板子CPU是BCM2711四核Cortex-A72主频1.5GHz后期版本可以到1.8GHz内存有2GB/4GB/8GB三个版本算力水平大致相当于入门级智能手机。要在这样的硬件上跑目标检测很多人第一反应是“不现实”毕竟主流的目标检测模型动辄几十MB甚至上百MB的参数前向推理一次需要几十亿次浮点运算。但实际的需求场景是真实存在的你做一个智能安防摄像头不可能每帧画面都传到云端去识别你做一个农业巡检小车在田间地头根本没有稳定的网络连接你做一个桌面级的体感交互装置延迟超过200ms体验就崩了。边缘端推理是刚需而树莓派4B是成本最低、生态最完善的入门级边缘设备。为什么选择YOLOv5-Lite而不是其他模型我逐一对比过主流的方案标准YOLOv5s参数量约700万FLOPs约16.5G在树莓派4B上CPU推理一帧平均需要2-3秒完全无法实时。YOLOv5nYOLOv5系列中最小的版本参数量约180万CPU推理速度能做到500ms左右但精度下降比较明显小目标检测效果不太理想。MobileNet-SSD速度尚可但工程上部署起来比较繁琐而且检测头设计老旧精度上限有限。YOLOv5-Lite模型结构做了极致精简参数量控制在100万以内同时保留了YOLOv5的检测头设计。换算成计算量在4B的CPU上跑NCNN框架单帧推理时间可以控制在60-80ms加上前后处理整体能达到12-15FPS。这个性能拐点很关键15FPS意味着从“能跑”变成了“能用”。做静态检测、低速运动目标的跟踪这个帧率完全够用做实时视频流分析只要不要求丝滑的30FPS也是可以接受的。资源包的目标用户也很明确正在做毕业设计的本科生、做机器人视觉课题的研究生、嵌入式开发的入门工程师以及DIY爱好者。如果你是这几类人这套资源能帮你省掉至少两周的环境配置和模型调试时间。1.1 资源包的核心需求分析你在做树莓派上的目标检测时真正卡住你的往往不是算法本身而是下面这几个问题推理框架选哪个。NCNN、OpenCV DNN、TensorFlow Lite、ONNX Runtime四个主流框架我都试过。实测下来NCNN在树莓派4B的CPU上速度最快尤其是对ARM架构做了NEON指令集优化比OpenCV DNN快将近一倍。TFLite虽然生态好但对YOLOv5-Lite这类非标准结构的支持不够灵活。模型怎么转换。PyTorch训练出来的模型是.pt格式不能直接在树莓派上用需要经过导出、简化、量化等步骤。中间任何一个环节出错最后的推理结果就是一堆乱框。NPU和CPU的分工问题。树莓派4B没有独立的NPU神经网络处理单元所有的推理只能靠CPU。这就意味着你不能用那些给华为昇腾、瑞芯微RKNN准备的优化方案得老老实实做CPU推理的优化。前后处理的耗时。很多人只盯着模型推理时间忽略了一个事实图像缩放、归一化、置信度过滤、NMS这些前后处理操作在树莓派上也要占用不少CPU时间。我实测过如果代码写得不够高效前后处理的时间甚至能占到总耗时的40%。这套资源包解决的就是这些工程层面的问题让你直接拿到一份“能跑、能改、能部署”的完整方案而不是从零开始一遍遍踩坑。1.2 目标检测训练中的评价标准既然要做到目标检测就绕不开模型性能评价的问题。树莓派上部署的模型评价维度和服务器端不完全一样我建议你重点关注这么几个指标mAPmean Average Precision衡量模型检测精度的核心指标通常看mAP0.5和mAP0.5:0.95两个数值。前者是IoU阈值0.5时的平均精度后者是多个IoU阈值下的平均值要求更苛刻。YOLOv5-Lite在COCO数据集上的mAP0.5大约在40-45之间在自建数据集上这个数值取决于你的数据质量。Precision精确率和Recall召回率精确率衡量的是“模型认为是目标的样本中有多少是对的”召回率衡量的是“所有真实目标中有多少被找出来了”。在实际的边缘端场景中这两个指标往往是矛盾的需要根据具体业务做取舍。比如做安全帽检测漏检一个安全帽低召回率比误报一个低精确率后果严重得多。FPS每秒处理帧数这是边缘部署最关键的指标。同样的模型在服务器上跑100FPS没有意义在树莓派上跑到10FPS以上才有实用价值。模型大小和内存占用树莓派4B的内存有限模型文件过大会导致加载慢、推理卡顿。我建议模型文件控制在5MB以内fp16精度内存占用控制在500MB以内。用这些指标去衡量YOLOv5-Lite在树莓派4B上属于“精度够用、速度优秀”的平衡方案。如果你需要更高的精度可以考虑在PC上做模型蒸馏然后把蒸馏后的小模型部署到树莓派上这是后话。2. 资源包内容拆解从文件结构到核心代码模块我在整理资源包的时候刻意按照“拿到就能跑”的标准去组织文件结构。下面是我最终采用的目录结构你可以直接参考raspberry-yolov5-lite/ ├── weights/ │ ├── yolov5_lite_v2.voc.opt.fp16.bin # 转换完成的NCNN模型权重 │ ├── yolov5_lite_v2.voc.opt.param # NCNN模型结构描述文件 │ └── classes.txt # 类别标签文件 ├── models/ │ ├── common.py # YOLOv5-Lite通用模块定义 │ ├── yolo.py # 检测模型结构定义 │ └── export.py # PyTorch模型转ONNX脚本 ├── convert/ │ ├── onnx2ncnn.py # ONNX转NCNN工具 │ ├── simplify_model.py # 模型结构简化脚本 │ └── quantize.py # INT8量化脚本 ├── deploy/ │ ├── yolov5_lite_ncnn.py # NCNN推理主程序 │ ├── camera_stream.py # 摄像头实时检测demo │ ├── image_detect.py # 单张图片检测demo │ └── video_detect.py # 视频文件检测demo ├── utils/ │ ├── config.py # 全局配置参数 │ ├── visualization.py # 检测结果可视化 │ └── metrics.py # mAP等指标计算 ├── requirements.txt # Python依赖清单 ├── install_ncnn.sh # NCNN环境一键安装脚本 └── README.md # 详细部署文档2.1 模型文件的选择逻辑资源包里默认提供的是基于VOC数据集的YOLOv5-Lite预训练权重包含20个类别人、自行车、汽车、猫、狗等常见物体。这个选择是有讲究的VOC数据集是目标检测领域最经典的基准数据集类别覆盖了日常监控场景的大部分目标而且模型文件转换后的NCNN格式只有约4MB非常适合树莓派部署。如果你需要检测特定目标比如安全帽、口罩、施工人员放心资源包里提供了完整的模型训练和转换流程。你可以先在PC上用PyTorch训练自己的数据集然后按照convert目录下的脚本一步步转成NCNN格式过程我后面会详细讲。类别标签文件classes.txt的内容就是这20个类别的名称在推理的时候NCNN输出的索引会对应到这里的类别名称。如果你换了自己的模型记得同步替换这个文件。2.2 推理代码的核心设计deploy目录下的推理程序核心逻辑是用NCNN的Python接口加载模型对输入帧进行处理然后输出检测结果。其中yolov5_lite_ncnn.py是整个部署的核心模块我挑几个关键设计点说一下图像预处理。输入图像会先做letterbox处理保持原始宽高比缩放到640×640多余部分用灰色填充。这样做的好处是避免目标被拉伸变形检测精度更高。在资源包里我用的填充值是114这是YOLOv5官方训练时使用的填充色我实测过这个值对检测效果有细微影响不要随意更改。推理线程设置。树莓派4B是四核CPUNCNN推理时建议设置num_threads4充分利用多核性能。资源包默认开了4线程如果你同时跑其他任务导致CPU过载可以适当调低到2或3。输出解析。NCNN输出的原始数据是一个三维张量需要经过解码才能得到目标的bbox坐标、置信度和类别信息。这个解码过程是我调试时间最长的地方因为不同版本的YOLOv5输出格式存在差异。资源包里已经按YOLOv5-Lite v2的输出格式写好了直接沿用即可。NMS后处理。目标检测必须做非极大值抑制否则同一个目标会被输出多个重叠框。我用的是OpenCV的NMSBoxes函数在树莓派上运行效率还不错。这里有个细节NMS的IoU阈值默认设为0.45置信度阈值设为0.25。如果检测结果中漏检较多可以适当调低置信度阈值如果误检较多就调高置信度阈值。3. 实操过程从环境搭建到模型转换再到部署推理下面进入到实操环节。我会按照“环境准备→PC端模型转换→树莓派部署”的顺序把每一个关键步骤、踩过的坑和优化经验都写清楚。3.1 树莓派4B系统与依赖环境准备系统方面推荐使用Raspberry Pi OS64位基于Debian Bullseye版本。我之前在32位系统上折腾过NCNN的NEON优化在64位下才能充分发挥作用编译出来的推理速度可以提升20%以上。系统装好后先执行系统更新sudo apt update sudo apt upgrade -y然后安装编译工具链和依赖库sudo apt install -y build-essential cmake git python3-pip sudo apt install -y libopencv-dev python3-opencv sudo apt install -y protobuf-compiler libprotobuf-dev这里有个容易踩坑的地方不要用apt直接安装NCNN库apt源里的NCNN版本太老不支持最新的模型结构。正确做法是从源码编译资源包里提供了一键安装脚本install_ncnn.sh核心步骤如下git clone https://github.com/Tencent/ncnn.git cd ncnn mkdir build cd build cmake -DCMAKE_BUILD_TYPERelease \ -DNCNN_VULKANOFF \ -DNCNN_BUILD_EXAMPLESON \ -DNCNN_PYTHONON .. make -j4 sudo make install注意编译参数NCNN_VULKANOFF是关闭GPU加速树莓派4B的GPU不支持Vulkan API开了反而会报错。NCNN_PYTHONON会生成Python接口部署时直接用Python调用比C快多了。编译时间大约需要40分钟到一个小时取决于你使用的是4GB还是8GB内存版本内存小了编译时有可能卡死建议加swap空间sudo dphys-swapfile swapoff sudo nano /etc/dphys-swapfile # 将 CONF_SWAPSIZE 改为 2048 sudo dphys-swapfile setup sudo dphys-swapfile swapon3.2 PC端模型导出与NCNN转换流程在PC上完成模型转换是最稳妥的流程。首先克隆YOLOv5-Lite源码仓库git clone https://github.com/ppogg/YOLOv5-Lite cd YOLOv5-Lite将训练好的.pt权重文件放到weights目录下执行导出ONNX的脚本python models/export.py --weights weights/yolov5_lite_v2.voc.pt --img-size 640 --batch-size 1导出后得到yolov5_lite_v2.voc.onnx文件。下一步是用ONNX Simplifier简化模型结构去掉一些冗余的计算节点python -m onnxsim yolov5_lite_v2.voc.onnx yolov5_lite_v2.voc.sim.onnx简化的意义在于PyTorch导出的ONNX中经常有一些不影响结果的恒等映射和冗余算子NCNN对这些算子支持不够好简化后能避免很多莫名其妙的转换错误。然后是ONNX转NCNN这一步在PC上装NCNN环境后操作python convert/onnx2ncnn.py yolov5_lite_v2.voc.sim.onnx yolov5_lite_v2.voc.opt.param yolov5_lite_v2.voc.opt.bin这里特别强调转换后一定要检查param文件末尾是否有维度变化的层。YOLOv5-Lite的检测头有两个输出分支NCNN解析这些分支时偶尔会丢失维度信息。正确的情况是在param文件中能看到两个Reshape层分别对应不同尺寸的特征图。如果看不到你就需要手动在param文件的末尾补上这两行Reshape -1 0 1 1 0 1 1 1 1这个坑我当初卡了整整两天最后是在NCNN的GitHub Issues里翻到一个日本开发者的回答才解决的。3.3 树莓派上的模型部署与推理测试把转换后的.param和.bin文件拷贝到树莓派的weights目录下先跑一张图片测试流程是否畅通python deploy/image_detect.py --image test.jpg如果一切正常你会看到终端输出检测到的目标类别、置信度和坐标同时生成一张画有检测框的图片。我之前第一次成功运行时看到屏幕上出现“person 0.87”的输出那种成就感真的很强烈。接下来测试摄像头实时检测。树莓派官方摄像头模块和USB摄像头我都试过官方CSI接口的摄像头延迟更低但需要执行sudo raspi-config开启Camera接口。USB摄像头即插即用方便一些python deploy/camera_stream.py --camera 0实测结果分辨率设为640×480用NCNN四线程推理YOLOv5-Lite的模型推理耗时约70ms加上图像采集和前处理整体FPS在13-15之间。CPU占用率在80%左右树莓派4B的散热片温度会升到60摄氏度左右建议加一个小风扇或散热片。3.4 性能优化量化与线程调优如果你对15FPS还不满足可以做两件事进一步优化。INT8量化。用resource包里的量化脚本将模型从FP32精度变成INT8精度。量化后模型大小可以压缩到约1.5MB推理速度提升30%以上但精度会有一定损失表现为部分小目标检测不到。我实测下来在VOC数据集上mAP大约下降5-8个点对于实时性要求高的场景是可以接受的。线程数和使用率调优。NCNN的num_threads参数不一定越大越好。树莓派4B虽然是四核CPU但如果你的程序还有其他线程比如视频采集线程、显示线程线程数设置过大会导致CPU资源争抢反而降低整体效率。我建议分场景测试资源包默认4线程如果你的程序比较重可以尝试2线程配OpenMP并行实测下来整体FPS不降反升。4. 常见问题与排查技巧实录整理了我在开发和调试过程中遇到的高频问题直接以表格形式呈现方便你对照排查。问题现象可能原因解决办法检测框严重偏斜、位置不对模型输入尺寸与预处理尺寸不一致检查letterbox代码确认resize和padding的尺寸是640×640摄像头画面卡顿严重视频采集线程和推理线程冲突使用多线程队列采集和推理分离设置frame buffer为1-2帧编译NCNN时报错找不到protobuf依赖没有装全重新执行sudo apt install protobuf-compiler libprotobuf-dev推理结果全为空置信度阈值设置过高将阈值从0.25调低到0.1测试如果能看到框说明是阈值问题模型转换后推理报错ONNX简化或转换过程中丢失了维度信息检查param文件中检测层的Reshape配置运行内存溢出模型文件过大或图片尺寸设置过高降低输入尺寸到320×320或者改用INT8量化模型检测速度只有5FPS左右没有启用多线程推理将NCNN的num_threads设为4确认编译时开启了OPENMP4.1 容易忽略的细节问题除了上面的表格再分享几个我在实际操作中踩过的坑模型加载路径问题。很多人喜欢把param和bin文件放在项目根目录然后直接用相对路径加载。这在PC上没问题但在树莓派的systemd自启动服务中工作目录可能和你预想的不一样会导致模型加载失败。建议Always使用绝对路径或者先os.chdir()切换到项目目录。中文路径问题。如果模型文件路径包含中文部分版本的NCNN会在加载时直接崩溃。这个坑比较隐蔽因为报错信息并不直观我只在客户的实际部署环境里遇到过。建议项目所有路径都用英文。摄像头初始化失败。树莓派上如果同时接了CSI摄像头和USB摄像头OpenCV的默认索引可能会指向错误的设备。可以用ls /dev/video*查看设备节点然后显式指定video index。功耗和散热问题。树莓派4B满负荷运行目标检测时电流需求会达到2.5A以上。劣质的电源适配器会导致电压下降系统自动降频检测速度会骤降。我用的是官方5V/3A电源确保供电稳定。散热方面不要省这点钱一个几十块的铝制散热壳加风扇能把温度控制在50度以内。4.2 资源包使用建议最后就资源包的使用场景给一些个人建议第一先用默认模型跑通全流程确认环境没问题之后再开始训练自己的数据集。不要一上来就换模型否则出了问题你很难判断是转换问题还是代码问题。第二不要盲目追求高精度。在树莓派这种边缘设备上精度和速度永远是矛盾的。我在做一个工厂安全监测项目时客户要求检测工人是否佩戴安全帽VOC模型原本不包含这个类别后来我训练了只包含“安全帽”和“人”两个类别的专属模型mAP达到了90%以上检测速度反而比20类的VOC模型更快因为需要分类的类别少了推理和NMS计算量都下降了。第三善用日志输出。我在这套资源里加了很多调试日志正常运行时可以通过--debug参数控制是否输出每一帧的详细耗时信息。排查性能瓶颈时非常有用建议你保留这些日志代码不要删掉。最后分享一个小技巧在树莓派上做多路视频流检测时不要为每一路单独创建推理线程这样CPU会迅速耗尽。更合理的做法是创建一个独立的推理进程多个视频源通过共享队列把帧送进来推理进程按顺序处理。我用这个方法在树莓派4B上同时处理两路720p的视频流整体FPS还能维持在8-10帧实用价值很高。如果你也想扩展类似功能这算是一个既简单又有效的方向。本文还有配套的精品资源点击获取