让你的火柴人动起来！DeepMind发布强化学习环境dm_control

十年来，强化学习在一些困难问题上，如在游戏上取得了长足的进步。其中游戏的学习环境为评估和比较算法提供了一套标准基准，它是这些进步的重要促进因素。而DeepMind控制套件也为连续控制问题提供了一些类似的标准基准。

目前，OpenAI Gym已经为连续强化学习任务提供了一套作为基准的连续控制域。虽然我们的控制套件也是一组面向连续RL任务的基准，但和前者相比还是有显著差异。我们专注于连续控制，如会根据不同门类将观察到的结果分类（位置、速度、力等），而不是统一联合成一个矢量。我们统一的奖励架构提供了可解释的学习曲线，它汇总了全套性能数据。此外，我们还强调用统一设计模式生成高品质代码，提供了兼具可读性、透明性和易扩展性的代码库。最后，这个控制套件和诸如Gym等竞品相比，除了具备了它们都有的域，还增加了大量新内容。

DeepMind控制套件是一套稳定的、测试结果良好的连续控制任务，它十分易于使用和修改。这些任务由Python编写，并用MJCF定义。标准化的动作（action）、观察（observation）和奖励结构，使得它的基准简单基础，学习曲线易于解释。

模型和任务验证

在连续控制的情况下，任务验证意味着要确保物理模拟的稳定性，同时保证这个任务是可以被完成的：

• 模拟物理运动很容易会出现不稳定和分歧等情况，这主要是因为它的时间步长是离散的，容易导致错误引入。较小的时间步长虽然更稳定，但也意味着单位模拟时间的计算更多，所以时间步长的选择要在稳定性和计算速度之间折衷。更重要的是，强化学习智能体喜欢“钻漏洞”，十分擅长寻找并利用这些不稳定性。

• 写出比计划更简单或更复杂的任务是容易的，但它们也许没有解决方案，或强化学习得出了很离谱的结论，比如“作弊”。为了防止这些情况发生，基于雅达利游戏的街机游戏学习环境ALE已经被广泛测试了长达10年。然而，人们至今还是无法解决连续控制问题，所以我们必须采取不同的方法。

为了解决这两大挑战，我们针对所有类型的任务运行了各种各样的学习智能体，并对每个任务的设计进行了迭代，直到我们确信其中的物理运动是稳定的、没有漏洞的，并且每个任务都至少能由一个智能体来完成。我们把能解决任务的智能体归类到benchmarking集中，而没能解决任务的智能体则被归类到任务的extra集中。

强化学习

一个连续的马尔可夫决策过程（MDP）由状态集S、动作A、动态（转换）函数f(s, a)、观察函数o(s, a)和一个标量奖励函数r(s, a)构成。

• 状态（state）：状态s是实数S ≡ Rdim(S)的向量，它比实数增加了一个表示空间方向的单位四元数（unit quaternion），这个四元数∈ SU(2)。通过begin_episode()，状态s会在一些子集：S0 ⊆ S中被初始化。为了防止得出“生硬”的结论，S0会保持变化。

• 动作（action）：除了物理模型LQR（见下文“域和任务”），其他模型动作向量的区间为：a ∈ A ≡ [−1, 1]dim(A)。

• 动态（dynamics）：当状态按照连续的常微分方程s˙ = fc(s, a)进行概念演化时，实际上时间积分是离散的，它们有一些固定的、有限的时间步长：st h = f(st, at)。观察（observation）：函数o(s, a)描述的是学习智能体的观察结果。只要没有point-mass:hard，所有任务的状态都可根据一个单一的观察值更新。依赖当前状态（位置、速度）的观察特征实际是当前状态的函数。而依赖控件（如触觉传感器读数）的观察特征则是前一次转换的函数。观察依靠Python的OrderedDict实现。

• 奖励（reward）：在控制套件中，除了LQR，其他模型的奖励区间为：r(s, a) ∈ [0, 1]。有些任务的奖励是稀疏的，这时r(s, a) ∈ {0, 1}。这个架构由函数tolerance()推进（下图），由于tolerance()生成的数都在区间内，所以无论是求平均值还是相乘，它们都会继续保留这个属性。

