跳转至

资产

当你已经能够启动本地模拟器后，下一层需要理解的就是资产包。LAV2 将几何、场景描述以及后端相关的机器人定义统一放在 lav2.assets 下面，这样同一个仓库就可以同时服务 MuJoCo、Isaac Lab 以及相关任务封装。

为什么需要资产包

lav2.assets 是仿真资源稳定的查找入口。本地 runner 不会硬编码绝对路径，而是通过 load_callback 从包资源中解析文件。

这种模式能够让本地运行、editable install 以及下游任务包围绕同一个资产根目录保持一致。

以 MJCF 作为建模标准

对 LAV2 来说，MuJoCo MJCF 是仿真资产的实施标准，这个选择是有意为之：

  • 对当前使用场景而言，MJCF 实际上可以视作 URDF 的增集。
  • URDF 原生并不能很好地描述本项目所需的旋翼电机及其执行语义，除非依赖特定模拟器的扩展或插件。
  • 本地模拟器与控制闭环本身就围绕 MuJoCo 构建，因此最精确、最容易验证的表达应当首先落在 MJCF 上。

在实际工作流中，建模路径是：

  1. 先在 MJCF 中建立权威的机体模型。
  2. 通过 lav2.controller.run 在本地 MuJoCo 仿真中验证行为。
  3. 在需要时，再将该 MJCF 资产转换到其它后端格式。

这样可以保留一个主要的机械描述来源，而不是长期维护多个能力上限不同、且都需要手工编辑的格式。

MuJoCo 资产加载流程

对本地健全性检查来说，关键路径如下：

  1. lav2.controller.run 调用 load_callback。
  2. load_callback 从 lav2.assets 中解析 MuJoCo 场景。
  3. MuJoCo 加载该场景，场景内部再引用 LAV2 的 MJCF 机体模型及其几何资源。
  4. 控制闭环将执行器命令写入场景中定义的 actuators。

这也是为什么当 viewer 无法启动，或者机器人显示不完整时，本地仿真指南会先让你检查资产是否正确。

转换得到的其它格式

其它格式是从 MJCF 模型派生出来的下游产物，而不是与其平行的权威来源。Isaac Lab 使用的 USD 资产最初是从 MuJoCo 侧描述转换而来，之后又进行了手工编辑，因为 Isaac Lab 对 USD 还有额外要求，直接转换并不能完全满足。

因此更准确的理解方式是：

  • MJCF 是参考实现。
  • 其它格式的资产继承自 MJCF 设计。
  • 转换之后仍然可能需要后端相关的手工调整。

这在排查跨后端不一致时尤其重要。如果 MuJoCo 与 Isaac Lab 表现不一致，应该先检查问题是否来自转换边界，或者来自后端特定的后处理修改，而不是默认两份表示是独立演化出来的。

资源边界

MJCF 与 USD 资产树都位于包的资源根目录之下，但它们有意不被当作 Python 子模块。它们是供仿真后端使用的资源目录，而不是导入接口。

因此文档中值得交叉引用的 API 表面，主要是包级资产入口 lav2.assets 以及实际消费这些资源的运行时代码，尤其是 lav2.controller.run。

实际编辑规则

  • 当平台几何结构或执行语义发生变化时，应把 MuJoCo MJCF 描述视作源资产进行修改。
  • 尽量让 loader 与任务封装继续依赖 lav2.assets，这样路径解析在 editable install 与打包分发场景下都能保持稳定。
  • 当需要引入新的后端时，优先从 MJCF 模型转换或派生，而不是直接维护一套完全独立、手工编写的资产定义。
  • 如果某个后端在转换后仍需要手工修改，应明确记录这一约束，避免把派生资产误认为是独立维护的事实来源。

API 交叉引用