在 RoboMaster 视觉自瞄系统中，sp_vision_25（同济大学 SuperPower 战队 25 赛季视觉框架）以国赛 39.6% 的最高命中率证明了"开火决策"与"射击延迟补偿"的价值：前者决定哪一发子弹该打，后者保证打出的子弹落在装甲板未来位置，而不是它"出现过"的位置。本文用尽量少的代码，带你读懂这两块核心机制的实现思路与调参方法。

一、命中率为什么是"决策问题"，而不是"识别问题"

在 readme.md 给出的量化数据中，搭载本算法的步兵在 25 赛季国赛上的最高命中率为 39.6%，正常发挥不低于 30%；面对 2m 处 300 血、14 rad/s 自旋的敌方步兵，击杀时间约 10 秒。

项目提出了"轨迹视角下的自瞄理论"，把命中率问题拆成一条链：

目标轨迹 --(提前子弹飞行时间)--> 射击轨迹 --(云台跟随)--> 云台轨迹

• 击杀时间取决于云台轨迹与射击轨迹的重合度（DPS = 单位时间射击窗口占比 × 射频 × 单发伤害）；
• 命中率则有一个理论上限：命中率 ≤ 重合射击轨迹段 / 总轨迹段。

也就是说：云台在"偏离射击轨迹"的阶段，一枪都不应该打，否则就是在浪费弹丸、稀释命中率。这正是 sp_vision_25 开火决策的出发点——不是"瞄得准就打"，而是"轨迹重合才打"。

二、开火决策机制：两层判断 + 500Hz 决策环

1. 瞄准位置怎么选

瞄准点计算在 tasks/auto_aim/aimer.cpp 的Aimer::aim()中完成：

1. 弹道解算：根据下位机上报的初速和装甲板距离，用抛体运动方程解出飞行时间和俯仰角，实现见 tools/trajectory.cpp；
2. 迭代预测：目标在飞弹期间还在动，所以"预测目标位置 → 重算弹道 → 再预测"迭代最多 10 次，直到飞行时间收敛；
3. 装甲板选择：choose_aim_point()会按距离旋转中心的夹角挑选可射击装甲板，小陀螺场景下通过"锁定模式"防止在两块 45° 装甲板之间来回跳变。

2. 开火判断怎么做

真正的"扣扳机"逻辑在 tasks/auto_aim/shooter.cpp 的Shooter::shoot()中，条件非常克制：

• 距离分级容差：目标距离超过judge_distance（2m）时用second_tolerance（2°），近距离用first_tolerance（3°）；
• 防突变量判断：本次瞄准指令的 yaw 与上一次差值必须小于 2 倍容差，避免装甲板切换瞬间的"跳变帧"误开火；
• 云台到位判断：云台实际角度必须跟上上次指令（差值小于容差）才允许开火——云台没到位，子弹必然偏离射击轨迹；
• 瞄准点有效性：aim_point.valid为 false（弹道无解、目标出界）时强制闭锁。

以上任一条件不满足，command.shoot置为 false，下位机保持不发射。这就是"偏离射击轨迹段停火"的工程实现。

3. 500Hz 决策环如何驱动二者

多线程主程序 src/mt_standard.cpp 中，识别线程负责采图，主线程完成解算与跟踪，并把目标推送给 tasks/auto_aim/multithread/commandgener.cpp 中的决策线程。该线程每 2ms 醒一次（约 500Hz）：

输入过期(>200ms)? --是--> 丢弃，等待 |否 aimer.aim() 计算瞄准指令 ↓ shooter.shoot() 判断是否开火 ↓ cboard.send() 下发给下位机

500Hz 的决策频率远快于人眼，保证云台在高速小陀螺的装甲板切换窗口里也能及时刹停或续射，这是命中率能稳定在 30% 以上的基础设施之一。开火链路的独立验证可以跑 tests/fire_test.cpp。

三、射击延迟补偿：把"过去"翻译成"未来"

1. 为什么必须补偿延迟

相机图像传到小电脑、神经网络推理、解算、通信、云台响应——每一步都要花时间。等你"看到"装甲板的那一刻，它已经离开画面位置好几个像素了。若直接朝"当前看到的点"打，高速小陀螺下一枪就是空炮。

