强化学习系统库及仿真环境

梳理当前经典的强化学习开源库， 以及一些经典的仿真环境。

1. Framework/Platform

• OpenAI gym是强化学习研究领域广泛使用的一个经典工具包，它主要包含两部分：

  • Environments，经典问题的测试集，并提供统一的接口；
  • ScoreBoards/LeaderBoards/Benchmarking，用户算法性能对比的平台，用户可以通过api分享其算法的结果

• Rllab 与gym 完全兼容，并内置了一些RL的算法，目前rllab项目已停止更新。

• garage是基于rllab 而来，该项目是为了benchmarking 连续动作控制场景下的DRL算法而建立。

• Tensorforce: A TensorFlow library for applied reinforcement learning

• Ray 目前RL应用领域sota的框架，它是为了解决类似RL这样需要持续交互进行学习的AI场景问题。构建remote特性；1）具备ms级的task响应，2）以及million的吞吐量。

  • Ray架构设计主要包含两部分：应用层和系统层。应用层抽象统一的编程和计算模型；通过全局控制表盘，分布式调度器以及分布式的对象存储三个关键特性构建了一个可伸缩、高容灾的分布式系统管控层；
  • 应用层提供三种进程（process），Driver，Worker 和Actor。
    • Driver 是用户程序的执行入口。
    • worker表示在一个无状态的节点上执行远端tasks（以函数体现）。当系统层指定某个task到worker上面，在数据就绪的情况下，worker会自动顺序执行task；同时，当worker或driver调用远端函数后，会立即返回一个future对象（类似回调、句柄），通过future可以获取到任务的执行结果。
    • Actor可表示一个有状态的处理进程，Actor暴露的方法可以连续远程调用执行。该方法的调用过程跟task一样，类似的顺序执行，只不过他的执行是有状态的，在本地的执行效率没有task高。Ray提供Tasks和Actors两种编程模型的接口API，这两个编程模型是基于动态构建任务的计算模型之上的。
  • 系统层主要包含三个组件：全局的中心调度服务节点（Global control Store，GCS），分布式的调度器和分布式的对象存储。
    • GCS通过“key-value”的形式保存所有的控制状态信息，使用发布-订阅模式、设计的初衷是为实现容错和低延迟，GCS节点是在需要的场景下，可以扩展到多个，进而提高系统的吞吐量。通过将所有对象的metadata存在GCS，使系统的所有组件可以无状态化，方便做到对象存储和任务调度在分布式环境的自由伸缩。
    • 为了支持每秒百万级任务的调度，Ray设计了自下而上的二级调度器：全局调度器和本地调度器。节点创建的任务首先会被提交到本地的调度器，只有当本地调度器超载或者其他资源不足的情况下，任务才会被提交到全局调度器，进而根据GCS的信息，分配到合适的节点（基于最小等待时间估计）。当全局调度器变成瓶颈的时候，Ray通过GCS建立更多的全局调度器副本来进行水平扩展。两级调度器均基于事件驱动，单线程设计（event-drive, single-threaded）。从内部看，本地的调度器将本地对象的metadata保持在cache里面；任务是等待输入数据，只要任务就绪（相关入参已处于local store）就派发放到worker执行。不同的对象存储之间发生大对象数据交换的时候，Ray通过建立多个tcp连接进行处理。
  • 为了最小化任务的延迟，Ray构建了内存分布式存储系统来存放每个任务的输入输出，即无状态化计算过程。
    • 在同一个节点上，Ray通过内存共享的方式进行对象存储，这样在同一节点的数据共享可以达到“zero-copy”。目前该子系统已经独立为Apache Arrow项目，形成一种列式数据交换的格式标准（13个主流开源项目使用）。
    • 如果任务的输入数据不在本地节点，该数据首先会被拷贝到本地的对象存储中，任务执行后，结果也会写入到本地的对象存储。该做法是为了最小化任务执行的时间，以达到高吞吐量，即每个任务只会在它的本地对象存储系统进行数据的读写。同时数据会被保持在内存中，必要的时候才以LRU(Least Recently Use)策略写入磁盘。
    • 尽管实例调用了大量的RPCs，由于相关的meta数据量很小，以及大多数的task都是在本地调度，并且GCS的拷贝过程均使用cache，整个过程的整体开销是比较小的。可以看到，Ray使用数据往代码方向移动的策略，它使用对象存储的方式来管理不可变对象，将数据放在每一个节点上存为一个对象，进行数据共享。

