PII: SOOlO-4485(97)00058-4

Computer-Aided
&sign, Vol. 30. No. 3, pp. 199-204, 1999
0 1999 Elsevier Science Ltd. All rights reserved
Printed in Great Britain
0010~4495/99i$19.00+oo.oo

An open architecture approach

to kinematic analysis for
computer-aided embodiment
design
Aylmer L Johnson

components such as shafts, cranks, and links; these carry

pointers to appropriate design rules which, given a set of
externally applied loads, allow the software to determine
suitable dimensions
for their satisfactory performance.
Once the dimensions have been chosen, the components
are able to make direct calls to one of the new generation
of core solid modeller libraries*, to generate the resulting
solid model without user intervention. Use of the technique
thus simply involves describing a proposed design in terms
of functional primitives instead of geometric primitives, and
can be conveniently termed functional modelling.
For many mechanical designs, a major element of the
loading on each component comes from the inertia of the
moving parts within the design. This effectively makes
the loads a dependent variable in the problem: redesigning
one moving part for greater strength will cause additional
loads on the other parts, as the redesigned part will also have
a greater inertia. The resulting design process therefore
inevitably becomes iterative, though it is usually convergent
for conceptually feasible designs.
These factors have raised the need for kinematic analysis
software which functions in a similar way to the solid
modelling functionality
described above. Most kinematic
packages, such as Mechanicas Applied Motion are used
via a graphical user interface: the requirement
for this
analysis is that it must be accessed directly from the
functional
modeller itself. Specifically,
procedures
are
required which can define the kinematic model, accept
specified input motions,
and calculate
the resulting
accelerations
of all the moving parts. This information
must then be combined with the mass and principal inertias
of each part to calculate the positions and magnitudes of the
inertia loads. Finally, these inertia loads must be combined
with other external loads on the design, and the resulting
interface forces between the parts of the design must be
calculated.
The remainder of this paper describes the resulting
software, which has been named Promech, and explains
the approaches which have been used to realise this
specification.
It should be emphasised that the present
requirement extends only to analysing mechanisms whose
conceptual intent has already been explicitly stated: this
work therefore differs in its goal from that of researchers
such as Gelsey loor Joskowicz , whose principal aim is to

In addition to providing tools for the conceptual design of

mechanisms, kinematic analysis is needed for the calculation of
inertia loads in mechanisms during the embodiment phase of
design. The goal of creating a computer-aided
embodiment
generator has raised the need to package this kinematic analysis
such that it can be invoked directly, without the need for a separate

user interface. This paper describes a set of kinematic and dynamic

analysis procedures which have been developed for this purpose,
explains how they work, and discusses their significance in the
progress of computer-aided embodiment generation. 0 1998
Elsevier Science Ltd. All rights reserved
Keywords: functional modelling, kinematic analysis, dynamic
analysis

INTRODUCTION
Traditional
computer-aided
design has tended to focus
largely on recording the shapes of proposed designs, as
specified by the designer. Some significant advances have
now been made in the direction of allowing shapes to be
generated automatically: either through parametric design ,
or by allowing users to specify design rules to be applied
under specific, well-defined conditions2. A more long-term
line of research at the Cambridge Engineering
Design
Centre is attempting to tackle the problem of generalised
embodiment design: that is, the fleshing out of conceptual
solution to almost any type of mechanical problem such that
the components
are automatically
assigned dimensions
which will guarantee their ability to carry out their intended
functions.
The details of the approach, the problems which it has
raised, and the current solutions to those problems have
been extensively
reported elsewhere3-.
The technique
essentially involves describing the parts of a proposed
design in terms of commonly
understood
engineering

Engineering Design Centre, Cambridge University, Trumpington Street,

Cambridge CB2 lF2, UK

199

Open architecture

kinematic analysis:

infer the kinematic behaviour

physical shape of its parts.

A L Johnson

of a mechanism

from the

