190 likes | 328 Views
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]
E N D
Knowledge EngineeringforPlanning 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 Tent • 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. Action Descriptor State Description
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 Transition Property Value Changing Satisfies next(x,y) nextStage(w,v) Constraint – Number Satisfies couple(x,y) Tent Property : Location Value present in all identified states. Transition State Changing Tent Person Car Person Properties: Location Stage Transition of Tent: Property Value Changing Location to Location
Hiking Domain Example 2 Transitions Require Objects at State Break Association Forget Car Transition Dependent on Source Both satisfy next(x,y) Add Association Record car 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 Available States for Sue State for Sue Known Objects
Animation of Plan Solutions Animation View Plan Inspect Object State
Manual Plan Creation [Stepper] Emerging Plan Available Actions Add Next Action – Choose action parameters
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 Event : when level > capacity Process: Level = flow * #t Process Trigger flow(Bath) = flow(Tap) Process Precondition
Stepper For Hybrid Automata Time line turnOn turnOff flood turnOn filling process plugIn
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?