• RLlib，基于Ray对RL系统的抽象层

  • 为保障RL算法在Ray框架下的通用性和高可伸缩性，Rllib基于Ray增加了一层抽象，提供策略评估器（graph）和策略优化器两个组件来实现智能体策略的分布式评估和训练。策略评估器封装了与深度学习框架的交互；策略优化器负责分布式采样、参数更新和管理replay缓冲区等跟RL性能强相关的任务。
  • Rllib内部构建了RL算法中不同形式的计算模型，比如无导优化，model-base，策略优化以及多种异步任务，任务嵌套等，其中还内置了一些经典算法，如A3C,DDPG,DQN，PPO等，便于用户更好的集成和重复使用。
  • 从上层来看，Rllib提供一个Agent给用户来封装策略和环境的交互过程，通过这个接口，策略可以进行trained，checkpoint，以及action 的计算。环境根据action给出一个观测信息，该观测信息经过一个preprocesser和filter（e.g 均值归一化）之后，被送到一个神经网络Model进行推理；推理后的逻辑值经过行为分配模块提取具体的action值，再次送给环境进行下一次交互。
  • Rllib语法上可以按照经典的交互过程（e.g mdp），集中编码RL的学习过程，对于每个分布式的rl算法，可以编写一个等价的算法，显示逻辑上的集中式程序控制。同时算法子任务交给别机器进行异步/同步处理。百度的PARL也是类似的做法。

• Dopamine多巴胺 (Google)是一种快速RL算法原型设计的研究框架。它旨在满足一个小的，易于理解的代码库的需求，用户可以自由地尝试疯狂的想法（目标是推测性研究/speculative research）。

  • 多巴胺坚持的两个主要的设计原则是：1) “小而精”。（紧凑而自足）；2）可靠和可重复实现。
  • 多巴胺的架构设计初衷是聚焦value-based RL算法，主要是DQN系，应用到Atari 2600 游戏。Runner模块管控agent和ALE环境的交互以及相关信息的记录，具体来看，交互过程中通过Checkpoint周期性保存experiment states和weights，以期望优雅的复现和模型权重重复使用；Runner调用Logger用于保存实验的统计数据，比如，训练/评估时的累积回报，用于tensorboard可视化。其论文提到，发布当时完整的项目只包含12个文件，共2000+行python代码。目前公开github库上的代码文件结构基本一致。
  • Dopamine为其代码库提供了一整套测试，代码覆盖率超过98％。此外，为确保代码的正确性，这些测试提供了Colab形式的文档，类似notebook，补充随框架提供的常规文档和交互式笔记本。Dopamine对每一个模块使用独立的 gin-config配置文件，并且对每一次实验使用独立的配置文件，将所有相关的配置集中管理。

• OpenAi Baselines 更像是一个高性能SOTA RL算法的实现库集合，用于benchmarking。

  • OpenAI实现该算法库总结的一些实践经验：1）与random baseline对比，避免无效的学习；2）注意非破坏性的bugs, 据统计6/10 的RL算法存在微秒的bugs。e.g. 在某些样本上忽略梯度的计算，causal convolution计算异常导致过高的分数值；3）查看agent在环境/真实世界的实际表现状态，e.g,数据转换错误。

• Horizon，是Facebook开源的一个端到端的RL平台。它是用Python构建的，使用PyTorch进行建模和训练，使用Caffe2进行模型服务。该平台构建了训练主流DRL算法的工作流程pipeline，包括数据预处理，特征转换，分布式训练，虚拟策略评估（counterfactual policy evaluation，CPE）和优化服务，划分为training,serving, Preprocessiong 三个组件。 不像其他RL框架主要聚焦原型和研究，Horizon 的设计定位是工业级真实数据的case，其主要特点是：1）数据级一般是百万到十亿级别的状态观测；2）与simulation相比，反馈环路比较缓慢；3）实验需要非常小心的处理，比如，在算法发布之前需要进行有效的性能评估（CPE, A/B test）。 在facebook内部有消息推送，页面管理员通知，视频传送自适应比特率流（adaptive bitrate, ABR）等产品上使用

