Hi SkiROS2 community,
URML (urml.dev) is a small, Apache-2.0 language for describing robot intent: it validates a request against a capability manifest and a safety envelope, then dispatches. Of everything in robotics, SkiROS2's skill model is the closest match to URML's posture: a parameterized skill with pre/post-conditions over a world model is very near a URML primitive with a typed signature and a capability/envelope precondition. So I'm writing to ask how the two should meet.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment, and a genuine design question.
The alignment: a URML primitive (move_to / grasp / set_output, with capability preconditions) lines up with a SkiROS2 parameterized skill (parameters + world-model pre/post-conditions); a validated URML program could populate or drive a skill sequence. And URML's manifest checks -- capability match, workspace bounds, safety envelope -- are exactly the kind of precondition SkiROS2 reasons over before executing a skill, so URML's static gate complements SkiROS2's world-model gate.
Two real questions: (1) How close is a URML primitive (typed args + capability/envelope precondition) to a SkiROS2 skill (parameters + world-model conditions) -- and could one drive the other? (2) Could URML's capability/envelope checks serve as (or feed) SkiROS2 skill preconditions?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0475-skiros2-outreach.md
Thanks for SkiROS2; a skill-based platform with explicit pre/post-conditions is the nearest neighbour to what URML is trying to do, and I'd value your read.
Ido Yahalomi (URML, greenvh@gmail.com)
AI-assisted prose, maintainer-reviewed before posting (see VIBE.md). Human-only correspondence available on request.
Hi SkiROS2 community,
URML (urml.dev) is a small, Apache-2.0 language for describing robot intent: it validates a request against a capability manifest and a safety envelope, then dispatches. Of everything in robotics, SkiROS2's skill model is the closest match to URML's posture: a parameterized skill with pre/post-conditions over a world model is very near a URML primitive with a typed signature and a capability/envelope precondition. So I'm writing to ask how the two should meet.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment, and a genuine design question.
The alignment: a URML primitive (move_to / grasp / set_output, with capability preconditions) lines up with a SkiROS2 parameterized skill (parameters + world-model pre/post-conditions); a validated URML program could populate or drive a skill sequence. And URML's manifest checks -- capability match, workspace bounds, safety envelope -- are exactly the kind of precondition SkiROS2 reasons over before executing a skill, so URML's static gate complements SkiROS2's world-model gate.
Two real questions: (1) How close is a URML primitive (typed args + capability/envelope precondition) to a SkiROS2 skill (parameters + world-model conditions) -- and could one drive the other? (2) Could URML's capability/envelope checks serve as (or feed) SkiROS2 skill preconditions?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0475-skiros2-outreach.md
Thanks for SkiROS2; a skill-based platform with explicit pre/post-conditions is the nearest neighbour to what URML is trying to do, and I'd value your read.
Ido Yahalomi (URML, greenvh@gmail.com)
AI-assisted prose, maintainer-reviewed before posting (see VIBE.md). Human-only correspondence available on request.