1 / 19

Knowledge Engineering for Planning Domain Design

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]

tass
Download Presentation

Knowledge Engineering for Planning Domain Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Knowledge EngineeringforPlanning Domain Design Ron Simpson University of Huddersfield

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

  3. 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

  4. 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

  5. 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.

  6. 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.

  7. 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

  8. 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

  9. 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]

  10. 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

  11. 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

  12. 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.

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

  14. Animation of Plan Solutions Animation View Plan Inspect Object State

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

  16. 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

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

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

  19. 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?

More Related