Hi abb_ros2 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. ABB is one of the largest industrial-robot makers, and a permissively-licensed ROS 2 driver for its arms is a strong home for validated manipulation intent.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.
URML's ROS 2 runtime meets abb_ros2 on its ROS 2 action/service surface (and the ros2_control controllers); a "pick the part from bin A and place it in fixture B" becomes a typed primitive (pick_from / place_at / grasp), validated against the declared reach, payload, and end-effector, and only then dispatched. Validate-before-actuate refuses an out-of-reach pose, an undeclared object class, or a payload over the declared limit before the arm moves.
Two real questions: (1) Is URML's ROS 2 action-surface mapping the right seam for an external validated-intent layer above abb_ros2? (2) What should a URML capability manifest declare to describe an ABB-class industrial arm honestly — reach/DOF, payload, joint/speed limits, end-effector + graspable classes, cell bounds?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0434-abb-ros2-outreach.md
Thanks for keeping a clean ROS 2 ABB driver alive; it is the natural home for this discussion.
Ido Yahalomi (URML, greenvh@gmail.com)
AI-assisted prose, maintainer-reviewed before posting (see VIBE.md). Human-only correspondence available on request.
Hi abb_ros2 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. ABB is one of the largest industrial-robot makers, and a permissively-licensed ROS 2 driver for its arms is a strong home for validated manipulation intent.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.
URML's ROS 2 runtime meets abb_ros2 on its ROS 2 action/service surface (and the ros2_control controllers); a "pick the part from bin A and place it in fixture B" becomes a typed primitive (pick_from / place_at / grasp), validated against the declared reach, payload, and end-effector, and only then dispatched. Validate-before-actuate refuses an out-of-reach pose, an undeclared object class, or a payload over the declared limit before the arm moves.
Two real questions: (1) Is URML's ROS 2 action-surface mapping the right seam for an external validated-intent layer above abb_ros2? (2) What should a URML capability manifest declare to describe an ABB-class industrial arm honestly — reach/DOF, payload, joint/speed limits, end-effector + graspable classes, cell bounds?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0434-abb-ros2-outreach.md
Thanks for keeping a clean ROS 2 ABB driver alive; it is the natural home for this discussion.
Ido Yahalomi (URML, greenvh@gmail.com)
AI-assisted prose, maintainer-reviewed before posting (see VIBE.md). Human-only correspondence available on request.