Hi LSTS maintainers,
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. The LSTS toolchain is a mature non-ROS stack for networked unmanned vehicles -- DUNE the onboard runtime, Neptus the fleet command-and-control. URML is interesting in two ways here.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment. (DUNE and Neptus are under a modified EUPL-1.1 with a non-commercial restriction; this proposes no code reuse, only a mapping / consumer relationship.)
The mapping, two seams: (1) DUNE is an onboard runtime in the same role URML's reference runtimes play -- the thing that executes a validated plan on a vehicle; URML validates intent against the vehicle's capabilities and a safety envelope, then dispatches to DUNE (URML stays substrate-neutral, DUNE is one substrate). (2) Neptus commands and monitors a fleet of networked vehicles; URML's fleet roster and cross-vehicle deconfliction are the static-validation complement -- declare the fleet and its constraints, validate the multi-vehicle intent, then drive it through Neptus.
Two real questions: (1) is DUNE a sensible non-ROS substrate for URML-validated intent to dispatch to? (2) Does URML's fleet roster + deconfliction complement Neptus's fleet C2, and which is the cleaner first seam -- DUNE (substrate) or Neptus (fleet)?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0546-lsts-outreach.md
Thanks for DUNE and Neptus; a real networked-UV stack with both an onboard runtime and fleet C2 is an unusually complete place to test substrate-neutral validated intent.
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 LSTS maintainers,
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. The LSTS toolchain is a mature non-ROS stack for networked unmanned vehicles -- DUNE the onboard runtime, Neptus the fleet command-and-control. URML is interesting in two ways here.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment. (DUNE and Neptus are under a modified EUPL-1.1 with a non-commercial restriction; this proposes no code reuse, only a mapping / consumer relationship.)
The mapping, two seams: (1) DUNE is an onboard runtime in the same role URML's reference runtimes play -- the thing that executes a validated plan on a vehicle; URML validates intent against the vehicle's capabilities and a safety envelope, then dispatches to DUNE (URML stays substrate-neutral, DUNE is one substrate). (2) Neptus commands and monitors a fleet of networked vehicles; URML's fleet roster and cross-vehicle deconfliction are the static-validation complement -- declare the fleet and its constraints, validate the multi-vehicle intent, then drive it through Neptus.
Two real questions: (1) is DUNE a sensible non-ROS substrate for URML-validated intent to dispatch to? (2) Does URML's fleet roster + deconfliction complement Neptus's fleet C2, and which is the cleaner first seam -- DUNE (substrate) or Neptus (fleet)?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0546-lsts-outreach.md
Thanks for DUNE and Neptus; a real networked-UV stack with both an onboard runtime and fleet C2 is an unusually complete place to test substrate-neutral validated intent.
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.