Dev:Source/GameEngine/RobotIKSolver/Status

Current state of the implementation

The algorithm is ported to the Blender 2.5 code base in the 'itasc' branch. The UI is unchanged except for a solver selection button in the Bone constraint panel:

Internally, a plugin system direct the code to the old or the new solver based on user selection. The solver temporary data is stored at the bPose structure level.

The itasc branch contains the solver library, called iTaSC. It supports the following features:

• Fixed and moving uncontrolled object.
  In Blender, this is equivalent to non-IK object such as a static object, an Empty following a path, etc.
• General purpose armature with multiple end effectors and moving base.
  Although the solver can handle multiple armatures linked by constraints, the plugin only supports one armature per IK tree: there is no way to specify symmetric constraints in the UI (and it would mess up the dependency graph). Proper support of symmetric constraint is left for future UI development.
• Joint limit constraints on 1DoF joints.
• 2DoF and 3DoF joints (without limit).
  Implementing joint limit on 2DoF and 3DoF joints turned out to be very complicated in the iTaSC framework. The method of old solver could not be used. As a result, nDoF joints with limits are implemented as separate 1DoF joints with limits. The result is not quite the same unfortunately but it's not too bad: instead of an elliptical limit, it gives a square limit.
• Distance constraint.
  This constraint is not available in the UI.
• CopyPose constraint.
  Each of the 6 pose variables (X/Y/Z position  and X/Y/Z rotation) can be constrained independently with offset. The offset method allows to control the relative position of an end effector from the target. It is not available in the UI but the same effect can be obtained by moving the target appropriately.
• Systematic framework for constraint definition.
  For each constrained output the application has the possibility to specify on each frame the feedback coefficient, the tolerance, the gain, the desired value and the desired velocity. A flexible callback system limits greatly the amount of code needed to control the constraints. This framework is used to implement user control over weight and limit in the UI.
• Detection of short loops in constraints.
  Each constraint defines a geometric loop that starts at the World reference and returns to the World reference after going through the armatures and constraint. If the same object is found multiple times in the loop (for example as the base of the armature and the base of the moving target), this object short circuits the loop, which is detected by the solver. This is important to have portable animation: by making the moving target relative to the armature position, the animation stays the same regardless of the position of the armature is in the world.
• Generic and fast cache system for all constraints and armatures.
  The cache is modular and entirely automatic.
• Sub-stepping.
  Two substepping method are available: fixed number of substeps and automatic substeps. A lot of effort has been put in the automatic substeps algorithm. It evaluates the optimal number of substeps based on 3 informations: the degree of 'non-linearity' of the armature pose, the velocity of the joint and the proximity of the joint limits. The non-linearity is estimated from the Eigen values of the Jacobian using an empirical law: the less linear, the greater number of substeps. The velocity has a direct influence of the duration of the substep: it is set so that no joint will change by more than 30 degrees in a single step. The proximity of the joint limit is a great source of non-linearity because of the variable gain. The substep is computed so that the gain does not vary by more than 50%. There is still room for improvement but the current algorithm gives good results already. It is an essential part of the stability of the simulation.
• Automatic interpolation of constraint during substepping.
• Re-iteration.
  The application can run more iterations of the solver for the same frame if it wants to improve the precision of the pose. This is used to set the pose at frame 1 in Blender just in case it is far from the rest pose.

The latest source code is available as part of the itasc branch. The original code is on the KUL repository and contains a lot of information in the commit logs. At some point I will convert this information into a wiki.

Original iTaSC repository (not being developped anymore):

mkdir ik-solver
cd ik-solver
svn co https://svn.mech.kuleuven.be/repos/orocos/orocos-apps/applications/iTaSC-standalone itasc
svn co https://svn.mech.kuleuven.be/repos/orocos/orocos-apps/applications/iTaSC-standalone-tests itasc-tests
svn co svn://anonsvn.kde.org/home/kde/branches/eigen/2.0/Eigen lib/Eigen

Directory structure:

• itasc: IK solver with embedded KDL (kinematic library from KUL)
  
• itasc-tests: test applications
  
• lib/Eigen : Eigen2 BLAS library. More info on their  web site

Blender itasc branch:

svn co https://svn.blender.org/svnroot/bf-blender/branches/itasc itasc

Performance

The solver is very fast and handles happily many constraints as long as the scene is under or fully constrained. The feedback coefficient for the constraint determines how quickly the constraints affect the armatures. A typical value is K=20s^-1. This means a time constant of 50ms and a reaction type of 100-200ms. This is too fast for real robots but just ok for armatures in Blender.

The value of the timestep is a critical parameter: if too large, the linear approximation of the solver is incorrect and the armature pose oscillates around the solution. In Blender this will directly be visible as an oscillation of the pose during the animation. That's one advantage of the new solver: if you don't set the parameters right, you see it directly as an ill behavior, while the old solver would eventually iterate many times silently.

There no configuration parameter available in Blender at the moment. The solver is set to use auto substepping (see above) and the feedback coefficient is set to 20 for all constraints. Later I will add a panel where the user will be able to change those settings.

Todo list

The current implementation meets the initial goal of replicating the functionality of the original solver. It is now time to move to the next level:

• Port constraint system to the GE.
  The current implementation has the limitations of the old solver: external targets for IK constraints are not supported in the GE. An external target is anything else than a bone of the same armature. It doesn't work in the GE because the evaluation of constraint target position is done using Blender data As Blender data (=object position, etc.) are fixed during the GE session, the target is also fixed and doesn't follow the corresponding GE object. For robotic applications you want to track real objects and it is necessary that external target are supported. This will be done by creating parallel constraint data in the GE.

• Allow dynamic modifications of constraints in the GE.
  The natural step after porting the IK constraint to the GE is to allow the creation/activation/removal of constraints during a GE session. A UI/python API will be necessary to allow the user to change the constraint set dynamically. This will be done with a new 'Armature Actuator' that will give access to the constraints.

• Implement more of the existing constraints in iTaSC.
  It is not decided yet which constraint should or can be supported. For each constraint, the corresponding 'armature' must be determine and implemented in iTaSC.

• Add new constraint.
  The first one will be the distance constraint. The UI will present it as a variant of the IK constraint.

• Implement bilateral constraint.
  This means the capability to declare that 2 armatures must cooperate and be evaluated together in a single simulation island. This is a major complication in the plugin code as now 2 armatures will share the same simulation data.