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

Herman Bruyninckx bf-committers@blender.org
Mon, 9 Aug 2004 09:27:30 +0200 (CEST)

```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 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

- 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

```