knowledge engineering for planning domain design ron simpson university of huddersfield

Knowledge Engineeringfor

Planning Domain Design

Ron Simpson University of Huddersfield

Automated Planning [A. I. Planning]

Mars Rover Courtesy of NASA/JLP-CaltechKitchen 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

ActionDescriptor

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

TentProperty : LocationValue present in allidentified states.

Transition of Tent:Property Value ChangingLocation to Location

TransitionState Changing

TransitionProperty Value ChangingSatisfies next(x,y) nextStage(w,v)Constraint – NumberSatisfies couple(x,y)

Person

Car

Tent

PersonProperties: Location Stage

Hiking Domain Example 2

Add AssociationRecord car

Break AssociationForget Car

TransitionsRequire Objects at State

TransitionDependent on SourceBoth 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

KnownObjects

State for Sue

Available States for Sue

Animation of Plan Solutions

Plan

Inspect Object State

AnimationView

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 : whenlevel > capacity

Process Triggerflow(Bath) =

flow(Tap)

ProcessPrecondition

Stepper For Hybrid Automata

plugIn

turnOn

turnOff

turnOn flood

fillingprocess

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?