Agent Programming in Goal Modules

Koen Hindriks Programming Multi-Agent Systems

Agent Programming in GOALModules

Koen HindriksDelft University of Technology, The Netherlands

Multi-Agent Systems Course

Koen Hindriks Programming Multi-Agent SystemsKoen Hindriks Programming Multi-Agent Systems

Agents in Games


Multi-Agent Systems Project

3

Project Multi-Agent Systems:CTF Competition in UT2004

• Control a team of bots by means of a multi-agent system.

• Compete at the end of the project.

Course Multi-Agent Systems:Learn to program a multi-agent system

Develop logic-based agents programs:

• Apply reasoning technology (Prolog)

• Write agent programs (GOAL)• Hands-on experience by various

programming assignments.


Outline

• Modules

• BW4T Assignment


Modules


An Agent is a Set of ModulesBuilt-in modules:• init module:

– Define global knowledge– Define initial beliefs & goals– Process “send once” percepts– Specify environment actions

• main module– Action selection strategy

• event module– Process percepts– Process messages– Goal management

User-defined modules.

init module{ knowledge{ … } beliefs{ %%% INITIAL BELIEFS ONLY IN INIT MODULE %%% } goals{ … } program{ %%% PROCESS “SEND ONCE” PERCEPTS HERE %%% } actionspec{ %%% SPECIFY ENVIRONMENT ACTIONS HERE %%% }} main module{ % OPTIONAL knowledge section % NO beliefs section HERE! % OPTIONAL goal section (not advised in ‘main’) program{ %%% ENVIRONMENT ACTION SELECTION HERE %%% }}

event module{ program{ %%% PROCESS PERCEPTS HERE %%% %%% PROCESS MESSAGES HERE %%% %%% PERFORM GOAL MANAGEMENT HERE %%% }}


Defined Module Components• User-defined module is similar to

any other module.

• Even though knowledge may be specified within a module, knowledge is global. I.e. all knowledge is put in a global knowledge base.

• Goals, macros, rules and actions specified within a module are local: They can only be used within that module.

init module{ ...} main module{ program{

}}

event module{ ... }

%%% YOUR OWN MODULES GO HERE %%%%%% CAN ALSO IMPORT MODULES %%%

module moduleName { % may have: [<options>] knowledg{ … } % optional goals{ … } % optional program{ … } % OBLIGATORY actionspec{ … } % optional}


Tower Env: Agent Design

% moving X on top of Y is a constructive move if that move results in X being% in position.#define constructiveMove(X, Y) a-goal( tower([X, Y | T]) ), bel( tower([Y | T]), clear(Y), (clear(X) ; holding(X)) ) .

