# 74'419 Artificial Intelligence 200506 - PowerPoint PPT Presentation

PPT – 74'419 Artificial Intelligence 200506 PowerPoint presentation | free to download - id: 1064c3-N2U5Z

The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
Title:

## 74'419 Artificial Intelligence 200506

Description:

### actions specified by preconditions and effects stated as formulae in (restricted) ... Hector J. Levesque, Raymond Reiter, Yves Lesperance, Fangzhen Lin and Richard ... – PowerPoint PPT presentation

Number of Views:34
Avg rating:3.0/5.0
Slides: 74
Provided by: jdur
Category:
Tags:
Transcript and Presenter's Notes

Title: 74'419 Artificial Intelligence 200506

1
74.419 Artificial Intelligence 2005/06
• Situation Calculus
• GOLOG

2
Review Planning 1
• STRIPS (Nils J. Nilsson)
• actions specified by preconditions and effects
stated as formulae in (restricted) First-Order
Predicate Logic
• planning as search in space of (world) states
• plan is sequence of actions from start to goal
state
• Partial Order Planning
• planning through plan refinement
• parallel expansion to satisfy preconditions
• causal links (effect of a used in precondition of
a')
• threats (effect of a negates precondition of a'
a'lta)

3
Review Planning 2
• Plan Decomposition / Hierarchical Planning
• hierarchical organization of 'actions'
• complex and less complex (or abstract) actions
• lowest level reflects directly executable actions
• planning starts with complex action on top
• plan constructed through action decomposition
• substitute complex action with plan of less
complex actions (pre-defined plan schemata or
learning of plans/plan abstraction, see ABSTRIPS)
• overall plan must generate effect of complex
action

4
Essentials of Situation Calculus
• Situation Calculus was introduced by John
McCarthy in 1969.
• It describes dynamic domains in FOL using
• situations (denote world states include world
history)
• actions (named, parameterized functions)
• axioms (to specify actions and domain knowledge)
• Planning (or reasoning with actions) in the
situation calculus is done through theorem
proving
• Infer a goal situation from the initial situation
using the given axioms.

5
Situation Calculus - Overview
• Situation Calculus is a specific, enriched FOL
language.
• Actions denote changes of the world and are
referred to by a name and a parameter-list (like
functions).
• Situations refer to worlds and can be used to
represent a (possible) world history for a given
sequence of actions.
• The special function Result or do expresses that
an action is applied in a situation.
• The effect (changes) and frame (remains) of an
action are specified through axioms.
• Planning in situation calculus involves
theorem-proving, inferring a goal situation from
the initial situation.
• The actions involved in a proof and the bindings
of their parameters represent the plan.

6
Situations
• A situation corresponds to a world (state).
• Situations are denoted through FOL terms e.g. s,
s'
• Actions transform situations, i.e. the
application of an action in a given situation s
yields a situation s'.
• Situations thus also refer to possible world
histories.

refers to the action sequence
yielding a new situation s when applied to S0.
7
Situations - Example
• Situation s0
• s0 on(A,B),on(B,Fl),clear(A),clear(Fl)
• on(A,B,s0),on(B,Fl,s0),clear(A,s0),
• clear(Fl,s0)
• Action move (A, B, Fl)
• Situation s1
• s1 on(A,Fl), on(B,Fl), clear(A),clear(B),clear(
Fl)
• on(A,F,s1),on(B,Fl,s1),clear(A,s1),clear(B,s1),cle
ar(Fl,s1)

8
Actions
Actions are written as functions with their name
and a parameter list. They can also be referred
to by variables (? reification). Actions
transform situations. The performance of an
action in a situation is denoted through the
Result or do function. The performance (do) of an
action a in a situation s yields a new situation
s'.
9
Result- or do-Function
Result (or do) is a function from actions and
situations into situations. Example s' do
(move (x, y, z), s) specifies a new situation s'
which is the result of performing a move-action
in situation s. General s do (a, s) for action
a and situations s, s
10
do-Function - Example
• situation s on(A,B), on(B,Fl), clear(C)
• action a move (A,B,C)
• apply action a in situation s
• do (move (A,B,C) , s) s'
• s' on(A,C), on(B,Fl), clear (B)
• Instead of specifying the situation s' this way,
we add situations into the basic formulas
(certain basic formulas - and terms).

11
Fluents
• Predicates and functions, whose values change due
to actions, are called fluents.
• Predicates, whose truth values can change, are
called relational fluents.
• example is_holding(robot, p, s) or
on(x,y,s) .
• Functions, whose denotations can vary, are called
functional fluents.
• example loc(robot, s) or under(x,s)
• Actions in a domain are specified by providing
action precondition axioms, effect axioms and
frame axioms.

12
Situations in Formulas
• Integrating situations into the formulas above
yields
• situation s on(A,B,s), on(B,Fl,s),
clear(C,s)
• action a move (A,B,C)
• apply action a in situation s
• do (a, s)
• do (move (A,B,C), s) s'
• situation s' on(A,C,s'), on(B,Fl,s'),
clear(B,s')
• Note Persistent predicate expressions like
Block(A), Block(B), ... remain without s.

13
The Calculus of Situation Calculus
14
Sit Calc Axioms "lite"
15
Action Description - Axioms
Axioms specify what changes and what remains.
Consider every combination of action and fluent.
effect-axioms specify effects, i.e. what
changes positive effects ? a formula becomes
true negative effects ? a formula becomes
false frame-axioms specify frame, i.e. what
remains positive effects ? a formula remains
true negative effects ? a formula remains
false In addition, general axioms specify general
laws or rules of the domain.
16
Effect Axiom - move-example
• action move (x, y, z)
• effect-axiom
• (on (x, y, s) ? clear (z, s) ? x ? z ) ?
• on (x, z, do (move (x, y, z), s))
• Explanation
• If the left side (condition) of the axiom holds,
then the action can be performed, and the right
side (consequence) follows.
• The consequence states what is true in the
resulting situation, here on(x,z,s)

17
Effect Axioms - move-example
positive effect on (x, y, s) ? clear (x, s) ?
clear (z, s) ? y ? z ? on (x, z, do (move (x, y,
z), s)) If x is on y, both x and z are clear, and
z is not the block onto which x is moved, then a
result of the move-action is that x is on
z. negative effect on (x, y, s) ? clear (x, s) ?
clear (z, s) ? y ? z ? ?on (x, y, do (move (x,
y, z), s)) If x is on y, both x and z are clear,
and z is not the block onto which x is moved,
then a result of the move-action is that x is not
anymore on y.
18
Frame Axiom - move-example
• action move (x, y, z)
• Frame Axiom
• on (u, v, s) ? x ? u ?
• on (u, v, do (move (x, y, z), s))
• Explanation
• A Frame Axiom states, what remains true or
unaffected, when an action is performed.
• In the example here a block u, which is not the
one moved, remains where it is, i.e. on (u, v) is
still valid after the action.

19
Frame Axioms - move-example
positive frame axiom on (u, v, s) ? x ? u ?
on (u, v, do (move (x, y, z), s)) If a block u
is on another block v, and u is not the block
being moved, then it stays on v. negative frame
axiom ?on (u, v, s) ? (x ? u ? y ? v) ? ?on
(u, v, do (move (x, y, z), s)) If a block u is
not on another block v, and u is not moved, or
nothing is put on v, then u will still not be on
v after the move.
20
Sit Calc Axioms in GOLOG
21
Axioms for Actions
• Actions are specified by providing a certain set
of domain-dependent axioms.
• These are
• action precondition axioms
• describe under what conditions an action can
occur
• effect axioms
• describe what is changed due to an action
• frame axioms
• describe what remains unchanged, when an action
takes place

22
GOLOG Axioms - Example
If a is possible in s, and there is a robot r,
such that a is the action that the robot repairs
x, then x is not broken after the "robot repairs
x action" was done in s.
23
Precondition Axiom - Example
• Action precondition axiom for pickup

Poss (pickup (x), s) ? ?x. ?Holding (x, s) ?
NextTo (x, s) ? ?Heavy (x)
24
Effect Axiom - Examples
Effect axioms for drop, explode, repair
25
Frame Axiom - Example
Frame axioms for drop
26
The Frame-Problem
• There can be a large number of frame axioms
necessary to describe a domain.
• This complicates the task of axiomatising a
domain and makes planning or reasoning in
situation calculus (theorem proving) extremely
inefficient.
• This is the famous Frame Problem.

27
Successor-State Axioms
• Collect all the effect axioms which affect a
given fluent. Assume that they specify all of the
ways that the value of the fluent can change.
Then apply a syntactic transformation to the
effect axioms to obtain a successor state axiom
for the fluent.
• successor-state-axioms
• combine frame and effect axioms
• specified for each fluent - action pair

28
Successor-State Axioms
general structure predicate expression is true in
true and the action did not make it false.
29
How to Derive Successor-State Axioms?
Effect Axioms Schema a action s situation F
fluent ? condition for F to become true (false)
for a in s.
General Successor State Axiom
30
General and Specific Successor State Axiom
31
Situation Calculus Axioms - so far
Effect axioms describe how an action changes a
situation, when the action is performed. Frame
axioms describe, what remains unchanged between
situations. Successor-state axioms combine effect
and frame axioms. Add domain knowledge!
32
General Axioms
General axioms Describe formulas, which are true
in all situations. Example ?x, y, s on (x, y,
s) ? ?(yTable) ? ?clear (y, s) For all
situations s and all objects x and y if
something is on object y in s, and y is not the
table, then y is not clear in s. ?s clear
(Table, s) The table (or floor) is always clear.
33
Domain Modelling in Sit Calc
• A particular domain of application will be
specified by a theory in the following form

34
Frame-Problem
Frame-Problem specify everything which remains
stable Leads to too many conditions which would
have to be explicitly stated for any state
transformation. Computationally very
expensive. Approach successor-state axioms
STRIPS
35
Qualification-Problem
Qualification-Problem specify everything which
is precondition to an action Difficult to
include every precondition, which could prevent
(if not fulfilled) the action to be
performed. Approach non-monotonic reasoning
with standard preconditions and effects as
defaults.
36
Ramification-Problem
Ramification-Problem conflict between change and
frame for derived formulas Some axioms state
conclusions about fluents indirectly affected by
Example An agent grabs an object and holds it.
When the agent moves, the object moves too
(domain model), though this is not explicitly
stated (not an effect axiom). Normally, objects
are supposed to stay, where they are
(frame-axiom). Frame every object stays where
it is unless it is moved. Domain if an object
is attached to another object and one of the
objects moves, the other object moves
too. Approach Integrate TMS for derived
formulae.
37
Planning
38
Situation Calculus and Planning
Planning starts with a specified start situation
and the specification of a goal
situation. Planning comprises of finding a proof
which infers the goal situation from the start
situation using successor-state and other axioms.
A Plan can be read from the proof it is the
sequence of actions causing the sequence of
transformations of situations from the initial
situation to the final situation.
For example, prove S' at (A, L) from S0 at
(A, S0)
39
GOLOG
Hector J. Levesque, Raymond Reiter, Yves
Lesperance, Fangzhen Lin and Richard Scherl,
Golog A logic programming language for dynamic
domains, Journal of Logic Programming, 31, 59-84,
(1997). M. Shanmugasundaram, Presentation in
74.757, 2004.
40
Golog
• Golog is a kind of logic programming language for
reasoning with actions, based on situation
calculus.
• Golog ? alGOL in LOGic
• It allows in addition to express and reason with
more complex action structures, like

41
Golog - Basics
• Complex action expressions are defined using
additional extralogical symbols (e.g., while, if,
etc.), which act as abbreviations for logical
expressions in the language of the situation
calculus.
• These extralogical expressions are like macros,
which expand into genuine formulas of the
situation calculus.
• The abbreviation Do(d, s, s) is the most basic
abbreviation used in the Golog language, where d
is a complex action expression.
• Do(d, s, s) means that executing d in situation
s has s as a legal terminating situation.
• Complex actions may be nondeterministic, i.e.
they may have several different executions
terminating in different situations.

42
Golog - Definitions 1
• Do is defined inductively for the structure of
its first argument
• Primitive actions
• Test actions
• Sequence

43
Golog - Definitions 2
• 4. Nondeterministic choice of two actions

5. Nondeterministic choice of action arguments
6. Nondeterministic iteration
44
Golog - Conditionals
• Conditionals and while loops are defined in terms
of the above constructs as follows

45
Golog - Conditionals
• Procedures are hard to define in situation
calculus semantics using macro expansion, because
there is no straightforward way to expand a
procedure body, when that body includes a
recursive call to itself.
• Use an auxiliary macro definition for any
predicate symbol P of arity n2, taking a pair of
situation arguments

46
Golog - Procedures
• Semantics of procedures A Golog program follows
the block-structured programming style. A program
of the form

will then be evaluated as
47
Golog - Blocks World Example
• A blocks world program to make a seven block
tower with block A clear in the final situation.

48
Programming in / Planning with Golog
• Golog programs are "executed" using theorem
proving.
• Program execution means, given a program d and an
initial situation s0, find a terminating
situation s for d, if one exists.
• To do so, we prove the termination of d as

and then extract from the proof a binding for the
terminating situation.
49
Elevator Controller in GOLOG
50
GOLOG - Elevator Controller
51
GOLOG - Elevator Controller
The next floor (to be served) is the nearest
floor to the floor, where the elevators is now,
in s.
52
GOLOG-Procedures for Elevator
53
GOLOG - Running the Elevator
Intial State
"Running the Elevator Program"
Find situation s
and collect matching action sequence
54
Elevator Controller - Initial and Final Situation
• The initial situation axiom specifies that,
initially buttons 3 and 5 are on, and moreover no
other buttons are on. Thus, we have complete
information initially about which call buttons
are on.
• A successful proof for the elevator program, for
example, may return the following binding for s

55
Elevator Controller - The Plan
• This example shows that Golog is a logic
programming language in the following sense
• Its interpreter is a general purpose theorem
prover.
• Like Prolog, Golog programs are executed to
obtain bindings for the existentially quantified
variables of the theorem.

56
Golog - Planning as Theorem Proving
• Running a program is a theorem proving task,
which establishes the following entailment
• The meaning of this entailment
• Do is a macro and not a predicate, and the
expression stands for a much longer situation
calculus sentence.
• We seek a proof of this macro-expanded sentence
from axioms, which characterise the fluents and
actions of the domain.
• The execution trace represented by this binding
is passed as solution to the elevators execution
module, which uses it for controlling the
elevator in the physical world.

57
References
• Hector J. Levesque, Raymond Reiter, Yves
Lesperance, Fangzhen Lin and Richard Scherl,
Golog A logic programming language for dynamic
domains, Journal of Logic Programming, 31, 59-84,
(1997).

58
Extensions to Golog
59
Golog - Extensions
• Golog is a sophisticated logic programming
language for implementing applications in dynamic
domains.
• But Golog lacks or neglects some important
features.
• Sensing and knowledge
• Exogenous actions
• Concurrency and reactivity
• Continuous processes
• The following slides show some extensions of
Golog.

60
ConGolog
• ConGolog is a concurrent programming language
based on the situation calculus
• The language includes facilities for prioritizing
the execution of concurrent processes,
interrupting the execution when certain
conditions become true, and dealing with
exogenous actions.
• ConGolog differs from other formal models of
concurrency in at least two ways. First, it
environment. Second, it allows the primitive
actions to affect the environment in a complex
way and such changes to the environment can
affect the execution of the remainder of the
program.

61
ConGolog - Semantics
• By using Do, programs are assigned a semantics in
terms of a relation, denoted by the formula Do(d,
s, s), which means that a given program d and a
situation s returns a situation s resulting from
executing d starting in the situation s.
• Semantics of this form are called evaluation
semantics, since they are based on the complete
evaluation of the program.
• To allow concurrency, it is more convenient to
adopt a different form of semantics, so-called
transition semantics or computation semantics.
• Transition semantics are based on defining single
steps of computation in contrast to directly
defining complete computations.

62
ConGolog (contd)
• For this two predicates are defined Trans(d, s,
d, s) and Final(d, s).
• Trans(d, s, d, s) holds, if there is a
transition from configuration (d, s) to the
configuration (d, s), i.e. if by running
program d starting in situation s, one can get to
situation s in one elemantary step with the
program d remaining to be executed.
• Every elementary step will either be the
execution of an atomic action (which changes the
situation) or the execution of a test (which does
not change the situation).
• Also, if the program is nondeterministic, there
are several transitions that are possible in a
configuration.

63
ConGolog (contd)
• Final(d, s) means that the configuration (d, s)
is final the computation is completed, i.e. no
part of the program remains to be executed.
• The final situations reached after a finite
number of transitions from a starting situation
coincide with those satisfying the Do relation.
• Complete computations are thus defined by
repeatedly composing single transitions until a
final configuration is reached.
• With Trans and Final, a new definition of Do can
be given as follows

64
ConGolog (contd)
• ConGolog is an extended version of Golog that
incorporates a rich account of concurrency.
• It is rich because it handles
• Concurrent processes with possibly different
priorities
• High-level interrupts
• Arbitrary exogenous actions (something happening
outside of the GOLOG-agent)
• Concurrent processes are modelled as
interleavings of the primitive actions in the
component processes.
• An important concept is that of a process being
blocked.

65
ConGolog (contd)
• The ConGolog language has the following
constructs
• Exogenous actions

66
cc-Golog
• cc-Golog is an action language which incorporates
continuous change and event-driven behaviour.
• It is used in high-level robot controllers, which
often need to specify event-driven behaviour and
operate low-level processes that change the world
in a continuous fashion.
• Main characteristics of cc-Golog program
• Timing of actions is largely event-driven thereby
providing a reactive behaviour.
• Actions are executed as soon as possible.
• Conditions change continuously over time.
• Good blocking policies.

67
cc-Golog (contd..)
• Event-driven behaviour is achieved by including a
special action waitFor(t).
• Continuous change is incorporated through
continuous fluents, which are functional fluents
whose values range over functions of time.
• Blocking policies are specified by means of a
special instruction withCtrl(f,s).
• Note cc-Golog only provides deterministic
instructions.

68
IndiGolog
• IndiGolog is an action language, which provides
nondeterminism and integrates sensing actions.
Indigolog programs are executed on-line by means
of an incremental interpreter.
• The initial state of the world is incompletely
specified and the agent or robot must use sensors
to determine values of certain fluents.
• Nondeterminism is taken care of by means of an

69
Golex
• The field of autonomous mobile robots lacks
methods that bridge the gap between high-level
symbolic techniques and low-level robot control
• Golex is an execution and monitoring system with
the purpose of bridging the gap between Golog and
the complex, distributed RHINO control software.
• Golex provides the following features
• High level of abstraction
• Execution monitoring
• Sensing and Interaction

70
pGolog
• Actions of a robot are often best thought of as
low level processes with uncertain outcomes.
• A high level robot plan is then a task, that
combines the low level processes in an
appropriate way and may involve nondeterminism.
• The robot needs to turn a given plan into an
executable program through some form of
projection such that it satisfies a given goal
with a sufficiently high probability.
• This is achieved through pGolog, a probabilistic
variant of Golog, whose programs model the
low-level processes.
• High-level plans are ordinary Golog programs,
except that during projection the names of
low-level processes are replaced by their pGolog
definitions.

71
Review
• Golog is a logic programming and planning
language for implementing applications in dynamic
domains, like robotics, process control,
intelligent software agents, discrete event
simulation etc.
• It is based on a formal theory of actions
specified in an extended version of the situation
calculus.
• Planning or programming in Golog is based on
Theorem Proving and methods adapted from Program
Verification.
• Golog has a number of extended versions, like
ConGolog, cc-Golog, pGolog etc., which address
limitations of the original, basic Golog.

72
References
• Hector J. Levesque, Raymond Reiter, Yves
Lesperance, Fangzhen Lin and Richard Scherl,
Golog A logic programming language for dynamic
domains, Journal of Logic Programming, 31, 59-84,
(1997).
• Giuseppe De Giacomo, Yves Lesperance, and Hector
J. Levesque, Congolog, a concurrent programming
language based on the situation calculus,
Artificial Intelligence, 121(1-2), 109-169,
(2000).
• Henrik Grosskreutz and Gerhard Lakemeyer, ccGolog
- An action language with continuous change,
Logic Journal of the IGPL, 11(2), 179-221,
(2003).
• Giuseppe De Giacomo and Hector J. Levesque, An
incremental interpreter for high-level programs
with sensing, In H. J. Levesque and F. Pirri
(Editors), Logical Foundations for Cognitive
Agents, 86-102, (1999).

73
References (contd)
• Dirk Hahnel, Wolfram Burgard, and Gerhard
Lakemeyer, Golex - bridging the gap between logic
(golog) and a real robot, in Proceedings of the
22nd German Conference on Artificial Intelligence
(KI 98), (1998).
• Henrik Grosskreutz, and Gerhard Lakemeyer,
Turning high-level plans into robot programs in
uncertain domains, In ECAI2000, (2000).
• And, of course
• Nils J. Nilsson Artificial Intelligence A New
Synthesis. Morgan Kaufmann, San Francisco, 1998.