KINEMATIC INTERFACES
Designers who have attempted to specify three-dimensional
kinematic models will be well aware of the difficulty of
creating models which are not over- or under-constrained.
This difficulty is clearly made worse when (as in this case)
there is a requirement for the kinematic model to be
generated automatically from the initial, component-oriented,
description.
The approach to kinematic interfaces adopted in Promech
addresses this problem in two ways. Firstly, the kinematic
pairs between bodies are not specified explicitly by the user,
but are defined implicitly from the relevant features of the
two parts involved in the pair. For instance, if an offset
section of a crankshaft (i.e., a short length of shaft) is
connected to the big end of a connecting rod, a revolute
joint is automatically
implied: the combination
of a
cylindrical shaft and a cylindrical hole whose depth is not
negligible means that the joint must either be cylindrical or
revolute; and the crank webs at each end of the section of
shaft imply that the connecting rod cannot slide along the
shaft, making the joint revolute.
Secondly, the software has been written to make it easy to
relax some of the constraints implied by the joints, without
the need to re-specify the features of either part. For
instance, the connecting rod mentioned above might be
re-declared by the software to have a very short hole through
it, if the longer hole had the effect of over-constraining
it:
this effectively converts the revolute joint into a spherical
joint, without the need to redefine any physical aspect of the
bodies involved in the joint.
The kinematic pairs which Promech can currently handle
are made up from all possible combinations of the features
shown in Figure 1. A shaft element can be plain, or it can
have a circlip (to prevent axial motion) and/or a keyway (to
prevent rotation about its own axis). Likewise, holes can
either be shallow or deep, and in addition can either
The combination
rules are
be circular or slotted.

Groove

for Circlip

Keyway

08 nil
6 w

exceedingly simple: any type of shaft can be paired with

any type of hole. One of resulting combinations is trivial as
it implies a solid joint: the remaining 15 include five of the
six possible types of Lower Pair joints, plus 10 of the more
common types of Upper Pair joints found in mechanical
systems. Figure 1 shows these combinations
graphically,
and records for each pair the set of Joint Primitives which
are needed to describe it. The exact definition of the Joint
Primitives used by Promech is given in the next section.

SIMPLIFICATION OF THE KINEMATIC

CONSTRAINTS
Static constraints
As explained above, each combination of a shaft type with a
hole type gives a different kinematic pair. The analysis of
these 1.5 pairs is simplified considerably by specifying a
set of more basic kinematic constraints than the classic
pairs (cylindrical,
spherical etc.) which are used in the
literature 12. Packages such as ADAMS I3 and TLA14 have
already exploited
this finding,
and use seven Joint
Primitives to model their kinematic constraints. Promech
also uses seven Joint Primitives, but they have been defined
in a slightly different way so that they can be processed by
an even smaller number of sub-primitives, which have been
termed Vector Constraints.
The first step is to define four vectors for the shaft element
in each joint, and four for the hole element, as shown in
Figure 2. These vectors are held in terms of their respective
bodys local co-ordinate
system for storage, but are
converted to a common or global co-ordinate
system
when they are required for the kinematic analysis.
Vectors S and H define reference points on the centrelines
of the shaft and the hole, respectively: nominally, at the base
of the shaft and at the start of the hole. If the hole is circular
and a circlip is specified for the shaft, the requirement is
generated that the reference point on the shaft must be
coincident with the reference point of the hole.
Vectors S2 and H2 define reference directions on the
shaft and hole perpendicular
to their respective axes. If
the shaft has a keyway, the requirement is generated that
S2 must either point in the same direction as H2, or must at
least lie in the plane defined by H2 and Hl.
Finally, vectors S3 and H3 are defined as the cross
products of (Sl X S2) and (Hl X H2), respectively. This
creates a set of three mutually orthogonal directions for the
shaft and the hole, which are convenient for specifying the
Joint Primitives.
Table 1 shows the set of seven Joint Primitives used in
Promech, and gives a verbal and vectorial definition of each
of them. The final column of the table shows the number of
restraints (rotational or translational) which each of these

PLANAA
w

+A

$R

@A

$A

+A

@T

SPHERICAL

CPS

$A
a:
cD

Figure 1

200

4A

CYLINDRICAL
@p

Feature combination

REVCUTE
4s

PRISMATIC

and joint types.

+p

Figure 2

