URML (open robot intent language): where validated actuation meets the EtherCAT master (request for comment)

[idoco2003]

Hi KickCAT community,

URML (urml.dev) is a small, Apache-2.0 language for describing robot intent: an intent becomes a typed primitive, validated against the robot's declared capabilities and a safety envelope, then dispatched. EtherCAT is the fieldbus beneath the actuation layer in many industrial and legged systems, and KickCAT is an open master/slave stack for it. I wanted to describe how URML layers above that and ask whether it is the right altitude.

Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.

The layering: URML's actuation primitives are validated statically (pre-dispatch); the realized motion reaches the servo drives over EtherCAT, where KickCAT is the master doing the cyclic exchange. URML is the typed, pre-dispatch-validated intent; KickCAT is the deterministic transport to the drives. This mirrors URML's existing ros2_control hardware-abstraction mapping, one layer lower. (KickCAT is CeCILL-C; this proposes no code reuse, only a layering description.)

Two real questions: (1) is "URML validates actuation intent above, KickCAT carries it to the drives over EtherCAT" an accurate description? (2) Is a fieldbus master the right altitude to engage, or is the integrator / ros2_control layer the better seam?

Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0507-kickcat-outreach.md

Thanks for KickCAT; an open EtherCAT master is a clean reference point for where the validated-intent layer ends and the deterministic bus begins.

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.

[leducp]

Hi @idoco2003

Nice project!

About the layering: EtherCAT rely usually on the DS402 standard to communicate with a motor. This helps a lot for a drive motion but a few caveats:

• units are not SI but drive dependent
• you'll need to handle the state machine (KickCAT provide the tools to do so but keep in mind that this is already on top of the raw EtherCAT)
  To be noted also: if your drive handle the position mode you can play a trajectory in open-loop to a certain extent, however if you want more complex control, you'll build it on top of the torque mode which requires to close the loop!

The other part of a robot are the sensors and in this field, I do not know standard way to talk to them.

My usual approach is to write a HAL that sequence the EtherCAT bus and do the translation between the hardware and what you want to declare as "standard" in the ecosystem. You may even need to fuse a bit of data (an IMU is a construction on top of accelerometers and gyroscopes for instance).

TL;DR
(1) I would add a control/HAL layer, something like that:
"URML validates actuation intent above, a controller play it and KickCAT carries it to the drives over EtherCAT"
(2) integrator / ros2_control it is from my POV. You' ll need a controller tha tsit between the intent to close the lop with the hardware, you may even need a safety process to do a bit of functional safety.

Hope that theses insights can help you!

[idoco2003]

This is genuinely helpful, thank you, and it matches where I landed from another EtherCAT thread.

Your layering is exactly the line I would use:
URML validates the actuation intent above, a controller plays it, and KickCAT carries it to the drives over EtherCAT.

URML stays above the controller.
It never touches the DS402 state machine, the drive dependent units, or the choice between position and torque mode.
Those live in the HAL and the controller, which is where ros2_control sits, exactly as you said.

A separate EtherCAT thread pushed me to model the cyclic and acyclic operation modes in the manifest, which shipped, so the validator now reasons about PDO timing versus the SDO mailbox without pretending to own the bus.
Your points about units not being SI and needing torque mode to close the loop belong in that controller and HAL layer, not in URML. You drew the line cleanly.

Really appreciate the detail.