无人机巡检里的人和车很多团队做了一年多最后发现做的是无人机识别人车不是人车追踪。这两者差别有多大这么说吧识别只回答画面里有没有人和车而追踪要回答这几个人和车从哪里来、要往哪去、在某个重点区域停了多久、是不是同一个目标。巡检场景里你需要的是后者但大多数方案实际上只做到了前者。这篇文章我打算把整个技术链路从头到尾捋一遍。我不会只讲算法选型还会把机载算力选型、数据标注细节、模型训练的坑、追踪模块的工程优化、后台GIS联动以及数据闭环这套东西全部串起来。如果你正准备做无人机巡检中的人车追踪或者已经在做但效果总是不理想这篇文章应该能帮你少走不少弯路。1. 为什么巡检场景里的人车追踪会那么难落地先说一个很多项目里都会出现的怪现象算法在测试集上跑mAP看着不错Demo视频效果也还行一旦装上无人机真正去飞问题全冒出来了——人车漏检、ID频繁跳变、背景里的影子被当成车、飞过一片树林后目标对不上号。这不是算法不行而是整个系统在设计的时候就把问题想简单了。我习惯把巡检里的人车追踪拆成三个层次去看每一层都有自己典型的翻车方式。第一层是检测也就是单帧图像里找到人和车。这一层在公开数据集上已经做得比较成熟但巡检场景有自己的特殊性无人机在几十米到上百米的高度往下看人可能就是十几个像素到几十个像素的小目标车的尺寸稍大但视角是俯视跟日常行车记录仪里的侧视视角完全不同。第二层是关联也就是把连续帧中属于同一个人的框串起来。这一层最有迷惑性因为目标数量少时看起来没什么难度一旦动作乱了——比如人走到树底下被完全遮挡再出来时换了个方向——关联就很容易断。而且无人机本身在动云台又在转画面里的背景每帧都在流过去这种相机不动的隐式假设根本不成立。第三层是业务语义也就是把追踪得到的轨迹放到具体巡检业务里去理解。这条轨迹是不是进入了禁入区域是不是在高压线塔下停留太久是不是沿公路朝向某个设施移动这一层直接决定了系统的价值但绝大多数技术方案根本走不到这一步因为它们在前两层就已经把置信度和ID搞乱了。还有一个客观现实的困难是无人机巡检的视角是高度动态的。飞手水平不同、飞航线时风速不同、云台俯仰角不同导致画面里目标尺度变化范围极大。同一个行人在航线起点可能占一百多个像素飞高了以后缩到二三十个像素这种尺度跨度对检测器的鲁棒性要求非常高。所以我现在做方案评审时会先问三个问题你们有没有针对俯视小目标做过专门的训练数据追踪模块有没有考虑无人机自身运动补偿轨迹数据最终有没有落到地理坐标上去三个都答不上来的基本还是停留在识别Demo阶段离追踪系统还差得远。2. 机载算力与相机配置追踪方案在硬件选型上的现实约束算法逻辑再漂亮最后都要跑在一台具体的设备上。人车追踪系统设计中最容易被低估的坑就是算力平台和相机配置的相互约束。我先说结论这套系统的性能上限往往在选硬件的那一天就定下来了。2.1 算力平台的选型逻辑目前巡检行业里做机载端AI最常见的选择是NVIDIA的嵌入式平台比如Jetson Orin系列也有人用一些国产NPU方案或者Intel平台的边缘盒子。选型时我重点看四个指标总算力、功耗、内存带宽、SDK成熟度。我个人的经验是人车追踪这种任务对内存带宽非常敏感。追踪模块里要做特征匹配、卡尔曼滤波、匈牙利算法这些操作的访存密度比单纯跑CNN模型高不少。有的平台标称INT8算力很高但实际跑起检测加追踪的完整流程帧率掉得厉害瓶颈往往就在带宽上。这里给一个可以参考的配置思路入门级单路1080P视频目标数量少选算力50TOPS左右的中端平台用YOLOv8s配合ByteTrack实测能稳定在15-20FPS。进阶级双光相机同时处理可见光和红外目标数量可能达到几十个选更高端平台模型可以上YOLOv8m配合TensorRT加速帧率能保住20FPS以上。项目制方案如果追求极致帧率还可以考虑把检测放到机载端做追踪放到地面站服务器做通过图传链路传回关键帧但这样对链路稳定性要求很高后面我在部署部分会细说。很多团队一上来就买最大的算力板卡理由是以后总会用得上。这个思路在巡检项目里不太划算因为无人机对重量和功耗极其敏感。算力板卡越大散热和供电压力越大整机续航就会缩水。续航缩水的直接后果是巡检覆盖面积变小追踪任务能持续的时间变短很多时候还没追明白就没电了。2.2 相机参数对追踪效果的影响追踪效果好不好源头在相机。项目里经常出现的情况是算法团队抱怨目标太小了检测不到但真正的问题其实是相机的有效探测距离不够。选相机时我建议关注三个参数传感器靶面尺寸靶面越大同样分辨率下单像素感光面积越大弱光和动态拖影表现越好。巡检场景尤其是傍晚和清晨时段这个参数比分辨率还重要。镜头焦距焦距决定了同样飞行高度下单个目标的像素尺寸。做人车追踪建议至少保证在最大飞行高度时人的目标尺寸不低于25x25像素。这个可以用公式提前算不用等装上飞机试飞时才发现。帧率与曝光时间帧率低于15FPS时车辆这类快速移动目标的帧间位移会非常大追踪匹配会变得很困难。曝光时间太长运动会带来严重的运动模糊小目标直接糊成一团。我见过一套方案用的相机传感器比较小飞行高度一超过80米人的检出率就断崖式下跌。后来换了一台大靶面长焦镜头的光学负载同样飞行高度下人的像素尺寸提升了两倍多检测和追踪效果都明显好转。所以说有些问题看起来是算法问题实际是光学问题。3. 训练数据的秘密俯视小目标的人车检测要解决的不只是尺度模型这块YOLO系列基本是巡检行业的事实标准。我见过用更重的检测网络去追求精度的但在嵌入式平台上一跑帧率掉到个位数实用性大打折扣。YOLO系在精度和速度的平衡上做得确实比较适合这个场景。但真正决定检测器性能上限的还不是网络结构而是训练数据。无人机俯视视角的人车数据跟公开的通用目标检测数据集差距非常大谁提前意识到这一点谁就能在效果上拉开差距。3.1 俯视视角带来的标注难题俯视视角下人的外观特征和水平视角完全不同。你能看到的是头顶、肩膀、头盔而不是正脸车辆看到的是车顶、天窗、机盖上的线条而不是车牌和车灯。这导致直接在通用预训练模型上微调收敛速度和精度都受影响不如从数据侧彻底改造。标注环节最典型的两个问题一个是小目标标注框普遍偏大。标注员在屏幕上看到一个小点顺手就画了一个比目标实际轮廓大几倍的框。这种噪声对检测器训练非常有害。我的办法是让标注员严格贴着目标轮廓标注同时对小于一定像素的目标允许只标一个点再用程序自动生成固定尺寸的框。另一个是漏标率高。画面里人车密集时标注员很容易漏掉角落里的目标。漏标的目标在训练时会被当成背景模型学到的是看到人也要抑制响应这是小目标检测效果上不去的隐形杀手。我现在的做法是标注完之后加一道质检环节用一个大而全的检测模型先预标注一遍再把大模型的检测结果以半透明框叠加到原图上让标注员重点检查那些模型觉得有、标签里没有的区域到底是漏标还是真背景。3.2 针对小目标的训练策略小目标检测的常规打法无非是几条路提高输入分辨率、使用多尺度训练、引入P2特征层、对图像进行切块训练。巡检场景里我最常用的是高分辨率输入配合适当切图。切图的做法是把原始大图切分成多个有重叠的Tile每个Tile单独送进模型推理后再把检测结果合并回原图坐标。这样相当于在不大幅增加全局分辨率的前提下放大了小目标在模型输入里的占比。实测下来对于二三十像素的行人目标切图训练加推理带来的提升非常明显代价是计算量成倍增加。所以在工程实现上我习惯做成动态策略飞行高度低、目标像素大时跑全图检测飞行高度高、目标偏小时自动切图。这个逻辑可以在飞控航线上提前规划好。还有一个细节是训练时不要忽略背景多样性。巡检场景飞过农田、树林、水域、建筑区每种背景下的虚警分布差异很大。有段时间我们的模型在草地上空跑总是把一些纹理复杂的区域判断成人就是因为训练数据里草地样本太少。后来有针对性地补充了大量农田和灌木背景的负样本虚警率降了一大截。3.3 模型部署中的精度与速度取舍训练收敛后的模型不能直接拿来部署。嵌入式平台一般要做TensorRT或者同类推理框架的转换FP16精度通常是性价比最高的选择INT8量化能再提速但需要准备校准数据集而且小目标对量化误差更敏感一个不小心精度就崩了。如果检测精度和推理速度冲突我宁可牺牲一点速度也要保住检测精度。道理很简单追踪是建立在检测质量上的检测漏一个目标追踪再厉害也追不回来。但在帧率低于某个底线时追踪算法会因为帧间位移过大而失效这个底线需要实际测试确定不同平台差异很大。4. 追踪模块的工程优化从Demo到上机的三个硬骨头检测模型能稳定检出人和车之后真正的追踪工程才算开始。我把这一阶段的问题概括成三个硬骨头相机自身运动、目标被遮挡、轨迹抖动。这三件事任何一个处理不好整个追踪系统看起来就没法用。4.1 用运动补偿对抗无人机自身运动普通监控摄像头是固定的背景不动目标移动追踪算法可以假设背景静止。无人机不一样机体前行、云台转动、风速导致的飘移全都叠加在背景运动上。如果不做任何处理画面里每个局部区域都在移动纯靠检测框之间的IoU来关联目标很容易在同一帧里匹配错对象。我常用的规避方案是云台IMU数据辅助。现在工业级无人机云台都带IMU能把每一帧的相机姿态记录传出来。利用相机姿态信息可以把上一帧的检测框转换到当前帧的坐标系这样即使在云台快速旋转时检测框的预测位置也不会产生系统偏移。没有IMU数据可用的平台退而求其次可以用图像配准。方法是每帧提取ORB或者使用ECC配准算法估算背景的仿射变换然后把上一帧目标框按这个变换投影到当前帧。算力开销不小但总比追踪乱跳好。4.2 为什么ByteTrack往往比DeepSORT更适配巡检追踪算法选型上DeepSORT曾经是主流但我在多个实际项目里对比下来ByteTrack在很多场景下比DeepSORT更适合无人机巡检。原因在于它们对低置信度检测框的处理逻辑完全不同。DeepSORT只保留高于某个置信度阈值的检测结果低置信度的直接丢弃。可巡检场景里远距离的小目标、被树冠遮挡一半的目标、运动模糊的目标检测置信度天然偏低。这些目标在DeepSORT里第一帧就被放弃了追踪链路根本建立不起来。ByteTrack核心思路是让高置信度和低置信度框都有用武之地高置信度框用来做主要关联低置信度框通过IoU跟已有的轨迹做匹配保住那些检测器不确定但确实是目标的对象。实测下来ByteTrack在无人机俯视场景里能多保持很多段完整度更高的轨迹ID Switch的数量也少得多。4.3 遮挡、出视野和航迹去抖人车追踪里最麻烦的情况是目标被遮挡后重新出现。无人机视角下的遮挡跟地面监控不一样——地面监控里目标被墙、车或行人挡住无人机视角下目标被树冠、桥梁、高压铁塔或无人机自身大幅运动出视野遮挡。应对遮挡的思路是预测加外推。目标进遮挡之前把它的运动状态位置、速度、方向记录好然后按照运动模型持续外推位置并降低匹配优先级但不直接删除轨迹。当目标在预期恢复区域重新出现时优先把新检测框关联回这条待定轨迹。但这里有个经验教训外推时间一定要有上限。我之前给一个项目设过比较长的外推窗口目标丢了之后轨迹在空中乱飘后台告警系统还把这段幽灵轨迹当成有效目标产生了一堆误报。后来做法调整为外推超过3秒没有匹配到新检测就分档处理——短时间的丢判为临时遮挡长时间没有任何证据的直接杀掉轨迹并标记疑似丢失等后台人工复核。航迹去抖也是一个大家容易忽视的地方。因为检测框每帧会有波动目标的车速、朝向等指标如果直接用相邻帧的框位置计算噪声会非常吓人。我通常的做法是把轨迹点做一次低通滤波或者用一个滑动窗口拟合轨迹窗口内做平滑然后再计算速度和运动方向。别小看这一步它直接决定了后续GIS叠加时轨迹画出来是干净利落的一条线还是满屏乱刺的一堆毛线。5. 从实验室到常态化巡检部署形式与后台系统的协同追踪算法在实验室跑通了只完成了三分之一的工作。真正让系统在巡查作业里能用的关键是把机载实时分析、地面站接报、后台GIS联动这条链路完整打通。这一部分是项目落地时最繁琐、最难通用的但也是甲方真正为价值买单的部分。5.1 机载端与地面端的任务切分我比较推荐的部署形态是机载端实时检测追踪地面端二次分析。所有视频流先在机载端以帧率运行检测和追踪生成目标的轨迹坐标和置信度序列但不会把每一帧目标画面都传输下来一方面链路带宽受限另一方面后台也没必要处理那么多冗余信息。机载端只需要在满足触发条件时向地面站推送信息目标进入了预设的重点区域、目标轨迹ID发生跳变、目标检测置信度连续一段时间低于阈值以及用户自定义的其他事件。地面站收到事件后可以从视频流中调取对应时间段的关键帧和一段短视频供调度人员确认。这套设计的好处是带宽需求小而且把机器初筛和人工复核放在各自擅长的地方。机器擅长的是不知疲倦地盯画面但面对复杂语义时误报率高人擅长的是理解上下文但没法持续几分钟盯住一块屏幕。任务切分就是让两边各做各擅长的部分。5.2 轨迹必须落回地理坐标飞手在屏幕上看到的是一条轨迹线但在调度中心的大屏上这条路迹必须叠加在GIS地图和航拍底图上才有业务意义。这意味着每一帧的追踪结果都要与无人机实时POS数据经纬度、高度、云台姿态、相机内参做投影变换把像素坐标映射成地理坐标。这里最大的坑是坐标映射的精度。无人机在飞行中姿态持续变化如果直接拿无人机的机头朝向当作相机光轴方向误差可能达到几十米甚至上百米。正确做法是使用云台回传姿态结合相机畸变参数做一个完整的共线方程解算复杂但可靠。映射完成后你就可以在地图上画重点区域了。比如一条高压线两侧各50米设为禁入区追踪系统检测到有人或车进入该区域并停留超过一定时长机载端就触发事件后台在GIS上弹出目标轨迹和现场截图。这种地图上的电子围栏轨迹判读的组合才是巡检业务真正需要的形态。5.3 网络链路的可靠性设计巡检区域往往在野外4G/5G信号不稳定图传链路也存在断流风险。如果整个系统强依赖实时传输任务经常会被打断。我采用的策略是机载端本地缓存加断点续传。机载端会缓存所有触发事件相关的短视频和轨迹快照链路正常时实时推送链路断开时本地暂存重新连接后自动补传。缓存容量按任务时长规划一般至少缓存两个小时的事件数据。同时追踪系统的关键运行指标——每帧耗时、检测目标数、追踪轨迹数、缓存状态等——也需要定期回传地面站方便远程判断算法运行是否健康。我见过不少项目链路一断后台完全黑盒恢复后才发现机载端早就因为某些异常退出了运行。这类问题在偏远地区巡检时格外致命。6. 数据闭环让追踪系统越用越聪明而不是越跑越糊涂最后一个环节也是最容易被砍掉、但长期价值最高的环节追踪系统的数据闭环。很多项目做到前面五步就交付了运行一两年后模型效果肉眼可见地滑坡却不知道怎么更新因为当时没有任何数据回收机制。6.1 自动化的难例数据回收追踪系统运行过程中最值得回收的数据不是检测正确的那些而是让系统犯难的那些。我把难例分成几类检测置信度在0.3到0.7之间反复横跳的框ID频繁切换的轨迹段在树影、水面反光区域产生的虚警帧以及在各类天气、光照条件下误检较多的片段。机载端按这些规则自动抽帧打包成难例集定期回传到地面站的数据服务器。每天飞行任务结束后算法团队可以快速浏览这些难例找出其中真正有价值的样本补充到训练集里。这个机制做起来以后整个系统的演进方向就是由真实场景驱动的而不是由算法团队的猜测驱动的。6.2 人工复核平台与轻量级增量训练光有自动化回收还不够得让有一定判断能力的人来标注和筛选。我做了一个简单的复核页面左边显示关键帧画面右边显示追踪状态和置信度曲线标注员只需要点确认目标误报漏检三个按钮。整个交互比从零开始的通用标注工具简单得多。数据攒到一定量后做增量训练。增量训练有两类做法一种是直接在之前训练好的权重基础上用新数据加较小学习率继续训练几千步速度快但存在遗忘旧数据的风险另一种是混入旧数据加新数据从头训练效果更稳但训练时间更长。我的建议是前几次迭代选择稳妥的第二种方式等到数据分布稳定之后再切换为第一种方式以提高更新频率。模型每次升级后要在保留的验证集上跑一遍回归测试确认新版本没有把以前做对的场景改坏。这一步能防止修一个场景坏十个场景的尴尬局面。6.3 模型版本管理与现场可回退野外作业环境不可控模型升级这件事尤其需要留一手。更新到机载现场的新模型如果在一个作业周期内发现异常必须能一键回退到上一版本。这要求从立项第一天就把模型文件的命名、校验和存储做成标准流程而不是开发同学本地改一版就传一版。我习惯在机载端固化一个模型包概念里面包含模型权重、配置文件、前后处理参数和版本号。地面站下发新模型包时机载端先启动校验进程校验通过后加载到影子存储区下一次重启或者特定指令切换时才生效避免飞行中模型被替换导致运行异常。数据闭环跑通之后系统有一个很直观的变化模型对现场环境数据的适应能力越来越强误报和漏检率在每一个作业周期里都能看到缓慢下降。这种越用越聪明的特性是追踪系统从项目交付物变成持续运营资产的关键。最后说一点个人体会。无人机巡检里的人车追踪技术上没有哪个单点是高不可攀的难点全在把检测、跟踪、部署、数据和业务语义串成一条完整的链路。很多团队单点技术都很强但系统整合时才发现彼此之间的衔接全是窟窿。我建议有条件的团队从第一个版本开始就把数据回流和GIS联动考虑进去哪怕先做得简陋一些也比后续推倒重来省太多精力和成本。