Vectors for shafts and holes

Open architecture kinematic analysis: A L Johnson

Table 1

Basic kinematic

constraints

Symbol

Description
Sliding constraint:
Axial constraint:

hole reference point on shaft base plane

hole reference point on shaft axis

Lateral constraint:
Crossing constraint:
Parallel constraint:
Twisting constraint:

= 0

(S - H)S2
(S - H)S3

= 0
= 0

(S - H).Hl = 0
(S - H).H3 = 0

shaft passes through slot line

(S - H) X H2)Sl

main axes parallel

Sl.H2
Sl.H3

shaft cant rotate about own axis

shaft axis parallel to plane of pocket

constraints imposes between the two bodies. Finally, the

cells in Figure 1 show which of these Joint Primitives is
required for each of the 15 kinematic pairs which Promech
currently allows.
The analysis can now be simplified still further by
observing the similarities
between the first three Joint
Primitives shown in Table I, and between the last three.
Promech carries out the position analysis5 of the mechanism
by means of a constraint matrix, the assembly of which is
carried out by just three procedures:

(1) ALIGN(V) which sets {(S - H).V= 0) and so carries

of 4S, ~#JAand 4L;

(2) CROSS which carries out the function of 4X;

(3) SETSQ(n,m) which sets {Sn.Hm = 0) and so carries
out the functions of 4P, 4T and 4R.The use of these
three vector constraints to analyse 15 types of kinematic
pairs compares favourably with, for instance, TLAs
use of seven Joint Primitives to analyse seven types of
kinematic pairs 14.

Driving constraints
In addition to the static kinematic constraints implied by the
joints between the various parts of the mechanism, so-called
driving constraints
must be specified to give it motion.
Promech currently allows two types of driving constraint,
which together can cover virtually all motions found in
practice: a rotary driver, which twists the shaft vectors S2
and S3 about the shaft axis vector Sl, and a linear driver
which moves the shaft reference point S along the shaft axis
vector. These two motions can be used to simulate rotary
input and linear actuators, respectively: in conjunction, they
can be used to simulate a screw. Since virtually all helical
joints in real mechanisms are part of a drive system, this
facility adequately overcomes the lack of a helical joint
amongst the static constraints.

No of constraints

(S - H)Sl

shaft reference point on slot line

Right angle constraint:

out the functions

Vector condition

2
= 0

= 0
= 0

S2.H3 = 0

Sl.H3

= 0

another body, as shown in Figure 3. Assembly of the bodies

consists firstly of evaluating the dot product of the two
vectors for the current positions of the two bodies:

Vs.VH= e.

(1)

The requirement is to rotate the two bodies through Euler

