Design of an automated assembly environment

Design of an automated assembly environment

Design of an automated assembly envi ronment U Roy, P Banerjee* and C R Liu* A design environment for acquisition, analysis and validation ot informat...

841KB Sizes 0 Downloads 106 Views

Design of an automated assembly envi ronment U Roy, P Banerjee* and C R Liu* A design environment for acquisition, analysis and validation ot information for automated mechanical assembly is proposed in this paper. The environment acts as a preprocessing step before the actual assembly operation. The working memory - consisting mainly ot instances of component and subassembly data objects and a B-rep based structured lace adjacency graph - is used to establish the assembly precedence relationship. The environment has been implemented in the objectoriented programming language Smalltalk-80. An objectbased approach has been preterred to a procedural language because of increased modularity, data abstraction, and efficiency ol the code. The hierarchical class (data type) structure of object-oriented programming has been used to define a hierarchical mating requirement module permitting knowledge inheritance from parent classes. computer-aideddesign,designenvironments,automatedmechanical assemblies, data representation One of the main drawbacks of present CAD systems is the lack of a global database that contains information required for all phases of manufacturing - namely design, processing, assembly, and inspection. Most of the recent research efforts in developing CAD databases concentrate on the information required for the automated process planning of individual components, but they do not contain a representation scheme for assembly information. A representation scheme for assembly planning should consider the relative spatial and temporal positioning of the components. Furthermore, a CAD database supporting this information can be used for generating task-level robot programs. Mechanical assembly is usually a hierarchical process in which components are assembled to form subassemblies. The subassemblies are further assembled to obtain aggregate subassemblies. The process continues until the final assembly is achieved. The number of hierarchical steps in the process depends upon the complexity of the assembly. Traditionally, an assembly planner interprets the assembly sequences from assembly drawings and a frequently accompanying assembly instruction sheet. In an automated assembly environment, these squences have to be generated from the CAD databases. Therefore, the CAD database has to provide information regarding functional or mechanical linkage Department of Mechanical and Aerospace Engineering, Syracuse University, SyracuseNY 13244,USA * EngineeringResearchCenterfor IntelligentManufacturingSystems, School of Industrial Engineering,PurdueUniversity,West Lafayette, IN 47907, USA

relationships between the mating components in addition to the geometric and topological information of the individual components. This demands first an efficient data representation of the functional relationships between several mating components of the assembled producff and then a process of interpreting these relationships to build up the assembly from its components. A hierarchical assembly data object representation that helps in planning task decomposition and automated sequence generation is proposed as an environment for automated assembly planning, A hierarchical mating knowledge acquisition system that reduces user interaction is also included in the environment.

REVIEW OF RELATED WORKS Research on computer-aided representation of assembly and its sequence planning started with the development of automated robotic task planning projects. Jentsch and Kaden 2 first discussed a graph theoretic method for determining an assembly tree for a geometrically described assembly. The basic idea of their work was to find the assembly sequence by reversing the disassembly sequence. Several researchers 3'4 have studied different algorithmic approaches to explore further this idea as a possible means of generating the assembly sequence. Ko and Lees have shown another method of automated assembly sequence generation from a user-specified 'mating graph' by checking interference between the related components. A second-order mating graph has been established in this work for deriving the assembly sequence planning. Daly ~ developed a system Boxer that directly uses the assembly sequence information provided by the designer to build the robotic task planning system. Recently, Morris and Haynes 7 have proposed a system known as ABC (assembly by constraints), which consists of a modeller for defining constraints between individual components and a sequencer for specifying the order of assembly, the interconnection between constraints, and the order of evaluation of constraints. The order of the execution of the constraints and assembly operations is determined by precedence graphs coupled with and/or graphs. An overview of a fully automated, noninteractive, rule-based assembly planning system is provided in EIMaraghy8.

PROBLEM DECOMPOSITION FOR ASSEMBLY PLANNING Planning for automated assembly involves the application of data and heuristic knowledge acquired from the user

volume 21 number 9 november 1989 0010-4485/89/090561-09 $03.00 © 1989 Butterworth & Co (Publishers) Ltd

561

as well as knowledge generated within the problemsolving environment. Heuristic knowledge in the form of functional relationships among components and data about the component configurations are imparted by the user. Temporal relationships are established by the problem-solving environment to generate an assembly sequence. A number of spatial and temporal relationships for assembly planning are defined and explained below.

