Using quaternion instead of RPY

[gabrielebndn]

Currently, the free-flyer configuration is represented as position+RPY. This is the configuration returned by the device object, and it is also the configuration expected by sot-dynamic-pinocchio.

However, all of our computations are performed using quaternions. In particular, Pinocchio models typically employ quaternions. Passing around RPY values around often forces us to manually convert from RPY to quaternion and vice-versa. Indeed, this is what sot-dynamic-pinocchio itself is doing.

It would be more straightforward to directly pass quaternions around. This might be done even without breaking existing code, by adding redundant input/output signals to sot-dynamic-pinocchio/device

[olivier-stasse]

It sounds like a good idea with a big weigt wrt the software refactoring it will needs. To be honest, I have other priorities than that.

[jmirabel]

Duplicates #45

[gabrielebndn]

I believe we should really start considering this.
We have seen that the current handling has already caused bugs in #105.
Switching to quaternions would enable us to directly employ Pinocchio's methods, without complications related to conversions, special handling, and code duplication.

I believe that once stack-of-tasks/pinocchio#910 is merged the transition will be easier, as there will be automatic size checks in place even for the release version and an exception will be thrown if the configuration vector is of the wrong size.

Also, notice that stack-of-tasks/pinocchio#808 suggests introducing a JointModelRPY. However, this would not solve the problem, as it would not comply with the current SoT way of handling it: currently, in the SoT, a hybrid convention is employed, where RPY is used for the orientation and omega is used for the angular velocity; the new joint would use RPY for the orientation and \dot{RPY} for the velocity; as such, special handling would still be needed for following the SoT convention.

[olivier-stasse]

Since #188 the whole SoT code has switched to quaternion representation for orientation of the free flyer and \dot{RPY} for the angular velocity. So I will close this issue.

[jmirabel]

What is #188 ?
I still have RPY for the robot free-floating base. When did the change occur ?

[olivier-stasse]

Sorry. It looks like I completely confused this issue with something else.
#188 does not exist.
Thanks @jmirabel for double checking.