Hi SimplerEnv 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. SimplerEnv reproduces real-robot manipulation policy evals in sim, and the embodiment and task a policy is scored in is exactly the envelope a deployment should be validated against.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.
The mapping: the embodiment, observation/action spaces, and task distribution a policy is scored in under SimplerEnv map onto a URML "LearnedPolicy" deployment envelope. A deployment can then be validated against the setup the policy's numbers were actually obtained in -- and URML checks each proposed action against the robot's declared capabilities + the safety envelope before dispatch, so an out-of-eval-distribution action is caught before it reaches hardware.
Two real questions: (1) does declaring a policy's evaluation setup (embodiment + obs/action spaces + task distribution) as a URML deployment envelope make sense? (2) Is a validated-intent gate that checks a deployment matches the eval setup interesting -- and which is the cleaner first seam?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0511-simplerenv-outreach.md
Thanks for SimplerEnv; tying deployment validity back to the eval setup is exactly the gap a declared envelope closes.
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 SimplerEnv 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. SimplerEnv reproduces real-robot manipulation policy evals in sim, and the embodiment and task a policy is scored in is exactly the envelope a deployment should be validated against.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.
The mapping: the embodiment, observation/action spaces, and task distribution a policy is scored in under SimplerEnv map onto a URML "LearnedPolicy" deployment envelope. A deployment can then be validated against the setup the policy's numbers were actually obtained in -- and URML checks each proposed action against the robot's declared capabilities + the safety envelope before dispatch, so an out-of-eval-distribution action is caught before it reaches hardware.
Two real questions: (1) does declaring a policy's evaluation setup (embodiment + obs/action spaces + task distribution) as a URML deployment envelope make sense? (2) Is a validated-intent gate that checks a deployment matches the eval setup interesting -- and which is the cleaner first seam?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0511-simplerenv-outreach.md
Thanks for SimplerEnv; tying deployment validity back to the eval setup is exactly the gap a declared envelope closes.
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.