Inverse Kinematics With Constraints

Transcription

Inverse Kinematics With Constraints
∗
Morten Pol Engell-Nørregård
Sarah Maria Niebe
Morten Bo Bonding
†
‡
December 14, 2007
Department of Computer Science, University of Copenhagen
Universitetsparken 1, DK-2100 Copenhagen East, Denmark
Figure 1: The Kinematics Vitruvian
Student project, 15 ECTS
supervisor: Knud Henriksen
∗
†
‡
[email protected]
[email protected]
[email protected]
1
Contents
1 Introduction
5
1.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.2
Goals and requirements
6
. . . . . .
7
1.3
Section Overview . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.4
Dividing the work . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.2.1
. . . . . . . . . . . . . . . . . . . . .
Main goals for an inverse kinematics solver
2 Background
10
3 A data set for testing
12
3.1
Making the models . . . . . . . . . . . . . . . . . . . . . . . .
12
3.2
Making the video . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.3
2d to 3d . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.4
From graphics to data structures
. . . . . . . . . . . . . . . .
15
3.5
Conclusion on the Data set
. . . . . . . . . . . . . . . . . . .
15
4 Inverse Kinematics
16
4.1
Uses of IK . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2
Introducing Concepts . . . . . . . . . . . . . . . . . . . . . . .
16
4.2.1
Quaternions . . . . . . . . . . . . . . . . . . . . . . . .
16
4.2.2
Spherical Coordinates
. . . . . . . . . . . . . . . . . .
17
4.3
Articulated Figures . . . . . . . . . . . . . . . . . . . . . . . .
19
4.4
Joint Representation . . . . . . . . . . . . . . . . . . . . . . .
19
4.5
Joint Chain
20
4.6
Joint Parameters
. . . . . . . . . . . . . . . . . . . . . . . . .
21
4.7
Increasing realism . . . . . . . . . . . . . . . . . . . . . . . . .
23
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Optimization
5.1
16
24
Introducing concepts . . . . . . . . . . . . . . . . . . . . . . .
24
5.1.1
Wolfe conditions
. . . . . . . . . . . . . . . . . . . . .
24
5.1.2
The Jacobian Matrix . . . . . . . . . . . . . . . . . . .
26
5.1.3
The Hessian Matrix
. . . . . . . . . . . . . . . . . . .
27
5.2
Newton's method . . . . . . . . . . . . . . . . . . . . . . . . .
28
5.3
The Jacobian inverse method
29
. . . . . . . . . . . . . . . . . .
5.3.1
The Jacobian transpose method . . . . . . . . . . . . .
30
5.3.2
The Pseudo inverse . . . . . . . . . . . . . . . . . . . .
30
5.4
Quasi Newton methods . . . . . . . . . . . . . . . . . . . . . .
30
5.5
The BFGS algorithm . . . . . . . . . . . . . . . . . . . . . . .
31
5.6
Constraining the problem
. . . . . . . . . . . . . . . . . . . .
32
5.6.1
Lagrange Multipliers . . . . . . . . . . . . . . . . . . .
33
5.6.2
Karush-Kuhn-Tucker conditions . . . . . . . . . . . . .
35
2
5.6.3
The simple approach . . . . . . . . . . . . . . . . . . .
36
5.6.4
Active Set Methods
. . . . . . . . . . . . . . . . . . .
36
5.6.5
The gradient projection method . . . . . . . . . . . . .
37
6 Implementation
39
6.1
Overview of the program . . . . . . . . . . . . . . . . . . . . .
39
6.2
The Editor
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
6.3
The solvers
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
6.4
data structures
. . . . . . . . . . . . . . . . . . . . . . . . . .
41
6.5
constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
6.6
optimizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
7 Evaluation
43
7.1
Implementation requirements
7.2
Evaluation by comparison
7.3
7.2.1
Constraints
7.2.2
Dening constraints
. . . . . . . . . . . . . . . . . .
43
. . . . . . . . . . . . . . . . . . . .
43
. . . . . . . . . . . . . . . . . . . . . . . .
44
. . . . . . . . . . . . . . . . . . .
44
Evaluating esthetic quality and realism . . . . . . . . . . . . .
45
7.3.1
45
Obtaining motion capture data . . . . . . . . . . . . .
8 Results
46
8.1
Test results
8.2
Comparing the methods
8.2.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Constraints
46
. . . . . . . . . . . . . . . . . . . . .
47
. . . . . . . . . . . . . . . . . . . . . . . .
48
8.3
Evaluating esthetic quality and realism . . . . . . . . . . . . .
49
8.4
Concluding remarks
50
. . . . . . . . . . . . . . . . . . . . . . .
9 Conclusion
51
10 Future work
53
10.1 incorporating global constraints . . . . . . . . . . . . . . . . .
53
10.2 Experiments with alternative optimization methods . . . . . .
53
10.3 Making the code fully OpenTissue compliant
. . . . . . . . .
54
. . . . . . . . . . .
54
10.4 Evaluating the Quaternion representation
A Images
57
3
Abstract
In the eld of computer animation, there is a variety of animation
techniques that an animator can utilize when animating articulated
gures. Each technique has its benets and draw-backs. Therefore the
choice of technique often depends on the task at hand. An animator
working on a main character of an animated feature may wish to hand
model every frame of motion, gaining maximum level of detail control.
When control is of less importance and ease of modeling becomes a
priority, inverse kinematics proves to be a powerful tool.
This report is a study of two dierent methods for solving the inverse
kinematics problem, posed as an unconstrained as well as constrained
optimization problems.
We describe the theory behind the methods and have implemented
both methods in their unconstrained version. We have also incorporated joint limit constraints, by projection of the solution unto a
feasible region dened by these constraints.
We evaluate the two methods, assessing the qualitative gains compared
to the computational complexities. The resulting implementation is to
be integrated with the existing open source meta library OpenTissue.
A small set of 3D models and motion capture data has been composed
to be used for an evaluation of the system once it is nished. A web
page has been constructed for the project comprising the full text plus
pictures and video clips to document the process. The web page can
be found at http://kinematics.icandy.dk/ [3].
Figure 2: The two gures modeled for the motion capture data set
4
1
1
INTRODUCTION
Introduction
In the following section we give a brief introduction to our project.
We
describe the motivation for the project as well as what we hope to accomplish.
We go on to describing the document as a whole, and give a short description
of our individual focus.
1.1
Motivation
Inverse kinematics rst found its use in the eld of robot technology, where
it was used to compute the poses of the robots.
Since then it has been
integrated in the world of animation, where it is used in a similar fashion
computing poses of articulated animated gures.
The reason for this new found use, was the prospects of easing the process
Figure 3: Example of a gure posed by skeletal deformation to resemple the
famous statue le penseur by Auguste Rodin.
of animation, eliminating the need for animating every single joint of the articulated gure. With inverse kinematics, an animator only needs to position
the end eectors of a gure, leaving the positioning of intermediate joints to
the inverse kinematics solver. For this to result in a pose that seems natural, it is necessary to impose constraints on the joints of the gure, which
means that the solver will have to solve a constrained optimization problem.
This is by no means uncharted territory, however we still feel that the work
5
1.2
1
INTRODUCTION
behind this report is justied since we combine well-known techniques with
new approaches. Furthermore the code will contribute to OpenTissue.
1.2
Our main goal is to create and document an inverse kinematics based animation system for the OpenTissue[4] meta library, using quaternions as internal
representation of the joints. Since there is currently no implementation of
kinematics, we nd that our work is a needed and valuable contribution to
OpenTissue.
We must adhere to certain programming guidelines and rules when aiming
at integrating, which can make implementation a somewhat tedious task.
Also we are obligated to thoroughly document our implementation to make
it accessible to others, being that OpenTissue is an open source library.
The methods we intend to use are based on previous work within the eld.
For the purpose of comparison, we will implement two numerical optimization methods for solving the inverse kinematics problem: A rst order Newton method and a second order Quasi-Newton based method.
The core of the Newton method is the calculation of the inverse of a matrix.
Actually, since the matrix in question is typically non-square, we need the to
calculate either an approximation, i.e. the transpose, or the pseudo-inverse.
We plan to implement both of these methods and test which way of matrix
inversion is the most ecient and which produce the most visually appealing
results.
The Quasi-Newton based method (called BFGS) approximates second order
derivatives, i.e. the Hessian matrix, which is a quite expensive calculation.
It should, however, enable this method to converge much faster than the
Jacobian. We will perform tests hoping to shed light on whether the added
computational complexity is aordable compared to the Newton method.
In order to create realistic movement, constraining our skeleton is crucial.
Therefore it is our goal to implement methods of constraining. As a minimum, our implementation should be able to explicitly enforce constraints on
the skeleton. This could be done by projection of the solution unto the feasible region. This will change the skeleton pose with no regards to a potential
solver working on the skeleton, in eect wasting resources on computing nonvalid solutions. More optimal, yet still not quite satisfactory, is the use of
gradient constraints which eectively set limits on the search direction for
the optimization methods. If time allows it, we will enable the implementation of the BFGS to solve the
constrained
IK problem.
This allows for
the most general type of constraint, but is a very complex technique both
regarding implementation and time complexity. Also it scales rather badly,
which we will need to exam in detail, if we implement it.
In our experience there is a need for a graphical user interface when
developing OpenTissue based software. Especially when testing end debug-
6
1.2
1
INTRODUCTION
ging these high dimensional non-linear methods and constrained IK, we will
need to ease interaction with the program.
Therefore we have decided to
integrate a graphical user interface allowing runtime variable manipulation.
In addition we will use utilities for enhancing interaction and give runtime
feedback.
In this report we seek to present methods and theory in such a way that
it will be possible for the reader to implement an inverse kinematics solver
on her own. Also this is an aid to those wanting to work on or improve our
implementation.
1.2.1 Main goals for an inverse kinematics solver
The main goals when making a solver for inverse kinematics are user-control
and a high degree of automation. What does that mean? User control means
that the solver must not impede the work of an artist by constraining his or
her possibilities. High degree of automation means that it must be possible to
obtain a plausible result with as few parameters as possible. As an example
related to our project it would be desirable to only have to position the end
eectors and then the rest of the gure is posed in a realistic way according
to the constraints.
These two goals are to some degree opposed to each other, the more control
you want the more parameters you need to be able to tweak and hence the
less automatic the process is. One way to tackle this dilemma is to let the
system be automatic but to also to make it possible to change the automatic
settings afterwards, again an example from character animation would be
to make it possible for an animator to reposition the links between the root
and the end eector after the IK solver has calculated their position.
For this to be feasible the poses computed by the IK-solver would have to
be usable in most cases. If the animator has to ne tune the poses each and
every time, IK would be no help. What we want then, is poses that could be
called generic and realistic, so that in most cases the animator could leave
the poses as they were, and only had to tweak them in some special cases.
It is not possible for a automatic IK system to produce life-like animations
for living creatures, they will always be sti and puppet-like, unless some
kind of post-processing is administered.
This could be in the form of the
method proposed in [9] or could be done by an artist.
The reason for this is that even with a constrained IK there are innitely
many viable solutions and only a few are the ones that a real person would
choose. Therefore we need something more. One obvious lack of the model
is gravity and muscle-actions. Kinematics are by denition not aected by
Newtonian forces and so can never hope to give a realistic solution. It is not
however impossible to incorporate gravity etc. into IK but that is beyond
the scope of this project, and might be the subject of later work as described
in section 10.
7
1.3
1.3
Section Overview
1
INTRODUCTION
Section Overview
Each chapter of this report begins with a short introduction of the content
of the given chapter. This section is a brief summary of these introductions
and is meant as a reading guide.
Section 1 on page 5
This rst section is of a practical nature, presenting
formalities pertaining to the project at hand.
There is no theoreti-
cal information in this section, so readers that are only interested in
implementing an IK solver may skip this chapter.
Section 2 on page 10
is a background study, trying to recap previous re-
search in the eld of IK.
Is a documentation of the process of acquiring a
proper data set for testing our solution.
is a walk trough of the most basic concepts of IK.
This is where we describe the articulated gure, on which we will perform IK. As such, in can be perceived as a prerequisite for understanding not only the section on optimization theory, but only the hows and
whys of our implementation.
is on the theory of optimization. When optimiza-
tion is given a separate section, it is an acknowledgment of the importance of the optimizing unit of an IK solver.
is a brief description of the developed program, and
its key parts.
describes which qualitative measures we wish to
test our system against, and how we mean to execute these tests.
is a followup on chapter 7. This is were we present
the results of our evaluation tests.
is the conclusion where we compare our results with
the goals we hoped to achieve and conclude on the project.
is concerned with describing possible ways to ex-
tent our work.
1.4
Dividing the work
All members of the group have partaken in all parts of the project, however
there are subjects where we each have had slightly more focus than others.
The following is a list of the areas each of us have concentrated upon. We
have each written our own description of the areas we have focused on in the
project.
8
1.4
Dividing the work
Morten Bo Bonding
1
INTRODUCTION
This project is going to be a part of the OpenTis-
sue meta library, which is why my main focus has been code design
and implementation evaluation, verication and testing. This includes
development of a range of utilities e.g. for importing constraints, data
handling, constraint manipulation as well as utilities for runtime logging, feedback and interaction.
Sarah Maria Niebe
I have placed my focus on the theoretical part of this
project, trying to get an all-round knowledge of the optimization algorithms and optimality conditions. The BFGS method as [16] describes
it, has been the main focus of this theoretical study, as it is one of the
two methods we have chosen to implement.
Morten Pol Engell-Nørregård
My focus has been the development of
the inverse kinematics solvers, both theoretically and practically.
I
have mostly concentrated on the unconstrained version.
Project management have also been one of my key areas, I have taken
care of trying to get some structure on the way we where working,
and making an overview of the current state of aairs available to all
members of the group.
I have also been the graphics artist on the project having made all the
motion capture data. This is not strictly a part of the project per se
but I mention it because it has been a prerequisite for the entire project.
9
2
2
BACKGROUND
Background
This section is a description of the background for our project, as well as a
description of the literature that has formed the basis for our project.
In robot technology, inverse kinematics (IK) has long been used for computing the positioning of intermediate joints on the path from root joint to end
eector joint. Must robotic systems consist of a single chain of joints, e.g.
a car factory migth have a robotic arm placing parts on a car chassis. This
means that an IK solver for such a system only has to handle a small number of degrees of freedom (DOF), combined with the advantage of having
a specic underlying architecture, one can implement a highly specialized maybe even hardware accelerated - IK solver.
So when IK was discovered by the graphics community, as a new way of
animating articulated gures, the need for more general methods was born.
The challenge was generalizing the methods while at the same time handling
a higher number of DOF. An often used articulated gure in animation is
the human body, if this is to be simulated somewhat accurately the gure
will have to have many DOF, some of which will be redundant.
E.g.
the
1
human arm, this is considered to have seven DOF , but only 3 DOF would
be necessary for reaching any point reached using the seven DOF. The redundant DOF are what enables the arm to grasp at the same object from
dierent angles and directions.
According to Martin F¥dor [8], most IK systems use the Jacobian inverse/transpose method even though these methods suers from singularity problems. The most common approach seems to be using some kind of pseudo
inverse [12] to invert the Jacobian, the problem with singularity is not solved
by this though [13].
Another approach is the Cyclic coordinate descent (CCD) described in [8,
15], it uses the greedy paradigm to solve for each joint in turn, and repeats
this process until a satisfactory solution is found. Although this method is
both simple and fast, it suers from several drawbacks when it comes to
precision. This text does not address CCD in any detail.
In 1994 Jianmin Zhao and Norman I. Badler [16] presented another method
for solving the IK problem using a nonlinear system of equations, that made
it possible to solve large systems with many redundant DOF. Most literature
on this subject use Euler angles when representing the joints, this report will
however be representing the joints with quaternions. The reason for this approach is the - to our knowledge - lack of literature that combines the theory
of such a solver with the actual implementation of it. The work of Kenny
Erleben and Knud Henriksen [11] serves as a basis for this approach.
Many dierent methods for solving the IK problem has been proposed, but
1
A shoulder gives pitch, yaw and roll, an elbow allows for pitch, and a wrist allows for
pitch, yaw and roll
10
2
BACKGROUND
recent research seems to favor numerical optimisation approaches. Most of
these methods are described in [13], where a both recent and thorough description of numerical optimization techniques can be found.
Much of the resent research in the eld such as [9, 7] is not really concerned
with solving the IK problem but rather with elaborating on the periferals of
the method, such as easing interaction[7], or combining dierent animations
calculated with IK [9].
11
3
3
A DATA SET FOR TESTING
A data set for testing
Since we work with Inverse Kinematics in a graphics context we needed some
kind of data set to test our system on. A typical test set would consist of a
model consisting of a skinned skeleton, and possibly some Motion captured
animations.
After having tried out dierent possibilities we decided on making our own
test data set. The Set should consist of two models each with a number of
animations.
Motion capture is a broad term covering a lot of dierent techniques from
advanced machines that capture directly to 3D data, to simple version where
data is taken from 2d movies of persons from dierent angles and transformed
into 3d data by hand. Since we do not have access to expensive equipment,
it was fairly obvious that we had to make do with less than that. Fortunately
we had a member in our group with some experience in 3d graphics.
3.1
Making the models
The most important part of the dataset are the models themselves. these
should be realistic with regard to proportions and visually pleasing, so as
to not disturb the communication of the results. The Models used for our
program are 3d models of humans. One male, E.R.I.K. (which is short for
Experimental Rig for Inverse Kinematics) and on female, E.R.I.K.A. (which
is a feminine form of E.R.I.K.). The models have approximately 32 joints
each with up to 6 degrees of freedom (although no more than 3 are used in
this context).
Both models have been build in Blender[1] using pictures of humans as
Figure 4: The Male model E.R.I.K. as it looks in our editor window
12
3.2
Making the video
3
reference in much the same way as described below for the animations. The
reason we chose human models are rst and foremost that it is the most
obvious choice since animations using motion-capture are usually (but far
from always) human. The second reason is that it was far easier for us to
make human motion capture since we could then use friends and family as
models.
Figure 5: the female model E.R.I.K.A as it looks in our editor window
3.2
Making the video
the easiest part was getting the videos it was a simple matter of taking some
videos of people walking around or doing motions. There are however some
problems involved, since these videos where to be used as the basis for 3d
models they would have to have the same orientation and position, relative
to the camera in every frame of the video. This is an almost impossible task
to accomplish using a small hand held camera, so we did something else.
The orientation isn't so big a problem, when you want to have a side shot.
You make people go around the camera in a circle. This can be marked on
the ground so as to make sure the distance is the same all the time.
Keeping a walking person centered is a more dicult problem.
This was
solved again as simple as possible by simply translating the individual frames
of the video so the person was in the same position in each of them.
As easy as this may sound it is not a simple problem, since a body deforms
when the person walks, arms sway, legs move, head and shoulders sink and
rise. Had it not been so, it would have been a simple task, best solved by a
13
3.3
2d to 3d
3
computer. as it is developing such a solution would be a project in its own
right.
Now it must be done by hand using the pelvis as the reference in the X-axis
and the foot currently touching the ground as the reference in the Y-axis.
Another problem arise when you lm people from the front. Since they are
moving towards the camera they will get bigger as they move closer. this is
solved by scaling the frames until the person walking is the same size as the
other frames.
The nal problem and one that is not easily solved unless one has an orthographic camera, is the perspective in the frame. as a person walks towards
the camera, his front most foot will be closer to the camera than the other
this is quite obvious when compared to the 3dmodel that must be tted to the
picture. There is no easy solution to this , however the necessary information
can be interpolated from the other views (where the perspective is dierent).
3.3
2d to 3d
When the movie are nished they are between 20-40 frames long these are
imported in Blender [1] and used as background in the modeling window.
Figure 6: illustration of the steps in transferring the pose from the picture
to the model
Artistic freedom
Some degree of artistic freedom is inevitable when using the method we
have used here. The important notion here however is that we have realistic
looking animation as the basis for our analysis, and that great care has been
14
3.4
3
taken, not to modify the original data more than absolutely necessary. All
people have slightly dierent motions anyway so as long as our models keep
well within these limits, there is really no reason to be concerned about the
realism.
Most motion capture is used in graphics where we are not really interested
in realism anyway. We want what is commonly known as cinematic reality
meaning that we want something that we think look realistic, not something
that really is realistic. As we have thrived to make our animations realistic
and have not taken the artistic freedom too far (actually we have tried not
to take it anywhere) our animations are very close to the way humans really
moves which can also be seen from the accompanying video material.found
at [3].
3.4
Converting the graphics les to OpenTissue data structures has been a fairly
straight forward process. Blender has an export option to the cal3d format[2]
and OpenTissue has import code from this format to Opentissue data structures.
3.5
Conclusion on the Data set
As we have shown we have succeeded in making realistic and usable 3D models for use with our project, a motion capture data set consisting of walking,
standing, and saluting has also been made. It has been a time consuming
process but since this dataset will be made available for other students at
DIKU and otherwise who want to work with character-animation,we believe
it has been worth the eort.
Examples of the data set can be found at
http://kinematics.icandy.dk/ [3].
15
4
4
INVERSE KINEMATICS
Inverse Kinematics
This chapter is a short introduction to inverse kinematics, and the system
we wish to apply it to. It is not a chapter on solving the inverse kinematics
problem, but rather a walk through of the system we wish to perform inverse
kinematics on.
4.1
Uses of IK
IK can be used in several dierent applications, each of which places dierent
requirements on the solver. The two most widely applications are:
1. Real time solving for robots or simulation. In this context it is necessary for the solver to be able to solve the problem at rates that makes
it possible for the simulation/robot to move in real time. This is similar to collision detection in simulation, which should be computable
at rates of approximately 50 - 100 times per second or more. Solving
a kinematics problem this fast is nigh on impossible unless we either
place some restrictions on the number of iterations we allow the solver
to take or we work on a very restricted model with regard to DOF.
2. Interactive solving for modeling and animation.
In this case we can
allow ourselves a little more time since we only need to compute 15-25
poses per second. This means that we can handle more DOF and can
achieve greater precision since we do not have to enforce a hard limit
on the number of iterations.
Which of these applications that are the most interesting depends on the
problem at hand.
4.2
Introducing Concepts
There are some mathematical and theoretical concepts that we need to explain, in order for the following to be easily understood.
4.2.1 Quaternions
Quaternions are a non-commutative extension of the complex numbers. They
are dened as the mathematical ring:
H = {a + bi + cj + dk | a, b, c, d ∈ R}
where
i2 = j 2 = k 2 = ijk = −1.
(1)
This means that a quaternion can be
represented by just 4 real numbers.
Quaternions are widely used for 3D
rotations, having the advantages over normal rotation matrices that:
16
4.2
•
4
INVERSE KINEMATICS
representing a quaternion is compact, 4 numbers compared to the 9
needed for a rotation matrix
•
rotation by quaternions eliminates gimbal lock (for an explanation of
gimbal lock see [12])
The common mathematical operations - addition, multiplication, inversion
and so fourth - are also dened for quaternions, but since we use quaternions
for 3D rotations we will only show the rules for multiplication and inversion.
Given two quaternions
ab
the product
a = (a1 +b1 i+c1 j +d1 k) and b = (a2 +b2 i+c2 j +d2 k),
is dened as:
ab = (a1 + b1 i + c1 j + d1 k)(a2 + b2 i + c2 j + d2 k)
= (a1 a2 − b1 b2 − c1 c2 − d1 d2 ) +
(2)
(a1 b2 + b1 a1 + c1 d2 − d1 c2 )i +
(a1 c2 − b1 d2 + c1 a2 + d1 b2 )j +
(a1 d2 + b1 c2 − c1 b2 + d1 a2 )k
The inverse quaternion is dened as
is the conjugate of
a.
ā
aā
a−1 =
This gives us:
where
ā = (a − bi − cj − dk)
ā
aā
a − bi − cj − dk
a2 + b2 + c2 + d2
a−1 =
=
(3)
(4)
Knowing how to invert and multiply quaternions enables us to use them for
rotations. A
θ
degree rotation around axis
n = (n1 , n2 , n3 )T
of the vector
v
is given by:
v 0 = qvq −1
where
q = (cos( 2θ ) + n1 sin( 2θ )i + n2 sin( 2θ )j + n3 sin( 2θ )k).
(5)
When the rotation
quaternion is of unit length, the inversion is equal to the conjugate of
q.
This is seen in equation (4), where the denominator is in fact the length of
quaternion
a,
which in the case of a unit quaternion is 1.
For more on quaternions, see [6].
4.2.2 Spherical Coordinates
Using quaternions for rotation and orientation dictates the use of spherical
coordinates, which might not be familiar to the reader. Therefore we will
recap the theory of spherical coordinates here.
Spherical coordinates, like the well known Cartesian coordinates, are a way
of representing position in 3D. In our particular case, where we wish to describe orientation, we use the model slightly dierent. Where the parameter
17
4.2
θ
4
INVERSE KINEMATICS
usually denotes the distance from origo (and is usually named
ρ),
we let it
denote twist as explained below. The math however, is identical.
A given orientation is represented by the three angles azimuth
ψ,
and twist
θ.
φ,
elevation
Throughout the literature, there is great ambiguity as to
which parameter is denoted by what symbol, we have adopted our use of
notation from [11].
The relationship between quaternions and spherical coordinates are de-
Figure 7:
Spherical coordinates:
modeling azimuth
φ,
elevation
ψ,
the gure shows an orientation version,
and twist
θ.
Twist could be exchanged
for length giving an arbitrary position. Note that the gure is only a half
sphere, this is for visual simplicity.
scribed in details in 4.6 on page 21.
Quaternions describe a rotation around an arbitrary axis in 3D space. Spherical coordinates are very close to this representation since the two rst parameters azimuth and elevation describe an arbitrary vector in 3D space,
and the last parameter twist describes a rotation around this axis.
There is a one to one mapping from the Cartesian coordinates to the spherical coordinates, given by:
p
x2 + y 2 + z 2
!
p
x2 + y 2
φ = arctan2
z
y
ψ = arctan2
x
θ=
(6)
(7)
(8)
And the reverse from spherical to Cartesian coordinates is given by:
x = θ sin φ sin ψ
(9)
y = θ sin φ cos ψ
(10)
z = θ cos φ
(11)
18
4.3
Articulated Figures
4.3
4
INVERSE KINEMATICS
Articulated Figures
There seems to be two dominating ways of working with articulated gures
•
constructing a skeleton unto which a skin is rigged, thereby dening
how the movement of the skeleton should deform the skin
•
working directly on the skin, skipping the time consuming rigging of
skin
Recent study shows that it is possible to do impressive deformations directly
on the mesh, [7], so why bother with skin rigging and making a skeleton?
First of all because of generality, animations on a skeleton can be tted to
dierent skins with little or no modications. Second, the methods developed for direct mesh deformation requires the construction of a number of
example poses from which other deformations are deduced. This makes this
method at least as time consuming as the rigging process, since most meshes
are very detailed. Third, since the process of making the example poses and
generating the deformable mesh is fully automated, based only on the example meshes, explicit control on the part of the modeler is lost. When this is
compared to the fact that, what the process does, is in fact a sort of rigging,
based on grouping the vertices of the mesh into rigid groups, old fashioned
rigging is still a fully acceptable a competitive method.
Based on this argumentation, we have chosen to work with the skeleton representation which means we will have to dene a skeletal structure. Similar
to the human skeleton, the articulated gures we have worked on during this
project, consist of bones connected by joints. The literature on this subject
speaks of prismatic and revolute joints, but since the human body doesn't
have prismatic joints we will only use the latter type.
A skeleton can be thought of as a graph tree, it typically has one root bone,
2
but can have several end eectors .
The joints on the path from root to
end eector make a joint chain, see chapter 4.5, and it is on these chains we
perform the inverse kinematics.
4.4
Joint Representation
If we assume a one to one correspondence of bones and joints, we can merge
the information of the length of the bone and the orientation of the joint,
see gure 8. From this point on, the denition of a joint is its rotation and
translation, relative to the parent joint. This can be represented as a rotation
quaternion
q
and a translation vector
t.
Given a parameter vector you can
compute the pose of jointi by performing a series of relative rotations and
translations, this is called forward kinematics. From section 4.2.1 we know
2
A bone with no child bones, or in graph theory a leaf
19
4.5
Joint Chain
4
INVERSE KINEMATICS
Figure 8: A single joint consisting of translation and orientation. The cone
represents the translation, while the sphere with the small coordinate system
attached is the orientation
that a rotation quaternion has the form:
q = (cos
θ
θ
θ
θ
+ n1 sin
i + n2 sin
j + n3 sin
k)
2
2
2
2
in vector notation:
θ
θ
q = [cos
, n sin
]
2
2
(12)
(13)
However, the revolute joints we wish to rotate are spherical and to model
this we have to introduce two more parameters
φ
and
ψ,
also known as the
azimuth- and elevation angles. These new parameters are used to parameterize the axis of rotation:
θ
θ
q(θ, φ, ψ) = [cos
, n(φ, ψ) sin
]
2
2
where
4.5

