Hi Open3D 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 3D geometry, it does not process point clouds -- and Open3D's point clouds, meshes, and reconstructions 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: Open3D's products (point clouds / meshes / reconstructions) are the geometry a URML deployment declares its occupancy and geofence constraints against, and its frames against. URML consumes that geometry as input; it does not do the processing.
Two real questions: (1) is "Open3D produces the 3D geometry, URML declares intent / constraints against it" a sensible consumer relationship? (2) Is there a clean product (an occupancy grid, a mesh, scene bounds) 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/0520-open3d-outreach.md
Thanks for Open3D; it is the 3D-processing layer a declared-world robot intent sits on top of.
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 Open3D 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 3D geometry, it does not process point clouds -- and Open3D's point clouds, meshes, and reconstructions 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: Open3D's products (point clouds / meshes / reconstructions) are the geometry a URML deployment declares its occupancy and geofence constraints against, and its frames against. URML consumes that geometry as input; it does not do the processing.
Two real questions: (1) is "Open3D produces the 3D geometry, URML declares intent / constraints against it" a sensible consumer relationship? (2) Is there a clean product (an occupancy grid, a mesh, scene bounds) 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/0520-open3d-outreach.md
Thanks for Open3D; it is the 3D-processing layer a declared-world robot intent sits on top of.
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.