技术杂项 - scutrobotlab/RM2021_simulation GitHub Wiki

除了上述主要功能，模拟器开发过程中还有一些比较边缘的技术部分。某些功能在 2021 赛季模拟器中并没有实装，下面简单记录一下供以后参考。

外挂程序

这里的外挂指的是通过各种本地跨进程调用方式，与模拟器协同运作的程序，一般用于与实战软硬件的联调。2021 模拟器实现了外挂决策系统，通过抽取雷达站决策系统的部分代码，为模拟器中的机器人提供自动决策功能。此外可以实现的还有视觉联调、硬件联调等。

决策系统联调等实现分为两部分。首先是决策代码的抽取，这部分工作是负责雷达站开发的同学帮忙完成的，主要是剥离硬件相关代码，只留下由数据驱动的决策树部分。由于视觉相关代码主要由 C++ 编写，要整合进模拟器构建流程比较复杂，我们直接采用了 websocket 跨进程通信的方式，用本来就有引用的 Boost 库实现了一个同步网络服务器，直接喂 JSON 数据，返回 JSON 数据。解决一些跨平台构建问题后，把这份代码构建成单独的可执行文件。第二部分是与模拟器的对接。在比赛开始时，异步启动决策器进程，主动连接本地服务。比赛过程中，不断把赛场数据喂给决策器，接收并解析决策结果，反馈在 HUD 上。在比赛结束时，要记得结束决策器进程，防止网络资源占用。

视觉联调是一个听起来很有前景的联调方向。其主要设想是通过模拟器渲染出尽可能拟真的赛场图像，包括车辆、能量机关、建筑等。由于模拟器渲染的图像自带标注数据，这种方式可以大量生成训练数据，用于视觉系统开发迭代。将视觉系统整合到模拟器中提供自动瞄准功能，就实现了上面提到过的外挂式自瞄。视觉联调的难点有两个：第一，为了保证训练数据等有效性，渲染出的图像必须尽可能拟真，这一点在 2021 模拟器还没有做得很好。如果图像很假，视觉系统就不能基于此开发，视觉联调就失去了意义。第二，要用视觉系统提供自瞄功能，就需要进行视频流传输。由于自瞄系统一般基于高帧率图像，甚至双目图像，本地回环的视频流量会很大。而且视频流传输不能有太高延迟，这就限制了视频压缩技术的使用。关于不同本地回环方式的流量承载能力有待测试。解决了这两个问题，能够实现联调的话，可以一定程度帮助视觉组的开发。

硬件联调是指采用一些真实的控制设备，对模拟器内的机器人进行操控。这个功能主要是为无人机设计的，让飞手能用遥控器来控制无人机。实现硬件联调会涉及到更多技术，包括编写上位机程序、解析接收器协议、设计真实无人机运动模型等。此需求有待讨论验证。

独占功能

如果有一些模拟器功能还没有开发完成，或者想藏一手的，可以设计一个鉴权系统，控制使用功能的用户范围。鉴权系统有两种实现，一种是使用本地密钥文件，比如一个注册表信息或者一个包含了密钥的文本文件，只要控制密钥分发，就可以在小规模地控制功能使用。这种实现简单明了，但是无法应用到线上的、大规模的使用场景。另一种实现基于在线用户系统，可以根据用户登录凭证进行鉴权、功能限制、灰度发布等，具体实现看场景。

服务器部署

不管最终采用什么实现方式，联机游戏的连接方式一般有两种：局域网游戏和公网游戏。局域网游戏适用于实验室内战，或者线下交流赛，优点是连接延迟低，部署没有成本，不需要公网流量，但是对实验室网络设备会有一定要求，比如内网不能隔断等。在 2021 模拟器使用过程中就经常出现由于局域网配置问题或路由器丢包问题导致局域网游戏连接不稳定的现象。公网部署适用于跨校区、跨学校的交流赛，当然也可以用于局域网能用等大部分场景。公网部署的优点是连接方便，不用考虑网络配置问题，对路由器对压力似乎也小一些，不足在于连接延迟受很多因素影响，最重要的是：服务器贵啊！

