本赛季暂无队伍将自动步兵实用化，下赛季恐怕也不会有。但应当清醒的认识到，自动步兵的算法基础会更加完善（主要是提高样本利用率，并提高算法自身表现），计算能力会大幅度上升（近五年从 Jetson TK1 到 Jetson Xavier NX 的跃进，无人驾驶硬件方案带来的技术红利），下层建设（自瞄、风车乃至于整个仿真）也会有很大的进步。最迟三年以内，第 一个实用化的自动步兵会出现在 RoboMaster 的某场高校联盟赛。
因而，在本赛季规划中，我们应当清楚的结合自身情况，去准备面对长期以来比飞镖和平衡步兵更被忽视的这一兵种。如果能够集成成功，即使当下不能有革命性突破，随着强化学习研究的进展，也一定会有一天有突破。即使最终并没有集成成功，其分散的研究成果也可以部署在一般的地面兵种上，减轻操作手的临场压力与培训成本。
应当充分认识到，这是一个长期计划。一阶段的目标，是完成一些比较重要，且能产生即时效益的子任务。这其中包括分析裁判系统数据、在原有的视觉代码体系内实现更完善的目标优先级选择、云台自动控制索敌设计这一级别的“智能”。我们希望本赛季能全部实现这一目标。第二阶段是建设整个自动步兵的基础。主要是如何建立仿真环境，并做自体定位和对其他车辆的定位，从局部场景复原出更多语义信息的一个阶段。我们希望本赛季到下赛季， 能实现这一目标。第三阶段的目标是综合实现控制底盘和云台的智能。具体而言，是实现“战或逃”， 如何战，如何逃的逻辑。我们希望下赛季能实现这一目标。与此并行的，是研究如何在 1500 人民币左右，将这套方案从实验室落地到实际机器人的一个任务。我们希望从现在开始，到下赛季结束，能将这个问题弄清楚。
设计指标上，首先整套方案应当稳定在 60fps ，然后是能在联盟赛上获得较高名次。
自动步兵的设计总体思路
客观上说，我校很难在短时间内集中比较大的算力以供强化学习训练。且本届构成视觉组的全部是本科生，普遍没有任何强化学习的知识，对机器学习本身的理解也比较有限。因而，即使整个自动步兵的技术路线理论上可行，也要避免处于过拟合与欠拟合的摇摆之中，并完全失去质量控制的可能性。因而，整个技术路线必须先求稳妥，后求性能，且宁愿损失一部分性能，也要让算法足够简单，尤其要避免过深、参数过多的神经网络（甚至尽量以 hand-craft 的策略取代理论上更为先进的人工智能的方法），过大的状态空间和过复杂的动作空间。
因而，在攻击决策（自动瞄准攻击步兵/英雄/哨兵、风车、前哨站/基地站）中，不应当过度依赖强化学习方法。其中，攻击步兵/英雄/哨兵和风车是我们已经有的，前哨站/基地站可以用同样的策略小修一下。这不是我们规划的重点。需要大范围运用强化学习的地方，是根据周围环境和全局情况，计算“战或逃”的策略。
感知 – 状态空间的设计
理论上，我们可以完全忽略状态空间的设计，直接输入每一帧图像或点云，但这种端到端的深度学习方法，有 sim2real 的难以回避的鸿沟。我们渲染出的场景和实际场地捕捉到的摄像机场景，往往是有很大区别的，而现实情况也不允许我们用实车进行头几百个 epoch 的自杀式训练。而根据深度学习的 critical learning period 理论，如果前后的数据分布差别太大，即使长时间在真实场地训练，很可能也无法弥补这一鸿沟。这就使得这一技术路线过于冒险，仅仅适合作为技术验证。
因而实际的状态设计，主要是雷达站与裁判系统中转换出的装甲板/车辆的世界坐标及状态；步兵自身的坐标；环境的地形；以及比赛的整体数据。实际操作上，首先是确定高精度自体/其他机器人定位的技术方案，并进行具体实现。单线激光雷达在立体赛场中局限较大，多线激光雷达造价高昂，因而目前倾向于运用最大距离在 15m 左右的深度相机。
自体定位上，比较理想的是用 UWB ，或者是使用雷达站。备选方案是运用点云配准(深度相机或激光雷达)，或是运用传统视觉的特征描述子，做视觉里程计，并反推自体坐标。定位其他机器人的方法，主要是根据步兵自带摄像头解算装甲板角度来反推坐标，以及雷达站输出。
决策 – 算法设计
决策是整个自动步兵最为关键的部分。目前决策算法的各种特性，直接决定了我们前置 的感知和后置的控制两者的设计目标。这是因为目前强化学习算法样本效率相当低下，训练相当困难。且除非有很强的财力与人力支撑，很难让端到端的强化学习方法实际落地。 因而，状态空间与动作空间都应该谨慎的如上文进行进行调整。并且，要取得良好的算法表 现，决策过程同样不应该是黑箱，而是从实际比赛经验中获得的。
我们根据强化学习算法目前的实际情况，并根据远期所能动用的人力物力，做出一些假设。首先是，我们假设两个步兵和英雄都完全是自动步兵，这样我们就不需要考虑人工智能和人的协同，减轻我们的训练难度。其次是，我们的设计目标是针对固定的某个场地。根据经验将决策过程分为三个部分：
总决策部分负责自动步兵不同状态的切换。最基本的两点，首先是综合处理路径规划与局部战斗间的冲突，或者说是“战斗或逃跑“的冲突。其次是处理战斗对象(地面车辆、哨兵、基地站/前哨战、风车)之间的优先级。此外，理想状态下，自动步兵应该有一定的探索能力，或者说是主动索敌的能力。这一部分主要处理宏观的数据， 如双方车辆坐标与状态、比赛任务完成情况等等。 寻路算法，这里主要是是尽量避免战斗，同时朝操作手或是总决策所圈定的特定方向行进的算法。其假设局部不能聚拢足够力量击溃敌人，因而优先保存自身实力并进行长距离战略机动。局部战斗决策算法中，假设我方处于优势，因而优先在该区域内集中力量打击敌人。因而该算法优化的目标是在不同的局部地形下，决定战斗的走位与打击对象，最大化对敌人的伤害并最小化对己方的损失。我们不妨回顾规则， “自动步兵机器人无操作手。云台手可通过小地图向自动步兵机器人发送指令。”这等于是 说，除了小地图和裁判系统的数据外，我们不能和自动步兵作其他交互。而且裁判系统的接 口虽然确实比较全面，但操作手操控与机器人通过裁判系统感知的频率有限，因而机器人间并不能看作是完全协同的，是比较常见的多智能体强化学习场景。
总的算法上，计划以 finetuned QMIX 为基底，可能将 QMIX 的 GRU/LSTM 替换成 Attention （等于是把模型变成了 QPLEX ，借以保证 Long-Term Memory ），并且融合进 BicNet 式的 LSTM 通信，来利用裁判系统提供的通信信道。 QMIX 在与此场景类似的 StarCraft 游戏上已经有了比较好的表现，落地成本也并不太大。
跟地图有关的两个部分，即避障寻路和局部战斗决策两个部分。问题集中在怎么处理栅格化的地图上，最简单直白的方法是用卷积，根据经验，输入在 32x32 - 88x88 上比较可行，深度一般也不能太深，把若干层的 CNN 输出的 feature flatten ，并和本机维护的数据 concat 后，输出某种决策。这两个的 feature 应该是可以共享的，输出的时候分别用两个 LSTM layer 去做两部分的具体决策。总决策可能是在下面两个部分训练完成后，比较两个部分的 reward ，以选定更好的策略。这个部分同时可能应该串两个交叉的 LSTM Layer ，输入是智能体的 feature ，一半本智能体中连接，一半交错连接到其他智能体，接入其他智能体的决策。
控制 – 动作空间的设计
对于动作空间，我们的先验知识已经足够丰富。理论上，刚体的平动和转动的组合已经足够表达车辆的全部运动状态。限于机器人的实际设计，可能会有奇异点或是理论可行但不符合实际车辆特性的动作出现。但我们完全可以通过仔细研究车辆性能来规避可能性。 对于枪管所在云台的运动状态，建模云台的转动和俯仰角度难度更低一点，也不存在奇异点 的问题。因而，我们后置的控制操作，主要是需要与电控组紧密合作，根据他们的车辆控制接口，找出一个低精度的动作空间，作为整个强化学习输出的状态。
如何落地?——底层设计
ROS 是目前比较流行的所谓“元操作系统”。其主要是提供了一些常用驱动，以及导航、视觉、机械臂控制等功能插件，一般在 RoboMaster 中由电控组去做的面向硬件的机器人控制，以及一些常用的接口组件。前期我们没有采用 ROS，是因为没有那么多通信，没有那么多特殊的传感器，也还不需要用 Gym 去给强化学习算法训练提供一个采样空间。现在传感器的数量（双目、IMU、单目）肯定是上升的，且要在实际部署前做比较完整的仿真，就需要考虑如何把现有的控制代码和 Gym 完善的对接起来。
即使我们完全想明白这套算法体系，要将算法流畅（ 60 帧以上）的在 NUC 或类似体积的计算平台上，以足够可控的成本运行起来，且保持很强的可扩展性，其难度绝对不亚于设计算法本身。首当其冲的是模型的低精度量化。对视觉模型，低精度量化已经比较成熟。其量化原理和流程可以参考：
这套方案在视觉的各种 backbone 上用，比如 ShuffleNet MobileNet ResNet 这种结构，已经是比较成熟的了，低精度量化后掉点并不严重。有代表性的比如RangiLyu/nanodet，Megvii-BaseDetection/YOLOX。比较适合在廉价的 NPU 上做部署。考虑到机器人的总体算力有限，堆模型精度的边际效益是并不高的，用这种轻量级模型经过修改，表现应该是可以接受的。
比较麻烦的是强化学习。INT8 / FP16 + QMIX 的 Quantization Aware Training 是个比较头疼的话题，学术界目前根本没有涉及，所以恐怕还是 Post-Training Quantization 会比较好用。根据之前的研究，量化精度保持在 FP16/INT8 的情况下，对强化学习做 PTQ 损失也是可以接受的。
基于算法的低精度量化，如何选择框架又是个比较麻烦的问题。如果要廉价方案，参考 Amlogic A311D 这种，恐怕是需要利用 Mali 的，那么估计需要 armnn 这样的库。然后在 NPU 上跑基本的自瞄模型， CPU 上主要处理底层的 A*/势能场 导航一类的问题。
