Proposal: URML, substrate-neutral robot intent vocabulary above Isaac Lab (RFC for maintainer comment)

[idoco2003]

Hello Isaac Lab maintainers,

URML is an open-source, substrate-neutral language for describing robot intent that compiles down to whatever sits below: Isaac Sim, ROS 2, PX4, MuJoCo, AUTOSAR, and others. Apache 2.0. Spec, validator, and reference runtimes live at https://github.com/URML-MARS/URML.

URML already ships a working IsaacAdapter against Isaac Sim via the isaacsim wheel. RFC-0050 proposes a urml-isaac-bridge package whose Isaac Lab vector adds a URMLIsaacLabTask that loads a validated URML program and runs it inside the Lab's training and evaluation harnesses using your standard Gymnasium-style task registration. The bridge does not modify Isaac Lab internals; it registers through the documented extension points.

Strategic posture, stated explicitly: URML sits ABOVE Isaac Lab as substrate-neutral vocabulary, not as a competing framework. NVIDIA's direction is for Isaac to be the Android of generalist robotics; URML's role is the human-readable intent vocabulary above the simulation and policy-learning layer.

Full RFC:
https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0050-nvidia-isaac-lab-integration.md

This RFC also has a second vector targeting NVIDIA/Isaac-GR00T (a PolicyClient wrapper that lets GR00T policies emit URML primitives as their action vocabulary). I'm filing a scoped Issue on NVIDIA/Isaac-GR00T separately for that vector's specific questions; this Discussion focuses on the Isaac Lab side.

We are looking for your input on:

1. Plugin shape. Is urml-isaac-bridge/isaaclab/ as a separate package the right integration point, or would you prefer URML tasks to live as ManagerBasedEnv subclasses inside the Isaac Lab task registry directly?
2. Reward and termination semantics. URML programs declare intent; Isaac Lab tasks declare reward. Should the task expose a default reward shape (intent-satisfaction signal) and let users override, or stay reward-agnostic?
3. Observation specification. URML's measure reads a named observation. Should the plugin auto-derive an Isaac Lab observation space from the URML manifest's declared sensors, or require explicit declaration?
4. GPU vectorization. Isaac Lab's key strength is parallel-env training. Does running a URML program inside a vectorized env make sense, or should the plugin force num_envs=1 at first?
5. Downstream link. Would Isaac Lab be open to a downstream link from your docs to URML's bridge once it publishes?

URML is independent open-source work; nothing on our side is gated by your response.

Thanks for any time you can spare.

Ido Yahalomi
URML maintainer
greenvh@gmail.com