这个项目是 Robomaster 赛场上使用的雷达机器人感知方案，核心逻辑是双目相机 + 雷达点云联合定位。代码本身是前人留下来的，后续维护工作主要集中在修复兼容问题、更新模型和调整参数。当前项目已经不再处于主流方案的前沿位置，随着算法迭代速度加快，现阶段多数方案已经转向单目相机仿射变换等方式，原有的双目 + 雷达联合定位方案逐渐被淘汰。
这套代码的价值在于它确实完整地实现了一条感知链路：
- 相机图像采集
- 车辆和装甲板检测
- 点云录播和预处理
- 四点标定与地图投影
- 深度和 3D 定位
- 共享内存和串口输出
本仓库并不是一个纯研究型项目，也不是一个单独训练脚本，而是一个直接服务于比赛机器人上的工程代码。它的主要特点是功能齐全、依赖较重、参数敏感、运行环境要求严格。
这个项目的实现方式是典型的双目视觉 + 点云融合：
- 双目相机负责目标识别和图像信息获取
- 雷达点云提供空间几何信息
- 标定和地图转换用于把图像中的目标变成世界坐标系中的位置
- 最终输出给底层控制和决策模块
从代码结构来看，项目已经具备一套较完整的感知流程：
- 相机驱动
- 图像缓存和共享内存
- 车辆与装甲板检测
- 点云处理
- 四点标定
- 深度与位置恢复
- 串口通信
但它的局限也很明显：
- 依赖较多的硬件、环境和配置参数
- 标定误差会直接放大定位错误
- 视觉和雷达的融合稳定性受环境影响很大
- 这套方案在现在的算法路线里已经不是主流选择
随着比赛和研究方向变化，当前更常见的是单目相机仿射变换、单目几何估计，以及更轻量的定位方案。相对而言，这个仓库更像是一个历史阶段的工程实现，不再是当前主力方案。
radar_src/
├── main.cpp
├── camera/
│ └── mvcamera/
├── image_preprocess/
├── workspace/
│ ├── workspace.h
│ ├── workspace.cpp
│ ├── public/
│ ├── threads/
│ ├── infer/
│ ├── radar/
│ ├── four_point_locate/
│ ├── map_mapping/
│ ├── logger/
│ ├── tools/
│ └── UART/
└── ...
几个核心模块：
- camera/mvcamera：相机驱动和相机参数读取
- workspace/infer：车辆和装甲板推理，基于 TensorRT 运行 YOLO 系列模型
- workspace/four_point_locate：手动标定与地图点处理
- workspace/map_mapping：坐标转换和深度映射
- workspace/radar：雷达点云播放、录制和过滤
- workspace/threads：各类线程入口，如采图、图像处理、定位、串口读写
- workspace/UART：串口通信和消息输出
相机模块负责：
- 打开和关闭相机
- 读取实况帧和回放视频
- 加载相机内参、畸变参数和外参
- 从配置中读取标定文件
- 支持在不同模式下切换
这部分是整个系统最基础的输入层，参数不对，后面所有结果都没有意义。
检测模块位于 workspace/infer 下：
- car_infer：车辆目标检测
- armor_infer：装甲板检测
- yolov5：推理前后处理和 TensorRT 相关逻辑
模型文件位于 workspace/infer/models 下，通常会有不同版本的 engine 用来迭代和切换。这个模块的更新频率比较高，参数、阈值和网络版本都会直接影响最终结果。
这一部分主要负责：
- 读取地图点和图像点
- 手动四点标定
- 将装甲板位置映射到地图坐标系
- 利用相机外参和深度信息恢复 3D 坐标
这块是整个方案最容易出问题的地方之一。因为它不是纯视觉算法，而是把图像坐标和真实世界坐标拼接在一起，所以标定和参数差一点，定位就会很明显偏。
雷达部分负责：
- rosbag 点云回放与录制
- 点云预处理
- 聚类与滤波
- 异常点剔除
- 提供视觉系统额外的空间信息
代码中也能看到卡尔曼滤波、滑动窗口增益和聚类逻辑，说明该模块在项目中不仅仅是“拿来看看”，而是用于减少噪声、提升定位稳定性。
除了视觉和点云，项目还使用了：
- 共享内存进行图像和状态交换
- 串口与下位机或裁判系统交互
- 多线程收发和状态更新
这意味着最后的感知结果不是仅停留在本地，而是要真正进入控制和决策链路。
主程序入口在 main.cpp，流程大致为：
- 初始化 ROS 节点
- 创建 Workspace 实例
- 读取全局参数
- 打开共享内存
- 打开相机或读取视频
- 完成四点标定
- 初始化串口
- 进入主循环执行图像处理与定位
- 程序退出前释放资源
核心逻辑可以概括为：
启动 -> 取图 -> 检测 -> 定位 -> 输出
这套流程在工程中运行时，最关键的问题不是“是否能跑起来”，而是最终稳定性和参数一致性。
这个项目的核心依赖包括：
- C++
- ROS / rosbag
- OpenCV
- PCL
- Eigen
- CUDA / TensorRT
- Linux 环境
- 共享内存
- 串口通信
它是典型的比赛机器人端代码，不是纯python脚本，也不是单机仿真工程。
从工程现实角度来说，这个仓库已经处于“历史实现”状态：
- 双目相机 + 雷达联合定位在当前算法迭代中已经不是主线方案
- 后续更多是单目相机仿射变换、几何估计和更轻量的定位方法
- 原有方案在代码层面仍然可用，但它已经不再适合继续作为当前主方案长期维护
因此，这个项目现在更像是：
- 已完成的工程实现
- 具备一定比赛价值的历史方案
- 用于维护和参考的过渡代码
它不再是现在主流的定位路线，但仍然保留了可参考的框架和算法实现。
这个代码库的维护重点不是“写新算法”，而是：
- 修复已有代码在新环境下的兼容性问题
- 更新引擎和模型参数
- 调整比赛场地对应的标定和阈值
- 处理共享内存、串口和多线程同步的问题
- 维持这套方案在现有机器上的运行稳定性
实际面对的问题通常包括：
- 相机参数变化导致定位偏差
- 模型版本更新后检测结果不稳定
- 点云噪声和视觉结果对应不上
- 标定和实际场地环境不一致
- 线程同步或状态共享出现异常
这些问题都不是单点问题，而是整套系统一起出的问题。
这个项目的本质是：
- 早期/历史阶段的双目视觉 + 雷达融合定位方案
- 完整的机器人感知链路实现
- 主要用于比赛场景中的目标识别和定位
但从当前算法迭代来看，这套方案已经逐渐被更新的单目仿射变换和更轻量的定位方式替代。也就是说，仓库本身仍然有参考价值，但它已经不属于当前主流技术路线，不再是后续主要开发方向。