Effector-Based
Operator
Construction:
An Alternative
Planner Knowledge Representation
for Reducing Planner Maintenance Effort
From: AAAI Technical Report WS-98-03. Compilation copyright © 1998, AAAI (www.aaai.org). All rights reserved.
Caroline C. Hayes
Daniel M. Gaines
dmgaines@cs.uiuc.edu
hayes@me.umn.edu
Dept of Computer Science
Dept of Mech. & Ind. Engineering
University of Illinois
at Urbana-Champaign
University of Minnesota
Fernando Castafio
castano@students.uiuc.edu
Department of Electrical
and Computer Engineering
University of Illinois
at Urbana-Champaign
Abstract
easier and less time consuming in complex physical
domains such as manufacturing planning by making it possible for users whoare domainexperts, but
not necessarily programmers, to perform the maintenance task. Thus, enabling them to customize
the planning tool to meet the changing needs of
their specific environment.
This work is motivated by the fact that the world
is not static. Becauseit constantly changes, intelligent software systems must be updated constantly
to deal with these changes. Maintenance of complex planning systems for real domains can take
considerable effort. For example, Chien reports on
a planner that required 4 out of 5 days of effort
spent simply on maintenance (Chien 1996). Because of the effort and cost involved in planner
maintenance, automated planners that are to be
used for practical purposes must not only be designed to provide accurate solutions, but must also
be maintainable. However, there is probably no
single solution that will address the maintenance
problem for all types of domains.
Researchers attempting to deploy complex planners in practical applications have met with the
high cost of maintaining and debugging a planner’s knowledgebase. There has been somesuccess
in using knowledgeacquisition tools and machine
learning techniquesto assist in developmentof operator schemas. However,it is often hard for the
domainexperts whoare the users of the program
to do their ownplanner maintenance unless they
are trained to think in terms of AI planning concepts, since their ownrepresentations of the problem may or maynot resemble typical operatorschema-based representations. Such automated
planning tools mayfall by the wayside in practical applications due to difficulty of retraining
for maintenance. In this work we have addressed
the knowledgeacquisition problemby using an alternative representation of the planner’s knowledge, whichbetter fits the users’ representations
in particular types of complexphysical domainsin
whichthe available effectors (i.e. tools and materials used in creating actions) changerapidly,
but the way in which they are used does not. We
call our representation for these problemsand the
technique for applying it Effector-based Operator:
Construction. One of the important characteristics that distinguishes the effector-based approach
from other approaches is that the representation
separates the effector descriptions from the descriptions of howthose effectors are used. Operator and action schematypically combinethese two
types of information in the representation. This
separation is of importancein maintenanceof complex physical domainsbecause it makesit possible for domain experts whoare non-programmers
to makethe changes required for planner maintenance by expressing the changesin concrete physical terms with whichthey are familiar.
There has been some success in using knowledge
acquisition tools and machine learning techniques
to assist in development of operator schemata, preconditions and effects. These tools vary in the ease
with which domain experts can use them. Often
(but not always) the maintenance work must
done by a specially trained knowledge engineer who
knows both the domain and the planning representation, or the users must be specially trained to do
the maintenance work. In some cases, this may be
the most desirable way to handle the issue. In this
work we have addressed the knowledge acquisition
problem by using an alternative way of representing the pLanning knowledge, called effector-based
operator construction, which is easier for the domain experts in many complex physical domains
to learn. The most rapid changes in such domains
are usually in the static effectors (tools, machines,
etc) which are available, and not in the way those
effectors are used. Our representation separates effector descriptions from the rules and conditions for
Introduction
This work presents an alternate method for representing a planner’s domain knowledge and generating operator instantiations, which we call effecforbased operator construction. The objective of this
method is to make planner knowledge acquisition
1
their use, and thus allows uses to describe domain
changes the same physical terms with which they
are used to dealing.
Effector-based operator construction focuses on
the objects
and motions that can be combined to produce actions/operations,’and
on the
rules/constraints by which those effectors and motions can be combined. It generates operators
from this more basic knowledge, rather than explicitly representing the actions/operations themselves.
Weexamine this method in the context of manufacturing planning, however, we believe the technique
will be useful in many complex physical domains
in which operations are formed by combining many
physical components to produce an action (such as
a combination of robot arm motions and gripper
motions to pick up objects).
Our representation is based on the observations
that in many physical domains 1) the actions one
can take in the domain(without incurring large economic costs) are strongly constrained by the tools
and materials one has available (i.e the effectors.
2) The set of effectors frequently changes, but not
the ways in which the effectors are used and combined. 3) actions are produced by applying not just
single effectors, but combinations of effectors, and
4) an ad-hoc combination of effectors is designed
to fit the specific needs of the current situation. A
consequence is that a potentially huge number of
operator schemata may be required to represent all
these combinations. Thus, if the domain is large
(i.e. many effectors, many possible ways of combining them to produce actions/operators),
it may
be more effective to represent the components effectors and the ways of combining them, than it it
is to represent the resulting operator schemata.
In response to these issues, instead of explicitly
representing a set of operator schemata and instantiating them for specific goals and situations, we
represent the set of effectors, constraints on how
they may be combined, and use this information
to construct operator instantiations for each goal.
One way to think of the approach is as a generative
approach to operator selection and instantiation.
If operator schema can be thought of as "operator
cases" in a case-based approach to generating instantiated operators, then our scheme of operator
construction can be thought of as a generative approach in which operator instantiations are derived
from more basic information.
Effector-based operator construction is most useful in complex planning domains where 1) operations are the result of combinations of effectors,
and 2) sufficient domaintheory is available to derive how the effectors will behave to produce operations/actions.
Examples of domains with the~e
properties include manufacturing domains, such as
machining, sheet metal forming, and assembly, as
well as certain types of robot task planning domains. Counter examples include empirically understood domains, such as administration of medications to patients. Frequently, the connection between the administration of a medication and its
result is only empirically understood. It maybe observed that if patient exhibits symptomsa, b and c,
and if one administers drug x, then the symptoms
abate. However, the causes, and the biochemical
action of the drug that produces a result may not
necessarily be well understood. In such empirically
understood domains, a more traditional operator
schema approach is probably more appropriate.
Wepropose this method as a way of defining families of planners. Thus, we do not recommendthat
system designers attempt to build general purpose
operator construction engines but rather that they
tailor them to specific families of problems. Frequently changing properties of that family should
be made accessible and editable by the users, while
it is less important to make the less frequently
changing properties explicit. Furthermore, users
can not change the properties of the planner (or
effectors) to those outside the bounds of the planner family, thus the types of changes that can be
made and the language in which the changes are
expressed can be made more manageable. In order to build a pragmatic planner with reasonable
performance, we feel that a given planner should
be designed so that it explicitly represents only
the frequently changing properties of the effectors,
which it allows the user to examine and update.
However,the more static properties of the planner
should be incorporated into the planner’s operator
construction engine, and the system designer may
or maynot want to explicitly represent these more
static properties. The system designer’s decision
about what properties to make static and what to
make user update-able, will partially determine the
trade-off between the breadth of the problem family that a planner can handle, and the efficiency of
the planner. In our examples, we have chosen to
implement a planner that addresses a fairly narrow but realistic range of manufacturing planning
problems, but which is relatively efficient.
One of the benefits of this approach is that for
manyimportant domains, it is easier users who are
domain domain experts, or at least domain proficient, to perform knowledge maintenance with out
the help of a knowledge engineer. First, since a
given effector may take part in more than one action, there maybe fewer effectors than there are operators. Second, effectors are often easier for users
to describe than operators, because effectors are
concrete objects which they are used to handling
and visualizing. In our manufacturing application,
we provide users with an "effector editor" which
allows them to visualize and to modify the various
Input
Output
Figure 1: Model of effeetor-based operator construction.
effectors. Planning tools that can be directly modified and customized by the users are much more
likely to be used and maintained than those the
require a specially trained knowledge engineering
intermediary.
Effector-Based
Operator
Construction
The operator construction engine takes the place of
the operator match and instantiation process of traditional planners. The engine takes as arguments
a set of effectors and the problem description and
produces a set of instantiated operators which can
be used to solve the problem. The remaining planning processes, such as selecting appropriate operators and avoiding interactions, can remain the
same.
Figure 1 shows the model of the effector-based
operator construction engine. The engine is run on
each goal in the problem description. It begins with
an operator shell that contains no pre-conditions
and a single post-condition corresponding to the
goal to achieve. Pre-conditions and post-conditions
are added to the operator through successive refinements as the engine narrows down the set of
effectors that can be combinedto achieve the goal.
The engine has three main steps which are repeated
until a complete operator description has been obtained. Each step has a corresponding database of
domain knowledge to help direct the process. The
first step, Select Effector Class, identifies the class of
effectors to try on the current pass. Search Control
knowledgeis used to identify which effector classes
are applicable given the effectors already present in
the operator description. Next, Match Effectors determines which effectors in the class actually match
the problem description. Domainspecific Matchers
tell the step how effectors match the problem description. For each match found, Construct Operators builds a new operator by adding pre-conditions
and post-conditions to the existing operator. Constructors decide what information to add based on
the matches. Search Control knowledge is used to
determine if the new operator description is complete. If it is not complete, it is sent back to Select Effector Class for another pass, otherwise it is
returned as output. In many cases there may be
more than one operator for achieving a given goal.
It is the planner’s job to select which operator is
most appropriate in the plan.
The effector-based operator construction process
will first be described using a simplified robot manipulator domain. This domain is not really complex enough to demonstrate the benefits of the
effector-based approach, but will serve to explain
the process. In the next section, a richer example
from a more complex manufacturing domain will
be presented.
Effector
Classes and Effector
Subclasses
The various types of effectors in a domainare represented as effector classes. For example, There are
two effector classes in the robot manipulator domain: grippers and robot arms. Grippers, shown
in Figure 2 (a) and (b), are used to grasp blocks
and come in different shapes and sizes. The grippers attach to a robot arm, shownin Figure 2 (c),
which is used to movethe gripper around. Together
these effectors can be used to lift and moveblocks.
An effector class is defined by a set of predicate
and function symbols that can be used to describe
the properties of the effectors within a class that are
relevant to producing actions. In the robot manipulator example, grippers using gripping surfaces to
grasp objects. Thus, the predicate symbols are chosen to describe properties of the gripping surfaces,
such as GrippingSurface,PlanarSurface,CylindricalSurface, Parallel and Opposite, and function symbols such as Normal, Axis, MaximumGripperWidth
and Minimum(;ripperWidth.
Figure 2 shows two gripper subclasses. Each subclass has a number of gripper instances associated
with it. The figure shows two example instances
for each subclass. The blocks which can be picked
up by a given gripper depend upon the shape of its
gripping surfaces. Gripper gl (Figure 2 (a))
effector
subclass
effector
subclass
C
gdRolng
surfaces
gripping
z
arm
instances
Instances
x
Gripper(gl)
MinimumGripperWidth
(gl, 0.25")
MaximumGripperWidth
(gl, 3.00")
GrippingSurface
(gl,Pl)
PtanarSurface(Pl)
GrippingSurface
(gl, p2)
PlanarSurface (P2)
Parallel (Normal(Pl),Normal(P2))
Opposite
(Pl,P2)
a) Gripper subclass gl
Gripper (g~)
MinimumGripperWidth
(g~,0.25")
MaximumGripperWidth
(g2,3.00")
GrippingSurface
(g2,cl)
CylindricalSurface
Arm (al)
Translate(al, (:El, O, 0))
Translate
(az, (0, 4-1, 0))
Translate (al, (0, 0,-I-1))
(el)
GrippingSurface
(g2,c2)
CylindricalSurface (c2)
Parallel (Axis (cl), Axis (c2))
Opposite
(Cl, 02)
b) Gripper subclass g2
c) Armsubclass al
Figure 2: Effectors for the robot manipulator domain.
two parallel planar gripping faces which are opposite to each other at a distance no greater than
3.00" and no less than 0.25". This property constrains the blocks that the gripper will be able to
grasp.
Grippers alone do not produce actions. They
must be used in combination with other effectors
such as robot arms to move and position them. A
subclass of arms and arm effector descriptions is
shown in Figure 2 (c). The relevant properties for
an arm are the directions in which it can mo~’e.
The arm in the example can translate in x, y and
z. Note that the arm is not allowed to rotate.
main, a goal corresponds to the task of grasping an
individual block. The explanation of the system
will begin with the goal of grasping block 2. The
operator shell for this goal is shown in Figure 4.
The engine makes a number of passes when developing operator descriptions until a knowledgebase
indicates that the operator is complete. Each pass
consists of the three steps shownin Figure 1.
In the example, there will be two passes. The
first pass will select a gripper and the second pass
will select the robotic arm and motions of the arm.
Figure 5 summarizesthe results of the first pass of
operator construction on this goal.
Inputs
The inputs to the construction engine includes the
set of effectors and a problem description. Figure 3
shows an example of the kinds of problems in the
robot manipulator domain. An initial state for this
domain consists of the initial position of the manipulator and a collection of blocks. The goal is to
pick up each of the blocks one at a time. The operator construction engine’s job is to identify ways
in which the grippers and arms can be combined to
grasp each of the objects. One could define more
complex goals, such as stacking the blocks, but simply picking up a block is sufficient to illustrate the
operator construction engine.
Step 1: Select Effector Class:, DomainKnowledge: Search Control:
Input: Goal (grasp block 2), partial operator description and effectors.
Output: An effector class.
This step identifies the class of effectors which may
be useful for completing the operator descriptions.
The Search Control knowledgeidentifies the appropriate class based on the effectors already present
in the partial operator description. In the example,
we have hard-coded the search to first look for grippers, then robot arms. Figure 6 shows the corresponding Search Control knowledge graphically. In
other domains, inferencing based on information in
the operator description may be used for a more
flexible search control.
Operator Construction
Engine
The construction engine is run on each goal in the
problem description. For the robot manipulator do-
Step 2: Match Effectors:,
4
Domain Knowledge:
ar:ima0,0u,ator
gripper
block. The same Matcher will construct a different
rule for gripper g2, because gripper g~ has different
clamping surfaces:
CylindricalSurface(zl) A CylindricalSurface(x2)
Opposite(zl,z2) A Parallel(Axis(zl),Axis(x2))
Distance(xz,z2) < 3.00" A Distance(mz,x2) _> 0.25"
Figure 3: Example of robot manipulator domain.
Operator Description "~
pre-conditions<none>
|
post-conditions
Grasp(block2)
I
Figure 4: Operator shell for goal 1.
Matchers:
Input: Goal, partial operator description and an
effector class.
Output: A set of binding lists ~, one binding list
for each match.
The MatchEffectors process compares the properties of each effector subclass in the given class with
the information in the current problem, in this case
grasping block 2.
The designer of the system is responsible for writing a Matcher for each effector class. The Matcher
constructs a match rule in first-order horns clause
form based on the conditions in an effector subclass and the partial operator description.
The
match rule for effector subclass e~ is of the form:
c~ =~ Match. Match Effectors finds all matches between this match rule and the current operator. A
set of bindings (ri is returned for each match. This
is repeated for each effector subclass in e and the
complete set of bindings is returned in E.
In the robot manipulator domain, a gripper
matches a block if the block contains faces with
the same class as the gripper’s gripping surfacqs.
In addition, the distance between the surfaces
in the block must be within the bounds of the
maximum gripper width. Therefore,
the match
rule agl created for gripper gl is:
PlanarSurface(zl)
A PlanarSurface(x2)
Opposite(x1,z2)AParallel(Normal(xl), Normal(z2))A
Distance(x1,x2) _< 3.00" A Distance(x1,x2) _> 0.25"
where zl and x2 are variables over the faces in a
Figure 5 shows the match attempts for the grippers on block 2. First, gripper gl is comparedwith
block 2, shown in match attempts (a) through (c).
The attempt in (a) fails because the matcher tries
to match planar clamping surfaces in gripper gl
with cylindrical faces in the block. The second
and third, (b) and (c), are matches because
faces in the block are planar, opposite to each
other and within the allowed distance for the gripper. These two matches result in two binding lists:
O’1 : {arl/f2, Z2/f3} and as : {zl/fl, z2/f6}, respectively. There would actually be two more matches,
where the bindings for Zl and z2 are swapped for
each list, but these have not been shownin the interest of space. Next, gripper g2 is compared with
block 2. Only one match is found since the block
contains only one pair of cylindrical faces. This
results in the binding list: ~r3 : {zl/f4, z2/fs}.
If an effector match is not found for the goal,
then that effector is not a valid way to achieve the
goal.
Step 3: Construct Operators:, Domain Knowledge: Constructors:
Input: A partial operator description and a set
binding lists E.
Output: A set of instantiated operators.
A new operator is created for each of the matches
found in the previous step according to the rules in
the Constructors knowledge base. The constructor
for grippers adds a pre-condition that each face in
the block which matched a gripping surface must be
clear. Post-conditions are added which state that
after the object is grasped, each of these faces in
the block will be gripped. In the example, there
were three matches for goal 1. Therefore, there are
three new partial operator descriptions, shown at
the bottom of Figure 5.
The operators are not yet complete because, in
addition to finding clamping surfaces, they also require motion to move them next to the block. The
first two partial operators in Figure 5 require rotation to allow the gripping surfaces in the gripper to
be oriented with the surfaces to be gripped in the
block. Translational motion will also be required to
position the gripper over the block. Therefore, the
partial operators are not yet complete. The third
partial operator does not require rotation, but it
does require translation to move the gripper over
Pass I
Goal 1
Select
Effector Type
/
[ effector type: grippers]
/
internal
blackboard
gripper 1 matchrule
gripper 2 matchrule
.
Match
Effectors
no match
match1
match2
needs
cylindricalfaces
¯ ,,
match3
Construct
Operators
no match
Operator
Description"] [~ OperatorDescription
OperatorDaacrlptlon
pre-conditlonsClear(f2)
~’C;lear(fl)
/ / pre-conditlons
Clear(f3
Clear(f6
post-conditionsGrasp
(3~ock2)// post-conditions
Grasp(b~l~)
Grip (pl,f2) /
Grip(pl,f6)
Grip(p2,fl)
pre-conditlonaClear(f4)
/
Clear(fS)
J
post-conditions
Grasp(block2)
I
~..~2
Partial OperatorI
f~ff3
Qflp(ci,f4)
6
Partial Operator
2
Partial Operator
3
Figure 5: Pass 1 of operator construction on goal 1.
Gripper
the block. The constructor will add these motion
requirements to the problem description and pass
the partially developed operators back to Select Effactor Class.
Onthe second pass, Select Eft’actor Classwill pass
the arm effectors to Match Effectors. Since there
is only one arm effector in this example, the arm
matcher will check to see if it has the motion capabilities required. Unfortunately, the arm is not
able to rotate, so it will not be able to orient the
gripper for partial operators 1 and 2. Translation
motion for partial operator 3 is found and a new
operator is constructed.
Figure 7 (a) summarizes the partial operators
constructed for the first goal of grasping block 2.
An "X" indicates that that branch of the search
was terminated because an effector to add to the
operator description was not found.
A similar process is performed for the second
goal, grasping block 1. Figure 7 (b) shows the
search for operators for this goal. In this case, no
Arm
Figure 6: The SearchControl knowledgefor the example.
complete operators could be found because the arm
cannot rotate.
The completed operator descriptions
are returned as output from the construction process.
For this example, there was only one valid operator: grasping block 2 with gripper 2. Given the
current set of effectors, there is no way to pick up
block 1. However, if an arm with rotational motion
is added, there will be more options for grasping the
blocks. The operators are passed on to the planner
which must select which operator to use for each
goal and sequence the operators into a plan.
6
OperatorDuorlptlon -~
pre~condltlons
,morw>
post con~stlon.
Gm,p(block2)
InltlallzatIon:
Operator
8helll
i
OperatorDescrlptlon
OperatorDesodptlon
-~r OperatorDescdptlon)
pre-oonditJons
Clear,2
pre-co~lUo~
Ctearfl
pre-concltt~ons
Clear
f4
C~ikrl~l
Clearl,21
.... I,~’l /
PaSS
1:
/ poat-cond~Q~s
Gra~(block,?.)poat.cond41km=
Grasp(l~oc~)l
Gdppl,f2
Gdp
I)1f6
/ polt-co~it~*Gmsp(bk:ck2)l
Gdpo1f4
GripperEffectors
//
OperatorDescription
X
Ckpar
14
.......o.,I,:l
Grup(~ock2)
X
Pills 2:
ArmEffectors
G~pol M
At (gr;pper2,
Nock2
pos~on~
[
b) Operator construction for goal
a) Operator construction for goal
Figure 7: Results of operator construction for robot manipulator example.
(a) stock
(c) delta volumne
Figure 8: An example machining problem.
Case
Study:
Machining
Process
Planning
The concept of operator construction was developed to address the challenges found in the domain of process planning for machined parts. This
domain is more challenging to represent than the
robot manipulator domain because the space of
possible actions is muchlarger and there are more
complex interactions amongthe effectors. Machining is the art of creating parts by removingmaterial
from a piece of metal called the stock, which represents the initial state. Figure 8 shows the stock
and the goal, the part to be created, for an example
machining problem. The part and stock are represented as boundary representation CADmodels
which describes the vertices, edges and faces that
form the boundary of the object. There are three
classes of effectors used to create shapes in a part:
cutting tools, which remove material from a part,
machine tools, which move the cutting tools in a
part, and fixtures, which hold the part fixed in various orientations. These effectors can be combined
in manydifferent ways to produce a wide variety of
shapes in the part. Each combination of effectors
represents a method for creating a shape. The goal
of machining process planning is to select methods
for creating each of the shapes in the part and then
select and order the methods into a high quality
plan that avoids harmful interactions among methods.
The ability to perform knowledge acquisition is
an important concern for this domain. Each machine shop will have its own set of equipment and
will need to customize a computer-aided planner
to fit the environment. As the equipment changes
from day to day, due to availability of equipment
or the addition of custom tools, the system must
be maintained to reflect the changes.
Anintegral part of process planning is identifying
which shapes can be made in a part and selecting
machining methods for creating each shape. The
shapes that can be made and the ways in which
they can be machined depend upon the set of available equipment. A computerized planner must take
the available equipment into account when deciding
what shapes can be made and how it can make each
shape. Because each machine shop has a slightly
different set of tools and fixtures to use and the set
of equipment may change from week to week. Shops
with different resources mayneed to produce differ-
7
EffectorGlasses
Cutting Tools
fiat endmlllball endmillchqmfere~,
ddll sq bclass"~| IJ
Machine Tools
Fixtures
vise
i ’’
MachiningMethodParameters
Removal
Volume
Part Orientation
CuttingToolShape/Orientation
Tool Motions
FixtureConfiguration
Machining’Method
Combines
effectors:
drill, 3-axismachine
tool,vise,sinetable
Figure 9: An example of howmachining equipment is combined to create machining methods.
ent plans, therefore, they must be able to customize
the planner to reflect the resources they have. The
traditional operator-based representations are unwieldy in this domaindue to the difficulty of maintaining an operator knowledge base.
This section describes MEDIATOR, a portion of a
manufacturing planning system developed by the
authors that uses effector-based operator construction to generate a set of methodsfor creating shapes
in a part.
This section shows the results of MEDIATOR
for
the example problem in Figure 8 and the effector
set in Figure 9. Because of space constraints, only
the results of each operator construction pass will
be shown. The description is kept at a fairly high
level. For more information, the reader is referred
to (Gaines, Castafio, ~ Hayes 1996; Gaines & Hayes
1997).
Effectors
in
the
Machining
ments and shape producing capabilities. Effectors
must be combined to produce cuts in the part. Figure 9 shows a manufacturing method for drilling a
hole. This method combines a drill, a 3-axis mill,
and two fixtures: a vise clamp and a sine table.
The vise is mountedon the sine table and grips the
part. The sine table provides a rotated orientation
for the part.
Figure 10 shows a possible operator for describing this method. The operator states that, if the
drill is combined with the downwardmotion of a
3-axis mill, clamped with a vise and tilted with a
sine table, then a cylindrical hole will be created.
While it is possible to approximate the shapes that
the equipment can produce with operator descriptions, a large numberof operators will be required.
Furthermore, it may not be possible to completely
describe all of the possible shapes that can be created. Instead of using operators, MEDIATOR
uses
the effector-based operator construction model to
construct operators as needed given the properties
of the available equipment.
Domain
The shapes that can be created in a part are closely
associated with the available machining equipment.
Figure 9 showsthe three class of effectors in the domain: cutting tools, machinetools and fixtures. For
each effector class, there may be manysubclasses.
For example, Figure 9 includes some cutting tool
subclasses. Each effector class has its ownrequire-
8
OperatorSchema
name:
drill-hole-with-drill-titlted
effect:remove
cylindricalvolume
precond:
holeaxisII to drill axis
1
generates a volumecalled the delta volume and represents all the material which must be removed
from the stock to create the part. Figure 8 (c)
shows the delta volume for the example part. Any
face in the delta volume and in the part is a
face that requires machining. In this case, faces
fl, f2, f3, f4 and f5 require machining. The example will illustrate the construction of operators for
creating face fl.
Figure 11 shows the Search Control for
MEDIATOR. MEDIATOR makes three passes during
operator construction, one for each effector type.
MEDIATOR
first identifies cutting tools for creating the surface. Then machine tools are found to
provide motions for the cutting tools. Finally, fixturing devices are selected for clamping the part.
Figure 13 summarizes the search for operators for
this example.
Pass 1: Effector Class: Cutting tools.
During this pass, each cutting tool subclass is compared with fl. The matcher identifies which cutting tool shapes can create the face. It also identifies approach directions, directions from which the
tool can approach the face, for each matching tool.
Only the flat endmill and chamfered custom mill
matched. There were three approach directions
found for the flat endmill and a single approach
direction found for the custom mill. The postconditions of the constructed operators identify the
part faces which can be machined with this operator. Notice that each operator is able to machinea
different set of faces.
Pass 2: Effector Class: Machine tools.
This pass identifies machine tool motions that will
be required to machine the surfaces. It also checks
to see if the cutting tool will collide with the part
at the given approach direction. Motion is found
for each of the partial operators, however, two operators are markedas invalid because the tool will
collide with the part if the operator is used. The
machine tool constructor combines the cutting tool
with a machine tool by sweeping the cutter along
a path to generate the volume that the operator
will remove from the stock. This volume is added
as a post-condition of the operator. The volumes
for each operator are different because they were
generated with different effector subclasses.
Pass 3: Effector Class: Fixtures.
The fixture matcher finds faces in the part that
match the seating and clamping surfaces in the vise
and allow the part to be oriented with respect to
the approach direction of the operator. There are
two possibilities for each of the operators from Pass
2 resulting in four operators at Pass 3.
The construction process will be repeated for
each surface requiring machining in the part. Each
operator contains a different set of pre-conditions
and post-conditions. Either of the operators using
Figure 10: A possible operator description for the
method in Figure 9.
Cutting Tools
Machine Tools
Fixtures
Figure 11: The Search Control knowledge for
MEDIATOR.
TOOL-EDITOR: An Effector-Based
Knowledge Acquisition
Tool for
o"
MEDIATOR
One of the benefits of an effector-based representation is that it facilitates knowledgeacquisition from
users who may not be programmers or AI planning experts. A knowledge acquisition tool for an
effector-based planner solicits information for new
effector subclasses allowing users to describe the
properties of the effectors they wish to add.
To demonstrate the usefulness of the effectorbased approach with respect to knowledge acquisition, we developed a knowledge acquisition tool
for the cutting tool effector class. The result is the
TOOL-EDITOR
system. Figure 12 shows a screen
capture of the TOOL-EDITOR
user interface.
For
the cutting tool effector class, the user must describe the shape and constraints on the dimensions
of the tool.
The user specifies the shape by sketching the
tool’s profile. An example profile is shownon the
left side of Figure 12. The right side contains a
three dimensional rendering of this tool. The dialog boxes at the top allow the user to add new
segments to the tool profile, and attach constraints
to the segments to specify the allowable dimensions.
In the example, the user is adding constraints on
the length of a line segment. The lower dialog box
contains detailed information, such as the position
of the segment vertices, on the segments in the profile.
When complete, TOOL-EDITORsaves the new
tool to a file that is loaded by the MEDIATOR
system. The next section will briefly describe how
MEDIATOR
uses this information to identify the
shapes that these tools can create.
MEDIATOR
MEDIATORgenerates operators for each face in the
part that requires machining. These faces are identified by subtracting the part from the stock. This
9
\
Figure 12: TOOL-EDITOR.
the chamfered custom mill from Figure 13 will machine all of the required face in the part and, therefore, satisfy the entire problem description. However, if the flat endmill operators are used, additional operators will be required to machine faces
f3 and f4.
All of the operators found for creating each surface are passed to the setup planner. The setup
planner selects operators for machining each of the
surfaces and orders the operators into a process
plan, which, when applied to the stock will result
in the final part.
Evaluation
of
cutting tools to the system is a straightforward process. Users can add new cutting tools by sketching
their profile in TOOL-EDITOR.
MEDIATOR
uses this
information to infer the shapes the tools can created when combinedwith the other pieces of equipment. Wefeel this is a significant improvement in
the maintainability of a system over previous approaches which required the user to describe the
types of shapes that a given cutting tool can create.
To evaluate the robustness of the system, we
compared the options that MEDIATOR
produces for
a number of parts with the options produced by
a human expert and, when available, the options
produced by other automated systems in this domain. MEDIATOR
found every option that the human found. In some cases, MEDIATOR
found options that the humanexpert overlooked, but when
pointed out by MEDIATOR, decided that they were
useful. MEDIATOR
has also been shown to find more
options for machining faces than other automated
systems.
Based on these results, we conclude that using
the operator construction approach, MEDIATOR is
MEDIATOR
Weevaluated MEDIATOR
to assess the benefits of
adopting the operator construction approach in t~e
machining process planning domain. In particular,
we were interested in evaluating the maintainability
and robustness of the system.
To evaluate the maintainability of the system, we
ran MEDIATOR
on a number of parts with different sets of cutting tools and fixtures. In each case,
MEDIATOR
produces a different set of results when
supplied with different equipment sets. Adding new
l0
Operator Deecrlptlon
I
~n~
post-conditionsMachined(fl)
Initialization:
fS~.l.19f5
Pass 1:
Cutting Tool
Effectors
Operator
Des~
pre-conditionsApproach
(0,0,-I)
post-condltig~Ls
Machlned
(fl,f2,f3)
I
( Operator Description
pre-condltions
,~pproach
(-I,0,0)
post-conditions~j~
Machined
(fl,f2)
Operator Description
pra-condltlons
Approach
(1,0,0)
post-conditions
Machined
(fl,f3)
Operator Descrlptlon
pre-condtttons
Approach
(0,0,-1)
post-conditions
Machined
(fl,f2~f3,
~
I~
I
~ f4,f5)
Operator Description
l
pre-condltlonsApproach
(0,0,-I)I
post-conditlons
Machlned
(fl,f2,f3,1
I
[ :::::t?:r ?eaA: r:roPtalch(0,0,.,)
Pass 2:
Machine Tool
Effectors
I
Pass 3:
Fixture
Effectors
Operator Descrlptlon
f Operator Deecrlptlon
pre-conditlonsMachined
(f6,fg)
pre-conditions
Machined
(f7,fS)
post-conditions
Machined
(fl,f2,
post-conditions
Machined
(fl,f2,
f3,v1)
f3,vl)
Operator Deecrlptlon
pre-conditions
Machined
(f6,f9)
post-conditions
Machined
(fl,f2,f,~
f4,f5,v2
Operator Description
]
pra-condltlons
Machined
(f7,fS)
’/ °st’c °~~ln ed ~4f If’sf ,2’~’
Figure 13: Operator construction for example part.
easier to maintain and more robust in its ability
to reason about the actions it can perform, than
previous approaches.
’"
cific properties of the goal it must achieve. This refinement process is similar to the refinement of the
developing operator description in operator construction.
The difference is that MOLGEN
has a
pre-defined set of operators, while the operator construction engine does not explicitly represent all of
the possible operators. Instead, it constructs them
when needed.
In this paper, the effector-based operator construction process is demonstrated for the domain
of process planning for machined parts. Other systems that perform similar tasks in the machining domain include (Joshi ~ Chang 1988; Vandenbrande & Requicha 1993; Jong & Fuchs 1994;
Han & Requicha 1995; Shah, Shen, & Shirur 1994;
Gaines, Hayes, & Kim 1995). Systems which perform some form of operator construction in this
domain include include (Gupta e~ al. 1994; Stage,
Henderson, ~ Roberts 1997; Laxmiprasad & Sarma
1997; Lee 1997). The main difference between these
systems and MEDIATOR
is that MEDIATOR
handles a
larger set of machining equipment and MEDIATOR
is
easier for non-programmers to customize. Wehave
also found that MEDIATOR
identifies more options
for machining some parts.
Research to improve the development of actionbased knowledgebases can be divided into those using knowledgeacquisition tools and those using ma-
Related
Work
Representations
of a planner’s knowledge have
ranged from the expressiveness of situation calculus (McCarthy 1968) to more restrictive representations such as STRIPS(Fikes & Nilsson 1971) and
propositional STRIPS(Bylander 1994). Other representations include the Action Description Language (ADL)(Pednault 1989), a middle-ground
tween STRIPSand situation calculus, and Hierarchical Task Networks (HTN) (Erol, Hendler, &
1994), which emphasize methods for carrying out
specific tasks. Each of these representations make
explicit the actions in the domain. For some domains this can lead to planners that are difficult
to maintain and adapt because the actions contain
knowledge about a set of domain effectors. When
domain effectors change, the user may be required
to rewrite large portions of the knowledgebase.
There have been other planners which have
shownelements of the effector-based operator construction process presented in this paper. Stefik’s
MOLGEN
is perhaps the most closely related AI
planner (Stefik 1981). MOLGEN
has a set of abstract operators which it refines based on the spe-
ll
chine learning techniques. Chien developed tools
to help detect incomplete Or inconsistent operator
descriptions and identify missing operators (Chien
1996). Machine learning techniques have been used
to add information to incomplete operator descriptions. Techniques for learning include experimentation (Gil 1993), inductive learning and simulation (DesJardins 1994), and observation (Wang
1995). These approaches assist in the difficult task
of developing and maintaining an operator knowledge base. However, our approach is to use a representation that allows easier maintenance by separating out the rapidly changing portions of the
operator descriptions (the effeetors) from the rest
of the domain knowledge.
Conclusions
The effector-based operator construction model
has been successfully implemented for the complex practical domain of manufacturing planning
in MEDIATOR, along with a tool editor that allows
users to quickly update effector descriptions. In
the future, MEDIATOR
will be expanded to handle a
broader family of machining domains such as turning and mill-turning. Wealso wish to investigate
the application of effector-based operator construction to other planning and design domains.
Acknowledgments
This work was funded by the Department of Energy
1996 Predoctoral Integrated Manufacturing Fellowship. Wewould also like to thank Mike Westjohn
for his machining expertise. TOOL-EDITOR
was developed within the graphical environment of Bentley System’s MieroStation Modeler using the MicroStation Development Language. MEDIATOR Was
developed using the Acis 3DToolkit from Spatial
Technology.
2
Effector-based operator construction offers an alternative representation for generating operator instantiations
for a given goal. The construction
process replaces the operator match and instantiation process of the planner. The remainder of
the planner can remain the same. In this model,
the planner does not use a set of pre-defined operator schemas. Instead, the domain knowledge
that is typically represented in operator schemas
is divided into several parts: a set of effector descriptions, knowledge about constraints and rules
on how they may be combined and used, and a more
general operator construction engine combines the
component effectors to to create operator instantiations to satisfy each specific goal in the context
of the problem at hand. Advantages of the operator construction method include easier maintenance for many important domains (provided that
the changes do not take the planner outside of the
domain family defined by the construction engine),
focus on the rapidly changing characteristics of the
planner (in manydomains, it is the effectors that
change rapidly), and the possibility of maintenance
by a system user who although competent in the
domain may not be versed in either AI plannir/g
concepts or programming. Maintenance is easier
largely because in these domains, it is often easier
for domain users to describe the physical characteristics of the effectors than it is for them to write
the corresponding operator descriptions.
This method is useful in domains where there are
wide variety of actions which are formed by combining effectors. However, the model is not suitable for all domains. In particular, there must be
a way to correlate effector matching and operator
construction from the properties of effectors. For
example, a medical domain may not be appropriate for the effector-based model because much of
the required information is obtained from empirical observations. There may not be a sufficient
domain theory to predict howdrugs will interact.
References
Bylander, T. 1994. The computational complexity of propositional STRIPSplanning. Artificial
Intelligence 69(1-2):165-204.
Chien, S. A. 1996. Static and completion analysis for planning knowledge base development and
verification. In Drabble, B., ed., Third International Conference on Artificial Intelligence Planning Systems, 53-61. Edinburgh: AAAIPress.
DesJardins,
M. 1994. Knowledge development
methods for planning systems. In Fall Symposium
on Learning and Planning: On to Real Applications, 34-40.
Erol, K.; Hendler, J.; and Nau, D. S. 1994. HTN
planning: Complexity and expressivity.
In Proceedings of the twelth National Conference on Artificial Intelligence, 1123-1128.
Fikes, R. E., and Nilsson, N. J. 1971. Strips: A
new approach to the application of theorem proving to problemsolving. Artificial Intelligence 5(2).
Gaines, D. M., and Hayes, C.C. 1997. A
constraint-based algorithm for reasoning about
the shape producing capabilities of cutting tools
in machined parts. In ASMEDesign for Manufacturing Conference.
Gaines, D. M.; Castafio, F.; and Hayes, C. C.
1996. Reconfigurable feature recognition for an
adaptable maintainable CAD/CAPPintegration.
In ASMEDesign Engineering Technical Conference.
Gaines, D. M.; Hayes, C. C.; and Kim, Y. S. 1995.
Negative volume to process methods mapping for
CAD/CAPP
integration.
In Proceedings of IJCAI
Intelligent Manufacturing Workshop, 104-115.
12
Gil, Y. 1993. Learning by experimentation: Incremental refinement of incomplete planning domains. Technical-Report ISI/RR-93-338, Information Sciences Institute.
Gupta, S. K.; Nau, D.; Regli, W.; and Zhang,
G. 1994. Building
MRSEVmodels for CAM
applications.
Advances in Engineering Software
20(2/3):121-139.
Han, J.-H., and Requicha, A. A. G. 1995. Integration of feature based design and feature recognition. In ASMEInternational Computers in Engineering Conference.
Jong, M. T. D., and Fhchs, A. 1994. PART:
Advanced manufacturing technology white paper.
Technical report, ICEMTechnologies.
Joshi, S., and Chang, T.C. 1988. Graphbased heuristics for recognition of machinedfeatures from a 3D model. Computer-Aided Design
30(2).
Laxmiprasad, P., and Sarma, S. 1997. A featurefree approach to 5-axis tool path generation. In
ASMEDesign Technical Conference.
Lee, Y.-S. 1997. Admissible tool orientation
control of 5-axis complex surface machining for
CAD/CAMsystems. In ASME Design Technical
Conference.
McCarthy, J. 1968. Programs with commonsence.
In Minsky, M. L., ed., Semantic Information Processing. MITPress. 403-418.
Pednault, E. P. D. 1989. ADL: Exploring the
middle ground between STRIPSand the situation
calculus. In Knowledge Representation.
Shah, J.; Shen, Y.; and Shirur, A. 1994. Determination of machining volumes from extensible sets
of design features. In Shah, J., et al., eds., Advances in Feature Based Manufacturing. Elsevier.
129-157.
Stage, R.; Henderson, M.; and Roberts, C. 1997.
A framework for representing and computing tool
accessibility.
In ASMEDesign Technical Conference.
Stefik, M. 1981. Planning with constraints (MOLGENpart 1). Artificial Intelligence 16(2).
Vandenbrande, J. H., and Requicha, A. A. G.
1993. Spatial reasoning for the automatic recognition of machinable features in solid models. IEEE
Transactions on Pattern Analysis and Machine
Intelligence 15(12):1269-1285.
Wang, X. 1995. Learning by observation and practice: An incremental approach for planning operator acquisition. In 12th International Conference
on Machine Learning.
13