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

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 lF’2, UK

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 Mechanica’s 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 lo or Joskowicz “, whose principal aim is to

199

Open architecture kinematic analysis: A L Johnson

infer the kinematic behaviour of a mechanism from the physical shape of its parts.

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 be “circular’ ’ or “slotted”. The combination rules are

Groove for Circlip Keyway

0’8 nil

6 w PLANAA

w w $R w

0

+A @A $A v

0 SPHERICAL

CPS

cD

$A 4A +A @T

a: CYLINDRICAL REVCUTE PRISMATIC

@p 4s w +p

Figure 1 Feature combination and joint types.

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 body’s 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

Figure 2 Vectors for shafts and holes

200

Open architecture kinematic analysis: A L Johnson

Table 1 Basic kinematic constraints

Symbol Description Vector condition No of constraints

Sliding constraint: hole reference point on shaft base plane

Axial constraint: hole reference point on shaft axis

Lateral constraint: shaft reference point on slot line

Crossing constraint: shaft passes through slot line

Parallel constraint: main axes parallel

Twisting constraint: shaft can’t rotate about own axis

Right angle constraint: shaft axis parallel to plane of pocket

(S - H)Sl = 0 1

(S - H)S2 = 0 (S - H)S3 = 0 2

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

(S - H) X H2)Sl = 0 1

Sl.H2 = 0 Sl.H3 = 0 2

S2.H3 = 0 1

Sl.H3 = 0 1

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)

(2) (3)

ALIGN(V) which sets {(S - H).V = 0) and so carries out the functions of 4S, ~#JA and 4L; CROSS which carries out the function of 4X; 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, TLA’s use of seven Joint Primitives to analyse seven types of kinematic pairs 14.

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.

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.

CONSTRAINT ASSEMBLY AND SOLUTION

The position and orientation of each body is held by storing the vector position of the body’s local origin, and a rotation matrix which maps the body’s local axes onto a set of global axes. Subsequent adjustments to a body’s 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

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, + (6eB x v,)) = 0 (2)

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

or (Vu x vspe, + (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:

_ W

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

Figure 3 Vector definitions for joints.

201

Open architecture kinematic analysis: A L Johnson

J Joint type:

Shaft in short round hole

IbA

ALIGN( ALIGN(S3) +

Figure 4 Assembly of the constraint matrix.

unstable iterative 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 13 of the body itself. After a short time 6t we wish the dot product of the two vectors still to be zero, which requires that:

(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 the linear and angular velocities of the bodies, whence

$=A-’ e’, (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 right- hand 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 =e’or&=e’-A&=e” (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-’ 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

i

Previous constraints

Current constraints

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 mechanism’s cycle are initiated by quoting an elapsed time interval, and then calculating new trial orienta- tions for the bodies using the velocities and accelerations calculated in eqns (8) and (10) during the previous calcula- tions. 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.

INERTIA LOADS

Once the linear and angular accelerations of each body have been found, the resulting inertia (d’Alembert) loads on the mechanism can be calculated. It can readily be shown from first principles I2 that these loads can be expressed as a force of - MaG acting 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

I xx -Ix, - Ixz

- IXY IYY -I,, .

- Ixz - IYZ Izz I

or

The coefficients of the inertia matrix must expressed in the global co-ordinate system, which requires a transformation

202

Open architecture kinematic analysis: A L Johnson

from the body’s own local co-ordinate system. This can be shown to come from the formula

J = RJ’RT,

where J’ is the inertia matrix in the body’s local co-ordinate system, and R is the transform matrix which maps the body’s 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)

(2)

(3)

(4)

(5)

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; Subroutine JOINT, which sets up joints between a shaft on one body and a hole on another; Subroutines ROTATE and MOVE, which allow relative motions to be specified between any shaft and its parent body; Subroutine TSET, which “sets the clock”, and thus defines how much motion has taken place between successive calculations; 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 5 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 mechanism’s 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 inte- grate it with the Functional Modeller’s 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 mechan- ism, 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.

REFERENCES

5

6.

I.

8 9.

10

Il.

12.

13.

14.

15.

16.

17.

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.

Thornton, A. C., A support tool for constraint processes in embodi- ment design. In Proc. 6th Int. Conf on Design Theory and Methodol- ogy (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. 1319- 1326. 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 User’s Manual, Rasna Corporation, San Jose, 1995. Gelsey, A., Automated reasoning about machines. Artificial Intelli- gence, 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 User’s 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/C- EDC/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.

204