Software.md

小型足球机器人--软件组

架构体系

首先我们来定位一下软件组在整个工程架构中的位置。

在以场地中的机器人为核心的工程中，在场地上方的全局摄像头对图像的采集是软件组工作的数据输入。

• 图像信息将会发给一个专门用于图像处理的计算机，该计算机的唯一工作就是通过对图像的色标的识别，将图像信息转化成直接可用的全局场地信息并通过网络进行广播，可用坐标信息包含双方机器人的坐标位置以及朝向和球的坐标位置。值得注意的是，在最初的3x4m的场地中，单个摄像头即可捕捉全场信息，但在后期场地扩大后，单个摄像头肯定是不够的，为了保证信息捕捉效果，对摄像头的数量进行了增加。随着镜头的升级和脚架的拉高，目前的摄像头数量从八个变为两个，但在图像机的处理是针对单个摄像头的，所以在网络中广播的数据包是单个摄像头的数据包，所以在当前两个摄像头的场地上，我们的图像接受帧率实际为75*2=150Hz。对于多个摄像头数据的融合需要我们自己进行处理。

  （在早期的比赛中，图像计算机上的图像处理软件是每个队伍都需要完成的工作，但随着比赛的发展，为了比赛的公平，CMU推出了一个软件作为官方的图像软件，对于色标的识别处理目前已经不再是我们的工作了）

现有软件

目前我们使用的软件为我们自主开发的Athena与Medusa，以及参照官方修改过的grSim。

• Athena

  Features:

  • 机器人信息和Debug信息可视化
  • 图像滤波处理与转发
  • 机器人指令和裁判盒信息接受和发送
  • 热力图绘制
  • 可视化参数列表
  • Log记录与播放
  • 其余软件的启动、连接与终结

  参见mAn

• Medusa

  Medusa是没有图形化界面的运算软件，通过接收Athena发来的图像信息与实车回包，经过局势分析、动态匹配、路径规划等复杂的运算，并调用lua脚本，为场上的每辆车赋予具体的任务，并将具体的指令传回Athena。Medusa是我们软件组的大脑。

• grSim

  grSim是由Parsian队伍开发并作为官方软件提供的仿真平台，我们对其中的机器人部分针对我们机器人的特点进行了修改。利用grSim我们可以脱离硬件的情况下来调试，大大降低了日常调试的成本。

模块分析

• 图像模块（Vision）： 图像模块作为整个软件的预处理模块，承担着图像的融合、滤波、碰撞检测等预处理任务。输入为所有摄像头的原始数据，首先融合成一帧的完整数据，再针对图像中存在的噪声、丢失等问题，通过滤波、预测等一系列处理，最终完成整个图像的预处理，等待其他模块进行调用。需要注意的是，由于我们的框架中并没有绝对时间的概念，图像的帧数就相当于我们的计时器，所以保持图像帧数的稳定尤为关键。

• 决策模块（Decision）： 决策模块作为整个系统中最为重要的模块，承担着整个比赛场上大脑的任务。通过拿到的图像信息，结合之前的状态，计算出在此时应该采取的策略。包括场上的进攻防守分配、跑位，通过复杂的计算生成具体动作任务，交由动作模块进行轨迹规划并下发执行。

• 动作模块（Action）： 从决策系统计算出的跑位点以及跑位方式开始，接下来的细节动作规划交由动作模块来处理。在该模块中，包含了轨迹规划以及对机器人速度控制的算法。计算好的速度与其他动作（射门、吸球）共同拼凑成数据包经由串口或网口发送至机器人。到此为止，软件组负责的整个工作结束，接下来的机器人接受指令以及具体执行交由电路组的嵌入式程序来完成。

关键算法

• 卡尔曼滤波（Kalman Filter）：在我们的系统中，由于图像是经由网络传输的，所以对于我们获得的信息，在绝对时间轴上存在一定的延后性。而通过我们的下发指令结合上一帧的图像进行预测而得到的位置存在一定的预知性。这两种针对同一位置信息的数据经由卡尔曼滤波恰好可以互相补偿。
• 随机扩展生成树（RRT） & Bang-bang控制：机器人的路径规划采用通用的RRT算法，计算出目标点后，利用简单的Bang-bang控制进行速度规划，简单稳定，执行效率高。

其他技术

• Protobuf：Protocol Buffer是由Google开源的一种数据交换格式，常用来作为通讯协议，独立于通讯媒介和语言。相比于通用的json或xml，该协议可以将数据包压缩到更小，通讯效率更高。在我们的程序中，利用UDP和protobuf来实现我们Athena与Medusa之间的通信。
• Lua & C++混合编程：Lua是一门类似与Python的脚本语言，但其更轻量。是一门常用于游戏脚本的胶水语言，其与C++的混合使用可以减少大工程中的常用修改带来的编译繁琐的问题。在我们的项目中，由于临场策略千变万化，所以配合Lua脚本可以使临场的战术调整更加方便灵活。
• ODE仿真：该项技术主要运用在我们的仿真平台grSim中。ODE是一个由C编写的开源物理引擎，常用来作为游戏内的仿真引擎或者用来制作机器人的仿真系统。在我们的项目中，使用了ODE搭建的软件作为日常调试的仿真平台，减少了复杂的硬件准备工作，也避免了因程序问题而带来的不必要的硬件损坏。
• Qt框架：Qt是一个跨平台的桌面应用编程框架，使用C++作为主语言。在本项目中，主程序的所有通讯接口均采用了Qt内部的现成组件，这样使得程序本身简单易懂且跨平台，避免了与操作系统的细节API打交道。另外，我们的软件均采用QtQuick Control编写，QtQuick Control是Qt在5版本之后推出了新框架，在原有的基础组件的基础上，将界面编写的工作改用一门可以嵌入javascript的标签语言（qml由Qt自研），且全部的界面渲染由opengl使用gpu完成，这样的方式使得我们可以放心的编写使用大量cpu计算资源的主程序而不用担心与复杂的调试界面的资源冲突问题。
• CUDA并行计算：利用GPU并行计算力优势，每次开启近5万个线程，对场上可能出现的传接球情况进行预测、评估，每次预测能在几毫秒内完成。该技术使得多机器人之间能够很好地完成传接球配合。

路线计划

策略

从今年的比赛中分析，策略提升的方向有以下两点：

1. 2019年比赛可以看出，场地因素十分影响吸球的稳定性，而我们的策略十分依赖吸球能力，比赛中吸球不稳将导致整盘皆输，所以我们需要一套不依赖吸球的PlanB。
2. 在决赛对阵ERForce的最后半分钟，对手采用了全进攻阵型，而我方在面对近乎空门（只有守门员防守）的情况下未能再次进球，这说明我们策略的自适应还不够，无法根据对方的特点做出相应的调整，导致相应的传接配合不是很流畅。这也将是我们新一年研究的重点。

车控

目前我们的车在较大速度、加速度下会出现到点超调、循迹能力和避障能力明显下降等问题，在新的一年里我们主要有三方面工作：

1. 路径规划层面：多车协同规划。
2. 在速度规划上（今年工作重心），通过增加闭环速度控制、合理速度约束、平动转动解耦等方法，将最大速度、加速度分别提升至400cm/s、550m/s²（原有基础上各提升100），并给出带避障的时间预测（区间）。
3. 动态避障方面：完善针对球的动态避障模型，目标为反应时间大于0.2s时动态避球失败概率为0或基本为0。