Remote-control warfare: Droning on

Blogging for the record an interesting piece entitled "Remote-control warfare: Droning on" about "How to build ethical understanding into pilotless war planes" which featured in the April 3rd 2010 issue of The Economist (Science and Technology section). A quote:

... Ronald Arkin of the Georgian Institute of Technology's School of Interactive Computing has a suggestion that might ease some of these concerns. He proposes involving the drone itself - or, rather, the software that is used to operate it - in the decision to attack. In effect, he plans to give the machine a conscience...

Good article. Worth a re-read.

Deadlock in Implementation

After quite a few days debugging finally spotted the problem...

Consider the following case:

1) a1 initiates a proposal with a3 and a4.
2) a2 initiates the same proposal with a3 and a4.
3) a3 responds to a1 with acceptance.
4) a4 responds to a2 with acceptance.

In this situation a3 cannot respond to a2 and a4 cannot respond to a1. Both are stuck.

Now need to think what to do about it!

68-69, Coloured Trails (CT) game

Looked through a couple of papers describing and running experiments using the Coloured Trails (CT) game for multi-agent resource negotiation:

68, The Influence of Social Dependencies on Decision-Making: Initial Investigations with a New Game, by Barbara J. Grosz, Sarit Kraus & Shavit Talman, 2004.

69, The Effects of Goal Revelation on Computer-Mediated Negotiation, by Ya'akov Gal et al, 2009.

Implementation referenced in [69] can be found here:
http://www.eecs.harvard.edu/ai/ct

PrologBeans Intro

I use PrologBeans to interface Jade (built on Java) and Prolog. Google it for details. Roughly, what you need to do is:

1. Start up an agent (a Java file). E.g. 'AgentNegotiatior.java' as contained in my 'argmas09modified' directory.
2. From this, make a connection to a Prolog server using 'PBConnect.java' (leave this unchanged) which requires a Prolog file like 'run.pl'. The Prolog file (in my case 'run.pl') loads up 'pbconnection.pl' (which I have modified for my purposes) and whatever other Prolog files you need to load (containing your Prolog clauses) before calling 'main' (defined in 'pbconnection.pl').
3. Run your queries from the Java file using a 'PrologSession' instance.
4. Shut down the server upon completion from your Java file.

Hope that makes sense.

JADE, PrologBeans, CaSAPI

Almost done linking JADE (Java Agent DEvelopment Framework), PrologBeans (package for integrating Java and Prolog applications) and CaSAPI (Credulous and Sceptical Argumentation Prolog Implementation). Should be done by the end of the week, ready to put the three to collaborate use as of next week, God-willing :)

PrologBeans - note to self 2

If I bind the atom "ag1" to the variable "Agent" using some Bindings instance ('b') and execute the query "has(Agent,Resource)" whilst providing 'b', then, as expected, if the query succeeds, a value is bound to the variable "Resource" in the returned QueryAnswer instance ('answer').

In addition, in 'answer', a value "ag1" is also bound to "Agent".

So, it seems 'answer' contains value bindings for output variables as well as input variables.

PrologBeans - note to self 1

In executing a query using a PrologSession instance, a QueryAnswer instance is returned.

If there was an error in execution, the QueryAnswer instance will return true for isError() but false for queryFailed().

PrologBeans

I spent this week interfacing Prolog with JADE. Seems to be working roughly (i.e. starting up an agent, making a connection to a Prolog server, running a query and then shutting down the server). Need to test it thoroughly and make corrections early next week before proceeding.

JADE - Behaviour Scheduling and Execution

"An agent can execute several behaviours concurrently. However, it is important to note that the scheduling of behaviours in an agent is not pre-emptive (as for Java threads), but cooperative. This means that when a behaviour is scheduled for exection its action() method is called and runs until it returns. Therefore it is the programmer who defines when an agent switches from the execution of one behaviour to the execution to another."

(Source: developing multi-agent systems with JADE)

Jason - note to self 6

Given a hypothetical execution as follows:
(1) an agent ag1 delegates a goal !g1 to an agent ag2;
(2) ag2 begins executing !g1 (as delegated by ag1);
(3) ag2 reaches a stage in the plan body of !g1 where it has to execute !g2;
(4) ag2 is in the process of executing !g2 (called from !g1);
(5) ag2 receives an 'unachieve !g1' message from ag1.

Now, in processing the 'unachieve' message, !g1 would be removed from the current set of intentions. !g2 (and any goals subsequently called by !g2 that are currently in the stack of intentions) would also be removed.

This is because all those plans chosen to achieve sub-goals would be within the stack of plans forming the intention, on top of the plan for !g1, which would be dropped (and everything on top of it too, necessarily).

HOWEVER... the case for !! is different (recall that this allows the agent to achieve a goal in a SEPARATE intention). In this case, if we choose to achieve a goal in a separate intention, we lose track of why we were trying to achieve the goal. Needless to say, although this (!!) operator is provided because it can be useful, this is one of the reasons why it should be used with care.

Modifying step (5) as "ag2 receives an 'unachieve !g2' message from ag1". In this case, !g1 will also be dropped since the 'unachieve' uses the '.drop_desire' intention. '.drop_desire(g2)' "kills" the intention where !g2 appears and no failure event is produced. If we used 'fail_goal' instead of 'drop_desire', this allows a different behaviour. With this, the plan for !g2 would be terminated and a failure of !g1 (note it's g1 here) would be created.

Jason - note to self 5

When an agent receives an 'unachieve' message, it checks all its related desires (goal addition events in the set of events) and intentions (goal additions in the set of intentions or in suspended intentions) and drops those.

In a situation where the agent receives the 'unachieve' message BEFORE it has even the desire to achieve the goal in question, nothing will be done.

An 'unachieve' message, from ag1 to ag2 say, should "kill" only those intentions in ag2 created by 'achieve' messages from ag1 (i.e. agents should only be able to drop desires in other agents that are created from their 'achieve' messages). However, this is not presently the case.

Jason - note to self 4

Agent programming is intrinsically concurrent: Agents and the environment, unless otherwise specified, run asynchronously, so various executions of some given code are possible. The different executions represent different interleavings of the executions of the threads of each of the agents, which is determined by the operating system scheduling. With 2 processors (or in a distributed network), the possibilities increase further.

Summing up, the asynchronous execution and the way events are produced by Belief Update Function lead to very different executions. This however corresponds to "real life". In case a more detailed control is required, the execution should be synchronised. This can be done by the "synchronous" execution mode.

It is worth reading up on concurrency and threads. A good Distributed Systems book should suffice.

Jason - note to self 3

It does not make much sense to have a plan to handle failures of a goal that has no plans. In other words, to have
-!g .....
without
+!g .....
does not make sense.

The "-!g" should be read like "in case the plan to achieve !g fails, do this".

Jason - note to self 2

Initial beliefs generate belief addition events when the agent code is run.

Jason - note to self 1

When an agent itself creates a goal the annotation "source(self)" is not added; and then there is no annotation. The solution is to add the source explicitly when the agent itself creates a goal.