-
Notifications
You must be signed in to change notification settings - Fork 16
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
Comments
This might be accomplished by calling setFloatingBase(). |
@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 |
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. |
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 |
@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? |
I'm not 100% sure. The function called when reducing a model is |
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 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. |
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:
WBToolbox.Configuration.m
wbt::Configuration
wbt::WBBlock
the joint name as a string from the struct passed from SimulinkBlocked by robotology/idyntree#404.
The text was updated successfully, but these errors were encountered: