Hi kr_autonomous_flight 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. URML ships an aerial drive type and a ROS 2 runtime, and your GPS-denied autonomous-flight stack from the Kumar Lab is one of the most credible in aerial autonomy — the kind of platform a validated intent layer should compose with. (For clarity: the repo is under the lab's academic-use software license; URML proposes nothing under it and asks for no license change — this is purely a mapping discussion.)
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.
URML's ROS 2 runtime meets the stack on its ROS surface; "fly to this position through the building and report" lowers onto its planning/control layer. The stack's strength is GPS-denied state estimation, and URML consumes that estimate rather than reimplementing it (the same posture URML takes toward SLAM). Validate-before-actuate refuses an out-of-envelope request before the drone acts, which matters in cluttered indoor flight.
Two real questions: (1) Is the ROS surface the right seam for an external validated-intent layer above a GPS-denied autonomy stack? (2) What should a URML capability manifest declare to describe such a platform honestly — drive type, altitude/speed limits, positioning source, operating volume?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0419-kr-autonomous-flight-outreach.md
Thanks for kr_autonomous_flight; the lab's GPS-denied flight work is a real benchmark for the field.
Ido Yahalomi (URML, greenvh@gmail.com)
AI-assisted prose, maintainer-reviewed before posting (see VIBE.md). Human-only correspondence available on request.
Hi kr_autonomous_flight 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. URML ships an aerial drive type and a ROS 2 runtime, and your GPS-denied autonomous-flight stack from the Kumar Lab is one of the most credible in aerial autonomy — the kind of platform a validated intent layer should compose with. (For clarity: the repo is under the lab's academic-use software license; URML proposes nothing under it and asks for no license change — this is purely a mapping discussion.)
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.
URML's ROS 2 runtime meets the stack on its ROS surface; "fly to this position through the building and report" lowers onto its planning/control layer. The stack's strength is GPS-denied state estimation, and URML consumes that estimate rather than reimplementing it (the same posture URML takes toward SLAM). Validate-before-actuate refuses an out-of-envelope request before the drone acts, which matters in cluttered indoor flight.
Two real questions: (1) Is the ROS surface the right seam for an external validated-intent layer above a GPS-denied autonomy stack? (2) What should a URML capability manifest declare to describe such a platform honestly — drive type, altitude/speed limits, positioning source, operating volume?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0419-kr-autonomous-flight-outreach.md
Thanks for kr_autonomous_flight; the lab's GPS-denied flight work is a real benchmark for the field.
Ido Yahalomi (URML, greenvh@gmail.com)
AI-assisted prose, maintainer-reviewed before posting (see VIBE.md). Human-only correspondence available on request.