the perspective
(5)
d to the glasses,
sensors can be
(6)
a four-by-four
ngles and the
if the equations
parameters and
e distinguished:
rameters of an
f the projective
“an "Euclidean
the vector of
à p. Using these
homogeneous
quations equals
neters is in the
oncatenation is
s that instead of
t two letters are
ted as:
0 (7)
easurement. All
ps that belong
be groups of
main the same.
listinguished to
approaches:
e control points
sensors are not
nent of a point
=0 6
)
h, Tuceryan's
)bservers head.
Iso given in the
1 into account.
splay system is
(also known as
first iteration of
is often used to
pproaches. As
(9)
3. In the above two methods it is presupposed that all errors
can be subsumed to a image point error. In contrast to this,
it is also possible to try to explain all errors by a tracker
error. It will be shown in chapter 4 that there are
differences between these two perspectives.
V» 9 P EyDi 9 C SeEy 9 € soSe 9 €yoso 9 Xy = 0 (10)
4. The above techniques do not integrate the sensor and
control point errors. But sensor and control points have
also systematic, random and rough errors. Thus, the
mathematical model has to be extended to:
Vpj o P Eypi o ÉSeEy 9 Ésose 9 €woso 2 Xy, = 0 (11)
5. So far only a single tracking device assumed. An
additional second sensor may be able to control the first
one and detect errors of the first. But when using it, the
system of equations has to be extended by a set of
equations describing the constant connection between the
two birds. An arbitrary number of sensors can be added
this way. The equations are:
Vp; © Prypi © €sey 9 Ésosea ° €moso © Xwo = 0
(12)
EsoseB ° Éscases © Ésosea = 0
3.2 Object model
The implementation of a calibration algorithm that is open for
all above mentioned variations is difficult because of the
following three problems: Firstly, there is an huge amount of
parameters of different type that have to be updated in each
iteration step of the Newton method. Secondly, different types
of equations may occur (as seen in equation (12)). Thirdly, the
partial differentiates become long expressions due to the
multiple concatenation. If there is no modular structured
program used, all combinations of partial differentiates have to
be computed explicitly (this would be 27*2+18*3 expressions
for equation (12)). In the following it will be shown how these
problems can be overcome by object oriented design. The class
hierarchy of the described concepts can be seen in figure 6.
Problem of different types of mathematical objects: To
simplify the problem of updating the parameters in each
iteration, the parameters are encapsulated in a separate
mathematical object (mathObject) called Atom. The object
Atom can be used to store the type (unknown, observed,
constant) of the parameter as well as additional information
(residual, range of values). The hierarchical structure can be
mapped using vectors (mathObjectVector) of such
mathematical objects. The mathObjectVector itself is a
mathObject that contains the interrelations between the atomic
parameters (or even other mathObjectVector objects), e.g.
variances and co-variances. All other objects that compute the
value (of an operation or relation) or the partial differentiate
hold only references to these objects. Therefore, the values have
to be updated only once, in the Atom itself.
Problem of different types of equations: In general, a
mathematical model can be understood as a set of relations
(relation) between mathematical objects. Therefore, a relation
is a vector of mathematical objects (mathObjektVektor). E. g.
the equations of section 2.2. are such relations. Equations
belonging together have to be grouped to vectors of relations.
This is possible as a relation is itself a mathObjekt, too.
Problem of simplifying the partial differentiates: If several
operations are concatenated as in equation (4), the partial
differentiation with respect to a certain parameter would result
in long expressions. The whole expression must not be
computed explicitly, if the object model reflects concatenation.
That means that an operation can be reused. To meet this claim,
mainly a modification of the design pattern “ chain of
responsibility " described by [3] can be applied (compare figure
6): "Avoid coupling the sender of a request to ist receiver by
giving more than one object the chance to handle the request."
A operation can be understood as a mathematical object that
"builds" a relation between several mathematical objects. The
operation itself produces again a mathematical object. If each
mathObjekt has a well defined interface to return its value and
the partial differentiation, all mathematical objects may be used,
irrespective of their concrete specification (operation, relation
or mathObject), in any combination.
mathObject
+computeValue:mathObject
+computePartialDifferentiate:r
1
Atom
*computeValue:mathObject
+computePartialDifferentiate
ze
mathObjectVektor
-composite:mathObject
3
4
; Relation
B et Operation
ConcreteOperation ConcreteRelation
SpecialMathObjectVector
+computeValue :mathObject
+computeValue:mathObject :
+computePartialDifferentiate:rf |+computePartialDifferentiate:nf |+computePartialDifferentiate:n
*computeValue:mathObject
Figure 6. The main classes of the parameter estimation program.
—537—