jc II

l jB

Simple functional relationship (R) This denotes functional relationships R,~ between components i and j for two components or subassemblies at-a-time assemblies. A functional relationship shows the required mechanical linkages, joints, and other mating conditions between different features of the components to be assembtedL A relationship can be virtual. In a virtual relationship, all the components may not touch each other, but a relative temporal positioning between two or more components is essential for successful assembly. As shown in Figure 1, component A does not touch component B. It should be noted here that this virtual relationship is different from the virtual links described in Lee and Gossard ~.

Compressed spring

o- =J

J

Figure 2. Composite functional relationship

Composite functional relationship (R')

Movablejaw / i h r e ( ~ l e d

screw

This denotes functional relationships between components for more than two components at-a-time assemblies. In Figure 2, components A and B should be held in position shown to insert component C.

.....

Modified functional relationship graph (M-FRG) A functional relationship graph (FRG)1 is defined to show the required mechanical linkages, joints, and other mating conditions (e.g. rigid attachment, constraint relationship and contact relationship) between different features of the parts to be assembled. In addition to the information in a functional relationship graph, a modified graph (M-FRG) has the provision for specifying the type of virtual relationship and composite relationship. For the automated assembly operation, there are two ways of building the M-FRG: either assimilate the functional information by identifying and correctly interpreting virtual and composite relationships from the features in single component modules 1 of the CAD database or get the functional relationship information explicitly from the user. While the fomer method is more automated, it is considerably more complex. The latter method is chosen for this system. The functional information serves as a heuristic control mechanism that helps in picking the number of feasible candidates

i_

,,r 3.625"-*0,O01"

~

._~ Z Vicebody

x

Figure 3. Vice assembly for assembly from a full list of candidates based on the broad features from the single-component modules initially present. So certain commonly encountered relationship types in these categories are specified by the user in the M-FRG. An example of M-FRG for a vice assembly (Figure 3) is shown in Figure 4. It should be noted that since there are no virtual relationships in this particular example, th'e M-FRG is the same as the FRG.

Second-order relationship graph (R 2) This is a graph in which the simple relationship R,i from M-FRG is represented by the nodes, and the precedence among relationships is shown by directed arcs (Figure _5). R2 graph is acyclic because if a relationship R,j precedes another relationship Rk~, then Rk~ cannot logically precede R~j.While M-FRG specifies the relationships among components based on spatial constraints, R2 specifies the temporal relationships at an atomic level among the relationships specified in M-FRG.

Problem statement

Figure 1. Virtual functional relationship

562

The assembly planning problem involves a path for the transformation of a set of components (initial state) to a definite assembled body (goal state) through a series

computer-aided design

Po rt_of

---'--

~ . ~ Designation = Bose_subassembly Part no.= sO3

Designation, Base_assembly Part no.: vOI Par t_of Plain she portion I Part_of

f Plain shaft

DesignatiOnpart no. = p05:Component_assembly

R4

/

R,\,

1

,(° RI .... R6 : Relations between features

Port_of ~art_of

Designation : Component_assembly Part no. : j02

Figure 4. Modified functional relationship graph ( M-FRG) for vice assembly the states can be represented by a hierarchy of levels, level 1 being the initial state and level n the goal state. It should be noted that the functional relationships are the 2-tuples of mating components and the related constraints among them, and at the initial state, it constitutes a null set. The set of available components for fusion at the initial state is 2Z1= ,~. Finally, at the goal state the set will be empty for a successful assembly: 27n= {0}.

Figure 5. Second-order relationship graph (R2) for vice assembly of intermediate states. Given first a set of components = {S~, $2. . . . Sin}, m ~> 1; second, a set of constraints ( ~ = { Q ~ , Q ~ , ..Qg, Q ~ , . . . Q ~ } , k o r / ~ > l ; w h e r e Q ~ and Q~ denote simple and composite constraints respectively; and third, a set of mating functional relationships [F = (5*, Q*), where g* _ g and Q* _~ Q,

volume 21 number 9 november 1989

Level 1 Based on the temporal mating relationships, there exists a set of two-at-a-time components for parallel assembly. R 1= I(Si, Si)/, i, j<, m, i=~j; where [~1 represents the set of fused components (subassemblies) at level 1. The set [~1 along with the set of remaining (not fused) components 272 are carried over to the next level (level 2): 272= g _ R1. In general, any level/ can be represented as follows. Level i Level i consists of a set of subassemblies ~ from the next lower level ( i - 1 ) and a set 27 of components carried over from level i - 1 . At level i, ~ = {(~,-1, Z i ) u ( Z ' n , Z~) u ( ~ q,-1 ,[~r,-1 ) } , t ~ n ~ p , s ~ q ~ r .

563

At each level, there can be of three types of fusion:

Label I

• A subassembly ~',-~from the set of subassemblies [~, 1 (from level i - 1 ) fuses with a component 7/I from the set of components 7/' • Two distinct components /7',, and /71, from the set 7/~ fuse together • Two distinct subassemblies ~'~ ~ and ~',-~ from the set ~' ~ fuse together

Label 2

Step 2

Step I

Label 3k..~~

The inequality constraints ensure that all fusions taking place are between two distinct entities at-a-time. For composite relationships, the set ~i can be formed by more than two components or subassemblies at-a-time. Finally, R "i = [~nI ' Vi, I, which indicates a single final assembly. The next section formalizes a series of steps that generates these levels automatically. The steps lead to an assembly sequence.

Label I

L°be'

Label 4 _ _

L0., Step 3

(:S::) ® Step 4

Step 5

a

Establishment of assembly operation sequence The creation of sequences of subassemblies of a product involves reasoning about the assembly operation constraints, availability of resources, and the object characteristics. The sequence generation module can be divided into the following steps.

Step 1. The user inputs all functional relationships R,i between components i and j and specifies the type of composite relationships to form the modified functional relationship graph (M-FRG). The final relative positions of the components involved also have to be specified by the user for generation of second-order relation graph (R2/.

Step 2. To establish the required precedence between relations for R2 graph, interference checking is done for each pair in the relationship R~i in M-FRG from the relative positions in a completed assembly (Appendix A). There may or may not be a precedence between a pair of relationships. For example, in Figure 5, precedence could be established between only a certain number of pairs of relationships. The precedence for each local assembly is determined by reversing each local disassembly sequence. Each independent local sequence is much easier to find than the assembly sequencing problem considered as a whole.

Step 3. A topological sorting 9 of the nodes of the R2 graph is established (Figure 6). The topological sorting algorithm determines a sequence by repeatedly deleting nodes that have no predecessors (and their emanating arcs) until there are no more nodes to be deleted. The order of deleted nodes gives a topological order of mating relationships. The nodes are also labelled along with topological sorting. The parent nodes of the R2 graph is labelled 'one'. Before deleting a node, all the nodes to which the node is connected are identically labelled after incrementing by one. Thus the label of the deleted node is one less than that of each of its immediate successors.

564

b Figure 6. ( a) Topological order generation and labelling, (b) linked list representation of Step 1 Step 4. R~ graph contains information about all precedences in the assembly. However, it does not fully exploit the parallelisms in assembly, and there may be redundant arcs in the graph. A directed assembly tree (Figure 7) is created by making use of the information available from the topological ordering of nodes of the R2 graph (Step 3) and the R2 graph itself (Step 2). The nodes of the directed assembly tree carry the labels obtained in Step 3. The relationships with the same label can be assembled simultaneously, in parallel, subject to availability of resources. The labels can be interpreted as the defined levels in the previous section.

KNOWLEDGE ENVIRONMENT FOR ASSEMBLY The design of the knowledge environment is based on the assembly database proposed by Roy and Liu 1. An object-oriented data model is better suited for implementation of the information present in the type of assembly data model proposed by them. An object-

computer-aided design

Level I

NTlvl6 eZl v

N31 v l z

vii

Level 2 -

"!~9

-N, L v,

Level 5

( r

Level 4

Level 5

vI eI sI NI

a

(

: : : :

v6

~

",

~.~

<

Vertices Edges Surfaces Normol vectors of the surfoces

--

e5

1N'o

v5

°

I

" Y v , ^

v22

V2o

IJ v,o v, Ni2 v/L~9

P

Figure 7. Directed assembly tree for vice assembly oriented approach permits features like data abstraction, inheritance and code reusability. The data and the operations are encapsulated to form an object. The greatest advantage of using object-oriented data models for building the knowledge environment for assembly is the straightforward integration with object-oriented programs. In general, it is difficult to meld database interaction with procedural code I°. The knowledge environment has been implemented in the object-oriented programming language Smalltalk-80 ~1.Smalltalk-80 provides a good interactive design environment. An attempt has been made to make the interactive session quite user friendly. The system recognizes syntactic variations in the queries, and so the user does not have to follow rigid syntax rules while querying the database. The working memory in the assembly knowledge environment is made up of instances of component data object, subassembly data object, and structured face adjacency graph (SFAG) (Figure 8). SFAG is a hierarchy of face adjacency graphs of the general shape of the object with its constituent design features; these graphs use faces as the object-defining entities and the face-edge relaton as the fundamental relation between primitive object entities.

Data object representation The representation used for the data objects in the assembly environment is a dictionary data structure consisting of two parts named keys (of type symbol) and values (of types real, integer, symbol, string, or array). A high-level programming language (like Smalltalk-80) usually provides a variety of abstract data types. Component data object

The component data object consists of all components taking part in an assembly. Its private memory is organized as a dictionary data structure with each

volume 21 number 9 november 1989

b

self - -

D I c U o n a r v ( v o 1 - > Dictionary (faces- > O i c t l o n a / y ( s 2 - > ( ÷ e l o + e l l ÷ e 1 2 - e2 ) s 4 - > ( - e 4 - e 1 4 + e 1 5 + e 1 6 ) s 8 - > ( - e l l - e 2 2 ÷ eZ3 ÷ e 2 4 ) s l O - ) ( ÷ e 2 7 - e l O - e l - e 2 6 ) $ 1 - ) ( + e l ÷ e2 e3 + e 4 + e 5 + e 6 ÷ e 7 + e8 + e 9 ) $ 3 - ) ( - e 1 2 e 1 3 + e 1 4 - e 3 ) | 6 - ) ( - e l B + e l 9 ÷ eZO - e 6 s 7 - > ( - e 2 0 ÷ e21 + e 2 2 - e 7 ) s 1 1 - ) ( - e 2 7 e23 - e 2 3 - eZ1 - e l i - e 1 7 - e 1 5 - e l 3 - e l i ) sS->(- e5 - e16 ÷ e17 + elll ) sg-)(- e9 - e24 + eZS + e 2 6 ) ) e d g e s - > D i c t i o n a r y ( e l o - ) ( v 2 v l O ) e211->(v19 v 2 0 ) e g - ) ( v 9 v l ) e i - ) ( v l l v 9 ) e29->(v20 v19 ) e17->(v13 v14 ) e14->(v13 v 5 ) e ? - ) ( v 7 v 8 ) e l s - > ( v 1 2 ,,13 ) e 1 4 - ) ( v 1 2 v4 ) e6-)(v6 v7 ) eS->(v5 v6 ) e31-)(v22 v21 ) e 4 - ) ( v 4 v 5 ) e 3 - > ( ¥ 3 ,,4 ) e 3 0 - > ( v 2 1 v 2 2 ) e13->(v11 v12 ) elE->(vt4 v6 ) e19-)(v14 vlS ) e20-)(vls v7 ) e21->(v15 v!6 ) e2-)(v2 v3 ) e12->(v11 v3 ) e22->(¥16 v8 ) el->(vl v2 ) e23->(v16 v17 ) e24->(v17 v9 ) e2S->(vl7 v18 ) ell-)(v10 v l l ) e26->(¥111 v l ) e 2 7 - > ( v 1 8 v l O ) ) v e r U c e s - > O I c U o n a r y (¥7->(0.687~; 0 1 .I I ) ¥ B - > ( 0 . 3 6 0 1 .I I ) v 4 - > ( 2 . 9 3 7 5 0 1.11 ) v 2 ~ ) ( 3 . 6 2 5 0 0 ) v 1 5 - ) ( 0 . 6 1 1 7 5 1.13 1.11 ) v 1 6 - > ( 0 . 3 6 1.15 1.11 ) V 1 7 - > ( 0 1.15 0 . 4 i S )

