urml-mujoco-bridge: completing URML's mujoco-runtime stub into a full MuJoCoAdapter + optional urml_envelope_plugin

[idoco2003]

Hi,

I work on URML, an open spec for substrate-neutral robot intent (Apache 2.0, urml.dev). URML already ships a reference/mujoco-runtime/ scaffold and a gated mujoco-integration.yml CI workflow, but the adapter isn't feature-complete. This is the proposal to formalize it and ask for input on the shape before doing the work.

Two vectors:

Vector A is a full MuJoCoAdapter satisfying URML's substrate Protocol. The adapter wraps mujoco.MjModel, mujoco.MjData, and mujoco.mj_step per the documented Python bindings (>=3.10). Same Protocol as MockROSAdapter and the planned DrakeAdapter (RFC-0059) and IsaacAdapter (RFC-0050); runs URML programs against MuJoCo's physics.

Vector B is an optional urml_envelope_plugin via MuJoCo's documented /plugin/ architecture. At simulation step, the plugin checks the next URML primitive's preconditions against MuJoCo's state and enforces URML's safety envelope without leaving the physics loop. Vector A works without Vector B; Vector B is for users who want simulation-loop-level safety enforcement.

URML's Layer-2 primitives (move_to, grasp, release, measure, wait_for, report, plus profile-specific extensions) sit above ROS 2, PX4, Isaac, MuJoCo, AUTOSAR Adaptive, OPC UA Robotics. URML's substrate-neutrality story leans on MuJoCo more than on any other single piece of upstream open-source.

Being honest: "URML supports MuJoCo" is the current overclaim that this RFC closes. The scaffold exists; the adapter implementation has gaps. I want to fix the overclaim by completing the adapter properly, which is why I'm asking for shape input first rather than just merging code.

Full write-up:
https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0060-mujoco-integration.md

Things I'd want input on:

1. Adapter shape: is wrapping MjModel plus MjData plus mj_step directly the right entry point for URML's Protocol, or do you recommend a different composition?
2. MJCF vs URDF: URML manifests reference URDF more commonly; is MuJoCo's URDF importer sufficient for adapter use, or should the adapter expect MJCF first-class?
3. Plugin viability: is the urml_envelope_plugin (Vector B) a use case the MuJoCo plugin architecture supports cleanly, or are there constraints that change the shape?
4. DeepMind alignment: should URML coordinate the MuJoCo integration with the OXE annotation work (RFC-0046 on the OXE consortium)? Technically independent but institutionally adjacent.
5. CI integration: would DeepMind be open to MuJoCo's CI exercising a URML-validated scenario as one of its integration tests?

No rush.

Ido
greenvh@gmail.com