Define base link of the floating base robot

[diegoferigo]

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 https://github.com/robotology/idyntree/issues/404.

[diegoferigo]

This might be accomplished by calling setFloatingBase().

cc @gabrielenava

[diegoferigo]

@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]

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]

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]

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]

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]

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 https://github.com/robotology/idyntree/issues/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.