服务部署可以选择的服务商基本就是 BAT 网络服务，或者华为云京东云之类。不推荐使用太小众的，或者香港、海外的服务器，国内的服务器也要仔细核对部署地域。不同部署区域会带来不同的网络延迟，参考值是在稳定有线网下，广州本地连接广州服务器延迟 10ms 以下，杭州服务器 30-40ms，北京服务器 60-70ms。除了延迟，还有一个需要考虑的属性是网络带宽。2021 模拟器 15 人同时在线的服务器下行带宽占用是 5 Mbps 左右，如果做一些网络优化可以更低，但考虑到国内带宽价格昂贵，建议使用后付费、不限制带宽的服务器做短期部署。或者如果搭建了开放平台，可以整点格局大的长期预付费服务器，反正还有论坛、匹配、Demo 共享之类的功能要跑。硬件配置方面，只要不在服务端跑图像渲染，1c2g 的配置运行起来 CPU 占用不到 40%，内存占用不到 600 MB，和带宽相比乐观得多。

Demo 录制

比赛 Demo 是指保存了整场比赛数据等回放文件，可以用于反复、多视角播放，进行战术分析、赛后复盘、或者录一些帅气的剪辑等。Demo 系统需要嵌入在各种控制器里，在游戏的每一帧保存数据。

保存数据的思路大致有两种，第一种是保存每个实体的数据，比如位置、朝向、血量弹量等属性、全局经济，以及附加数据如用户输入等。依赖这些数据，即使不需要物理模拟也可以进行视觉上的比赛重放。这种实现的好处是数据保留完整，重放结果确定，外部程序可以直接读取文件进行分析，与模拟器解耦。缺陷是文件大小相对比较大。第二种思路是记录外部输入，比如用户控制输入、随机数种子、裁判系统配置文件等。在重放时将输入数据重新喂给模拟器，将比赛重新模拟一遍。这种思路的好处是 Demo 文件非常小，但是重放依赖模拟器，外部程序不好分析，时间回溯等操作比较困难。

要播放 Demo，模拟器也需要跟进相关功能设计。比如专用的 UI、专用的 OB 视角、交互逻辑，根据数据进行控制的另一套控制器等。Demo 录制和重放功能等实现是强侵入性的，如果确定要实现这样的功能，需要在一开始设计时就对其充分考虑。

参数自定义

RM 和电竞比赛的重要区别在于，角色的数值掌握在战队自己手上。大多数 RM 比赛双方的战力是存在差异，甚至十分悬殊的。而且每个战队的机器人都有自己的长处和短板。如果每一场模拟赛双方机器人的能力都完全对等，模拟器就会丧失一部分针对性战术分析的能力。这就是参数自定义功能存在的意义。

可以自定义的参数主要包括车辆运动速度、操作（取矿、补给等）速度、射速、精度等。功能实现思路大致有两类：本地参数自定义和服务器参数设置。本地参数定义是指利用本地配置文件等，每个客户端定义自己机器人的强度。这种方式实现不涉及网络同步，更改参数方便。但是如果需要保存全局的参数配置，做多次特定参数模拟的话，本地定义方式操作会比较繁琐，也不利于与 Demo 一起分享。服务器参数配置是指在服务端编写或上传一份配置文件，服务端将具体参数同步到各个客户端，并可以加入到 Demo 文件中。

服务端 UI

官方的服务端软件是有 UI 界面的，在上面可以设置机器人的各种属性、判罚机器人、重启比赛等。服务端 UI 可以放在裁判的界面实现，也可以实现为网页控制台。UI 具体需要承载的功能据情况而定。

比赛分析工具

只根据肉眼观察 Demo 可能会漏掉很多比赛细节，如果能用程序对 Demo 进行分析，就可以更全面地展示比赛情况。分析的内容可以是不同机器人的伤害水平、团战胜率、进攻贡献值、击杀热点图、实时胜率分析等。有这些图表作为依据，赛后复盘可以讨论得更加深入。