★ FEATURED ARTICLE 1. 河道巡检为什么需要无人机图像识别1.1 从人工巡河到智能识别的现实痛点我最早接触河道垃圾巡检这个场景是因为一个做水利信息化的朋友找我帮忙。他们单位负责一段大约40公里的河道过去巡河的方式很传统两个人一组沿着河堤开车加步行看到垃圾就拍照记录回来再整理成表格上报。一趟下来大半天遇到汛期或者河道两侧没有通路的地段基本靠肉眼远距离判断漏检是常态。这个场景的核心痛点其实有三个。第一是覆盖效率低人工巡河受地形和交通限制很多河湾、滩涂、桥墩背面根本走不到。第二是判定标准不统一同样一堆漂浮物老张觉得是垃圾要上报老李觉得是水草不用管数据没法沉淀。第三是响应滞后等巡河人员发现并上报垃圾可能已经顺流漂走或者沉底了。无人机介入之后前两个问题解决得很直接飞行覆盖半径大、视角统一、影像可回溯。但第三个问题——也就是识别这一环——才是真正决定这套系统能不能落地的关键。拍回来几百张照片如果还要靠人一张张看那只是把走路巡河变成了坐着看图效率提升有限。所以无人机河道垃圾图像识别这件事本质上是把采集和判定两个环节都自动化让巡河人员从重复劳动里解放出来只处理系统标记出来的疑似目标。这套东西适合谁来参考我梳理了一下主要是三类人一是做智慧水利、环保信息化的工程技术人员需要一套可落地的技术方案二是高校里做无人机视觉、遥感识别方向的学生和研究者需要真实的场景和数据思路三是有无人机但不知道怎么把航拍数据用起来的行业从业者比如河道管理、环卫外包公司的技术负责人。不管你是哪一类下面这套从架构到落地的思路都能直接拿去改。1.2 图像识别在河道场景里到底识别什么很多人一上来就说我要做垃圾识别但真到标注数据的时候才发现垃圾这个词太模糊了。我在实际项目里把河道垃圾分成了几个可操作的类别这个分类直接决定了后面模型怎么设计、数据集怎么标。第一类是水面漂浮物包括塑料瓶、泡沫块、塑料袋、纸箱这类密度小、浮在水面的东西。这类目标的特点是颜色和纹理跟水面差异明显识别难度相对低但受光照和反光影响大。第二类是岸边堆积物比如建筑垃圾、生活垃圾堆、枯枝杂草堆。这类目标往往和河岸的泥土、植被颜色接近边界模糊是识别里的难点。第三类是水生植物异常聚集比如大面积水葫芦、浮萍。严格说这不算垃圾但在河道管理里属于需要预警的对象因为过度繁殖会影响水质和行洪。这类目标面积大、纹理重复用传统的目标检测框反而不好使更适合用语义分割来做。第四类是疑似排污口或异常色块水面出现不正常的颜色变化可能是偷排的迹象。这类不是物体而是区域异常处理逻辑和前几类完全不同。提示分类不要贪多。我见过一个项目一开始定了十几个细分类别结果标注成本爆炸模型精度还上不去。建议先做三到四个大类跑通闭环之后再细分。把识别对象定义清楚之后整个技术架构的轮廓就出来了无人机负责采集图像识别负责判定中间还需要一套数据流转和结果呈现的机制。这就是下一节要拆的架构问题。2. 整套系统的技术架构怎么搭2.1 四层架构的划分逻辑我习惯把这类系统拆成四层采集层、传输层、识别层、应用层。这个划分不是为了好看而是因为每一层的技术选型和故障模式都不一样分开之后排查问题和迭代升级都清晰。采集层就是无人机平台本身包括机身、云台相机、飞控。这一层决定了你能拿到什么质量的原始数据。传输层负责把数据从现场搬到算力所在的地方可以是实时图传也可以是降落后批量导出。识别层是核心跑图像识别算法输出结构化结果。应用层把结果变成人能看懂、能用的东西比如地图标注、报表、告警推送。为什么这么分因为实际项目里最常见的扯皮就是识别不准但问题可能出在采集层——照片本身就模糊、过曝、角度太斜算法再强也救不回来。分层之后你可以逐层验证先看原始影像质量再看传输有没有丢帧最后才怀疑算法。2.2 采集层无人机平台与载荷选型采集层里最关键的决策是飞什么平台、挂什么相机、飞多高。这三个参数互相牵制得一起考虑。平台方面河道巡检一般用多旋翼因为需要低空慢速、定点悬停、沿河道曲折飞行。固定翼速度快、航时长但转弯半径大不适合贴着河道来回扫。我参与过的项目里用得比较多的是四轴和六轴载重不需要太大但要求续航稳定、抗风能力够。如果河道比较宽、单次覆盖面积大可以考虑垂直起降固定翼兼顾航时和起降便利。相机选型上可见光相机是标配但要注意两个参数地面分辨率GSD和视场角。GSD决定了你能看清多小的垃圾。假设相机像素是2000万传感器宽度是13.2毫米飞行高度100米镜头焦距8.8毫米那么GSD (飞行高度 × 传感器宽度) / (焦距 × 图像宽度像素数) (100 × 13.2) / (8.8 × 5472) ≈ 0.027 米/像素也就是每个像素对应地面约2.7厘米。一个矿泉水瓶直径大概6到7厘米在图像上就是2到3个像素勉强能看出是个点但识别难度很大。所以如果目标是识别小件垃圾飞行高度要压到50米甚至更低或者换更长焦距的镜头。这个计算过程在实际选型时一定要做不能拍脑袋定高度。注意飞得越低单张覆盖面积越小同样的河道长度需要更多航线和更多照片作业时间和数据量都会上升。这是一个典型的效率与精度的权衡需要根据实际识别目标的最小尺寸来反推。2.3 传输层与识别层的部署位置选择传输和识别这两层核心问题是算力放在哪。有三种典型方案我列个表对比一下。方案算力位置优点缺点适用场景机载实时识别无人机上实时出结果无需传大图算力受限模型要压缩应急巡查、小范围边缘端识别地面站/边缘盒子平衡算力和实时性需要现场部署设备固定河段日常巡检云端批量识别服务器/云算力充足模型可大有传输延迟依赖网络大范围、非实时我个人的经验是日常巡检用边缘端或云端批量处理更划算因为河道垃圾不是需要秒级响应的场景晚半小时出结果完全可以接受。而机载实时识别更适合应急场景比如突发污染事件需要边飞边看。这里要提一句机载识别对模型压缩要求很高。你不可能把一个大模型塞进无人机的计算模块里得用量化、剪枝、知识蒸馏这些手段把模型压到几十兆甚至几兆。这个过程会损失精度所以要评估损失是否可接受。2.4 应用层结果怎么变成可用的信息识别层输出的是某张图里有几个垃圾框、分别在哪但巡河人员要的不是这个。他们要的是哪一段河道有垃圾、什么类型、大概多少、优先级如何。所以应用层要做的是把图像坐标映射到地理坐标再聚合成河段级别的信息。这里涉及一个关键步骤正射拼接与地理配准。无人机拍的照片自带POS信息位置和姿态通过摄影测量软件可以拼成正射影像图每张照片的像素坐标就能换算成经纬度。垃圾框的位置也就落到了地图上。这一步不做识别结果就是一堆孤立的图片没法跟河道管理业务对接。应用层通常还要做几件事按河段统计垃圾数量和类型分布、生成巡检报告、对超过阈值的河段推送告警、把历史数据存起来做趋势分析。这些功能不复杂但决定了这套系统是能用还是好用。3. 图像识别算法的核心细节与实操要点3.1 目标检测与语义分割怎么选河道垃圾识别主要用两类算法目标检测和语义分割。选哪个取决于你要识别的对象形态。目标检测比如YOLO系列、Faster R-CNN输出的是矩形框适合识别独立、边界清晰的物体比如漂浮的塑料瓶、泡沫块。它的优势是速度快、标注成本相对低一张图框几个框就行。语义分割比如U-Net、DeepLab系列输出的是像素级分类适合识别面积大、形状不规则的区域比如水葫芦聚集区、岸边垃圾带。它的优势是能精确勾勒边界但标注成本高要一个像素一个像素地涂。我的建议是两者结合用目标检测处理独立漂浮物用语义分割处理大面积异常区域。实际项目里我也见过只用目标检测硬扛所有类别的结果大面积水葫芦被框成一堆重叠的框后处理非常麻烦。3.2 数据集构建河道垃圾数据从哪来这是整个项目里最费劲、也最容易被低估的环节。公开的垃圾识别数据集不少但专门针对河道场景的很少直接拿来用效果往往不好因为河道的水面反光、岸边植被、光照条件跟通用数据集差异太大。数据来源我总结了几条路。第一条是自采用无人机在目标河段按不同高度、不同光照、不同季节飞几轮这是最贴合实际的数据。第二条是公开航拍数据集筛选有些通用的无人机航拍数据集里能挑出河道相关的图像但需要人工清洗。第三条是数据增强扩充通过旋转、翻转、亮度调整、加噪声、模拟水面反光等方式把小样本扩成可训练的规模。标注方面我强烈建议用半自动标注加人工修正的流程。先用一个预训练模型跑一遍生成初始标注人工只做增删改比从零画框快好几倍。标注规范要提前定死什么算一个目标、遮挡怎么处理、边界模糊的算不算、最小标注尺寸是多少。这些规则不统一后面模型怎么调都上不去。实操心得标注团队一定要给困难样本单独建一个文件夹。那些模棱两可、大家意见不一致的图单独拿出来讨论定标准否则标注质量会随着时间漂移。3.3 模型训练的关键参数与调优思路训练这块我把几个关键点拎出来说。输入分辨率。河道垃圾在图像里往往很小输入分辨率太低小目标直接糊没了。我一般会把输入尺寸设到640甚至1280代价是显存占用和推理时间上升。如果用小目标检测的改进方法比如切片推理把大图切成小块分别检测再合并可以在不显著增加单次推理成本的前提下提升小目标召回。数据增强策略。除了常规的翻转旋转河道场景要特别加两类增强一是光照模拟模拟阴天、逆光、水面强反光二是水面纹理扰动让模型不要过度依赖水面波纹这种无关特征。这两类增强对实际泛化帮助很大。损失函数与正负样本平衡。垃圾目标在整张图里占比很小正负样本极度不平衡。常用的做法是调整分类损失的权重或者用Focal Loss这类专门处理不平衡的损失。我实测下来单纯调权重比换损失函数更省事效果也够用。评价指标。别只看mAP河道场景我更关注召回率。漏检一个垃圾堆的代价比误检几个假目标高得多。所以调参时我会优先保证召回允许一定的误检后面再用规则或二次分类过滤。3.4 推理部署的性能优化模型训练完只是第一步部署到实际环境还要过性能这关。几个常用手段模型量化把浮点权重转成低精度模型体积和推理时间都能降下来精度损失通常在可接受范围。TensorRT或类似推理加速针对特定硬件做图优化和算子融合速度提升明显。批处理与异步批量推理比单张推理吞吐高配合异步IO能充分利用算力。分辨率自适应不是所有图都需要高分辨率可以先低分辨率粗筛可疑区域再高分辨率精检。我踩过的一个坑是训练时用的是高分辨率部署时为了速度降到低分辨率结果小目标全丢了。后来改成两级推理粗筛加精检才把速度和精度都保住。4. 从飞行到出报告的完整实操流程4.1 航线规划与飞行参数设定实操第一步是规划航线。河道巡检的航线一般是沿河道中心线或岸线做往复式扫描保证相邻航线有足够的重叠率。重叠率我一般设航向70%、旁向60%太低会漏拍太高数据量爆炸。飞行高度根据前面算的GSD反推。如果目标是识别直径10厘米以上的垃圾GSD至少要优于3厘米对应飞行高度大概在80到100米。如果河道窄、目标小可以降到50米。飞行速度也有讲究。太快会导致运动模糊尤其光线不足时。我一般控制在每秒3到5米光线好可以快一点阴天就慢下来。相机快门速度要跟飞行速度匹配保证单张清晰。注意河道上方常有桥梁、电线、树木航线规划时一定要做障碍物检查。我见过一次飞行直接撞上跨河电线机器掉水里损失惨重。现在每次飞之前都会用地图工具把障碍物标出来航线绕开。4.2 数据回传与预处理飞行结束后数据回传有两种方式现场用读卡器导出或者通过地面站无线回传。大范围作业建议现场导出无线回传几百GB数据不现实。预处理包括几步去重相邻照片重叠度高可以按距离抽帧、质量筛选剔除模糊、过曝、欠曝的图、地理配准把照片和POS信息对齐、正射拼接生成整段河道的正射影像。这几步做完数据才具备进入识别环节的条件。质量筛选这一步很多人省掉结果一堆废片进模型识别结果乱七八糟。我一般会用一个简单的清晰度指标比如拉普拉斯方差自动筛一遍再人工抽查。4.3 识别执行与结果后处理识别执行就是把预处理后的图像送进模型输出检测框或分割掩码。这一步本身不复杂关键是后处理。后处理包括置信度过滤低于阈值的框丢掉、非极大值抑制去掉重叠的重复框、类别合并把细分类别归并成大类、地理映射把像素坐标转成经纬度、聚类聚合把相邻的检测结果合并成一个垃圾点避免同一堆垃圾被重复计数。我特别想强调聚类聚合这一步。同一堆垃圾在连续几张照片里都会出现如果不做聚合统计数量会严重虚高。我一般按地理距离聚类比如50米范围内的同类检测合并成一个事件。4.4 报告生成与业务对接最后一步是把结果变成业务能用的东西。通常包括地图标注在河道地图上标出垃圾位置和类型、统计报表按河段、按类型、按时间统计、告警推送超过阈值的河段通知负责人、历史归档存起来做趋势分析。这一步的技术难度不高但很考验对业务的理解。比如告警阈值定多少、报表按什么维度统计、推送给谁这些都要跟一线人员反复确认。我见过技术做得很漂亮但业务不用的系统问题就出在这一步没对接好。5. 常见问题与排查技巧实录5.1 识别不准的排查思路识别不准是最常见的问题但原因可能有很多层。我一般按这个顺序排查现象可能原因排查方法解决方向小目标漏检多分辨率不足/模型对小目标弱看漏检目标的像素尺寸提高输入分辨率/切片推理误检多训练数据负样本不足看误检目标像什么补充负样本/加后处理规则特定光照下失效训练数据光照单一按光照条件分组看指标补充对应光照数据/增强岸边目标识别差背景干扰强看岸边样本占比增加岸边样本/分割预处理同一目标重复计数未做地理聚合看连续帧检测结果加聚类聚合后处理这个表是我实际排查时总结的基本覆盖了八成以上的问题。核心思路是先定位问题出在哪一层再针对性解决不要一上来就调模型。5.2 飞行与数据采集的避坑经验采集环节的坑往往比算法环节更致命因为数据废了后面全白搭。几个我踩过的反光问题晴天正午水面反光严重照片上一片白垃圾全看不见。解决办法是避开正午飞行或者加偏振镜。运动模糊飞行速度快加快门慢照片糊。要么降速要么提高快门要么两者都调。重叠不足航线间距太大正射拼接出现空洞。规划时一定要算好重叠率。POS精度差无人机自带GPS精度有限地理配准会有偏差。要求高的话需要地面控制点。实操心得每次飞行前先试飞一小段回来看数据质量再决定要不要调整参数。别一上来就飞全程废一次就是半天。5.3 模型泛化与季节变化的应对河道场景有个特殊问题季节变化极大。夏天水草茂盛、水面反光强冬天水面平静、岸边枯黄同一个模型在不同季节表现可能差很多。应对办法有几个。一是分季节建模不同季节用不同模型或不同阈值。二是持续学习把新季节的数据持续加进训练集定期更新模型。三是域适应用一些迁移学习的方法让模型适应新分布。我实际用下来持续学习最省心但要有数据回流机制保证新数据能定期进训练流程。5.4 系统落地时的工程问题最后说几个工程层面的坑。算力成本如果全用云端GPU跑大范围高频巡检的费用不低要算清楚账。数据存储航拍数据量很大一次飞行几十GB长期积累要考虑存储方案。网络依赖如果识别放在云端现场网络不好会卡住整个流程要有离线兜底方案。维护成本模型不是一劳永逸的河道环境会变要预留持续迭代的人力和预算。我在实际项目里最大的体会是这套系统的难点不在算法而在工程闭环。算法可以调但数据采集、传输、存储、业务对接这些环节任何一个掉链子整个系统就跑不起来。所以做这类项目一定要有全局视角别一头扎进模型里出不来。最后分享一个我觉得很实用的小技巧先用最简单的方案跑通全流程再逐步优化每个环节。我见过太多项目一上来就追求高精度模型、实时推理、全自动闭环结果卡在某个环节迟迟出不来成果。先用一个能跑的模型、一个能看的报告把从飞行到出结果的链路打通哪怕精度只有六成也比一个永远在调优的完美方案有价值。跑通之后你才知道瓶颈到底在哪优化才有方向。
阅读完成 · 觉得有帮助？
