School of Computing and Mathematics, University of Huddersfield The Induction of Operator Descriptions from Examples and Structural Domain Knowledge Lee McCluskey Beth Richardson Department of Computing and Mathematical Sciences, The University of Huddersfield

School of Computing and Mathematics, University of Huddersfield Background n Acquiring and maintaining planning domains is acknowledged to be a major problem. Operators can be hard to construct and debug and planners aren’t built to help in debugging. n We want non-planning experts to use our planning technology. This requires a higher level interface than PDDL ‘code’ n Complex domains make these problems more acute

School of Computing and Mathematics, University of Huddersfield Thrust of this work.. To develop an induction method for creating planning operators that works.. n in complex hierarchical domains n in the context of an “acquisition method” supported by a planning engineering environment (- something I’ve argued for at past SIGs..) It should reduce the complexity of the creation process by abstracting away “mathematical details” and reusing off the shelf templates. Eventually it should be usable for non-planning-experts

School of Computing and Mathematics, University of Huddersfield Operator induction in the past.. Tim Grant - (‘96) induction of operators from pairs of states (POI algorithm) ‘unordered observations’ --- acquisition --> object domain theory --- induction --> operators X. Wang - (‘96) induction of ops from operator headings, types and pre- and post states. Repair carried out through ‘planning practice’. Huffman et al - (‘91) extending and correcting planning domain theories - more refinement that initial operator acquisition

School of Computing and Mathematics, University of Huddersfield GIPO (described in separate paper + demo) n An ‘open’ tools environment supporting domain acquisition and domain modelling - the tools are integrated via a GUI around the OCL / OCL h language and associated method. n The hardest part of planning domain modelling is designing the operators - GIPO + OCL eases acquisition, but the user still has to mess around with parameters!

School of Computing and Mathematics, University of Huddersfield Specific goal of this research n Use GIPO to create a PARTIAL domain model n Induce operators using sample operator sequences and simple input if required (mouse clicks) n Either use Theory Revision techniques or User Intervention (with the help of ‘standard’ validation tools) to correct bugs. [Recall induction does not give us the correct answer!]

School of Computing and Mathematics, University of Huddersfield Opmaker - INPUT in OCL/OCLh Offline: Partial domain spec, got via GIPO or other acquisition method: n Objects, object classes (sorts), predicates: objects(car,[car1,car2]). objects(tent,[tent1]) objects(person,[sue,fred]). objects(couple,[couple1]) objects(place,[keswick,helvelyn,fairfield,honister,derwent]) predicates([ up(tent,place), down(tent,place), loaded(tent,car,place), in(person,car,place), fit(person,place), tired(person,place), at(car,place), partners(couple,person,person), walked(couple,place), next(place,place)])

School of Computing and Mathematics, University of Huddersfield Opmaker - INPUT n Substate classes - for each dynamic sort substate_classes(person,Person,[ [tired(Person,Place)], [fit(Person,Place)], [in(Person,Car,Place)]]). substate_classes(couple,Couple,[ [walked(Couple,Place),partners(Couple,Person1,Person2)] ]). substate_classes(tent,Tent,[ [up(Tent,Place)], [down(Tent,Place)], [loaded(Tent,Car,Place)] ]) substate_classes(car,Car,[[at(Car,Place)]]) n Atomic Invariants atomic_invariants(partners(couple1,sue,fred),next(keswick,helvelyn), next(helvelyn,fairfield), next(fairfield,honister), next(honister,derwent)])

School of Computing and Mathematics, University of Huddersfield Opmaker - INPUT Online: Training sequence, initial state, and user ‘clicks’! Example op sequence: put_down tent1 fred keswick load fred tent1 car1 keswick getin sue keswick car1 drive sue car1 keswick helvelyn getout sue helvelyn car1 unload sue tent1 car1 helvelyn put_up tent1 sue helvelyn getin sue helvelyn car1 drive sue car1 helvelyn keswick getout sue keswick car1 walk_together sue fred couple1 keswick helvelyn sleep_in_tent sue fred tent1 helvelyn

School of Computing and Mathematics, University of Huddersfield Opmaker - OUTPUT - A set of Operators in OCLh Operators are sets of TRANSITIONS A transition is of the form: (sort, sort variable, LHS => RHS) where: n A transition can be necessary, conditional, or null (the latter being a ‘prevail’ condition) n The LHS and RHS are substate expressions possibly containing static constraints (The Operator set can be output in PDDL ADL format if required)

