把无人机飞上城市街道的那一刻，我脑子里其实盘旋着一个很具体的问题：空中视角下的占道经营，到底能不能被模型稳定地揪出来。之前用地面摄像头做违规摆摊识别，路灯杆、商店招牌、绿化带一挡，经常漏检，而且执法部门真正想要的是一整条街的全局态势，不是某个路口的一帧画面。无人机的好处显而易见——视野开阔、角度统一、能沿着街道快速巡航。但代价也很直接：目标在画面里非常小，一个摊点可能就几十个像素，光照从早到晚变化剧烈，树影、车顶、雨棚随时制造干扰。这个项目做的事情，就是围绕"无人机街道巡检占道经营识别"把整条链路跑通——整理一套可用的占道经营数据集，训练YOLO模型，再部署到实际巡检场景里做验证。如果你手里也有一堆无人机航拍图，想训练一个能识别街道商贩违规摆摊的模型，或者正在做智慧城市治理方向的目标检测，这篇内容应该能给你一些可以直接抄作业的思路。
1. 项目背景与需求拆解
1.1 为什么无人机+占道经营是个真需求
先聊聊需求侧。城市治理里有个高频场景：街道巡查发现占道经营，需要及时处置。传统方式靠城管队员开车或步行巡查，效率低、覆盖面小，高峰期同一路段可能半小时都走不到一次。固定摄像头能解决部分点位，但一套枪机覆盖一条街，视角是水平的，低矮摊位被车辆一挡就看不见了。无人机把视角拉高之后，一条街从东头到西头几秒钟就能扫完，问题点带有清晰的空间位置，复查也方便。
但"看得见"不等于"认得出"。空中看到的是一个摊位还是一辆普通面包车，是合法店外摆放还是违规越线，这些都需要模型来判定。这个项目把目标锁定在占道经营识别上，本质上是在给无人机配一双能自动过滤街道杂音的眼睛。智慧城市治理对这类识别能力的需求会越来越大，后面做违建识别、垃圾堆放检测、流动摊贩疏导，基本是同一套技术底座换数据。
1.2 从业务到技术的链路拆解
整个项目如果拆开看，大概有这么几块：
第一，数据从哪来。无人机航拍街道素材不会天然带有标注，需要自己采集、清洗、框选目标。这里面最花时间的不是飞飞机，而是标注时面对成千上万个大小不一的摊位框，怎么标才能让模型学会。
第二，模型怎么选。目标检测现在选择很多，YOLO系列在速度和精度之间平衡最好，适合无人机端侧实时推理。这个项目用的就是YOLO，具体版本和参数量下面章节细说。
第三，怎么部署验证。无人机不会在机载端跑一套庞大模型，需要把模型转换到机载算力平台上，还要考虑帧率、功耗、检测结果怎么回传。
这条链路和之前做的固定点位识别项目有本质区别：拍摄角度从水平变俯视，目标尺度从几百像素缩到几十像素，背景从单一街道变成连续变化的城市地表。每一个差别都会在模型训练和实测中变成坑，后面我会把踩过的坑逐个讲出来。
2. 占道经营数据集：从原始航拍到YOLO格式
2.1 数据集来源与数量分布
训练目标检测模型，数据是地基。这套项目使用的数据集编号是10437期，内容全部围绕街道商贩违规摆摊场景。数据来源做了三层补充：第一层是无人机沿街巡检拍摄的正射和斜视画面，覆盖上午、傍晚、夜间三个时段；第二层是路边高点补拍的镜头，用于模拟无人机在悬停状态下的视角；第三层是从公开街景素材里挑选的正常街道负样本，用来降低误检。
整个数据集清洗后保留了一万多张有效图像，其中80%左右是无人机视角，20%是街道高点视角。光照分布上，白天占60%、阴天占20%、夜间占20%。实例数量接近三万五千个，目标绝大多数是中小尺度，很多框的高宽只有三四十像素。
这里要重点强调一个很多人忽视的问题：占比不能只按"张"算，要按"场景"算。如果数据全部来自同一条示范街，模型见到实景就废了。我对数据做了一轮场景去重，按街道特征和拍摄高度做了聚类，保证训练集和验证集来自不同路段，验证集里还故意放了一些训练集没出现过的街道类型。这个操作对最终精度影响非常大。
2.2 标注规范与类别设计
标注工具用的是开源标注软件，支持YOLO格式导出。类别设计上，一开始我也纠结过：只标一个粗类"摊位"，还是拆细？最后定的是三个细分类别：固定摊位移位越界、流动摊贩、货物占道堆放。原因很简单：执法场景里，固定摊位和流动摊贩的处置方式完全不同，前者是整改，后者是劝离，货物堆放又可能是临时装卸。如果只用一个类别，模型学到的特征混合在一起，调优时很难定位错在哪儿。
标注边界有两条规则必须遵守：
- 目标被雨棚、遮阳伞遮挡时，框要包含完整目标外轮廓，也就是要标出"未遮挡时的完整边界"，而不是只框可见部分。这样模型不会因为伞的位置飘移而跟丢摊位本体。
- 目标极小但能明确判断为摊点时，宁可标上，不能漏。因为小目标样本本来就少，漏一个就少一个学习机会。当然，肉眼都难以确认的像素团就不标，那是噪声不是样本。
标注完成后统一转成YOLO格式的txt文件，每行一个目标，格式是class_id x_center y_center width height，坐标全部做归一化处理。这里有个细节：无人机俯拍视角下，地面物体往往是任意朝向的，常用的轴对齐矩形框会框进大量背景。要不要用旋转框？我实测下来，YOLOv8原生支持的是轴对齐框，换旋转框会引入一大堆后处理复杂度，而且本场景里摊位的矩形框通常占总面积70%以上，轴对齐框已经够用。先求落地，再谈极限精度。
2.3 数据增强：解决小目标和样本不平衡
无人机场景的小目标问题，靠数据增强能缓解但不能根治。我用的增强策略分两种：通用增强和小目标专项增强。
通用增强配置如下：
- 马赛克增强，关闭随机擦除：无人机视角下场景本身信息密集，随机擦除容易把目标直接抹掉。
- 复制粘贴增强：把干净的摊位目标复制到另一张图的空白路面区域，制造更多正样本，这个策略对城市地面场景意外地有效。
- 上下翻转增强打开：地面摄像头通常不翻，但无人机俯拍在反向飞行时画面确实会上下颠倒，翻转等于增加一倍样本。
- 色彩抖动小心控制：夜间和白天样本的亮度差异巨大，色偏增强过猛会让模型在真实场景里颜色混乱，建议只做轻度的亮度和饱和度扰动。
样本不平衡也需要单独处理。数据集中白天样本充足、夜间样本少，我先把夜间样本提高到总数的20%，再针对雨天、逆光这类极端场景做了定向增补。数据层面雨露均沾之后，模型夜间测试的漏检率明显下降。
3. 模型选型与训练参数
3.1 YOLO版本怎么选
YOLO系列从v5到v11，还有各种分支，选型时很容易挑花眼。我的判断标准很简单：机载部署的算力约束摆在那里，模型精度和推理速度必须同时满足。横向对比过YOLOv5s、YOLOv8s、YOLOv8n之后，最终选择的是YOLOv8s作为主力模型，原因有几个：
- v8的C2f结构在特征融合上比v5的C3更细腻，对中小目标的特征表达能力更好，实测小目标mAP提升约三个点。
- v8的anchor-free头在密集场景下预测框数量更稳定，后处理里面没有anchor匹配的复杂环节，误检率略低。
- v8n速度最快但精度下降明显，v8m精度高一截但帧率对机载平台不够友好，v8s是速度和精度都能接受的折中点。
如果你的机载算力非常紧张，可以考虑v8n配合切片推理方案，这个后面章节会讲。如果算力充足，直接上v8m或更大的模型，精度收益确实存在。
3.2 输入分辨率与小目标的权衡
这个项目里最影响精度的参数是输入分辨率。640乘640是YOLO的默认输入，但在无人机巡检场景下几乎必然漏检小目标。一个40像素宽的摊位缩放进640分辨率再经过下采样，到最后特征层只剩几个像素，检测头基本无能为力。把输入分辨率提高到1280乘1280之后，小目标保留的像素量翻了几倍，mAP提升非常明显。
代价是显存和推理时间同步增长。我的做法是：训练阶段用1280输入，部署阶段也保持1280输入，不搞"训练1280、推理640"这种偷懒方案。实测对比下来，训练和推理分辨率一致，精度损失最小。如果你的显存不够，可以把批量大小降到8，或改用自动混合精度训练。
3.3 训练配置与超参数调优
训练配置这块，直接给一组能跑出结果的参数组合。基于COCO预训练权重做微调，迭代120轮，批量大小16，输入尺寸1280乘1280，优化器用AdamW，初始学习率0.002，权重衰减0.0005。数据增强在前60轮保持强度，后60轮逐渐降低增强幅度，让模型回归真实分布。这个"先强增强后退火"的节奏是从实际教训里总结出来的：全程满强度增强会让模型学到的特征过于"抽象"，在真实数据上反而表现不稳。
类别数为3，对应前面说的三个细分类别。超参数里最值得关注的是mosaic增强系数，直接设为0.5。太高会让模型看到大量拼接痕迹，太低则丢失多尺度信息。还有一个平台默认开了但本场景需要关掉的：随机透视变换。无人机俯拍本质是正射投影，透视变换会往图里注入不符合实际的几何变形，对训练反而有害。
3.4 训练过程实测记录
训练过程是标准的loss曲线下降。前20轮分类损失从2.1快速降到0.8，边界框损失同步收敛；60轮之后曲线趋于平缓；到110轮附近，验证集mAP基本不再变化。这时候我做了一次在1280分辨率下对验证集的完整评估：mAP@0.5达到87.6%，mAP@0.5:0.95达到56.3%。这个数字单独看不算夸张，但考虑到目标大多是中小尺度、且验证集故意混入了不同街道场景，实际表现已经满足"白天可辅助巡查"的要求。
夜间子集单独测出来mAP@0.5在78%左右，比白天低不少，主要丢分在暗光下目标边缘模糊、摊点和背景对比度不足。这个问题单靠模型训练解决不了，我最后给夜间巡检建议是配合无人机探照灯或选择兰博时段补光。
4. 无人机巡检场景下的精度评估与部署
4.1 评测指标不能只看mAP
很多项目交付时只报一个mAP@0.5，但无人机巡检场景里，光看这个数字会骗人。mAP是各类别所有置信度阈值下精召曲线的积分平均，它会平滑掉很多实际部署时致命的短板。我做评估时会额外关注三个指标：小目标召回率、高频误检率和单帧处理延迟。
小目标召回率是把所有检测框面积小于32乘32像素的目标单独拎出来统计召回。这个指标直接反映无人机高空巡检的核心能力，如果低于70%，说明模型在真实巡航高度上基本抓瞎。高频误检率则是统计在正常街道负样本上的误报密度，一般用"每平方公里误检数"来量化，要控制在3个以内，否则每次出警都是狼来了，执法队员很快会对系统失去信任。
4.2 SAHI等多尺度推理
针对小目标，我用到了一个非常有效的推理方案：切片辅助推理。核心思想简单粗暴——把大图切成多块带重叠区域的子图，分别做检测，再用NMS把跨子图重复检测的框合并。它模拟了人凑近看的过程：整条街看不清单个摊位，放大到区域就看清楚了。
实际配置是切片尺寸512、重叠率0.25，推理时保持模型输入1280。跑一遍全图加切片的处理时间大约是纯全图推理的两倍，但小目标召回率能提升8到10个百分点，夜间场景提升更明显。这个方案唯一的缺点是推理框架实现稍复杂，需要自己写切图重组逻辑。如果你用的是云端GPU或地面站处理，这点延迟完全值得；如果是机载实时处理，就要评估算力余量。
4.3 模型部署到机载设备
模型导出和部署是另一个坑密集的环节。训练好的PyTorch权重必须经过模型转换才能在机载推理引擎上跑出高帧率。我的路线是：PyTorch权重导出为ONNX，再转成TensorRT的engine格式，用FP16精度做推理加速。
实测下来，在常见机载嵌入式开发板上，FP16推理比FP32快接近一倍，而精度损失不到0.5%。整个转换过程中最需要注意的是动态形状配置。不少开发者导出的engine只支持固定批次，一旦输入尺寸有波动就报错。我建议直接把batch固定为1，输入尺寸固定为1280乘1280，换取更高效的显存布局和更低延迟。
机载推理接口部署完成后，单帧处理延迟大约40毫秒左右，对20帧每秒的巡航视频流完全够用。还要把推理线程和视频采集线程分开，用双缓冲队列防止丢帧。这个优化看起来基础，但扛住了无人机飞行时的负载波动，实测里帧率一直很稳。
4.4 检测结果坐标映射
识别出摊位还不够，执法队员需要知道摊点在哪儿。检测框中心点的像素坐标需要映射到经纬度或局部平面坐标。在无人机正射模式下，可以结合飞行高度、相机焦距、云台角度做单应变换近似换算。
我用的简化方案是：把检测框中心点像素坐标换算成相对画面中心的偏移，结合无人机自身的GPS位置和机头朝向，做一次平面坐标旋转平移。精度在正射且地面相对平坦时大约三到五米偏差，对于街道巡检这种任务足够用。如果摊位在画面边缘且云台大角度倾斜，误差会偏大，所以实际部署时会让无人机先做一次云台俯视锁定再记录精确坐标。
5. 常见问题与避坑清单
5.1 误检与漏检的典型场景
把整个项目跑完之后，我整理了一份高频问题清单，都是实测里踩过的真实坑。
第一类误检是卡车和货车被识别成流动摊贩。高空俯视下，一辆白色厢式货车顶部和一个带棚摊位顶部确实太像了。解决办法不是魔改模型，而是收集更多"路边停车"负样本加入训练集。我把负样本比例提高到正样本的三成，误检率立刻降下来。
第二类是固定摊位越界行为容易漏检。原因是很多固定摊位的默认合法外摆和违规越界之间，特征差异非常细微。这类问题单靠目标检测的框无法解决，后续我会改用语义分割加规则判断来补充，目前是先把两种状态的样本都标清楚，让模型至少学会"这里有个摊位"，至于是否越界，交给地面核实。
第三类是密集摊位重叠。夜市场景中相邻摊位挨得很近，预测框相互重叠，NMS会把两个相邻摊点合并成一个框。解决办法是把NMS的IoU阈值从默认的0.45调低到0.3，并开启跨类别NMS抑制。
这些都是典型的工程调优思路，没有什么高深的数学，就是反复测、反复看错例、反复加数据。
5.2 硬件与运行时的坑
机载设备本身也是问题大户。散热是关键项，嵌入式平台上高负载推理会让核心温度很快逼近上限，一旦降频帧率立刻暴跌。我在实际部署时专门加装了散热片和小风扇，并把推理任务设置成大核优先。功耗控制方面，建议开启低功耗模式，让推理任务在GPU上运行而不是CPU，整套系统功耗能控制在几十瓦以内。
还有一个容易被忽略的点：机载存储卡写入速度。如果检测结果和视频切片大量写卡，存储卡速度变成瓶颈会导致视频流断帧。后来我把检测结果改成只写结构化JSON，视频默认存地面站，机载只保留最近五分钟的循环缓存。这个改动之后，长期运行的稳定性提升非常明显。
6. 几点延伸想法
项目交付之后，我又重新审视了整套方案里哪些环节是可以复用的。占道经营识别只是智慧城市治理的一个切入点，同一套数据采集流程、模型训练策略和部署链路，换一套标注数据，完全可以推到渣土车未覆盖运输识别、违规建筑检测、水域漂浮物识别等场景。与其每次从零开始，不如把"无人机巡航+目标检测+坐标回传"这套底座沉淀下来，根据不同业务快速换数据迭代。
最后分享两个我自己觉得最值得记住的经验：一是数据集质量永远优先于模型技巧，小目标识别问题的七成解决靠的是把数据标注和场景平衡做扎实；二是一切以实测为准，mAP再漂亮，也要看它在真实巡检视频上连跑两小时的表现。这两句话支撑起了整个项目的最终效果，也希望对你有所启发。
