Hi Roboflow Inference 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. Roboflow Inference turns any device into a vision inference server, and on a robot perception feeds action -- which is exactly the handoff URML gates.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.
The mapping: Roboflow Inference produces typed perception outputs (detections, masks). URML consumes a perception result as the condition for a typed primitive, then validates the resulting action against the manifest and safety envelope before it reaches the robot. URML is the perception-to-action gate; it does not do the inference. Separately, a served model's classes map toward a URML perception capability declaration, so a program that conditions on "detect the mug" is checkable.
Two real questions: (1) is "Roboflow Inference perceives, URML validates the action it conditions" a sensible description of the perception-to-action handoff on a robot? (2) Could a served model's classes inform a URML perception capability declaration -- and which is the cleaner first seam?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0515-roboflow-inference-outreach.md
Thanks for Inference; edge perception feeding action is exactly where a validated handoff matters on a robot.
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 Roboflow Inference 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. Roboflow Inference turns any device into a vision inference server, and on a robot perception feeds action -- which is exactly the handoff URML gates.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.
The mapping: Roboflow Inference produces typed perception outputs (detections, masks). URML consumes a perception result as the condition for a typed primitive, then validates the resulting action against the manifest and safety envelope before it reaches the robot. URML is the perception-to-action gate; it does not do the inference. Separately, a served model's classes map toward a URML perception capability declaration, so a program that conditions on "detect the mug" is checkable.
Two real questions: (1) is "Roboflow Inference perceives, URML validates the action it conditions" a sensible description of the perception-to-action handoff on a robot? (2) Could a served model's classes inform a URML perception capability declaration -- and which is the cleaner first seam?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0515-roboflow-inference-outreach.md
Thanks for Inference; edge perception feeding action is exactly where a validated handoff matters on a robot.
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.