School of Computing and Mathematics, University of Huddersfield OPMAKER -the step for each training op. Assume OP is NEW Input Op-name O1.. Oi.. On (1) for each dynamic object Oi in parameter list form LHS from current substate information on Oi ask user to CLICK on new substate class (2) match free variables in transitions with parameter list using sort structure as guide (3) add generalised atomic invariants to the operator using parameter list and sort structure as a guide Finally, record the actual object transitions of the training sequence

School of Computing and Mathematics, University of Huddersfield OPMAKER - for hierarchical operators HTN operators in OCLh are roughly of the form: (Transitions, Static Constraints, Temporal Constraints, Decomposition)

School of Computing and Mathematics, University of Huddersfield OPMAKER - to induce HTN operators 1. retrieve set of object transitions T that made up the training sequence. For any conditional transitions, make them into necessary if they did indeed change an object 2. Work out (hierarchical) 'start' and 'end' substates for each object using T to give the transitions. 3. Use primitive operator’s generalised atomic invariants to make up static constraints 4. Temporal constraints can be derived from transition sequences and primitive operators 5. Decomposition = generalised training sequence

School of Computing and Mathematics, University of Huddersfield RESULTS n The Hiking Domain: as shown in paper - a partial domain model was created, then a full operator set was generated by Opmaker, passing all local and global validation checks in the GIPO system. The resulting model was fed into Hoffman’s FF which solved the general hiking problem. This was all done in approximately 1 day’s development. n Other “Flat” domains: Briefcase World, Rocket World and Tyre World: full operator sets induced with little difference to hand-crafted

School of Computing and Mathematics, University of Huddersfield RESULTS: Hierarchical domains Results for Translog and Drum Store showed up problems: n inaccurate constraints: opmaker may generate unwanted constraints, and in some cases may miss necessary constraints. On the other hand it may throw up needed constraints that may not have been thought of. n inaccurate pre-conditions: especially in the hierarchical case, the LHS is not so easy to generate accurately. n undergeneralised parameters: The rule of generalising constants to variables in the object's primitive sorts is sometimes too restrictive. For example, the load_package induced operator in the Translog worlds was only applicable to loading packages into trucks if the training example used involved trucks.

School of Computing and Mathematics, University of Huddersfield RESULTS e.g. HTN operator method(move_package(Truck_2,Pk_3,Ac5), % dynamic constraints [], % list of necessary transitions [sc(truck,Truck_2,[at(Truck_2,City3_cl1),moveable(Truck_2),available(Truck_2)] => [at(Truck_2,Ap1),moveable(Truck_2),available(Truck_2)]), sc(package,Pk_3,[at(Pk_3,City3_cl1),uncertified(Pk_3)] => [at(Pk_3,Ap2),waiting(Pk_3),certified(Pk_3)]), sc(aircraft,Ac5,[at(Pk_3,Ap1)] => [at(Ac5,Ap2)])], % static constraints [ in_city(Ap1,City3), in_city(City3_cl1,City3), in_city(City3_cl2,City3)], % temporal constraints [before(1,2),before(2,3),before(3,4),before(4,5),before(5,6),before(6,7),before (7,8),before(8,9)], % decomposition [pay_fees(Pk_3), commission(Truck_2), local_move(Truck_2,City3_cl1,City3_cl2), load_package(Pk_3,Truck_2,City3_cl2), local_move(Truck_2,City3_cl2,Ap1), unload_package(Pk_3,Truck_2,Ap1), load_package(Pk_3,Ac5,Ap1), fly(Ac5,Ap1,Ap2), unload_package(Pk_3,Ac5,Ap2)]).

School of Computing and Mathematics, University of Huddersfield Future Work n Induction of recursive hierarchical operators, with more distinctive HTM features (e.g. more conditional filters) n full integration into GIPO n use of theory refinement to debug initial operator set n evaluation with novice users (students?)

School of Computing and Mathematics, University of Huddersfield Conclusions Opmaker relies on the following cues to help induce operators: n a partial domain model of object sort and behaviour n the completeness and coherence of the example sequences of operators n high level user input, when necessary, in the form of one `click' indicating a choice of substate class It appears to help a great deal in operator acquisition, but a full evaluation is ongoing..