• Coach，是英特尔开源的一个Python环境，以一种模块化的方式对智能体与环境之间的交互进行建模。其通过暴露简单的API接口，使用户可以简单地集成新的算法或环境。Coach要求Agent必须包含至少一个神经网络作为函数近似器，用于动作的选择。Coach被抽象封装为环境，算法，神经网络，探索策略和缓存等模块，以便于用户组合使用。

  • Coach 一个重要机制是预制，通过封装，预制算法、环境、网络结构和探索策略等多种参数，其目标是让用户可以基于已有模块，方便地进行复用和扩展。为了让用户更加方便地复用Coach已提供的相关算法，从控制流程的角度出发，平台设计了GrahManager、LevelManager 和Agent这三层抽象。
  • GraphManager用于引导RL任务的整个学习过程。它的主循环，Improve，将heatup，Training和Evaluation三个阶段串行起来。a）heatup 主要负责实验开始前的准备工作，包括收集随机的样本用于填满整个replay buffer；b）Training阶段是实验的主要部分，它包含agent与环境的交互，收集数据，训练agent 的network，以及通过增加noisy 的方式支持对环境的探索；c）Evaluation阶段是对Agent的当前性能进行评估，该阶段中act的行为选择是贪婪的，并且通过多情节评估的平均值进行评价，以避免随机性误差。
  • LevelManager用于代理Agent和环境之间的交互过程。其目标在于解耦环境和Agent 的代码逻辑，以支持更加复杂的交互方式，比如多Agent在同一个环境中交互的时候，其中各Agent的动作选择将由LevelManager来管理。LevelManager把Agent和环境的交互过程隐含在其内部，那么LevelManager可以看做是上层的一个环境，这样就可以灵活的支持构建多层Agent的学习场景。
  • Coach封装了：1）Agent基类；2）RL领域类（如ValueOptimizationAgent，ActorCriticAgent, 以及3）SOAT算法的实现类（如，DDPGAgent，PPOAgent 等）。三层Agent类的封装，用户可以直接调用，扩展比较方便。并且提供了一个评判标准，如是否连续动作，是否有专业领域知识，是否有仿真器等等，用于辅助用户在不同任务场景下RL算法的选择。基类Agent包含三个主要函数：observe、act和train函数。Observe负责处理环境的兼容性，并且组合成一组Transition用于replay buffer的存储；act主要是负责Agent行为预测相关的逻辑；Train负责从replay buffer采样数据，并进行训练的更新。
  • 分布式模式下，policy提供两种同步机制，同步用于on-policy，异步用于off-policy。在训练过程中，Coach通过将相关的训练信息存为.csv文件到experiments指定目录下面，用于dashboard的可视化。同时，在评估过程中，支持打包保存gif格式的图片。Coach在人机交互上面也是属于比较完善的一类。

• Tensorforce来自剑桥大学的几名博士（Michael Schaarschmidt, Alexander Kuhnle and Kai Fricke.）2017年开源的一个项目。

  目前主要是Alexander Kuhnle 这一位作者维护；然后，Michael和Kai跟另外两位（Sven Mika，Eiko Yoneki）开源了一个新的项目RLgraph，这也是下文我们需要继续讨论的一个框架。

  • 缘起，TRPO的代码大量混合tensorflow和Numpy在RL的控制流程中，如此混乱的模块设计，会干扰其他接口的扩展和使用，比如分布式的执行模式。那么，这几位同学开始构建他们的强化学习框架。框架设计的难点在于如何解耦出其它层面的内容，尽可能将共用的部分抽象出来。在强化学习过程中，智能体与环境不断通过交互试错来学习，作者尝试把智能体从环境中解耦出来。
  • Tensorforce基于tensorflow实现，其最主要的特点是明确定义了RL解决方法的声明式接口，集成SOTA的RL算法，并且保持配置的透明性。该框架抽象了下面四层概念：Environment <-> Runner <-> Agent <-> Model。Agent在训练前可以加载model，训练后保存model，运行时接收state，(预处理后)作为model的输入，返回action。模型会根据算法及配置自动更新，即Tensorforce把训练的触发隐含起来了。
  • Runner将Agent和Environment之间的交互抽象出来作为独立函数。那么，这有点类似把强化学习“动的过程静态化”。用户不需要去关注强化学习的交互过程，主要去关注Agent里面model的设计，以及训练的策略。Tensorforce构建的Runner这一层，跟Coach的LevelManager层非常类似。如果用户没有仿真器的话，这一层还可以很好地搭建Agent的API与环境的交互桥梁。
  • Environment根据应用场景的不同需要自己写接口，如果是学习或者算法测试，可以使用现成的基准环境，TensorForce提供了OpenAI Gym、OpenAI Universe和DeepMind Lab的接口。
  • 基于上面的四层抽象，用户只需要声明自己的input/output，声明model 的网络结构或者预处理的操作等等。Tensorforce这样的抽象架构，让用户似乎避开了RL的动态过程，专注于去解决一个网络的设计，或者策略的学习问题，这样的API设计值得借鉴，将环境和模型隔离开来。

