无人机视角下做行人检测和普通监控摄像头完全是两码事。地面摄像头拍行人目标大、角度平、光照可控模型随便跑无人机挂载的相机是俯视视角人的头部和肩部占了画面绝大部分同时整幅画面里的目标数量可能非常多地面一辆车、一排树都能把行人挡住大半。之前我用YOLOv5跑过一版遇到小目标密集场景时漏检明显后来借着YOLOv8发布我把整套系统重新做了工程化落地从模型训练到TensorRT加速再到最终的实时监控平台前后踩了不少坑。这篇就把完整的实战过程写出来包括数据怎么处理、训练参数怎么调、模型怎么部署到Jetson设备上、监控平台怎么搭以及我遇到过的各种奇怪问题。这套方案的目标很简单一架搭载摄像头的无人机把视频流实时传回地面站地面站或机载边缘设备上跑YOLOv8检测行人检测结果叠加在实时画面上推送监控大屏同时把告警事件比如闯入特定区域的行人自动记录下来。整个系统的价值在于解决两个痛点一是无人机替代人工巡逻效率高、覆盖面大二是实时性不是拍完回来再看视频而是边飞边看边报警。适合做安防巡检、大型活动现场保障、应急救援搜救等场景如果你正在做类似的无人机视觉项目这篇的实操经验可以直接参考。1. 整体架构设计与技术选型1.1 为什么选择YOLOv8而不是其他模型我做选型时对比过几个方向。一类是两阶段的Faster R-CNN系列精度高但推理速度太慢无人机平台本身算力有限还要考虑续航每帧多花几十毫秒都会显著影响一块电池能巡检的面积直接排除。另一类是YOLOv5和YOLOv8这两者都是单阶段检测器速度足够但YOLOv8在几个关键点上更契合我的需求。先看检测头的改进。YOLOv8换成了Anchor-Free结构不再需要预设Anchor Box。无人机俯拍视角下行人的尺度变化非常极端——同一帧画面里近处的行人可能占200×400像素远处的可能只有20×30像素。Anchor-Based方法需要针对这种尺度分布专门聚类Anchor不同飞行高度还得重新算Anchor-Free用中心点加回归的方式对不同尺度目标的适应性天然更好。我实测下来在无人机视角数据集上YOLOv8s的mAP比YOLOv5s高出3到4个百分点这个差距在密集小目标场景下尤其明显。另一个原因是模型的部署生态。YOLOv8官方代码库直接支持ONNX导出而且从训练到导出到推理的完整链路做得非常顺滑。我用它导出TensorRT引擎的时候不需要做太多额外的模型转换工作对Jetson这种边缘设备来说这一步节省了大量调试时间。整个系统架构分三块数据与模型训练、模型压缩与部署、实时监控平台。模型训练在PC端完成部署目标是一块Jetson Orin NX 16G模组监控平台跑在同一个设备上通过RTSP接收无人机图传的推流检测结果输出到Web前端。这样的好处是整套系统高度集成只需要给无人机和地面站供上电就能工作不依赖外部服务器。1.2 系统各模块的技术选型视频流接入这块我选的是GStreamer配合RTSP协议。无人机图传通常以RTSP流方式输出GStreamer负责拉流、解码、抽帧再把帧数据送到推理管线。这里有一个关键考量解码性能和延迟。GStreamer可以利用Jetson平台的硬件解码器NVDEC把CPU负载降到最低让出更多算力给模型推理。如果用OpenCV的VideoCapture拉RTSP流默认走的是软件解码FFmpeg在4K分辨率下CPU占用率能飙到70%以上这会让推理延迟明显变大。推理引擎我选了TensorRT。YOLOv8导出的ONNX模型经过TensorRT转换后在Jetson Orin NX上能把FP16精度下的推理速度做到单帧12毫秒左右而直接用ONNX Runtime推理则需要35到40毫秒。对于实时监控场景来说这个差距直接决定了用户体验——前者能跑到每秒80帧以上受解码帧率限制实际稳定在30帧后者勉强只能跑25到30帧一有波动就开始卡顿。监控平台的数据通道我用的是WebSocket。检测结果不是简单地输出到控制台而是要实时推送到浏览器端的监控页面。WebSocket全双工通信天然适合这种场景后端每处理完一帧就把检测框坐标、类别、置信度、时间戳打包成JSON推给前端前端用Canvas叠加到视频画面上。相比HTTP轮询这种方式的实时性和带宽效率都好太多。1.3 系统工作流程梳理整套系统的工作流程分成这样几条链路第一是视频流链路。无人机相机输出RTSP流Jetson上的GStreamer管道负责拉流和解码每帧解码完成后放进一个环形缓冲区推理线程从这个缓冲区取帧。第二是推理链路。推理线程拿到帧后先做预处理Resize到640×640、归一化、通道变换然后送入TensorRT引擎执行推理拿到检测框、类别和置信度。这里的后处理要去掉低置信度的框再做NMS非极大值抑制去重。第三是业务链路。如果检测到行人就把检测结果和原始帧关联起来一是叠加检测框标注后推送到Web前端显示二是当有行人进入预设的警戒区域时触发告警截取当前帧保存到本地并推送告警消息。第四是存储链路。正常的视频流不做全量保存太占空间只做事件触发的片段录制。发生告警时从前置缓冲区里取出告警前10秒的帧序列合成MP4文件保存。这是监控系统常见的预处理策略既能留存关键证据又不至于把一块256G的固态硬盘几天就写满。2. 数据集准备与模型训练实战2.1 训练数据的构成与标注训练数据是决定模型上限的关键。YOLOv8官方预训练权重是在COCO数据集上训出来的COCO里包含“person”这个类别但COCO里的行人绝大多数是水平或接近水平视角拍摄的直接用来推理无人机俯拍画面效果很差。好在用预训练权重做迁移学习时模型已经具备了通用的特征提取能力只需要少量无人机视角的数据微调就能收敛得很好。我这里训练数据的构成是三部分第一部分是公开的无人机视角行人检测数据集比如VisDrone和UAVDT前者包含大量不同高度、不同光照条件下拍摄的俯视行人画面后者侧重交通场景第二部分是自己采集的无人机视频在不同的飞行高度30米、50米、80米、不同的场景广场、园区道路、停车场拍摄然后抽帧标注第三部分是用COCO数据集中的人头、行人上半身样本做补充增强模型对人头肩部特征的敏感性。自采数据的标注是件耗时的工作。我用的是LabelImg工具标注时统一规则是“行人”类别只标注完整可见或者大部分可见的人体严重遮挡超过70%的不标注多个行人挨在一起时严格按照实例边界框标注不刻意区分每个人的粘连。这个标注规则的统一性非常重要标注标准不一致会让模型学到的特征混乱。最终数据集的情况大概是VisDrone和UAVDT的公开数据筛选后选用了约8000张图片自己采集标注了约3000张图片总共11000张左右按照8:1:1划分训练集、验证集和测试集。2.2 数据增强策略与训练参数无人机视角的行人检测有一个反复出现的问题小目标占比极高。实测统计下来30米以上高度拍摄的画面里行人目标面积占整幅画面的比例通常不到1%换算成640×640的输入尺寸很多目标只有20×20像素甚至更小。模型对这种极小目标的特征提取能力很有限所以数据增强的手段必须针对性设计。我在训练里使用了Mosaic增强和Copy-Paste增强的组合。Mosaic是YOLO系列常用的增强方法四张图拼接成一张增加小目标出现次数并提升模型的尺度鲁棒性。Copy-Paste是把小目标行人图像块随机粘贴到其他训练图上增加小目标的密度和多样性。这套组合用下来模型对稀疏小目标的召回率提升非常明显。训练参数上我用的YOLOv8s作为基础模型输入的图片尺寸是640×640批次大小设为32初始学习率0.01使用SGD优化器。总共训练了300个epoch在前50个epoch使用了Warm-Up策略让学习率从0.001线性增长到0.01避免模型在初始阶段剧烈震荡。这里有一个经验之谈YOLOv8默认的训练配置是基于COCO的直接拿来训无人机数据mAP可能只有50出头但只改一个数据增强参数可能就会涨2到3个点所以不要迷信默认配置。训练过程中的损失函数曲线需要关注三个部分边界框回归损失Box Loss、分类损失Cls Loss、置信度损失DFL Loss。这三个损失在前50个epoch快速下降之后缓慢收敛300个epoch后基本平稳。我用早停机制监控验证集mAP连续30个epoch不上升就停止训练避免过拟合。2.3 训练效果评估与分析训练完成后我用测试集做了详细评估。YOLOv8s在这个自建数据集上的mAP0.5达到了88.6%mAP0.5:0.95达到64.2%。对比一下直接用COCO预训练权重不做微调时的表现mAP0.5只有61.3%说明迁移学习加自建数据微调的效果是决定性的。逐尺度分析测试结果有个有趣的发现在30米高度拍摄的画面中模型对中等尺度大于40×40像素的行人目标检测精度接近95%但对小于20×20像素的目标召回率只有70%左右。小目标漏检和误检的主要原因是特征太少和背景干扰——在俯视视角下有人穿着颜色接近地面的衣服时模型很容易漏检。针对这个短板我又做了一轮迭代。一个办法是测试时开启多尺度推理在FP32和FP16两种精度下分别处理原始分辨率的0.8倍、1倍、1.2倍三种尺度融合结果后再输出。效果确实有提升mAP0.5涨了接近2个点但代价是推理时间几乎翻倍实时性受影响。另一个更实用的办法是改用YOLOv8m模型作为基线参数量和FLOPs虽然变大但在Jetson Orin NX上配合TensorRT同样能跑到25毫秒以下而小目标召回率提高了5个百分点。最终为了实时性优先我折中选择YOLOv8s并重点优化数据侧的增强策略和部署阶段的预处理逻辑。3. 从PyTorch到TensorRT的部署优化3.1 模型导出与精度验证训练完毕后先要对模型做导出。YOLOv8官方代码提供了直接的导出命令支持导出ONNX格式。这里有一个关键参数是动态输入还是静态输入。TensorRT对动态输入的支持比较麻烦如果输入尺寸固定为640×640引擎可以做一些内存布局上的优化推理速度更快。我日常使用都是固定输入尺寸所以导出时直接固定shape。导出的命令大致是这样。yolo export model/path/to/best.pt formatonnx dynamicFalse opset12导出成功后ONNX模型还要做一次精度验证。从PyTorch到ONNX的转换可能因为算子实现差异导致精度微降我一般用Python脚本分别跑PyTorch模型和ONNX模型的推理对比同一批图片的检测结果确认mAP差距在0.5个百分点以内才继续下一步。ONNX转TensorRT时有两个关键参数要调。动态形状会影响引擎生成时间FP16精度则直接决定推理速度和精度平衡。TensorRT的FP16模式在某些极端情况下会让极小目标的置信度出现0.1到0.2的波动但常规测试中影响不大加上可以用后处理卡阈值来兜底我最终还是选了FP16。这里有一个坑ONNX模型里如果带有一些不支持的操作符比如某些版本的Focus层展开方式转换成TensorRT时可能会报错或者生成错误引擎。我用的YOLOv8没有这个问题但如果从更老的YOLO版本迁移过来转换前需要用ONNX GraphSurgeon手动处理一下不兼容的节点。3.2 TensorRT引擎的构建与加载构建TensorRT引擎的方法有两种用trtexec命令行工具或者写Python代码调用TensorRT Python API。用命令行工具简单直接但部署时灵活性差而且无法嵌入到自己的应用逻辑中。我更推荐用Python API在应用启动时动态构建引擎方便统一管理日志和错误处理。import tensorrt as trt logger trt.Logger(trt.Logger.INFO) builder trt.Builder(logger) network builder.create_network(1 int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)) parser trt.OnnxParser(network, logger) with open(model.onnx, rb) as f: parser.parse(f.read()) config builder.create_builder_config() config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, 1 30) config.set_flag(trt.BuilderFlag.FP16) plan builder.build_serialized_network(network, config) with open(model.trt, wb) as f: f.write(plan)引擎构建完成后的序列化文件可以保存在本地后续启动时直接加载省去重新构建的时间。在Jetson设备上一次引擎构建大概需要30到60秒这在开发阶段可以接受但如果做产品发布建议在安装时预生成引擎文件避免用户等待。加载引擎并用它做推理时输入输出的张量布局需要和模型对齐。YOLOv8的输入是NCHW布局的RGB图像归一化范围是0到1输出是一个1×84×8400的张量其中84是4个边界框坐标加80个类别分数8400是三个不同尺度特征图上的候选框总数。在后处理时要把这个张量分解成边界框和类别分数然后做阈值筛选和NMS。这些逻辑用NumPy实现就行TensorRT只负责前向推理。3.3 Jetson平台上的推理管线优化Jetson Orin NX模组的CPU部分是8核Arm Cortex-A78AEGPU是Ampere架构算力在边缘设备里属于第一梯队。但就算算力充裕推理管线设计不好照样会卡顿。我最初的实现是每帧图像从解码到推理串行执行延迟在30毫秒左右但CPU使用率不稳定偶尔会掉到20毫秒以下偶尔飙升到45毫秒以上。后来改成生产者消费者模型解码线程持续把帧放入队列推理线程从队列取帧队列满时丢弃最新帧而不是阻塞解码线程。这样处理后帧率稳定在30FPSCPU占用率也降了下来。预处理和后处理的耗时也值得关注。在Python环境里把一张1080P的BGR图像缩放到640×640再做归一化用OpenCV实现大概要4毫秒NMS如果用纯Python实现候选框多时会拖到6到8毫秒。这些时间加起来即使TensorRT推理只有12毫秒整条链路的帧率也会被拖到30FPS以下。我的做法是把预处理和后处理都用NumPy的向量化操作重写NMS直接调用一个用Cython优化的版本整体预处理加后处理的耗时压缩到不到5毫秒。对于部署形态我有两种选择一种是把模型部署到Jetson设备上该设备放在地面站端接收无人机图传的RTSP流另一种是把设备直接挂在无人机上实现机载实时处理。考虑到系统主要用于安防监控场景地面站部署是主流方式既不影响飞行续航又便于管理维护。4. 实时监控平台的实现4.1 RTSP视频流接入与画面处理视频流接入部分用的是GStreamer管道核心命令大致是gst-launch-1.0 rtspsrc locationrtsp://drone_ip:554/live ! decodebin ! videoconvert ! video/x-raw,formatBGR ! appsink在实际代码里我会用OpenCV的VideoCapture配合GStreamer后端来接收帧cap cv2.VideoCapture(rtspsrc locationrtsp://drone_ip:554/live ! decodebin ! videoconvert ! video/x-raw,formatBGR ! appsink, cv2.CAP_GSTREAMER)这里有几个细节需要注意。第一格式一定要显式指定为BGR因为GStreamer默认输出可能是RGBA或其他格式OpenCV后续处理时容易搞混通道顺序。第二如果RTSP流的编码格式是H.265Jetson的硬件解码器可以正常处理但前提是GStreamer插件库里包含了对应插件。第三网络不稳定时RTSP流经常断流重连这段逻辑必须单独处理。针对断流重连问题我写了一个简单的重连机制检测到帧读取超时比如连续5秒没有新帧就销毁当前视频捕获对象等待1秒后重新创建并连接RTSP地址最多重试5次。这套逻辑还配合一个看门狗线程定期检查视频捕获是否仍然健康异常时自动拉起重连流程。实测下来在弱网环境信号强度低于-75dBm下原来平均每3分钟就要手动重启一次系统现在可以稳定运行数小时。4.2 检测结果叠加与前端展示监控前端我选的是Web方案跑在本机或局域网内的浏览器里。后端用FastAPI提供HTTP接口和WebSocket接口前端是一个简单的单页应用用Canvas渲染视频帧和检测框。具体流程是后端解码线程拿到原始帧后先做一次推理推理结果通过WebSocket实时推送到前端前端拿到检测框数据后在Canvas上叠加绘制。视频画面本身也是后端推过来的——使用Motion JPEGMJPEG格式把每帧JPEG编码后通过HTTP流式输出到浏览器。这种方式的好处是兼容性好、实现简单不需要复杂的WebRTC协商流程。缺点是需要额外的编码开销但在局域网环境下完全够用。这里有一个渲染性能的细节如果检测结果通过WebSocket推送每帧一条消息一秒30条消息对于WebSocket来说毫无压力前端Canvas绘制检测框也非常快。但如果推理结果直接在后端用OpenCV画好框再整体推图像JPEG编码和传输带宽会比没有检测框时高不少。所以我的最终方案是后端不画框只传输原始画面和检测框数据前端负责把框画到画面上。这样对带宽的占用是最小的。告警功能的实现逻辑是这样的在监控页面里可以预设多个多边形警戒区域前端会把区域顶点坐标发给后端后端在推理时判断每个行人检测框的中心点是否落在警戒区域内。如果检测到有行人闯入就触发告警推送一条WebSocket消息到前端弹窗提醒同时把当前帧保存到本地磁盘帧文件名带上时间戳和告警ID。4.3 数据存储与告警录像告警录像的存储设计是我花了不少心思的部分。监控系统如果对全量视频流做连续录像按1080P30FPS的H.264编码估算每小时需要1.5GB左右的存储空间一个8小时的飞行任务会产生12GB数据。如果只是做安防巡检这个量级对于移动硬盘还能接受但如果要常态化部署存储压力会迅速变大。我的方案是只录事件。后端始终维护一个环形缓冲区容量是10秒的帧序列约300帧新帧不断写入旧帧不断丢弃。当检测到告警事件时把当前缓冲区里的300帧连同后续的5秒新帧一起提取出来用H.264编码合成MP4文件。这样一条告警录像的长度是15秒覆盖了行人进入警戒区前后的关键画面既省存储空间又保留了证据链。合成MP4的编码操作如果放到主推理线程会卡顿我的做法是开一个专门的存储线程告警触发时把帧序列放入队列存储线程负责编码和写盘。这样即使同时发生多个告警主流程的推理帧率不会受到明显影响。对于告警事件除了保存录像还可以在Web界面里按照时间、区域、置信度进行历史检索。我把检测结果统一写入SQLite数据库字段包括时间戳、检测框坐标、置信度、是否告警、视频文件名。这套数据量不大SQLite完全够用比上MySQL或PostgreSQL省事得多而且部署时不用额外启动数据库服务。5. 实际部署中的问题排查与性能优化5.1 常见问题排查实录把这套系统从开发环境搬到真实的无人机作业现场时我遇到了不少预料之外的问题。这里整理几个最典型的按“现象—原因—解决”的方式列出来。第一个问题是画面撕裂和卡顿。原因是无人机图传使用的5.8GHz模拟/数字链路带宽有限RTSP流的实际码率不稳定加上Jetson上的解码器和推理线程竞争CPU资源。解决方式是用GStreamer管道直接设置drop-on-latencytrue允许解码器丢弃延迟过高的帧同时把解码器输出和推理线程的队列深度设为2——超过2帧就直接丢掉最旧的帧。这样的策略虽然会偶尔丢帧但避免了积压导致的整体延时加剧。第二个问题是告警误报率偏高。主要原因是模型对穿着迷彩服、深色衣服的行人容易漏检对树木、电线杆等竖直物体容易误检。解决方式是在后处理阶段增加一个“目标面积占比”的过滤条件检测框面积小于整幅图面积的万分之五的直接忽略因为在这个飞行高度下不可能是真实行人大于某个阈值且宽高比严重畸形的也过滤掉。第三个问题是长期运行内存泄漏。我最初用Python写推理服务时每处理一帧就创建一个新的推理上下文运行几个小时后内存占用从1.2G涨到6G以上系统开始频繁触发交换分区帧率直线下降。排查发现是TensorRT的execute_v2返回的张量没有及时释放Python垃圾回收机制处理不了CUDA显存。解决方式是把输入输出缓冲区在启动前一次性分配好推理过程反复复用同一块显存不再新建临时对象。下面这张表列了我遇到的其他几个问题以及对应的排查思路方便对照参考。现象可能原因解决办法模型推理速度慢TensorRT引擎未启用FP16构建引擎时开启FP16标志画面长时间无数据显示RTSP断流未重连增加断流检测和自动重连机制告警延迟高推理线程阻塞在写盘操作将磁盘编码和写盘移到独立线程前端画面模糊MJPEG压缩质量过低调整JPEG编码质量参数到85以上夜间漏检严重可见光相机成像质量差切换或融合红外热成像输入源5.2 性能调优的量化指标整个系统优化完成后我最终在Jetson Orin NX 16G上做了完整的性能基准测试。输入是1080P30FPS的RTSP流模型是FP16精度的YOLOv8s最终测得的端到端延迟从帧到达解码器到检测结果推送到前端稳定在33到38毫秒之间前端看到的实时性是完好的。细分各环节的耗时是这样的视频解码约3毫秒预处理约3毫秒TensorRT推理约12毫秒后处理约2毫秒WebSocket消息序列化与推送约2毫秒。在Jetson上这套链路的总耗时基本在25毫秒上下换算成帧率约35到40FPS超出视频源本身的30FPS说明管线没有成为瓶颈。对于算力更紧张的部署目标比如Jetson Nano或树莓派类设备也有几条降级路径。一是把输入分辨率降到416×416推理速度能提升接近一倍代价是mAP下降4个点左右二是限制推理的采样频率每2帧只推理1帧避免逐个帧做推理三是用更小的模型YOLOv8n推理延迟会从12毫秒降到7毫秒左右。方案没有绝对的好坏完全取决于业务对精度的容忍度。夜间作业是无人机安防的常见需求我在这套系统中预留了红外热成像视频流的接入方案。由于红外图像的颜色通道和可见光不同后处理逻辑需要做适配但整体架构不用变。这里只提一句如果业务对夜间检测有强需求建议额外训练一个针对红外图像的检测模型而不是直接复用可见光模型两者特征分布差异很大。5.3 关于部署形态的一些思考这里额外聊几句部署形态的选择。在开发这套系统时我们考虑过三段式部署方案机载部署、地面站部署、云中心部署。这三种方案各有优劣不能一概而论。机载部署的优点是时延最低。检测直接在无人机上完成不需要经过图传链路把画面传回地面再推理特别适合对响应时间要求极高的场景比如无人机避障或者应急搜救。缺点是算力受限于机载平台而且增加重量和功耗会影响续航。地面站部署是当前的主流做法。算力可以做得很强部署多块Jetson甚至显卡都没问题模型可以用更大的版本检测精度更高。缺点是画面必须经过图传链路回传RTSP流本身有编码传输延迟整条链路的端到端延迟会比机载部署高。我实际测试下来1080P的画面从机载传感器到地面站解码器的延迟大约是100到150毫秒对于安防监控来说完全可以接受。云中心部署适合多机多站点的大规模作业。所有无人机都把视频流推送到中心推理集群监控画面集中管理。但这种方案对网络的要求很高在偏远地区或野外作业场景常常不现实。我在最终的工程项目里选择了地面站部署理由很直接系统要处理的画面最差也是一路1080P30FPS地面站的算力充足整套系统随地面站移动不需要额外架设云端服务断网情况下系统依然可以正常工作只把告警数据保存在本地。6. 经验总结与复用建议这套系统从模型训练到部署上线前后经历了两轮迭代。第一轮用YOLOv5做原型验证了无人机视角下行人数检测的可行性但小目标和密集场景的精度达不到业务要求。第二轮全面切换到YOLOv8结合数据增强和TensorRT优化把精度和实时性都拉到了可交付的水平。我个人在实操中的体会是无人机行人检测项目最大的坑往往不在模型本身而在数据工程和部署链路。模型选型在YOLOv8这个级别基本已经进入了“能用”的区间剩下真正拉开差距的是你如何解决俯拍视角的数据分布问题、如何把模型高效地塞进边缘设备、如何在弱网环境下保证流媒体链路的稳定性。如果你是从零开始做类似项目我建议先按这个顺序推进确认数据采集方案能覆盖你要飞的高度和场景把标注标准定死然后再投入训练和部署优化。最后再分享一个小技巧。在做模型部署验证时别只盯着mAP或者FPS这种宏观指标一定要针对你的典型场景做切片测试。比如你主要飞30米高度就单独统计这个高度下的小目标召回率你主要在广场场景飞就单独统计这个场景下的误检数量。宏观指标会掩盖局部的严重短板而局部的短板恰恰是无人机巡检项目交付验收时最容易出问题的点。这套系统的后续扩展方向也很明确。一是加入行人重识别ReID模块让系统能追踪同一个行人在多架无人机画面之间的连续活动轨迹二是加入飞行路径规划联动检测到告警事件时自动调整无人机位置进行目标跟踪三是把检测结果接上应急联动系统告警信息直接推送短信或者语音通知。每一步扩展都建立在当前这套稳定的推理和监控底座上这也是我把工程化部署部分认真写出来的原因。