• 终止与折算（termination & discount）：控制问题可被分类为有限时域、first-exit和无限时域3种（Bertsekas，1995）。我们的控制套件任务没有状态和时间限制，因此属于无限时域。理论上来说，我们的目标值就是连续时间的无限平均：limT→∞ T−1∫0Tr(st, at)dt。但事实上，我们的智能体都用了discount公式∫0∞e−t/τr(st, at)dt。当τ → ∞（即γ → 1）时，用discount公式和求无限平均值得到的结果是相同的。

• 评估（evaluation）：虽然我们希望智能体能无限优化结果，但是这在实际操作中难以衡量。作为替代，我们将时间步长固定在1000，再加上当智能体状态接近目标状态时，奖励函数r ≈ 1，所以反映观察结果的学习曲线在y轴上的区间都是[0, 1000]。

如果x在区间内，函数tolerance(x, bounds=(lower, upper))返回1，反之为0；如果给出了margin参数，那输出会逐渐平稳下降，取值为margin范围内的value_at_margin。它支持几种激活函数：上图中的为3种无限时域激活函数，它们的value_at_margin必须为正；下图中是3种有限时域激活函数，它们的value_at_margin=0。

MuJoCo物理引擎

MuJoCo物理引擎是一种快速、坐标精确、支持连续时间的物理引擎。和其他流行引擎相比，它体积小，功能全面，可以扩展计算密集型技术，因此可以被应用到复杂的动力系统中，深受机器人学习和强化学习研究人员欢迎。

一个域指的是一个物理模型，而一个任务指的是一个具有特定MDP结构的实例。例如，控制Cart-pole模型进行swingup（摆动）和balance（平衡）的主要区别在于杆子方向的初始化方式（向上/向下）。在一些情况下，如当系统随机生成一个模型时，它在不同任务中也许有不同的物理属性。

在我们的控制套件中，任务被按照预定义的标签整理成组。其中，用于充当表现基准的任务被分类在BENCHMARKING组中，而其他任务则因为过于复杂，或者不符合标准，被分类在EXTRA组中。我们可以在ALL_TASKS组中访问这些任务。下面是一些域的简介，它们都由3个整数构成，分别代表状态、控制和观察空间的维度。

Pendulum (2, 1, 3)：经典的倒立摆。如果要使杆子达到图中状态，那我们的目标是将杆子从自然下垂的静止状态提升到该位置，并要经历几次摇摆和平衡，这时执行器的力矩约为所需力矩的1/6。这在套件里被称为swingup任务，它有一些简单的稀疏奖励：如杆子和垂直方向的夹角在30°以内，奖励1；反之，0。

Acrobot (4, 1, 6)：欠驱动双摆。通过向第二关节施加扭矩，我们的目标是让它摆动同时保持平衡。尽管维度低，但这不是一个简单的控制问题。图中使用的物理模型来自Coulom，而不是早期模型。同样的，利用swingup或swingup_sparse，我们可以为这个物理过程提供平滑的、稀疏的奖励。

Cart-pole (4, 1, 5)：通过向底座施加力来让杆子摆动或保持平衡。图中物理模型来自1983年Barto等人的论文。我们的套件为它提供了4个基准任务：当使用swingup和swingup_sparse时，杆子垂直向下；当使用balance和balance_sparse时，杆子保持直立。

Cart-k-pole (2k 2, 1, 3k 2)：这是Cart-pole物理模型的衍生品，我们的套件支持增加杆子数量进行物理模拟。但现在它只支持两种非基准的任务，分别是two_poles和three_poles。

Ball in cup (8, 2, 8)：这是一个平面任务，上方的杯状物体需要在当前平面内进行位移来摆动底部连接的球，同时争取让球落入杯中。这个物理模型需要用到catch任务，它只有一个稀疏奖励：当球在杯子中时，奖励为1；否则为0。

Point-mass (4, 2, 4)：在一个平面内，如果黄点和目标点（红点）重合，奖励为1。在我们的套件里，如果用easy任务，那我们只需对应两点的坐标位置；如果用hard任务，那么由于目标到轴的增益矩阵是完全随机的，所以简单智能体无法解决这个问题，它就不在benchmarking组里。

