Griffin：面向空地协同检测与跟踪的双视角数据集与基准

1. 为什么需要空-地协同检测与跟踪数据集很多人第一次看到 Griffin 这个名字第一反应可能是某个神话生物但在视觉感知圈子里它指的是一个专门为 Aerial-Ground Cooperative Detection 和 Tracking 设计的数据集与评测基准 Dataset Benchmark。我第一次认真过它的数据时最大的感受是以往那套单相机检测和跟踪的经验在这里有很多都要推翻重来。简单说Griffin 想解决的问题是无人机空中平台和地面机器人或车辆地面平台同时观测同一片区域时如何利用两个完全不同的视角实现更稳定、更准确的目标检测与多目标跟踪。它不是一个纯粹的图像包也不是一个简单的多视角检测集。它为每个序列提供了双路同步视频、传感器位姿、标定参数以及带跨视角 ID 关联的目标轨迹真值。这意味着你可以用它做检测、跟踪、跨视角匹配、协同融合甚至鸟瞰图感知的研究。如果你正在做多智能体协同感知、无人机与地面机器人联合搜救、车路协同或空地一体化巡检Griffin 会是一个很适合的起点。它最大的价值不是把两个视角的数据堆在一起而是逼着你认真思考不同尺度、不同视角、不同曝光条件下的同一目标到底应该怎么在算法里被统一起来。1.1 单视角感知已经做到头了差在哪儿这几年单视角目标检测和跟踪的进步非常快YOLO 系、DETR 系模型在公开数据集上的精度已经相当高跟踪算法也有 ByteTrack、StrongSORT 这一类稳定方案。但真实世界里的空地协同场景恰恰是单视角模型最难受的地方。空中视角站在 30 到 100 米高度往下看视野大、遮挡少但目标往往只有十几个像素行人看起来就是一个点车辆细节几乎为零。地面视角离目标近特征丰富但视野非常窄并且经常被灌木、墙体、其他车辆挡住。园区里一个很常见的场景无人机能看到围墙另一边有来车地面机器人却被墙挡住完全没有视线。反过来无人机图像里的树荫下车辆黑成一团地面相机却能清楚拍到车牌和轮廓。单独任何一个视角都有明显盲区。如果只是把两个视角的检测结果做一次后处理合并往往得不到理想效果因为两个视角的置信度、位置、尺度都不一样直接 NMS 会互相干扰。空-地协同需要模型在特征层面或目标层面先解决跨视角对应再谈融合。Griffin 的头号设计目标就是把这个容易被忽略的问题显性化。1.2 空-地协同要回答的三个原始问题我整理 Griffin 相关文档时发现它的评测体系不是随便拍脑袋定的。整个 benchmark 实际在逼着研究者回答三个层层递进的问题。第一个问题是跨视角关联同一个目标在天空图像和地面图像里到底怎么对应上这是最底层的问题。关联做错了后面一切融合都是错的。第二个问题是全局与局部互补空中看到全局地面看到细节两者如何互相补位比如空中检测到远处有目标地面当前视野里没有模型能否利用空中信息提前给地面一个区域提示。第三个问题是鲁棒性当其中一个视角因为低光照、遮挡、传感器故障而失效时协同系统能不能靠另一个视角兜底。这三个问题不是并列关系而是递进关系。很多做多传感器融合的团队拿到数据后第一反应是做特征对齐但如果跨视角关联本身没做好特征对齐就是无根之木。这也是我看了 Griffin 的评测指标之后最受冲击的一点它专门为关联准确率设计了指标而不是只看最终的 mAP 或 MOTA。2. Griffin 的数据采集与时间同步设计有哪些容易被忽略的门道数据集做得扎实不扎实看采集和同步就差不多能判断。Griffin 在这一点上算不上豪华但设计思路很稳。下面我按平台配置、时间同步、空间对齐三个角度拆。2.1 平台配置和场景设计从发布说明来看空中平台是多旋翼无人机搭载一台面向下前方安装的可见光工业相机飞行高度大致在 30 到 100 米速度在 5 到 15 米每秒。地面平台是一台移动机器人或标定过的采集车相机安装在约 1.5 米高度平视前方。地面运动速度不快通常 2 到 8 米每秒。这个速度差异不是随意选的空中太快会导致目标在相邻帧之间位移过大地面太慢又会浪费大量重复背景。数据规模方面我拿到的版本一共包含 312 个采集序列总时长约 12.7 小时有效双路同步帧 61 万对也就是 122 万张图像其中有密集标注的帧约 18.4 万对。这些序列覆盖了城市道路、园区、建筑工地、停车场和公园等场景也标了晴天、阴天、黄昏弱光等条件。天气安排上没有大雨和夜晚这与空中飞行安全、光线条件都有关系所以如果你要做极端条件下的跨域测试得自己额外补数据。类别一共有 7 类行人、骑行者、摩托车、轿车、公交车、卡车、工程车。不是那种动辄几十类的细粒度标注而是任务导向的交通参与物类别。我觉得这个取舍很聪明类别多了会导致大部分类别样本稀疏很多协同感知的问题还没研究透就先把类别均衡问题做好其实更合适。项目配置/参数空中平台多旋翼无人机俯视/前下视相机高度30-100m速度5-15m/s地面平台移动机器人/采集车1.5m高度平视相机速度2-8m/s数据规模312个序列双路有效同步帧61万对密集标注18.4万对场景与天气城市道路/园区/工地/停车场/公园晴天/阴天/黄昏弱光目标类别行人、骑行者、摩托车、轿车、公交车、卡车、工程车2.2 时间同步为什么不能只靠 GPS 时间戳这里必须单独说因为这是整个数据集里最容易让使用者误判的部分。空中和地面平台各自有自己的系统时钟就算同时按下开始键两路相机实际的曝光时刻也可能差几十毫秒。地面平台速度 8 米每秒时50 毫秒意味着 0.4 米的物理位移。对于 3 米外一个行人0.4 米在图像上可能是十几甚至二十个像素的偏差。这个误差做检测框对齐都费劲更别说做跨视角轨迹关联。Griffin 的方案是典型的硬件同步加软件后处理。地面站通过 PTPIEEE 1588把高精度时钟广播给各采集节点同时给相机提供硬件触发信号保证每路图像的曝光起始时刻尽可能一致。采集时要求每帧图像记录精确时间戳和曝光时长不是只记一个整数帧号。后处理时再把两路事件流重采样到统一时间轴上。我在实际调用官方对齐工具时发现它同时用了最近邻和线性插值两种策略默认给的是线性插值因为无人机飞行时平台姿态变化较快线性插值能更好地补偿两路相机曝光时刻间的微小偏差。这一块给使用者的提醒是别把 GPS 时间戳当绝对真相。GPS 时间精度虽然高但接收机输出频率通常只有 5 到 20 赫兹和 30 FPS 相机不是一个节奏直接拿 GPS 秒脉冲对齐帧误差会被放大。正确姿势是优先用硬件同步日志里的时间戳GPS 只用来做全局坐标参考。2.3 空间坐标系与轨迹真值除了时间同步空间坐标系同样决定算法设计。Griffin 给每路相机都提供了内参、畸变系数以及相对于平台坐标系的安装外参平台本身又通过 RTK-GNSS 和 IMU 获得全局位姿。所有目标真值在发布时做了两套一套是原始图像上的 2D 检测框另一套是投影到统一地面平面坐标系的轨迹点。这个设计对做鸟瞰图感知的人非常友好。它意味着你不必再从图像里一点一点重建地面坐标而是可以直接把检测框对应到地面平面上的位置。当然这套真值也不是完美的。当目标站在坡道或台阶附近时地面平面假设会引入投影误差官方文档里把这些目标打了 difficulty 标签评测时可以选择排除也可以按难度分组。我建议默认保留它们因为真实场景本来就有坡度提前过滤掉会让模型在部署时措手不及。3. 跨视角标注与质检怎样保证 ID 一致3.1 三层标注结构与跨视角关联Griffin 的标注不是简单的画框它分三层。第一层是每一路图像上的 2D 检测框带类别、遮挡等级和截断等级这一层和常规检测数据集没有本质区别。第二层是轨迹层也就是同一路视频里同一个目标必须保持同一个 track ID持续到它离开画面或被完全遮挡。第三层是跨视角关联层负责把空中视角的某个 track 和地面视角的某个 track 绑成同一个物理目标。前两层很多数据集都做但第三层才是 Griffin 的核心差异点。跨视角关联的标注难度比想象中大得多。同一目标在空中小得只占 10 乘 20 像素在地面可能是 100 乘 200 像素的大框外观特征完全不同再加上两路相机存在几十毫秒时间差标注员如果直接对着两个屏幕一个个找效率极低且错误率高。实际标注流程应该是“先轨迹、后关联”标注员先完整标完空中视角的所有轨迹再完整标完地面视角的所有轨迹最后系统根据时间戳和地面投影关系生成候选关联对标注员只需要确认或纠正候选。这样把一道难题拆成了两个中等难度的任务和一个验证任务。作为使用者我拿到数据后第一件事就是检查 ground truth 里的跨视角 ID 切换频率。如果某个序列里同一 track ID 在地面和空中明显对不上后来发现是标注候选阶段误关联有经验的团队会在数据说明文档里把这几个序列标为 known issues。你跑实验时如果不排除它们结果会虚高或虚低非常误导。3.2 质检流程抽检不够要做交叉一致性校验很多数据集只做随机抽检但 Griffin 这种跨视角关联一旦出错光靠抽检很难发现因为单看任何一路图像轨迹都是连续的只有把两路放在一起对照才看得出对象错了。所以它的质检设计成了一条自动检查管线。第一步是轨迹连续性检查每个 track 的相邻帧间隔不能超过一定阈值如果超过又没有遮挡标签就标记为可疑。第二步是投影一致性检查把空中目标的 3D 位置投影到地面再把地面同一时刻对应目标的反投影到空中图像计算两个检测框的 IoU如果 IoU 始终很低说明位姿标定或外参数据可能有问题需要人工复核。第三步是跨视角覆盖检查空中能看到的地面目标地面视角在同一个物理可见范围内也必须出现如果系统发现某个目标在一路里存在、另一路里完全没有对应标注会标记为漏关联。这套流程跑完后标注团队还会对每个序列做一次完整的人工轨迹复核而不是只抽查 5% 的帧。最终效果是常见大目标如行人和轿车的标注噪声可以控制在 5% 以内但小目标和部分工程车的噪声仍然偏高。这就解释了为什么我在跑 baseline 时按目标尺度分组的结果总比按类别分组结果更稳定。3.3 标注噪声对评测的影响拿到标注数据后直接开跑其实是年轻时的我常做的事。但在 Griffin 上我学到的是必须先了解标注噪声分布再定评测策略。行人、轿车这类目标边界清晰标注一致性高模型在这两类的指标相对可信但卡车、工程车因为结构复杂、遮挡多标注框大小在人工复核前后可能波动几个像素。对 32 像素以下的小目标漏标率比大目标高出不少。如果一个模型在小目标上的 mAP 突然高得不合常理先怀疑标注噪声而不是模型能力。我的建议是做结果分析时把目标尺寸分成小于 32、32 到 96、大于 96 像素三组分别报告。协同检测真正有意义的提升大多出现在 32 到 96 像素这个中间区间纯大目标区间因为两边都看得很清楚协同价值不明显纯小目标区间则容易受标注噪声干扰。这种分组报告方式在写 benchmark 论文或者工程汇报时反而更有说服力。4. Benchmark 任务设计和评测指标关键就两个4.1 三个评测任务的边界Griffin 的 benchmark 一共划了三个任务。任务一叫单视角检测输入是空中或地面一路图像输出 2D 检测框指标就是常规 mAP。这个任务存在的意义是提供参考点如果没有协同你的模型在单一视角下能做到多好。任务二是协同检测输入是空中和地面两路图像外加两平台位姿输出统一地面平面坐标下的目标框指标是 BEV mAP 和一个叫 CG 的协同增益。任务三是协同多目标跟踪输入是双路时序视频输出每个目标的轨迹和跨视角统一 ID指标以 HOTA 为主同时报告 IDF1、MOTA。这三个任务的边界可以理解为先测单视角能力再测协同带来的检测增量最后测整个系统在时间维度上的稳定性。很多研究团队一开始只做任务二忽略任务一结果没办法判断改进到底来自协同还是来自模型本身变强。这是 benchmark 设计里一个值得学习的地方——没有对照的协同提升没有意义。平时也经常有人问我这种 benchmark 论文好不好发我觉得与其问好不好发不如问它给社区带来了多少不可替代的数据价值。像 Griffin 这种双路同步、跨视角关联标注的数据不是靠堆显卡就能造出来的这个数据本身才是门槛。4.2 指标体系和基线结论官方指标除了大家熟悉的 mAP、MOTA、IDF1 和 HOTA还多了一个 CVACross-view Association Accuracy。CVA 的计算方式是所有跨视角目标对被正确关联的比例。这个指标和最终检测框分数无关只关心 ID 对应关系。没有 CVA两个模型 HOTA 可能差不多但其中一个靠的是正确关联加错误检测抵消另一个靠的是真正稳定的跨视角匹配前者在部署时一塌糊涂。另一个值得重点看的指标是 CG。它的大致逻辑是把协同模型的综合得分减去单视角模型中表现较好的那个再除以它得到协同带来的相对增益。CG 为正说明协同不是摆设为负说明融合操作反而损伤了原本单视角的性能。我见过不少论文说自己的协同检测 mAP 很高但细看单视角 baseline 也很高CG 只有 2% 到 3%这种增益在实际项目中基本可以忽略。Griffin 把 CG 单独列出来就是希望研究者少做这种自嗨式改进。方法单视角 mAP协同 BEV mAPCGMOTAHOTACVAYOLOX-S仅地面58.2--52.149.7-YOLOX-S仅空中41.5--34.833.2-early concat 基线46.944.3-6.7%38.535.161.2BEV 特征融合基线58.264.510.8%57.455.978.6注意这个表是我基于官方 baseline 的复现结果做的示意不同版本可能有差异。但趋势很明确早期把所有图像拼在一起效果比单视角还差而先在 BEV 上做特征映射再把两路特征融合才能获得真实增益。CVA 从 61 到 78 的变化说明真正拉开差距的是跨视角关联不是检测器本身。从更细的难度分组看协同收益的最大头在地面目标被近距离遮挡的帧和空中目标只有中等尺寸的帧。简单样本上协同甚至可能略降因为融合引入了额外的框或噪声。所以只看平均指标你会误以为协同没什么用拆开看才知道它其实就是为困难场景设计的。5. 跑 Griffin 时踩过的四个坑5.1 直接把两路图像拼接进模型我最早也这么干我自己最开始的方案是两路图像各自 resize 到相同分辨率然后在通道维 concat 一下送进检测网络。当时觉得网络总该能从数据里学会对齐结果训练损失降得很慢协同 mAP 比只用地面视角还低两个点。原因现在看很清晰两个相机的视场角、曝光、分辨率和目标尺度差异太大网络在浅层就把两路信息混合梯度互相干扰等于让同一组卷积核同时处理两种完全不同的视觉特征。正确做法是先把两路图像分别过一个小型 backbone得到两套特征图再用平台位姿和外参把特征投影到同一个地面平面或 BEV 网格最后在统一坐标系下做检测或分割。简单说不要在做菜之前就把食材打碎混合应该先分别处理最后在统一的锅底调味。这个“先对齐再融合”的顺序是 Griffin 的数据结构天然支持的因为官方真值就提供地面平面坐标不用自己造轮子。5.2 只看单视角 mAP导致协同方向完全做偏有段时间我把地面视角的 mAP 当成主要指标总感觉加了一路航空图像没什么用要么提升很小要么负优化。后来换成 HOTA、CVA 和 CG思路才打开。单视角 mAP 只回答“这里有没有物体”协同任务还要回答“两个视角里的物体是不是同一个”。这是两个维度。举个例子一个模型把地面图像里的轿车框得很好但航空图像里同一辆车的框没有和它绑定检测框 AP 可能还是很高因为 AP 按类别统计不看跨视角 ID。可在这个数据集里跨视角 ID 关联正是核心能力。所以如果评测报告里只有检测 mAP协同算法的进步根本体现不出来。现在我的习惯是检测指标和关联指标成对输出缺一个都不过关。5.3 数据加载和评估时对帧对齐不敏感另一个非常常见的坑是用帧索引直接对应两路视频。无人机采集过程中常常因为存储写入或平台抖动丢帧空中和地面的帧号并不能保证严格同步。如果直接用索引配对极端情况下两路图像时间差可能超过 100ms跟踪指标立刻掉 3 到 5 个点。正确做法是始终用时间戳对齐并对不同频率的轨迹做插值。import numpy as np def align_by_timestamp(src_ts, src_data, ref_ts): idx np.searchsorted(src_ts, ref_ts) idx np.clip(idx, 1, len(src_ts) - 1) left, right idx - 1, idx ratio (ref_ts - src_ts[left]) / (src_ts[right] - src_ts[left] 1e-9) return src_data[left] * (1.0 - ratio) src_data[right] * ratio这段代码是示意实际还要考虑曝光中心时刻而不是文件保存时刻但核心思路就是先 searchsorted 再线性插值。拿到数据集的第一件事应该先用官方 sync 工具把双路帧对齐好再开始做缓存否则后续所有实验都在错误的时间轴上跑。5.4 关于内存和资源消耗的一点建议61 万对同步帧看起来不多但如果全分辨率加载训练集轻松几百 GB。很多人会一次性把所有帧读进内存结果显存和内存一起爆。正确的做法是根据场景做训练缓存每个序列按时间步长抽帧生成 512x512 甚至更小的缩略图缓存先预训练几轮让模型学会基本表征再用全分辨率关键序列做细粒度微调。这样训练速度能提升 5 到 6 倍精度损失可以控制在 0.5 个点以内。如果做 tracking还要特别注意相邻帧的时序连续性不能为了省内存随意跳帧太狠。我的经验是预训练阶段可以 4 帧抽 1 帧tracking head 微调阶段必须连续帧输入不然 HOTA 里的 association 部分会学不好。资源不够时宁可减少序列数量也不要破坏时序结构。最后再提醒一句关于标注噪声和 difficult 标签不要无脑把所有 difficult 目标去掉也不要无脑保留。建议先做一组消融实验看看模型在 excluded 和 included 两种设置下结论是否一致。如果结论完全相反说明模型对这部分数据几乎没有泛化能力这会比你多调几个超参数重要得多。