Add visualizers (Robot Visualizer) and sensors libraries (IMUsensor)

[nunoguedelha]

Implements #39 .
Implements #40 .

[traversaro]

Comment on the formulas implemented for IMU and accelerometer simulations.

[traversaro]

This is missing a rotation ${}^S R_A$, where $S$ is sensor frame and $A$ is the world/absolute frame. See equation 4.3 in https://traversaro.github.io/traversaro-phd-thesis/traversaro-phd-thesis.pdf .

[nunoguedelha]

yes Silvio, you're right. I was going to fix this later on after finishing robotology/whole-body-controllers#122, and after checking those sections in your thesis about the sensor acceleration, just to be sure I wouldn't miss anything. That's why I specified in the issue and block documentation that the quantities where expressed in the world frame. But you're right, better do be accurate right away.

[traversaro]

If you like to merge as it is for me it is ok, probably better to open an issue to eventually fix it, thanks1

[nunoguedelha]

I'll push here. Just quick question @traversaro . The WBT Jacobian block output is actually the jacobian expressed in a mixed frame right? B[A], i.e. the frame with origin of B and orientation of A, where B is the specified body frame and A the inertial frame. Such that J*nu gives:
$$
\begin{equation}
{}^{F _i[A]}\mathrm{v} _{A,F _i} = {}^{F _i[A]}R _{F _i} J _i \nu
\end{equation}
$$

Where $A$ is the inertial frame and $J_i$ is the Jacobian of body frame $F_i$ expressed in body coordinates as described in Featherstone RBDA textbook.

[nunoguedelha]

It should be the case, as in KinDynComputations.cpp, m_frameVelRepr is set to MIXED_REPRESENTATION.

Running the following in MATLAB command line getFrameVelocityRepresentation():

>> kinDyn = iDynTree.KinDynComputations()
>> kinDyn.getFrameVelocityRepresentation
ans =
  int64
   2

returns the default value: 2 => MIXED_REPRESENTATION. We get the same value while running RobotVisualizer.prepareRobot() which loads the robot model and prepares the robot visualization through the iDynTree bindings. Assuming that the Frame Velocity Representation is not explicitely changed later on through KinDynComputations::setFrameVelocityRepresentation method, we can assume that the Jacobian WBT block uses that type of representation. I've opened an issue to cross check that: #42 .

[traversaro]

I'll push here. Just quick question @traversaro . The WBT Jacobian block output is actually the jacobian expressed in a mixed frame right? B[A], i.e. the frame with origin of B and orientation of A, where B is the specified body frame and A the inertial frame. Such that J*nu gives:
$$
\begin{equation}
{}^{F _i[A]}\mathrm{v} _{A,F _i} = {}^{F _i[A]}R _{F _i} J _i \nu
\end{equation}
$$

Where $A$ is the inertial frame and $J_i$ is the Jacobian of body frame $F_i$ expressed in body coordinates as described in Featherstone RBDA textbook.

In this formula, what is ${}^{F _i[A]}R _{F _i}$ ? Anyway, for iDynTree convention that formula is incomplete because if you pass from the mixed jacobian to the body-fixed jacobian, also the convention used by floating base velocity in the $\nu$ vector changes, so you need to also account for that. See equation 3.70 of https://traversaro.github.io/traversaro-phd-thesis/traversaro-phd-thesis.pdf for the correct formula.

In any case, yes all WB-Toolbox bocks use MIXED_REPRESENTATION and i do not think there is any way to change it, so it is safe to assume that the jacobian is the mixed one according to iDynTree convention.

[nunoguedelha]

sorry, I meant actually ${}^{F _i[A]}X _{F _i}$ instead of $R$. And the Jacobian was already left trivialized. Nevertheless I shouldn't mention Featherstone as he addresses the fixed base casein the sections I was thinking about. Anyway, it's much clearer now for me, after reading again the respective section in your thesis. Thanks!

[nunoguedelha]

All fixes done.

[nunoguedelha]

For some reason, the GRAVITY_VECTOR parameter had disappeared from the IMUsensorProc() MATLAB System mask config. Restored it. merging now.

[nunoguedelha]

@traversaro , side note: I forgot to merge this into devel. Submitting a PR in a few minutes, which will be followed by a fast-forward merge into devel.