Formal Objects and Feature Associations in "ARGOS-II"

FORMAL OBJECTS AND FEATURE ASSOCIATIONS IN "ARGOS-II"

Michel CAYROL, Bernard FADE, Henri FARRENY

Laboratoire "Langages et Systemes Informatiques" Universite Paul Sabatier, 118 Route de Narbonne 31077 Toulouse Cedex FRANCE

ABSTRACT : ARGOS-II is a problem solving system developed at L.S.I. laboratory. Its purpose is to em­ body a general model of the decision function of a robot. After a brief global characterization of the system, an overview of the initial specialization process is provided. Then two interesting particula­ rities of the system are emphasized : "formal prospective aptitude" and "automatic control of feature associations". ARGOS-II generates action plans but also performs the execution monitoring. ARGOS-II is a pattern directed inference system. The "formal prospective aptitude" allows to continue to build plans even when some circumstances are unknown. They permit to avoid some awkwardnesses or failures and are open to learning. Not only does the "feature associations" mechanism deal with the heavy pro­ blem of updating the attributes of a group of objects involved in a unique action, but it also allows to easily create powerful demon functions useful for Artificial Intelligence programming.

I. CHARACTERIZATION OF AROOS-II (I]

1. ARGOS-II is first a problem-solver it ela­ borates the action plans by means of an inter­ preter of production rules. The rules are invo~ cated by using problem patterns and a pattern­ matching procedure. The search method is, funda­ mentally, of depth-first type in an implicit and­ or graph, with back~tracking control facilities. However there is no definite order in the repre­ sentation of the rules. Their disposition can be modified during the solving process owing to, mainly, the existence of s~veral explicit direc­ tives and also efficacious demon families.These directives and demon families are specially de~ signed to deal with rules (a kind of metarules). For example it is possible to inhibit -~or to awake-- rules conditionnally or not, temporarily or not. All these possible changes of the rule states are pattern directed. The solving process is not considered as terminated when a plan is produced : ARGOS-II realizes the plan monitoring execution (about the process of monitoring plan execution, see [5],[8],L9]).Besides, the separa­ tion of planning process and execution process is not sharp (as it happens rather frequently) : before the whole plan is built, actions can be performed, if it is necessary (deductions, per­ cep tions, interrogations, ... ).The ARGOS-II pro­ gram is written in TLISP-language (see [4]).
2. ARGOS-II is also a problem expression langua­ ge for Artificial Intelligence. lt contains many of the primitives 1mplemented in classical pro­ cedural languages or in more recent systems which use specifications by production rules