C

Figure 8. (a) Vice body, (b) SFAG representation ot vice body, (c) instance ot SFAG object for vice body component identified by a code. Each component structure also consists of a dictionary that contains information about its designation, primary features, functional features, material, weight, and position. The geometrical and topological information is stored in SFAG. The user-supplied designation is categorized as base assembly, base subassembly, component assembly, or component subassembly. The component designated as base assembly~subassembly is treated as the base component for a particular assembly operation. The designation base subassembly is for a component that

565

figures as the base component for a subassembly with its mating component designated as component subassembly. These designations can be used for data inconsistency checking and for ensuring feasible assemblies. For example, a designation component assembly (or component subassembly) cannot exist in a particular level of assembly sequence unless there is at least one designation base assembly (or base

subassembly). In this prototype system, the list of primary features is limited only to common prismatic and cylindrical features like hole, slot, v-groove, and semi-v-groove. The feature information is organized as an ordered collection and includes location, dimensions, tolerances, surface roughness, and Boolean type. The Boolean type is derived from the CSG representation of the component. If the feature is arrived at by removing material, then it is given a Boolean type '-', whereas if the feature is arrived at by adding material, then the Boolean type for that feature is ' + ' . The Boolean type is used for a preliminary check on accessibility during assembly.

Subassembly data object The assembly-specific semantic information is organized in subassembly data object. The primary purpose of subasssembly data object is to record the links between the component at various stages of the assembly process. Initially, the M-FRG (raw data)is stored without reflecting the partition into levels. After the final directed assembly graph generation, the relationship among various components is organized into sequential levels (Figure 9) detailing opportunities for parallel assembly operations. The private memory of the subassembly data object is organized as a dictionary. The information within each level is also organized into dictionaries identifying each of the possible candidates for assembly at that level. Each candidate has its own designation, mating