• RLgraph(sysML2019, 剑桥)

  如前面提到RLgraph 与Tensorforce具备深刻的渊源关系的。

  • RLgraph模块的封装模式，是基于Tensorforce声明式接口的继承与递进。主要坚持算法跟执行分离的原则，并且借鉴了Ray集中式逻辑信息管理的特性，该框架构建了一个graph 组件的抽象概念。如下图所示，Graph内部包含 API 和设备资源管理、系统构建，以及独立的变量创建和计算逻辑。该graph具备创建，组装和编译三个不同阶段，创建和组装是“静态”过程，真正运行的时候，是基于编译后的tensorflow.op计算图信息。其降低了构建多个session的执行切换开销。这也是为什么RLgraph封装了Ray的分布式执行框架后，可以做到比Ray本身的执行效率更高的原因.
  • RLgraph对算法支持的配置内容与Coach较为近似。如network定义，优化方法，memory，探索方式等。区别在于RLgraph是以配置的形式传递到graph里面进行组装，编译，真正执行的时候，不需再次关注这些信息，因为它们都保存在每个graph的属性里面。组件与组件之间的嵌套调用，通过graph暴露的API接口实现。（由于该框架出来比较新，只有一篇文章，具体的实现方式需要阅读源码后，继续补充）
  • 基于算法与执行分离的原则，RLgraph将执行相关的模块放在了backend层，上层算法可以不具体感知。每个graph组件包含了对相关资源的记录信息，用于隐式的更新相关状态，进而可以让用户更加专注在算法层面的设计，而不用跟执行层高度耦合。并且每个graph都是可以独立测试验证的，可以大大降低用户的开发调测成本。

• Keras RL。为延续Keras的模块化、易扩展性以及用户友好等特性，到RL问题的解决框架中，开源社区基于Keras的基础之上，构建了keras-rl库。该框架继承了Keras 的特性，根据RL问题的领域知识，Keras-rl直接简单抽象，构建了Agent类和Policy类，来满足RL问题求解的基本组件。用户也是只需要串行式的写业务代码，即可以解决简单的RL任务。

由于该框架支持的环境主要是gym，且已有算法只有DQN系的部分内容，故该框架目前已进入“不活跃期”。故该框架不做深入探讨。

• Gorila (DeepMind, Google Reinforcement Learning Architecture)是DeepMind团队于2015年发布的DRL大规模并行学习框架，其专注于DQN系列算法（主要是off-policy问题），利用并行计算的能力，来提高解决单智能体（single agent）问题的效率。Gorila架构主要包含四大组件：

  1. 分布式的经验回放池，experience replay memory；
  2. 并行的Actor与环境独立交互，产生行为数据，放入经验回放池；
  3. 分布式的神经网络表示值函数或行为策略，即Parameter Server实现。
  4. 并行的Learner从经验池采样batch数据，进行训练；每个Learner进程独自跟Parameter Server同步以及更新网络权重的梯度。

  为了避免任何组件的瓶颈，Gorila架构设计的这四个模块支持独立扩展，以达到完全分布式的风格。

• Amazon SageMaker RL, 作为第一款云托管强化学习商用服务，通过提供托管式强化学习算法、支持Intel Coach 和 Ray RLlib工具框架、多种模拟环境（包括 Gym，MATLAB 和 SimuLink）以及 AWS RoboMaker 集成，让任何开发人员都能使用强化学习进行构建、训练和开发。AWS RoboMaker是 AWS 新推出的机器人服务， 它提供了一个与 SageMaker RL 良好集成的模拟平台。该服务提供了从环境的定义、模型训练代码构建（支持notebook模式）、分布式训练到模型评估、部署，以及可视化训练指标等整套工作流。值得注意的是，该服务集成了Intel Coach，Ray Rllib和OpenAI Baselines，集成的处理方法值得我们借鉴，但是其相关技术细节并没有太多信息提供。

• PARL(百度)的定位是一个高性能，灵活的RL框架。强调复现和并行支持，并提供较好的扩展性。Agent主要包含三部分：

  • Model 用来定义前向(Forward)网络，这通常是一个策略网络(Policy Network)或者一个值函数网络(Value Function)，输入是当前环境状态(State)。
  • Algorithm 定义了具体的算法来更新前向网络(Model)，也就是通过定义损失函数来更新Model。一个Algorithm包含至少一个Model。
  • Agent 负责算法与环境的交互，在交互过程中把生成的数据提供给Algorithm来更新模型(Model)，数据的预处理流程也一般定义在这里。
  • PARL将整个框架实现分为Actor/Learner 两个部分：Actor 负责与 simulator 交互，生成数据提供给 Learner；Learner 负责收集数据来进行训练，同时把最新的模型推送给 Actor。使用zmq通信，基于 发布-订阅 C/S架构，并且PARL隐含了消息的传递过程。PARL没有真正的分布式，它使用python装饰器的语法，基于zmq的发布订阅模式，构造了一个基础的消息传递C/S模型，当注册remote修饰符的时候，调用的函数被传输到远端的进程执行，与Ray相比，由于没有对GPU等资源的管理，这个远端函数/类只能执行cpu操作。具体的执行过程，猜测 PARL也打算使用pyarrow，（即ray中使用的数据共享模块，代码中看到了import pyarrow，但是没实际使用。基于remote+pyarrow这两点，猜测其设计出发点 :））
  • 在 PARL 中，通过parl.remote_class 修饰器即可以对 Actor进行并行化改造，就可以像在本地操作一样对 Actor 进行操作，比如 Leaner 需要给 Actor 传输参数，只需要在 Learner 端执行 actor.set_param(params) 函数即可。在实际的编码过程中，用户不需要关心数据是如何通过网络传输过去的，也不需要维护多线程队列这些数据结构来实现数据的同步，用户写并行代码和写多线程代码一样简单，用户的易用性上值得参考（同样来自Ray的特性）。
  • 从官方提供的性能测试来看，在数据吞吐量上百度对比Rllib，针对交互数据的收集有159.4%的提高。来说明 PARL 在并行性能上达到了业界领先的水准。

