Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
diegoferigo opened this issue May 2, 2024 · 5 comments · Fixed by #148
Closed

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

diegoferigo opened this issue May 2, 2024 · 5 comments · Fixed by #148
Assignees
@xela-95

Comments

@diegoferigo
Copy link
Member

diegoferigo commented May 2, 2024 •
edited

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
Copy link
Member Author

cc @xela-95

@diegoferigo
Copy link
Member Author

diegoferigo commented May 3, 2024 •
edited

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
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Member

xela-95 commented May 7, 2024

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

@xela-95 xela-95 mentioned this issue May 7, 2024
Merged
@diegoferigo diegoferigo mentioned this issue May 22, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@xela-95 xela-95

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Expose quantities related to generic frames xela-95/jaxsim
3 participants
@diegoferigo @traversaro @xela-95