Expose quantities related to generic frames similarly to those of link frames

[diegoferigo]

The rod parser used under the hood, being primarily based on SDF, supports the definition of frames. Furthermore, our parsing logic automatically detects kinematic chains (link)->(fixed joint)->(dummy link with zero mass) that are often used to implement frames in URDF, and creates out of it an actual frame.

Computing quantities of a frame that is not a link frame is a common operation for model-based control. We should develop a new jaxsim.api.frame module providing at least the following functionality:

• Map name <--> index of a frame. We can either start with a 0-index like for links, or adopt an indexing similar to iDynTree in which the first frame index is number_of_links.
• Computation of the frame transform ${}^W \mathbf{H}_F \in \text{SE}(3)$.
• Computation of the frame Jacobian ${}^F J_{W, L} \in \mathbb{R}^{6 \times (6+n)}$ (this is the body-fixed version, we might also need the other representations) assuming $F$ is rigidly attached to $L$.

We should be able to provide all these quantities by just manipulating what our RBDAs already provide. The only necessary quantity to compute is the link-to-frame transform ${}^L \mathbf{H}_F$ that can be gathered after #137.

[diegoferigo]

cc @xela-95

[diegoferigo]

First off, JaxSim currently considers frames the following:

• All the <frame> elements specified in the SDF.
• The frames of the links that have been removed during model loading because connected with fixed joints.
• The frames of the links that have been removed in the model reduction process due to link lumping.

Considering that links are numbered from $0$ to $n_L - 1$, where $n_L$ is the number of links, the two options for frames are the following:

1. Consider extra frames attached to the model as different entities than links, and indexed from $0$ to $n_F - 1$, where $n_F$ is the number of frames.
2. Consider frames a generalization of a link, similarly to iDynTree, and indexed from $n_L$ to $n_L + n_F - 1$. In this case, we can also consider to allow e.g. calling the future jaxsim.api.frame.transform with a link index and get a link transform.

While frames are not yet exposed to jaxsim.api, they are part of the KinematicGraph and their index follows the second option. From a JaxSim model, they can be inspected accessing model.description.get().frames.

Tagging @traversaro for a quick feedback on the indexing of frames. Do you think that using a numbering compatible with iDynTree has relevant advantages in the JaxSim case?

[traversaro]

An indexing similar to iDynTree is useful so users have a consistent API for all methods and they do not need to worry if they need to provide a Link index or an additional frame index

[diegoferigo]

An indexing similar to iDynTree is useful so users have a consistent API for all methods and they do not need to worry if they need to provide a Link index or an additional frame index

Ok agreed, this option seems to me also easier to implement.

[xela-95]

@diegoferigo could you assign the issue to me? :)