Start implementing changeRootJoint

[jcarpent]

No description provided.

[jcarpent]

Related to #1308.

[jcarpent]

In this PR, it is still needed to inverse the joint placements, change the inertias and the frame placements according to the new root joint.

[Gregwar]

One note about that (not sure if it is relevant): the degrees of freedom on the chain from (old root) to (new root) should be "backward" if you want that the same q state vector to produce the same configuration

[jcarpent]

One note about that (not sure if it is relevant): the degrees of freedom on the chain from (old root) to (new root) should be "backward" if you want that the same q state vector to produce the same configuration

Yes this is precisely the content of my previous comment and what I have started to implement. Did you check the code?

[jmirabel]

One note about that (not sure if it is relevant): the degrees of freedom on the chain from (old root) to (new root) should be "backward" if you want that the same q state vector to produce the same configuration

Yes this is precisely the content of my previous comment and what I have started to implement. Did you check the code?

isn't this breaking compactness on which some algorithms rely ?

[jcarpent]

Normally not.

[jmirabel]

I am not sure to understand how it is possible to have the same configuration order for the original model and the re-rooted model, while keeping the fact that all the child joints of a joint A corresponds to the n DoFs following the parameter of joint A...

Anyway, I think this is a useful feature. Thanks for implementing it.

[jcarpent]

No, the configuration order will change. This is the role of the user to provide the correct configuration.
For all the basic joints except the FreeFlyer, SphericalZYX and Composite this is possible.

[Gregwar]

The fact that the configuration order will change should indeed be specified on the documentation, a common thing the user will want is to write some code to remap the values of its model data from the original model to the re-rooted one. My comment above is that the values themselves could be compatible (which I guess is what @jcarpent also wants).

Thanks as well for implementing this.

[jcarpent]

@Gregwar It would be nice if you can provide some help on this feature. For instance, the remaping function for joints configuration, so far an so on.

[Gregwar]

I am not sure what is your philosophy here: do you want the values of the joints to be compatible with the re-rooted robot or not?

As a simple example; will a revolute joint axis that is on the re-root support in the tree have its orientation inverted (newAxis=-axis) or not?