做工业视觉的同行应该都有同感YOLOv5 加海康工业相机这几年几乎成了产线定位、缺陷检测、分类分拣的默认组合。尤其是当你拿到一台 500 万甚至 1200 万像素的海康工业相机又希望跑实时检测的时候事情就没那么简单了——直接拿整张高分辨率图塞进 YOLOv5显存爆炸、帧率掉到难以接受根本谈不上“实时”。我最早做这个项目的时候也以为无非是装个 YOLOv5、接上相机、跑 detect.py 就完事结果被取流、触发、切图、推理加速这些环节反复上了一课。这篇文章就是把那段时间踩过的坑和最终落地的方案完整记录下来。内容围绕 YOLOv5 与海康工业相机的高分辨率实时检测展开会讲到环境怎么搭、海康 SDK 取流时最常见的“未收到触发信号”问题怎么排、自己的数据集怎么从标注到训练以及高分辨率图怎么通过切片、TensorRT 加速等工程手段保住实时性。适合刚入行做机器视觉、正在折腾工业相机和 YOLOv5 的工程师也适合想把现有检测算法从实验室搬到产线的朋友参考。1. 项目整体设计与选型思路1.1 为什么是 YOLOv5 而不是其他检测框架我知道很多人会问现在都 YOLOv8、YOLO11 了为什么还抱着 YOLOv5 不放我的回答很简单工业项目要的不是最新而是最不容易出问题的那一套。YOLOv5 的生态太成熟了。从官网下载源码到训练自己的数据集网上随便一搜就是大量中文资料遇到问题基本都能找到答案。它支持 PyTorch 训练也能导出 ONNX、TensorRT 引擎部署灵活性很高。更重要的是YOLOv5 的权重文件、模型结构、超参数配置在工业场景里被验证过太多次稳定性比很多新框架好。用 YOLOv8 当然也可以但如果你是从零开始做产线项目我建议先选 v5s 或 v5m 跑通一套流程后面想换再换。还有一个容易被忽略的原因YOLOv5 对高分辨率输入、切片推理这类场景的支持非常友好。它的后处理逻辑可以灵活改造尤其是把大图切块后各自推理再把结果合并做 NMSv5 的检测头输出格式很容易操作。换成一些新的 DETR 类模型实时性反而不如 v5 稳部署成本也高。所以选型这件事不要被“新模型精度更高”带偏要先看你的算力、相机、节拍要求能不能接受。1.2 为什么是海康工业相机以及高分辨率带来的现实约束海康工业相机在这个方案里几乎是绕不开的选择。它的 MVS 软件和 SDK 做得很完整支持 GigE Vision、USB3 Vision 接口能通过 C、C#、Python 调用。相比进口品牌海康的相机性价比高技术支持和案例也丰富产线上用得很普遍。但“高分辨率”三个字对实时检测是实实在在的压力。工业相机的分辨率从 500 万到 1200 万甚至更高而 YOLOv5 默认的训练分辨率只有 640x640。你想想一张 500 万像素的图大概是 2448x2048如果直接缩放到 640x640等于把画面里大量细节扔掉。检测大件物体没问题但如果是细小的划痕、小零件、车牌上的小字符直接就漏检了。可如果不缩放把 2448x2048 整张图喂给 YOLOv5s推理延迟会非常高显存占用也大普通显卡很难跑实时。还有个约束来自相机接口带宽。GigE 千兆网口理论带宽约 125MB/s500 万像素 8bit 灰度图一帧接近 5MB拍 10 帧每秒就要 50MB/s勉强能撑住。但如果是彩色图一帧 15MB 左右10 帧就 150MB/s千兆网口已经超了。USB3.0 的理论带宽约 350MB/s会好很多。所以选相机之前先算清楚你需要的分辨率和帧率再决定接口类型否则后面取流会很痛苦。1.3 系统整体流程与分工我在这个项目里的实际分工是这样的海康工业相机通过 MVS SDK 采集图像采集线程拿到一帧高分辨率图后放进队列处理线程从队列里取图先做预处理包括切块、缩放、归一化然后送进 YOLOv5 模型做推理得到目标框和类别最后对多个切块的检测结果做坐标换算和 NMS 合并输出到上层业务或者 PLC。采集和推理一定要分离线程否则相机帧率稍微一高取流就会阻塞丢帧严重。整个系统看起来不复杂但每个环节都有讲究。下面我就按环境准备、数据训练、推理加速、问题排查这几块把能直接复用的细节写出来。2. 环境准备与 SDK 接入2.1 开发环境怎么搭最省心先说训练和推理的机器。我通常用一台带 NVIDIA 显卡的 Ubuntu 工作站显卡至少 8GB 显存推荐 12GB 以上。YOLOv5 依赖 PyTorch所以先装好 CUDA 和 cuDNN。这一步偷懒不得建议直接用 Anaconda 创建虚拟环境避免系统 Python 环境被搞乱。我习惯的做法是conda create -n yolov5 python3.8 conda activate yolov5 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 git clone https://github.com/ultralytics/yolov5 cd yolov5 pip install -r requirements.txt这里要注意PyTorch 版本不要随便装最新。YOLOv5 的代码对 PyTorch 版本有一定兼容范围装太新的版本反而可能遇到算子兼容问题。我自己用 PyTorch 1.10 到 2.x 都跑过如果只是训练和推理选 1.13 或 2.0 都可以。装完依赖后先用官方权重跑一次推理验证环境python detect.py --weights yolov5s.pt --source data/images/bus.jpg能正常出框说明环境没问题。如果是在 Jetson Nano 上部署那又是另一套玩法。Jetson 需要先刷 JetPack再安装对应版本的 PyTorch 和 torchvision不能直接 pip install否则会装到 CPU 版本。这个坑我踩过后来老老实实从 NVIDIA 官方论坛下载预编译的 wheel 才解决。Jetson Nano 上跑 YOLOv5s 大概能到 5-10 FPS配合 TensorRT 可以再快些但高分辨率实时检测还是需要切图和合理控制输入尺寸。2.2 海康相机 SDK 接入要点未收到触发信号排查海康工业相机的接入首先要安装 MVS 客户端也就是机器视觉软件。装完后在安装目录下的 Development 文件夹里能找到 SDK 文档和示例。Python 调用时我用的模块是MvCameraControl_classGigE 相机基本都支持这个接口。SDK 取流有两种方式主动拉流和回调取流。主动拉流是循环调用MV_CC_GetOneFrameTimeout拿图简单直接但高分辨率场景下容易因为处理慢导致缓冲区积压。回调取流是 SDK 在有新帧时自动调用你的回调函数效率更高推荐在实时检测场景用。热词里有个“海康工业相机未收到触发信号”这个问题我印象太深了几乎每个用海康相机做硬触发的人都会遇到。我第一次调试时曝光参数设好了TriggerSource 也设成了 Line0但相机就是不触发报“未收到触发信号”。后来排查发现是这几个原因第一触发模式没开。相机默认是连续采集模式你需要先通过MV_CC_SetEnumValue(TriggerMode, 1)把触发模式设置为 ON也就是等待外部信号。第二触发源没选对。海康相机支持软触发和硬触发硬触发要设置MV_CC_SetEnumValue(TriggerSource, 0)表示 Line0或者根据接线选择对应的 Line。第三如果你用软触发除了设置触发源为 Software还要在每帧采集前调用MV_CC_SetCommandValue(TriggerSoftware, 1)发送软触发命令很多新手会漏掉这一步。硬触发还有一个隐蔽问题信号线接对了、参数也设置了依然收不到触发这时候要检查触发信号的电气参数。比如相机需要 5V 差分信号你给的是 24V 或者接地不对肯定触发不了。另外曝光时间太短也会导致相机来不及完成曝光表面上看就是“没有触发”。所以排查顺序一定是先确认触发模式再确认触发源然后用示波器或者万用表量信号最后查曝光和触发延时。2.3 高分辨率图像流的读取优化海康相机在高分辨率下带宽压力很大。比如 500 万像素彩色图一帧约 15MB如果你用主动拉流方式在 Python 里逐帧拷贝很容易超过带宽限制导致丢帧。我的做法是使用回调取流并在回调函数里只做浅拷贝或者把图像数据直接放入队列不进行任何图像处理。图像处理放在另一个线程里。如果你用的是 USB3 接口还要注意 USB 控制器带宽。一台电脑上插多个工业相机的时候最好分别接在不同 USB 控制器的接口上否则带宽会被共享帧率上不去。GigE 相机则需要开启巨帧也就是 Jumbo Frame并把相机和网卡之间的 MTU 调到 9000否则千兆带宽发挥不出来。另一个优化点是像素格式。如果项目不需要彩色信息尽量让相机输出 8bit 灰度图比如 Mono8带宽直接降到彩色图的三分之一。如果需要彩色优先选 RGB8 而不是 Bayer 格式虽然 Bayer 数据量小但还要做 ISP 插值转换反而增加 CPU 负担。我习惯先把相机输出转换成适合模型输入的 RGB 或 BGR 格式再进队列。3. 数据与训练自己的数据集怎么搞3.1 图像采集、标注和自动标注YOLOv5 训练自己的数据集第一步永远是数据。数据集的质量直接决定模型上限我见过太多人训练集就几百张图结果模型在产线上根本没法用。工业场景里最好在你实际要部署的光照、角度、背景下多采集。比如做水果识别就拍不同成熟度、不同遮挡程度的果做车牌识别就尽量覆盖省份简称、颜色、车牌倾斜角度。标注工作确实枯燥。我早期用 LabelImg 手工拉框一晚上标几百张就头晕。后来发现可以用界面操作 YOLOv5 完成数据集的自动标注效率提升非常多。具体做法是先用少量手工标注的数据训练一个粗糙版本的 YOLOv5 模型然后用这个模型去预测未标注的新图生成 YOLO 格式的 txt 标注文件。接着把预测结果导入 CVAT 这类标注工具人工检查和修正。CVAT 本身支持自动标注可以导入模型做预标注人只需要拖动错框和确认漏检。这里有个技巧自动标注的模型不需要精度特别高能框出八成目标就行目的是省去从零拉框的时间。然后用标注工具快速修正。另外每轮修正后的数据再重新训练模型再去预标注下一批新图数据积累和模型精度的提升可以形成正循环。我第一次用这个方式把人工标注时间从三个晚上压缩到一天。标注格式要注意一个坑YOLO 的标签是归一化的类别从 0 开始。比如一张 1920x1080 的图目标中心坐标 (960, 540)宽 400高 300那么 txt 里写的是0 0.5 0.5 0.2083 0.2778而不能直接写像素坐标。很多标注软件可以自动帮你转换但如果你自己写脚本生成标注一定要反复核对这个归一化。3.2 数据集目录结构和 YAML 配置训练前把数据集整理成 YOLOv5 要求的目录格式通常是这样dataset/ images/ train/ val/ labels/ train/ val/ data.yamltrain 和 val 的图片一一对应放在 images 和 labels 下文件名保持一致后缀不同。data.yaml 的内容也很简单比如做水果识别train: /path/to/dataset/images/train val: /path/to/dataset/images/val nc: 2 names: [apple, orange]这里nc是类别数量names是类别名称列表。名称顺序必须和标注文件里的类别编号一致。如果顺序错了模型训练出来框和标签就对不上这个错误很隐蔽我因为类别顺序搞反过测试阶段才发现。3.3 超参数怎么调YOLOv5 的超参数配置文件在data/hyps/hyp.scratch-low.yaml和hyp.scratch-high.yaml。新手直接用默认配置也能出不错的结果但我还是建议理解几个关键参数。首先是imgsz。如果你做高分辨率检测训练时将输入尺寸设成 640 还是 1280会影响小目标检测能力。我的建议是如果显卡允许优先用 1280 训练或者在推理时用高分辨率切片推理。如果用 640 训练推理时直接输入 1280模型也能跑但精度提升有限最好是训练和推理尺寸一致。batch越大训练越稳定。显存有限时不要硬撑大 batchYOLOv5 支持自动批大小也就是--batch -1它会根据显存自动选择一个合适的值。epochs我一般先设 100 到 200配合早停机制当验证集 mAP 连续多轮不提升时自动停止避免过拟合。lr0初始学习率默认 0.01这个值对大部分情况都适用。如果你发现 loss 震荡厉害可以降到 0.005。数据量很少时迁移学习比从头训练有效得多一定要用预训练权重比如--weights yolov5s.pt。数据量只有几百张图的时候别去改太多网络结构老老实实微调。超参数里还有个容易忽略的mosaic数据增强它在训练时把四张图拼在一起可以极大丰富小目标的训练样本。默认是开启的通常不需要关。如果你的目标特别小可以把mosaic设为 1.0同时把mixup调低些避免图像混合后目标太模糊。3.4 训练监控、测试和导出训练过程我会重点看两个东西一个是终端输出的 mAP 和 Precision/Recall 指标另一个是训练生成的results.png里面有 loss 变化曲线和各类指标。如果训练 loss 在下降但验证 loss 先降后升那就是过拟合了可以增加数据、增强正则或者提前停止。训练完成后用val.py评估python val.py --weights runs/train/exp/weights/best.pt --data data.yaml重点看各类别的 mAP0.5 和 mAP0.5:0.95。工业场景里我一般更关注小目标的召回率因为漏检比误检要命。验证没问题后导出模型。推理部署建议导出为 ONNX 或者 TensorRT 引擎python export.py --weights runs/train/exp/weights/best.pt --include onnx --opset 11如果要在 Jetson Nano 上部署可以再加--include engine导出 TensorRT 引擎。导出后一定要用同一张测试图对比 PyTorch 模型和导出模型的结果防止精度掉太多。4. 高分辨率实时推理的工程化改造4.1 直接整图推理为什么不行刚起步时我最想省事直接用相机的原始分辨率整图输入 YOLOv5比如 2448x2048。结果在 RTX 3060 上YOLOv5s 推理一帧花了 200 多毫秒帧率不到 5 FPS显存占用还接近 6GB。如果换成 1200 万像素的图干脆直接显存不足。这还不是最要命的检测小目标的精度反而可能变差因为模型会把大图压缩成 640 的特征图细小目标在特征图里可能只剩一两个像素。所以高分辨率实时检测一定要做切片。思路很简单把大图切成若干块分别送进 YOLOv5再把结果合并。这样每一块的有效分辨率没有损失太多小目标依然有足够的像素特征。类似 SAHI 这样的库就是做这件事的很多场景下能直接把小目标检测的 mAP 提高 10 个百分点以上。4.2 切片、重叠与 NMS 合并切片不是简单均分就完事必须设置重叠区域。我常用的策略是把 2448x2048 的图切成 4 块 1280x1280重叠 100 到 200 像素。有了重叠横跨切图线的目标就不容易漏检因为在相邻两块里都能看到目标的大部分。但如果重叠太多推理次数增加实时性变差所以要平衡。目标越大、越稀疏重叠可以小一点目标越小、越密集重叠要适当加大。切块推理完之后每个目标框的坐标是相对于各自切块的。合并回原图时要加上切块在原图中的偏移量。这步如果自己写容易出 bug我建议用 SAHI 的预测逻辑或者自己封装一个函数处理。合并之后同一目标可能被多个切块重复检测出来框位置相近需要用 NMS 去重。NMS 的 IoU 阈值一般设 0.5项目要求严格时也可以到 0.6看实际效果。我实测过一组数据用 2448x2048 的原图做整图缩放推理小目标召回率只有 72%切成 4 块重叠 10% 推理小目标召回率提升到 91%单帧总延迟从 200ms 增加到 260ms但配合多线程和 TensorRT 加速后整体仍然能达到 20 FPS 以上。切图带来的精度收益明显大过延迟成本。4.3 推理加速TensorRT 与多线程流水线切片方案会让推理次数变多所以必须对 YOLOv5 做加速。首选方案是导出 TensorRT FP16 引擎。TensorRT 会把网络结构优化并利用半精度浮点速度比 PyTorch 快一倍以上。在 RTX 3060 上YOLOv5s 输入 1280x1280 的 TensorRT FP16 推理延迟大约 15ms 到 20ms输入 640x640 可以压到 3ms 到 5ms。用trtexec生成引擎也很快命令大致是trtexec --onnxyolov5s.onnx --saveEngineyolov5s.engine --fp16生成后可以在自己的推理代码里加载 engine。这里有个细节TensorRT 默认可能使用固定输入尺寸如果你需要动态调整输入尺寸要用--minShapes、--optShapes、--maxShapes设置动态维度。不过工业项目里我一般就直接固定输入尺寸比如 1280简单稳定。另一个加速手段是批量推理。一次把 4 个切块拼成一个 batch输出 4 组结果。GPU 对 batch 的利用率更高总延迟反而比逐个推理低很多。但要注意 batch 后的显存占用切块尺寸越大batch 要适当减小。我通常配置 batch4 来做四块切片推理单帧总延迟和 batch1 相比能降低三成以上。采集、预处理、推理、后处理之间应该用队列和线程池串成流水线。相机采集线程负责拿图预处理线程负责切图和归一化推理线程只做模型前向计算后处理线程做坐标变换和 NMS。这样即使单帧推理延迟高一点只要流水线不间断吞吐量依然可以接近最慢环节的帧率。实际项目里相机 30 FPS 取流流水线跑满 20 到 25 FPS 是很常见的事。4.4 实时性评估与性能计算评估实时性不能只看模型推理毫秒数要统计端到端延迟。我习惯把每个阶段的时间都打印出来用队列深度监控是否有积压。如果采集队列越来越深说明后处理跟不上如果后处理队列空了说明相机帧率不足或者预处理太慢。端到端帧率的公式大概是FPS 1 / (采集等待时间 预处理时间 推理时间 后处理时间)但由于流水线并行实际吞吐量可以比这个高。我通常还会在代码里记录最近 100 帧的平均延迟输出到日志。如果平均延迟超过相机帧周期的 80%就要考虑优化。比如相机 30 FPS帧周期约 33ms端到端延迟最好控制在 26ms 以内否则就会有丢帧风险。5. 场景迁移与问题排查5.1 水果识别与车牌识别的落地差异YOLOv5 训练自己的数据集最常见的两种场景就是水果识别和车牌识别。两者对高分辨率检测的要求完全不同。水果识别通常目标大、颜色丰富、遮挡多。我用 YOLOv5s 就能做到较好效果关键在于样本覆盖度。不同成熟度的苹果颜色差异很大同一枝上果子互相遮挡也很常见。训练数据里一定要包含侧光、逆光、夜间补光等不同光照条件否则产线环境一变模型就掉点。水果场景的模型输入尺寸用 640 足够因为目标都很大没必要上 1280。车牌识别则不一样车牌字符小且往往在整帧中只占一小块。如果相机像素是 500 万拍一整条车道车牌区域也就几百像素宽直接整图推缩到 640字符细节基本丢失。这种场景我用两段式方案先用 YOLOv5 检测车牌位置把车牌区域裁剪放大再接 OCR 识别字符。YOLOv5 在这个流程里只负责定位训练时输入用 1280 或切片推理确保小目标框得准。我还尝试过直接把低分辨率车牌图用扩散模型放大再喂给 OCR也就是热词里提到的“低分辨率转高分辨率 diffusion”但在工业部署里完全不可行一张图生成时间就几百毫秒还会产生幻觉字符不如从采集端提高帧率和清晰度。5.2 常见问题速查表我把项目里遇到的高频问题整理成了一张表方便排查现象可能原因排查与解决方法相机不出图驱动未装好 / 网络 IP 不对检查 MVS 能否发现设备GigE 相机要设置同网段 IP未收到触发信号触发模式未开启 / 触发源选择错误 / 信号线问题 / 曝光时间过短按 2.2 节的顺序逐个检查推理帧率很低输入分辨率太大 / 设备用了 CPU / 未用 TensorRT切片输入、导出 ENGINE用 GPU 推理显存不足输入尺寸过大或 batch 过大减小 imgsz、batch或用更小的模型 v5s/n小目标漏检严重整图缩放丢失细节用切片推理增加重叠训练时用 1280 输入训练 mAP 很低数据标注错误 / 类别顺序不一致 / 学习率不合适检查标注归一化核对 data.yaml names调整 lr0转换 ONNX 后结果不一致动态尺寸 / 输出层解析问题固定输入尺寸检查 YOLOv5 输出格式Jetson 部署速度慢没装 TensorRT / 使用普通 PyTorch 模型导出 engine减少输入尺寸使用半精度这张表是我自己复盘时整理的不一定覆盖所有情况但按这个顺序排查能解决大部分问题。5.3 几点压箱底的经验项目做多了以后我发现 YOLOv5 和海康相机的组合最怕的不是模型不够强而是工程细节粗糙。最后分享几个让我少走弯路的经验。第一相机触发和模型推理一定要分开调。刚开始调试时不要一上来就搞什么自动触发。先用软触发一张一张拍图跑通整个链路确认模型没问题后再上硬触发这样定位问题会快很多。第二高分辨率场景的很多问题并不是模型决定的而是采集环节决定的。图像模糊、曝光过度、帧率不稳定都会让后续的检测精度大打折扣。所以先把相机调清晰再谈算法。第三数据版本和模型版本一定要管理好。我在产线上吃过亏同一个模型文件改了几个超参数重新训练没有记录好结果现场调试时找不到最优版本。后来每次训练前都在跑命令里加注释模型导出也都按下发日期命名。还有一个小技巧批量切图推理时尽量用固定切块顺序并在代码里写死偏移量不要每次动态计算能省不少时间。如果做更复杂的项目建议把采集、推理、通信封装成独立模块这样换相机、换模型的时候只改配置不动代码维护成本会低很多。做这类项目最踏实的路径就是先用小项目把全流程跑通再逐步加分辨率、加帧率、加复杂度。希望这些实战细节能让你少踩几个我踩过的坑。