sp_vision_25 的补偿思路统一为一句话：用估计器把目标状态"外推"到子弹真正到达的时刻。

2. 开火延迟补偿：delay_time 外推

Aimer 构造时从配置读取三个关键参数：

aim()中根据目标 yaw 角速度选择对应延迟，把目标状态外推到future = timestamp + 图像处理耗时 + delay_time，再基于这个"未来目标"解弹道。也就是说：开火补偿不是拍脑袋加个提前量，而是直接作用在 EKF 目标预测上，与识别、跟踪共用同一个运动模型，参数只需调试 2~3 个。

3. 全链路延迟：预测时间偏移量

除了开火延迟，README 还系统列出了"预测时间"应包含的延迟项：

• 图像传输延迟（相机 → 小电脑）
• 图像处理延迟（神经网络推理 + 决策生成）
• 下位机通信延迟（指令下发）
• 下位机控制延迟（云台响应）

工程上除了图像处理延迟可直接计算外，其余项合并为一个约15ms的调试参数，通过拍摄慢动作视频、对比击杀时间来整定。这种"少数可调参数 + 可测量验证"的设计，让延迟补偿从玄学变成了可回归的测试项。

4. 轨迹规划器的"提前开火"决策

赛季新增的轨迹规划器（tasks/auto_aim/planner/planner.cpp）把开火决策做得更精细：

• 规划器用 TinyMPC 基于云台最大加速度，规划出一条未来 ±0.5s 的平滑云台轨迹（planner/planner.cpp 中HORIZON = 100，步长 10ms）；
• 开火判断不再看"此刻的误差"，而是查询t_fire（开火延迟）之后：规划轨迹与射击轨迹在该未来时刻的偏差是否小于fire_thresh（0.003 rad）；
• 只有偏差足够小，才发出plan.fire = true。

这等价于问了一个正确的问题："如果现在扣扳机，延迟过后云台和弹丸会同时落在哪里？" 相比只看当前误差，它天然规避了"位置看起来已到位、云台还在加速中"的误开火，这也是命中率上限能贴近轨迹重合度的关键。

四、关键参数速查（configs/standard4.yaml）

各兵种参数集中在 configs/ 下的 YAML 文件，以 4 号车 configs/standard4.yaml 为例：

#####-----aimer参数-----##### decision_speed: 8 # rad/s high_speed_delay_time: 0.015 # s low_speed_delay_time: 0.015 # s #####-----shooter参数-----##### first_tolerance: 3 # 近距离射击容差，degree second_tolerance: 2 # 远距离射击容差，degree judge_distance: 2 # 距离判断阈值 auto_fire: true # 是否由自瞄控制射击 #####-----planner-----##### fire_thresh: 0.003 # 开火角误差阈值，rad max_yaw_acc: 50 # 云台yaw最大加速度约束

调参建议：先用 tests/fire_test.cpp 验证通信链路，再用慢动作视频整定delay_time，最后在 PlotJuggler 曲线中观察shoot信号与云台角度的相位关系微调fire_thresh/tolerance。

五、快速上手 🚀

git clone https://gitcode.com/gh_mirrors/sp/sp_vision_25 cd sp_vision_25 cmake -B build make -C build/ -j$(nproc) ./build/auto_aim_test

依赖与编译细节见 readme.md 第 3.2 节；demo 素材（视频 + 四元数）位于 assets/demo/。

总结

39.6% 的命中率并非来自更"聪明"的识别，而是来自三个可复用的工程思想：

1. 命中率是决策指标：把云台轨迹与射击轨迹的重合度作为开火依据，偏离即停火；
2. 延迟统一建模：所有时间延迟都折算成对 EKF 目标状态的外推量，参数少、可测量；
3. 面向"子弹到达时刻"判断：规划器查询t_fire之后的轨迹偏差而非当前误差，从根上避免误开火。

这套机制全部实现在 tasks/auto_aim/ 模块中，配合 tests/ 下的独立测试程序即可离线复现和回归——这正是 sp_vision_25 对新手最友好的地方。