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.

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

Define base link of the floating base robot #67

Open
diegoferigo opened this issue Dec 12, 2017 · 7 comments
Open

Define base link of the floating base robot #67

diegoferigo opened this issue Dec 12, 2017 · 7 comments

Comments

@diegoferigo
Copy link
Member

diegoferigo commented Dec 12, 2017

Right now the toolbox uses as base link the default base link set into iDynTree::KinDynComputations, which is the first link read from the urdf.

It could be worth adding in the configuration of the toolbox an additional entry that defines the base link, with the default value of root_link.

This change should be trivial:

  • Add an additional option to WBToolbox.Configuration.m
  • Add an additional member to wbt::Configuration
  • Read in wbt::WBBlock the joint name as a string from the struct passed from Simulink
  • Update the Configuration block's mask

Blocked by robotology/idyntree#404.

@diegoferigo diegoferigo self-assigned this Dec 12, 2017
@diegoferigo
Copy link
Member Author

This might be accomplished by calling setFloatingBase().

cc @gabrielenava

@diegoferigo
Copy link
Member Author

diegoferigo commented Feb 9, 2019

@traversaro I am bit perplexed on the usage of setFloatingBase(). It allows to set the base on a link that belongs to either a full or reduced model. However, links are lumped when a reduced model is created, how would you expect to set the new base e.g. on the l_sole for iCub? @gabrielenava

@gabrielenava
Copy link
Collaborator

gabrielenava commented Feb 11, 2019

However, links are lumped when a reduced model is created, how would you expect to set the new base e.g. on the l_sole for iCub? @gabrielenava

Just to clarify: at the moment, my intention is to use two link frames, specifically the chest and neck frames, as floating base for the ironbot controller. Given that the change of base will involve link frames, I think it is not a big deal if in practice we cannot select as floating base the frames that are not associated with a specific link.

However, independently from my use case the problem highlighted in the comment seems an issue.

@traversaro
Copy link
Member

Right now the toolbox uses as base link the default base link set into iDynTree::KinDynComputations, which is the first link read from the urdf.

If anyone is reading this discussion, a clarification: the default base link is not the first link read from the URDF, but rather is the root node of the directed tree (or directed acyclic graph, see https://en.wikipedia.org/wiki/Tree_(graph_theory) ) induced by the URDF file. See https://github.com/robotology/idyntree/blob/v2.0.2/src/model_io/urdf/src/URDFDocument.cpp#L87 for the related code. @nunoguedelha @CarlottaSartore

@nunoguedelha
Copy link
Collaborator

However, independently from my use case the problem highlighted in the comment seems an issue.

@gabrielenava @diegoferigo , I don't know these aspects in detail... correct me if I'm wrong: when iDynTree lumps multiple links together, we lose the respective links frames, but the attached fake frames stay untouched?

@diegoferigo
Copy link
Member Author

I'm not 100% sure. The function called when reducing a model is createReducedModel. You can quickly test it with the icub model and check if the {r,l}_sole remain.

@traversaro
Copy link
Member

However, independently from my use case the problem highlighted in the comment seems an issue.

@gabrielenava @diegoferigo , I don't know these aspects in detail... correct me if I'm wrong: when iDynTree lumps multiple links together, we lose the respective links frames, but the attached fake frames stay untouched?

Yes, all the "URDF fake links" aka "iDynTree additional frames" are properly converted to be additional frames of the resulting lumped link, see https://github.com/robotology/idyntree/blob/84d216c14eb923fb2c54e86e46511565617f314c/src/model/src/ModelTransformers.cpp#L402 and https://github.com/robotology/idyntree/blob/84d216c14eb923fb2c54e86e46511565617f314c/src/model/src/ModelTransformers.cpp#L221 .

As of iDynTree 2 the main limitation (that can however been worked on, see the related issue) is that you can't specify additional frames as "base frames" of the multibody model, see robotology/idyntree#422 . This means that for example with a complete model you can specify the l_foot as base link, but you can't specify it anymore if you create a reduced model in which the parent joint of l_foot is not part of the consideredJoints .

fyi @GiulioRomualdi remember when you asked me why I had the feeling that re-using the URDF ModelLoader of iDynTree for iDynFor could be useful? This is one of the aspects for which re-using the URDF ModelLoader of iDynTree could make it is easier to provide a drop-in replacement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants