Hi Project 11 community,
URML (urml.dev) is a small, Apache-2.0 language for describing robot intent: an intent becomes a typed primitive, validated against the vehicle's declared capabilities and a safety envelope, then dispatched. Project 11 is a ROS backseat-driver framework for ASVs with mission and helm managers, and URML is interesting as the front door above the mission manager.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.
The mapping: a URML program declares an ASV survey / transit mission, validated against the vehicle's declared mobility and a safety envelope (operating area, depth band), then handed to Project 11's mission manager. Your backseat-driver architecture is exactly the clean boundary URML likes: URML produces the validated mission; the autopilot / helm executes it.
Two real questions: (1) does a URML ASV mission program (mobility + operating-area envelope) fit how Project 11's mission manager is driven? (2) Is a validated-intent front door above the mission manager interesting for survey ASVs -- and which is the cleaner first seam?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0531-project11-outreach.md
Thanks for Project 11; the backseat-driver boundary is the cleanest place a validated-mission layer plugs in.
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 Project 11 community,
URML (urml.dev) is a small, Apache-2.0 language for describing robot intent: an intent becomes a typed primitive, validated against the vehicle's declared capabilities and a safety envelope, then dispatched. Project 11 is a ROS backseat-driver framework for ASVs with mission and helm managers, and URML is interesting as the front door above the mission manager.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.
The mapping: a URML program declares an ASV survey / transit mission, validated against the vehicle's declared mobility and a safety envelope (operating area, depth band), then handed to Project 11's mission manager. Your backseat-driver architecture is exactly the clean boundary URML likes: URML produces the validated mission; the autopilot / helm executes it.
Two real questions: (1) does a URML ASV mission program (mobility + operating-area envelope) fit how Project 11's mission manager is driven? (2) Is a validated-intent front door above the mission manager interesting for survey ASVs -- and which is the cleaner first seam?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0531-project11-outreach.md
Thanks for Project 11; the backseat-driver boundary is the cleanest place a validated-mission layer plugs in.
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.