简介一套系统讲解无人机城市巡检建设的方案型PPT共59页重点面向智慧城市、自然资源、城管执法、交通环保等领域的方案规划与项目实施人员。资源包仅含1个PPTX文件压缩后约33.78MB内容按系统整体架构、大疆机场接入、AI算法库、管理后台、小程序工单闭环等模块展开。方案不仅说明由机场、算法、后台、小程序四部分组成的通用行业解决方案还结合Al变化检测与自动比对算法演示了房屋加建、土地监测、目标识别等真实场景并给出AI自动比对在准确率、时间成本上较人工巡查的量化优势。已有436人浏览学习适合作为智慧城市项目汇报、行业方案设计与无人机巡检业务培训的参考底稿能帮助读者快速把握平台组成、业务协同与落地路径。1. 无人机城市巡检系统真正要命的不是飞起来而是巡完怎么办拿到一份《无人机城市巡检系统》的59页PPT外行看到的是飞机、镜头和炫酷大屏内行看到的却是另一个问题发现一个疑似违建之后这张照片怎么变成有坐标、有对比、有责任人的工单再回到网格员手里去复核。城市巡检是典型的“飞得容易、巡得难”飞机可以按航线自动把照片拍回来真正的成本在图像与地理信息、业务流程的衔接。它适合县市级城管、园区、水务、住建等有明确巡查清单的甲方也适合准备把航测能力转化为巡检服务的集成商。这篇文章我从一个常年做落地项目的工程视角把方案拆成可执行的链路并告诉你哪些参数最值得调。2. 先把“巡什么”拆明白无人机、任务航线与数据链路的选型逻辑城市里能飞的东西很多但能纳入巡检的对象必须满足两个条件一是能用影像稳定发现二是发现了以后有人能处置。所以我做这类项目的第一步从来不是选无人机而是拿着需求方的巡查清单去对成像条件。需求方往往直接说“我们要发现所有问题”这句话无法翻译成算法必须拆成“目标类别、影像特征、业务处置动作”三要素否则后面选飞机、选镜头、建模型都会走偏。2.1 先建一张“巡检对象-现象-载荷-算法”对照表我一般会先和业务方开一次现象清单会最后落到一张类似下表的对照表上之后再谈买什么飞机。巡检对象典型现象影像表现推荐载荷识别手段新增违建楼顶加盖、彩钢棚新结构、高对比色块可见光变焦镜头语义分割历史影像差分暴露垃圾垃圾堆、渣土堆积不规整暗色斑块可见光目标检测占道经营路边摊群、堆物道路边界外聚集物可见光目标检测河湖漂浮物水面积聚绿藻、垃圾水面异常纹理可见光/多光谱语义分割夜间偷倒偏僻区域装卸渣土热源车灯热成像红外目标检测裸土扬尘工地未覆盖、黄土裸露大片黄褐色地表多光谱/可见光指数分割这张表的价值在于避免“一个模型识别所有问题”的陷阱。违建需要勾出轮廓边界垃圾只需要一个中心点河湖漂浮物又要求像素级面积三类任务对算法架构、标注成本、推理硬件的要求完全不同。先定类别再定算法才不会出现飞机买回来、照片拍了一大堆、算法却只能识别其中两类的情况。确定类别后还要给每个类别定义一个“最小目标尺寸”。比如暴露垃圾的最小对象按 0.8 米宽算河湖漂浮物按 1.5 米直径算夜间卡车按车头热源算。这个尺寸直接决定飞行高度、镜头焦距和单张照片覆盖范围比无人机续航参数重要得多。2.2 从最小地面分辨率反推飞行高度和镜头焦距城市巡检里最常用的是一个叫做地面分辨率 GSD 的参数意思是单个像素对应地面上多大的真实尺寸。公式不复杂GSD 传感器宽度 × 飞行高度 ÷焦距 × 图像宽度像素这里传感器宽度、焦距、图像宽度都是镜头与相机参数。举例一台常见的一英寸相机传感器宽度约 13.2 毫米焦距 8.8 毫米照片宽度 5472 像素飞行高度 100 米时GSD 约等于 2.74 厘米/像素。要识别 0.8 米宽的垃圾堆理想情况下目标长宽至少占 4 个像素这个 GSD 可以满足。如果把飞行高度拉高到 200 米GSD 翻倍一个 0.8 米的目标只占 2 个像素算法基本不可能稳定召回。所以选型顺序应该是先定最小目标尺寸再定 GSD再反推飞行高度最后看这个高度下航线和禁飞限高是否允许。我见过不止一个项目把顺序反过来买完长焦镜头才发现城市限高 120 米长焦视角太窄单张照片覆盖面积小巡检效率骤降。按照经验城市网格巡检的飞行高度控制在 80 到 100 米比较平衡不需要一味追求低空。2.3 数据链路设计实时回传、落盘上传、离线归档各管一段城市巡检的数据链路容易犯的毛病是把实时视频当成主力素材。实际落地时实时图传只解决两个问题一是飞手判断飞机状态二是应急任务里快速确认现场。所有用于算法分析、历史归档和争议定责的素材都应该来自机载存储卡里落盘的原始照片而不是被压缩编码过的图传视频。常见做法是飞机降落后自动将任务照片传到数据服务器按“任务ID/相机目录/照片编号”归档。照片的 EXIF 里带有拍摄时间、经纬度、高度、姿态角这些元数据是后面坐标计算、工单派发的依据。实时图传链路用 4G/5G 或专用遥控链路都行但带宽有限要做码率可调上传链路则要求高带宽和断点续传否则一个 600 张照片的任务传到一半断了重头再来会严重影响当天闭环。我的原则是原始照片永远先落盘识别结果作为派生数据存在后面出了问题还能回溯原始影像。3. 跑通一条最小可用链路航线规划、图像采集到告警推送的完整命令很多团队把城市巡检系统想成一个大平台一上来就规划用户管理、部门流转、数据大屏。真正落地时我建议先做一条极小的链路一条航线、一个网格、两个识别类别让它从任务开始自动跑到告警结束。跑通之后再谈扩展。3.1 最小闭环需要哪五个模块最小链路只需要五块内容任务规划、图像采集、自动上传、推理分析、告警生成。任务规划负责把网格变成航点和拍照动作图像采集由飞控和云台完成自动上传负责把落盘照片搬回服务器推理分析对每张照片跑模型告警生成把检测结果组装成一条带照片、带坐标、带类别的事件记录。技术选型可以全部用开源工具和少量脚本串联不急着买商业平台。地面站规划航线飞控执行拍照服务器上用 Python 监听目录推理模型用常见的目标检测框架告警通过 Webhook 推到即时通信或工单系统。下面给一段可以直接改参数跑起来的推理脚本前提是照片已经按任务落盘。3.2 照片推理与告警生成的最小 Python 实现import json from pathlib import Path from ultralytics import YOLO # 加载训练好的巡检模型类别名与训练时的 data.yaml 保持一致 model YOLO(weights/city_inspect_best.pt) # 只处理当天新落盘的照片避免任务还没飞完就开始推理 photo_dir Path(/data/mission/20240517) photo_list sorted(photo_dir.glob(*.JPG)) detections [] for photo in photo_list: result model.predict( sourcestr(photo), conf0.35, # 置信度阈值低了误报多高了漏报多 imgsz1280, # 推理尺寸过大会拖慢速度过小会丢小目标 device0, verboseFalse, )[0] for box in result.boxes: cls_id int(box.cls[0]) conf float(box.conf[0]) name model.names[cls_id] # 只推送有价值类别避免“车辆”这种全城都有的目标刷屏 if name in {illegal_building, trash_heap, bare_soil}: x1, y1, x2, y2 [float(v) for v in box.xyxy[0]] detections.append({ photo: photo.name, cls: name, conf: round(conf, 3), bbox_px: [round(x1), round(y1), round(x2), round(y2)], }) # 同一任务的多个检测点汇总成一批交给下游复核或生成工单 with open(detections.json, w, encodingutf-8) as f: json.dump(detections, f, ensure_asciiFalse, indent2) if detections: print(f发现 {len(detections)} 个疑似目标) else: print(本任务未发现预警目标)这段代码的重点不是模型本身而是输出结构。每个疑似目标都带着原始照片名、类别、置信度、像素坐标框这些东西足以让下游做两件事根据照片名去查 EXIF 经纬度按像素框中心计算目标的地理位置。参数里 conf 初始设为 0.35 比较合适如果业务上漏报影响更大就降到 0.25但收到的误报也会变多imgsz 用 1280 后城市航拍中的常见小目标基本不会丢但如果你的照片超过 4K建议先做滑窗切片而不是直接缩放整张图。3.3 航线和拍照参数怎么设参数推荐初值调节方向飞行高度80100m低于 50m 覆盖太窄高于 120m 小目标丢失旁向重叠率65%做正射建模时提高到 80%只识别可以降到 60%航向重叠率75%80%保证同一目标出现在多张照片中飞行速度58m/s过快导致运动模糊曝光时间不超过 1/2000 秒拍照模式定时等距拍照优先于航点触发航点触发在转弯处容易拍出半张图设置逻辑如果只做目标识别不建模重叠率可以低一些因为只要目标在任意一张照片里出现就行如果要拿历史影像对比违建变化则重叠率必须满足三维重建要求。飞行速度是被低估的一项。城市飞行中高楼遮挡造成 GPS 漂移飞控速度反而容易不稳我一般用 6m/s 配合 1/2000 秒快门既能保证效率又能稳住图像清晰度。4. 识别模型选型与数据准备小目标能发现才算合格无人机城市巡检的影像和普通监控视频有个显著差别视野大、目标小、背景杂。同样一个垃圾堆在路边监控里占整张画面的三分之一在 100 米高度航拍里可能只占十几个像素。模型选型和数据准备都要围绕这一点来。4.1 检测还是分割任务边界决定算法边界先说结论暴露垃圾、渣土堆、占道堆物这类对象识别位置即可用目标检测新增违建、河湖漂浮物、裸土这类需要算面积或边界的问题用语义分割想发现新增违建还得叠加历史影像差分单纯靠单张图片识别会分不清水箱和彩钢房。不要想着一个模型统一处理不然精度和迭代效率都会被拖垮。任务类型推荐模型架构输出部署成本暴露垃圾定位单阶段检测模型中心点包围框低违建轮廓勾画语义分割模型像素掩码多边形中河湖漂浮物面积语义分割模型像素掩码中夜间车辆识别单阶段检测模型包围框低实际项目中我会把算力需求高的分割任务放到服务器做只有实时性要求高的夜间偷倒检测放在机载或边缘端。城市网格任务通常是小时级闭环不需要过分追求端侧实时服务器 GPU 的性价比更高模型迭代也方便。4.2 用滑窗切片解决小目标漏检训练数据是城市巡检最容易忽视的环节。公开的航拍数据集覆盖的一般是车辆、建筑、船只很少专门标注垃圾堆和违建。因此大部分情况要自采数据、自标数据。自采时不要只飞正射视角还要飞一点 45 度斜拍因为违建和占道在斜视影像里特征更明显。标注完成后另一个问题是小目标。一张 4000×3000 的航拍图直接缩放到 1280 会让很多目标变成 3 像素模型根本学不到特征。常见做法是滑窗切片让训练样本里的目标保持原始尺寸。import cv2 import os def slice_image(src_path, dst_dir, tile1280, step960): os.makedirs(dst_dir, exist_okTrue) img cv2.imread(src_path) h, w img.shape[:2] idx 0 y 0 while y h - tile: x 0 while x w - tile: patch img[y:y tile, x:x tile] # step 小于 tile保留重叠区域 cv2.imwrite(os.path.join(dst_dir, f{idx:05d}.jpg), patch) x step idx 1 y step切片参数上tile 选 1280、step 选 960 意味着相邻切片有 25% 重叠目标即使正好骑在切片边界上也大概率在下一片里完整出现。如果目标平均边长只有 20 像素甚至可以考虑 tile 640、step 480效果更好但训练样本数量会增加不少。滑窗切片的格式要和标注工具配合不能先切完再手工标而是先用标注工具在原始大图上标一次再根据每个目标的像素坐标计算它属于哪个切片。4.3 部署调优置信度、NMS 与批大小模型训练完只是一个起点部署才是踩坑密集区。城市航拍图里存在大量误报常见来源是楼顶水箱、太阳能板、阴影边缘。这里我不会只调一个全局置信度因为调高了漏报调低了误报。正确做法是分类别设置阈值对建筑类目标conf 阈值给到 0.5因为误报代价高对垃圾堆conf 阈值给到 0.3因为允许稍多的误报再由人工复核漏检代价更高。模型部署到边缘盒子时还需要注意几个参数FP16 推理通常能保持精度且显著提高吞吐NMS 的 IoU 阈值可以从默认 0.45 调整到 0.6减少同一目标被重复框出的情况推理批大小设 4能压满 GPU 利用率但显存不够时会掉帧。显存占满了看 nvidia-smi先降 batch再降输入尺寸不要一上来就换轻量模型很多精度问题其实出在输入图像被压得太小。5. 城市巡检避坑排查从定位漂移到误报翻车的修正记录城市巡检项目从试飞到稳定运行一定会经历一段“每天都在处理告警”的阶段。这个阶段并不可怕可怕的是没有排查框架。我把最常见的问题整理成现象、原因、解决三个步骤照着对号入座能省下大量远程调试的时间。5.1 现象楼顶水箱和太阳能板被标成新增违建误报密集出现在楼顶设施的解决方案经常是“调高置信度阈值”但阈值调高后真实违建也跟着丢。原因很简单训练集里没有足够的历史合法设施样本模型只知道“楼顶多了东西就是违建”。解决方法是建立一张已登记合法设施的空间图层把水箱、电梯间、太阳能板的位置提前录入数据库推理结果出来后先做空间叠加过滤落在合法设施范围内的检测框直接降级为待人工确认。同时把水箱、太阳能板也加入训练数据作为负样本模型才能学会区分。5.2 现象告警工单位置与实际相隔 40 米这是城市巡检里最隐蔽的问题因为照片看起来完全正常点击地图落点却跑到了隔壁小区。原因通常是飞控使用的单点 GPS在高楼反射环境下出现几米到几十米的漂移而告警系统直接用照片 EXIF 里的经纬度生成坐标。解决方法是给巡检网格提前布设地面控制点再把每张照片的位置修正到控制点基准上。条件允许时上 RTK 或 PPK预算有限时至少做一个事后仿射校正用三个以上控制点换算出偏移量回填到检测结果里。坐标字段不要在算法层直接覆盖原始 EXIF应该保留原始值和修正值两列用于日后追溯。5.3 现象自动航线中途中断飞机悬停在路口上方航线中断在城市环境中经常遇到飞手在地面站看到的是“任务暂停”而不是明确原因。常见原因是城市更新后的临时限飞、限高区域没有被离线地图及时同步。解决方法是起飞前调用平台侧的航线校验接口把整个航点列表做一次合法性检查而不只是加载本地航线。校验接口返回不通过时自动跳过异常航段或提示飞手重新规划。另一个做法是把大网格拆成小任务段一个任务段失败不影响整个任务也能减少中断后重头再飞的窘况。5.4 现象地面站画面卡成幻灯片飞控数据却正常图传卡顿往往把责任推给网络但城市楼群环境里更多是无线信号遮挡和码率过高。现象特征是图传卡飞控的航线、高度、电池一切正常这就说明不是飞控问题。处理顺序是先让飞机提升高度打开天线跟踪方向然后把图传码率从 8Mbps 降到 4Mbps。如果任务不要求实时看画面干脆不用图传干预让自动任务继续飞完所有分析都回到落盘照片。实时画面在巡检里更多是心理依赖不是业务刚需。5.5 现象夜间出一次任务存储直接爆掉夜间巡检用红外相机时很多人习惯从起飞录到降落结果一晚上产生几百 GB 甚至上 TB 的视频文件。原因是没有事件触发录制策略。解决方法是设置“移动侦测录制”和“到达兴趣点后延迟录制”两种模式车辆和人员进入画面才开始保存平时只做低码率预览。红外视频统一用 H.265 编码码率控制在 6Mbps 以内同时记录每段视频的起始时间戳方便事后与飞行姿态数据对齐。数据量直接决定处理成本夜间任务的存储策略要提前定下来。6. 把识别结果做成闭环工单和验收报告一周试运行的量化验证系统最后能不能投运不看演示效果看一周试运行的数据。我的习惯是先把检测结果的结构固定下来再做量化指标验收。6.1 用统一的检测记录结构让任务、照片、工单串成一条线字段含义示例mission_id任务ID关联航线与批次M20240517-001photo_name原始照片文件名00123.JPGcls_id类别ID关联问题类型3confidence置信度0.87bbox_px像素坐标框[800, 600, 900, 700]lon_lat修正后经纬度116.37, 39.92raw_lon_lat原始EXIF经纬度116.38, 39.91status状态待复核/已确认/误报pending这张表可以作为所有系统模块的数据约定。工单模块只认这张表不直接读照片复核人员改状态后再把误报数据送回训练集。整个闭环里误报不是负担而是模型迭代最重要的原材料。6.2 一周试运行只看三个指标指标口径最低通过线查全率预埋测试目标中模型识别出来的比例80%误报密度每天每平方公里误报数小于 0.5闭环时长从照片落地到工单派发完成时长小于 10 分钟验收前在巡检网格内的人工布设测试点用涂色的板材模拟彩钢违建用固定大小的色块模拟暴露垃圾每天飞一次统计三天数据。查全率达不到时优先补数据误报密度超标题时优先加空间过滤规则闭环时长超时则排查上游脚本的串行等待。最后说一个个人习惯每次任务结束我都会导出复核不一致清单看看哪些检测框被业务方否决哪些是模型比人工更早发现的。一个无人机城市巡检系统从能飞到能用靠的就是这份清单的不断回填。希望帮到你。本文还有配套的精品资源点击获取
简介一套系统讲解无人机城市巡检建设的方案型PPT共59页重点面向智慧城市、自然资源、城管执法、交通环保等领域的方案规划与项目实施人员。资源包仅含1个PPTX文件压缩后约33.78MB内容按系统整体架构、大疆机场接入、AI算法库、管理后台、小程序工单闭环等模块展开。方案不仅说明由机场、算法、后台、小程序四部分组成的通用行业解决方案还结合Al变化检测与自动比对算法演示了房屋加建、土地监测、目标识别等真实场景并给出AI自动比对在准确率、时间成本上较人工巡查的量化优势。已有436人浏览学习适合作为智慧城市项目汇报、行业方案设计与无人机巡检业务培训的参考底稿能帮助读者快速把握平台组成、业务协同与落地路径。1. 无人机城市巡检系统真正要命的不是飞起来而是巡完怎么办拿到一份《无人机城市巡检系统》的59页PPT外行看到的是飞机、镜头和炫酷大屏内行看到的却是另一个问题发现一个疑似违建之后这张照片怎么变成有坐标、有对比、有责任人的工单再回到网格员手里去复核。城市巡检是典型的“飞得容易、巡得难”飞机可以按航线自动把照片拍回来真正的成本在图像与地理信息、业务流程的衔接。它适合县市级城管、园区、水务、住建等有明确巡查清单的甲方也适合准备把航测能力转化为巡检服务的集成商。这篇文章我从一个常年做落地项目的工程视角把方案拆成可执行的链路并告诉你哪些参数最值得调。2. 先把“巡什么”拆明白无人机、任务航线与数据链路的选型逻辑城市里能飞的东西很多但能纳入巡检的对象必须满足两个条件一是能用影像稳定发现二是发现了以后有人能处置。所以我做这类项目的第一步从来不是选无人机而是拿着需求方的巡查清单去对成像条件。需求方往往直接说“我们要发现所有问题”这句话无法翻译成算法必须拆成“目标类别、影像特征、业务处置动作”三要素否则后面选飞机、选镜头、建模型都会走偏。2.1 先建一张“巡检对象-现象-载荷-算法”对照表我一般会先和业务方开一次现象清单会最后落到一张类似下表的对照表上之后再谈买什么飞机。巡检对象典型现象影像表现推荐载荷识别手段新增违建楼顶加盖、彩钢棚新结构、高对比色块可见光变焦镜头语义分割历史影像差分暴露垃圾垃圾堆、渣土堆积不规整暗色斑块可见光目标检测占道经营路边摊群、堆物道路边界外聚集物可见光目标检测河湖漂浮物水面积聚绿藻、垃圾水面异常纹理可见光/多光谱语义分割夜间偷倒偏僻区域装卸渣土热源车灯热成像红外目标检测裸土扬尘工地未覆盖、黄土裸露大片黄褐色地表多光谱/可见光指数分割这张表的价值在于避免“一个模型识别所有问题”的陷阱。违建需要勾出轮廓边界垃圾只需要一个中心点河湖漂浮物又要求像素级面积三类任务对算法架构、标注成本、推理硬件的要求完全不同。先定类别再定算法才不会出现飞机买回来、照片拍了一大堆、算法却只能识别其中两类的情况。确定类别后还要给每个类别定义一个“最小目标尺寸”。比如暴露垃圾的最小对象按 0.8 米宽算河湖漂浮物按 1.5 米直径算夜间卡车按车头热源算。这个尺寸直接决定飞行高度、镜头焦距和单张照片覆盖范围比无人机续航参数重要得多。2.2 从最小地面分辨率反推飞行高度和镜头焦距城市巡检里最常用的是一个叫做地面分辨率 GSD 的参数意思是单个像素对应地面上多大的真实尺寸。公式不复杂GSD 传感器宽度 × 飞行高度 ÷焦距 × 图像宽度像素这里传感器宽度、焦距、图像宽度都是镜头与相机参数。举例一台常见的一英寸相机传感器宽度约 13.2 毫米焦距 8.8 毫米照片宽度 5472 像素飞行高度 100 米时GSD 约等于 2.74 厘米/像素。要识别 0.8 米宽的垃圾堆理想情况下目标长宽至少占 4 个像素这个 GSD 可以满足。如果把飞行高度拉高到 200 米GSD 翻倍一个 0.8 米的目标只占 2 个像素算法基本不可能稳定召回。所以选型顺序应该是先定最小目标尺寸再定 GSD再反推飞行高度最后看这个高度下航线和禁飞限高是否允许。我见过不止一个项目把顺序反过来买完长焦镜头才发现城市限高 120 米长焦视角太窄单张照片覆盖面积小巡检效率骤降。按照经验城市网格巡检的飞行高度控制在 80 到 100 米比较平衡不需要一味追求低空。2.3 数据链路设计实时回传、落盘上传、离线归档各管一段城市巡检的数据链路容易犯的毛病是把实时视频当成主力素材。实际落地时实时图传只解决两个问题一是飞手判断飞机状态二是应急任务里快速确认现场。所有用于算法分析、历史归档和争议定责的素材都应该来自机载存储卡里落盘的原始照片而不是被压缩编码过的图传视频。常见做法是飞机降落后自动将任务照片传到数据服务器按“任务ID/相机目录/照片编号”归档。照片的 EXIF 里带有拍摄时间、经纬度、高度、姿态角这些元数据是后面坐标计算、工单派发的依据。实时图传链路用 4G/5G 或专用遥控链路都行但带宽有限要做码率可调上传链路则要求高带宽和断点续传否则一个 600 张照片的任务传到一半断了重头再来会严重影响当天闭环。我的原则是原始照片永远先落盘识别结果作为派生数据存在后面出了问题还能回溯原始影像。3. 跑通一条最小可用链路航线规划、图像采集到告警推送的完整命令很多团队把城市巡检系统想成一个大平台一上来就规划用户管理、部门流转、数据大屏。真正落地时我建议先做一条极小的链路一条航线、一个网格、两个识别类别让它从任务开始自动跑到告警结束。跑通之后再谈扩展。3.1 最小闭环需要哪五个模块最小链路只需要五块内容任务规划、图像采集、自动上传、推理分析、告警生成。任务规划负责把网格变成航点和拍照动作图像采集由飞控和云台完成自动上传负责把落盘照片搬回服务器推理分析对每张照片跑模型告警生成把检测结果组装成一条带照片、带坐标、带类别的事件记录。技术选型可以全部用开源工具和少量脚本串联不急着买商业平台。地面站规划航线飞控执行拍照服务器上用 Python 监听目录推理模型用常见的目标检测框架告警通过 Webhook 推到即时通信或工单系统。下面给一段可以直接改参数跑起来的推理脚本前提是照片已经按任务落盘。3.2 照片推理与告警生成的最小 Python 实现import json from pathlib import Path from ultralytics import YOLO # 加载训练好的巡检模型类别名与训练时的 data.yaml 保持一致 model YOLO(weights/city_inspect_best.pt) # 只处理当天新落盘的照片避免任务还没飞完就开始推理 photo_dir Path(/data/mission/20240517) photo_list sorted(photo_dir.glob(*.JPG)) detections [] for photo in photo_list: result model.predict( sourcestr(photo), conf0.35, # 置信度阈值低了误报多高了漏报多 imgsz1280, # 推理尺寸过大会拖慢速度过小会丢小目标 device0, verboseFalse, )[0] for box in result.boxes: cls_id int(box.cls[0]) conf float(box.conf[0]) name model.names[cls_id] # 只推送有价值类别避免“车辆”这种全城都有的目标刷屏 if name in {illegal_building, trash_heap, bare_soil}: x1, y1, x2, y2 [float(v) for v in box.xyxy[0]] detections.append({ photo: photo.name, cls: name, conf: round(conf, 3), bbox_px: [round(x1), round(y1), round(x2), round(y2)], }) # 同一任务的多个检测点汇总成一批交给下游复核或生成工单 with open(detections.json, w, encodingutf-8) as f: json.dump(detections, f, ensure_asciiFalse, indent2) if detections: print(f发现 {len(detections)} 个疑似目标) else: print(本任务未发现预警目标)这段代码的重点不是模型本身而是输出结构。每个疑似目标都带着原始照片名、类别、置信度、像素坐标框这些东西足以让下游做两件事根据照片名去查 EXIF 经纬度按像素框中心计算目标的地理位置。参数里 conf 初始设为 0.35 比较合适如果业务上漏报影响更大就降到 0.25但收到的误报也会变多imgsz 用 1280 后城市航拍中的常见小目标基本不会丢但如果你的照片超过 4K建议先做滑窗切片而不是直接缩放整张图。3.3 航线和拍照参数怎么设参数推荐初值调节方向飞行高度80100m低于 50m 覆盖太窄高于 120m 小目标丢失旁向重叠率65%做正射建模时提高到 80%只识别可以降到 60%航向重叠率75%80%保证同一目标出现在多张照片中飞行速度58m/s过快导致运动模糊曝光时间不超过 1/2000 秒拍照模式定时等距拍照优先于航点触发航点触发在转弯处容易拍出半张图设置逻辑如果只做目标识别不建模重叠率可以低一些因为只要目标在任意一张照片里出现就行如果要拿历史影像对比违建变化则重叠率必须满足三维重建要求。飞行速度是被低估的一项。城市飞行中高楼遮挡造成 GPS 漂移飞控速度反而容易不稳我一般用 6m/s 配合 1/2000 秒快门既能保证效率又能稳住图像清晰度。4. 识别模型选型与数据准备小目标能发现才算合格无人机城市巡检的影像和普通监控视频有个显著差别视野大、目标小、背景杂。同样一个垃圾堆在路边监控里占整张画面的三分之一在 100 米高度航拍里可能只占十几个像素。模型选型和数据准备都要围绕这一点来。4.1 检测还是分割任务边界决定算法边界先说结论暴露垃圾、渣土堆、占道堆物这类对象识别位置即可用目标检测新增违建、河湖漂浮物、裸土这类需要算面积或边界的问题用语义分割想发现新增违建还得叠加历史影像差分单纯靠单张图片识别会分不清水箱和彩钢房。不要想着一个模型统一处理不然精度和迭代效率都会被拖垮。任务类型推荐模型架构输出部署成本暴露垃圾定位单阶段检测模型中心点包围框低违建轮廓勾画语义分割模型像素掩码多边形中河湖漂浮物面积语义分割模型像素掩码中夜间车辆识别单阶段检测模型包围框低实际项目中我会把算力需求高的分割任务放到服务器做只有实时性要求高的夜间偷倒检测放在机载或边缘端。城市网格任务通常是小时级闭环不需要过分追求端侧实时服务器 GPU 的性价比更高模型迭代也方便。4.2 用滑窗切片解决小目标漏检训练数据是城市巡检最容易忽视的环节。公开的航拍数据集覆盖的一般是车辆、建筑、船只很少专门标注垃圾堆和违建。因此大部分情况要自采数据、自标数据。自采时不要只飞正射视角还要飞一点 45 度斜拍因为违建和占道在斜视影像里特征更明显。标注完成后另一个问题是小目标。一张 4000×3000 的航拍图直接缩放到 1280 会让很多目标变成 3 像素模型根本学不到特征。常见做法是滑窗切片让训练样本里的目标保持原始尺寸。import cv2 import os def slice_image(src_path, dst_dir, tile1280, step960): os.makedirs(dst_dir, exist_okTrue) img cv2.imread(src_path) h, w img.shape[:2] idx 0 y 0 while y h - tile: x 0 while x w - tile: patch img[y:y tile, x:x tile] # step 小于 tile保留重叠区域 cv2.imwrite(os.path.join(dst_dir, f{idx:05d}.jpg), patch) x step idx 1 y step切片参数上tile 选 1280、step 选 960 意味着相邻切片有 25% 重叠目标即使正好骑在切片边界上也大概率在下一片里完整出现。如果目标平均边长只有 20 像素甚至可以考虑 tile 640、step 480效果更好但训练样本数量会增加不少。滑窗切片的格式要和标注工具配合不能先切完再手工标而是先用标注工具在原始大图上标一次再根据每个目标的像素坐标计算它属于哪个切片。4.3 部署调优置信度、NMS 与批大小模型训练完只是一个起点部署才是踩坑密集区。城市航拍图里存在大量误报常见来源是楼顶水箱、太阳能板、阴影边缘。这里我不会只调一个全局置信度因为调高了漏报调低了误报。正确做法是分类别设置阈值对建筑类目标conf 阈值给到 0.5因为误报代价高对垃圾堆conf 阈值给到 0.3因为允许稍多的误报再由人工复核漏检代价更高。模型部署到边缘盒子时还需要注意几个参数FP16 推理通常能保持精度且显著提高吞吐NMS 的 IoU 阈值可以从默认 0.45 调整到 0.6减少同一目标被重复框出的情况推理批大小设 4能压满 GPU 利用率但显存不够时会掉帧。显存占满了看 nvidia-smi先降 batch再降输入尺寸不要一上来就换轻量模型很多精度问题其实出在输入图像被压得太小。5. 城市巡检避坑排查从定位漂移到误报翻车的修正记录城市巡检项目从试飞到稳定运行一定会经历一段“每天都在处理告警”的阶段。这个阶段并不可怕可怕的是没有排查框架。我把最常见的问题整理成现象、原因、解决三个步骤照着对号入座能省下大量远程调试的时间。5.1 现象楼顶水箱和太阳能板被标成新增违建误报密集出现在楼顶设施的解决方案经常是“调高置信度阈值”但阈值调高后真实违建也跟着丢。原因很简单训练集里没有足够的历史合法设施样本模型只知道“楼顶多了东西就是违建”。解决方法是建立一张已登记合法设施的空间图层把水箱、电梯间、太阳能板的位置提前录入数据库推理结果出来后先做空间叠加过滤落在合法设施范围内的检测框直接降级为待人工确认。同时把水箱、太阳能板也加入训练数据作为负样本模型才能学会区分。5.2 现象告警工单位置与实际相隔 40 米这是城市巡检里最隐蔽的问题因为照片看起来完全正常点击地图落点却跑到了隔壁小区。原因通常是飞控使用的单点 GPS在高楼反射环境下出现几米到几十米的漂移而告警系统直接用照片 EXIF 里的经纬度生成坐标。解决方法是给巡检网格提前布设地面控制点再把每张照片的位置修正到控制点基准上。条件允许时上 RTK 或 PPK预算有限时至少做一个事后仿射校正用三个以上控制点换算出偏移量回填到检测结果里。坐标字段不要在算法层直接覆盖原始 EXIF应该保留原始值和修正值两列用于日后追溯。5.3 现象自动航线中途中断飞机悬停在路口上方航线中断在城市环境中经常遇到飞手在地面站看到的是“任务暂停”而不是明确原因。常见原因是城市更新后的临时限飞、限高区域没有被离线地图及时同步。解决方法是起飞前调用平台侧的航线校验接口把整个航点列表做一次合法性检查而不只是加载本地航线。校验接口返回不通过时自动跳过异常航段或提示飞手重新规划。另一个做法是把大网格拆成小任务段一个任务段失败不影响整个任务也能减少中断后重头再飞的窘况。5.4 现象地面站画面卡成幻灯片飞控数据却正常图传卡顿往往把责任推给网络但城市楼群环境里更多是无线信号遮挡和码率过高。现象特征是图传卡飞控的航线、高度、电池一切正常这就说明不是飞控问题。处理顺序是先让飞机提升高度打开天线跟踪方向然后把图传码率从 8Mbps 降到 4Mbps。如果任务不要求实时看画面干脆不用图传干预让自动任务继续飞完所有分析都回到落盘照片。实时画面在巡检里更多是心理依赖不是业务刚需。5.5 现象夜间出一次任务存储直接爆掉夜间巡检用红外相机时很多人习惯从起飞录到降落结果一晚上产生几百 GB 甚至上 TB 的视频文件。原因是没有事件触发录制策略。解决方法是设置“移动侦测录制”和“到达兴趣点后延迟录制”两种模式车辆和人员进入画面才开始保存平时只做低码率预览。红外视频统一用 H.265 编码码率控制在 6Mbps 以内同时记录每段视频的起始时间戳方便事后与飞行姿态数据对齐。数据量直接决定处理成本夜间任务的存储策略要提前定下来。6. 把识别结果做成闭环工单和验收报告一周试运行的量化验证系统最后能不能投运不看演示效果看一周试运行的数据。我的习惯是先把检测结果的结构固定下来再做量化指标验收。6.1 用统一的检测记录结构让任务、照片、工单串成一条线字段含义示例mission_id任务ID关联航线与批次M20240517-001photo_name原始照片文件名00123.JPGcls_id类别ID关联问题类型3confidence置信度0.87bbox_px像素坐标框[800, 600, 900, 700]lon_lat修正后经纬度116.37, 39.92raw_lon_lat原始EXIF经纬度116.38, 39.91status状态待复核/已确认/误报pending这张表可以作为所有系统模块的数据约定。工单模块只认这张表不直接读照片复核人员改状态后再把误报数据送回训练集。整个闭环里误报不是负担而是模型迭代最重要的原材料。6.2 一周试运行只看三个指标指标口径最低通过线查全率预埋测试目标中模型识别出来的比例80%误报密度每天每平方公里误报数小于 0.5闭环时长从照片落地到工单派发完成时长小于 10 分钟验收前在巡检网格内的人工布设测试点用涂色的板材模拟彩钢违建用固定大小的色块模拟暴露垃圾每天飞一次统计三天数据。查全率达不到时优先补数据误报密度超标题时优先加空间过滤规则闭环时长超时则排查上游脚本的串行等待。最后说一个个人习惯每次任务结束我都会导出复核不一致清单看看哪些检测框被业务方否决哪些是模型比人工更早发现的。一个无人机城市巡检系统从能飞到能用靠的就是这份清单的不断回填。希望帮到你。本文还有配套的精品资源点击获取
