Dummy root link requirement

[bchretien]

While trying to test metapod on a dummy URDF model that I use for my unit tests, I was surprised by the disappearance of the root link. I know that several URDF models use a dummy link for the free-flyer (base_link for HRP-2, NP for metapod's examples etc.), e.g.:

  <link name="NP"/>

However, this does not seem to be part of the standard, and my test model has a "real" root link (with a mass, an inertia etc.). I have used it with ROS and I haven't had any problem so far. Is this "dummy root link" a known requirement of metapod? (possibly related to #65) If it is, it may be good to add this information somewhere in the README.md since some URDF models may not comply (e.g. non REP 120 models). Else, please enlighten me :-)

Note: I noticed a similar problem when checking rbdl's URDF loader.

[olivier-stasse]

Dear Benjamin, Yes you are right the dummy link is mandatory because it would allow to describe a multi-robot structure. Thanks for noticing us that it is not in the README.md. I'll fix that.

[sbarthelemy]

Hello Benjamin,

I maintain a fork of metapod we use at Aldebaran, I'm currently working on a major refactoring aimed at bringing support for coupled joints.

In the process I have fixed issue #65, but have not submitted a merge request yet (properly testing with jrl-cmake boost versions and so is lengthy, I'm planning to test the whole branch in a single shot).

A preview of this work is there https://github.com/sbarthelemy/metapod/tree/sbarth_coupled0

These two commits more specifically. https://github.com/sbarthelemy/metapod/commit/b4e54547f187e10b9a121b22a0e681e884a3017e https://github.com/sbarthelemy/metapod/commit/de5329618007f44291b7c6373b731a1a8349b484

[olivier-stasse]

Hi Sebastien, BTW I have been rereading the book of Featherstone on this point, and the way it is handle is through a constraint on the dynamical system. Is this the way you are treating it ?

[bchretien]

@olivier-stasse: thanks for the information. I also noticed that the Wiki's Quick start example is out-of-date. This may be worth updating for new users (in the meantime they can take a look at the test suite).

@sbarthelemy: duly noted. In regard to free-flyer parametrization, I have some unusual requirements that may differ from what the usual metapod users do though. My free-flyer link varies during the simulation depending on active contacts (e.g. compute the kinematics from the left_foot with the given transformation frame), and the base_link is just there to comply with other libraries. Since I will only use metapod for testing, I can make the tests "base-link-centered", but is it currently possible to change the root link when computing forward kinematics and/or inverse dynamics?

[sbarthelemy]

In regard to free-flyer parametrization, I have some unusual requirements that may differ from what the usual metapod users do though. My free-flyer link varies during the simulation depending on active contacts (e.g. compute the kinematics from the left_foot with the given transformation frame), and the base_link is just there to comply with other libraries. Since I will only use metapod for testing, I can make the tests "base-link-centered", but is it currently possible to change the root link when computing forward kinematics and/or inverse dynamics?

No, it not possible to change the root link at run time.

You could use two models, both without a free-flyer: one with the left foot fixed the other with the right foot fixed. Metapod is quite flexible regarding how you organize your configuration vector, which might help you a bit. But still, that looks cumbersome and error-prone.

What we do here is that the root joint is a free-flyer from the ground to the torso, where limbs starts. We have a variant of the metapod bcalc algorithm which, instead of computing the pose of the bodies in the ground frame, does so in the torso frame (so it "skips" the root free-flyer). These poses can then be used to find out (and set) the free-flyer configuration.