URML (open robot intent language): a validated target as a PlaCo task set, request for comment

[idoco2003]

Hi PlaCo maintainers,

URML (urml.dev) is a small, Apache-2.0 language for describing robot intent: English sentence -> typed primitive -> static validation against a capability manifest and a safety envelope -> dispatch. URML declares a target and capability; it does not solve kinematics. PlaCo solves whole-body kinematics and control as a QP over tasks and constraints, which is exactly the kind of solver URML would hand a validated target to, with a whole-body emphasis the single-arm IK solvers do not cover.

Nothing here asks PlaCo to change or maintain anything. This is a request for comment.

Two real questions. First, what is the cleanest way for URML to express a target as a PlaCo task and constraint set, so URML stays the intent layer and PlaCo stays the solver? Second, for the whole-body case (a mobile base plus an arm, or a humanoid), how should URML's capability declaration carry the structure PlaCo needs without restating the model? For context, Pink and mink are the single-arm differential-IK siblings I am reaching in parallel.

Full write-up, with the manifest mapping table: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0361-placo-outreach.md

Thanks for PlaCo; an approachable whole-body QP library lowers a real barrier.

Ido Yahalomi (URML, greenvh@gmail.com)

AI-assisted prose, maintainer-reviewed before posting (see VIBE.md). Human-only correspondence available on request.

[Gregwar]

First, what is the cleanest way for URML to express a target as a PlaCo task and constraint set, so URML stays the intent layer and PlaCo stays the solver?

PlaCo has two API, C++ and Python, which are really similar

The API is expressed in the documentation with extensive examples

• Kinematics: https://placo.readthedocs.io/en/latest/kinematics/index.html
• Dynamics: https://placo.readthedocs.io/en/latest/dynamics/index.html

Please note that, in your project, you might want or not want to call "clear" to clear the list of tasks used. Re-creating all tasks at each step have an overhead that is not well benchmarked (involving re-allocating memory) that can be avoided by simply updating tasks data, just like in all example provided in galleries

There are many examples in the following repo:
https://github.com/rhoban/placo-examples

Second, for the whole-body case (a mobile base plus an arm, or a humanoid), how should URML's capability declaration carry the structure PlaCo needs without restating the model? For context, Pink and mink are the single-arm differential-IK siblings I am reaching in parallel.

Can you elaborate on what you mean by "restating" ?
As explained, PlaCo doesn't need you to re-load the model, neither it requires to re-create the tasks. You can simply update the tasks data.

In the following example: https://github.com/Rhoban/placo-examples/blob/master/kinematics/6axis_trajectory.py#L36

The loop simply update the effector_task data and call solve again, you don't have (and don't want) to re-allocate memory or re-create model/solver/tasks at each step

[idoco2003]

Thanks @Gregwar, this is exactly what I needed. The update-the-task-data-instead-of-clearing point is well taken: I'll follow the 6axis_trajectory pattern (update effector_task, then re-solve) rather than rebuilding tasks each step.

On "restating": I meant the kinematic model itself, the URDF / links / joints PlaCo already loads. URML's capability manifest stays deliberately abstract (it declares things like arm count, reachable workspace, drive type) and does not re-describe the robot's structure, since that is PlaCo's to own. So the boundary I am aiming for is: URML carries the abstract capability plus the validated target, and PlaCo holds the model and the task / constraint set and solves. Your point that PlaCo updates task data on an already-loaded model actually confirms that split. Does that match how you would draw the line?