Subassembliest self

au~lr~nlB

Dictionary ( 1 - > Dictionary (sum I 1 - > Dictionary (entiUes->(v01 J02 ) fuslon->fusedFeaturel mating g e q - ) clearance FR r e l C o d e - ) R1 r e l T y p e - ~slidlngContact functional Features - >(slot Base 1 base 1 ) contactCond- >surfaceContact comblnedName->newPartl ) s u m 1 2 - ) OIctionary (entitles->(s03 sh04 ) fuslon->fusedFeature2 mating Keq- >interference fit r e l C o d e - > K2

relType-, detachable KlgidAttachment functlonalFeatures->(reamedHolel knurledPo~ont contactCond- >surfaceContact comblnedName- >newPartZ ) ) 2 - >Dictionary ( s u m 2 1 - > Dictionau~' ( e n t i t l e s - > ( s u m l 1 sum12 )

)

fusion- >fused Feature3 maUng Keq- >¢otationaJScrew M o v e m e n t r e i C o d e - > K3

relType- >constrained functionadFeatures->(ticopedHolel threadedShaftl ) c o n t a c t C o n d - >surfaceContact c o m b i n e d N a m e - ) n e w P a ~ 3 ) s u m 2 2 - > Dictionary (entities->(sum21 sum21 ) f u s l o n - > f u s e d F e a t u r e 4 matingKe¢l- >interferenceFIt r e l C o d e - > ~4

relType- >detachable KlgldAttachment functionaJFeatures->(drlUedHolel plainSha/tPortionl ) c o n t a c t C o n d - >surfaceContact c o m b i n e d N a m e - >newPart4 ) ) 3 - > OIctionau~/ (sum31 - > Dictionary (entitles- >(p05 sum22 ) fusion- >fusedFeature$ mating Ke(i- >transition FR relCode- > RS r e l T v p e - ) detachable RigldAitachment funcUonaJFeatures->(plaJnShaftPo~lon2 drilledHole2 ) c o n t a c t C o n d - • surfaceContact comblnedName->newPart5 ) s u m 3 2 - > Olctlonary

Figure 9. Instance el subassembly data object

566

entities, functional features, relationship number, relationship type, contact condition, mating requirements, combined part designators, and fused feature designator. An intermediate stage (level i) of the assembly process consists of functional features that are not yet fused as well as the features that are fused. The relationship type describes the nature of the relationship between the two mating surfaces. The relationship type can be either rigid attachment in which the surfaces can be destroyed if they are taken apart (e.g. welding, brazing, adhesive bonding, and interference fits); constrained where the movement is restricted in 1D or 2D (e.g. mechanical fasteners, clearance, and transitions fits); or contact where there is a mere touching of the two surfaces, the purpose being to support and to permit sliding or relative movement. The contact condition indicates where the contact between two mating surfaces is a point, line, or surface contact. The contact surfaces can be identified from the SFAG representation of the mating components. The mating requirements describes the nature of contact desired so that the requiremenLs for that contact can be determined. Some amount of data redundancy is intentionally provided for easy access of information. This information is also used in checking data inconsistency.

User interface Input data representation and storage The component data object is established by interactive input from the user or by reading from a stored data file. The input is in the form of code, name, designation, primary features, material, weight (optional), functional features, approximate overall shape (e.g. rectangular, cylindrical), position vector (x, y, z, c(, fl ~/) or a shape matrix. The M-FRG shown in Figure 4 also comes as user input. The instance of subassembly data object for the vice assembly stores this information. A part of the private memory of the subassembly data object is shown in Figure 9. An instance of subassembly data object typically consists of the level of subassembly, relationship code, mating entity-codes, combined entity code, name, and mating functional features. Dictionary, Set, Ordered Collection, Array, and Linked List are the data types used to represent and manipulate the assembly structure in the planning environment. The vertices, edges and surfaces of each component and their correlations are stored as part of a B-rep based SFAG. If the components of an assembly are stored in a CAD database, then the user essentially has to transfer the information in the format specified for this automated assembly environment. A suitable computer program can be written for this interface. If the components are stored by some other means, then the user has to input the necessary information in the format specified. The user has to specify the codes, names and mating functional features in the designed interactive format for the subassembly data object. The SFAG information also has to be transferred from the CAD representation.

computer-aided design

This interface is very similar to the component data and CAD interface.

Thus this hierarchical data abstraction scheme structurally distinguishes itself and achieves the task of an additional explicit control mechanism of a procedural language in generating questions and interpreting user responses.

Mating specification The classification of the mating requirement for every fusion in an assembly is done by the user. Once a mating requirement type is specified, it is instantiated and positioned in its class. Data validation is done by using the methods defined in its own class and by inheriting the method from its parent classes. A typical hierarchy of mating requirement knowledge for mechanical assembly is shown in Figure 10. Every mating requirement is an instance of one of the ten mating classes. The ten classes are Sliding, Clearance, Transition, Interference, Fastener, Gear (the subclasses of Gear have not been considered here), Sleeve, Ball, Roller, and Hydrodynamic. Each of these classes provides generic mating requirement characteristics from which each instance can derive its own information by using its set of operations and store the acquired information in its private memory. This information can serve as an input for the task-level specification for executing an automated assembly operation. This implementation is more efficient, modular, and comprehensive compared to its corresponding procedural representation. By clearly specifying the set of operations for each instance of the type of mating requirement, it is shielded from the rest of the operations that do not fall in its class hierarchy. The amount of user interaction needed in generating this mating information is also reduced because each subsequent query is structurally based on user responses to previous questions.

Evolution of assembly sequence The evolution of the assembly sequence is explained by a vice assembly example (Figure 3). By performing the accessibility test on each pair in the relationship in M-FRG, a precedence is established between the nodes of the R2 graph (Appendix A) (Figure 5). A topological sorting of the nodes is established from the R~ graph (Figure 6). Before deleting a node with no predecessors in the topological sorting algorithm, the direct successors of it having no other predecessors are labelled. A directed assembly tree (Figure 7)is established from the R2graph and the topological sorting of nodes. The directed assembly tree has no redundant arcs, and so it uniquely and sequentially divides the assembly into multiple levels. The labels are used to determine the various levels in the assembly tree. Parallel two-at-a-time assembly operations can be performed on candidates within the same level. In the example, relationship R2 can be done in parallel at any level because it is not connected with any other node in the graph.

C O N C L U S I O N S A N D FUTURE W O R K A successful mechanical assembly requires a lot of expertise on the part of the assembler. The knowledge environment described in this paper can form the basis

Mating specification - get Components - read Data (SFAG) - get Weight - accessibility Test - check Alignment

~~i~i::i::ii~i~i~i::ij:!:i:i:i:i:i:i:i:!:~:::!~!.:~::i:i:i:i:i:i:i:i:i:~:i:i:i:i:i:i:iiiiii~i~i~ii!i~

:::::::::::::::::::::::::::::::::::::::::::::::::::::: Fit ::iiiiililililiiiiiiilililili::ilili::ili::ilili::iiii!ii::il(Prismotic and cylindrical)

iiiiiiiiiiiiiiiiiiiiiii iii

- force Requirement

Bearing

!!i!iiii!i!!i!i!iiiiii::

- torque Requirement li!i!ii!::!iiii!iii!iiii Anti friction

iiiiii!i!i iiiiiiiiii!i i{!iiiiiiiii!i !iiiiiiiiiii:;i;ii!i!!;!;:iiii!i!i!i!i!iiiii!i!:ii;:!iii!!!i!i!i!!!iii!!!i!i!:i;:!!ii;:i!i!!i!i!!i!i!!!ii!i~

~

!iJ Interference - check Tolerance - checkSpecial :iil- ch~kl_ubricotion [:] -check Tolerance requirement ::i~- for~ Requirernent [i - force Requirement - force Requirement i

i

~

]

Transition

iiil- eck To o.ce Ill-c ck

Hydrodynamic

Figure 10. Hierarchy of mating specification volume 21 number 9 november 1989

567

for building an expert system. Once the mating requirement classification is supplied by the user, the assembly sequence generation, validation, and consistency checking of the data can be done by the expert system before supplying the data for the actual assembly. The information available in the assembly environment can be utilized for generating task-level programs for automated robotic assembly. With advances in task-level robot programming, issues like how to grasp a component in the case of robotic assembly and how to plan a suitable trajectory for a component to reach its approach direction before assembly should be generated by utilizing the world model of the components and subassemblies available from the assembly environment. A number of extensions to the prototype design of the knowledge environment can be made. Further investigation of composite relationships have to be done to identify and to generate automatically their assembly sequence. The accessibility test has to be extended to analyse the assemblability of more than two entities simultaneously. A typical assembly involves a combinatoric number of potential arrangements based on component features and, therefore, an intelligent control of the search space is essential for its automated planning. A heuristic control mechanism used in the knowledge environment is based on the user's specification of functional relationships among components. This framework provides a good foundation for linking component and subassembly relationships in a CAD database, which is essential for automated assembly planning. Potential augmentations with other control strategies like one based on hierarchical stepwise refinement and opportunistic planning for assembly tasks as discussed in Hayes-Roth et al. ~2have to be explored to make the planning more versatile with the automated handling of composite relationships.

REFERENCES 1 Roy, U and Liu, C R 'Establishment of functional relationships between product components in assembly database' Comput.-Aided Des. Vol 20 No 10 (1988) pp 570-580 2 Jentsch, W and Kaden, F 'Automatic generation of assembly sequences' in Plander, I (ed.) Artificial Intelligence and Information Control System of Robot Elsevier North-Holland, Amsterdam, The Netherlands (1984) pp 197-200 3 Lee, C S G and Huang, Y 'Automatic planning of automated assembly system' CIDMAC Annual Report 1986-87 Purdue University, West Lafayette, IN, USA (1987) pp 525-527 4 Woo, T C 'Automatic disassembly' Proc. SAE Int. Computer Graphics Conf. (Detroit, MI, USA, 1987) pp 163-168 5 Ko, H and Lee, K 'Automatic assembling procedure generation from mating conditions' Comput.-Aided Des. Vol 19 No 1 (1987) pp 3-10

568

6 Daly, T 'BOXER: a design to build system - system architecture study' IBM Research Report RCl1096 IBM (1985)

7 Morris, G H and Haynes, L S 'Robotic assembly by constraints' Proc. IEEE Int. Conf. on Robotics and Automation Vol 3 (Raleigh, NC, USA (1987) pp 1507-1515 8 EIMaraghy, H A 'Artificial intelligence and robotic assembly' Eng. Comput. Vol 2 (1987) pp 147-155 9 Horowitz, E and Sahni, S Fundamentals of Data Structures Computer Science Press(1983) pp 310-315 10 Blaha, M R, Premerlani, W J and Rumbaugh, J E 'Relational database design using an object-oriented methodology' ACM Commun. Vol 31 No 4 (1988) pp 414-427 11 Goldberg, A and Robson, D SMALLTALK-80: The Language and its Implementation Addison-Wesley, Reading, MA, USA (1983) 12 Hayes-Roth, B, Johnson, A V, Garvey, A and Hewitt, M 'Application of the BB1 blackboard control architecture to arrangement-assembly tasks' Int. J. AI Eng. Vol 1 No 2 (1986) pp 85-94 13 Lee, K and Gossard, D C 'A hierarchical data structure for representing assemblies: part 1' Comput.-Aided Des. Vol 17 No 1 (1985) pp 15-19 A P P E N D I X A: G E N E R A T I O N OF S E C O N D - O R D E R R E L A T I O N S H I P G R A P H ( R 2) Assumptions Disassembly and assembly are considered only from the final positions. In other words, partial disassemblies or assemblies of two components involved in a relationship are not considered. The direction of assembly of each pair in the relationship is exactly opposite to the direction of disassembly. Only translational movements along the three cardinal axes directions for arriving at the final positions or disassembly from the final positions are considered (e.g. a screw is considered as a shaft being pushed into or pulled from its final position). For determining precedence among relationships, the final relative positions in the global coordinate frame of the components involved in the relationships are considered.

Procedure The following procedure is used for the generation of R2 graph. It is applicable for simple relationships (and for properly defined virtual relationships). Step 1. The direction of disassembly of each node relationship of the R2 graph is obtained by using the accessibility test as described in Appendix B. Step 2a. The precedence is now established by considering two nodes at a time in the R2 graph. If the two relationships involve two distinct sets of components

computer-aided design

then there exists no precedence. In fact, these two relationships are possible candidates for parallel assembly within each level subject to resource constraints. For example, relationships R~ and R2 in the vice assembly fall in this category.

B

Step 2b. If three components are involved in the two node relationships of the R2 graph, then there exist two possibilities: I Case 1. The relationships are independent. In such a case, there is no precedence, and any one of the two relationships can be performed before the other. However, they cannot be performed in parallel. • Case 2. The relationships are not independent, and so there is a precedence. Consider relationships R~ and R4 in the vice assembly. © Assume R4 precedes R1. Step 1 indicates that the disassembly for relationship R4 can be done only in + X direction according to the coordinate system shown in Figure 3. The disassembly for R1 can be done in +Z, +Y, and - Y directions. So the assembly for R1 can be carried out in - Z , - Y, and + Y directions. After establishing the assembly in relationship R4, the assemblability for R~ is checked in directions - Z , - Y, and + Y by using the accessibility test in Appendix B. Interference occurs in each of these directions. So R4 cannot precede R~. © Now consider that R~ precedes R4. After establishing R~, the assemblability for R4 is checked in - X direction. The screw so3 (Figure 3) can be assembled to the movable jaw j02 to validate R4 after R~. So R1 can precede R4. A similar test shows that R3 cannot precede R~ because only the final assembled position of each pair of components in a relationship is considered. However, R~ can precede R~. After testing each pair of nodes in R2 graph, the precedence shown in Figure 5 is established.

APPENDIX B: ACCESSIBILITY TEST The purpose of the accessibility test is to ensure that there is no interference in the path of the assembly. The information required for this test comes from SFAG and from functional relationships stored in the subassembly data object. It has been assumed that the

volume 21 number 9 november 1989

a

u2

/ b Figure 11. (a) Successful disassembly directions (u~, u2 and u3 are possible directions of disassembly); (b) no successful disassembly direction in the plane of u~ components have only surface contacts. For simplicity, only the three translational degrees of freedom are permitted and only two-at-a-time assemblies are considered. A successful approach direction for assembly may be redefined as the direction of dismantling the assembled product. As an example, consider the components shown in Figure 11. Component B can be dismantled from the subassembly in a direction u~ if for all points P on the boundary edges of the mating surfaces of B, a ray (P, u~) in the direction of u~ does not intersect component A. The directions of normals of the mating surfaces are tested first to select the direction ui (as shown in Figure 11 (a)). If no such direction satisfies the condition for dismantlability (as in the case of Figure 11(b)), the directions perpendicular to u~, say v~, are tried next. If these directions also fail, the directions (u~ x v~) are checked for the feasible direction.

569