2. Simulator开源仿真器

• OpenAI Gym 是OpenAI为更好地评估强化学习算法，于2016年开源的一个工具包，它整合了当时几个最好的测试集，RLPy，RL-Glue，PyBrain，RLLib(saminda) 等，提供统一的环境接口，便于算法研究人员快速的测试其RL算法，并提供一个排行榜进行分享与交流。其主要包含以下几个特点：

  • 只专注于环境的抽象，最大化用户的自由度来实现各自的算法。基于episodes提供(observation, reward, done, info)的统一接口。集成环境有：a) 经典的控制任务，如倒立摆，过山车；b) 规则算法，比如，倒排；c) Atari 游戏，使用Arcade Learning Environment；d) 棋盘游戏；e) 2d和3d 的机器人。
  • 强调数据采样的灵活性，不仅仅注重在最终的结果表现。评价RL算法的好坏包含两部分，最终性能和学习的时间。学习时间的成本可以以某种方式平摊到每次交互的reward中去。
  • 鼓励同行的review，而不是竞赛。提供一个benchmarking的窗口，即scoreboard，用户可以提交其算法code和参数，有兴趣的同学可以直接进行重新实验，进而可以客观地判断该算法是否有“过拟合”现象。
  • 严格版本化环境的名称，以更好的向后兼容。比如，Cartpole-v0， Cartpole-v1.
  • 交互的过程是可以记录的。Gym 仿真环境的控制流程是一个典型的“智能体-环境”情节式交互模式，在每一时刻，智能体选择一个动作，环境返回下一个状态和奖励。
  • Gym的环境主要是用于single智能体在虚拟环境的评估测试，不支持多智能体之间的通信协作,也不支持在物理的机器上面验证RL算法。但是作为一个经典的算法验证基础环境，很多RL研究人员往往首要使用Gym来做测试对比。

• Rllab、garage(UCB, OpenAI etc, Gym 的升级). Rllab环境与Gym相比，主要是增加了连续控制任务的环境。并且集成了一些就经典的RL算法的实现。目前Rllab环境已经停止更新，正在迁移到garage 项目。

• garage项目的定位是可重复的（reproducible）RL研究，完全兼容OpenAI Gym环境。garage所有的环境都实现了gym.Env, 故garage的所有组件可以使用gym.Env所有环境。目前官方只支持Python3.5+，从开发运行环境上看，garage已经进入RL算法开发和评估框架的范畴，内置了DQN，DDPG，PPO等算法，支持使用tensorflow框架设计算法模型，无缝支持在亚马逊的EC2集群上运行内置的强化学习相关算法，并且自带可视化工具包。该项目主要针对Gym问题

