Knowledge Engineering for Planning Domain Design Ron Simpson University of Huddersfield

Automated Planning [A. I. Planning] Mars Rover Courtesy of NASA/JLP-Caltech Kitchen Rover

Domain Independent Planning Declarative Descriptions of Desired State of World [Goal State] Initial State of World Actions available to agents Pre Conditions Post Conditions Planning Problem Synthesise ordered sequence of actions to bring about Goal State

Levels of Ambition Classical Deterministic / Complete / Omniscient World described by lists of simple propositions. No numeric attributes. Actions add or remove propositions from world description. Time not represented Non Classical Add notions of time to actions Allow numeric attributes Non Deterministic / Incomplete Knowledge

Knowledge Engineering Formalisms Develop tractable formalisms capable of being reasoned with. Visualisation Develop tools/image systems to help users create and understand domain of interest. Refractor Develop transformation techniques to allow representations at differing levels of generality to co- exist.

Aims What To develop methods and tools to assist in the : Creation of planning domain specifications. To assist in the task of domain specification validation and testing. How Develop higher level conceptualisations as modelling aids and support these with software tools. Develop the object centric view of planning. Build a prototype environment [GIPO] to demonstrate the utility of the view. Scope Currently classical planning with extensions to HTN Planning and planning with timed processes and numeric properties.

Object Centric View Plans are strategies to bring about changes in the states of objects within the domain problem. Domain design can be done by charting the possible state changes of the participating object types. Assume all objects of same type have same potential. Tent State Description Action Descriptor

Generic Types Patterns of state transitions reoccur in many domain definitions. Domain definitions may be constructed by composing together common patterns of life histories. Mobile + Bistate = Portable

Prerequisites Rules for defining the States of object types. Identified by name – parameterised by object Ids Enhanced by properties Identified by property-name -parameterised by property value Rules for defining state transitions. Identified by name and links to source and target states. Rules for merging. Defines rendezvou between object transitions Or object states and Transitions. May augment state by adding association parameters to state predicates [See GIPO Help]

Hiking Domain – Example 1 Tent Property : Location Value present in all identified states. Transition of Tent: Property Value Changing Location to Location Transition State Changing Transition Property Value Changing Satisfies next(x,y) nextStage(w,v) Constraint – Number Satisfies couple(x,y) Person Car Tent Person Properties: Location Stage

Hiking Domain Example 2 Add Association Record car Break Association Forget Car Transitions Require Objects at State Transition Dependent on Source Both satisfy next(x,y) Must Occur Together

Tools Integrated into GIPO Graphical Life History Editor to define domains Graphical editors to capture Instance Information Auto generate specification from diagrams. Create task specifications. Run integrated planners to solve defined problems. Graphically animate plans produced. Manually create plans in a visual stepper. Translate specifications to PDDL.

Instance and Problem Description Known Objects State for Sue Available States for Sue

Animation of Plan Solutions Plan Inspect Object State Animation View

Manual Plan Creation [Stepper] Add Next Action – Choose action parameters Available Actions Emerging Plan

Representing Time and Numeric Properties Hybrid Automata State Change Instantaneous – These are actions may make changes to numeric properties and trigger processes Processes take time. Numeric properties may change as a function of time Events (State Change) may be triggered by processes. These - like processes happen as a result of actions

Filling Bath Domain Process: Level = flow * #t Event : when level > capacity Process Trigger flow(Bath) = flow(Tap) Process Precondition

Stepper For Hybrid Automata plugIn turnOn turnOff turnOn flood filling process Time line

Conclusion Does the graphical conceptualisation simplify the task? How do we measure this? What is the range of applicability of the technology? Planning seems to be ubiquitous but when is it worthwhile to specify the domain problem?