cosφsinψ
n(φ, ψ) =  sinφsinψ 
cosψ
(14)

(15)
Joint Chain
A joint chain is a number of connected joints, where the translation and rotation of the i'th joint aects the translation and rotation of any joint placed
later in the chain, which means we are operating with relative transformations as opposed to absolute transformations. Figure 9 illustrates a simple
joint chain, constructed by three joints.
The chains are build under the assumption that all bones have at most one
parent but can have any number of children. This assumption is not a very
strong constraint on the generality since almost any conguration that we
20
4.6
Joint Parameters
Figure 9:
4
INVERSE KINEMATICS
A joint chain consisting of 3 joints.
The cones represent the
translation of the joint and the spheres represent the rotation. Notice that
the order of transformations is translation,rotation.
can think of from real life is like this. Even those that might not be, could be
made to work as if they were, by careful placement of the root. Furthermore
this restriction is one that very often is placed upon the skeleton anyway.
This assumption makes it possible to build all the chains in a skeleton very
simply.
We just run through the entire skeleton and mark all bones with
no children as end eectors. Then we build a chain for each end eectors
by moving back through the skeleton, going from parent to parent until we
reach the root. Figure 10 illustrates a branched skeleton, and how it is traversed to build to joint chains.
By doing so we have a robust and simple way to construct the chains and
we are thus ready to start performing inverse kinematics on each of these,
or all simultaneously if we so please.
4.6
Joint Parameters
Given a quaternion
qi ,
representing the relative orientation of the i'th bone,
we may wish to extract the three angles
θ, φ and ψ .
Since they are not explic-
itly represented, we have to derive a way of computing the angles. Equation
(14) gave us the quaternion that describes the rotation around axis
n(φ, ψ),
combined with equation (15) we have all the information needed to isolate
the three unknown angles. First we dene the vector
and a rotation quaternion
q = [s,
n∗ ] where:
θ
s = cos
2
n∗0
θ
= cosφsinψsin
2
21
n∗ = (n(φ, ψ) sin( 12 θ))
(16)
(17)
4.6
Joint Parameters
4
INVERSE KINEMATICS
Figure 10: A simple branched skeleton. Two chains are build consisting of
the joints
{0, 3, 4}
and
{0, 1, 2}
n∗1
n∗2
θ
= sinφsinψsin
2
θ
= cosψsin
2
We can now isolate the angle
φ
φ
(19)
since
sinφsinψsin
n∗1
=
∗
n0
cosφsinψsin
and
(18)
θ
2
θ
2
=
sinφ
cosφ
(20)
is given by
φ = arctan
sinφ
cosφ
(21)
To be sure to compute the correct angle, no matter which quadrant it lies
in, we recommend using the slightly modied version of arctan, arctan2 see
[12].
Now that we know the value of
φ
we can use this knowledge to compute
the other two parameters.
By using the relation
n∗0
= sinψsin
cosφ
and
n∗0
cosφ
n∗2
=
22
θ
2
sinψ
cosψ
(22)
(23)
4.7
Increasing realism
we can use the
arctan2
4
function again to compute
n∗0
cosφ
arctan2  ∗
n2

