Hi RoboHive community,
URML (urml.dev) is a small, Apache-2.0 language for describing robot intent: an intent becomes a typed primitive, validated against the robot's declared capabilities and a safety envelope, then dispatched. RoboHive is a unified framework for robot learning, and URML is interesting at the deployment boundary: a policy trained in RoboHive carries observation/action spaces and a training domain, and URML has a "LearnedPolicy" declaration that lets a policy publish those bounds so a deployment is validated against the domain it was actually trained for.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.
Two seams: (1) envelope export -- a RoboHive env defines the obs/action spaces and the domain a policy trains against; emitting those as a URML deployment envelope makes "what was this policy trained for" a typed, checkable artifact next to the weights. (2) validated deployment -- URML then sits between the trained policy and the robot, checking each proposed action against the robot's declared capabilities + the safety envelope before dispatch. The policy decides; URML is the typed gate.
Two real questions: (1) does exporting a trained policy's spaces + training-domain bounds as a declared deployment envelope make sense as an optional artifact? (2) Is a validated-intent gate between a RoboHive policy and a real robot interesting -- and which is the cleaner first seam?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0510-robohive-outreach.md
Thanks for RoboHive; a unified learning framework is a natural place to ask where a deployment envelope and a validation gate fit.
Ido Yahalomi (URML, greenvh@gmail.com)
AI-assisted prose, maintainer-reviewed before posting (see https://github.com/URML-MARS/URML/blob/main/VIBE.md). Human-only correspondence available on request.
Hi RoboHive community,
URML (urml.dev) is a small, Apache-2.0 language for describing robot intent: an intent becomes a typed primitive, validated against the robot's declared capabilities and a safety envelope, then dispatched. RoboHive is a unified framework for robot learning, and URML is interesting at the deployment boundary: a policy trained in RoboHive carries observation/action spaces and a training domain, and URML has a "LearnedPolicy" declaration that lets a policy publish those bounds so a deployment is validated against the domain it was actually trained for.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.
Two seams: (1) envelope export -- a RoboHive env defines the obs/action spaces and the domain a policy trains against; emitting those as a URML deployment envelope makes "what was this policy trained for" a typed, checkable artifact next to the weights. (2) validated deployment -- URML then sits between the trained policy and the robot, checking each proposed action against the robot's declared capabilities + the safety envelope before dispatch. The policy decides; URML is the typed gate.
Two real questions: (1) does exporting a trained policy's spaces + training-domain bounds as a declared deployment envelope make sense as an optional artifact? (2) Is a validated-intent gate between a RoboHive policy and a real robot interesting -- and which is the cleaner first seam?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0510-robohive-outreach.md
Thanks for RoboHive; a unified learning framework is a natural place to ask where a deployment envelope and a validation gate fit.
Ido Yahalomi (URML, greenvh@gmail.com)
AI-assisted prose, maintainer-reviewed before posting (see https://github.com/URML-MARS/URML/blob/main/VIBE.md). Human-only correspondence available on request.