Export position in a consistent way

[severin-lemaignan]

Export position in a consistent way through in different components (use Transformation3D).

Currently, we often export (x,y,z,yaw,pitch,roll) at the sensor level. Because different middlewares have different needs, and also modifiers often need to convert back the data to their own standard, it leads to numerous conversions and no standard representation.

It would make sense to export always the same object (Transformation3D) to prevent this.

[adegroote]

See #185 for proper documentation.

[flixr]

I started on cleaning this up and exporting position/translation as well as orientations/rotation in a consistent format. However I'm not sure what the best format would be... Should we really export the full Transformation3d class? Or maybe rather export them as simpler mathutils.Vector and mathutils.Quaternion? And we should probably also use Vector to export things like velocity and acceleration...

What about backwards compatibility? Continue to export separate x,y,z (etc.) fields in addition to the Vectors?

How does that work (or possibly cause problems) with "automatic" serialization for e.g. socket interface (and maybe some other middlewares)?

[severin-lemaignan]

Cool you want to takle this issue! In my humble opinion, vector + quaternion is the best for 6D positions. And I would use directly numpy objects. The other good option is a 4x4 transformation matrix. But then, as long as it remains 'internal', a Transformation3D object that encapsulate this vector and quaternion may be convenient (especially to expose common conversions that will still be required).

For linear speeds and acceleration, vectors are fine. But I'm not sure for rotational speeds/accelerations. Are quaternions well suited for that as well?

Regarding backward compatibility, as long as it is internal (ie, what is exchanged between components/modifiers/middlewares within MORSE), we don't care. Concerning 'external' visibility (what is exported by the middlewares), we have to assess what would break. Generally speaking, I would keep separate x,y,z for at least one more release, with blinking deprecation warnings to the end users.

Regarding automatic serialization (namely for text, socket and yarp), yes, these middlewares will need to be updated, but this should be a big deal.

[adegroote]

I don't have strong opinion about what is the best format to represent internal transformation, but as Severin, I would go with numpy representation instead of mathutils one. Euler has clearly lots of issues for internal representation, but it would be nice to have it as possible output, because it is probably the most understandable output format. Between 4x4 matrix and quaternion, I don't care, choose the more efficient (for multiplication, inversion, ...). We probably need to define too 'point3D', 'rotation3D', 'point2D', 'rotation2D'.

For speed and acceleration, I would follow ROS convention, so two vector of 3 (one for linear, one for angular).

Compatibility is an important thing. I would be nice to go from:

add_data('x', 0.0, "float", \
         'x coordinate of the sensor, in world coordinate, in meter')

....

add_data('pos', [0.0, 0.0, 0.0], "pos", ....) add_compatibility_data('x', 0.0, "float", \ 'x coordinate of the sensor, in world coordinate, in meter', local_data['pos'][0])

It would allow to keep the code of component sane, while providing compatibility, and allow to disable compatibility with only one flag. The last argument may be more general (a function) ?

[flixr]

I agree with Arnaud to use vectors for rotational velocity and acceleration. Using quaternions for this doesn't make any sense.

About using numpy vs. mathutils:

• numpy with scipy is great for a lot of things, but doesn't have e.g. a quaternion type and conversion functions to rotation matrix, euler, etc... We would have to use e.g. transformations.py quaternion_multiply
• mathutils provides a few very easy to use classes like vector, quaternion, matrix, etc.. This is directly what we get from Blender and using these you can easily rotate a vector, multiply matrices, access components by attribute...

IMHO for most things we do in MORSE itself mathutils is totally sufficient and way easier to use than numpy with transformations.py. So where do you see the advantage of using numpy as long as Blender is still using mathutils? Mathutils is also efficiently implemented in C and you don't need to start converting to numpy objects first. If you attach a middleware you most likely need to convert to another format anyway...

[adegroote]

After some thinking you're probably right. Go with mathutils for my part :)

[severin-lemaignan]

Agreed as well :-)

[adegroote]

Felix, did you find time to work on this point finally ?

[flixr]

I started, but then didn't have time to work on MORSE again since :-( and I doubt I will be able to finish it before beginning of February next year (vacation first, then paper deadline).