Hi OpenVDB 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. On the robotics side, an OpenVDB grid is a memory-efficient occupancy / distance-field map -- and URML consumes an occupancy representation as the world its safety envelope is checked against.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.
The mapping: URML's safety envelope declares occupancy and geofence constraints; an OpenVDB grid is exactly the kind of map those constraints can be checked against. URML consumes the volume as the declared world; OpenVDB is the volumetric data structure.
Two real questions: (1) is "an OpenVDB grid is the declared occupancy a URML deployment validates intent against" a sensible consumer relationship for the robotics use of OpenVDB? (2) Is there a clean way a robot deployment would reference a VDB occupancy / distance field from a URML safety envelope -- and is robotics-occupancy the right framing for OpenVDB's audience (vs VFX)?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0523-openvdb-outreach.md
Thanks for OpenVDB; the sparse-volume structure is increasingly the occupancy map robots reason 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 OpenVDB 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. On the robotics side, an OpenVDB grid is a memory-efficient occupancy / distance-field map -- and URML consumes an occupancy representation as the world its safety envelope is checked against.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.
The mapping: URML's safety envelope declares occupancy and geofence constraints; an OpenVDB grid is exactly the kind of map those constraints can be checked against. URML consumes the volume as the declared world; OpenVDB is the volumetric data structure.
Two real questions: (1) is "an OpenVDB grid is the declared occupancy a URML deployment validates intent against" a sensible consumer relationship for the robotics use of OpenVDB? (2) Is there a clean way a robot deployment would reference a VDB occupancy / distance field from a URML safety envelope -- and is robotics-occupancy the right framing for OpenVDB's audience (vs VFX)?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0523-openvdb-outreach.md
Thanks for OpenVDB; the sparse-volume structure is increasingly the occupancy map robots reason 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.