(see [3],[7],[13]. Among the possibilities to act on rules let us point out, not only the above quoted directives to inhibit,to awake or to fire (immediately), but also the facilities to state spontaneous triggering rules and demon rules.All the standard functions of TLISP may be used.

II. OVERVIEW OF THE INITIAL SPECIALIZATION PROCESS

The system maintains several separated associa­ tive networks by means of pattern-matching. Essentially"fact-memory","problem-memory","rule­ memory".For embedding ARGOS-II in a real context, the user initially provides four main kinds of knowledge :

1. facts in like-S-expressions form, e.g. : (BOX3 ASPECT (METAL BLUE) IN (ROOMI (5 10)))

• (y) (if-patfact (ROBOT* TAKEN <X *) then return)
• (o) (execute (POINT-IN-ROOM (<Y) (>Z)))
• (e:) (replace-problem (GO <Z) (APPROACH <X))

(r;) (record (plan (GRASP <X)) (updatf (modify (ROBOT *) (TAKEN <X)) D 1

The words "not", "if-patfact", ... "execute",etc ... are ARGOS primitives, The symbol "*" represents the operator of undiscriminate absorption (see [l4].We find several important knowledge modules in this rule : utility (a), subsidiary conditions for applicability (B), control de endin on facts (y), communication with envlronment (interfaces or knowled~e procedures (~) probTem~reduction (in two sub~problems here) (£), pr1mitive sub­ problem (terminal act of the considered robot) and world model updating (r;).

c) procedures written by means of ARGOS and TLISP primitives.Some of these procedures represent do­ main knowledge which is useful for internal de­ ductions or computations of the system (e.g. : a method for designing an itinerary, in the case of a moving robot),The others are interfaces bet­ ween the system and external processes (effectors captors,dialogue with the user).The procedures may be called from the body of the rules by AR­ GOS-primitives as 11 execute 11 .In this case, the formal call may contain a list of identificators for the results :e.g, : (execute (MEASURE-TEMPE­ RATURE (<OBJ <PLACE) (>X >Y >Z))) becomes after instantiation :. (execute (MEASURE-TEMPERATURE (WALLS UP) (>X >Y >Z))).The real list of results returned as value of MEASURE-TEMPERATURE is then matched with the pattern (>X >Y >Z), thus the results are affected to X,Y,Z.

d) problems in like-S-expressions form, e.g. (HND (OBJECT (HEAVY SOLID)))

III. FORMAL PROSPECTIVE APTITUDE

In planning phas1s, when a production rule is triggered, a part of its arguments receive ground values. Some other arguments may not be instan­ tiated until a posterior step of plan generation or until execution time, ARGOS-II affects an ori­ ginal symbolic identificator to these latter ar­ guments. Defining and dealing with such "formal objects" have already been done by SUSSMAN (see: "wishful thinking technique" in HACKER [II] and by SACERDOTI (see: "use existing objects critic" in NOAH E9J. In ARGOS-II the formal objects are systematically used, The plan generator can pro­ duce sequences like :

[CHOOSE-FREE (ANVIL)-->(>GOOS)] [LOCATE (<GOOS) ----->(>G006)] [TAKE (HAMMER) ------->(>GOO?)]

[BRING-TO (<G007 <G006)J

where : "CHOOSE-FREE" and "LOCATE" are planning aid procedures :· some occurrences of them did not succeed during planning and entailed the inser­ tion of corresponding steps into the plan to execute ; "TAKE" and "BRING-TO" are interfaces with terminal acts of the considered robot ; "(ANVIL)" or 11 (<G007 <G006) 11 are entry parameter lists; after "->" are described the (symbolic)

expected results of the execution ; we note 11 >X 11 for a variable "X" which must be instantia­ ted, 11 <X 11 the same variable after pattern mat­ ching instantiation, "GOOi" the original name of the ith encountered formal object.

After the above fourth step some assert i ons like 11 (ANVIL <GOOS AT <G006)" and "(HAMMER <G007 AT <G006)" will be recorded in fact-memory. These new data may be, in the following of the AR�O~ s work, matched with patterns like: "(*ANVIL >X* )" or "(* ANVIL ANVIL4 AT >Y *)". Besides, formal problems may be introduced in the data base and then solved. Such a technique often allows to avoid the awkwardnesses or even failures due t o a premature bounding. In spite of the lack of some specifications which can only be obtai ned at execution time, longer (i.e."more pros.pecti­ ve") plans can be designed. Besides, some impas­ ses which are independent of the unknown para­ meters can be detected. Let us emphasize that "formal objects" facilitate intermixing planning and execution monitoring, allowing to include perception-decision points in the plans to exe­ cute. At last the formal objects process may in­ troduce some kind of learning : a partially sym­ bolic plan, correctly executed may be interes­ ting to save as a resolution scheme (new rule) .

IV. AUTOMATIC CONTROL OF "FEATURE ASSOCIATIONS" The problem of the robot which carries a bag which itself contains a box is we ll-known : we have to conveniently update some related attri­ butes of a group of objects involved in a unique action. In ARGOS-II is implemented a dispositive which allows to link the transformations of a collection of variables with the modification of anyone among them. The chief primitive availa­ ble for the user for such a work is "associate": e. g.: (associate (VI add J sub I) (V2 id i d) . .. ... (Vi Fi Hi) ... ) In the above example is de ­ fined an association between the variables VI, V2 ... Vi ..· via the functions 11 addl 11 , 11 subl","id" , "id", ..· "Fi","Hi" .·· (addl,subl,id: standard­ TLISP-primitives).The association is implemen­ ted by linking VI, ..· Vi ·.. to a common variabl e (G004 in the provided example) created dynami ­ cally by the system at every use of "assoc iate":

• initially, the value of G004 equals the value of tiddl (VI)
• every demand of acces s to the value of Vi en­ tails an evaluation of Hi(G004)(Hi appli cat ed to value of G004) reciprocally,every mo­ dification of Vi en­ tails an updating of (only) G004,with the
• value Fi(Vi).

Let us emphasize that for any access or modif ication of Vi only one computation is done,to re­ late the Vi-value to the common variable value. I ndeed, not only explicit variables (as Vi) but also implicit variables (what we call "features'' may be handled with 11 associate 11 .In this case,the formal syntax is of the form : (associate (PI (FNI Fl HI)) ·.. (Pi (FNi Fi Hi)) .. ,) where Pl. ·· Pi... .ue patterns, FNI..,FNi. .. are feature names and P).,HI ·.. Fi,Hi ..· are LISP functions. e.g.:initially, thHe is in the data base : (PAINT-BRUSH .. ,COLOUR BLUE ..· ) (PAINT-BOX ,.,,COLOUR GREEN ... ). Let us con­ sider: (associate ((PAINT-BRUSH *)(COLOUR id id)) ((PAINT-BOX *)(COLOUR id id))).In this example, the first implicitly manipulated feature is the attribute following the prefix "COLOUR" in any datum able to match with the pattern "(PAINT~ BRUSH *)". Henceforth the features "COLOUR" of "PAINT-BRUSH" and "PAINT-BOX" will be considered as identical (features "COLOUR", i.e, here, the attributes following the prefixes "COLOUR").Let us note that, by side effects of the functions Fi and Hi, any procedure can be triggered,either when affecting a value to one of the associated variables or features, or at the moment of access to one of these variables (or features).We can write, for example, very practical procedures to control communications between the robot..-system and its environment ; e.g. : (associate (VI FUNCI FUNC2))

(define FUNCI (X) (print PLEASE X ?)(read)) (define FUNC2 (X) (setq HOWMANY (addl HOWMANY))X) Any modification of VI, like "(setq VI BIG­ VALUE)" will modify, in fact, the value of the common variable by call to "FUNCI".The value re­ turned by the computation of FUNCI, i.e.the va­ lue of the latter expression "(read) 11 ,is affec­ ted to the common variable, And for any referen· .ce to "VI", the value computed from the common variable by means of FUNCi is returned.Besides, "HOWMANY" counts the number of entries by "VI". l'he above example shows that, with "associate" primitive family,it is easy to create a new class of demons ; these demons are able not only to watch over the traffic into and out of data bases, but also to watch over the traffic to and from any variable or feature. The facilities provided by "associate" and other analogous primitives implemented in ARGOS-II extend the "AFFIXMENT" statement proposed in AL (see [6],[12])and the ideas. about "representation of actions that have side effects" implemented in AIMDS r 10]. They are adapted to current mechanisms used in pattern directed inference systems (e.g,:back-tracking) ..

V. CONCLUDING REMARKS

ARGOS-ti has been designed to be a general sys­ tem able to control the behaviour of a robot whose particular description is provided by the user. Industrial applications (computer aided production) are being studied. Among several other worth-considering directions of research for the ARGOS project, let us quote : the learning of plans ; the extension of the system ca­ pacities to interact with operator and to expli­ citate the (deep) reasons of its behaviour ; the fuzzification of the triggering mechanism of the production rules (see [2]).

VI. ACKNOWLEDGEMENTS

The authors wish to thank Professor Beaufils, Director of L.S.I. Laboratory, for his constant encouragements.