ψ=
nally we can nd the value of
θ
ψ
as


(24)
θ
2
θ
2
(25)
by
n∗0
cosφsinψ
=
s
θ
INVERSE KINEMATICS
sin
cos
can then be determined as

θ
2
= arctan2 

n∗
0
cosφi sinψi

θ = 2 arctan2 
4.7

s
n∗
0
cosφi sinψi
s

⇔
(26)

(27)

Increasing realism
There exists several ways of increasing the realism of the animation.
The
simplest yet surprisingly eective method, is weighting the individual joints
willingness to move. This can be done quite simply by weighting the distance
each link is moved each iteration. Given an update vector
matrix
W,
joints, the
W = wT I and w is a vector
weighted update pu is given by:
where
p
and a weight
of weights on the individual
pu = W p
(28)
This simple weighting method can be applied to any or all joints in this way
and can be used to model the willingness to move.
In practice this weighting is performed on the update vector. See section 5.3
on page 29 and section 5.5 on page 31 for a detailed description of the update
vector.
23
5
OPTIMIZATION
Figure 11: An example of the inuence of dierent weights on the nished
pose. This illustration is produced with our program, using low weights on
the two outermost joint in the left case and low weights on the innermost
joint in the right case.
5
Optimization
When solving optimization problems, the choice of solver is not a straightforward right or wrong choice. Dierent solvers pose dierent benets and
drawbacks, some of which can be dicult to foresee theoretically, based on
the optimization problem at hand. Appreciating this, we have chosen to implement two dierent types of solvers with the intent of comparing the results
they produce. This chapter is meant as a brief introduction to the Jacobian
inverse method and the BFGS method, for a more in depth description of
the two, the reader is referred to [13, 16, 14].
5.1
Introducing concepts
Before we start deriving the two methods, we rst need to introduce a couple
of mathematical concepts used in a wide selection of optimization solvers.
The following subsections attempt to give an explanation of the concepts in
a manner that doesn't require a complete understanding of the underlying
math.
5.1.1 Wolfe conditions
A large part of optimization is determining the search direction,
pk ,
for the
next iteration. This could be the negated gradient of the object function,
the negated product of the inverted Hessian and the gradient, or some other
24
5.1
5
OPTIMIZATION
update paradigm. But common to them all is that they only represent the
direction of search, not where along this direction the local optimum lies.
αk , there exist a variety of line search methods
φ(α) = f (xk + αpk ), where α > 0. A common set of
To determine the step size,
that tries to minimize
conditions for many line search methods is the Wolfe conditions:
f (xk + αk pk ) ≤ f (xk ) + c1 αk ∇fkT pk
T
∇f (xk + αk pk ) pk ≥
with
(29)
c2 ∇fkT pk
(30)
0 < c1 < c2 < 1
The rst condition, (29), is also known as the Armijo condition. The Armijo
condition is a sucient decrease condition, as it demands a sucient reduction in
f
at point
xk+1 = xk + αk pk .
Figure 12 illustrates the intervals
Figure 12: The Armijo condition
that will satisfy the Armijo condition, but it also illustrates the shortcoming
of using only the Armijo condition as in this case the condition is satised
for very small
αk
values, impeding the rate of convergence. To correct this
behaviour, the Wolfe conditions incorporates information of the functions
curvature with inequality (30). The curvature condition requires an increase
in the slope, since a strongly negative slope at
creasing after
xk+1 ,
meaning that
αk
xk+1
implies that
is not a minimizer of
f
is de-
φ.
We are still not guaranteed that the step size found using the Wolfe conditions is a step that brings us to a global minimum of
αk to
φ(α):
the strong Wolfe conditions force
allowing a positive derivative at
φ.
To amend this,
lie close to a minimizer of
f (xk + αk pk ) ≤ f (xk ) + c1 αk ∇fkT pk
T
|∇f (xk + αk pk ) pk | ≤
with
c2 |∇fkT pk |
φ
by not
(31)
(32)
0 < c1 < c2 < 1
The setting of variables
c1
and
c2
depends on how the search direction is
25
5.1
5
OPTIMIZATION
found, however the two methods of this report - Newton and Quasi-Newton
methods - often use the values
c1 = 10−4
and
c2 = 0.9,
[13].
5.1.2 The Jacobian Matrix
Jf (x) is the matrix of rst-order partial derivatives of f (x).
n × m matrix, where n is the size of the goal vector and m is the
number of parameters. For f (x1 , x2 , . . . , xm ) = (y1 , y2 , . . . , yn ), this is the
Jacobian:
 ∂y

