Skip to content

Assets

After you can launch the local simulator, the next layer to understand is the asset package. LAV2 keeps geometry, scene descriptions, and backend-specific robot definitions under lav2.assets so the same repository can serve MuJoCo, Isaac Lab, and related task wrappers.

Why The Assets Package Exists

lav2.assets is the stable lookup point for simulation resources. The local runner does not hard-code absolute paths. Instead, it resolves files through package resources inside load_callback.

That pattern keeps local execution, editable installs, and downstream task packages aligned around one asset root.

MJCF As The Modeling Standard

For LAV2, MuJoCo MJCF is the implementation standard for simulation assets. That choice is deliberate:

  • MJCF is effectively a superset of URDF for this use case.
  • URDF does not natively describe rotor motors and their actuation semantics in the way this project needs unless you rely on simulator-specific extensions or plugins.
  • The local simulator and controller loop are already centered on MuJoCo, so the most precise and testable representation lives there first.

In practice, the modeling flow is:

  1. Build the authoritative vehicle model in MJCF.
  2. Validate behavior in the local MuJoCo simulation through lav2.controller.run.
  3. Convert that MJCF asset into other backend formats when needed.

This keeps one primary mechanical description instead of trying to maintain multiple hand-authored formats with different feature ceilings.

MuJoCo Asset Flow

For the local sanity check, the path is:

  1. lav2.controller.run calls load_callback.
  2. load_callback resolves the MuJoCo scene from lav2.assets.
  3. MuJoCo loads the scene, which in turn references the LAV2 MJCF robot model and its geometry assets.
  4. The controller loop writes actuator commands into the scene-defined actuators.

This is why the local simulation guide starts with asset verification when the viewer fails to launch or the robot appears incomplete.

Converted Formats

Other formats are downstream products of the MJCF model, not peer authorities. The USD asset used by Isaac Lab was originally converted from the MuJoCo-side description and then edited manually because Isaac Lab imposes additional USD requirements that a direct conversion does not fully satisfy.

That means the correct mental model is:

  • MJCF is the reference implementation.
  • Converted assets inherit from the MJCF design.
  • Backend-specific adjustments may still be required after conversion.

This is especially relevant when debugging cross-backend mismatches. If MuJoCo and Isaac Lab disagree, start by checking whether the issue comes from the conversion boundary or from backend-specific edits rather than assuming both representations evolved independently.

Resource Boundaries

The MJCF and USD asset trees are stored under the package asset root, but they are intentionally not Python submodules. They exist as resource directories for simulation backends, not as import surfaces.

The API surface worth linking from documentation is therefore the package-level asset entrypoint lav2.assets and the runtime code that consumes it, especially lav2.controller.run.

Practical Editing Rules

  • Treat the MuJoCo MJCF description as the source asset whenever platform geometry or actuation semantics change.
  • Prefer keeping loaders and task wrappers anchored to lav2.assets so path resolution survives editable installs and packaging changes.
  • When introducing a new backend, prefer conversion or derivation from the MJCF model before maintaining a fully separate hand-authored asset definition.
  • If a backend requires manual post-conversion edits, document that constraint explicitly so the derived asset is not mistaken for an independently authored source of truth.

API Cross-References