search

robotology / wb-toolbox

Simulink toolbox to rapidly prototype robot controllers
https://robotology.github.io/wb-toolbox/
GNU Lesser General Public License v2.1
23 stars 16 forks source link

Define base link of the floating base robot #67

Open diegoferigo opened 6 years ago

diegoferigo commented 6 years ago

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:

Blocked by https://github.com/robotology/idyntree/issues/404.

diegoferigo commented 5 years ago

This might be accomplished by calling setFloatingBase().

cc @gabrielenava

diegoferigo commented 5 years ago

@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 commented 5 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.