简介针对旋转目标检测需求这份资源以YOLOv5为基础扩展了角度回归分支可同时输出边界框、类别与旋转角度。面向具备一定深度学习基础、希望在检测任务中引入角度信息的开发者尤其适合航空航天、工业质检、交通监控等方向。资源共173个文件包含66个Python脚本、33个YAML配置、6个C与4个CUDA源文件以及Markdown文档和示例图片等压缩包约24.45MB。其中C/CUDA代码实现了旋转框NMS等关键后处理便于精读算法细节与二次开发。目前已有1041人学习下载。借助完整工程结构研究者可直接对照配置文件理解角度分支的训练与推理流程工程人员也可基于源码适配自有数据快速验证旋转目标检测效果。 搞旋转目标检测这个方向十有八九是碰到了水平框解决不了的问题。我之前在项目里做航拍图像的目标识别飞机停得横七竖八用普通YOLOv5跑出来的检测框一个目标恨不得框住旁边两个目标IoU算出来虚高后处理NMS一压直接误删。后来切到旋转目标检测这些问题才真正落地解决。这篇就把我在YOLOv5基础上做旋转框检测的完整思路梳理一遍从数据、模型改法、损失函数到部署踩坑一条龙讲清楚给准备入坑的朋友一个可以直接抄的参考。先说明一下旋转目标检测是啥。普通目标检测输出的是(x, y, w, h)四个值矩形框永远和图像坐标轴平行。旋转目标检测在此基础上多了一个角度θ输出变为(x, y, w, h, θ)五个参数。这第五个参数看着简单但牵扯到标注格式、损失计算、NMS后处理、锚框匹配机制全部要跟着改工作量并不只是加一个分支那么简单。1. 方案选型为什么死磕YOLOv5而不是另起炉灶1.1 水平框在密集场景下的致命缺陷先看一个很典型的例子。遥感图像里有一排停着的飞机机头方向各不相同如果只画水平外接矩形小飞机侧着停的时候水平框面积可能比飞机实际面积大出一倍不止。这意味着两个相邻目标一旦有一点角度错位框就会大面积重叠NMS计算IoU时很容易把低置信度的目标直接抑制掉造成漏检。更麻烦的是精度评估阶段。DOTA数据集的评估标准是mAP它对旋转框的IoU计算要求框与框之间真的在空间上重合水平框在目标斜着的时候gt框和预测框的IoU天然就吃亏。所以只要任务是遥感、航拍、无人机视角、文档扫描这类目标方向随意的场景水平框方案在精度上限上就有天花板。1.2 YOLOv5-OBB与主流旋转检测框架的取舍目前旋转目标检测的主流技术路线大致分三类。一类是两阶段方法代表是RoI Transformer、Oriented R-CNN精度确实高但速度慢部署到边缘设备上比较吃力。另一类是单阶段anchor-based方法比如Rotated RetinaNet、S2ANet精度和速度相对均衡但工程化代码成熟度参差不齐训练配置文件需要从零调。第三类就是YOLOv5-OBB系列也就是在YOLOv5的基础上加角度回归把原来水平框的输出头改成带角度的输出头。我个人选择YOLOv5-OBB原因有几个。首先是YOLOv5的生态太成熟了数据加载、Mosaic增强、自动锚框、多尺度训练、TensorRT导出这些链条是现成的不需要自己重复造轮子。其次是YOLOv5的检测头结构做角度分支改造非常自然只需要把reg_output的通道数从4改成5损失的mask、匹配逻辑稍作调整即可。最关键的是工程落地阶段需要部署到NXP iMX8MP这类边缘设备上YOLOv5的算子结构对NPU和量化工具链友好得多。提示如果你的需求只是验证算法效果不在乎速度直接用MMRotate里的S2ANet或者Oriented R-CNN会更省心精度也确实更硬。但如果是奔着量产部署去的YOLOv5-OBB路线基本是当前综合性价比最高的选择。2. 数据标注与预处理旋转框方案的隐藏工作量2.1 标注格式选型DOTA四点格式还是OpenCV五点格式旋转框标注格式没有统一标准不同框架要求不一样。DOTA数据集的原始标注是四点多边形坐标即四个顶点从头到尾排列成8个数字但这种格式不适合直接训练因为四个顶点的顺序必须一致否则模型学不到稳定的几何语义。更常见的训练格式是OpenCV五点格式也就是(cx, cy, w, h, angle)其中angle是弧度制表示框的宽度方向与x轴正方向的夹角范围是[-π/2, 0)。这个格式直接对应旋转框参数模型输出天然对齐训练和推理都方便。实际代码中很多实现用的是hbb格式转换工具把四点坐标按照“长边定义法”或者“opencv定义法”转换成五参数。2.2 标注工具与格式转换实操标注旋转框我试过几款工具最终留下来的是roLabelImg和X-AnyLabeling。roLabelImg是LabelImg的旋转增强版可以画旋转矩形保存成XML格式。X-AnyLabeling就更现代一些支持yolo-obb格式直接标注导出就是带角度的txt文件非常契合YOLOv5-OBB流程。如果你拿到的原始数据是DOTA四点格式转换逻辑按下面步骤来计算4个点围成四边形的最小外接旋转矩形直接调用cv2.minAreaRect得到RotatedRect拿到(cx, cy, w, h, angle)。 但这里有个坑cv2.minAreaRect返回的angle范围是[-90, 0)当短边作为宽度时角度退化会出现一定要检查一下你的数据转换后可视化效果很多目标会旋转90°误差。把angle统一映射到目标框架定义的范围内OpenCV格式用[-π/2, 0)长边定义法用[-π/2, π/2)选好一种就全程保持一致否则训练会神经错乱。2.3 数据增强时角度要跟着几何变换同步这一点是旋转框检测最容易忽略的坑。普通YOLOv5的Mosaic增强里图像做了随机旋转、缩放、平移标签框只要跟着做同等变换就行但旋转框不行你图像旋转了45°框的角度参数也要同步加45°同时换算出新的中心点和宽高。我当时用的增强策略是Mosaic、随机水平/垂直翻转、随机90°旋转这些操作全部在程序中把标签的五个参数同步换算。我自己写了一个坐标变换函数把五参数转回四个顶点坐标做完整几何变换后再转回五参数虽然每一步多花了点时间但至少保证了训练集里的角度分布与图像实际内容一致不然后期验证集上角度误差惨不忍睹。3. 模型改造与训练调参实录3.1 YOLOv5检测头加角度分支的改法YOLOv5默认的检测头每个尺度输出两部分cls分支和reg分支。在普通水平框版本中reg分支输出的是4个值中心点偏移、宽高。改成旋转框版本后reg分支输出变成5个值最后一个维度是角度θ。对应的改动集中在三个地方。第一是模型定义文件yolo.py把Detect类里的reg输出通道数从4改成5并且给每个尺度的anchor数量乘上输出维度。第二是损失函数loss.py在bbox loss计算部分把角度预测和角度真值单独拎出来计算损失。第三是标签分配也就是anchor匹配阶段旋转框的IoU计算不能直接用普通水平框IoU要换成旋转IoU这一步是性能和精度的双重瓶颈。3.2 损失函数设计角度回归的周期性陷阱角度回归最大的坑是周期性这个我踩过必须说清楚。如果直接对θ做Smooth L1损失模型预测89°和-89°时角度差只有2°但数值差却是178°梯度会直接爆炸式更新导致训练震荡甚至不收敛。解决办法常见的有两种。第一种是把角度损失换成交叉熵分类损失把360°按桶划分成若干个类别然后让模型做分类而不是回归。第二种是使用环形平滑标签CSL或者直接对角度向量化把θ编码成(cosθ, sinθ)两个值模型输出两个值做回归推理时再用atan2还原。我在实践中用的是第二种训练稳定度明显好很多。核心损失公式大致是位置与宽高CIoU或GIoU与水平框一致角度Smooth L1 with angle normalization或CSL分类损失分类BCE with logits与YOLOv5一致3.3 环境搭建与训练超参数调整训练环境的搭建如果你用的是NVIDIA显卡直接装CUDA 11.x和对应cuDNNPyTorch版本推荐1.13以上YOLOv5官方代码在2.0版本以后对旋转检测的兼容性更好。显卡驱动这一步其实最容易出错我用的RTX 3090一开始装的是推荐驱动版本跑其他项目正常但跑旋转框训练时偶发CUDA error后来把驱动升级到470.xx以上的稳定版才彻底解决。超参数方面我记录过一次完整的调参过程batch size单卡3090上取16显存占用约12G如果再大容易OOM初始学习率0.01搭配warmup 3个epoch训练轮数200个epoch大约在120轮后mAP增长变缓数据增强Mosaic概率设为1.0但在最后20轮关闭Mosaic让模型在真实分布上微调最终在自建数据集上跑出来的效果mAP50从水平框的71.3%提升到旋转框的86.2%这个提升主要来自角度正确带来的IoU准确率提升检测框数量没有变但有效命中增加了。注意训练过程中如果发现loss曲线一直下降但验证集mAP不动优先检查是不是角度定义不一致导致的评估指标失真。用可视化脚本把预测框画出来看比盯着曲线猜高效得多。4. 推理阶段与边缘设备部署4.1 旋转NMS后处理性能瓶颈与优化推理阶段和水平框最大的不同在于NMS。水平框NMS可以直接用普通IoU但旋转框必须用旋转IoU也就是两个任意角度的矩形之间的交并比。旋转IoU计算本身就是几何计算不能像水平框那样直接调用矢量化运算所以推理速度会明显变慢。我实测过纯Python实现的旋转NMS一轮推理要额外花120ms这对边缘设备是不可接受的。优化方案有两个层面。第一层是代码优化把旋转IoU计算用C扩展重写计算量能降一个量级实测能压到15ms左右。第二层是策略优化在旋转NMS之前先做一个基于中心点距离的粗过滤距离远的框直接跳过旋转IoU计算这个方法能再减少大约40%的计算量。4.2 模型转换与量化NXP iMX8MP与树莓派5部署实录部署这块我实际在两类设备上跑过一类是NXP iMX8MP带NPU一类是树莓派5纯CPU。NXP iMX8MP的部署链路是这样的PyTorch模型 → ONNX → NPU工具链支持的量化模型。这里有两个关键点必须注意。第一iMX8MP的NPU对算子支持有限旋转框输出头里如果用了torch.atleast_2d这类动态shape操作导出ONNX时要特别小心建议把后处理里的角度转换从网络里拆出来放到CPU端做只让NPU跑纯CNN部分。第二INT8量化后置信度分数会掉我们实际遇到mAP从0.86掉到0.81的情况解决方法是量化校准集尽量贴近实际部署场景不能直接用训练集的子集要采集现场光照和目标分布的数据。树莓派5的部署方案就简单直接了模型导出ONNX后直接用onnxruntime跑FP32精度然后做一个流水线优化把图像缩放、Chw转换、后处理全部放在多线程队列里实测FP32推理在树莓派5上单帧耗时约480ms优化后压到350ms左右勉强满足轻量级实时场景如果要做实时视频流建议上NPU。4.3 后处理中的角度还原与坐标映射部署端最容易出bug的地方是角度还原。网络输出的原始角度是归一化后的值后处理时要先反归一化到真实角度范围再结合中心点坐标和宽高恢复出四个顶点坐标最后画框或者做业务判断。我建议画框统一走cv2.boxPoints(cv2.RotatedRect(...))OpenCV内部处理了各种边界情况比自己手写四点转换函数稳定得多。再补充一个实际遇到的边界情况当目标的旋转角度接近0°时角度还原误差会被宽高比放大。比如一个宽高比10:1的长条形目标角度误差1°在目标远端边缘就会产生约宽度10%的位置偏移。这个在检测集装箱船、铁塔这类细长目标时尤其明显。解决办法是给角度损失加一个与目标宽高比相关的权重对细长目标的角度精度要求更高。5. 常见问题与排查技巧速查旋转目标检测的坑集中在训练和部署两个阶段我整理了一个速查表基本覆盖了大部分常见问题。问题可能原因排查与解决方案训练loss持续不降角度回归周期性导致梯度方向不稳定换成角度向量化编码或CSL分类损失预测框角度与实际方向相差90°角度定义不一致训练格式与推理格式混用检查数据管线中所有角度转换统一为同一定义mAP提升缓慢、后期过拟合Mosaic增强没做衰减最后20轮关闭Mosaic换成轻度颜色增强旋转NMS耗时严重旋转IoU计算无向量化实现C扩展中心点距离粗过滤部署后角度预测偏差大量化误差放大角度小误差校准集覆盖现场分布角度误差做后处理补偿导出ONNX失败动态shape或自定义算子把角度归一化和box恢复拆到网络外CPU处理还有一个小技巧是可视化管理。我训练过程中每20轮导出一次预测可视化图重点看几个场景密集停放目标、细长目标、接近水平的目标。这比盯着mAP曲线要灵敏得多能快速定位模型是在学目标还是在学角度规律。6. 关于工程落地的一些经验补充最后再分享几个细节这些不是论文里会写的东西但实际项目里非常关键。第一个是锚框设置。YOLOv5默认用K-Means自动从标注中聚类锚框尺寸但旋转框的“宽高”统计和水平框不一致尤其是细长目标聚类出来的锚框长宽比跨度很大需要在自动锚框之后手动检查一下锚框宽高比的合理性必要时用更细的锚框分组。第二个是推理时的置信度阈值和NMS阈值这两个参数在旋转框场景下和平框场景差别很大。水平框场景下NMS阈值取0.45挺合适但旋转框因为旋转IoU计算更精细NMS阈值可以适当调到0.5~0.6置信度阈值则要根据场景漏检和虚警的可接受程度来调。我做过一次阈值扫描发现0.35置信度配0.55 NMS在大多数场景下是综合表现最好的组合。第三个是数据集的角度分布均匀性。如果你的训练数据里目标朝向有明显的偏置比如全都是水平或者竖直方向模型学出来的角度预测会向这些方向偏移。我在标注阶段就做了角度直方图统计发现部分类别的角度分布非常不均做了角度增强补充后最终模型在各种随机朝向下的稳定性明显改善。旋转目标检测在YOLOv5上的落地本质上是把成熟的目标检测框架和几何约束结合的过程最考验人的不是模型结构改动而是数据格式一致性、角度定义统一、后处理工程化这些环环相扣的细节。希望我这篇实操记录能帮你少踩几个坑顺利把项目跑起来。如果有其他细节问题欢迎在评论区一起交流。本文还有配套的精品资源点击获取 基于YOLOv5的旋转目标检测实战：从数据标注到部署全解析
简介针对旋转目标检测需求这份资源以YOLOv5为基础扩展了角度回归分支可同时输出边界框、类别与旋转角度。面向具备一定深度学习基础、希望在检测任务中引入角度信息的开发者尤其适合航空航天、工业质检、交通监控等方向。资源共173个文件包含66个Python脚本、33个YAML配置、6个C与4个CUDA源文件以及Markdown文档和示例图片等压缩包约24.45MB。其中C/CUDA代码实现了旋转框NMS等关键后处理便于精读算法细节与二次开发。目前已有1041人学习下载。借助完整工程结构研究者可直接对照配置文件理解角度分支的训练与推理流程工程人员也可基于源码适配自有数据快速验证旋转目标检测效果。 搞旋转目标检测这个方向十有八九是碰到了水平框解决不了的问题。我之前在项目里做航拍图像的目标识别飞机停得横七竖八用普通YOLOv5跑出来的检测框一个目标恨不得框住旁边两个目标IoU算出来虚高后处理NMS一压直接误删。后来切到旋转目标检测这些问题才真正落地解决。这篇就把我在YOLOv5基础上做旋转框检测的完整思路梳理一遍从数据、模型改法、损失函数到部署踩坑一条龙讲清楚给准备入坑的朋友一个可以直接抄的参考。先说明一下旋转目标检测是啥。普通目标检测输出的是(x, y, w, h)四个值矩形框永远和图像坐标轴平行。旋转目标检测在此基础上多了一个角度θ输出变为(x, y, w, h, θ)五个参数。这第五个参数看着简单但牵扯到标注格式、损失计算、NMS后处理、锚框匹配机制全部要跟着改工作量并不只是加一个分支那么简单。1. 方案选型为什么死磕YOLOv5而不是另起炉灶1.1 水平框在密集场景下的致命缺陷先看一个很典型的例子。遥感图像里有一排停着的飞机机头方向各不相同如果只画水平外接矩形小飞机侧着停的时候水平框面积可能比飞机实际面积大出一倍不止。这意味着两个相邻目标一旦有一点角度错位框就会大面积重叠NMS计算IoU时很容易把低置信度的目标直接抑制掉造成漏检。更麻烦的是精度评估阶段。DOTA数据集的评估标准是mAP它对旋转框的IoU计算要求框与框之间真的在空间上重合水平框在目标斜着的时候gt框和预测框的IoU天然就吃亏。所以只要任务是遥感、航拍、无人机视角、文档扫描这类目标方向随意的场景水平框方案在精度上限上就有天花板。1.2 YOLOv5-OBB与主流旋转检测框架的取舍目前旋转目标检测的主流技术路线大致分三类。一类是两阶段方法代表是RoI Transformer、Oriented R-CNN精度确实高但速度慢部署到边缘设备上比较吃力。另一类是单阶段anchor-based方法比如Rotated RetinaNet、S2ANet精度和速度相对均衡但工程化代码成熟度参差不齐训练配置文件需要从零调。第三类就是YOLOv5-OBB系列也就是在YOLOv5的基础上加角度回归把原来水平框的输出头改成带角度的输出头。我个人选择YOLOv5-OBB原因有几个。首先是YOLOv5的生态太成熟了数据加载、Mosaic增强、自动锚框、多尺度训练、TensorRT导出这些链条是现成的不需要自己重复造轮子。其次是YOLOv5的检测头结构做角度分支改造非常自然只需要把reg_output的通道数从4改成5损失的mask、匹配逻辑稍作调整即可。最关键的是工程落地阶段需要部署到NXP iMX8MP这类边缘设备上YOLOv5的算子结构对NPU和量化工具链友好得多。提示如果你的需求只是验证算法效果不在乎速度直接用MMRotate里的S2ANet或者Oriented R-CNN会更省心精度也确实更硬。但如果是奔着量产部署去的YOLOv5-OBB路线基本是当前综合性价比最高的选择。2. 数据标注与预处理旋转框方案的隐藏工作量2.1 标注格式选型DOTA四点格式还是OpenCV五点格式旋转框标注格式没有统一标准不同框架要求不一样。DOTA数据集的原始标注是四点多边形坐标即四个顶点从头到尾排列成8个数字但这种格式不适合直接训练因为四个顶点的顺序必须一致否则模型学不到稳定的几何语义。更常见的训练格式是OpenCV五点格式也就是(cx, cy, w, h, angle)其中angle是弧度制表示框的宽度方向与x轴正方向的夹角范围是[-π/2, 0)。这个格式直接对应旋转框参数模型输出天然对齐训练和推理都方便。实际代码中很多实现用的是hbb格式转换工具把四点坐标按照“长边定义法”或者“opencv定义法”转换成五参数。2.2 标注工具与格式转换实操标注旋转框我试过几款工具最终留下来的是roLabelImg和X-AnyLabeling。roLabelImg是LabelImg的旋转增强版可以画旋转矩形保存成XML格式。X-AnyLabeling就更现代一些支持yolo-obb格式直接标注导出就是带角度的txt文件非常契合YOLOv5-OBB流程。如果你拿到的原始数据是DOTA四点格式转换逻辑按下面步骤来计算4个点围成四边形的最小外接旋转矩形直接调用cv2.minAreaRect得到RotatedRect拿到(cx, cy, w, h, angle)。 但这里有个坑cv2.minAreaRect返回的angle范围是[-90, 0)当短边作为宽度时角度退化会出现一定要检查一下你的数据转换后可视化效果很多目标会旋转90°误差。把angle统一映射到目标框架定义的范围内OpenCV格式用[-π/2, 0)长边定义法用[-π/2, π/2)选好一种就全程保持一致否则训练会神经错乱。2.3 数据增强时角度要跟着几何变换同步这一点是旋转框检测最容易忽略的坑。普通YOLOv5的Mosaic增强里图像做了随机旋转、缩放、平移标签框只要跟着做同等变换就行但旋转框不行你图像旋转了45°框的角度参数也要同步加45°同时换算出新的中心点和宽高。我当时用的增强策略是Mosaic、随机水平/垂直翻转、随机90°旋转这些操作全部在程序中把标签的五个参数同步换算。我自己写了一个坐标变换函数把五参数转回四个顶点坐标做完整几何变换后再转回五参数虽然每一步多花了点时间但至少保证了训练集里的角度分布与图像实际内容一致不然后期验证集上角度误差惨不忍睹。3. 模型改造与训练调参实录3.1 YOLOv5检测头加角度分支的改法YOLOv5默认的检测头每个尺度输出两部分cls分支和reg分支。在普通水平框版本中reg分支输出的是4个值中心点偏移、宽高。改成旋转框版本后reg分支输出变成5个值最后一个维度是角度θ。对应的改动集中在三个地方。第一是模型定义文件yolo.py把Detect类里的reg输出通道数从4改成5并且给每个尺度的anchor数量乘上输出维度。第二是损失函数loss.py在bbox loss计算部分把角度预测和角度真值单独拎出来计算损失。第三是标签分配也就是anchor匹配阶段旋转框的IoU计算不能直接用普通水平框IoU要换成旋转IoU这一步是性能和精度的双重瓶颈。3.2 损失函数设计角度回归的周期性陷阱角度回归最大的坑是周期性这个我踩过必须说清楚。如果直接对θ做Smooth L1损失模型预测89°和-89°时角度差只有2°但数值差却是178°梯度会直接爆炸式更新导致训练震荡甚至不收敛。解决办法常见的有两种。第一种是把角度损失换成交叉熵分类损失把360°按桶划分成若干个类别然后让模型做分类而不是回归。第二种是使用环形平滑标签CSL或者直接对角度向量化把θ编码成(cosθ, sinθ)两个值模型输出两个值做回归推理时再用atan2还原。我在实践中用的是第二种训练稳定度明显好很多。核心损失公式大致是位置与宽高CIoU或GIoU与水平框一致角度Smooth L1 with angle normalization或CSL分类损失分类BCE with logits与YOLOv5一致3.3 环境搭建与训练超参数调整训练环境的搭建如果你用的是NVIDIA显卡直接装CUDA 11.x和对应cuDNNPyTorch版本推荐1.13以上YOLOv5官方代码在2.0版本以后对旋转检测的兼容性更好。显卡驱动这一步其实最容易出错我用的RTX 3090一开始装的是推荐驱动版本跑其他项目正常但跑旋转框训练时偶发CUDA error后来把驱动升级到470.xx以上的稳定版才彻底解决。超参数方面我记录过一次完整的调参过程batch size单卡3090上取16显存占用约12G如果再大容易OOM初始学习率0.01搭配warmup 3个epoch训练轮数200个epoch大约在120轮后mAP增长变缓数据增强Mosaic概率设为1.0但在最后20轮关闭Mosaic让模型在真实分布上微调最终在自建数据集上跑出来的效果mAP50从水平框的71.3%提升到旋转框的86.2%这个提升主要来自角度正确带来的IoU准确率提升检测框数量没有变但有效命中增加了。注意训练过程中如果发现loss曲线一直下降但验证集mAP不动优先检查是不是角度定义不一致导致的评估指标失真。用可视化脚本把预测框画出来看比盯着曲线猜高效得多。4. 推理阶段与边缘设备部署4.1 旋转NMS后处理性能瓶颈与优化推理阶段和水平框最大的不同在于NMS。水平框NMS可以直接用普通IoU但旋转框必须用旋转IoU也就是两个任意角度的矩形之间的交并比。旋转IoU计算本身就是几何计算不能像水平框那样直接调用矢量化运算所以推理速度会明显变慢。我实测过纯Python实现的旋转NMS一轮推理要额外花120ms这对边缘设备是不可接受的。优化方案有两个层面。第一层是代码优化把旋转IoU计算用C扩展重写计算量能降一个量级实测能压到15ms左右。第二层是策略优化在旋转NMS之前先做一个基于中心点距离的粗过滤距离远的框直接跳过旋转IoU计算这个方法能再减少大约40%的计算量。4.2 模型转换与量化NXP iMX8MP与树莓派5部署实录部署这块我实际在两类设备上跑过一类是NXP iMX8MP带NPU一类是树莓派5纯CPU。NXP iMX8MP的部署链路是这样的PyTorch模型 → ONNX → NPU工具链支持的量化模型。这里有两个关键点必须注意。第一iMX8MP的NPU对算子支持有限旋转框输出头里如果用了torch.atleast_2d这类动态shape操作导出ONNX时要特别小心建议把后处理里的角度转换从网络里拆出来放到CPU端做只让NPU跑纯CNN部分。第二INT8量化后置信度分数会掉我们实际遇到mAP从0.86掉到0.81的情况解决方法是量化校准集尽量贴近实际部署场景不能直接用训练集的子集要采集现场光照和目标分布的数据。树莓派5的部署方案就简单直接了模型导出ONNX后直接用onnxruntime跑FP32精度然后做一个流水线优化把图像缩放、Chw转换、后处理全部放在多线程队列里实测FP32推理在树莓派5上单帧耗时约480ms优化后压到350ms左右勉强满足轻量级实时场景如果要做实时视频流建议上NPU。4.3 后处理中的角度还原与坐标映射部署端最容易出bug的地方是角度还原。网络输出的原始角度是归一化后的值后处理时要先反归一化到真实角度范围再结合中心点坐标和宽高恢复出四个顶点坐标最后画框或者做业务判断。我建议画框统一走cv2.boxPoints(cv2.RotatedRect(...))OpenCV内部处理了各种边界情况比自己手写四点转换函数稳定得多。再补充一个实际遇到的边界情况当目标的旋转角度接近0°时角度还原误差会被宽高比放大。比如一个宽高比10:1的长条形目标角度误差1°在目标远端边缘就会产生约宽度10%的位置偏移。这个在检测集装箱船、铁塔这类细长目标时尤其明显。解决办法是给角度损失加一个与目标宽高比相关的权重对细长目标的角度精度要求更高。5. 常见问题与排查技巧速查旋转目标检测的坑集中在训练和部署两个阶段我整理了一个速查表基本覆盖了大部分常见问题。问题可能原因排查与解决方案训练loss持续不降角度回归周期性导致梯度方向不稳定换成角度向量化编码或CSL分类损失预测框角度与实际方向相差90°角度定义不一致训练格式与推理格式混用检查数据管线中所有角度转换统一为同一定义mAP提升缓慢、后期过拟合Mosaic增强没做衰减最后20轮关闭Mosaic换成轻度颜色增强旋转NMS耗时严重旋转IoU计算无向量化实现C扩展中心点距离粗过滤部署后角度预测偏差大量化误差放大角度小误差校准集覆盖现场分布角度误差做后处理补偿导出ONNX失败动态shape或自定义算子把角度归一化和box恢复拆到网络外CPU处理还有一个小技巧是可视化管理。我训练过程中每20轮导出一次预测可视化图重点看几个场景密集停放目标、细长目标、接近水平的目标。这比盯着mAP曲线要灵敏得多能快速定位模型是在学目标还是在学角度规律。6. 关于工程落地的一些经验补充最后再分享几个细节这些不是论文里会写的东西但实际项目里非常关键。第一个是锚框设置。YOLOv5默认用K-Means自动从标注中聚类锚框尺寸但旋转框的“宽高”统计和水平框不一致尤其是细长目标聚类出来的锚框长宽比跨度很大需要在自动锚框之后手动检查一下锚框宽高比的合理性必要时用更细的锚框分组。第二个是推理时的置信度阈值和NMS阈值这两个参数在旋转框场景下和平框场景差别很大。水平框场景下NMS阈值取0.45挺合适但旋转框因为旋转IoU计算更精细NMS阈值可以适当调到0.5~0.6置信度阈值则要根据场景漏检和虚警的可接受程度来调。我做过一次阈值扫描发现0.35置信度配0.55 NMS在大多数场景下是综合表现最好的组合。第三个是数据集的角度分布均匀性。如果你的训练数据里目标朝向有明显的偏置比如全都是水平或者竖直方向模型学出来的角度预测会向这些方向偏移。我在标注阶段就做了角度直方图统计发现部分类别的角度分布非常不均做了角度增强补充后最终模型在各种随机朝向下的稳定性明显改善。旋转目标检测在YOLOv5上的落地本质上是把成熟的目标检测框架和几何约束结合的过程最考验人的不是模型结构改动而是数据格式一致性、角度定义统一、后处理工程化这些环环相扣的细节。希望我这篇实操记录能帮你少踩几个坑顺利把项目跑起来。如果有其他细节问题欢迎在评论区一起交流。本文还有配套的精品资源点击获取