∂y1
∂y1
1
.
.
.
∂x2
∂xm
1
 ∂x
∂y2 
∂y2
∂y2
.
.
.
 ∂x
∂x
∂xm 
1
2


Jf (x) =  .
(33)
.
.
..

.
.
.
.
.
.
.


∂yn
∂yn
∂yn
∂x1
∂x2 . . . ∂xm
The Jacobian
Jf (x)
is a
The Jacobian can be viewed as a multi-dimensional gradient, that is it denes
the direction of travel in a multi-dimensional space much like a tangent
denes the direction of travel in a one-dimensional space.
To get a more
tangible explanation of the Jacobian, consider this example:
Example in 2 dimensions
The situation is this, we have a simple chain
of two joints each with one DOF. Assuming that the movement of the end
eector is conned to a plane, we can model this in a two-dimensional space,
see gure 13. The Jacobian of this problem is a
2 × 2 matrix, since the joints
have one DOF and is therefore parameterized with one parameter each and
the goal vector is two-dimensional. Figure 14 shows a plot of the objective
Figure 13: A conguration with to joints each with 1 DOF, the unconnected
circle, at {1.2 , 0.6} is the goal position
function for a chain with two joints, each of which is of unit length. Both
26
5.1
5
OPTIMIZATION
joints have one rotational DOF. The root of the chain is situated in origo and
the goal position have the coordinates
x = 1.2 y = 0.6
Since the distance
Figure 14: A plot of the objective function for a joint chain of two joints,
each with two DOF. Notice the two global minima seen as bulges on the
underside of the function
from the root is less than the maximum reach of the chain there is more
than one minimum in the objective function. In this simple example there
are only two possible optimal solutions, however with more joints or more
DOF the number of solutions will go towards innity.
The Jacobian can be used to minimize this function, see section 5.2 on the
next page and 5.3 on page 29.
5.1.3 The Hessian Matrix
Since the methods we have implemented don't use the actual Hessian matrix,
but just an approximation of it, we will only briey describe it here.
Assuming that the function
f (x)
is twice dierentiable, the Hessian matrix
Hf (x) is a square matrix, consisting of the second-order partial derivatives
of f (x). The Hessian is equivalent to the Jacobian of the gradient of f .
 ∂ 2 f (x) ∂ 2 f (x)

∂ 2 f (x)
.
.
.
2
∂x1 ∂x2
∂x1 ∂xn
1
 ∂ 2∂x

f (x)
∂ 2 f (x)
∂ 2 f (x) 

.
.
.
2
 ∂x2 ∂x1
∂x2 ∂xn 
∂x2
Hf (x) = 
(34)

.
.
.
.


.
.
..
.
.
.
.


