1 / 19

# Knowledge Engineering for Planning Domain Design - PowerPoint PPT Presentation

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]

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

## PowerPoint Slideshow about 'Knowledge Engineering for Planning Domain Design' - tass

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Knowledge EngineeringforPlanning Domain Design

Ron Simpson

University of Huddersfield

Automated Planning [A. I. Planning]

Mars Rover Courtesy of NASA/JLP-Caltech

Kitchen Rover

• 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

• 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

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

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

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

• 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

• 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]

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

Transitions

Require Objects at State

Break Association

Forget Car

Transition

Dependent on Source

Both satisfy next(x,y)

Record car

Must Occur Together

• Graphical “Life History” Editor to define domains

• Graphical editors to capture “Instance Information”

• Auto generate specification from diagrams.

• Run integrated planners to solve defined problems.

• Graphically animate plans produced.

• Manually create plans in a visual stepper.

• Translate specifications to PDDL.

Available States for Sue

State for Sue

Known

Objects

Animation

View

Plan

Inspect Object State

Emerging Plan

Available Actions

Add Next Action – Choose action parameters

• 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

Event : when

level > capacity

Process:

Level = flow * #t

Process Trigger

flow(Bath) = flow(Tap)

Process

Precondition

Time line

turnOn

turnOff

flood

turnOn

filling

process

plugIn

• 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?