main module{ program{ % pick up a block if you can and want to. if a-goal( holding(X) ) then pickup(X) .

% put a block you're holding down, ideally where you want it, but otherwise put it on the table. if bel( holding(X) ) then { if constructiveMove(X,Y) then putdown(X, Y) . if true then putdown(X, table) . }

% otherwise, there is nothing to do, so we can move the gripper to the top left corner. % no need to check whether we're holding a block because of linear order. if true then nil . }}

Design rule: Only use action rules that select environment actions in main module.Use main module to define a strategy for handling the environment as above.


Tower Env: Agent Design main module{ program{ … if a-goal( holding(X) ) then pickup(X) . if bel( holding(X) ) then { if constructiveMove(X,Y) then putdown(X, Y) . if true then putdown(X, table) . } if true then nil . } } event module{ program{ … % process percepts from Tower World environment. rules below assume full observability. forall bel( block(X), not(percept(block(X))) ) do delete( block(X) ) . forall bel( percept(block(X)), not(block(X)) ) do insert( block(X) ) .

forall bel( holding(X), not(percept(holding(X))) ) do delete( holding(X) ) . forall bel( percept(holding(X)), not(holding(X)) ) do insert( holding(X) ) .

forall bel( on(X,Y), not(percept(on(X,Y))) ) do delete( on(X,Y) ) . forall bel( percept(on(X,Y)), not(on(X,Y)) ) do insert( on(X,Y) ) . …}

Process percepts first in event module. Always use most up-to-date information.


Tower Env: Agent Design event module{ program{ % a block is *in position* if it achieves a goal. #define inPosition(X) goal-a( tower([X|T]) ) .

…

% GOAL MANAGEMENT % check for reasons to DROP a goal FIRST. if goal( holding(X) ) then {

% first reason: cannot pick up block X because it's not clear.if bel( not(clear(X)) ) then drop( holding(X) ) .% second reason: cannot pick up block X because now holding other block!if bel( holding(_) ) then drop( holding(X) ) .% third reason: block X is already in position, don't touch it.if inPosition( X ) then drop( holding(X) ) .% fourth reason: we can do better by moving another block constructively. listall L <- constructiveMove(Y,Z) do { if bel(not(L=[]), not(member([X,_],L))) then drop( holding(X) ) .}

}

% check reasons for ADOPTING a goal. % holding(X) is a *single instance goal* to maintain focus. if not(goal( holding(X) )) then adoptgoal. } } …

Locate rules for updating the agent’s mental state outside main module.Design rule: for goal mngt, first delete content, then add content.

What is adoptgoal?Strategy for adopting goals rules in user-defined module


Tower Env: Agent Design main module{ program{ … if a-goal( holding(X) ) then pickup(X) . … } } event module{ program{ … % holding(X) is a *single instance goal* to maintain focus. if not(goal( holding(X) )) then adoptgoal. } } module adoptgoal{ % default order=linear: adopt at most one goal to hold a block at any time. % gripper cannot hold more than one block.

program{ #define obstructingBlock(X) a-goal( on(Y, Z) ), bel( above(X, Z); above(X, Y) ) .

if constructiveMove(X, Y) then adopt( holding(X) ) . % prefer making constructive moves. if obstructingBlock(X) then adopt( holding(X) ) . } } …

Standard module: select one applicable action, perform it, and exit module again.

Use of single instance goal for maintaining focus.


Tower Env: Agent Designmain: towerBuilder{ …

event module{ program{ % a block is *in position* if it achieves a goal. #define inPosition(X) goal-a( tower([X|T]) ) .

… % check for reasons to drop or adopt a goal (goal management). if goal( holding(X) ) then { % first reason: cannot pick up block X. if not(bel( clear(X) )) then drop( holding(X) ) . % second reason: block X is already in position, don't touch it. if inPosition( X ) then drop( holding(X) ) . }

% adopt new goal only after cleaning up. if not(goal( holding(X) )) then adoptgoal. } } module adoptgoal{ program{ … if constructiveMove(X, Y) then adopt( holding(X) ) . if obstructingBlock(X) then adopt( holding(X) ) . } …

Q: Why not put all goal management rules in event module?A: In event module all rules are applied, but we want to adopt at most one goal.


Modules:Focus of Attention and Control


Multiple Goals in Blocks World

Objective:Move blocks in initial state such that all goals are achieved.

init module { knowledge{ block(X) :- on(X, Y). clear(X) :- block(X), not(on(Y,X)). clear(table). tower([X]) :- on(X, table). tower([X,Y|T]) :- on(X,Y), tower([Y|T]). } goals{ on(a, b), on(b, c), on(c, table). on(d, e), on(e, f), on(f, table). } actionspec{ move(X,Y) { pre{ clear(X),clear(Y),on(X,Z),not(on(X,Y)) } post{ not(on(X,Z)), on(X,Y) } } }}

main module{ program[order=random]{ #define misplaced(X) a-goal(tower([X|T])). #define constructiveMove(X,Y) a-goal(tower([X,Y|T])), bel(tower([Y|T])).

if constructiveMove(X,Y) then move(X,Y). if misplaced(X) then move(X, table). }}

...

EXERCISE:Q: Does agent achieve goals?A: Yes. Goals are not conflicting.




init module { knowledge{ block(X) :- on(X, Y). clear(X) :- block(X), not(on(Y,X)). clear(table). tower([X]) :- on(X, table). tower([X,Y|T]) :- on(X,Y), tower([Y|T]). } goals{ on(a, e), on(e, c), on(c, table). on(d, e), on(e, f), on(f, table). } actionspec{ move(X,Y) { pre{ clear(X),clear(Y),on(X,Z),not(on(X,Y)) } post{ not(on(X,Z)), on(X,Y) } } }} main module{ program[order=random]{ #define misplaced(X) a-goal(tower([X|T])). #define constructiveMove(X,Y) a-goal(tower([X,Y|T])), bel(tower([Y|T])).


EXERCISE:Q: Does agent achieve goals?A: No. After achieving one of the goals the agent cannot remove block a or d.




init module { knowledge{ block(X) :- on(X, Y). clear(X) :- block(X), not(on(Y,X)). clear(table). tower([X]) :- on(X, table). tower([X,Y|T]) :- on(X,Y), tower([Y|T]). } goals{ on(a, e), on(e, c), on(c, table). on(d, e), on(e, f), on(f, table). } actionspec{ move(X,Y) { pre{ clear(X),clear(Y),on(X,Z),not(on(X,Y)) } post{ not(on(X,Z)), on(X,Y) } } }}

main module{ program[order=random]{ #define misplaced(X) a-goal(tower([X|T])). #define constructiveMove(X,Y) a-goal(tower([X,Y|T])), bel(tower([Y|T])).


EXERCISE:Q: How can this be fixed?


A: Fixing the problem:

A block is misplaced if it is “in the way”.



init module{ knowledge{ block(X) :- on(X, Y). clear(X) :- block(X), not(on(Y,X)). … above(X,Y) :- on(X,Y). above(X,Y) :- on(X,Z), above(Z,Y). } goals{ on(a, e), on(e, c), on(c, table). on(d, e), on(e, f), on(f, table). } actionspec{ move(X,Y) { pre{ clear(X),clear(Y),on(X,Z),not(on(X,Y)) } post{ not(on(X,Z)), on(X,Y) } } }}

main module{ program{ #define misplaced(X) a-goal(tower([Y|T])),

bel(above(X,Y) ; X=Y). #define constructiveMove(X,Y) a-goal(tower([X,Y|T])), bel(tower([Y|T])).



But the agent achieves its goalsvery inefficiently!!



Agent performs action: move(c,table)Agent performs action: move(e,table)Agent performs action: move(f,table)Agent performs action: move(d,table)Agent performs action: move(e,c)Agent performs action: move(e,table)Agent performs action: move(e,c)Agent performs action: move(e,table)Agent performs action: move(e,f)Agent performs action: move(e,c)Agent performs action: move(e,f)Agent performs action: move(e,c)Agent performs action: move(e,table)Agent performs action: move(e,c)Agent performs action: move(e,f)Agent performs action: move(e,table)Agent performs action: move(e,c)Agent performs action: move(e,f)Agent performs action: move(d,e)Agent performs action: move(d,table)Agent performs action: move(e,table)Agent performs action: move(e,c)Agent performs action: move(f,table)Agent performs action: move(e,f)Agent performs action: move(e,table)Agent performs action: move(e,f)Agent performs action: move(e,table)Agent performs action: move(e,f)…Agent performs action: move(e,f)Agent performs action: move(d,e)

(Continued)


Fixing the problem (2):

Part of the problem is due to randomness, adding order partly fixes this problem.



init module{ knowledge{ block(X) :- on(X, Y). clear(X) :- block(X), not(on(Y,X)). … above(X,Y) :- on(X,Y). above(X,Y) :- on(X,Z), above(Z,Y). } goals{ on(a, e), on(e, c), on(c, table). on(d, e), on(e, f), on(f, table). } actionspec{ move(X,Y) { pre{ clear(X),clear(Y),on(X,Z),not(on(X,Y)) } post{ not(on(X,Z)), on(X,Y) } } }}

main module{ program{ #define misplaced(X) a-goal(tower([Y|T])),

bel(above(X,Y) ; X=Y). #define constructiveMove(X,Y) a-goal(tower([X,Y|T])), bel(tower([Y|T])).


(Continued)


But still the agent performsan unnecessary action…



Agent performs action: move(c,table)Agent performs action: move(e,c)Agent performs action: move(d,table)Agent performs action: move(a,e)Agent performs action: move(a,table)Agent performs action: move(e,table)Agent performs action: move(f,table)Agent performs action: move(e,f)Agent performs action: move(d,e)

(Continued)


Fixing the problem (3):

The agent also lacks focus on a single goal…



init module{ knowledge{ block(X) :- on(X, Y). clear(X) :- block(X), not(on(Y,X)). … } goals{ on(a, e), on(e, c), on(c, table). on(d, e), on(e, f), on(f, table). } actionspec{ … }}

main module{ program { if a-goal(tower([X|T]), clear(X)) then buildTower. }}

event module{ ...}

module buildTower[exit=nogoals, focus=select]{ program{ if constructiveMove(X,Y) then move(X,Y). if misplaced(X) then move(X,table). }}


Focus of attention on goal removesunnecessary action…



Agent performs action: Entering module buildTowerAgent performs action: move(c,table)Agent performs action: move(e,c)Agent performs action: move(d,table)Agent performs action: move(a,e)Agent performs action: Entering module buildTowerAgent performs action: move(f,table)Agent performs action: move(a,table)Agent performs action: move(e,f)Agent performs action: move(d,e)


Modules: Focus of Attentioninit module { knowledge{ block(X) :- on(X, Y). clear(X) :- block(X), not(on(Y,X)). … } goals{ on(a, e), on(e, c), on(c, table). on(d, e), on(e, f), on(f, table). } actionspec{ … }} main module{ program { if a-goal(tower([X|T]), clear(X)) then buildTower. }}


• Focus option of module creates new attention set (‘local’ goal base):[….., focus=select]

• Mental state conditions that trigger modules act like a filter

• One of the (possibly multiple) goals that satisfies the condition is put in the attention set of the module.

• In the example both goals satisfy the mental state condition, so either one of:on(a,b), on(b,c), on(c,table).on(d,e), on(e,f), on(f,table).may be selected and put in the attention set of the module.

• For example, attention set for buildTower module is: on(a,b), on(b,c), on(c,table).


Modules: Mental state conditions• An attention set functions like a regular

goal base.

• Mental state conditions used within a module are evaluated on the attention set and the global belief base.

• For example, if the attention set is:on(a,e), on(e,c), on(c,table).the mental state condition:

goal(tower([X,Y|T]))yields:

[T/[c],Y/e,X/a][T/[],Y/c,X/e]

init module { knowledge{ block(X) :- on(X, Y). clear(X) :- block(X), not(on(Y,X)). … } goals{ on(a, e), on(e, c), on(c, table). on(d, e), on(e, f), on(f, table). } actionspec{ … }} main module{ program { if a-goal(tower([X|T]), clear(X)) then buildTower. }}



Modules: Action RulesWhen a module is activated:• Only action rules within the module’s program

section are applied.• Provides:

– a scoping mechanism.– encapsulation of action logic.

• Actions specified outside module that are specified in init module may be used.


Modules: Options• Set exit condition using [exit=…][exit=always] : Always exit (default)[exit=nogoals] : Exit focus goals have been achieved.[exit=noaction] : Exit when no actions are enabled.

• Set filter condition using [focus=…][focus=none] : no new attention set, global goal base used (default)[focus=new] : new empty attention set is used instead of global gb[focus=select] : new attention set with selected goal instead of global gb[focus=filter] : new attention set with filtered goal instead of global gb

NB: Setting rule order option using [order=…] is associated with program sections, NOT modules. Options are:Default : [order=linear]Other options : random, linearall, randomall


Modules: Focus=Filter (Example)• Suppose current goal is:

on(a,b), on(b,c), on(c,table), on(d,e), on(e,f), on(f,table), maintain.

• Then mental state condition:a-goal(tower([X,Y|T])),bel(tower([Y|T]),clear(Y),(clear(X);holding(X)))

and filter focus yields goals of the form:tower([a,b,c])

a-goal(on(X,table)), bel(clear(X); holding(X))yields goals of the form:

on(a,table)


focus = filter, select• A mental state only acts as a method to focus

on a goal if it contains at least one positive goal literal.

• a-goal(…), goal(…), goal-a(…) are positive goal literals.

these act to select a focus goal.

• not(a-goal(…)), not(goal(…)), not(goal-a(…)) are negative goal literals.

these do not select or filter goals.


Modules: Exit Condition• Example: [exit=nogoals]

• Whenever all goals in the attention set are achieved, a module is terminated.

• For example, if the attention set is:on(a,b), on(b,c), on(c,table).and this goal is achieved, control returns to:• top-level, or• the module from which this

module was entered.

• NB: modules may be entered from an active module.




Modules: Explicit exit• The built-in action exit-module may be

used to exit a module even if the goals in an attention set have not been achieved.

• Use this action as in any other action rule within the program section of a module.

• Best practice: if used with other actions (using the + construct), then put exit-module last.


module buildTower[exit=nogoals, focus=select]{ program{

if bel( cannotBuildTower ) then exit-module.

if constructiveMove(X,Y) then move(X,Y). if misplaced(X) then move(X,table). }}


Modules: Adopt and Drop• Semantics of the built-in adopt and drop

action within modules:

• adopt action within module:– Adds goal to the current attention set.– Only local effect.

• drop action within module:– Removes goal from all attention sets (including

global goal base)– Has global effect.


BW4T ASSIGNMENT


A Working Program• Your agent program should solve the task:

deliver blocks in right order to drop zone.

• It does not need to perform optimally but some efficiency would be nice:– Do not visit rooms more often than needed.– I.e., keep track of what has been visited!


Agent does not exist???

• Name of GOAL file should match your actual GOAL file.

environment{ …}

agentfiles{% insert (list of) agent file references below.“someName.goal" [name = robot] .

}

launchpolicy{when [max=1]@env do launch robot : robot .

}


Hardcoding rooms??

• Better & Simpler:

% ?????…if bel(not(visited('RoomC3'))) then adopt(in('RoomC3')).if bel(visited('RoomC3'),not(visited('RoomC2'))) then adopt(in('RoomC2')).if bel(visited('RoomC2'),not(visited('RoomC1'))) then adopt(in('RoomC1')).if bel(visited('RoomC1'),not(visited('RoomB1'))) then adopt(in('RoomB1')).if bel(visited('RoomB1'),not(visited('RoomB2'))) then adopt(in('RoomB2')).if bel(visited('RoomB2'),not(visited('RoomB3'))) then adopt(in('RoomB3')).if bel(visited('RoomB3'),not(visited('RoomA3'))) then adopt(in('RoomA3')).if bel(visited('RoomA3'),not(visited('RoomA2'))) then adopt(in('RoomA2')).if bel(visited('RoomA2'),not(visited('RoomA1'))) then adopt(in('RoomA1')).…

% ?????…if bel( percept(room(RoomID)), not(visited(RoomID))) then adopt(in(RoomID)).…


Specifying Durative Actions• BW4T has instantaneous & durative actions.• Which of the following are durative?

– pickUp– putDown– goTo– goToBlock


Postcondition Durative Actions

• Do NOT insert information that is not immediately true.

• One Solution: use empty postcondition

goTo(Location) { pre { not(state(traveling)), place(Location) } post { state(arrived), at(Location) }}

Will be inserted too early.

goTo(Location) { pre { not(state(traveling)), place(Location) } post { true }}


Spec for goToBlock(<BlockID>)

• Not holding a block is NOT a precondition for being able to perform goToBlock…

• goToBlock action takes time (when tick delay>0). Agent should NOT be made to believe it will immediately arrive…

Guideline: Pre- and post-condition should match real conditions present in environment!

goToBlock(BlockID) {

pre{ not(holding(_)) }post{ state(arrived) }

}

Other similar example:goTo(PlaceId) with precondition

not(visited(PlaceID)).


Spec for goToBlock(<BlockID>)• Updated Doc says: Robot must be in same room as

block <BlockID>.

• Executing goToBlock(‘RoomA1’) gives exception (check Console).

→ include check whether parameter <BlockID> really is a block AND that robot is in same room.

• For example, goToBlock(BlockID) {

pre{ color(BlockID, _), block(BlockID, _, RoomID),in(RoomID), not(state(traveling)) }

post{ true } }


Spec for pickUp• Doc says:

“Precondition: Robot is close to a block anddoes not hold a block yet.

Postcondition: Robot is holding the block, and the block is not located anywhere (i.e., there is no ‘at’ percept for the block) until it is dropped.”

• For example, pickUp{

pre{ not(holding(_)), atBlock(BlockID) }post{ holding(BlockID) }

}


Using the + operator• Rule of thumb: Do NOT combine environment

actions that take time with + operator.

• Make reasons for doing action explicit!Increases agent’s flexibility & code readability

program{ … if bel(not(holding(_)),color(A,B),nextColorInSeq(B)) then goToBlock(A) + pickUp. % ????? … }

% BETTER:…% FIRST THINGS FIRST... LINEAR ORDER IN MAIN MODULE BY DEFAULT

if a-goal( holding(ColorID) ), bel( block(BlockID, ColorID, PlaceID), atBlock(BlockID) )

then pickUp.…% if agent wants to be at block, go there.if a-goal( at(Id) ), bel( block(Id, _, _) ) then goToBlock(Id).…

FIRST THINGS FIRST... (USE) LINEAR ORDER IN MAIN MODULE (DEFAULT)


Beliefs:

Goals:

Setting Goals• Adopt goals that agent will eventually believe.• For example, use atBlock(Block) en in(Room).

• No need to use drop action in this case!

in(‘RoomA1’)

in(‘RoomA1’)

goal adopted

-

beliefinserted

goalremoved


Code for interruptable goTo• Precondition not(traveling) prevents interruption of

goTo action, but in MAS sometimes you want this.

• For example (N.B.: different from spec above!)

• Plus remove not(traveling) to change direction:

• Instead of not(goal( atSomeWhere)) use own reason

% Go to place PlaceID.% Precondition 'not(state(traveling))' prevents interruption of goTo action.% The action may fail if PlaceID is a room that is occupied at the time the % robot wants to enter it.goTo(PlaceID) {

pre{ place(PlaceID), state(State), not(state(traveling)) }post{ not(state(State)), state(traveling) }

}

% If robot does not want to go somewhere, make sure we can redirect the robot% by removing state(traveling).if not(goal( atSomeWhere )), bel( state(traveling) )

then delete( state(traveling) ) + insert( state(arrived) ).


ASK QUESTIONS!• If YOU cannot solve a problem…

• There are at least FOUR THINGS you can do:

1. Check http://mmi.tudelft.nl/trac/goal.

2. Check Programming Guide.

3. Check FAQ on GOAL website.

4. Send mail to [email protected] or Assistants.

http://mmi.tudelft.nl/trac/goal

mailto:[email protected]


!! DOCUMENTATION !!

Document your code using COMMENTS!

• Solution can be provided in about 100 lines of code.

• But then add at least half that amount to document and explain your code


Organisation• Next lecture: Multi-Agent Systems

• Tutorial this week:– Assignment 4: BW4T MAS

• Updated GOAL Installer available at: http://ii.tudelft.nl/trac/goal/wiki/Releases.includes:– Simplified reset/restart for BW4T.

http://ii.tudelft.nl/trac/goal/wiki/Releases

Agent Programming in Goal Modules

Documents

Transcript of Agent Programming in Goal Modules