Hi RLBench maintainers,
URML (urml.dev) is a small, Apache-2.0 language for describing robot intent: English sentence -> typed primitive -> static validation against a robot's declared capabilities and a safety envelope -> dispatch, and it composes primitives into behaviors. RLBench defines manipulation tasks with success conditions, which is strikingly close to what a URML behavior describes at the intent level.
Nothing here asks RLBench to change or maintain anything. This is a conceptual request for comment, not a runtime adapter.
The overlap: an RLBench task (open the drawer, stack the blocks) reads like a URML behavior over validated primitives, and URML could add a capability-and-safety-checked description of each task's actions. Two real questions. First, does an RLBench task <-> URML behavior correspondence sound sound, or do the task definitions carry assumptions that would not survive being expressed as portable validated intent? Second, would a capability-checked, substrate-neutral task description be useful to the benchmark, or is the CoppeliaSim/PyRep grounding too load-bearing to abstract over?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0359-rlbench-outreach.md
Thanks for RLBench; a large shared task set moved the field forward.
Ido Yahalomi (URML, greenvh@gmail.com)
AI-assisted prose, maintainer-reviewed before posting (see VIBE.md). Human-only correspondence available on request.
Hi RLBench maintainers,
URML (urml.dev) is a small, Apache-2.0 language for describing robot intent: English sentence -> typed primitive -> static validation against a robot's declared capabilities and a safety envelope -> dispatch, and it composes primitives into behaviors. RLBench defines manipulation tasks with success conditions, which is strikingly close to what a URML behavior describes at the intent level.
Nothing here asks RLBench to change or maintain anything. This is a conceptual request for comment, not a runtime adapter.
The overlap: an RLBench task (open the drawer, stack the blocks) reads like a URML behavior over validated primitives, and URML could add a capability-and-safety-checked description of each task's actions. Two real questions. First, does an RLBench task <-> URML behavior correspondence sound sound, or do the task definitions carry assumptions that would not survive being expressed as portable validated intent? Second, would a capability-checked, substrate-neutral task description be useful to the benchmark, or is the CoppeliaSim/PyRep grounding too load-bearing to abstract over?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0359-rlbench-outreach.md
Thanks for RLBench; a large shared task set moved the field forward.
Ido Yahalomi (URML, greenvh@gmail.com)
AI-assisted prose, maintainer-reviewed before posting (see VIBE.md). Human-only correspondence available on request.