1 / 40

MINERVA – A Dynamic Logic Programming Agent Architecture

MINERVA – A Dynamic Logic Programming Agent Architecture. Jo ã o Alexandre Leite, Jos é J ú lio Alferes, Lu í s Moniz Pereira Centro de Intelig ê ncia Artificial (CENTRIA) Universidade Nova de Lisboa, Portugal. Presented by Ian Strascina 3/8/04. Agents.

ozzy
Download Presentation

MINERVA – A Dynamic Logic Programming Agent Architecture

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. MINERVA – A Dynamic Logic Programming Agent Architecture João Alexandre Leite, José Júlio Alferes, Luís Moniz Pereira Centro de Inteligência Artificial (CENTRIA) Universidade Nova de Lisboa, Portugal Presented by Ian Strascina 3/8/04

  2. Agents • Agents commonly implemented by imperative languages – efficiency • Efficiency not always critical, but clear specification and correctness is • Thus Logic Programming and Non-Monotonic Reasoning (LPNMR) are being (re)evaluated for implementation

  3. LPNMR • Provide abstract, generalized solutions to accommodate different problem domains • Strong Declarative & Procedural Semantics – bridges gap between theory and practice. • Several powerful concepts: belief revision, inductive learning, preferences, etc. • The combination of these can allow for a mixture of agents with reactive and rational behaviours

  4. LPNMR • Drawback: LP usually represents static environments • Conflict – Agents typically dynamic, acting in dynamic environments • To get around this: Dynamic Logic Programming (DLP) • Represent/Integrate knowledge from different sources which may evolve over time • Multi-Dimensional Dynamic Logic Programming (MDLP) – more expressive • “Language for Dynamic Updates” (LUPS) – specifying changes over time

  5. MINERVA • Agent Architecture design based on dynamic representation of several system aspects and a evolving them via state transitions • Named after the Roman goddess Minerva • goddess of wisdom (amongst other things)

  6. Topics • Background of (M)DLP and LUPS • MINERVA overall architecture • Labouring sub-agents

  7. Dynamic Logic Programming • Sequence of logic programs • each has knowledge about a given state – different time periods, priorities, points of view, etc. • Try to define declarative & procedural semantics given relationships between different states • Declarative semantics – stable models of program consisting of all ‘valid’ rules in that state • Property of inertia r1. a :- b, c. p(X) :- q(X). d1 :- d2, e1. r1. p(X) :- f(Y,X), g(X,Z). d1 :- d2, e1. r1. a :- b, c. p(X) :- q(X).

  8. Dynamic Logic Programming • DLP  Situation Calculus • MDLP – generalized, more expressive • “societal” view – inter- and intra- agent relationships • Transitioning between states??? r1. a :- b, c. p(X) :- q(X). d1 :- d2, e1. r1. p(X) :- f(Y,X), g(X,Z). d1 :- d2, e1. r1. a :- b, c. p(X) :- q(X).

  9. LUPS • LUPS – “Language for dynamic updates” • language to declaratively specify changes to logic programs • sequentially updates logic program’s KB • The declarative meaning of a sequence of sets of update command in LUPS is defined by the semantics of the DLP generated by those commands

  10. LUPS • A sentence U in LUPS – set of simultaneous update commands (actions), that given an existing sequence of logic programs (MDLP), produces a new MDLP with one more logic program • A LUPS program is a sequence of this type of sentence • semantics are defined by the DLP generated by the sequence of commands

  11. LUPS • “Interpretation update” – no good • ex. program – only stable model is M={free} free ←not jail. jail ← abortion. • Suppose U={ abortion ← } • Only update of M by U would be {free, abortion} • Doesn’t make sense according to the update • Inertia should be applied to rules, not individual literals

  12. LUPS – commands • Simplest command to add a rule to current state assert L ← L1,…,Lk when Lk+1,…,Lm • If preconditions Lk+1,…,Lm are true in current state, add the rule L ← L1,…,Lk to the successor knowledge state • Rule will then remain indefinitely by inertia, unless retracted or defeated by a future update

  13. LUPS – commands • Sometimes we don’t want inertia example: wake_up ← alarm_rings • If the alarm rings we will wake up • Want to stay awake if not alarm becomes true (alarm stops ringing) • alarm_ring should not persist by inertia • One-time events assert event L ← L1,…,Lk when Lk+1,…,Lm

  14. LUPS – commands • To delete rules, we use the retract command retract [event] L ← L1,…,Lk when Lk+1,…,Lm • This deletes the rule from the next state and continuing onward • If event is specified, the rule is temporarily deleted in the next state

  15. LUPS – commands • Assertions – newly incoming information • Effects remain by inertia (unless); assert command itself does not • May want certain update commands to remain in successive consecutive updates • Persistent update commands – “Laws” always [event] L ← L1,…,Lk when Lk+1,…,Lm • Cancel a persistent update cancelL ← L1,…,Lk when Lk+1,…,Lm • cancel and retract – not the same

  16. Overall Architecture

  17. Common KB • Contains knowledge about the agent and others • Components – MDLP or LUPS • Capabilities • Intentions • Goals • Plans • Reactions • Object Knowledge Base • Internal Behaviour Rules • Internal Clock (???)

  18. Object KB (MDLP) • Main component containing knowledge about the world • Represented as a DAG • Sequence of nodes for each sub-agent of agent α • evolution in time • sub-agents manipulate its own node • Sequence of nodes for other agents in system • represent α’s view of their evolution in time • Dialoguer sub-agent – interactions w/ other agents

  19. Capabilities (LUPS) • Describes actions and effects possible of agent • Easy to describe since LUPS describes states and transitions • Typically, for each action ω: alwaysL ← L1,…,Lk when Lk+1,…,Lm,ω effect preconditions action

  20. Capabilities (LUPS) • 3 main types of actions: • Adding a new fluent: ω causes F if … always F when F1,…,Fk,ω(F, Fi’s are fluents) • Rule update alwaysL ← L1,…,Lk when Lk+1,…,Lm,ω • Actions that, when performed in parallel, have different results • translate into 3 update commands always L1 when Lk+1,…,Lm,ωa,not ωb always L1 when Lk+1,…,Lm,not ωa,ωb always L2 when Lk+1,…,Lm,ωa,ωb • “ωa (x)or ωb cause L1 if the preconditions hold, and cause L2 in parallel”

  21. Internal Behaviour Rules (LUPS) • Specify agent’s reactive internal epistemic state transitions • Form is assertL ← L1,…,Lk when Lk+1,…,Lm • Assert this rule if these conditions are true now. • example assert jail(X) ← abortion(X) when gov(repub) assert not jail(X) ← abortion(X) when gov(dem)

  22. Goals (DLP) • Each state in DLP contains goals that agent needs to accomplish • goals are of the form goal(Goal,Time,Agent,Priority) • Goal – conj. of literals • Time – time state; related to internal clock??? • Agent – agent where goal originated • Priority – priority of goal • Any sub-agent can assert a goal • Sub-agent Goal-manager can manipulate goals

  23. Plans (MDLP) • Action update – set of update commands of the form {assert event ω} ; ω is an action name • Asserting an event is conceptually the same as executing an action • must be an event since action do not persist • Example – to achieve Goal1 at time T, a plan might be: UT-3 = {assert event ω1; assert event ω2} UT-1 = {assert event ω4; assert event ω5} • Strength of LUPS allows conditional events (when) • Example – to achieve Goal2 at time T, a plan might be: UT-3 = {assert event ω3when L; assert event ω6when not L} UT-2 = {assert event ω1; assert event ω2}

  24. Plans (MDLP) • Each plan for a goal (Goal) has preconditions (Conditions) • Planner sub-agent generates plans for goal • Asserts plans into Common KB as plan(Goal,Plan,Conditions) • Scheduler sub-agent uses plans and reactions to produce agent intentions

  25. Reactions (MDLP) • Simple MDLP – rules just facts denoting actions ω, or negation of actions notω. • Contains sequence of nodes for every sub-agent capable of reacting • Hierarchy of reactions • Sub-agents have a set of LUPS commands of the form assertω when Lk+1,…,Lm • LUPS allows a form of action ‘blockage’ – prevent an action from being executed assert not ω when Lk+1,…,Lm • Deny any assert by lower ranked sub-agent

  26. Intentions (MDLP) • Actions agent has committed to • Compiled by Scheduler from plans and reactions • Form is intention(Action,Conditions,Time) • perform action Action at time Time if the Conditions are true • Actuator sub-agent executes intentions • Previous example: (c is current time state) intention(ω3, L, c+1); intention(ω1, -, c+3); intention(ω4, -, c+5); intention(ω6, not L, c+1); intention(ω2,-, c+3); intention(ω5,-, c+5);

  27. Sub-Agents

  28. Sub-Agents • Evaluate and manipulate Common KB • Can interface with environment, other agents • Different specialities provides modularity • Each has a LUPS program describing its behaviour • Meta-interpreter to execute program • Execution produces states – nodes of the Object KB • Allow private procedure calls – extend LUPS to call them in when statement of a command assert X ← L1,…,Lk when Lk+1,…,Lm,ProcCall(Lm+1,…,Ln,X) • Can read Common KB, but not change

  29. Sub-Agents • Present • Sensor • Dialoguer • Actuator • Effector • Reactor • Planner • Goal Manager • Scheduler • Learner • Contradiction Remover • Others

  30. Sensor • Gets input from environment • Procedure Call SensorProc(Rule) • Can assert into Object KB by assert Rule when SensorProc(Rule) • Can act as a filter – decide what input to accept

  31. Dialoguer • Similar to sensor • Gets inputs from other agents • Updates other agents’ nodes in Object KB • Generate new goals, reply messages, etc. based on received message • Example assert goal(Goal,Time,Agent,- )@goals when MsgFrom(Agent,Goal,Time,Rule), cooperative(Agent). assert Rule@Agent when MsgFrom(Agent,Goal,Time,Rule). assert msgTo(Agent,Goal,plan(Goal,Plan,Cond)@reactions when goal(Goal,Time,Agent,- )@goals, Agentα, plan(Goal,Plan,Cond)@plans

  32. Actuator • Executes actions on the environment • Each cycle (of Internal Clock?) – extracts intentions and performs them • Successful? • if so, assert action name in Object KB • Form of LUPS command(s): assert event ωwhen intention(Action,Cond,Time)@intentions, Current(Time), Cond, ActionProc(ω).

  33. Effector • At each cycle – evaluates LUPS commands • Capabilities and Behaviour rules • These don’t belong exclusively to Effector • Planner can access • Capabilities – prior successful action execution • Behaviour – doesn’t require

  34. Reactor • Has reactive rules • if executed, produce an action to perform assert event ω@reactions when L1,…,Lk • Example assert event runaway@reactions when danger • Can also reactively block actions with assert event not ω@reactions when L1,…,Lk

  35. Planner • Can find plans by abduction in LUPS specified scenarios • Uses Object KB, Intentions, Capabilities, and Common Behaviour Rules to find plans • LUPS command for AbductivePlan(Goal,Plan,Cond) assert plan(Goal,Plan,Cond)@plans when goal(Goal,T,-,1)@goals, AbductivePlan(Goal,Plan,Cond) • Other planners can be used – interface w/ LUPS commands

  36. Goal Manager • Deal with conflicting goals • asserted by other sub-agents • possibly originating from other agents • Works on the Goals structure • can delete goals, change priorities, etc. • Example of two incompatible goals being handled retract goal(G1,T1,A1,P1)@goals when goal(G1,T1,A1,P1)@goals, goal(G2,T2,A2,P2)@goals, incomp(G1,G2), P1 < P2.

  37. Scheduler • Determines intentions based on current state • Acts if there are pending reactions or goals and plans • May be more than 1 specialized scheduling procedure • Example assertΠ@intentions when goal(G,-,-,-)@goals, plan(G,-,-)@plans, not X@reactions, SchedulePlans(Π). assertΠ@intentions when not goal(-,-,-,-)@goals, X@reactions, ScheduleReactions(Π). assertΠ@intentions when goal(G,-,-,-)@goals, plan(G,-,-)@plans, X@reactions, CombineSchedule(Π).

  38. Conclusion • Logic Programming provides clear specification and correctness • Dynamic Logic Programming (DLP) provides a way to represent knowledge (possibly from different sources) that evolves over time • sequence of logic programs • different states • MDLP – express added knowledge of environment, other agents • LUPS – specifies transitioning between states in (M)DLP • This together with strong concepts such as intentions, planning, etc. form a solid agent architecture

  39. Ian’s Diagnosis Looks a little complicated, but sounds cool enough to want to give it a shot!

More Related