∂ 2 f (x)
∂ 2 f (x)
∂ 2 f (x)
∂xn ∂x1
∂xn ∂x2 . . .
∂x2
n
The Hessian contains information of the curvature of function
f
at point
x.
The properties of the Hessian can be used to test for optimality of a given
27
5.2
Newton's method
point. If we have
5
∇f (x∗ ) = 0,
and
x∗
Hf (x)
•
Positive denite: then
•
Negative denite: then
•
Indenite: then
•
Singular: udeneable behaviour of
x∗
x∗
OPTIMIZATION
is:
is a minimum of
f
is a maximum of
is a saddle point of
f
f
f
Testing a symmetric matrix for positive deniteness - which is of interest of
this project since we are trying to minimize our problem - can be done in a
couple of ways. Some methods use factorization of the matrix, analyzing the
resulting sub matrices. By computing the eigenvalues of
Hf (x) and checking
that they are all positive, is an alternative and very expensive way of testing
for positive deniteness.
5.2
Newton's method
Newton's method is based on a second order Taylor series expansion of the
object function
f (x):
1
f (x + σ) ≈ f (x) + ∇f (x)T σ + σ T Hf (x)σ
2
(35)
∇f (x + σ) = 0,
which by a rst-order
∇f (x + σ) ≈ ∇f (x) + Hf (x)σ
(36)
The minimizer of (35) is found when
Taylor series expansion is
recalling from 5.1.3, the Hessian is equivalent to the Jacobian of the gradient.
Solving the system
Hf (x)σ = ∇f (x)
(37)
∇f (x + σ) = 0 and is the minimizer of equation (35). Since this
f (x) we are not guaranteed that solving (37) will
give us the exact solution to min f (x). This is why the Newton method is an
iterative method, updating x in each iteration by adding the σ computed in
thus solves
is just approximations of
(37), till it converges towards a solution. The Newton method has, in most
problems, a quadratic convergence rate, when given a good initial point
When presented with a bad choice of
x0 ,
x0 .
there is no guarantee that the
Newton method will converge at all. When given good starting points, the
Newton method won't need a line search method as the newton update gives
not only the direction but also the size of the step. To improve the methods
robustness towards bad starting points, one can alter the newton update
so that the update vector
σ
is weighted by a scalar
α.
This scalar is often
referred to as a step length, and it can be computed by a line search method
such as the back-tracking algorithm. The altered newton update would then
be
xk+1 = xk + αk σk .
This is known as a damped Newton method.
28
5.3
xk
5
OPTIMIZATION
= initial guess
while(not done)
xk = xk − Jf (xk )−1 f (xk )
check if done
end
Figure 15: Pseudo code for the Jacobian inverse algorithm
5.3
The Jacobian inverse method, also known as Newton-Raphson, is a simplied version of the general Newton method without the second order Taylor
expansion, thus disregarding the Hessian matrix.
When solving a unconstrained linear system:
fi (x) = 0
for
i = 1, 2, . . . , m
one has to solve
m
(38)
simultaneous equations. Performing a
rst order Taylor series expansion gives us:
fi (x) ≈ fi (xk ) + fi0 (xk )(x − xk )
(39)
fi (x) = 0 which would require determining the inverse
−1
function fi (x), we can solve:
so instead of solving
fi (xk ) + fi0 (xk )(x − xk ) = 0
where the solution
x
(40)
can be isolated:
fi (xk )
fi0 (xk )
x = xk +
(41)
Since we have reformulated the original problem the
x
in equation (41) can
not be expected to be the exact solution to equation (38). Instead equation
(41) is used as an update step in an iterative method of the form illustrated
in gure 15, where
f (x)
is expanded to include all
is a matrix of the rst partial derivates of
Jacobian of
f
at
x,
m
equations and
Jf (x)
this matrix is called the
f.
The termination criteria can be a variety of termination , e.g. a xed number
of iterations, an absolute e.g. the distance from end eector to the goal or
a relative measuring the rate of change.
that a bad choice of initial value of
rather than converge.
xk
One drawback of this method is
might cause the algorithm to diverge
However no method is known to guarantee a good
initial value, which brings us back to the termination condition. When well
chosen, the termination condition can ensure that the algorithm won't loop
29
5.4
Quasi Newton methods
5
OPTIMIZATION
indenitely.
Inverting a matrix is an expensive operation so alternatives has been suggested, one is to solve the system
Jf (xk )(x − xk ) = −f (xk )
but for large
systems this is still expensive. A second alternative is using the transposed
Jacobian
Jf (x)T
instead of the inverse, this is yet another approximation of
the original problem which is so widely used that it will be described shortly
in its own section
5.3.1 The Jacobian transpose method
Since the Jacobian matrix is usually not square, inversion is often not possible, one simple and widely used alternative is transposing the matrix instead.
This has led to a variant of the Jacobian method called the Jacobian transpose. the greatest advantage of this method, is the fact that no singularity
issues arise, since no inversion takes place.
This and the fact that trans-
posing a matrix is both faster and simpler than inversion, has led to many
implementation of the Jacobian transpose method. The method is similar
to the original Jacobian inverse in all respects apart from the approximation
of the inverted Jacobian, which is why it would be folly not to implement a
version of this method when we have the Jacobian inverse.
5.3.2 The Pseudo inverse
A much better approximation of the inverse of the Jacobian is the pseudo
inverse
J+
dened in one of three ways depending on whether the system
is over determined ,under determined or regular.
In the regular case the
inverse is taken directly in the over determined case the pseudo inverse takes
the following form:
J + = (J T J)−1 J T
(42)
in the under determined case it takes the form:
J + = J T (JJ T )−1
(43)
it can be shown that the pseudo inverse is a least squares approximation to
the inversion, this is beyond the scope of this text though. Finally it should
be noted that the pseudo inverse does not solve the problem of singularity.
since if the matrix
5.4
JT J
or
JJ T
is singular, the inverse is still undened.
Quasi Newton methods
The main concern when constructing a real time inverse kinematics solver, is
computational complexity. In order to label a solver real time it has to supply
at least 25 fps, not just when running on a supercomputer but also on most
30
5.5
The BFGS algorithm
5
OPTIMIZATION
commercial PC's. For this to be accomplished, we need to choose the best
algorithm for the main component of the solver, the optimization algorithm.
A Quasi-Newton algorithm is based on Newton methods, in that it also
searches for a stationary point, a local minima. In Newton methods these
stationary point are found using line search algorithms and by computing the
Hessian matrix for each point along the search direction. The computation of
the Hessian matrix is a computationally heavy operation, as is the inversion
of the Hessian needed in the Newton update step. Enter the Quasi-Newton
methods, these methods excel in never computing the exact Hessian, only
approximations of the Hessian. Some methods extends this to approximating
the inverse Hessian thus removing the expensive matrix inversion in the
update step.
The Quasi-Newton method we've chosen to implement for this project is the
BFGS algorithm as it is presented in [13], however an important reference
has been the version described in [16], a slight alteration of the original
algorithm presented i 1970 by Broyden, Fletcher, Goldfarb and Shanno.
5.5
The BFGS algorithm
As mentioned earlier, the Quasi-Newton methods mainly dier from ordinary
Newton methods in the use of an approximated Hessian matrix as opposed
to a computed Hessian. How the Hessian is approximated, is therefore one
of the main dierences between the various Quasi-Newton methods.
The BFGS method updates the inverse Hessian by applying the following
formula:
Hk+1 = Hk +
y T Hk yk
1+ k T
σk σkT − σk ykT Hk − Hk yk σkT /σkT yi
σk yi
(44)
It maintains existing information of the objective function, while also adding
recent acquired knowledge about the development of the objective function.
The latter is by incorporating
σk
and
yi ,
which is the step taken and the
change of gradients during the k'th iteration.
The formula is derived by
imposing three conditions on the updated inverse Hessian
Hk+1 :
1. The updated matrix must remain symmetric and positive denite
2. The updated matrix must satisfy the secant equation
3. The updated matrix must be close to the previous update
x∗ , f (x∗ ) is twice contin∗
3
Hessian of f (x ) is symmetric ,
We assume that within a close neighborhood of
uously dierentiable which means that the
therefore we will require that the approximated inverse Hessian also is symmetric. The Hessian is constructed of the second partial derivatives of the
3
For further elaboration on Hessians see [10]
31
5.6
5
OPTIMIZATION
object function, this means that the Hessian contains information about the
curvature of the object function at a given point
x∗ .
When the Hessian is
positive denite it means that in a small neighborhood of
tion will increase meaning that
x∗
x∗ , the object func-
is a local minimum of the object function.
Since the inverse of a positive denite matrix is also positive denite, we will
require that the approximated inverse Hessian also is positive denite.
By second order Taylor expansion of f, rearranging and short handing the
notation one ends up with the secant equation, see [13]:
Bk+1 ρk = yk
(45)
Bk+1 is the approximated Hessian, however we are approximating the inverse
Hessian and therefore we need to enforce the following:
Hk+1 yk = ρk
(46)
Compliance with all three conditions can be achieved by minimizing
Hk k
subject to
H = HT
4
and the secant equation (46).
kH −
When using the
weighted Frobenius form , the unique solution to this minimization problem
is (44).
5.6
Up until now we have described how to solve the unconstrained optimization
problem.
However since we are dealing with IK, whose nature demands
constraints on joints, we will have to address this problem too.
There are two major groups of constraints that invariably presents itself
when dealing with IK. The rst is joint limits which work on the individual
DOF of a joint, the second group is global constraints, imposed by external
objects in the scene, or by the user to add realism.
Joint limits take the form of inequality constraints where a given variable
xi
is constrained by a lower and an upper bound.
li ≤ xi ≤ ui
where
li
and
ui
(47)
are lower and upper bound respectively. An example of a
joint limit is shown in gure 17.
Global constraints are a more diverse lot. Global constraints can be equality
constraints on e.g. position, they could also be inequality constraints constraining a given bone to lie on one side of a plane, or orientation constraints
forcing a bone to have a certain range of orientations.
The knowledge about the dierent types of constraints makes it possible to
use tailored approaches to their solution.
4
See [13]
32
5.6
5
OPTIMIZATION
01:Init Hessian
02:Check if initial point is a Kuhn-Tucker point
03:
While point is not a Kuch-Tucker point
04:
if q'th constraints is obsolete
05:
Drop q'th constraint
06:
Update the Hessian
07:
else
08:
Use line search to find next feasible point
09:
if most tight constraint becomes active
10:
Add constraint
11:
Update the Hessian
12:
else
13:
Update the Hessian by either BFGS or DFP method
14:
Check if current point is a Kuhn-Tucker point
15:Return when Kuhn-Tucker point is found
Figure 16: Outline of the BFGS algorithm as presented in [16]
5.6.1 Lagrange Multipliers
Solving a constrained optimization problem is often far more complicated
than solving an unconstrained problem, so if we can turn the former into the
latter and solve this, we should be better of.
First we dene the problem to be minimized:
min
subject to
where
m
f (x, s)
ci (x) ≥ 0, i = 1, 2, . . . , m
(49)
is the number of constraints. Inequality constraints is turned into
equality constraints by adding a slack variable
min
subject to
Dening
(48)
s2i ≥ 0
f (x)
ci (x) + s2i = 0 i = 1, 2, . . . , m
(50)
(51)
c = (c1 , c2 , . . . , cm )T , s2 = (s21 , s22 , . . . , s2m )T , λ = (λ1 , λ2 , . . . , λm )T
and the Lagrangean function
L(x, s, λ) = f (x) − λ[c(x) + s2 ]
the claim is that minimizing (52) is equivalent to solving (50).
(52)
Accepting
this claim for now, we rst will look at what happens when minimizing (52).
33
5.6
5
OPTIMIZATION
Figure 17: The joint limit of an elbows single DOF
The optimality condition states that at an optimal point
∇f (x∗ )
= 0,
∇L(x, s, λ) =
∇L(x, s, λ) = 0
An interpretation
L(x, s, λ)
∂L ∂L ∂L
,
,
∂x ∂s ∂λ
(53)
to hold the following must hold
∂L
= ∇f (x) − λ∇c(x) = 0
∂x
∂L
= −2λi si = 0, i = 1, 2, . . . , m
∂si
∂L
= −(c(x) + s2 ) = 0
∂λ
of λ is extracted from (54), where λ can
λ=
λ
the gradient
so let us analyse the gradient of
for
x∗
(54)
(55)
(56)
be isolated
∂f
∂c
is thus a measure of the rate of variation of
(57)
f
with respect to
c.
Returning to the claim that
min L(x, s, λ) = min f (x)
. let us rst show that
∗
If x is a minimizer of
min f (x) ⇒ min L(x, s, λ):
f (x) constrained by (51), then
c(x∗ ) + s2 = 0
(58)
L(x∗ , s, λ) = f (x∗ ) − λ[c(x∗ ) + s2 ]
(59)
giving
∗
= f (x ) − λ(0)
(60)
∗
(61)
= f (x )
34
5.6
5
OPTIMIZATION
min f (x) ⇐ min L(x, s, λ) is shown by looking at the partial
∂L
derivative of L(x, s, λ) with regards to λ,
∂λ . Optimality conditions require
the partial derivatives of L(x, s, λ) are equal to zero, see equation (56). Since
The reverse
∂L
= −(c(x) + s2 ) = 0
∂λ
then we know that (58) holds at
x∗
(62)
and that once again
L(x∗ , s, λ) = f (x∗ ) − λ[c(x∗ ) + s2 ] = f (x∗ ) − λ(0) = f (x∗ )
given that the minimizer of
∗
to c(x )
+
s2
L(x∗ , s, λ) is also the minimizer of f (x∗ ) subject
= 0.
The benet of solving an unconstrained problem versus the original problem,
must be compared with the cost of expanding the number of variables by
2 × m,
since we're no longer minimizing over
x
but also over
s
and
λ.
For more on Lagrange multipliers see [14].
5.6.2 Karush-Kuhn-Tucker conditions
When searching for an optimal solution to a constrained optimization problem, one needs to be able to tell whether a given point is a (local) optimal
solution(hereafter solution). The Karush-Kuhn-Tucker conditions (hereafter
KKT) are a set of necessary conditions, which need to be satised at a solution. Since they are only necessary conditions we can not be sure that a
point which satises the conditions is an optimal solution, but any point not
satisfying them we can discard as being not optimal solutions.
The KKT
conditions are also known as rst-order condition, since they only take the
rst-derivative into account when checking for optimality.
The KKT conditions are an application of the Lagrangean method, see 5.6.1
on page 33, exploiting the properties of the Lagrange multipliers and the
behaviour of the gradient
∇L(x, s, λ),
equation (53), at a stationary point.
For convenience, we will restate the partial derivatives of the Lagrangean
function.
∂L
∂x
∂L
∂si
∂L
∂λ
= ∇f (x) − λ∇c(x) = 0
(63)
= −2λi si = 0, i = 1, 2, . . . , m
(64)
= −(c(x) + s2 ) = 0
(65)
Deriving the necessary conditions starts with equation (64).
The set of equations of (64) describes the relationship between
•
si
and
λi
λi 6= 0 then si = s2i = 0, meaning that inequality constraint ci of the
original problem f (x) at this point would be an equality constraint
if
35
5.6
•
if
s2i > 0
then
λ i = 0,
5
this means that inequality constraint
original problem has not yet reached its limit,
value of
OPTIMIZATION
ci
ci
of the
is not aecting the
f (x)
Combining equations (64) and (65), we get
λi ci (x) = 0, i = 1, 2, . . . , m
(66)
λ 6= 0 then s2i = 0 and by (65) so is ci (x, on the
2
other hand when si > 0 then λi = 0. Equation (66) combines the check of
these two conditions in one (or conceptually m) equation(s). The Lagrange
multipliers, as λ is known as, must all be nonpositive at an optimal solution
since we know that when
when the problem is a minimizing problem.
Uniting these observations gives the following four conditions
Any optimal solution to
λ ≤ 0
(67)
∇f (x) − λ∇c(x) = 0
(68)
λi ci (x) = 0
(69)
c(x) ≤ 0
(70)
f (x)
will satisfy the KKT necessary conditions,
but the reverse is not necessarily true, any
x
satisfying the KKT necessary
condition is not guaranteed to be anything more than a stationary point. In
order to these conditions to be sucient as well, both the objective function
and the solution space has to be convex (when minimizing). Since convexity
of functions and solution spaces is beyond the scope of this report, we will
refer to [14] for more on this subject.
5.6.3 The simple approach
The simplest approach to imposing constraints on a problem is a projection
of the solution unto the feasible region.
Welman [15] actually favors this
approach even though he admits it is discouraged in most optimization literature.
The inherent problem in the simple projection method is that since we solve
the problem as if it is unconstrained, and then afterwards projects the solution unto the feasible region, we cannot know whether or not the projected
solution is a minimum of the constrained feasible region. It is however a very
simple solution to a complicated problem, and even though no theoretical
foundation is supporting this, it seems to work adequately as long as the
constraints are of a certain type e.g. joint limits.
5.6.4 Active Set Methods
Active set methods are based on the idea that if we know all the active constraints i.e. those that are constraining the solution at the optimal solution,
36
5.6
5
OPTIMIZATION
we can use only these constraints in our calculation of a solution. Consider
the minimization problem
min
f (x)
subject to
where
E
(71)
ci (x) = bi i ∈ E
(72)
ci (x) ≥ bi i ∈ I
(73)
is the set of equality constraints and
I
is the set of inequality con-
straints. The i'th constraint is said to be active at
constraints are thus always active.
x∗
if
ci (x∗ ) = b1 ,
equality
The problem with this approach is to
determine which constraints are active at the optimal solution. Inequality
constraints will have to be iteratively added to and removed from the active
set as the solution moves around the feasible region towards a solution.
The core of an active set method is the building of a working set, based on a
number of "educated guesses" on the active constraints, followed by iterative
adding and subtracting constraints, until a solution is found.
For a formal description we refer to [13].
5.6.5 The gradient projection method
One of the problems with active set methods, is that the active set changes
slowly, typically adding only one constraint to the set per iteration. When
the problem is structured as
f (x)
min
subject to
where
li
is the i'th lower limit,
ui
(74)
li ≤ xi ≤ ui
is the i'th upper limit and
xi
is the i'th
variable. Then there is a simple and eective method, which will update the
active set rapidly.
The approach is based on the fact that the type of constraints described in
(74) denes what can be thought of as a box enclosing the feasible region.
Figure 18 shows this, extending the example from section 5.1.2 on page 26
The constraints in (74) are exactly the constraints imposed by joint limits
since these only work on one DOF and typically sets an upper and a lower
limit on these.
If we stopped here, this approach would be little more than an elaborate
version of the simple approach mentioned in section 5.6.3. The method goes
on to nd a Cauchy point in the constrained feasible region. A Cauchy point
is an intersection of two constraints or one constraint and the objective function, thus ensuring that a (local) minimum of the constrained feasible region
is found. A formal description of Cauchy points is beyond the scope of this
brief description. (se below).
37
5.6
5
OPTIMIZATION
Figure 18: Plot of the objective function for a 2 DOF kinematic chain. The
joint variables are plotted along the horizontal axis. Notice the box shaped
feasible region dened by the constraints.
Given a problem where all constraints are joint limits we could solve it eectively using this approach. For a more in depth description of the method,
and of Cauchy points, the reader is referred to chapter 16.7 of [13], on which
this section is based.
38
6
6
IMPLEMENTATION
Implementation
In this section we describe the developed program, and try to explain some of
the issues that may arise for someone implementing a similar program. The
IK branch of the OpenTissue svn repository
[5], and includes the les inside the path $OpenTissue$/OpenTissue/kinematics/.
source code can be found in the
The walk through will be quite brief, and we direct the interested reader to
the source code for a more in depth understanding of the internal workings.
This is meant to give a general overview, not an implementation cookbook.
On a general note, we have implemented the system using the meta library
OpenTissue [4]. Where possible and practical, we have tried to comply with
the coding paradigms of OpenTissue to ease future integration of our code
with OpenTissue.
However since the focus of our project have been IK and not coding style,
there are several areas where a signicant clean up has to be carried out,
before the code could be included in OpenTissue.
OpenTissue is a cross-
platform library. Our solution however has only been tested on the Microsoft
Windows XP platform using Visual Studio 2005 SP1. Whether the source
code compiles and runs on other platforms is untested.
6.1
Overview of the program
The program consists of the following parts:
The Editor
The details of implementation as well as a short guide of use,
is described in details in section 6.2.
The solvers
The solvers are the core of the program, and the most the-
oretically challenging.
For a thorough explanation of the theory see
section 5 on page 24.
Section 6.3 on the following page will give a
more practical explanation, pertaining to the implementation of such
solvers.
Data structures
We make use of a couple of specialized data structures,
section 6.4 on page 41 lists these structures.
6.2
The Editor
We have constructed an editor based on the OpenTissue GLUI application
template. The editor allows us to manipulate constraints in a seamless manner. For the purpose of easing testing and debugging we also added controls
for changing various visualization related settings, including toggling skin,
bones and end eector visibility. By utilizing the OpenTissue On Screen Display (OSD), we can supply runtime data feedback and program information
39
6.3
The solvers
Figure 19:
6
IMPLEMENTATION
Our user interface for manipulating constraints and changing
visualization options
such as frame rate, currently selected bone and which method of optimization is currently active. An example of the GUI is shown in gure 19. The
embedded display is a perspective view of the 3D world used for visualization. In the display we show the results of our IK computations, character
model, skeleton and bones, coordinate systems, plane grid for orientation
reference as well as On Screen Displays.
We visualize the skeleton by iteratively drawing the individual bones using
the DrawBone and DrawFancyBone utilities from OpenTissue. For a realistic looking character visualization we use the built in skinning feature, which
draws the surface (i.e. the skin) of the character. Examples are shown in
gure 20.
When manipulating the constraints and bone weighting active
bone can be selected using either the so called "spinner" GUI control, or by
iterating through the bones using the keyboard. Since the bone selection is
merely an index for the internal skeleton bone array, the user has no means
of determining which bone is actually being controlled. As a result we apply
a very clear distinctive visual style to the bone being manipulated by scaling
up and changing the color of an OpenTissue bone draw procedure. In the
skeleton to the left in gure 20, the active bone is the rightmost thighbone.
6.3
The solvers
At present two solvers are implemented.
The object structure is simple
inheritance. A base solver implements the basic functionality, such as ini-
40
6.4
data structures
Figure 20:
Visualization of 1.
6
Skeleton, 2.
IMPLEMENTATION
skinned character, 3.
both.
Notice the thick black visualization of the active bone in the leftmost image.
tialization of the chains, see 6.4.
The specialized solvers implement one
optimization algorithm each, i.e. Jacobian inverse and BFGS. Both solvers
are presently implemented as classes which hold information of the current
skeleton on which it works. This is not a very generic approach, but it has
the advantage of making the solvers more simple. it should be noted that
we have implemented the Jacobian transpose as a variation of the Jacobian
inverse. this has mainly been done out of curiosity, and because it is such a
simple modication of the inverse method.
6.4
data structures
The following data structures are implemented in the system.
•
Chain holds one IK chain, and implements the dierent functions necessary to access chains, such as iterators.
•
Constrained bone is an extension of the bone structure, found in OpenTissue [4]. It incorporates the ability to constrain the bone directly as
well as containing information on lower and upper bounds, accessible
by e.g. the solvers.
6.5
constraints
Only one constraint method has been implemented. This is the simple projection method described in section 5.6.3 on page 36. the reader should refer
to this section for an explanation of the method.
41
6.6
6.6
optimizing
6
IMPLEMENTATION
optimizing
The code should be seen as a proof of concept code, meaning that we have
not used any of our resources on optimizing the code. It could be argued
that since our project concerns itself explicitly with real-time execution, it
should also be optimized accordingly. However the resources spent on such
an activity was, we felt, better used on making the method work.
42
7
7
EVALUATION
Evaluation
This section describes how we wish to verify that our implementation is
correct and functional. We will evaluate our implementation with regards
to both accuracy, resource usage, benchmark speed and esthetic quality(i.e.
realism). In section 8 on page 46 we discuss the results we have obtained.
The evaluation falls in three parts. First we test whether our solution meets
the goals we have dened for it.
Second we test the performance of our
solvers. This is done through a variety of benchmarks and by measuring the
resource usage. By doing so, we seek to give an overview of the speed and
the level of interactivity at dierent congurations. Also, we will compare
the accuracy and resource usage of the BFGS and the Jacobian Inverse to
analyze the performance of our implementation in greater detail. Finally we
will evaluate the level of realism obtained by our implementation.
7.1
Implementation requirements
The system should be interactive in the sense that it spends less than
1
15 of
a second on computing a pose for a given number of DOF and constraints.
Obviously this is hardware-dependent so we will test it on dierent platforms.
The BFGS method, as well as the Jacobian Inverse, is meant to minimize
the distance from the end eector to the goal position. Over time, the distance should be monotonously decreasing.
However, in the case that the
solver exceeds the maximum number of iterations, the distance might not
be minimal. We wish to see if this happens, and if so, how often. Since we
aim at producing realistic results, we do not want sudden large variations
in movement. As a result the dierence in parameter vector from one time
step/iteration/solution to another should be
as small as possible.
We calcu-
late the 2-norm of the distance vector, which in eect, should be as small
as possible. Since the size should be dependent on the step size, we need to
verify that it is.
As we mention in section 1.2, the Jacobian Inverse is implemented in two
ways: the transpose and the pseudo-inverse.
Since both of these methods
has been implemented we need to test which is the most ecient and which
produce the most visually appealing results.
7.2
Even though the BFGS method has a higher CPU and memory usage than
the Jacobian Inverse, it should be faster as it should have superior convergence due to its second order nature.
Additionally, the BFGS should be
more accurate due to its global solutions.
Also, the high level of freedom
in constraint manipulation allowed in the BFGS, should help provide the
43
7.2
7
EVALUATION
most esthetically pleasing solutions of the methods in question. We intend
to evaluate the esthetic properties of the BFGS by comparing it to animation
done with the Jacobian Inverse as well as motion capture based character
animations (see section 7.3).
7.2.1 Constraints
When doing explicit constraint enforcing, the limitations to the solutions
done by our solvers should be visible. Since the solutions does not actually
incorporate the constraints, this method should be slower than the gradient
constraints. If we are able to apply gradient constraints, the method should
set limits on the search direction, eectively reducing the sample space. Provided that we have an implementation of the constrained BFGS method at
the time of testing, there are some things we wish to evaluate. We expect
the number of active constraints to have signicant impact on the speed of
updating the approximated inverted Hessian matrix. By enforcing a series of
equality constraints, on a simple skeleton chain, we can xate the number of
active constraints per bone. Increasing the number of bones in the skeleton
should result in an noticeable decrease in speed. We obtain a measure of the
per-constraint resource usage which is essential for predicting the resource
usage for a specic conguration. This allows us to dene limitations on the
number of constraints feasible, still enabling the implementation to operate
at interactive speeds.
7.2.2 Dening constraints
For constraining our skeleton we need to either manually dene the constraints, calculate them in some way or import existing data.
Manually
dening would involve setting 1-6 DOF per bone for more than 30 dierent
bones. This would require a lot of time and testing and since it is quite unlikely to result in realistic animations it is not a feasible solution. If we want
to create realistic movements we need realistic constraints.
Therefore we
will obtain constraints by reading character animation movement thresholds
and calculate the constraints based on these values. This allows for simple
extraction of hopefully usable constraint values for our skeleton, and can be
based on the actual animations we wish to use for comparison. Whether or
not these constraints will result in life-like movement is hard to say but will
be put to the test.
In addition to import routines we have constructed a
GUI for manipulating our constraints allowing us to do manipulation of the
constraints interactively at runtime (see section 6.2).
44
7.3
Evaluating esthetic quality and realism
7.3
7
EVALUATION
Our implementation needs to comply with a set of technical requirements
but also has to be visually realistic. Since we aim at producing result of high
esthetic quality our implementation needs to produce realistic or at least
plausible looking animations. The most intuitive way of evaluating the quality in terms of realism is to make a comparison with something known to be
correct. For that we need real world data such as motion capture data. We
could use hand modelled animations, however there are several important
properties of such animations which makes them unsuitable. First o, the
world of animation is littered with what is commonly known as cinematic
reality. As a result, hand modelled animations may not be particularly realistic or even possible in real life. Furthermore, animators do not necessarily
agree on what is realistic and no general rules exists for hand modelled animations. In eect, subjective realism is not very useful since our evaluation
might dier signicantly when comparing the work of various animators.
Most motion capture on the other hand is by denition realistic since it is
in essence a sampling of real human motion. We want to present a working
basis for a modeller and so we nd that the realistic motion of a human is a
suitable starting point.
7.3.1 Obtaining motion capture data
We have chosen to make our own motion capture dataset since this would
free us from any considerations regarding property rights. The data set has
been made in the simplest possible way by recording a series of video clips
of humans moving and then transforming this into 3D using Blender [1].
While not the easiest or most precise way it is by far the least complicated
when it comes to specialized equipment. Furthermore, since the IK and the
motion capture animations are performed on the same models and hence
the same skeletons, this gives us an optimal foundation for comparing the
results.
Although not an inherent part of the project a documentation of
the process of creating the motion capture dataset has been included.
It
may be of interest to the reader to see this process described as a means of
evaluating the correctness of our work. The detailed description of how the
motion capture dataset was made is included in section 3 on page 12.
We use two hand modeled skeletons, a human male and a human female.
These models have a number of associated animations based on motion capture data acquired as described in Appendix 3. We will try to reconstruct
the motions of the models as precisely as possible with only the positions of
the end eectors and the constraints on the skeletons.
45
8
Computer
BFGS
JI
1
24-30
15-20
2
36-40
20-25
3
36-43
19-24
4
28-36
18-22
RESULTS
Table 1: Frames Per Second(FPS) for four dierent computers
8
Results
In this section we describe the results we have obtained when carrying out
the evaluative tests. In some cases we were unable to perform the test we
wanted, since time limitations did not allow us to implement every detail described in 1.2 on page 6. Unfortunately we did not have time to implement
the constrained BFGS nor the gradient projection method. This means that
our intension of testing these functionalities will not be realized.
Also we
probably will not obtain the visual results we hoped for by using the constrained solvers. We did however implement the simple projection method
allowing us to constrain the resulting poses.
8.1
Test results
First we test if the system runs interactively. For all the computers we ran
both the BFGS method and the Jacobian Inverse. We congured the termination criteria to make sure that they would not converge. We manually
read the frame rate from the On Screen Display. We have tested our implementation on four computers with the following hardware congurations:
Computer 1
Intel PM740 1.73GHz, 2GB RAM, GeForce GO6200 64MB
Computer 2
AMD Athlon 64 3400+, 1GB RAM, Radeon X800 256MB
Computer 3
Intel Dual Core TM2 T5500 1.66GHz, 1GB RAM, Radeon
X1600 256MB
Computer 4
Intel Dual Core T2400 1.83GHz, 1GB RAM, GeFOrce Go7400
128MB
These machines range in frame rate from 24 to 43 fps for the BFGS and 15
to 25 for the Jacobian inverse. See table 1.
In table 2 is an example of time usage on machine 1 when running 1.000
iterations of the Jacobian Inverse, Jacobian Transpose and the BFGS. The
Jacobian Transpose is roughly 6 times faster than the Jacobian Inverse. The
Jacobian Inverse is 10 times faster than the BFGS.
46
8.2
8
Jacobian Inverse
RESULTS
1.3
Jacobian Transpose
BFGS
0.23
12.9 seconds
Table 2: Time spent for each method solving for 1000 iterations, which is
also the number of milliseconds per iteration.
This was to be expected since what we measure here merely is the average
time usage of the methods.
8.2
Our results show that the BFGS is faster the Jacobian inverse in spite of being much more complex. However, these two methods are inherently dierent
and not directly comparable with respect to convergence speed and frame
rate. If we allowed the BFGS a mere 5 additional iterations the frame rate
would decrease signicantly, making the Jacobian inverse the faster method.
Also the line search step-size computation aects the number of iterations
used by the BFGS since the rate of convergence is much faster for the BFGS.
In the following we will present example gures which has been created in
matlab from unmodied output data, taken directly from our implementation, using the OpenTissue logging facility. The tests are done by positioning
the goal position 100 unit away from the end eector of the chain, and solving the IK problem only once. As a measure of quality, we plot the
distance from the goal position to the end eector.
.
Figure 21: Nicely decreasing Jacobian Inverse
47
squared
8.2
8
RESULTS
Figure 22: Chaotic Jacobian Transpose convergence/divergence example
We have tested the convergence properties of the BFGS and the Jacobian Inverse by forcing them to run 1.000 iterations in a single solve. Both
methods does in fact minimize the distance at some point. The Jacobian Inverse does however diverge after reaching a local minima. The BFGS on the
other hand does the job remarkably well, even though it has a slight spike in
distance. See an example of the results in gures 23 and 24. In this test we
had no relative stop criteria in the Jacobian Inverse method, which is quite
obvious, since the method clearly diverges after 400 iterations. When adding
a rst order nite dierence threshold check, the Jacobian Inverse does decrease monotonously as can be seen in gure 21.
Though the change in
parameter vector is rather small from one iteration to another the Jacobian
Inverse presents some key problems.
First the solutions does not visually
comply with our needs, second the end eector is typically pretty far from
the goal position. Figure 22 shows an example of the Jacobian Transpose,
the use of which is particularly troublesome.
Notice how the distance is
ickering which would suggest that the resulting poses might neither be very
reliable nor visually appealing.
In our experience this is in fact the case,
and we mention this test for completeness only.
The use of the Jacobian
Transpose is not a viable solution for us. However, of the methods we have
implemented it is by far the fastest way of solving the IK problem.
8.2.1 Constraints
We have tested the simple constraints by making a number of poses where
one or more bones have been constrained, with our method.
In Figure 28 on page 54 an example of testing our constraints are shown.
What we can derive from this is that the constraints although simple, makes
48
8.3
Figure 23:
8
RESULTS
Jacobian Inverse convergence over 1.000 iterations.
Non-
monotonously decreasing.This conguration had the goal out of range which
prevented the absolute stopping criteria from being met
it possible to constraint the pose of a gure.
more examples of poses are
shown in appendix A on page 57. All the constrained poses are made with a
combination of constraining and weighting the joints. Since the editor is not
a nished commercial product, but rather a tool for testing , it is possible to
make complicated poses only with some diculty. Nonetheless interaction
with both constraints and weight are possible and not too complicated.
8.3
Since we aim at producing realistic results, we will now compare the BFGS
to the Jacobian Inverse with regards to visual quality. This part of the testing will not be as elaborate as we had initially planned, this is due to the
fact mentioned in 8.2.1 on the preceding page.
Figure 26 on page 52 and 27 on page 53 shows how the two methods solve a
conguration with the end eector situated in the head and the goal placed
in front of and slightly to the side of the head. The expected pose would be
a slight bend forward of the spine. Much as the one shown in 30 on page 58.
however since no constraints or weight are applied both methods come up
with much dierent poses. The Bfgs method gives a pretty fair pose, apart
from the legs which has been ung backwards. This is the result of not xing
the pelvis, and as the legs are calculated with forward kinematics relative
to the pelvis joint, the look of the gure diers much from the desired pose.
49
8.4
Concluding remarks
8
Figure 24: BFGS convergence.
RESULTS
Again the goal is out of range preventing
the absolute stopping criteria from being met. The method actually nds
an optimal (local) solution
No constraints are necessary to solve this. It could be solved with weights
alone just by setting the pelvis joint weight close to zero.
The Jacobian method suers from graver problems though, and this could
not be xed without applying constraints to the spine links, to prevent them
from moving to far to the sides. The behavior in this simple test is symptomatic of the overall behavior of the methods, in all the (informal) tests
that we have run.
Several dierent poses has been made and some of these can be seen in appendix A on page 57.
The results from these informal tests are that it is
indeed possible to pose the gures in complicated yet realistically possible
poses.
8.4
Concluding remarks
Our results, even when applying our simple constraining, are not really comparable to the animations.
As for realism, it is hard to say whether the
character does in fact behave realistically in some ways. It seems that for
very specic congurations we can obtain some level of plausibility, though
only for a subset of the skeleton. Presumably, since we do not incorporate
suciently general constraining, our methods does not produce quite the
results we had hoped for.
50
9
CONCLUSION
Figure 25: Jacobian Transpose character solve example
9
Conclusion
These concluding remarks are meant as an overview of the goals fullled or
unfullled, and a description of what we have learned.
Where this project at rst was meant as a study of the inverse kinematics
problem, it has undergone a seamless transformation and is now in large
parts a study on optimization algorithms. This change of focus means that
not only have we gained a great amount of knowledge on where, why and
how inverse kinematics is applied, we are now also familiar with a wide range
of optimality solvers. Since the only course on optimization, the three of us
has attended was an introductory course. The attempts on understanding
the theory has therefore at times felt like an uphill climb. In spite of this,
5
we have been able to implement two dierent optimization algorithms , as
well as feel prepared to take on further work on optimization problems.
Combining this lack of theoretic foundations upon entering this project, with
the fact that our only previous acquaintance with inverse kinematic is based
6
on a minor project , one might argue that our original goals were somewhat
ambitious.
Even though we feel that we have accomplished much, there are still some
5
6
Three if counting the slight alterations resulting in the Jacobian Transposed
An
inverse
kinematics
solver
using
the
Hartenberg joints
51
Jacobian
Inverse
method
and
Denavit-
9
CONCLUSION
Figure 26: Jacobian Inverse character solve example
of our original goals that we have not reached. Evaluating the quaternion
representation versus the Euler representation, comparing our inverse kinematics with motion capture data and implementing general constraining of
the system, this is the three goals unfullled.
When comparing the three goals not met, to the vast amount of work put
in both implementation and theory, we feel that this project as a whole is a
success.
The nal result is a system that can handle simple joint limit constraints,
solving inverse kinematics for an articulated gure of 33 joints each with 6
DOF (even if we still have to do it one chain at a time). As extra features
we have implemented a GUI for the solver, which have eased the testing of
the system considerably. We have modeled two skins rigged to skeletons and
we have provided 3D animations obtained by means of motion capture. The
last two features are going to be made available for free to be used i future
animation courses or projects at DIKU, thus contributing to other students
future work.
52
10
FUTURE WORK
Figure 27: BFGS character solve example
10
Future work
Having worked both with IK and the numerical optimization techniques
used to solve IK, has opened a Pandora's box of possibilities for future work.
This section is a short introduction to some of the possible projects we could
choose to take on. Some of them are already being made real by members
of this group, some are merely ideas.
10.1
incorporating global constraints
Since we have only implemented a simple method for imposing constraints
on joint limits, it would seem natural to try and incorporate more general
constraints in the system. This was one of our original intentions, and one
that has not been forgotten.
10.2
Experiments with alternative optimization methods
Having worked hard on understanding the enormous wealth of methods available to solve optimization problems, and having seen how the IK problem
seems solvable by many dierent approaches, it is tempting to followup some
of these alternative methods.
Some of the possibilities has been briey mentioned in section 5. Any one of
these methods could be an obvious choice for future study.
53
10.3
Making the code fully OpenTissue compliant
10
FUTURE WORK
Figure 28: A pose obtained by constraining the shoulder joints in their initial
position, while moving both the hands. While the pose might not look very
relaxed, it is certainly possible.
This could also take the form of a comparison between two or more methods,
regarding their eciency, precision and so forth.
10.3
Making the code fully OpenTissue compliant
Since this project has been focused on the IK problem, there is a lot of work
to be done before the code is acceptable for inclusion in OpenTissue.
Some of the auxiliary parts of the program such as the GUI could probably
turn into a project in its own right.
10.4
Evaluating the Quaternion representation
It would be interesting to make a comparison on the eciency of the quaternion representation with the classical Euler representation.
The fact that OpenTissue did not include an rotation matrix based skeleton
data structure, made it infeasible to make that kind of comparison part of
this project.
The problem remains an interesting one and could quite easily be turned
into a stand alone project.
54
REFERENCES
REFERENCES
References
[1]
Blender,
http://www.blender.org, 2007. The Blender Foundation. 12,
14, 45
[2]
Cal3d, https://gna.org/projects/cal3d/, 2007. Open source project.
[3]
icandy, http://kinematics.icandy.dk/, 2007. icandy.dk.
[4]
OpenTissue, http://www.opentissue.org/, 2007. OpenTissue Library.
15
4, 15
6,
39, 41
[5]
Source code,
http://www.opentissue.org/websvn/, 2007. OpenTissue
Library IK branch. 39
[6] Erik B. Dam, Martin Koch, and Martin Lillholm. Quaternions, interpolation and animation.
Technical report, Department of Computer
Science, University of Copenhagen, 1998. 17
[7] Kevin G. Der, Robert W. Sumner, and Jovan Popović. Inverse
SIGGRAPH '06: ACM
SIGGRAPH 2006 Papers, pages 11741179, New York, NY, USA, 2006.
kinematics for reduced deformable models. In
ACM Press. 11, 19
[8] Martin F¥dor. Application of inverse kinematics for skeleton manipula-
tion in real-time. In SCCG '03: Proceedings of the 19th spring conference on Computer graphics, pages 203212, New York, NY, USA, 2003.
ACM Press. 10
[9] Keith Grochow,
Popovic;.
Steven L. Martin,
Aaron Hertzmann,
Style-based inverse kinematics.
SIGGRAPH 2004 Papers,
In
and Zoran
SIGGRAPH '04: ACM
pages 522531, New York, NY, USA, 2004.
ACM Press. 7, 11
[10] Michael T. Heath.
Scientic Computing, An Introductory Survey.
McGraw-Hill, second edition, 2002. 31
[11] Knud Henriksen and Kenny Erleben. Inverse kinematics using quaternions. Technical report, Department of Computer Science, University
of Copenhagen, 2007. 10, 18
[12] Kenny Erleben, Jon Sporring, Knud Henriksen and Henrik Dohlmann.
Physics based animation.
Charles River Media, 2005. 10, 17, 22
[13] Nocedal, J. and Wright, S.J.
Numerical Optimization.
Springer, 1999.
10, 11, 24, 26, 31, 32, 37, 38
[14] H.A. Taha.
Operations research: an introduction.
Inc., seventh edition, 2003. 24, 35, 36
55
Pearson Education,
REFERENCES
[15] C. Welman.
REFERENCES
Inverse Kinematics and geometric constraints for articu-
lated gure manipulation. Master's thesis, SIMON FRASER UNIVERSITY, 1993. 10, 36
[16] Jianmin Zhao and Norman I. Badler.
Inverse kinematics positioning
using nonlinear programming for highly articulated gures.
Graph., 13(4):313336, 1994.
9, 10, 24, 31, 33
56
ACM Trans.
A
A
IMAGES
Images
This section is a collection of images of poses computed by our Ik solver. It
is stated by each picture, which solver has been used and whether some or
al bones are constrained.
Figure 29: A skeleton of a walking pose seen from the front and both sides.
The pose has been obtained by, constraining the knee joints and placing the
feet.
57
A
IMAGES
Figure 30: An arm reaching for an end eector. the Bfgs solver was used.
the spine has been weighted so that the lowest weight are nearest the pelvis.
the shoulder has been constrained to prevent unrealistic behaviour. Notice
that only the chain going from the pelvis to the left hand has been posed
the rest of the joints are in their bind pose.
58

Inverse Kinematics With Constraints

Transcription

Similar documents

PSORIASIS- ARTHRITIS

Global Optimization Datasheet

skeleton warriors

Abstracts - Sodankylä Geophysical Observatory

Contents of this book

Supercharching_Category_Management_with_the_P

Elastomer Expansion Joints

Framing pyramids

ARTICULATIONS!