[Bf-committers] Some questions/suggestions for "motion toolkit" and "iksolver"...

[Herman Bruyninckx]

Since a couple of weeks, I've been taking a very close look at the
Blender code, because our idea is to start using it as a 3D GUI for
robotics, and to contribute some robotics code to Blender. So,
especially the code of the "motion toolkit" (moto) and the "iksolver"
attract our curiosity. Here follow a couple of questions and suggestions
about this code. More will follow in the future, I guess :-)

Please, let me know your remarks or comments, as well as an indication
about how desirable you think it would be for us to begin working on
these issues...

- in "moto", I miss a class like "MT_RotMatrix3x3", which would
   specialise MT_Matrix3x3 for the case of rotation matrices. The only
   real differences would be:
     - a MT_RotMatrix3x3 must always be orthogonal
     - it has a very easy inverse: just the transpose. (Instead of the
       explicit inverse by Cramer's rule that is used now.)
   There _is_ already such an efficient thing for 4x4 matrices:
   "MT_Transform", where the efficient inverse is implemented, but it
   still calls the efficient inverse of its 3x3 rotation part.
   Maybe I miss some historical reason why the MT_RotMatrix3x3 has never
   been introduced explicitly, but it seems odd for a roboticist :-)

- I would add things like "MT_Screw", "MT_Twist", "MT_Wrench" for 6D
   rigid body motion; these are the physical things that Jacobian
   matrices (see IKSOLVER) of armatures work with: each column of a
   Jacobian matrix represents the end-point velocity ("twist") generated by
   the joint corresponding to that column; and vice versa, any 6D force
   ("wrench") applied to the end-point is transformed by the transpose
   Jacobian into torques at the joint level.

- can't we remove the dependency on TNT? (TNT namespace occurs
   explicitly in some of the moto code.) Possibly just by other namespace
   ("MN" or so, for "Matrix Numerics") that can wrap many numerical
   libraries that one wants to use. It's not a priority, but TNT is a
   dead project...

- in the "iksolver", I would suggest to work with the physical ("twist")
   Jacobian instead of with the matrix of partial derivatives: the
   physical Jacobian has nicer properties and is easier to calculate
   iteratively. No derivatives must be calculated explicitly, which gives
   large efficiency gains for complex structures. Our goal is to extend
   the solver to cope with "humanoid"-like armatures, including the dynamic
   properties; and to contribute more general IK routines than the one
   implemented now (e.g., damped pseudo-inverse, redundancy resolution
   based on the real mass distribution, etc.)

- I would also introduce revolute, prismatic and helical joints in the
   armatures, because doing everything with the current spherical joints
   requires too often constraints to be added to the chain, and that
   reduces efficiency and numerical accuracy of the iksolver.

- it seems that the moto library stores transformations as follows:
    | Xx  Yx  Zx  Px |
    | Xy  Yy  Zy  Py |
    | Xz  Yz  Zz  Pz |
    | 0   0   0   1  |
   but the Python code that we use in the Gameengine prints out the
   transpose of this... Am I overlooking or misinterpreting something, or
   is there really a difference in storing transforms and rotation matrices?

Herman
-- 
   K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480