Hi CORC maintainers,
URML (urml.dev) is a small, Apache-2.0 language for robot intent: a subtask becomes a typed primitive, validated against the device's declared capabilities and a safety envelope, and only then dispatched. CORC is the layer that turns a controller's decision into real CANopen position and torque commands on an exoskeleton or rehab robot, which is exactly the handoff a pre-dispatch check is most worth running. This is a request for comment.
Nothing here asks the project to adopt, host, or maintain anything.
The seam: on a device coupled to a person, the safety envelope is the whole point. A subtask (move this joint to this position, never exceeding this torque, within these limits) is a goal plus hard constraints. URML's candidate role is to state that envelope once, in a capability manifest, and validate every subtask intent against it in five passes (argument typing, capability, safety envelope, bindings, policy) before the intent reaches CORC's CANopen loop. CORC keeps the real-time control; URML is the static check that runs before the loop is handed an intent.
Two real questions: (1) is a typed, statically-validated intent layer useful above a CANopen control stack like this, or does your control layer already carry that admissibility reasoning? (2) Do a device's per-joint torque ceilings and position ranges map onto a capability manifest and safety envelope cleanly, for something like the X2 or the ArmMotus arms?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0618-corc-exoskeleton-outreach.md
Thanks for CORC; an open CANopen control stack for exo and rehab hardware is exactly where a checked envelope before actuation earns its keep.
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 CORC maintainers,
URML (urml.dev) is a small, Apache-2.0 language for robot intent: a subtask becomes a typed primitive, validated against the device's declared capabilities and a safety envelope, and only then dispatched. CORC is the layer that turns a controller's decision into real CANopen position and torque commands on an exoskeleton or rehab robot, which is exactly the handoff a pre-dispatch check is most worth running. This is a request for comment.
Nothing here asks the project to adopt, host, or maintain anything.
The seam: on a device coupled to a person, the safety envelope is the whole point. A subtask (move this joint to this position, never exceeding this torque, within these limits) is a goal plus hard constraints. URML's candidate role is to state that envelope once, in a capability manifest, and validate every subtask intent against it in five passes (argument typing, capability, safety envelope, bindings, policy) before the intent reaches CORC's CANopen loop. CORC keeps the real-time control; URML is the static check that runs before the loop is handed an intent.
Two real questions: (1) is a typed, statically-validated intent layer useful above a CANopen control stack like this, or does your control layer already carry that admissibility reasoning? (2) Do a device's per-joint torque ceilings and position ranges map onto a capability manifest and safety envelope cleanly, for something like the X2 or the ArmMotus arms?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0618-corc-exoskeleton-outreach.md
Thanks for CORC; an open CANopen control stack for exo and rehab hardware is exactly where a checked envelope before actuation earns its keep.
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.