Hi URDF tooling maintainers,
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. URDF describes a robot's structure; URML's manifest describes what a robot is allowed and able to do, plus a safety envelope. I'm anchoring this on urdfdom and referencing the sibling tooling (urdfdom_headers, xacro, robot_state_publisher) rather than posting to each.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment, and a design question.
A URDF (parsed by urdfdom, generated via xacro) carries links, joints, limits, and geometry; a URML manifest carries capabilities and a safety envelope. Some manifest fields (reach, DOF, joint/speed limits) could be derived or cross-checked from URDF; others (payload limits, graspable classes, the safety envelope) are genuinely separate. URML's validator could consume a urdfdom-parsed model to bootstrap or sanity-check a manifest, keeping description and capability declaration from drifting. The split: URDF says what the robot is; the manifest says what it is allowed and able to do.
Two real questions: (1) Which URML capability-manifest fields can be derived honestly from URDF, and which are genuinely separate? (2) Would a thin adapter from a urdfdom-parsed model to a URML manifest skeleton be useful — and where should the boundary sit between URDF and capability + safety declaration?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0457-urdfdom-outreach.md
Thanks for the URDF tooling; the most widely-used robot-description format is the natural place for this question.
Ido Yahalomi (URML, greenvh@gmail.com)
AI-assisted prose, maintainer-reviewed before posting (see VIBE.md). Human-only correspondence available on request.
Hi URDF tooling maintainers,
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. URDF describes a robot's structure; URML's manifest describes what a robot is allowed and able to do, plus a safety envelope. I'm anchoring this on urdfdom and referencing the sibling tooling (urdfdom_headers, xacro, robot_state_publisher) rather than posting to each.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment, and a design question.
A URDF (parsed by urdfdom, generated via xacro) carries links, joints, limits, and geometry; a URML manifest carries capabilities and a safety envelope. Some manifest fields (reach, DOF, joint/speed limits) could be derived or cross-checked from URDF; others (payload limits, graspable classes, the safety envelope) are genuinely separate. URML's validator could consume a urdfdom-parsed model to bootstrap or sanity-check a manifest, keeping description and capability declaration from drifting. The split: URDF says what the robot is; the manifest says what it is allowed and able to do.
Two real questions: (1) Which URML capability-manifest fields can be derived honestly from URDF, and which are genuinely separate? (2) Would a thin adapter from a urdfdom-parsed model to a URML manifest skeleton be useful — and where should the boundary sit between URDF and capability + safety declaration?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0457-urdfdom-outreach.md
Thanks for the URDF tooling; the most widely-used robot-description format is the natural place for this question.
Ido Yahalomi (URML, greenvh@gmail.com)
AI-assisted prose, maintainer-reviewed before posting (see VIBE.md). Human-only correspondence available on request.