尧图网页设计 
简介YOLOv7无人机实时探测人体是一篇基于YOLOv7模型构建无人机热红外TIR目标检测框架的学术论文资料面向计算机视觉、目标检测与无人机遥感方向的研究者和工程师解决复杂背景、小尺度目标条件下的人体检测难题。该框架利用前视红外相机采集地面TIR影像通过CNN架构的YOLO模型实现快速检测——在IOU0.5时平均精度达72.5%检测速度约161FPS并系统评估了不同无人机观测角度对交叉检测效果的影响。资源包为单个PDF文件总大小2.01MB包含论文全文、方法说明、实验设计以及定性与定量评估结果可为相关科研、毕业设计或技术调研提供参考。已有269人学习浏览适合需要了解YOLOv7在热红外无人机场景应用、复现实验或撰写技术报告的研究人员。内容展示了完整的架构细节、性能对比与无人机视角分析可直接用于算法选型或方案论证。1. YOLOv7无人机实时探测人体为什么低空巡检和安防都在拿它当第一步在低空巡检、安防巡逻甚至搜救场景里YOLOv7无人机实时探测人体几乎成了无人机视觉感知的第一道标准题。它要解决的不是把一个通用目标检测模型跑起来那么简单而是要把近景里很清晰、高空往下看只有几十像素的人形目标在机载算力有限的前提下识别出来并反馈给飞控。选中YOLOv7的原因很实际v7-tiny不到20MB在Jetson Orin NX这类板卡上能维持30帧左右的持续推理并且重参数化结构在部署阶段不会带来额外计算开销。适合先来搭一套可复现最小系统的安防工程、工地人员和算法验证团队参考。2. 为什么是YOLOv7在无人机算力约束下选型模型的三个硬标准2.1 基于锚点的检测头在低空小目标场景里是不是短板无人机视角和普通地面视角最大的区别是“俯视小目标”。YOLOv7的检测头仍然基于锚点COCO预训练模型的anchor预设是针对常规水平影像统计出来的。一架多旋翼悬停在25米高度一个人形在640×640输入图里大约只有15到30个像素高换算到stride 32的检测层上目标高度常常不到1个像素。用COCO权重直接推理时这类目标往往不是完全漏检而是间歇性出现同一个目标刚有框、下一帧就消失。这个现象最容易让人误以为是模型过拟合或者置信度阈值设得偏高其实回头用tools/anchors.py对航拍样本重新聚类一下anchor召回会立刻提一截。相比anchor-free的CenterNetv7的优点是检测头对长条形的行人目标收敛更可靠工程链路上NMS、ONNX导出、TensorRT都有现成脚本不需要自己从零拼一套后处理。对现场交付来说能够在一天内跑通比“理论最优”更重要这是我把v7作为默认起点的原因。2.2 YOLOv7原理里的重参数化辅助头在部署阶段白捡的推理效率YOLOv7原理里最有实用价值的设计是训练阶段的辅助头aux head和可重参数化。训练时模型不只有一个输出头而是用额外的辅助头参与深层监督让梯度更容易传到浅层主干推理时再把这些分支折叠回普通卷积只保留主检测头。翻译成工程语言就是训练阶段多花了点算力部署阶段计算量和内存占用不变但精度比同样架构不带辅助头的版本更高。在算力紧张的机载设备上这种“白捡”的精度正是选型时最想要的。不过这个便利也有代价如果用torch.jit.trace之类的通用工具导出模型可重参数化分支里的一些控制流会被trace固化导出后的输出和PyTorch不一致。我踩过这个坑后来统一用官方仓库的export.py导出ONNX再转TensorRT。凡是带重参数化结构的仓库第一件事是看官方是否给了导出脚本没有的话再考虑自己写通用导出别一上来就上通用trace工具。提示选择YOLOv7的方案后第一步先核对官方export脚本的工作模式不要自创导出路径否则后面转engine的时间足够让你怀疑人生。2.3 v7-tiny、v7和v7x怎么选不要只看mAP要看持续平均帧率在无人机上做实时探测选型不是“性能最好的模型”而是“能持续跑完一块电池的模型”。三个常见选择的差别如下模型权重体积640分辨率实测范围TensorRT适合部署位置yolov7-tiny约12MB机载GPU上20~40fpsJetson Nano/Orin NX、树莓派加速棒yolov7约71MB桌面GPU上60fps左右机载不足10fps地面站、后台分析yolov7x约132MB精度高但机载内存风险大高算力地面集群我一般拿到新板卡后不做官方benchmark而是直接跑一段自己的视频流统计持续30分钟的平均帧率和GPU显存占用。很多“演示跑得好”的模型一上持续推理会因为显存碎片化掉到个位数帧率。以v7-tiny为例如果板卡是Jetson Orin NX 8GB用FP16推理640输入常见能到20fps以上但如果输入分辨率提到960帧率差不多要打六折所以不要盲目上高分辨率。验证选型是否合适可以先用官方detect.py快速测一轮python detect.py --weights yolov7-tiny.pt --source drone_shots.mp4 --conf 0.4 --img 640先用本地机器跑一遍确认输出框的“person”出现频率如果视频里大量人员被漏掉再判断是不是需要换成v7或加大输入尺寸。这一步能避免在还没解决数据和部署问题的时候就过早投入更重的模型。3. 无人机端yolov7部署的最小可运行方案Jetson板卡上的实时推流检测3.1 环境准备ONNX Runtime还是TensorRT以及为什么先导出onnx在Jetson板卡上跑YOLOv7最常用的后端有ONNX Runtime和TensorRT两种。ONNX Runtime的优势是跨平台部署方便缺点是在机载GPU上对TensorRT这种深度定制的后端没有竞争力。我自己的习惯是原型验证用PyTorch直接加载权重拿到板卡后立刻转ONNX再用TensorRT编译成engine。ONNX更像中间产物不要把它当成最终部署格式因为TensorRT在NVIDIA平台上会和显存管理、固定张量尺寸深度绑定带宽利用率和帧率都明显高一截。转之前先检查板卡上的CUDA版本和TensorRT版本因为YOLOv7仓库里的一些旧导出脚本在TensorRT 8.6以上会遇到算子兼容问题。一个可复现的指令链如下# 在PC上与板卡同CUDA版本导出fp16可用的onnx python export.py --weights yolov7-tiny.pt --img 640 --batch 1 --simplify --include onnx # 在Jetson上编译TensorRT engine trtexec --onnxyolov7-tiny.onnx --fp16 --workspace1024 \ --minShapesimages:1x3x640x640 \ --optShapesimages:1x3x640x640 \ --maxShapesimages:1x3x640x640 \ --saveEngineyolov7-tiny.engine这段命令里有两个关键点一是--img 640要和训练时一致不然张量尺寸对不上二是trtexec的minShapes/optShapes/maxShapes都写同一个值等于把模型固定成640×640静态尺寸。固定尺寸看似浪费灵活性但机上显存少静态尺寸能让TensorRT做更激进的内存复用实测比动态尺寸更可靠。导出后务必把engine文件和它对应的输入尺寸记录在案。我在现场吃过亏几天后重新接线发现实际推流分辨率是1920×1080而engine固定输入是640×640所有人都误以为解码出错了。最后在视频流入口加一个统一的letterbox预处理才让画面和engine匹配起来。3.2 从视频流取帧RTSP流和相机参数怎么对齐机载摄像头通常有两种取流方式RTSP网络流和USB摄像头。USB摄像头的问题在于内部缓冲和CPU占用高在飞控断开的边沿会直接影响控制周期。推荐用RTSP硬件解码或者选择支持MJPEG输出的低成本相机让板卡的硬件编解码单元分担一部分压力。我一般会在起飞前先把相机参数固化下来分辨率、帧率、曝光模式、快门速度。分辨率并不是越高越好1920×1080的原始流经过letterbox缩到640后远处的“人”可能连10个像素都没有。与其全分辨率采集再缩放不如在相机端直接输出1280×720让目标在输入图里占更多像素。实时流取帧时最需要注意OpenCV的缓冲问题。cv2.VideoCapture默认会积压多帧推理端按每帧处理人眼看上去就是画面“跳到当前”然后出现半秒的跳变。我的做法是把缓冲区压到1帧并限制只在有新帧时才推理。3.3 一个跑通实时探测的Python脚本推流、置信度参数和letterbox原则import cv2 import torch # 加载本地YOLOv7仓库中的v7-tiny模型不要在每次运行时下载 model torch.hub.load(/path/to/yolov7, custom, yolov7-tiny.pt, sourcelocal) model.conf 0.4 model.iou 0.45 cap cv2.VideoCapture(rtsp://192.168.1.10:8554/main, cv2.CAP_FFMPEG) cap.set(cv2.CAP_PROP_BUFFERSIZE, 1) while True: ret, frame cap.read() if not ret: continue frame_rgb cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) # size640 时模型内部会先做letterbox返回的坐标已经映射回原图 results model(frame_rgb, size640) det results.pandas().xyxy[0] person det[det[name] person] for _, row in person.iterrows(): x1, y1, x2, y2 map(int, row[[xmin, ymin, xmax, ymax]]) cv2.rectangle(frame, (x1, y1), (x2, y2), (0, 255, 0), 2) cv2.imshow(drone-detect, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()这里最关键的一点是不要自己先cv2.resize成正方形再喂给模型。YOLOv7自带的预处理会保持长宽比把缺的部分补成灰色从而避免人体形状被横向拉伸如果你在外部强行resize到640×640高压线杆、塔吊这些垂直物体全都会“变粗”误检率立刻上升。如果你自己实现letterbox最后画框时要把模型输出的归一化坐标除以缩放系数再补回pad偏移否则框的位置会整体错位。参数上model.conf 0.4比官方默认低一点因为低空小目标置信度天然偏低iou_thres对应的是model.iou 0.45重叠目标多时可以往下调。cap.set(cv2.CAP_PROP_BUFFERSIZE, 1)是降低延迟的关键OpenCV默认会为了流畅显示积压不少帧但推理端的帧率跟不上解码端时拿到的永远是“过去”的画面这对飞控联动的危害很大。4. 自采航拍人体数据做微调从公开的无人机航拍工地数据到YOLO标签4.1 数据来源和筛选公开的无人机航拍工地数据有多少可以直接用如果要做低空人体检测完全依赖COCO预训练权重上限是明显的。COCO里的行人照片以平视为主无人机视角需要补大量“俯视小目标”样本。公开的无人机航拍工地数据是一个能快速拿到的起点但这类数据通常包含许多机位杂乱、曝光过强的帧不能整段直接灌进训练。拿回来先按三个步骤筛第一去掉完全没有人员的帧只保留人员目标出现超过一帧的画面第二用开源检测模型先粗标一遍把大面积误标抽出来人工复核尤其是阴影、工地防护网这类容易把模型带偏的区域第三把同一场景里连续相似帧去重按5秒间隔抽帧避免训练集被相似背景淹没。同一个工地的样本占比不要超过40%否则模型很快学会“只在这个工地有用”的背景记忆换个场景就失灵。4.2 用LabelImg标注人形VOC转YOLO格式时四个坐标坑点标注工具首推LabelImg导出为Pascal VOC后转YOLO txt格式下面这段是常用的转换逻辑import xml.etree.ElementTree as ET def voc_to_yolo(xml_file, classes[person]): tree ET.parse(xml_file) root tree.getroot() size root.find(size) w, h int(size.find(width).text), int(size.find(height).text) lines [] for obj in root.iter(object): cls obj.find(name).text if cls not in classes: continue box obj.find(bndbox) x1, y1, x2, y2 [float(box.find(i).text) for i in (xmin, ymin, xmax, ymax)] x_center ((x1 x2) / 2) / w y_center ((y1 y2) / 2) / h bw (x2 - x1) / w bh (y2 - y1) / h lines.append(f{classes.index(cls)} {x_center:.6f} {y_center:.6f} {bw:.6f} {bh:.6f}) return lines四个坑点依次说第一如果一个人的目标在图像边缘x1或x2可能超出图像边界不先裁剪就直接归一化会让中心点超出[0,1]训练时会被当成“坏样本”过滤掉第二不要用整数型保存归一化小数至少保留6位不然小目标的width和height会在反向传播里出现截断误差第三有些数据集的标注框只框住人上半身俯瞰视角下身体和腿的重叠度较高需要把框拉到整个人体第四很多自动标注工具会输出“person”和“people”两种类名转换时统一映射到person。4.3 单类微调yolov7-tiny数据配置、anchor重聚类和训练命令在只检测人体时把类别数量设为1创建data/custom.yamlpath: ./data/airsurvey train: images/train val: images/val nc: 1 names: 0: person然后先用官方工具重新聚类anchor再启动训练# 重新统计低空人体目标的anchor尺寸 python tools/anchors.py --data data/custom.yaml --img 640 \ --cfg cfg/training/yolov7-tiny.yaml # 微调训练 python train.py --img 640 --batch 8 --epochs 50 \ --data data/custom.yaml \ --cfg cfg/training/yolov7-tiny.yaml \ --weights yolov7-tiny.pt \ --hyp data/hyp.scratch.custom.yaml这两条命令有讲究。--img 640表示训练时输入尺寸是640如果你最终部署的目标是高空小目标可以改成960但显存占用和训练时间会明显上涨。--batch 8适合8GB显存的消费级GPU显存再小就降到4同时把--epochs提高到60来补救。--weights yolov7-tiny.pt会自动把COCO的80类输出层替换成单类输出这一层是随机初始化的必须保证前几个epoch有足够小的学习率否则骨干网络刚学到的特征会被新分类层的大梯度冲掉。微调完之后用验证集跑一遍test.py专门看AP0.5在person这个类别上的数值。只有它高于0.8才值得花时间做TensorRT部署如果卡在0.6上下问题大概率不是模型而是标注里的遮挡和漏标不是调参能解决的。5. 无人机实时探测避坑清单5个高频故障的现象、原因和修正5.1 现象起飞后画面明显卡顿目标在屏幕上跳来跳去起飞前在地面推流流畅一上天就卡顿先别怀疑模型性能多半是取流链路在机身振动下出现帧积压。OpenCV的VideoCapture默认缓冲区是4到5帧而推理线程每帧耗时30ms解码线程可能已经解出来150ms之后的画面推理之后显示出来的目标位置和实际位置偏差越来越大看起来就是目标在“跳”。原因本身不是单一的RTSP的UDP传输丢包会导致关键帧解码失败机身振动让码率波动解码端就会缓冲等待。我一般把CAP_PROP_BUFFERSIZE设为1同时RTSP传输改为TCP模式在地址后加?transporttcp让丢包率降到接近零。如果画面依然卡就把相机端码率限制在4Mbps以内别让解码占满CPU。5.2 现象地面实测正常上机后误检数量翻倍地面测试用的是静态三脚架上机后是手持或机载云台画面上会有明显的运动模糊和果冻效应。模型训练时见过清晰的和轻微模糊的样本但没见过高速飞行下的横向拖影于是把地面纹理误判成人形。最有效的缓解是在采集训练数据时就加入“模拟运动模糊”把清晰航拍帧转成模糊版本或是在每个epoch里随机对输入做高斯模糊增强。我通常把hyp.scratch.custom.yaml里的hsv_h、hsv_s增强量调低把degrees保持为0因为无人机横滚角度不会让太阳颜色发生剧变但运动模糊必须加。除了数据增强推理端也要做时序平滑。单帧置信度低的目标不要马上丢弃记录它在连续5帧内的位置如果位置保持可靠再上报告警。这能滤掉随机噪点和因模糊出现的“一次性误检”。5.3 现象检测框在图像上位置正确但换算到实际经纬度后偏了半米这个问题的根源不在YOLOv7而在云台姿态和相机内参没有参与坐标换算。检测框中心只是图像像素坐标要变成无人机坐标系下的东北天ENU坐标需要相机内参、云台俯仰角、偏航角和机身高度的完整链路。很多人只用一个固定的“俯仰角补偿”在5米低空感觉不出来到了30米高度误差立刻超过0.5米根本无法用于精确投送或目标跟踪。解决方法是把云台角度换算成一个旋转矩阵再把相机光心偏移量加进去。这一步不复杂但必须在机载代码里写成常驻参数每次收到云台角度变化时更新一次。否则飞控端拿到的永远是悬停初始时刻的转换结果。5.4 现象TensorRT engine第一次编译要几分钟飞控已经完成解锁TensorRT在第一次执行时会做算子选择和内存优化如果机载启动脚本里临时编译engine等待时间会超过飞控的解锁窗口整个系统在起飞阶段就“假死”几秒钟。处理方式分两部分在交付前把编译好的engine保存下来开机时从文件加载如果担心engine跟驱动不匹配也要在板卡上加电的一瞬间立刻触发预编译然后再启动其他任务。我在实际项目里还会顺手检查engine文件是否完整因为用过网络下载的engine文件在另一台板卡上偶尔因为驱动版本不同出现加载后推理结果全为空的“黑匣子”问题。每次升级JetPack或TensorRT版本后记得重新导出engine别为省那几分钟出现更严重的定位错误。5.5 现象30米高度下小目标漏检到只剩三分之一当目标在640输入里只有不到8个像素时任何检测模型的召回都会断崖式下降这不是调阈值能救回来的。常见做法是提高输入分辨率到960或1280但这会压垮机载GPU的帧率所以更实用的办法是对检测区域做“中心裁剪”利用无人机相对不动或只有缓慢平移的特性把画面中央1.3倍大小的区域切成子图放大后单独送到模型外围区域用低分辨率轮流检测。这样既保留了小目标的像素又不至于对整帧做昂贵的超分。如果你没有时间做切片推理还有一个更直接的替代把相机从4K模式收到2.7K模式同时把推理输入从640升到768。目标在模型输入里的像素比例会提升20%左右帧率损失15%但漏检能明显下降。取舍标准是安全任务优先召回巡检任务优先帧率。6. 从探测结果到飞控联动Mavlink触发抑制的两个小技巧模型输出“person”和置信度之后直接把它发给飞控是很危险的一件事因为单帧误检和高频抖动会让飞控以为目标位置在来回跳。所以我把下游Mavlink逻辑分两层触发抑制和轨迹保持。第一个技巧是“连续帧计数触发”。给每个跟踪目标分配一个计数器只有在连续帧里累积足够多的检测才允许发送一次目标消息class TriggerFuse: def __init__(self, n_miss_allowed10): self.count 0 self.miss 0 def update(self, has_det): if has_det: self.count 1 self.miss 0 if self.count 10: return True else: self.miss 1 if self.miss n_miss_allowed: self.count 0 return False如果后期接跟踪器就给每个Track ID单独保存一个实例。真正触发后目标位置以5Hz的频率发送而不是跟随模型帧率避免下游指令密集到挤占带宽。第二个技巧是坐标系的选择。飞控端的SET_POSITION_TARGET_LOCAL_NED期望的是机体NED坐标系如果直接把图像中心偏置误当作角度增量飞控会做很夸张的俯仰翻滚。正确做法是先把检测框中心转换为camera pitch和yaw的偏差再乘以云台角速度增益生成速度指令。每次出厂前我都会在模拟器里用一条固定航线验证这个速度环否则真机上的第一次悬停转向很难一次成功。我现在接到新任务都会把这两层逻辑当成默认约束提前写进机载代码不在现场临时飞代码。这个习惯帮我避免过很多次“模型很准、飞控乱动”的深夜炸鸡希望帮到你。本文还有配套的精品资源点击获取 YOLOv7无人机实时人体检测：从模型选型到Jetson部署实战
简介YOLOv7无人机实时探测人体是一篇基于YOLOv7模型构建无人机热红外TIR目标检测框架的学术论文资料面向计算机视觉、目标检测与无人机遥感方向的研究者和工程师解决复杂背景、小尺度目标条件下的人体检测难题。该框架利用前视红外相机采集地面TIR影像通过CNN架构的YOLO模型实现快速检测——在IOU0.5时平均精度达72.5%检测速度约161FPS并系统评估了不同无人机观测角度对交叉检测效果的影响。资源包为单个PDF文件总大小2.01MB包含论文全文、方法说明、实验设计以及定性与定量评估结果可为相关科研、毕业设计或技术调研提供参考。已有269人学习浏览适合需要了解YOLOv7在热红外无人机场景应用、复现实验或撰写技术报告的研究人员。内容展示了完整的架构细节、性能对比与无人机视角分析可直接用于算法选型或方案论证。1. YOLOv7无人机实时探测人体为什么低空巡检和安防都在拿它当第一步在低空巡检、安防巡逻甚至搜救场景里YOLOv7无人机实时探测人体几乎成了无人机视觉感知的第一道标准题。它要解决的不是把一个通用目标检测模型跑起来那么简单而是要把近景里很清晰、高空往下看只有几十像素的人形目标在机载算力有限的前提下识别出来并反馈给飞控。选中YOLOv7的原因很实际v7-tiny不到20MB在Jetson Orin NX这类板卡上能维持30帧左右的持续推理并且重参数化结构在部署阶段不会带来额外计算开销。适合先来搭一套可复现最小系统的安防工程、工地人员和算法验证团队参考。2. 为什么是YOLOv7在无人机算力约束下选型模型的三个硬标准2.1 基于锚点的检测头在低空小目标场景里是不是短板无人机视角和普通地面视角最大的区别是“俯视小目标”。YOLOv7的检测头仍然基于锚点COCO预训练模型的anchor预设是针对常规水平影像统计出来的。一架多旋翼悬停在25米高度一个人形在640×640输入图里大约只有15到30个像素高换算到stride 32的检测层上目标高度常常不到1个像素。用COCO权重直接推理时这类目标往往不是完全漏检而是间歇性出现同一个目标刚有框、下一帧就消失。这个现象最容易让人误以为是模型过拟合或者置信度阈值设得偏高其实回头用tools/anchors.py对航拍样本重新聚类一下anchor召回会立刻提一截。相比anchor-free的CenterNetv7的优点是检测头对长条形的行人目标收敛更可靠工程链路上NMS、ONNX导出、TensorRT都有现成脚本不需要自己从零拼一套后处理。对现场交付来说能够在一天内跑通比“理论最优”更重要这是我把v7作为默认起点的原因。2.2 YOLOv7原理里的重参数化辅助头在部署阶段白捡的推理效率YOLOv7原理里最有实用价值的设计是训练阶段的辅助头aux head和可重参数化。训练时模型不只有一个输出头而是用额外的辅助头参与深层监督让梯度更容易传到浅层主干推理时再把这些分支折叠回普通卷积只保留主检测头。翻译成工程语言就是训练阶段多花了点算力部署阶段计算量和内存占用不变但精度比同样架构不带辅助头的版本更高。在算力紧张的机载设备上这种“白捡”的精度正是选型时最想要的。不过这个便利也有代价如果用torch.jit.trace之类的通用工具导出模型可重参数化分支里的一些控制流会被trace固化导出后的输出和PyTorch不一致。我踩过这个坑后来统一用官方仓库的export.py导出ONNX再转TensorRT。凡是带重参数化结构的仓库第一件事是看官方是否给了导出脚本没有的话再考虑自己写通用导出别一上来就上通用trace工具。提示选择YOLOv7的方案后第一步先核对官方export脚本的工作模式不要自创导出路径否则后面转engine的时间足够让你怀疑人生。2.3 v7-tiny、v7和v7x怎么选不要只看mAP要看持续平均帧率在无人机上做实时探测选型不是“性能最好的模型”而是“能持续跑完一块电池的模型”。三个常见选择的差别如下模型权重体积640分辨率实测范围TensorRT适合部署位置yolov7-tiny约12MB机载GPU上20~40fpsJetson Nano/Orin NX、树莓派加速棒yolov7约71MB桌面GPU上60fps左右机载不足10fps地面站、后台分析yolov7x约132MB精度高但机载内存风险大高算力地面集群我一般拿到新板卡后不做官方benchmark而是直接跑一段自己的视频流统计持续30分钟的平均帧率和GPU显存占用。很多“演示跑得好”的模型一上持续推理会因为显存碎片化掉到个位数帧率。以v7-tiny为例如果板卡是Jetson Orin NX 8GB用FP16推理640输入常见能到20fps以上但如果输入分辨率提到960帧率差不多要打六折所以不要盲目上高分辨率。验证选型是否合适可以先用官方detect.py快速测一轮python detect.py --weights yolov7-tiny.pt --source drone_shots.mp4 --conf 0.4 --img 640先用本地机器跑一遍确认输出框的“person”出现频率如果视频里大量人员被漏掉再判断是不是需要换成v7或加大输入尺寸。这一步能避免在还没解决数据和部署问题的时候就过早投入更重的模型。3. 无人机端yolov7部署的最小可运行方案Jetson板卡上的实时推流检测3.1 环境准备ONNX Runtime还是TensorRT以及为什么先导出onnx在Jetson板卡上跑YOLOv7最常用的后端有ONNX Runtime和TensorRT两种。ONNX Runtime的优势是跨平台部署方便缺点是在机载GPU上对TensorRT这种深度定制的后端没有竞争力。我自己的习惯是原型验证用PyTorch直接加载权重拿到板卡后立刻转ONNX再用TensorRT编译成engine。ONNX更像中间产物不要把它当成最终部署格式因为TensorRT在NVIDIA平台上会和显存管理、固定张量尺寸深度绑定带宽利用率和帧率都明显高一截。转之前先检查板卡上的CUDA版本和TensorRT版本因为YOLOv7仓库里的一些旧导出脚本在TensorRT 8.6以上会遇到算子兼容问题。一个可复现的指令链如下# 在PC上与板卡同CUDA版本导出fp16可用的onnx python export.py --weights yolov7-tiny.pt --img 640 --batch 1 --simplify --include onnx # 在Jetson上编译TensorRT engine trtexec --onnxyolov7-tiny.onnx --fp16 --workspace1024 \ --minShapesimages:1x3x640x640 \ --optShapesimages:1x3x640x640 \ --maxShapesimages:1x3x640x640 \ --saveEngineyolov7-tiny.engine这段命令里有两个关键点一是--img 640要和训练时一致不然张量尺寸对不上二是trtexec的minShapes/optShapes/maxShapes都写同一个值等于把模型固定成640×640静态尺寸。固定尺寸看似浪费灵活性但机上显存少静态尺寸能让TensorRT做更激进的内存复用实测比动态尺寸更可靠。导出后务必把engine文件和它对应的输入尺寸记录在案。我在现场吃过亏几天后重新接线发现实际推流分辨率是1920×1080而engine固定输入是640×640所有人都误以为解码出错了。最后在视频流入口加一个统一的letterbox预处理才让画面和engine匹配起来。3.2 从视频流取帧RTSP流和相机参数怎么对齐机载摄像头通常有两种取流方式RTSP网络流和USB摄像头。USB摄像头的问题在于内部缓冲和CPU占用高在飞控断开的边沿会直接影响控制周期。推荐用RTSP硬件解码或者选择支持MJPEG输出的低成本相机让板卡的硬件编解码单元分担一部分压力。我一般会在起飞前先把相机参数固化下来分辨率、帧率、曝光模式、快门速度。分辨率并不是越高越好1920×1080的原始流经过letterbox缩到640后远处的“人”可能连10个像素都没有。与其全分辨率采集再缩放不如在相机端直接输出1280×720让目标在输入图里占更多像素。实时流取帧时最需要注意OpenCV的缓冲问题。cv2.VideoCapture默认会积压多帧推理端按每帧处理人眼看上去就是画面“跳到当前”然后出现半秒的跳变。我的做法是把缓冲区压到1帧并限制只在有新帧时才推理。3.3 一个跑通实时探测的Python脚本推流、置信度参数和letterbox原则import cv2 import torch # 加载本地YOLOv7仓库中的v7-tiny模型不要在每次运行时下载 model torch.hub.load(/path/to/yolov7, custom, yolov7-tiny.pt, sourcelocal) model.conf 0.4 model.iou 0.45 cap cv2.VideoCapture(rtsp://192.168.1.10:8554/main, cv2.CAP_FFMPEG) cap.set(cv2.CAP_PROP_BUFFERSIZE, 1) while True: ret, frame cap.read() if not ret: continue frame_rgb cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) # size640 时模型内部会先做letterbox返回的坐标已经映射回原图 results model(frame_rgb, size640) det results.pandas().xyxy[0] person det[det[name] person] for _, row in person.iterrows(): x1, y1, x2, y2 map(int, row[[xmin, ymin, xmax, ymax]]) cv2.rectangle(frame, (x1, y1), (x2, y2), (0, 255, 0), 2) cv2.imshow(drone-detect, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()这里最关键的一点是不要自己先cv2.resize成正方形再喂给模型。YOLOv7自带的预处理会保持长宽比把缺的部分补成灰色从而避免人体形状被横向拉伸如果你在外部强行resize到640×640高压线杆、塔吊这些垂直物体全都会“变粗”误检率立刻上升。如果你自己实现letterbox最后画框时要把模型输出的归一化坐标除以缩放系数再补回pad偏移否则框的位置会整体错位。参数上model.conf 0.4比官方默认低一点因为低空小目标置信度天然偏低iou_thres对应的是model.iou 0.45重叠目标多时可以往下调。cap.set(cv2.CAP_PROP_BUFFERSIZE, 1)是降低延迟的关键OpenCV默认会为了流畅显示积压不少帧但推理端的帧率跟不上解码端时拿到的永远是“过去”的画面这对飞控联动的危害很大。4. 自采航拍人体数据做微调从公开的无人机航拍工地数据到YOLO标签4.1 数据来源和筛选公开的无人机航拍工地数据有多少可以直接用如果要做低空人体检测完全依赖COCO预训练权重上限是明显的。COCO里的行人照片以平视为主无人机视角需要补大量“俯视小目标”样本。公开的无人机航拍工地数据是一个能快速拿到的起点但这类数据通常包含许多机位杂乱、曝光过强的帧不能整段直接灌进训练。拿回来先按三个步骤筛第一去掉完全没有人员的帧只保留人员目标出现超过一帧的画面第二用开源检测模型先粗标一遍把大面积误标抽出来人工复核尤其是阴影、工地防护网这类容易把模型带偏的区域第三把同一场景里连续相似帧去重按5秒间隔抽帧避免训练集被相似背景淹没。同一个工地的样本占比不要超过40%否则模型很快学会“只在这个工地有用”的背景记忆换个场景就失灵。4.2 用LabelImg标注人形VOC转YOLO格式时四个坐标坑点标注工具首推LabelImg导出为Pascal VOC后转YOLO txt格式下面这段是常用的转换逻辑import xml.etree.ElementTree as ET def voc_to_yolo(xml_file, classes[person]): tree ET.parse(xml_file) root tree.getroot() size root.find(size) w, h int(size.find(width).text), int(size.find(height).text) lines [] for obj in root.iter(object): cls obj.find(name).text if cls not in classes: continue box obj.find(bndbox) x1, y1, x2, y2 [float(box.find(i).text) for i in (xmin, ymin, xmax, ymax)] x_center ((x1 x2) / 2) / w y_center ((y1 y2) / 2) / h bw (x2 - x1) / w bh (y2 - y1) / h lines.append(f{classes.index(cls)} {x_center:.6f} {y_center:.6f} {bw:.6f} {bh:.6f}) return lines四个坑点依次说第一如果一个人的目标在图像边缘x1或x2可能超出图像边界不先裁剪就直接归一化会让中心点超出[0,1]训练时会被当成“坏样本”过滤掉第二不要用整数型保存归一化小数至少保留6位不然小目标的width和height会在反向传播里出现截断误差第三有些数据集的标注框只框住人上半身俯瞰视角下身体和腿的重叠度较高需要把框拉到整个人体第四很多自动标注工具会输出“person”和“people”两种类名转换时统一映射到person。4.3 单类微调yolov7-tiny数据配置、anchor重聚类和训练命令在只检测人体时把类别数量设为1创建data/custom.yamlpath: ./data/airsurvey train: images/train val: images/val nc: 1 names: 0: person然后先用官方工具重新聚类anchor再启动训练# 重新统计低空人体目标的anchor尺寸 python tools/anchors.py --data data/custom.yaml --img 640 \ --cfg cfg/training/yolov7-tiny.yaml # 微调训练 python train.py --img 640 --batch 8 --epochs 50 \ --data data/custom.yaml \ --cfg cfg/training/yolov7-tiny.yaml \ --weights yolov7-tiny.pt \ --hyp data/hyp.scratch.custom.yaml这两条命令有讲究。--img 640表示训练时输入尺寸是640如果你最终部署的目标是高空小目标可以改成960但显存占用和训练时间会明显上涨。--batch 8适合8GB显存的消费级GPU显存再小就降到4同时把--epochs提高到60来补救。--weights yolov7-tiny.pt会自动把COCO的80类输出层替换成单类输出这一层是随机初始化的必须保证前几个epoch有足够小的学习率否则骨干网络刚学到的特征会被新分类层的大梯度冲掉。微调完之后用验证集跑一遍test.py专门看AP0.5在person这个类别上的数值。只有它高于0.8才值得花时间做TensorRT部署如果卡在0.6上下问题大概率不是模型而是标注里的遮挡和漏标不是调参能解决的。5. 无人机实时探测避坑清单5个高频故障的现象、原因和修正5.1 现象起飞后画面明显卡顿目标在屏幕上跳来跳去起飞前在地面推流流畅一上天就卡顿先别怀疑模型性能多半是取流链路在机身振动下出现帧积压。OpenCV的VideoCapture默认缓冲区是4到5帧而推理线程每帧耗时30ms解码线程可能已经解出来150ms之后的画面推理之后显示出来的目标位置和实际位置偏差越来越大看起来就是目标在“跳”。原因本身不是单一的RTSP的UDP传输丢包会导致关键帧解码失败机身振动让码率波动解码端就会缓冲等待。我一般把CAP_PROP_BUFFERSIZE设为1同时RTSP传输改为TCP模式在地址后加?transporttcp让丢包率降到接近零。如果画面依然卡就把相机端码率限制在4Mbps以内别让解码占满CPU。5.2 现象地面实测正常上机后误检数量翻倍地面测试用的是静态三脚架上机后是手持或机载云台画面上会有明显的运动模糊和果冻效应。模型训练时见过清晰的和轻微模糊的样本但没见过高速飞行下的横向拖影于是把地面纹理误判成人形。最有效的缓解是在采集训练数据时就加入“模拟运动模糊”把清晰航拍帧转成模糊版本或是在每个epoch里随机对输入做高斯模糊增强。我通常把hyp.scratch.custom.yaml里的hsv_h、hsv_s增强量调低把degrees保持为0因为无人机横滚角度不会让太阳颜色发生剧变但运动模糊必须加。除了数据增强推理端也要做时序平滑。单帧置信度低的目标不要马上丢弃记录它在连续5帧内的位置如果位置保持可靠再上报告警。这能滤掉随机噪点和因模糊出现的“一次性误检”。5.3 现象检测框在图像上位置正确但换算到实际经纬度后偏了半米这个问题的根源不在YOLOv7而在云台姿态和相机内参没有参与坐标换算。检测框中心只是图像像素坐标要变成无人机坐标系下的东北天ENU坐标需要相机内参、云台俯仰角、偏航角和机身高度的完整链路。很多人只用一个固定的“俯仰角补偿”在5米低空感觉不出来到了30米高度误差立刻超过0.5米根本无法用于精确投送或目标跟踪。解决方法是把云台角度换算成一个旋转矩阵再把相机光心偏移量加进去。这一步不复杂但必须在机载代码里写成常驻参数每次收到云台角度变化时更新一次。否则飞控端拿到的永远是悬停初始时刻的转换结果。5.4 现象TensorRT engine第一次编译要几分钟飞控已经完成解锁TensorRT在第一次执行时会做算子选择和内存优化如果机载启动脚本里临时编译engine等待时间会超过飞控的解锁窗口整个系统在起飞阶段就“假死”几秒钟。处理方式分两部分在交付前把编译好的engine保存下来开机时从文件加载如果担心engine跟驱动不匹配也要在板卡上加电的一瞬间立刻触发预编译然后再启动其他任务。我在实际项目里还会顺手检查engine文件是否完整因为用过网络下载的engine文件在另一台板卡上偶尔因为驱动版本不同出现加载后推理结果全为空的“黑匣子”问题。每次升级JetPack或TensorRT版本后记得重新导出engine别为省那几分钟出现更严重的定位错误。5.5 现象30米高度下小目标漏检到只剩三分之一当目标在640输入里只有不到8个像素时任何检测模型的召回都会断崖式下降这不是调阈值能救回来的。常见做法是提高输入分辨率到960或1280但这会压垮机载GPU的帧率所以更实用的办法是对检测区域做“中心裁剪”利用无人机相对不动或只有缓慢平移的特性把画面中央1.3倍大小的区域切成子图放大后单独送到模型外围区域用低分辨率轮流检测。这样既保留了小目标的像素又不至于对整帧做昂贵的超分。如果你没有时间做切片推理还有一个更直接的替代把相机从4K模式收到2.7K模式同时把推理输入从640升到768。目标在模型输入里的像素比例会提升20%左右帧率损失15%但漏检能明显下降。取舍标准是安全任务优先召回巡检任务优先帧率。6. 从探测结果到飞控联动Mavlink触发抑制的两个小技巧模型输出“person”和置信度之后直接把它发给飞控是很危险的一件事因为单帧误检和高频抖动会让飞控以为目标位置在来回跳。所以我把下游Mavlink逻辑分两层触发抑制和轨迹保持。第一个技巧是“连续帧计数触发”。给每个跟踪目标分配一个计数器只有在连续帧里累积足够多的检测才允许发送一次目标消息class TriggerFuse: def __init__(self, n_miss_allowed10): self.count 0 self.miss 0 def update(self, has_det): if has_det: self.count 1 self.miss 0 if self.count 10: return True else: self.miss 1 if self.miss n_miss_allowed: self.count 0 return False如果后期接跟踪器就给每个Track ID单独保存一个实例。真正触发后目标位置以5Hz的频率发送而不是跟随模型帧率避免下游指令密集到挤占带宽。第二个技巧是坐标系的选择。飞控端的SET_POSITION_TARGET_LOCAL_NED期望的是机体NED坐标系如果直接把图像中心偏置误当作角度增量飞控会做很夸张的俯仰翻滚。正确做法是先把检测框中心转换为camera pitch和yaw的偏差再乘以云台角速度增益生成速度指令。每次出厂前我都会在模拟器里用一条固定航线验证这个速度环否则真机上的第一次悬停转向很难一次成功。我现在接到新任务都会把这两层逻辑当成默认约束提前写进机载代码不在现场临时飞代码。这个习惯帮我避免过很多次“模型很准、飞控乱动”的深夜炸鸡希望帮到你。本文还有配套的精品资源点击获取