angles MA and bea, respectively, such that the error quantity
e becomes zero. Assuming that these angles are small, we
should choose MA and 60s such that:
(vs +

(6eA x v,b(v,

whence (MA X

x vspe,

or (Vu

+ (6eB x v,)) = 0

(2)

Vs).VH+ (6$ X V&Vs = - e

+ (V,x vH)-seB = e.

All equations of this type, plus all the (similar) equations

generated by ALIGN and CROSS can be assembled into a
matrix equation of the form:

_
A

orAS=e

_ 64

(3)

as shown in Figure 4, whence

6=A-e.

(4)

If the required adjustments to the position and orientation of

the bodies are small, they will be yielded by eqn (4). If they
are large, eqn (4) will not give precise answers, but it does
provide information
for a Newton-Raphson
style of
solution to the position analysis problem. Some care is
needed in applying the method: Promech typically scales
all proposed adjustments down so that no body is rotated
through more than 45. This avoids the potentially

CONSTRAINT ASSEMBLY AND SOLUTION

The position and orientation of each body is held by storing
the vector position of the bodys local origin, and a rotation
matrix which maps the bodys local axes onto a set of global
axes. Subsequent adjustments to a bodys position can then
be made by applying increments of the form 6R to its
position vector and rotational transforms 68 to its rotation
matrix, as shown in Figure 3.
All the constraints handled by the procedure SETSQ
above require that a vector on a shaft (Vs,say) on one
body be perpendicular to a vector on a hole (V,,say) on

Figure

Vector definitions for joints.

201

Open architecture

kinematic analysis: A L Johnson

J
Joint type:
Shaft in short
round hole
IbA

Previous
constraints

i
Current
constraints

ALIGN(
ALIGN(S3) +

Figure 4

Assembly of the constraint matrix.

behaviour reported by Kramer in Chapter

7 of Ref. 14.
For velocities, we note that each shaft vector Vs may in
general have an angular velocity ws relative to the body it
belongs to, in addition to the angular velocity 13of the body
itself. After a short time 6t we wish the dot product of the
two vectors still to be zero, which requires that:
unstable iterative

(Vs + (ws + e, X vs &).(V,

+ (4, x VJj) at) = 0

(3

Noting that VA.VB = 0, ignoring terms in lit*, and dividing

through by 6t gives:
(es x Vs).Vu + (4 x V).VS = (Vs X WS).V

(6)

or (V, X Vs)& + (V, X V,)4& = (Vs X os).VH

i.e. Ai=e

(7)

where d contains
bodies, whence
$=A-

the linear and angular

e,

velocities

of the

(8)

where the contents of A- are exactly as in the final iteration

of eqn (4). Velocities are thus calculated
by simply
evaluating the terms in e, which come from the righthand side of eqn (6) plus other similar equations from
ALIGN and CROSS. Most of these terms are zero, as only
driving constraints cause non-zero terms.
For accelerations, we simply differentiate eqn (7) with
respect to time to give:
_&+_A6 =eor&=e-A&=e

e,

(10)

where A- IS
again the same as for the previous calculations.
Thus, once the position analysis has been carried out,
velocities and accelerations are then both calculated exactly
without the need either for further matrix inversion or for

202

INERTIA LOADS
Once the linear and angular accelerations of each body have
been found, the resulting inertia (dAlembert) loads on the
mechanism can be calculated. It can readily be shown from
first principles I2that these loads can be expressed as a force
of - MaGacting though the centre of gravity plus a couple
of - J(? - 0 X (Jt9), where:
M is the mass of the body
aG is the acceleration of its centre of gravity and

(9)

where the elements in err are all in terms of V, w, cj and 8

which are all known. These elements
are calculated
individually
by differentiating
eqn (6) (and equivalent
equations from ALIGN and CROSS) and collecting the
terms not involving 6 or R onto the right-hand side. The
linear and angular accelerations
of the bodies are then
obtained from:
$=A-

numerical differentiation. This gives Promech a substantial

performance advantage, since step sizes can be kept fairly
large without compromising the accuracy of the kinematic
calculations.
Calculations of velocities and accelerations at subsequent
points in the mechanisms cycle are initiated by quoting an
elapsed time interval, and then calculating new trial orientations for the bodies using the velocities and accelerations
calculated in eqns (8) and (10) during the previous calculations. If the time interval is not too large, this will usually
yield an acceptably small set of values in e (eqn (4)), such
that there is no need to make any further adjustments to the
bodies positions. This means that the constraint matrix A
generally only needs to be assembled and inverted once for
each cycle of calculations, making for good computational
efficiency even in complex mechanisms.

or

I xx

-Ix,

- IXY

IYY

- Ixz

- IYZ

- Ixz
-I,,
Izz

.
I

The coefficients of the inertia matrix must expressed in the

global co-ordinate system, which requires a transformation

Open architecture kinematic analysis: A L Johnson

from the bodys own local co-ordinate
shown to come from the formula

system. This can be

J = RJRT,
where J is the inertia matrix in the bodys local co-ordinate
system, and R is the transform matrix which maps the
bodys co-ordinate system into the global system.
When these loads have been calculated, they can be
combined with any other external loads applied to the
mechanism, and used to calculate forces and couples at
the interfaces between the bodies. This process involves
using the same constraint information as was used in the
kinematic analysis to create and solve a set of simultaneous
equilibrium equations for the bodies. The method for doing
this is described in detail elsewhere16.

STRUCTURE OF THE SOFTWARE

Promech was initially written in FORTRAN and takes the
form of a library of subroutines, some of which are designed
to be called by the controlling program. These fall into five
main categories:

(1) Definition routines, which allow the main program to

define the required number of bodies, specify their
inertias, and add shafts and holes to them as required;
(2) Subroutine JOINT, which sets up joints between a shaft
on one body and a hole on another;
(3) Subroutines ROTATE and MOVE, which allow relative
motions to be specified between any shaft and its parent
body;
(4) Subroutine TSET, which sets the clock, and thus
defines how much motion has taken place between
successive calculations;
(5) Interrogation routines which report back the position,
velocity and acceleration of any defined part of the
mechanism, or the forces and couples being transmitted
through any joint.
The subroutines in (4) and (5) above are generally placed
in a loop in the main program, to allow the behaviour of the
mechanism to be analysed throughout its cycle. ROTATE
and MOVE can also be placed in the loop, if the input
velocities are not constant. A fresh set of calculations is
automatically
triggered the first time an interrogation
routine is called after any alteration to the position, velocity
or acceleration of a driving shaft.

CASE STUDY AND BENCHMARK

A case study has been carried out for this software as part of
the design of a deployable flight refuelling probe for British
Aerospace
Military Aircraft Division.
This essentially
consists of two hinged limbs (similar to a human arm),
each actuated by a separate hydraulic
cylinder.
An
important
aspect of the design was to ensure that
deployment would occur within a suitable timescale, despite
the inertia and aerodynamic
loads on the moving parts.
Promech was used to investigate the problem, and generated
an animated sequence of the mechanism in operation, as well
as a tabulation of the axial forces in the two hydraulic rams
at each stage of the deployment. The inertia component of
these forces was calculated quite automatically; evaluating
the aerodynamic
component
involved interrogating
the

Figure

Kinematic

model of the flight refuelling

probe.

position of the mechanism

after each assembly, then
calculating
and applying the appropriate
aerodynamic
forces on the various parts of the mechanism
before
completing the calculation of the joint loads. Three typical
frames from the animation sequence, with the probe at
different stages in its deployment, are shown in Figure 5.
A full description of the program written for this task is
beyond the scope of this paper, and has been published
separately.
It is, however, useful to record that it needed
fewer than 100 executable
statements to describe the
mechanism, record the joint forces and draw the simple
kinematic
models shown in Figure 5. The program
calculates and draws 180 pictures in 30 s on a 100 MHz
Pentium PC, which is the time in which the actual probe
is intended to be able to open and close. A Personal
Computer thus provides a real-time animation
of the
process, with a refresh rate of slightly greater than 6
frames per second. If the drawings are omitted from the
loop, the run time drops to just 18 s, or 0.1 s for each
calculation
of the mechanisms
behaviour.
The probe
mechanism consists of four moving bodies, and the run
time for more complex mechanisms would be proportional
to the square of the number of bodies; but this still
represents
an acceptable rate of calculation
for most
mechanical designs.

CONCLUSIONS AND FUTURE WORK

A new style of kinematic analysis software has been
presented, which is directly accessed by another calling
program, rather than via a user interface. The analysis
203

Open architecture kinematic analysis: A L Johnson

methods are essentially
well understood,
though the
identification of three vector constraints to cover 15 types
of kinematic pair makes the assembly of the constraint
matrix efficient both in terms of volume of code and speed
of execution. The specification of kinematic pairs is also
simpler than in many other analysis packages, as it is
automatically implied by the type of shaft and hole which
are involved in each joint.
The subroutine library described in this paper has been
fully written and tested, and work is now in progress to integrate it with the Functional Modellers constraint manager.
When this has been completed it will be possible to generate
suitable dimensions for any proposed mechanism, such that
specified stress limits in the parts and bearings are not
exceeded, without any intervention by the designer.
A current shortcoming of the system is that while it is
capable of generating a viable embodiment of any mechanism, it will not necessarily generate the best embodiment.
This is due to two reasons: firstly, no method has yet been
developed for improving
an unsatisfactory
design, for
instance by adding further features such as webs or pockets
to the parts; and secondly, because the criteria for what
constitutes the best design are relatively hard to define.
A simple criterion for the current work has been to minimise
the mass of the design, which is often the most desirable
goal in mechanism design; but manufacturing criteria must
also eventually be considered, as the lightest design is not
necessarily the cheapest to produce.
A second area for further development is to automate, as
far as possible, the re-specification
of constraints,
as
described in the section entitled Kinematic inte$aces.
Many mechanisms which work perfectly satisfactorily in
three dimensions are in fact over-constrained kinematically,
and work only because of play in the joints or flexibility in
their moving parts. While the Promech subroutines have the
facility to vary the amount of constraint in each joint to
mimic this, further work needs to be done in directing the
designer towards the location of such problems, and offering
guidance on the possible ways of resolving them. It is likely
that the final decision on how to vary the constraints should
always be left to the designer, as the calculated joint loads
can vary considerably, depending on what option is chosen.
Despite the clear need for further work, however,
the Promech subroutines
have effectively
provided an
interface-free route to kinematic and dynamic analysis in
the same way as the new generation of core modellers
does for solid modelling.
As such, they represent a
significant
and useful step towards the exciting and
challenging goal of computer-assisted
embodiment design.

204

REFERENCES
Roller, D., et al., Dimension-driven Geometry in CAD-a Survey.
Theory and Practice of Geometric ModeRing. North Holland, 1989.
Wagner, M. R., Understanding the ICAD System. ICAD Inc, 1990.
Johnson, A.L., Designing by functions. Design Studies, 1991, 12, No.

6.

I.
8
9.
10
Il.
12.
13.
14.
15.
16.
17.

Thornton, A. C., A support tool for constraint processes in embodiment design. In Proc. 6th Int. Conf on Design Theory and Methodology (DTM 94), ASME, 1994, pp. 231-239.
Thornton, A. C. and Johnson, A. L., Constraint specification and
satisfaction in embodiment design. In Proc. Int. Conf on Eng. Des.,
ZCED 93, The Hague, Netherlands. Hem&a, Zurich, 1993, pp. 13191326.
Yao, Z. and Johnson, A. L., Formalising knowledge for constraint
satisfaction in the design nrocess. In ICED 95. Prague. WDK, V
Hubka, Hemista, Zurich: 1995.
Yao, Z. and Johnson, A. L., On estimating the feasible solution space
of design. Computer-Aided Design, 1997, 29, 649-655.
Martin, E., Getting Started with the ACIS 30 Toolkit. Schemers, 1995.
Mechanica Applied Motion Users Manual, Rasna Corporation, San
Jose, 1995.
Gelsey, A., Automated reasoning about machines. Artificial Intelligence, 1995,74, l-53.
Joskowicz, L. and Sacks, E. P., Computational Kinematics. Artificial
Intelligence, 1991, 51, 381-416.
Haug, E.J., Computer-aided Kinematics and Dynamics of Mechanical
Systems Vol.1; Basic Methods, Ch. 9. Allyn and Bacon, 1989.
ADAMS Users Manual, Mechanism Dynamics Inc., Ann Arbor,
Michigan, 1987.
Kramer, G. A., Solving Geometric Constraint Systems. MIT Press.
Cambridge, MA.
Shigley, J. E. and Uicker, J. J., Theory of Machines and Mechanisms.
McGraw Hill, New York, 1980.
Johnson, A. L., Mechanism analysis by matrix reduction. Part I:
Statics. Proc. R. Sot. Lond. A, 1992, 439, 485-495.
Blessing, L. T. M. et al., Applying Systematic Design: the Flight
Refuellinn Probe Proiect. Cambridge EDC nublication CUED/CEDC/TR48, 1997.

Aylmer Johnson is a lecturer in

Mechanical Engineering and CAD at
the University of Cambridge. He
graduated from Cambridge in 1973,
and became leader of the development
team for the DUCT sutface modeller
over the period leading up to its first
commercial sales in 1979. He was 0
founder member of the Cambridge
Engineering Design Centre, and has
worked and published for the last
10 years in the area of Functional
Modelling
and
Computer-Aided
Embodiment Design. His other research interests include kinematics,
optimization and computer-based teaching.