Hi NTNU ARL 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 lab's autonomy work — the unified autonomy stack here, plus the aerial_gym_simulator where policies are trained — is a natural place for a validated intent layer. I'm anchoring this on the autonomy stack and referencing the simulator rather than posting to each repo.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.
URML's ROS 2 runtime meets the unified autonomy stack on its ROS 2 surface; an "explore this volume and return" intent lowers onto the stack's planning/behavior layer. Where aerial_gym_simulator trains a policy, URML wraps the deployed controller in a validated envelope (the decide-then-do split applied to learning). Validate-before-actuate refuses an out-of-envelope request before the drone acts.
Two real questions: (1) Where is the cleanest seam — above the autonomy stack's behavior/planning layer, or wrapping a policy trained in aerial_gym_simulator? (2) What should a URML capability manifest declare to describe an exploration-class aerial robot honestly — drive type, altitude/speed limits, sensor suite, exploration bounds?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0418-ntnu-arl-outreach.md
Thanks for the autonomy stack and aerial_gym; the lab's aerial-exploration work is some of the most interesting in the area.
Ido Yahalomi (URML, greenvh@gmail.com)
AI-assisted prose, maintainer-reviewed before posting (see VIBE.md). Human-only correspondence available on request.
Hi NTNU ARL 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 lab's autonomy work — the unified autonomy stack here, plus the aerial_gym_simulator where policies are trained — is a natural place for a validated intent layer. I'm anchoring this on the autonomy stack and referencing the simulator rather than posting to each repo.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.
URML's ROS 2 runtime meets the unified autonomy stack on its ROS 2 surface; an "explore this volume and return" intent lowers onto the stack's planning/behavior layer. Where aerial_gym_simulator trains a policy, URML wraps the deployed controller in a validated envelope (the decide-then-do split applied to learning). Validate-before-actuate refuses an out-of-envelope request before the drone acts.
Two real questions: (1) Where is the cleanest seam — above the autonomy stack's behavior/planning layer, or wrapping a policy trained in aerial_gym_simulator? (2) What should a URML capability manifest declare to describe an exploration-class aerial robot honestly — drive type, altitude/speed limits, sensor suite, exploration bounds?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0418-ntnu-arl-outreach.md
Thanks for the autonomy stack and aerial_gym; the lab's aerial-exploration work is some of the most interesting in the area.
Ido Yahalomi (URML, greenvh@gmail.com)
AI-assisted prose, maintainer-reviewed before posting (see VIBE.md). Human-only correspondence available on request.