• TORCS (he Open Racing Car Simulator）本身是一个跨平台的赛车游戏模拟器，由于其定位是模拟游戏比赛，视觉信息是虚拟的机动车（赛车），视觉效果较为简单，后台使用C/C++编写的，故对计算资源的要求比较低，在Linux操作系统上是一个比较流行的游戏。最初的参赛选手一般使用规则控制，或者演化算法相关知识设计和实现其控制器。后续也被RL领域的研究人员拿来作为强化学习的研究环境。Gym_TORCS项目为TORCS封装一层，提供类似Gym一样的接口，便于使用TORCS环境用于RL算法的实验，其使用的通信接口原型来自于2016届的参赛选手SnakeOil。TORCS支持砂石，水泥等配置成不同材质的赛道，支持多赛道的虚拟场景，并且有SDK支持用户自行编辑赛道环境；支持雷达，测距传感和测速等基础的传感器，RGB视觉信息可以切换第一、第三视角。故一些CNN相关的算法也是基于该环境进行研究。随着近几年自动驾驶领域的一些较为高级专业仿真器的涌现，如Intel CARLA， AirSim ，SUMO等等，考虑到TORCS的虚拟特性，它在自动驾驶领域的使用热度已经逐步下降。

• AutoWare (Japan, 自动驾驶)号称是世界上第一款用于自动驾驶汽车的“一体化”开源软件套件。该软件来自名古屋大学的几位老师于2015年发布开源，其定位是自动驾驶技术的研究和开发平台。随后Tier IV，东京大学，大阪大学等机构也一起参与维护该项目。Autoware的功能主要适用于城市，但也可以涵盖高速公路，高速公路，中间地区和地理围栏。它包含了自动驾驶的一整套解决方案，可以用于真实车辆，并且为了安全使用，AutoWare也提供了一整套基于ROSBAG的仿真环境。

  • Autoware提供丰富的自动驾驶模块，包括了自动驾驶中传感，计算和驱动的各个功能组件。支持的传感器包括摄像机，激光雷达，雷达，以及多传感器融合；从感知应用角度看，支持物体检测和跟踪，交通灯识别，车道检测和选择，定位，3D地图等；从规控的角度看，它支持车辆控制驱动，路径规划，导航，轨迹生成等；从整个研究的范围看，支持使用深度学习，基于规则的系统，数据记录，虚拟现实等等。该套件的设计架构如下图所示，从感知，决策，规控模块看，都有相对应的功能组件。从Intel CARLA的扩展支持角度看，AutoWare是自动驾驶领域较为重要的一个开源套件。并且随着Tier IV的加入，该项目已经落地到实际的自动驾驶车辆上面。

• CARLA (Intel, 自动驾驶)是英特尔实验室联合丰田研究院和巴塞罗那计算机视觉中心，于2017年发布的，用于城市自动驾驶系统的开发、训练和评估验证的开源仿真器，发布的时候，即提供了1）规则控制，2）模仿学习，和3）强化学习的测试对比试验。支持多种传感器模式和环境条件的灵活配置。

  • CARLA支持三种感知模式：1）正常的RGB摄像头；2）真实深度（depth）；3）真实的语义分割（semantic segmentation），可以支持道路，交通灯，行人，机动车等12中类别。同时支持第一和第三视角。CARLA支持切换不同的天气场景。2017年发布的时候，该模拟器定义了两个城市的完整地图，用户可以自定义设计自己的地图布局，建筑物与车辆等等。 从接口层面看，CARLA支持ROS，Python API，并且可以直接连接AutoWare仿真器作为baselines测试。

• Apollo (Baidu, 自动驾驶) 生态于2017年发布，它的目标也是致力于构建一个高性能，灵活的自动驾驶架构，用于加速自动驾驶的相关研究，测试与部署。从定位上来说，与前面提到的AutoWare也有一定的类似。从组件上看，也是构建了一整套方案，可以方便地运行在ROS以及车载终端等环境里面。它的目标不是一个通用的仿真平台，更是一整套解决方案，这里不过多探讨。初步看，Apollo本身已经是一套解决方案，从扩展和本身的环境依赖来看，也并不适合于其他外界的框架做交叉融合。

• AirSim (Microsoft, 无人机/自动驾驶)是微软开源的一个跨平台的，建立在虚拟引擎（ Unreal Engine）上的无人机以及其它自主移动设备的模拟器。

  • AirSim 的目标定位是AI研究无缝迁移到物理试验的平台，以测试深度学习、计算机视觉和自主车辆的增强学习算法。它支持嵌入业界流行的飞行控制器相关的硬件属性，以弥补物理硬件设备和视觉逼真模拟之间的差距。（Supports hardware-in-loop with popular flight controllers such as PX4 for physically and visually realistic simulations.）该模拟器创造的是一个高还原的逼真虚拟环境，模拟了阴影、反射等其它现实世界中容易干扰的环境，让无人机不用经历真实世界的风险就能进行训练。
  • AirSim包括物理动力学引擎，车辆、环境、和传感器的模型等均被独立设计，并实现对AirSim依赖的最小化，以达到灵活的可扩展性能。其设计的目标是促使仿真环境下的实验算法可以很快迁移到物理环境中。同时，AirSim本身被开发为一个虚拟的插件，可以简单地放到任何你想要的虚拟环境中。AirSim具备公开的API，以平台独立的方式控制车辆以及探索不同场景下的数据。目前支持C++，Python，C#和Java等语言。
  • 从传感器角度看，仿真器支持IMU，激光雷达，摄像头等经典设备；并且从视觉角度看，跟CARLA类似，AirSim支持深度图，语义分割，第一视角图等不同视觉语义。
  • AirSim专门针对强化学习和深度学习问题而建立，项目已发布具备较完善分布式强化学习的教程，其中包含并且环境探索，训练和测试评估等。AirSim致力于打通仿真器到物理世界的通道，具备比较完善的API接口和对应的开发文档，后期值得我们关注与兼容。

• Webots项目开始于1996年，Swiss Federal Institute of Technology, 瑞士洛桑联邦理工学院的一个项目。后面于1998年孵化为Cyberbotics公司的一款商用的、跨平台机器人建模、编程和仿真平台，然后于2018年12月份开源。目前Webots在工业界和学术界较为广泛使用，宣称上千所高校选用。

  • 在Webots中，用户可以设计各种复杂的结构，在一个共享的环境中设计多种复杂的异构机器人，可以自定义环境大小，环境中所有物体的属性包括形状、颜色、文字、质量、功能等也都可自由配置。它使用Open Dynamics Engine, ODE检测物体碰撞和模拟刚性结构的动力学特性，可以精确的模拟物体速度、惯性和摩擦力等物理属性。每个机器人可装配大量预制的仿真传感器和驱动器,(比如高级自动驾驶的各种传感、执行设备）机器人的控制器可以通过内部集成化开发环境或者第三方开发环境进行编程，控制器对外接口丰富，支持C，C++, Python，Java，Ros，Matlab等多种编程API和插件。并且机器人每个行为都可以在真实世界中测试。Webots支持SUMO接口，以助力自动驾驶交通仿真的相关研究。

• Simulation of Urban MObility，SUMO是一款由德国宇航局（Institute of Transportation Systems at the German Aerospace Center）开发的开源软件，它的功能是对道路交通进行实时的模拟仿真。

  • 它支持交通灯，行人，车辆，道路等不同物理元素的建模，以支持覆盖大容量道路网络和不同交通模式的仿真。

• MuJoCo（Multi-Joint dynamics with Contact）是一个物理模拟器，可以用于机器人控制优化等研究的商业软件。MuJoCo的api接口在Gym，Rllab和garage中均已支持，如需调用，则需要提前安装MuJoCo软件本身。

• Neural MMO (OpenAI)是OpenAI于2019年3月份开源的大规模多智能体游戏环境。其目标定位是具备持续性和大规模特性的多智能体强化学习的基准环境。其设计的主要基准原则包括：

  • 持续性 (Persistence)：在没有环境重置的情况下，Agent 可以与多个不同 Agent 同时进行学习。策略必须考虑长生命周期范围，并适应其他 Agent 行为中潜在的快速变化。
  • 规模 (Scale)：环境支持大量且可变数量的实体。该环境经实验验证了在 100 server * 128 Agents长达 100M 的lifetimes。
  • 效率 (Efficiency)：进入 Neural MMO 所需的计算资源门槛很低。它支持在单个桌面 CPU 上训练有效的策略。
  • 扩展 (Expansion)：与现有 MMO（Massively multiplayer online game） 类似，Neural MMO 的设计旨在保持更新。目前的核心功能包括 tile-based 地形的程序化生成、食物和水的觅食系统，以及战略作战系统，如下图所示。未来会进行更多的扩展。

• DeepMind Lab (3D)是一个第一视角3D游戏平台，专门为研究通用人工智能和机器学习系统而设计，于2016年发布开源。主要用于研究Agent如何在大型、部分可观测、视觉多样化的环境中学会执行复杂任务。DeepMind Lab有一个简单灵活的API，类似Gym.env的Python接口,可用于探索创造性的任务设计和全新的AI设计。它基于一个被广泛认可的游戏引擎（id software’s Quake III Arena，雷神之锤3：竞技场）所驱动，并针对开发者社区的高效利用进行了定制。它可以丰富的科幻视觉来呈现场景。

  • 丰富的操作能让智能体环顾四周，并以3D的形式移动。示例任务包括收集水果、走迷宫、穿越危险的通道且要避免从悬崖上坠落、使用发射台在平台间移动、玩激光笔、以及快速学习并记住随机生成的环境（可以暂停等待）。与MineCraft和VizDoom相比，DeepMind Lab具备更加丰富的的视觉效果和更自然的物理效果。并且动作空间也更加3D化，如下图所示。
  • DeepMind Lab已经成为DeepMind内部的一个主要研究平台。例如，它被用于开发强化学习的异步学习方法、无监督的辅助工作，以及导航学习等。
  • 该仿真环境略重，对硬件资源有一定要求。在github上也具有一定热度，目前已经5800+ Star，它可以直接跑在GPU服务器上，通过Python API连接驱动，如有算法更近一步的需要，可考虑集成API。

• PySC2 (StarCraft II, DeepMind)。2017年，DeepMind和Blizzard合作推出StarCraft II的研究平台PySC2. 它是基于Blizzard的StarCraft II Machine Learning API封装的Python强化学习环境。该环境暴露了Agent基类的API接口，可以方便地通过继承Agent base类，即可以进行RL相关算法的开发。

• MineCraft 我的世界。它是一款开放世界游戏，玩家没有具体要完成的目标，即玩家有超高的自由度选择如何玩游戏。核心玩法大多围绕破坏和放置方块。游戏的世界主要由粗糙的3D方块组成，表面有些固定的网格（点阵）图案，代表不同的材料，如泥土、石头、各种矿物、水和树干。虽然玩家可以在世界各地自由移动，但方块只能被放置在整数的网格中，除了实体之外，玩家可以收集这些方块，并将其放置在其想要放置的地方，从而进行各项建设（若使用冒险模式则是视游戏设置而定。

  • 该游戏有多种模式，生存模式中玩家必须维持生命并采集资源来打造自己的世界；创造模式中玩家拥有无限的资源并可飞行，大多数玩家会使用此模式来建造大型建筑；冒险模式中玩家可在其他玩家定制的地图中游玩。截止2019年5月，MineCraft游戏成为有史以来最畅销的电子游戏。也正是由于其策略的灵活性和环境的复杂性，该游戏被微软，NeurIPS等机构用来作为相关AI竞赛的测试平台。

• ViZDoom 是基于第一视角射击 Doom游戏的人工智能研究平台[69]，如下图。VizDoom 主要针对的是机器视觉学习，特别是深度强化学习的研究。该平台允许自定义开发Bots，使用屏幕图像信息进行对战。它具备简单的类似Gym的Python API接口。与MineCraft一样，常被用来作为AI相关竞赛的载体。自2016年开始，Visual Doom AI Competition (VDAIC)是IEEE旗下一个比较hot的AI比赛。

Reference

• [1] G. Brockman et al., “OpenAI Gym,” Jun. 2016.
• [2] Y. Duan, X. Chen, R. Houthooft, J. Schulman, and P. Abbeel, “Benchmarking Deep Reinforcement Learning - for Continuous Control,” Apr. 2016.
• [3] A framework for reproducible reinforcement learning research: rlworkgroup/garage. Reinforcement - Learning Working Group, 2019.
• [4] “torcs › News.” [Online]. Available: http://torcs.sourceforge.net/. [Accessed: 07-May-2019].
• [5] S. Kato, E. Takeuchi, Y. Ishiguro, Y. Ninomiya, K. Takeda, and T. Hamada, “An Open Approach to - Autonomous Vehicles,” IEEE Micro, vol. 35, no. 6, pp. 60–68, Nov. 2015.
• [6] S. Kato et al., “Autoware on Board: Enabling Autonomous Vehicles with Embedded Systems,” in Proceedings of the 9th ACM/IEEE International Conference on Cyber-Physical Systems, Piscataway, NJ, USA, 2018, pp. 287–296.
• [7] A. Dosovitskiy, G. Ros, F. Codevilla, A. Lopez, and V. Koltun, “CARLA: An Open Urban Driving - Simulator,” ArXiv171103938 Cs, Nov. 2017.
• [8] C. Team, “CARLA,” CARLA Simulator. [Online]. Available: http://carla.org//. [Accessed: 28-May-2019].
• [9] An open autonomous driving platform. Contribute to ApolloAuto/apollo development by creating an - account on GitHub. Apollo Auto, 2019.
• [10] S. Shah, D. Dey, C. Lovett, and A. Kapoor, “AirSim: High-Fidelity Visual and Physical Simulation for - Autonomous Vehicles,” ArXiv170505065 Cs, May 2017.
• [11] D. Krajzewicz, J. Erdmann, M. Behrisch, and L. Bieker-Walz, “Recent Development and Applications of - SUMO - Simulation of Urban MObility,” Int. J. Adv. Syst. Meas., vol. 3&4, Dec. 2012.
• [12] “MuJoCo.” [Online]. Available: http://www.mujoco.org/index.html. [Accessed: 10-May-2019].
• [13] J. Suarez, Y. Du, P. Isola, and I. Mordatch, “Neural MMO: A Massively Multiagent Game Environment - for Training and Evaluating Intelligent Agents,” Mar. 2019.
• [14] “Neural MMO: A Massively Multiagent Game Environment,” OpenAI, 04-Mar-2019. [Online]. Available: - https://openai.com/blog/neural-mmo/. [Accessed: 05-Jun-2019].
• [15] C. Beattie et al., “DeepMind Lab,” ArXiv161203801 Cs, Dec. 2016.
• [16] “DeepMind and Blizzard open StarCraft II as an AI research environment,” DeepMind. [Online]. - Available: https://deepmind.com/blog/deepmind-and-blizzard-open-starcraft-ii-ai-research-environment/. - [Accessed: 10-May-2019].
• [17] “Blizzard/s2client-proto,” GitHub. [Online]. Available: https://github.com/Blizzard/s2client-proto. - [Accessed: 10-May-2019].
• [18] “我的世界,” 维基百科，自由的百科全书. 02-Jun-2019.
• [19] M. Kempka, M. Wydmuch, G. Runc, J. Toczek, and W. Jaśkowski, “ViZDoom: A Doom-based AI Research Platform for Visual Reinforcement Learning,” May 2016.