74'419 Artificial Intelligence 200506 - PowerPoint PPT Presentation

Loading...

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



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
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
Learn more at: http://www4.cs.umanitoba.ca
Category:

less

Write a Comment
User Comments (0)
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
  • use additional function Poss
  • 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
follow state ? the action made it true or it was
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
actions. This can contradict frame-axioms.
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
    allows incomplete information about the
    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.
  • While the Golog interpreter works off-line,
    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
    off-line lookahead search operator S.

69
Golex
  • The field of autonomous mobile robots lacks
    methods that bridge the gap between high-level
    symbolic techniques and low-level robot control
    and navigation systems.
  • 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.
About PowerShow.com