RoboMaster雷达站目标检测：数据采集、YOLOv8优化与边缘部署实战

简介RoboMaster雷达站数据集与开源项目汇总包面向参赛战队、雷达感知方向开发者及机器人爱好者旨在解决雷达站数据分散、开源方案难找的问题。包内共3个文件以index.html导航页为核心搭配.inscode与.gitignore工程配置整包仅6KB轻巧易用。汇总内容覆盖大疆官方数据集、Damon2019/RM-DATASET、华农数据集并整理了上海交通大学、沈阳航空航天大学、中国石油大学华东、华中科技大学等高校的开源雷达站程序涉及YOLOv5模型剪枝、高性能推理加速等关键模块还引入2024赛季厦门理工和辽宁科技的最新开源项目展示规则化降本与工程提效思路。通过这个索引包读者可快速对比不同数据集的视角与噪声特性评估各高校源码的框架和部署方式再按需跳转学习。已有211人学习下载适合需要系统摸底雷达站数据来源、开源方案选型与算法优化路径的读者。 折腾了快半年终于把RM雷达站这套目标检测数据集和整套开源源码整理出来了。说实话雷达站在队里的存在感一直很微妙——它不像步兵那样能直接打出血量优势也不像哨兵那样全场焦点但它决定了你的队伍到底是“睁着眼打仗”还是“蒙着眼乱打”。这套数据集的构建过程、模型选型思路、包括训练时踩过的那些坑我觉得值得好好写一篇给以后想认真做雷达站的队伍留个参考。如果你正准备接手队里的雷达站或者正在为“怎么识别得又远又稳”发愁这篇应该能帮你省下不少时间。我会把从数据采集、标注规范、模型选型、训练调参到边缘端部署的完整链路都聊一遍也会把开源仓库里哪些东西可以直接用、哪些东西需要按自己队伍情况改全都讲清楚。1. 雷达站任务到底难在哪一个固定视角下的高速小目标检测问题1.1 雷达站和装甲板识别的本质差异RoboMaster比赛里雷达站是固定在场地外的设备以一个较远的俯视视角观察整个战场。它要做的事情很纯粹持续检测场上对方机器人的位置通过裁判系统或者自建的通信链路把坐标发给己方机器人让己方决策系统知道“对面步兵在哪、哨兵在没在基地位、有没有人绕后”。很多队伍的误区是直接照搬步兵机器人上的装甲板识别方案。装甲板识别相对容易因为近距离、特征明显颜色和灯条在画面里占比大。但雷达站的视角完全不同一辆步兵车在长边场地对面的时候画面上可能只有几十个像素高车体细节完全丢失看到的更像是一个移动的色块。而且场上还有烟幕、灯光频闪、草丛、障碍物遮挡机器人还会小陀螺旋转导致外形实时变化。所以雷达站的目标检测不是简单的“目标识别”它其实是一个小目标、远距离、高动态范围的实时检测问题。目标尺度小、运动速度快、背景干扰强这三座大山叠在一起决定了我们在模型选型和数据采集上必须走一条和步兵机器人完全不同的路。1.2 为什么不能只靠官方小地图信息有人会问裁判系统本身不就有位置信息吗我直接读小地图不就行了这里要说明一下雷达站获取到的先验信息确实可以辅助定位但它的更新频率、精度尤其是延迟都很难满足实时决策的需求。比赛中的对抗节奏到了后期非常快等你看小地图上的点再反应对方的走位早就变了。而且雷达站还有一个很重要的作用是识别对方机器人的状态是正在回血、卡在草丛里还是在飞坡这些信息通过官方小地图是拿不到的只能靠视觉去推测。所以视觉检测模型是整个雷达站的感知底座只有先把位置信息以足够高的帧率稳定输出后面的轨迹预测和决策才有意义。我们的目标定得很明确在Jetson级别的边缘设备上单帧推理时间控制在10ms左右对中近距离的机器人检测准确率达到99%以上对远程小目标也能保持足够的检出率不能出现“时有时无”的不稳定情况。2. 数据集是怎么一帧一帧攒出来的采集、标注与清洗的完整链路2.1 视频采集的场地布置与车辆配置很多队伍开源的数据集最大的问题不是数量不够而是场景太单一。我们最开始也犯了同样的错误在实验室里固定场地、固定灯光、固定角度拍了两个星期数据看着不少拿到比赛场地一试模型直接退化。后来才反应过来数据集好不好看的是场景覆盖度不是图片总数。正式采集时我们在三个不同场地各布置了一整套采集方案。场地选型上尽量拉开差异一个接近正式比赛的标准场地有草丛、飞坡、障碍块一个是开阔的纯色地面一个是有大量灯光干扰的场馆环境。每个场地架设两台不同高度的固定相机模拟雷达站的高位视角另外用一台手持相机在不同位置模拟异常机位防止模型过拟合到固定透视角度。车辆配置上我们把队伍里的步兵、英雄、哨兵、工程都拉出来跑并安排不同的运动模式匀速巡航、急停急转、小陀螺还有故意跑到场地边缘贴边的情况。这一块特别重要因为雷达站最怕的就是“目标突然从视野里消失”而边缘场景恰恰是消失高发区数据里没有足够样本的话模型学不会“边缘其实也有人”。2.2 抽帧策略关键帧和模糊样本的平衡有了原始视频下一步是抽帧。这一步看着简单其实直接影响了数据集的整体质量。我们最开始用固定间隔抽帧结果发现相邻帧高度相似算下来等效有效数据其实很少还浪费了大量标注时间。后来改用动态策略先用一个轻量级的运动检测算法对视频做预处理把画面变化幅度大的片段标记出来在这些片段里多抽帧静止或几乎不动的片段少抽帧。这么做的道理很直白——比赛里对模型挑战最大的永远是快速运动场景运动越大目标越模糊越难识别也就越需要多喂给模型。另外我们专门保留了一部分运动模糊严重的帧。一开始我打算把模糊帧全部清洗掉后来看了一些自动驾驶数据集的做法意识到完全去掉模糊样本是错的。雷达站实战场景里机器人高速转向的瞬间就是模糊的模型必须见过这种输入才能稳定输出。保留大约10%左右的中度模糊帧最终验证下来对实战鲁棒性提升很明显。2.3 标注规范类别定义与难例处理方式标注是整个流程里最枯燥但最关键的一环。我们用的是LabelImg工具输出YOLO格式的标注文件。类别定义经过两次调整最初的版本按机器人型号分为步兵、英雄、哨兵、工程——大而全但实战中雷达站画面上远程小目标根本分不清具体型号模型学得也很痛苦。最终压缩成三类目标机器人为一类未上电/静止的机器人为一类人操作手偶尔出现在雷达站画面里为一类。其中第一类打底负责绝大部分训练第二类用来辅助模型理解“静止不代表消失”避免漏检第三类纯属为了排除干扰模型见到人形目标时不能把它当机器人报警。难例的处理我们单独强调两点一是遮挡目标机器人被草丛或障碍物挡住一半的仍然要画完整的包围框让模型学会“即使看不到整辆车也知道它在哪”二是极小目标在画面上小于20个像素的我们不会简单删除而是保留一部分并单独标注防止模型对这些超远程目标彻底失明。2.4 数据清洗去掉自坑数据而不是堆量数据清洗这个环节我强烈建议每个队伍都重视起来。早期我们模型出现过一个诡异的问题对某个场地角落的背景老有误检排查了很久才发现是采集时有一辆已经损坏的备用机器人被放在了那个角落模型看到的不是“目标”而是“一个静止的蓝色形状”。清洗流程我分三步走先人工抽检删除明显无效的帧比如相机抖动到画面完全模糊的再用脚本统计每张图的标注框面积和数量把标注框面积异常小或数量异常多的图挑出来重点复查最后用初版模型跑一遍全部数据把预测置信度异常高的图和漏检率最高的图调出来看是不是标注质量出了问题。这三步跑完数据集的整体噪声水平才降到一个可接受的范围。开源时我们最终放出了一万五千多张有效图像覆盖六类典型场景包含约八万个目标实例。这个体量不能算大但对雷达站这个垂直场景来说因为类内差异相对集中配合规范的数据增强已经足以训练出一个实战可用的模型。3. 模型选型与训练策略为什么是YOLOv8加自定义小目标层3.1 从传统视觉到深度学习的迁移过程雷达站目标检测不是一开始就上深度学习的。很多老队伍的第一版方案用的是基于颜色阈值和形态学处理的传统视觉方法先按队伍颜色提取色块再算轮廓和质心。这个方案的好处是算力开销极小部署简单但问题也很致命——对光照极其敏感场地灯光一变阈值就得重新调机器人被遮挡时色块断裂检测直接失败小陀螺旋转时颜色没变但外形变了又容易和目标丢失混在一起。我们的结论很明确传统视觉可以用于辅助校准但作为主检测方案完全不够用。后来切到深度学习路线在几个主流检测框架里做了一次横向评测最终把目光锁定在YOLOv8上。原因有三点第一推理速度快YOLO系列在边缘设备上的效率是出了名的好第二训练生态成熟数据格式简单标注完直接就能训练不需要过多的预处理流程第三模型结构上有不错的小目标处理基础尤其是配合自定义检测头之后完全可以满足雷达站的场景需求。3.2 P2层加入针对远程小目标的结构改动YOLOv8默认使用P3、P4、P5三层特征图做检测分别负责不同尺度的目标。P3对应浅层特征感受野小理论上适合小目标但雷达站场景里的远程目标太小了在P3层上的特征已经非常稀疏模型很难有效学习。我们做的第一个关键改动是增加一个P2检测头。P2层来自网络更浅的阶段分辨率更高能保留更多细节信息对小目标更友善。这个改动在远程目标的检出率上提升非常明显但也带来一个副作用计算量和内存占用都上去了推理时间变长这对边缘端的实时性是个大威胁。解决思路是给P2层单独瘦身不直接复用默认的backbone结构而是用一个轻量级的特征融合分支来生成P2特征控制这部分额外的算力开销。最终在Jetson Orin NX上推理时间仅增加了约3ms但远程小目标的AP提升超过了10个百分点这笔账是完全划算的。3.3 训练细节尺度扰动、Mosaic和类别不平衡处理训练策略上我们没有用什么花哨的新算法真正决定上限的是几个细节。第一是尺度扰动雷达站画面的特殊性在于目标尺寸跨极大同一个机器人近距离占满屏幕的一半远程可能只有几个像素。我们把训练输入分辨率定在1280x1280并在训练过程中对输入做随机缩放模拟不同距离下的目标尺寸分布让模型见过各种尺度的特征。第二是Mosaic增强和Copy-Paste增强的合理配比。Mosaic把四张图拼成一张能显著丰富背景和上下文但Mosaic占比太高会让模型对小目标的位置学习产生偏差因为我们实测发现纯Mosaic训练出来的模型在对远程小目标定位时存在系统性偏移。最终我们把Mosaic开启概率设为0.5并配合一部分Copy-Paste增强单独把Robotroid实例粘贴到其他背景图上增加目标密集场景。第三是类别不平衡。前面说了类别分成三类其中“机器人目标”占了超过90%的样本“人”和“静止机器人”加起来不到10%。直接训练的话模型会严重偏向第一类。我们没有采用复杂的采样策略只是把后面两类的损失权重调高并在输入采样时对包含这两类的图像做了轻微的上采样训练过程中观察验证集上的分类准确率逐步微调权重比例。3.4 蒸馏训练大模型带路小模型上场上面的模型结构改动完成之后训练完的模型尺寸和参数量在边缘设备上其实属于“能跑但不轻松”的状态特别是在比赛后期需要同时跑检测、匹配、预测多个模块的时候算力很容易吃紧。为了进一步压缩推理耗时我们做了一次知识蒸馏。方案是先训练一个YOLOv8-Medium版本作为教师模型它不需要考虑部署实时性只追求尽可能高的精度。之后用蒸馏损失把教师模型的暗知识迁移到学生模型一个极致轻量的YOLOv8-Nano实例上。蒸馏过程中特别关注了远程小目标区域的响应一致性因为教师模型学到的很多细节特征恰恰是小目标检测的关键。蒸馏后的学生模型在精度上相比直接从零训练或只从预训练权重微调的Nano版本mAP提升了约5个百分点但推理速度几乎快了一倍。最终部署时的方案就是Nano蒸馏版加上TensorRT FP16量化在边缘设备上稳定跑到了接近100FPS。4. 开源源码的项目结构与部署细节从训练到裁判系统通信4.1 仓库模块划分与使用方式开源仓库的代码组织成了几个独立的模块尽量做到每一块都能单独用不用非得全套跑起来才能看效果。rm-radar-detect/ ├── configs/ # 模型和训练超参数配置 ├── dataset/ # 数据集接口、标注预处理脚本 ├── models/ # 检测模型定义含P2层改动 ├── tools/ # 训练、验证、导出脚本 ├── deploy/ # TensorRT部署和推理代码 ├── communication/ # 裁判系统/机器人通信模块 └── docs/ # 使用文档和性能评测报告训练入口在tools/train.py参数通过configs目录下的YAML文件控制换数据集只需要改data_root、train_ann、val_ann三个字段。如果你用的是自己的数据按照YOLO格式组织好目录结构理论上几行配置就能跑起来不需要改动模型代码。推理模块单独抽到了deploy文件夹里不依赖训练框架只依赖TensorRT的Python绑定。这个设计是为了方便在比赛现场快速替换模型每次重新训练完只需要导出engine文件比赛的时候加载进去就行不需要在部署机上装一套完整的深度学习训练环境。4.2 推理链路把检测结果变成机器人能用的信息检测只是起点雷达站最终要给机器人提供的是“前方的哪个坐标有敌方机器人”。这里有一个很容易坑到新队伍的问题相机画面上的像素坐标怎么换算成场地平面上的世界坐标我们的做法是假设场地为平面通过场地角点和已知尺寸做单应性变换标定出像素坐标到场地坐标的映射矩阵。整个推理链路是图像输入到模型得到每辆车的包围框和类别对每个包围框取底部中心点作为“接触面点”因为机器人是放在地面上的底部中心点的投影误差远小于绝对中心点再配合卡尔曼滤波对连续帧的检测结果做跟踪平滑掉单帧误检和漏检导致的坐标抖动。通信模块也做了抽象默认提供基于UDP的坐标广播方式广播内容包括目标ID、类别、世界坐标和置信度。不同队伍如果使用的是裁判系统的自定义协议只需要替换communication目录下的编码器实现不需要动上层逻辑。4.3 从PyTorch到TensorRT的模型导出步骤导出这一步值得单独拿出来说因为很多人卡在“训练好了但上不了设备”这道坎上。我们整理了一个标准的导出流程按这个顺序走基本不会出问题。第一步用训练好的PyTorch权重导出ONNX格式导出时注意把opset版本号设到13以上否则部分算子会因为版本旧而转换失败。第二步用TensorRT的trtexec工具把ONNX转为FP16 engine文件转换命令里需要显式指定maxBatch和maxWorkspaceSize因为默认值对边缘设备不友好。第三步在设备上加载engine文件做推理测试这一步要重点检查输入图像的预处理方式是否和训练时完全一致比如图像归一化的mean/std值、输入尺寸、通道顺序任何一个不一致都会导致精度暴跌。有一个细节提醒一下在Jetson设备上建议直接用JetPack自带的TensorRT版本不要自己用pip安装也不是说跑不起来而是版本匹配问题会让你花掉大量本来不需要花的时间。我们最开始自己装了一套折腾了一整天才意识到自带的明显更合适而且自带的版本在设备上做过充分的性能调优。5. 实测性能与踩坑记录那些文档里不会写的经验5.1 不同场景下的实测数据开源之前我们把模型拉到各个场景下做了一轮完整的压力测试。为了直观说明问题整理了一张对比表格列出不同场景下的核心指标场景输入分辨率平均推理耗时中近距离检出率远程小目标检出率误检率标准场地白天灯光1280x128010.2ms99.4%91.0%0.3%低照度/夜间场地1280x128010.5ms97.1%84.5%0.8%强烟幕干扰1280x128010.1ms92.7%71.2%1.5%高速运动/急转场景1280x128010.6ms94.3%82.3%0.6%整体来看日常比赛场景是够用的真正的短板在烟幕和低照度场景这也是我们下一步打算重点补数据的方向。如果你是在比较极限的场地使用我建议先跑一遍自己的数据测一下再决定要不要加训练样本。5.2 坑一灯光频闪让模型学会了“眨眼”这个坑是最早踩的也非常有代表性。我们在一个场馆里测试时发现模型检测结果每隔几帧就会突然消失一下像是“眨眼睛”。一开始怀疑是推理线程的问题排查了很久最后把逐帧画面打印出来才发现那个场馆使用的是50Hz交流电供电的灯光亮度的频闪周期刚好和相机的自动曝光产生耦合导致每隔几帧就出现一张整体偏暗的帧模型在这种帧上漏检率很高。解决方案分两步。第一步在相机设置里固定曝光时间和增益关闭自动曝光从源头上消除帧与帧之间的亮度突变。第二步在训练数据里专门加入了一批模拟频闪暗帧的样本通过随机降低亮度实现让模型对整体偏暗的输入不再那么敏感。这个坑告诉我们雷达站的部署环境远比实验室复杂采集数据时的光照条件必须尽可能贴近真实比赛场景。5.3 坑二模型过拟合到了训练场地特征有一段时间我们自信满满地带着模型去外场实测结果发现模型在训练过的实验室场地表现接近满分一到外场就频繁漏检。后来分析发现问题出在训练数据里大部分图片的背景都是同一块绿色的地面模型学到的不完全是“机器人长什么样”还有一部分是“绿色背景上有一个孤独的机器人”稍微复杂一点的背景一来模型就懵了。解决办法是在数据增强阶段引入大量的背景替换和色彩扰动把训练图里的地面颜色随机偏移甚至把一整类背景换掉。同时在采集阶段就尽量多覆盖几种地面材质塑胶地、水泥地、木质地板、草地。经过这一轮调整外场实测的掉点幅度从接近20个百分点缩小到了5个百分点以内。经验很简单雷达站的泛化性全靠数据多样性撑模型结构再复杂也救不了分布外场景。5.4 坑三远程小目标标注框的偏移远程小目标本身就小标注时鼠标稍微偏差几个像素反映到模型训练上就是持续的定位偏差。这个坑最隐蔽因为它不会让模型“漏检”或“误检”但会让输出坐标精度变差对雷达站这种需要精确坐标推导的场景来说影响是很直接的。我们的排查过程是这样的模型在远程目标上坐标抖动异常平均误差明显大于近处目标。先用标定板验证了单应性变换矩阵没有大问题然后调出远程目标的训练标注逐张检查才发现部分标注框中心点普遍偏左几个像素。原因是小目标标注时人会倾向于把框的中心点落在目标的视觉重心上而视觉重心和几何中心在低分辨率下是有偏差的。解决方法是制定了更严格的标注规则对于远程目标要求标注时放大到合适倍数再画框并且以目标底部中心作为定位锚点而不是用视觉感受上的中心。校正后远程目标的坐标精度明显提升。5.5 开源协议与后续扩展方向开源数据集的协议我们选了CC BY-NC-SA 4.0也就是非商用、署名、相同方式共享。不希望这份数据集被拿去直接商用但很欢迎比赛队伍、科研团队用来做非商业的算法研究和比赛实践。源码部分则采用MIT协议方便大家在项目里自由使用和二次开发。在开源的过程中有很多人问我们接下来还有什么计划。我的想法是这套数据集的视觉检测能力目前只是第一步下一个阶段更想做的是雷达站的多目标跟踪与轨迹预测模块把检测结果和比赛决策系统更好地联动起来。如果你们队伍做了类似方向欢迎在GitHub上提交issue或者PR一起把这条小众但不冷门的工程链路做扎实。最后说点实在的雷达站这个岗位在RoboMaster里天然不显眼但它对整个队伍的感知能力来说是质的改变。如果你正准备开始做我的建议是先别急着调模型把数据采集和标注流程跑通你再回头看会发现后面所有事情都顺了。这套开源仓库就是按这个思路设计的希望能帮你们少走一点我们走过的弯路。本文还有配套的精品资源点击获取