我在一个占地接近两个标准足球场的仓储园区做安防改造时遇到过一个特别典型的问题固定摄像头把主干道和出入口照得清清楚楚但园区边缘的围墙死角一旦有人翻进来监控最多只能拍到一条腿的残影。等第二天发现异常人都走了好几个小时。后来我逐步把它做成了一套 AI 值守的哨戒炮塔与无人机联动系统也就是 Aegis Control。地面端是一台可以自动转动的云台“炮塔”空中端是一架可随时起飞的无人机两者共用一套视觉识别模型识别到闯入者后接力追踪、持续示警并保留完整证据链。这篇文章就把整个项目从立项背景、硬件选型、视觉链路、伺服控制到无人机协同展开说清楚适合正在做嵌入式 AI、开源无人机、安防巡检方向的人参考。1. 为什么我会做一个“有腿的摄像头”项目立项背景与痛点1.1 固定监控的三个核心问题传统安防监控系统在园区这种场景里存在三个无法回避的短板。第一个是视角固定。再好的摄像头装上去之后可视范围就是一锤子买卖除非你部署足够多、足够密否则总有遮挡和死角第二个是没有主动预警能力。普通摄像头只是被动录像画面里发生了什么都得靠人盯着屏幕或者事后翻录像入侵发生的那一刻它不会主动通知任何人第三个是无法持续跟随。即便你看到了可疑目标摄像头也没法自动转动去锁定它目标一旦走出画面线索就断了。这三个问题放在一起结果就是装了监控不等于有人值守录了像不等于抓得到人。我做这个项目的初衷不是要搞一个玩票的玩具而是想验证一套能够“自动发现、持续跟踪、主动示警”的端到端系统看它能不能真正承担一部分夜间巡逻和边界值守的工作。1.2 方案设想固定哨戒加空中侦察的两级值守那段时间我刚好在接触边缘端的 AI 推理也在玩开源飞控于是很自然地把两个方向合在了一起。地面的“哨戒炮塔”本质上是一个搭载摄像头、可双向转动的云台AI 识别到可疑目标之后云台自动旋转让目标始终保持在画面中央但如果目标跑出了炮塔的射角范围或者进入了围墙另一侧的低洼区域地面视角就失效了。这时候就需要一个能离开固定位置、从空中俯瞰的节点也就是无人机。所以 Aegis Control 并不是单纯的云台追踪也不是单纯的无人机巡逻而是要把两个节点串成一个两级值守系统地面节点负责常态监控和快速响应空中节点负责补盲和接力追踪。项目名字里 Aegis 取的是“盾牌、守护”的意思Control 代表的是整个决策和控制链路。整体定位是安防巡检与行为示警不涉及任何杀伤性输出。1.3 为什么不直接买成品安防系统市面上带自动跟踪的安防球机并不少海康、大华都有类似产品直接买一套不省事吗但我当时的真实需求是这套系统必须能二次开发。我需要它在识别到目标后不只是在本地录像还要把目标坐标通过结构化数据发出去需要它能和无人机飞控联动需要我能随时把自己训练的模型换进去。成品设备的固件大多是封闭的做不到这些事。另外成品的跟踪逻辑是黑盒误报了你不知道它为什么误报也没法针对你所在的园区做参数优化。从投入角度看自己攒一套基于开源框架的系统前期研发成本高但后期可以持续迭代逻辑透明可控我觉得这笔账是值得的。2. 系统架构与关键选型先把骨架搭对再谈AI2.1 整体拓扑地面节点、空中节点与指挥中心整套系统分成三个角色。地面哨戒节点是核心包含云台机构、摄像头、边缘计算板卡和声光示警模块负责目标检测、跟踪、示警和视频推流。空中节点是可垂直起降的四轴无人机搭载机载摄像头和飞控通过 WiFi 数传链路与指挥中心通信负责接到命令后起飞补盲。指挥中心是部署在局域网内的一台 PC运行 Web 控制台显示实时视频流、目标标记框、轨迹路径和系统状态同时支持手动接管云台或下达无人机任务。数据流上我做了明确的分离视频流走 RTSP控制指令走私有 WebSocket无人机指令走 MAVLink。这样做的原因是三类数据对网络的要求完全不同视频流要求低延迟但可以容忍轻微丢包控制指令要求可靠性和实时性无人机指令要求协议语义明确。混在一个通道里出问题时很难排查。2.2 硬件选型明细模块选型关键参数说明边缘计算板卡NVIDIA Jetson Orin Nano 8GB可跑 YOLOv8m支持 TensorRT 加速摄像头USB 全局快门相机支持 MIPI 转接减少卷帘快门带来的画面果冻效应云台电机俯仰用 MG996R 舵机水平用闭环步进电机水平方向负载大、需要定位精度步进更合适示警输出声光报警器加激光指示器非杀伤性用于警示与标记目标飞控Pixhawk 6C 配合 ArduPilot开源、可通过 MAVLink 二次开发机架550 轴距四轴机架留足载重可挂相机和数传模块机载图传WiFi 数字图传模块与地面站局域网直连无额外中转选 Jetson Orin Nano 是综合考虑了算力、功耗和开发效率的结果。它的 8GB 显存可以跑带 TensorRT 加速的 YOLOv8m帧率能做到 25 到 30同时整体功耗控制在 15W 左右用一块 5V 4A 的 DC-DC 模块就能带起来。如果预算收紧换成树莓派 5 也能跑但模型要降级到 YOLOv8n帧率在 10 到 15 之间边缘检测能力会明显下降。2.3 通信与进程解耦的设计软件上我一开始就决定把视觉识别和伺服控制分成两个独立进程。原因很实际AI 推理是计算密集型任务帧率波动很大而云台控制是实时性要求很高的任务如果两个进程混在一起推理偶发卡顿会导致云台响应延迟看起来就像人在操作时“手抖”。实际实现里推理进程把目标检测结果写入共享内存结构体控制进程以固定 50ms 周期读取最新目标框并计算云台转角。就算推理掉帧到 5FPS控制进程也不会跟着掉节奏而是用卡尔曼滤波对目标轨迹做平滑预测。3. 视觉识别链路的搭建从YOLOv8到目标追踪这一层3.1 检测模型的选择与训练细节目标检测模型我最终选的是 YOLOv8m。原因一是精度和推理速度的平衡在边缘端最理想二是生态成熟从导出 ONNX 到转为 TensorRT 引擎都有现成工具链。训练数据没有完全从零标注而是以 COCO 数据集中的人、自行车、车辆类别为基础再补充几百张园区实际场景的巡检照片做微调主要目的是降低柏油路面、集装箱、夜灯光影等背景造成的误检。微调时冻结了前 10 层特征提取层batch size 设 16训练 200 轮测试集上的 mAP50 大约 0.87基本满足实用要求。模型转换是另一个容易被忽略的环节。直接从 PyTorch 权重部署到 Jetson 上推理延迟很难看正确做法是先用yolo export formatonnx导出再用 TensorRT 的trtexec工具生成 fp16 引擎。跑 fp16 精度损失很小但速度能比 fp32 快接近一倍。转换后我在实际输入分辨率 960x544 下测过单帧推理约 18 到 22 毫秒这个数字基本够用了。3.2 目标追踪防止跟丢的ByteTrack单帧检测只能告诉你目标“这一刻在哪里”无法告诉你“这是刚才那个目标还是新出现的目标”。追踪模块的作用就是把连续帧的检测框关联起来给每个目标分配稳定的 ID。我用了 ByteTrack而不是 DeepSORT。原因是 ByteTrack 不依赖额外的行人重识别网络计算量小得多而且在目标被短暂遮挡后重新出现的场景里表现并不比 DeepSORT 差太多。它通过卡尔曼滤波预测每个目标在下一帧的位置再结合检测框的 IoU 或位置距离做匹配。对边缘设备来说这种方案足够轻量且稳定。3.3 电子围栏与入侵判定逻辑识别和追踪只能告诉你“画面里有人”但系统真正要回答的问题是“这个人该不该触发告警”。我在地面节点上配置了电子围栏在图像坐标系下用多边形标注出重点防护区域目标被追踪后系统计算目标框底边中心点是否落在围栏多边形内部。一旦越界系统立刻锁定这个目标 ID联动示警模块并开始记录完整事件片段。围栏参数不需要改代码Web 控制台里直接用鼠标拖拽多边形顶点即可。这个设计让 Aegis Control 也能适应不同场地换到一个新区域时不用重新编译程序。3.4 漏检和误报处理策略误报是最容易让人对系统丧失信心的因素。飞鸟、飘过的塑料袋、树影晃动在最开始测试时都会触发告警。我加了两层过滤第一层是多帧确认目标必须在连续 5 帧内都被检测到且通过围栏判定才正式触发示警这个策略把单帧误检的干扰基本滤掉了第二层是置信度动态阈值白天光线好时阈值为 0.5夜间会自动降到 0.35因为夜间图像对比度低模型输出的置信度普遍偏低用一个固定阈值会导致夜间漏检率升高。漏检则是另一个方向的问题。当目标被遮挡导致连续丢帧时ByteTrack 的卡尔曼滤波还能维持短暂预测但如果超过 3 秒仍未重新检测到系统就认为目标丢失然后进入重搜索状态保留目标最后出现的位置驱动云台在那个区域小幅往复扫描同时准备触发无人机接力。4. 哨戒炮塔的伺服控制从空间坐标到云台角度4.1 云台结构设计与坐标换算炮塔的机械结构我采用的是水平步进加俯仰舵机的组合。水平方向是主要承力方向需要面对风力、线缆拉力和转动惯量用 MG996R 舵机虽然便宜但存在明显回差转动停止后会有 1 到 2 度的旷量反映在画面上就是目标框轻微抖动。步进电机配闭环编码器就没有这个问题。俯仰方向负载小用舵机就够。结构上用两块数控切割的铝合金侧板做支撑中间夹住步进电机和摄像头模组整体重量控制在 1.2 公斤以内独立安装在一根立杆上。目标像素坐标到云台角度的换算公式并不复杂。水平角速度等于像素误差除以画面像素宽度再乘以镜头水平视场角最后乘一个缩放系数俯仰方向同理只是用垂直视场角计算。实际使用时还需要把镜头的安装高度和俯仰零位考虑进去做一次简单的三角函数标定。4.2 PID跟踪环与平滑控制云台控制核心是一个位置环加速度环的 PID。控制进程每 50ms 读取一次目标框中心坐标与画面中心比较得到误差然后计算期望转动速度pan_speed Kp * error Kd * d(error)/dt Ki * integral(error)我调试出来的参考参数是 Kp1.8Kd0.12Ki0.05。注意 Ki 务必设得很小因为云台本来就存在静摩擦积分项加多了会造成低速时的反复振荡。调试顺序上先只加比例项让云台能跟随目标但可能有来回摆动再加入微分项抵消摆动最后才加一点点积分消除残余静差。这个顺序几乎适用于所有类似的云台追踪项目比一上来就三个参数一起调效率高得多。4.3 非杀伤性警戒输出与安全锁定炮塔下方安装了独立的声光报警模块和一支 5mW 激光指示器。触发条件有两个目标被确认闯入电子围栏且锁定状态持续超过 3 秒。声光报警用于驱离警示激光指示器用于把目标标记出来方便远程值守人员快速确认。这里我要刻意说明整套系统没有设计任何发射机构也不打算接入任何具有伤害性的执行器。Aegis Control 的定位是“发现目标、锁定目标、示警目标、取证上报”杀伤性输出会带来不可控的法律和安全风险对演示、开源和实际部署都不合适。安全锁定逻辑也需要考虑周全。云台水平方向虽然能连续旋转但俯仰舵机有机械限位我加了两级保护软件层在角度接近限位前 5 度就停止加速硬件层用限位开关切断驱动信号。每次系统启动时云台自动归零通信断连超过 2 秒则回到安全位并停用示警模块避免误触。5. 无人机系统协同什么时候起飞、怎么接力5.1 为什么必须有空中节点地面炮塔的射角再好也受安装高度和周边遮挡物的限制。测试中我发现一个很现实的场景目标识别到后沿着围墙外侧跑绕过一排集装箱地面节点就彻底丢失目标了。如果用无人机从 20 米高度俯视这个盲区几乎不存在。所以 Aegis Control 的关键不只是“追踪”而是“接力追踪”地面丢失目标后派出无人机到目标最后出现的位置上空重新建立视觉接触然后持续跟踪直到目标离开防护区或无法继续追踪为止。5.2 MAVLink通信基础与命令通道无人机飞控用的 Pixhawk 6C跑的是 ArduPilot。它与指挥中心之间通过一个 WiFi 数传模块建立 MAVLink 连接。控制代码里用 DroneKit 或 pymavlink 下发指令常用的有三类MAV_CMD_COMPONENT_ARM_DISARM控制解锁上锁SET_POSITION_TARGET_LOCAL_NED控制飞往指定相对位置MAV_CMD_CONDITION_YAW控制机头朝向。起飞和降落我直接用了 ArduPilot 的 AUTO 模式任务而不是手动给油门这样安全性更高。5.3 接力触发逻辑与起飞决策接力触发的条件我设置得比较保守。地面节点连续丢失目标超过 3 秒目标最后出现的位置在无人机可飞行半径内默认 150 米且无人机电量高于 60%、GPS 定位有效这三个条件同时满足才会自动下发任务。前两个条件缺一个都不会启动避免无人机因为短暂误丢目标就频繁起降。无人机起飞后先飞到目标丢失位置上空 20 米然后开启机载摄像头用同一套 YOLO 模型在视野内重新搜索目标。找到目标后无人机进入跟随模式保持与目标的相对方位持续录像并把实时画面推回控制台。5.4 目标交接的坐标换算“地面炮塔最后看到的目标位置”需要转化成无人机能理解的经纬度或局部 NED 坐标这里有一个坐标换算的关键步骤。地面节点通过自身经纬度、云台水平角和俯仰角以及摄像头安装高度计算目标的地面偏移距离。水平距离等于高度乘以俯仰角的正切东西方向和南北方向的偏移再通过对水平角取正弦余弦得到。这个计算带到无人机飞控里就是一组局部 NED 坐标精度在 10 米左右。这个精度不够直接命中目标但足以让无人机飞到目标附近再通过机载视觉精确定位。这也说明视觉接力比单纯靠 GPS 定位可靠得多。5.5 返航与降级机制无人机自动任务必须有退路。我设置了三级降级逻辑电量低于 40% 时停止接受新接力任务但仍在执行的任务可以继续电量低于 30% 触发返航目标丢失或遇到高风速时提前终止任务整套系统还有一个总超时保护无人机起飞时间超过 8 分钟自动强制返航防止任何逻辑僵死导致电量耗尽。测试下来这个策略虽然没有用到极端情况但让我在调试阶段面对各种异常参数时心里踏实很多。6. 实测效果与踩坑记录6.1 测试场景与基准数据我们在约 200 米乘 150 米的场地里做了两轮测试一轮白天、一轮夜间。日间测试中YOLOv8m 在 30 到 45 米的距离上可以稳定识别站立和行走的人云台水平跟踪角速度实测可以达到每秒 60 度对正常步速的行人跟踪没有压力声光报警触发到控制台收到事件通知的延迟在 0.8 秒左右。夜间加装红外补光后识别距离回落到 25 米左右关键是不要把补光灯直接装在摄像头正上方会产生严重的逆光反光。无人机接力这个环节从指挥中心下达起飞命令到旋翼解锁升空约 8 到 12 秒属于较慢但可接受的响应。6.2 最折腾人的几个坑问题根因解决方案远程画面频繁掉帧GStreamer 默认 jitter buffer 不足调整rtpjitterbuffer延迟参数让视频流不抢控制指令的带宽云台跟踪时画面抖动水平舵机齿轮回差过大水平换闭环步进俯仰保留舵机边缘端长时间运行降频卡顿Orin Nano 散热不足加装主动散热风扇并在软件层限制检测帧率不超过 25FPS无人机GPS在围墙边跳变多路径效应导致定位漂移增加航点平滑逻辑起飞后先爬升再平移飞鸟反复误触报警单帧检测误报多帧确认加电子围栏边界缓冲带这些坑里最典型的是边缘端降频。当时项目第一次跑到 30 分钟推理帧率从 28 一路掉到 11查了半天发现是核心温度飙到了 85 度以上Orin Nano 自动降频保护。这个问题在 Jetson 系列上非常常见不是换软件能解决的老老实实加强散热比优化代码重要得多。6.3 调优路径与参数记录最值得归档的调试经验是任何参数改动都必须只改动一个变量然后观察至少 10 分钟。比如 PID 参数我只调 Kd测试云台在目标静止时的稳定性和目标突然移动后的超调量确认没问题再调 Ki。音频报警的触发时长也从 3 秒试到 10 秒最终定在 3 秒既能滤掉误报又不会让真正闯入者走太远。所有参数我都在 Web 控制台里做成了可配置项不用重新编译程序大大缩短了迭代周期。7. 合规与安全边界这个项目里必须守住的底线7.1 非杀伤性示警的设计约束把项目命名为“哨戒炮塔”确实容易让人联想到武器所以我在设计之初就明确了一个原则这套系统没有任何发射机构输出手段只有声光报警、激光指示、录像取证和远程通知。这样的定位有几个好处。第一部署在公共或半公共区域时合规性风险极低第二可以把技术精力集中在视觉跟踪和控制逻辑上而不是花在危险的机械执行机构上第三作为开源项目分享不会因为安全审核问题被平台下架。如果你也要仿照这个项目我的建议非常直接把论文、资料的重点放在“如何识别、如何跟踪、如何协同”上千万不要引入任何具备伤害能力的执行部件。7.2 飞行合规与数据保护无人机部分首先要考虑空域合规。测试场地必须避开机场净空区、禁飞区、人群密集区飞行高度不要超过 120 米并且始终保持视距内或至少远程可监控状态。不同地区对无人机飞行的具体规定有差异动手前务必查清楚当地现行要求。隐私方面Aegis Control 的录像策略是“事件触发录制”没有触发事件时不保留连续录像目标人脸在控制台上也做了模糊处理只有授权账号可以查看清晰原图。这些细节让整套系统更接近“可信的安防工具”而不是“无差别的监控机器”。7.3 开源与模块复用建议Aegis Control 的代码我做成了三部分视觉推理服务、地面控制服务、Web 前端。视觉推理服务可以单独拆出来放在任意一台普通电脑上跑配合普通 USB 摄像头就能做一个简单的闯入检测器地面控制服务也可以拆出来配合任何一个串口控制的云台使用。如果你要参考这个项目不必一步到位复刻整套系统先把视觉推理和云台跟踪打通再考虑接入无人机循序渐进会顺利得多。最后说点实操感受。这类系统的核心难点其实不在 AI 识别精度上而在控制闭环的稳定性和系统集成的各种“最后一公里”问题。模型准确率从 0.85 提升到 0.92感觉并不明显但云台每次跟丢目标需要人工复位、无人机因为通信延迟飞偏方向这些都是实打实影响可用性的问题。把目标检测跑通只是第一步能让云台持续稳定跟上目标、能让无人机在正确时机升空接力、能在无人干预的情况下连续运行一整晚才算是一个真正能交出去的系统。
AI哨戒炮塔与无人机联动：边缘智能安防系统实践
我在一个占地接近两个标准足球场的仓储园区做安防改造时遇到过一个特别典型的问题固定摄像头把主干道和出入口照得清清楚楚但园区边缘的围墙死角一旦有人翻进来监控最多只能拍到一条腿的残影。等第二天发现异常人都走了好几个小时。后来我逐步把它做成了一套 AI 值守的哨戒炮塔与无人机联动系统也就是 Aegis Control。地面端是一台可以自动转动的云台“炮塔”空中端是一架可随时起飞的无人机两者共用一套视觉识别模型识别到闯入者后接力追踪、持续示警并保留完整证据链。这篇文章就把整个项目从立项背景、硬件选型、视觉链路、伺服控制到无人机协同展开说清楚适合正在做嵌入式 AI、开源无人机、安防巡检方向的人参考。1. 为什么我会做一个“有腿的摄像头”项目立项背景与痛点1.1 固定监控的三个核心问题传统安防监控系统在园区这种场景里存在三个无法回避的短板。第一个是视角固定。再好的摄像头装上去之后可视范围就是一锤子买卖除非你部署足够多、足够密否则总有遮挡和死角第二个是没有主动预警能力。普通摄像头只是被动录像画面里发生了什么都得靠人盯着屏幕或者事后翻录像入侵发生的那一刻它不会主动通知任何人第三个是无法持续跟随。即便你看到了可疑目标摄像头也没法自动转动去锁定它目标一旦走出画面线索就断了。这三个问题放在一起结果就是装了监控不等于有人值守录了像不等于抓得到人。我做这个项目的初衷不是要搞一个玩票的玩具而是想验证一套能够“自动发现、持续跟踪、主动示警”的端到端系统看它能不能真正承担一部分夜间巡逻和边界值守的工作。1.2 方案设想固定哨戒加空中侦察的两级值守那段时间我刚好在接触边缘端的 AI 推理也在玩开源飞控于是很自然地把两个方向合在了一起。地面的“哨戒炮塔”本质上是一个搭载摄像头、可双向转动的云台AI 识别到可疑目标之后云台自动旋转让目标始终保持在画面中央但如果目标跑出了炮塔的射角范围或者进入了围墙另一侧的低洼区域地面视角就失效了。这时候就需要一个能离开固定位置、从空中俯瞰的节点也就是无人机。所以 Aegis Control 并不是单纯的云台追踪也不是单纯的无人机巡逻而是要把两个节点串成一个两级值守系统地面节点负责常态监控和快速响应空中节点负责补盲和接力追踪。项目名字里 Aegis 取的是“盾牌、守护”的意思Control 代表的是整个决策和控制链路。整体定位是安防巡检与行为示警不涉及任何杀伤性输出。1.3 为什么不直接买成品安防系统市面上带自动跟踪的安防球机并不少海康、大华都有类似产品直接买一套不省事吗但我当时的真实需求是这套系统必须能二次开发。我需要它在识别到目标后不只是在本地录像还要把目标坐标通过结构化数据发出去需要它能和无人机飞控联动需要我能随时把自己训练的模型换进去。成品设备的固件大多是封闭的做不到这些事。另外成品的跟踪逻辑是黑盒误报了你不知道它为什么误报也没法针对你所在的园区做参数优化。从投入角度看自己攒一套基于开源框架的系统前期研发成本高但后期可以持续迭代逻辑透明可控我觉得这笔账是值得的。2. 系统架构与关键选型先把骨架搭对再谈AI2.1 整体拓扑地面节点、空中节点与指挥中心整套系统分成三个角色。地面哨戒节点是核心包含云台机构、摄像头、边缘计算板卡和声光示警模块负责目标检测、跟踪、示警和视频推流。空中节点是可垂直起降的四轴无人机搭载机载摄像头和飞控通过 WiFi 数传链路与指挥中心通信负责接到命令后起飞补盲。指挥中心是部署在局域网内的一台 PC运行 Web 控制台显示实时视频流、目标标记框、轨迹路径和系统状态同时支持手动接管云台或下达无人机任务。数据流上我做了明确的分离视频流走 RTSP控制指令走私有 WebSocket无人机指令走 MAVLink。这样做的原因是三类数据对网络的要求完全不同视频流要求低延迟但可以容忍轻微丢包控制指令要求可靠性和实时性无人机指令要求协议语义明确。混在一个通道里出问题时很难排查。2.2 硬件选型明细模块选型关键参数说明边缘计算板卡NVIDIA Jetson Orin Nano 8GB可跑 YOLOv8m支持 TensorRT 加速摄像头USB 全局快门相机支持 MIPI 转接减少卷帘快门带来的画面果冻效应云台电机俯仰用 MG996R 舵机水平用闭环步进电机水平方向负载大、需要定位精度步进更合适示警输出声光报警器加激光指示器非杀伤性用于警示与标记目标飞控Pixhawk 6C 配合 ArduPilot开源、可通过 MAVLink 二次开发机架550 轴距四轴机架留足载重可挂相机和数传模块机载图传WiFi 数字图传模块与地面站局域网直连无额外中转选 Jetson Orin Nano 是综合考虑了算力、功耗和开发效率的结果。它的 8GB 显存可以跑带 TensorRT 加速的 YOLOv8m帧率能做到 25 到 30同时整体功耗控制在 15W 左右用一块 5V 4A 的 DC-DC 模块就能带起来。如果预算收紧换成树莓派 5 也能跑但模型要降级到 YOLOv8n帧率在 10 到 15 之间边缘检测能力会明显下降。2.3 通信与进程解耦的设计软件上我一开始就决定把视觉识别和伺服控制分成两个独立进程。原因很实际AI 推理是计算密集型任务帧率波动很大而云台控制是实时性要求很高的任务如果两个进程混在一起推理偶发卡顿会导致云台响应延迟看起来就像人在操作时“手抖”。实际实现里推理进程把目标检测结果写入共享内存结构体控制进程以固定 50ms 周期读取最新目标框并计算云台转角。就算推理掉帧到 5FPS控制进程也不会跟着掉节奏而是用卡尔曼滤波对目标轨迹做平滑预测。3. 视觉识别链路的搭建从YOLOv8到目标追踪这一层3.1 检测模型的选择与训练细节目标检测模型我最终选的是 YOLOv8m。原因一是精度和推理速度的平衡在边缘端最理想二是生态成熟从导出 ONNX 到转为 TensorRT 引擎都有现成工具链。训练数据没有完全从零标注而是以 COCO 数据集中的人、自行车、车辆类别为基础再补充几百张园区实际场景的巡检照片做微调主要目的是降低柏油路面、集装箱、夜灯光影等背景造成的误检。微调时冻结了前 10 层特征提取层batch size 设 16训练 200 轮测试集上的 mAP50 大约 0.87基本满足实用要求。模型转换是另一个容易被忽略的环节。直接从 PyTorch 权重部署到 Jetson 上推理延迟很难看正确做法是先用yolo export formatonnx导出再用 TensorRT 的trtexec工具生成 fp16 引擎。跑 fp16 精度损失很小但速度能比 fp32 快接近一倍。转换后我在实际输入分辨率 960x544 下测过单帧推理约 18 到 22 毫秒这个数字基本够用了。3.2 目标追踪防止跟丢的ByteTrack单帧检测只能告诉你目标“这一刻在哪里”无法告诉你“这是刚才那个目标还是新出现的目标”。追踪模块的作用就是把连续帧的检测框关联起来给每个目标分配稳定的 ID。我用了 ByteTrack而不是 DeepSORT。原因是 ByteTrack 不依赖额外的行人重识别网络计算量小得多而且在目标被短暂遮挡后重新出现的场景里表现并不比 DeepSORT 差太多。它通过卡尔曼滤波预测每个目标在下一帧的位置再结合检测框的 IoU 或位置距离做匹配。对边缘设备来说这种方案足够轻量且稳定。3.3 电子围栏与入侵判定逻辑识别和追踪只能告诉你“画面里有人”但系统真正要回答的问题是“这个人该不该触发告警”。我在地面节点上配置了电子围栏在图像坐标系下用多边形标注出重点防护区域目标被追踪后系统计算目标框底边中心点是否落在围栏多边形内部。一旦越界系统立刻锁定这个目标 ID联动示警模块并开始记录完整事件片段。围栏参数不需要改代码Web 控制台里直接用鼠标拖拽多边形顶点即可。这个设计让 Aegis Control 也能适应不同场地换到一个新区域时不用重新编译程序。3.4 漏检和误报处理策略误报是最容易让人对系统丧失信心的因素。飞鸟、飘过的塑料袋、树影晃动在最开始测试时都会触发告警。我加了两层过滤第一层是多帧确认目标必须在连续 5 帧内都被检测到且通过围栏判定才正式触发示警这个策略把单帧误检的干扰基本滤掉了第二层是置信度动态阈值白天光线好时阈值为 0.5夜间会自动降到 0.35因为夜间图像对比度低模型输出的置信度普遍偏低用一个固定阈值会导致夜间漏检率升高。漏检则是另一个方向的问题。当目标被遮挡导致连续丢帧时ByteTrack 的卡尔曼滤波还能维持短暂预测但如果超过 3 秒仍未重新检测到系统就认为目标丢失然后进入重搜索状态保留目标最后出现的位置驱动云台在那个区域小幅往复扫描同时准备触发无人机接力。4. 哨戒炮塔的伺服控制从空间坐标到云台角度4.1 云台结构设计与坐标换算炮塔的机械结构我采用的是水平步进加俯仰舵机的组合。水平方向是主要承力方向需要面对风力、线缆拉力和转动惯量用 MG996R 舵机虽然便宜但存在明显回差转动停止后会有 1 到 2 度的旷量反映在画面上就是目标框轻微抖动。步进电机配闭环编码器就没有这个问题。俯仰方向负载小用舵机就够。结构上用两块数控切割的铝合金侧板做支撑中间夹住步进电机和摄像头模组整体重量控制在 1.2 公斤以内独立安装在一根立杆上。目标像素坐标到云台角度的换算公式并不复杂。水平角速度等于像素误差除以画面像素宽度再乘以镜头水平视场角最后乘一个缩放系数俯仰方向同理只是用垂直视场角计算。实际使用时还需要把镜头的安装高度和俯仰零位考虑进去做一次简单的三角函数标定。4.2 PID跟踪环与平滑控制云台控制核心是一个位置环加速度环的 PID。控制进程每 50ms 读取一次目标框中心坐标与画面中心比较得到误差然后计算期望转动速度pan_speed Kp * error Kd * d(error)/dt Ki * integral(error)我调试出来的参考参数是 Kp1.8Kd0.12Ki0.05。注意 Ki 务必设得很小因为云台本来就存在静摩擦积分项加多了会造成低速时的反复振荡。调试顺序上先只加比例项让云台能跟随目标但可能有来回摆动再加入微分项抵消摆动最后才加一点点积分消除残余静差。这个顺序几乎适用于所有类似的云台追踪项目比一上来就三个参数一起调效率高得多。4.3 非杀伤性警戒输出与安全锁定炮塔下方安装了独立的声光报警模块和一支 5mW 激光指示器。触发条件有两个目标被确认闯入电子围栏且锁定状态持续超过 3 秒。声光报警用于驱离警示激光指示器用于把目标标记出来方便远程值守人员快速确认。这里我要刻意说明整套系统没有设计任何发射机构也不打算接入任何具有伤害性的执行器。Aegis Control 的定位是“发现目标、锁定目标、示警目标、取证上报”杀伤性输出会带来不可控的法律和安全风险对演示、开源和实际部署都不合适。安全锁定逻辑也需要考虑周全。云台水平方向虽然能连续旋转但俯仰舵机有机械限位我加了两级保护软件层在角度接近限位前 5 度就停止加速硬件层用限位开关切断驱动信号。每次系统启动时云台自动归零通信断连超过 2 秒则回到安全位并停用示警模块避免误触。5. 无人机系统协同什么时候起飞、怎么接力5.1 为什么必须有空中节点地面炮塔的射角再好也受安装高度和周边遮挡物的限制。测试中我发现一个很现实的场景目标识别到后沿着围墙外侧跑绕过一排集装箱地面节点就彻底丢失目标了。如果用无人机从 20 米高度俯视这个盲区几乎不存在。所以 Aegis Control 的关键不只是“追踪”而是“接力追踪”地面丢失目标后派出无人机到目标最后出现的位置上空重新建立视觉接触然后持续跟踪直到目标离开防护区或无法继续追踪为止。5.2 MAVLink通信基础与命令通道无人机飞控用的 Pixhawk 6C跑的是 ArduPilot。它与指挥中心之间通过一个 WiFi 数传模块建立 MAVLink 连接。控制代码里用 DroneKit 或 pymavlink 下发指令常用的有三类MAV_CMD_COMPONENT_ARM_DISARM控制解锁上锁SET_POSITION_TARGET_LOCAL_NED控制飞往指定相对位置MAV_CMD_CONDITION_YAW控制机头朝向。起飞和降落我直接用了 ArduPilot 的 AUTO 模式任务而不是手动给油门这样安全性更高。5.3 接力触发逻辑与起飞决策接力触发的条件我设置得比较保守。地面节点连续丢失目标超过 3 秒目标最后出现的位置在无人机可飞行半径内默认 150 米且无人机电量高于 60%、GPS 定位有效这三个条件同时满足才会自动下发任务。前两个条件缺一个都不会启动避免无人机因为短暂误丢目标就频繁起降。无人机起飞后先飞到目标丢失位置上空 20 米然后开启机载摄像头用同一套 YOLO 模型在视野内重新搜索目标。找到目标后无人机进入跟随模式保持与目标的相对方位持续录像并把实时画面推回控制台。5.4 目标交接的坐标换算“地面炮塔最后看到的目标位置”需要转化成无人机能理解的经纬度或局部 NED 坐标这里有一个坐标换算的关键步骤。地面节点通过自身经纬度、云台水平角和俯仰角以及摄像头安装高度计算目标的地面偏移距离。水平距离等于高度乘以俯仰角的正切东西方向和南北方向的偏移再通过对水平角取正弦余弦得到。这个计算带到无人机飞控里就是一组局部 NED 坐标精度在 10 米左右。这个精度不够直接命中目标但足以让无人机飞到目标附近再通过机载视觉精确定位。这也说明视觉接力比单纯靠 GPS 定位可靠得多。5.5 返航与降级机制无人机自动任务必须有退路。我设置了三级降级逻辑电量低于 40% 时停止接受新接力任务但仍在执行的任务可以继续电量低于 30% 触发返航目标丢失或遇到高风速时提前终止任务整套系统还有一个总超时保护无人机起飞时间超过 8 分钟自动强制返航防止任何逻辑僵死导致电量耗尽。测试下来这个策略虽然没有用到极端情况但让我在调试阶段面对各种异常参数时心里踏实很多。6. 实测效果与踩坑记录6.1 测试场景与基准数据我们在约 200 米乘 150 米的场地里做了两轮测试一轮白天、一轮夜间。日间测试中YOLOv8m 在 30 到 45 米的距离上可以稳定识别站立和行走的人云台水平跟踪角速度实测可以达到每秒 60 度对正常步速的行人跟踪没有压力声光报警触发到控制台收到事件通知的延迟在 0.8 秒左右。夜间加装红外补光后识别距离回落到 25 米左右关键是不要把补光灯直接装在摄像头正上方会产生严重的逆光反光。无人机接力这个环节从指挥中心下达起飞命令到旋翼解锁升空约 8 到 12 秒属于较慢但可接受的响应。6.2 最折腾人的几个坑问题根因解决方案远程画面频繁掉帧GStreamer 默认 jitter buffer 不足调整rtpjitterbuffer延迟参数让视频流不抢控制指令的带宽云台跟踪时画面抖动水平舵机齿轮回差过大水平换闭环步进俯仰保留舵机边缘端长时间运行降频卡顿Orin Nano 散热不足加装主动散热风扇并在软件层限制检测帧率不超过 25FPS无人机GPS在围墙边跳变多路径效应导致定位漂移增加航点平滑逻辑起飞后先爬升再平移飞鸟反复误触报警单帧检测误报多帧确认加电子围栏边界缓冲带这些坑里最典型的是边缘端降频。当时项目第一次跑到 30 分钟推理帧率从 28 一路掉到 11查了半天发现是核心温度飙到了 85 度以上Orin Nano 自动降频保护。这个问题在 Jetson 系列上非常常见不是换软件能解决的老老实实加强散热比优化代码重要得多。6.3 调优路径与参数记录最值得归档的调试经验是任何参数改动都必须只改动一个变量然后观察至少 10 分钟。比如 PID 参数我只调 Kd测试云台在目标静止时的稳定性和目标突然移动后的超调量确认没问题再调 Ki。音频报警的触发时长也从 3 秒试到 10 秒最终定在 3 秒既能滤掉误报又不会让真正闯入者走太远。所有参数我都在 Web 控制台里做成了可配置项不用重新编译程序大大缩短了迭代周期。7. 合规与安全边界这个项目里必须守住的底线7.1 非杀伤性示警的设计约束把项目命名为“哨戒炮塔”确实容易让人联想到武器所以我在设计之初就明确了一个原则这套系统没有任何发射机构输出手段只有声光报警、激光指示、录像取证和远程通知。这样的定位有几个好处。第一部署在公共或半公共区域时合规性风险极低第二可以把技术精力集中在视觉跟踪和控制逻辑上而不是花在危险的机械执行机构上第三作为开源项目分享不会因为安全审核问题被平台下架。如果你也要仿照这个项目我的建议非常直接把论文、资料的重点放在“如何识别、如何跟踪、如何协同”上千万不要引入任何具备伤害能力的执行部件。7.2 飞行合规与数据保护无人机部分首先要考虑空域合规。测试场地必须避开机场净空区、禁飞区、人群密集区飞行高度不要超过 120 米并且始终保持视距内或至少远程可监控状态。不同地区对无人机飞行的具体规定有差异动手前务必查清楚当地现行要求。隐私方面Aegis Control 的录像策略是“事件触发录制”没有触发事件时不保留连续录像目标人脸在控制台上也做了模糊处理只有授权账号可以查看清晰原图。这些细节让整套系统更接近“可信的安防工具”而不是“无差别的监控机器”。7.3 开源与模块复用建议Aegis Control 的代码我做成了三部分视觉推理服务、地面控制服务、Web 前端。视觉推理服务可以单独拆出来放在任意一台普通电脑上跑配合普通 USB 摄像头就能做一个简单的闯入检测器地面控制服务也可以拆出来配合任何一个串口控制的云台使用。如果你要参考这个项目不必一步到位复刻整套系统先把视觉推理和云台跟踪打通再考虑接入无人机循序渐进会顺利得多。最后说点实操感受。这类系统的核心难点其实不在 AI 识别精度上而在控制闭环的稳定性和系统集成的各种“最后一公里”问题。模型准确率从 0.85 提升到 0.92感觉并不明显但云台每次跟丢目标需要人工复位、无人机因为通信延迟飞偏方向这些都是实打实影响可用性的问题。把目标检测跑通只是第一步能让云台持续稳定跟上目标、能让无人机在正确时机升空接力、能在无人干预的情况下连续运行一整晚才算是一个真正能交出去的系统。
