Hi Open-Source Leg maintainers,
URML (urml.dev) is a small, Apache-2.0 language for robot intent: a subtask becomes a typed primitive, validated against a device's declared capabilities and a safety envelope, and only then dispatched. opensourceleg already drives the prosthesis's actuators behind a clean API and knows its joint and torque limits. URML's candidate contribution is to lift those limits into a typed envelope that a subtask intent is validated against before the SDK is asked to drive the actuator. This is a request for comment, and given the LGPL-2.1 license it is a layering relationship, no shared code.
Nothing here asks the project to adopt, host, or maintain anything.
The seam: the SDK knows the leg's joint ranges and torque ceilings; URML turns those into a safety envelope that a gait or assist subtask is checked against statically, so an out-of-envelope command is refused before it reaches the actuator rather than caught (or not) at runtime. The SDK keeps the actuator and sensor handling; URML is the pre-dispatch gate. A prosthesis is coupled to a person, so a typed limit declaration plus a static check is concrete value, not decoration.
Two real questions: (1) is a static safety-envelope check useful above the device API, or does the SDK already refuse inadmissible commands? (2) Do the leg's declared limits map onto a capability manifest and safety envelope cleanly, or do prosthesis dynamics need something a manifest does not yet express? A single joint (knee or ankle) would be a natural first try.
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0619-opensourceleg-outreach.md
Thanks for opensourceleg; a widely used open prosthesis SDK is a good place to see whether a typed envelope check adds anything above the device API.
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 Open-Source Leg maintainers,
URML (urml.dev) is a small, Apache-2.0 language for robot intent: a subtask becomes a typed primitive, validated against a device's declared capabilities and a safety envelope, and only then dispatched. opensourceleg already drives the prosthesis's actuators behind a clean API and knows its joint and torque limits. URML's candidate contribution is to lift those limits into a typed envelope that a subtask intent is validated against before the SDK is asked to drive the actuator. This is a request for comment, and given the LGPL-2.1 license it is a layering relationship, no shared code.
Nothing here asks the project to adopt, host, or maintain anything.
The seam: the SDK knows the leg's joint ranges and torque ceilings; URML turns those into a safety envelope that a gait or assist subtask is checked against statically, so an out-of-envelope command is refused before it reaches the actuator rather than caught (or not) at runtime. The SDK keeps the actuator and sensor handling; URML is the pre-dispatch gate. A prosthesis is coupled to a person, so a typed limit declaration plus a static check is concrete value, not decoration.
Two real questions: (1) is a static safety-envelope check useful above the device API, or does the SDK already refuse inadmissible commands? (2) Do the leg's declared limits map onto a capability manifest and safety envelope cleanly, or do prosthesis dynamics need something a manifest does not yet express? A single joint (knee or ankle) would be a natural first try.
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0619-opensourceleg-outreach.md
Thanks for opensourceleg; a widely used open prosthesis SDK is a good place to see whether a typed envelope check adds anything above the device API.
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.