Hi PCL 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. URML consumes processed geometry, it does not do the point-cloud math -- and PCL's segmented, registered point clouds are exactly the geometry a robot's intent is validated against.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.
The mapping: PCL turns raw sensor returns into segmented, registered geometry. A URML deployment declares its occupancy / geofence constraints and its frames against that geometry. URML consumes the processed result as input; the heavy point-cloud math stays in PCL.
Two real questions: (1) is "PCL processes the point cloud, URML declares intent / constraints against the result" a sensible consumer relationship? (2) Is there a clean product (segmented obstacles, an occupancy proxy) a robot deployment would feed a URML manifest / envelope -- and which is the cleaner first seam?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0521-pcl-outreach.md
Thanks for PCL; it is the canonical point-cloud layer beneath the declared world a robot reasons about.
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 PCL 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. URML consumes processed geometry, it does not do the point-cloud math -- and PCL's segmented, registered point clouds are exactly the geometry a robot's intent is validated against.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.
The mapping: PCL turns raw sensor returns into segmented, registered geometry. A URML deployment declares its occupancy / geofence constraints and its frames against that geometry. URML consumes the processed result as input; the heavy point-cloud math stays in PCL.
Two real questions: (1) is "PCL processes the point cloud, URML declares intent / constraints against the result" a sensible consumer relationship? (2) Is there a clean product (segmented obstacles, an occupancy proxy) a robot deployment would feed a URML manifest / envelope -- and which is the cleaner first seam?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0521-pcl-outreach.md
Thanks for PCL; it is the canonical point-cloud layer beneath the declared world a robot reasons about.
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.