Hi LibEMG maintainers,
URML (urml.dev) is a small, Apache-2.0 language for robot intent: a recognized intent becomes a typed primitive, validated against a device's declared capabilities and a safety envelope, then dispatched. LibEMG takes EMG signals all the way to an online control decision, and URML is a natural consumer of that output. This is a research-scope note, with no clinical claim, matching your own posture.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.
The boundary: LibEMG turns muscle activity into a control decision; URML's role is what happens next. Take that decoded intent, validate the resulting action against the assistive device's declared capabilities and an operating envelope, then dispatch. For an assistive device, the "is this action admissible for this device right now" check is exactly where a typed validation layer earns its place, and URML stays entirely out of the decoding. URML does not classify EMG; it consumes the recognized intent.
Two real questions: (1) is a typed, validated action layer downstream of a decoded EMG intent (the action checked against the device's capabilities + envelope, then dispatched) useful for assistive-device research? (2) Does a decoded LibEMG control decision map cleanly onto a recognized-intent input to such a layer?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0607-libemg-outreach.md
Thanks for LibEMG; making myoelectric control accessible and reproducible is real work, and the action-validation step downstream of the decoder seemed worth asking you about.
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 LibEMG maintainers,
URML (urml.dev) is a small, Apache-2.0 language for robot intent: a recognized intent becomes a typed primitive, validated against a device's declared capabilities and a safety envelope, then dispatched. LibEMG takes EMG signals all the way to an online control decision, and URML is a natural consumer of that output. This is a research-scope note, with no clinical claim, matching your own posture.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.
The boundary: LibEMG turns muscle activity into a control decision; URML's role is what happens next. Take that decoded intent, validate the resulting action against the assistive device's declared capabilities and an operating envelope, then dispatch. For an assistive device, the "is this action admissible for this device right now" check is exactly where a typed validation layer earns its place, and URML stays entirely out of the decoding. URML does not classify EMG; it consumes the recognized intent.
Two real questions: (1) is a typed, validated action layer downstream of a decoded EMG intent (the action checked against the device's capabilities + envelope, then dispatched) useful for assistive-device research? (2) Does a decoded LibEMG control decision map cleanly onto a recognized-intent input to such a layer?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0607-libemg-outreach.md
Thanks for LibEMG; making myoelectric control accessible and reproducible is real work, and the action-validation step downstream of the decoder seemed worth asking you about.
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.