[Core] Next classes to implement

[traversaro]

It would be desirable to have semantics aware classes for covering all the algorithms implemented in iDynTree, I will list some of them to keep track.

For integration work with @DiegoRomeres and @occam , we need to expose at least a subset of this classes, that I marked in the list with [priority] .

(cc @DanielePucci All the iDynTree::?? still needs a proper name.)

At the raw (coordinates) level we will need:

• iDynTree::SpatialMotionRaw [priority]
• iDynTree::SpatialForceRaw [priority]
• iDynTree::SpatialMotionToForceDyadicRaw
• iDynTree::JntPositionRaw [priority]
• iDynTree::JntMotionRaw [priority]
• iDynTree::JntForceRaw
• iDynTree::JntMotionToForceDyadicRaw
• iDynTree::?? Free floating robot configuration
• iDynTree::?? Free floating robot Motion
• iDynTree::?? Free floating robot force
• iDynTree::?? Free floating robot Motion to force dyadic

[traversaro]

To wrap up: we have three configuration spaces:

• SE3
• robot joint configurations (i.e. fixed base robot configurations)
• "free floating robot configurations.

For each one of this configuration spaces, we need classes to represent the:

• configuration space (i.e. positions)
• tangent space (i.e. velocities and its derivatives)
• dual of the tangent space (momentum, wrenches/forces and their derivatives)
• dyadics between the tangent space and its dual (tangent --> dual inertia/mass matrices, dual --> tangent inverse mass matrices).

To avoid a combinatorial explosion, it could make sense to include derivatives information (i.e. if a spatial motion vector is a twist, acceleration twist, jerk twist) directly in the semantics.

[traversaro]

I like the idea of including derivatives information in the semantics, but this could be confusing because the user could realistically expect to have different classes for different concepts, even if they share the same geometry, like iDynTree::Wrench and iDynTree::SpatialMomentum. This is useful to have also some semantics check at compile time, instead of runtime. Using template metaprogramming this would reduce to a simple typedef, but I guess we can obtain a similar result by having classes like iDynTree::Wrench and iDynTree::SpatialMomentum inherit from iDynTree::SpatialForce.

[traversaro]

Note that until we support complex joint type (i.e. spherical) the configuration space, tangent space and dual space have the same R^n geometry, so we can just start with a iDynTree::JntArrayRaw, similary to the KDL::JntArray class.

[traversaro]

We choose a different direction to implement those classes, closing.