环境设计背景

现在我们已经安装好项目，可以开始设计环境了。在传统的强化学习（RL）问题描述中，环境负责使用智能体生成的动作来更新 “世界” 的状态，最终计算并返回观察值和奖励信号。然而，关于模拟机制本身，Isaac Sim 和 Lab 有一些独特的概念。传统的强化学习问题描述设定了一个 “世界” ，但我们却没有这样的奢侈品，我们必须自己定义这个世界，成功与否取决于理解如何构建这个世界以及它如何适应模拟。

App、Sim、World、Stage 和 Scene

World 是由笛卡尔坐标系的原点和定义它的单位所定义的。有多大或多小？离得多近或多远？ 对这些问题的答案只能相对于某种上下文的参考框架来定义，而这个参考框架就是定义世界的。

结构上，world “上方” 是 Simulation 和 Application 。 Application 是 “负责其他一切的东西” : 它控制所有资源管理以及在我们完成后启动和销毁模拟。当我们 用模板进行训练启动 时，出现的窗口与用来训练 cartpoles 的视口是 Application 窗口。但是，Application 不是由 GUI 定义的，即使在headless模式下运行，所有模拟都有一个控制它们的 application。

Simulation 控制着世界的 “规则” 。它定义物理法则，比如时间和重力如何工作，以及频率如何执行渲染。如果 application 持有 sim，那么 sim 就持有世界。Simulation 通过将时间划分为许多不同的子步骤，每个步骤都致力于更新世界到一个状态。Isaac Lab 中的许多 API 是专门为了连接到这些不同步骤而编写的，你经常会看到类似 _pre_XYZ_step 和 _post_XYZ_step 的命名函数，其中 XYZ_step 是模拟的一个子步骤的名称，比如 physics_step 或 render_step 。

结构上，world “下方” 是 Stage 和 Scene 。如果世界为模拟提供了空间上下文，那么 Stage 为世界提供了 组成上下文 。假设我们想在房间里模拟一张摆好了餐具的餐桌: 在这种情况下，房间就是 “世界” ，我们将世界的原点选为房间的一个角落。餐桌在房间里的位置被定义为从世界原点到我们选择的餐桌上的某个点的向量，我们将这个点选为固定在桌子上的一个 新 坐标系的原点。对我们 智能体来说，与其根据房间的角落谈论食物和餐具在餐桌上的位置，不如更喜欢使用相对于餐桌定义的坐标。然而，模拟需要知道这些全局坐标，以便正确地模拟下一个时间步，因此我们必须定义如何将这两个坐标系统 组合 在一起。

这就是 Stage 的作用: 模拟中的每一个对象都是一个 `USD 原语<https://openusd.org/release/glossary.html#usdglossary-prim>`_ ，而 Stage 则将这些原语之间的关系表示为一棵树，上下文由树中的相对路径来定义。舞台上的每个原语都有一个名称，因此在这棵树上有一个路径，例如 /room/table/food 或 room/table/utensils 。关系由这棵树中给定节点的 “父节点” 和 “子节点” 来定义: table 是 room``的子节点，但是是 ``food 的父节点。父原语的组成属性应用于其所有子节点，但是子原语有能力在必要时覆盖父属性，这在材料的情况下经常发生。

有了这些词汇，我们终于可以谈论 Isaac Lab 中最关键的元素之一 Scene 了。深度学习，在各种形式中，都源于数据的分析。即使在机器学习中，数据是通过受训机器人的传感器获取的。设置机器人、收集数据并重置机器人以收集更多数据所需的时间，是教机器人做 任何事情 的基本瓶颈，无论使用什么方法。Isaac Sim 让我们可以访问机器人而无需实际的物理机器人，而 Isaac Lab 则给我们提供了 向量化 的能力: 有效地模拟训练过程的多个副本，从而提高数据生成速度，加速按比例训练。场景管理了舞台上对这个向量化过程有影响的那些原语，被称为 simulation entities 。

假设你想模拟一张摆好了餐具的餐桌，是因为你想训练一个机器人来为你摆餐具！机器人、桌子以及桌子上的所有物品都可以注册到环境的场景中。我们可以指定要创建多少个副本，场景将自动构建并在舞台上运行这些副本。这些副本被放置在舞台上的新坐标上，定义了一个新的参考框架，从中观察和奖励可以被计算。场景中的每个副本都存在于舞台上，并且由同一个世界进行模拟。这比为每个副本运行单独的模拟要高效得多，但同时也会带来不同副本之间意外交互的可能性，因此在调试时要牢记这一点。

现在我们对机制有了掌握，可以看一下为我们的模板项目生成的代码！