Reacher (4, 2, 7)：这是一个简单的平面双连杆机械臂，它的触碰位置（黄点）是随机的。这个模型的奖励只有一个，就是黄点与目标红点重合。如果使用easy，你会发现它能比hard更快找到红点。

Hopper (14, 4, 15)：这是一个单足跳跃者，它的初始位置是随机的。在stand任务里，它的奖励是躯干高度达到最低；而在hop任务里，它的奖励是躯干高度和前进速度。

Walker (18, 6, 24)：这是一个由Lillicrap等人改良的平面步行者。在stand任务里，它的奖励是直立的躯干和躯干高度；而在walk和run任务中，它的奖励包括一个令人振奋的前进速度。

Swimmer (2k 4, k−1, 4k 1)：这个平面多轴“游泳者”基于Coulom等人的模型设计，并使用了MuJoCo的high Reynolds流体阻力模型。当“游泳者”的头部处于目标红球中，奖励为1；当“游泳者”逐渐远离红球，奖励平稳减少，且符合柯西分布。控制套件提供了15轴、6轴两种基准任务。

LQR (2n, m, 2n)：n个质点，由m ≤ n根杆子驱动，我们要做的是让这个各关节线性串联的模型前进。它的奖励是位置和控制的平方。针对这个模型，我们从MuJoCo中提取分析转移和控制增益矩阵，并用Riccati迭代在lqr_solver.py中计算最优策略和值函数。由于它的控制和奖励是无限的，所以LQR这个模型并没有包含在benchmarking中。

以上只是部分模型，更多内容，请查询原文。由于论文之后的内容是相关工具、API的介绍，具体可以参看GitHub的技术报告。

DeepMind控制套件和控制包dm_control包含以下工具：

• 一套由MuJoCo物理引擎驱动的Python强化学习环境，可看suite子目录；

• 可用于MuJoCo物理引擎的Python库。

完整指令，请看论文或技术报告。

安装和要求

按照以下步骤安装dm_control：

1. 从MuJoCo网站的下载页面下载MuJoCo Pro 1.50 。必须先安装MuJoCo Pro dm_control，因为dm_control安装脚本会ctypes 根据MuJoCo的头文件生成Python 绑定。默认情况下，dm_control假设MuJoCo Zip压缩文件被提取为~/.mujoco/mjpro150。

2. dm_control通过运行pip install git git://github.com/deepmind/dm_control.git （PyPI包即将推出）或复制存储库并运行来安装Python软件包。 pip install /path/to/dm_control/ 在安装时，dm_control从步骤1中查找MuJoCo头文件~/.mujoco/mjpro150/include，但是可以使用headers-dir命令行参数来配置该路径 。

3. 为dm_control运行时所需的MuJoCo安装许可证密钥。更多详细信息，请参阅MuJoCo许可证密钥页面。默认情况下，dm_control查找MuJoCo许可证密钥文件 ~/.mujoco/mjkey.txt。

4. 如果许可证密钥（例如mjkey.txt）或MuJoCo Pro（例如libmujoco150.so或libmujoco150.dylib）提供的共享库安装在非默认路径中，则分别使用MJKEY_PATH和 MJLIB_PATH环境变量指定它们的位置。

macOS、自制软件用户须知

1. 如果你使用的是Homebrew安装的Python解释器（而不是系统默认安装的），那么用pip，上面的步骤同样适用。

2. 要运行OpenGL，你需要运行brew install glfw，从Homebrew下载glfw软件包。

3. 在运行之前，DYLD_LIBRARY_PATH需要使用GLFW库的路径来更新环境变量。这可以通过运行export DYLD_LIBRARY_PATH=$(brew –prefix)/lib:$DYLD_LIBRARY_PATH来完成 。

控制套件快速入门

from dm_control import suite # 加载一个任务 env = suite.load(domain_name="cartpole", task_name="swingup") # 遍历一个任务集： for domain_name, task_name in suite.BENCHMARKING: env = suite.load(domain_name, task_name) # 进行迭代，输出奖励、discount和观察结果。 action_spec = env.action_spec() time_step = env.reset() while not time_step.last(): action = np.random.uniform(action_spec.minimum, action_spec.maximum, size=action_spec.shape) time_step = env.step(action) print(time_step.reward, time_step.discount, time_step.observation)