urml-openpi-bridge: a URMLOutputs class for emitting substrate-neutral primitives alongside actions

[idoco2003]

Hi,

URML is an open spec I work on for substrate-neutral robot intent. Apache 2.0, urml.dev. I'm trying to figure out the cleanest way to plug into openpi and wanted to ask before writing code.

The shape I'm thinking about is a custom Outputs class, in the style of LiberoOutputs in src/openpi/policies/libero_policy.py. It takes the action chunk from policy.infer(example)["actions"] and emits URML primitives alongside the raw tensor, so the eval harness still sees a normal policy and URML translation rides on top.

What URML gets out of it: the Layer-2 primitives (move_to, grasp, release, measure, wait_for, report, plus a few profile-specific ones) sit above ROS 2, PX4, Isaac, MuJoCo, AUTOSAR Adaptive, OPC UA Robotics. A π policy whose Outputs class emits URML can drive any of those substrates without retraining.

Full write-up if you want the detail:
https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0045-physical-intelligence-openpi.md

Things I'd actually want input on before building anything:

1. Outputs class (the LiberoOutputs shape) vs. wrapping policy_config.create_trained_policy and intercepting infer. Which feels more natural on your side?
2. Better as a contribution into Physical-Intelligence/openpi or as a standalone urml-openpi-bridge on PyPI?
3. Does the move_to collapsing rule (contiguous joint or EE-pose tokens become one primitive) actually hold across π-zero, π-zero-FAST, π-zero.5, or do their action token formats differ enough to need per-model logic?
4. For the websocket remote-inference path, does the URML translation belong on the server side or the client side?
5. openpi consumes LeRobot v3 datasets; a sidecar annotation for URML programs would be the cleanest data shape from my side, but happy to align with whatever you'd prefer.

No rush on this. I'd rather get the shape right than ship a wrapper you'd want rebuilt.

Ido (greenvh@gmail.com)