Messaging asynchronously wrt the reasoning cycle

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Messaging asynchronously wrt the reasoning cycle

Alan Gordon White
Actually, I'm not sure that subject string is the best description.

If I understand correctly, a Jason agent will normally handle received  
messages within the normal reasoning cycle - so (for example) if a  
message is sent prior to an action being executed, any response will  
not be processed by the agent until after said action is completed and  
the reasoning cycle iterates back round.

What I'd like to do, though, is to have a 'contract-formation' phase  
for multiagent action; namely to have a messaging sequence where agent  
A confirms that agent B will perform some action, when requested.  I'm  
trying to make this transparent in terms of the asl files, so my  
thoughts are to implement it at an AgArch level.

My intent is that at each action, the agent checks the plan and  
confirms that all actions not handled locally have the relevant  
dependency relationships formed - if not, these relationships are  
formed.  In certain cases this may not be possible to perform all this  
relationship formation in one go (i.e. if relevant arguments are being  
ground during plan runtime), so I want to perform this upon every plan  
step.

So I'm trying to figure out if one of a few possible approaches would  
be possible;
1) A performs a conversation with B prior to executing the next  
action, within the act() method; essentially it waits for a set  
timeout OR the appropriate message receipt before performing the act  
method.  If it's possible to continuously poll messages (would the  
buf() method allow this?), taking only the relevant ones, I guess this  
could be reasonably simple.
2) A takes the same basic approach, except that act() will skip until  
the desired responses are found (i.e. the agents intention selection /  
action performance are effectively suspended until the conversation(s)  
are complete)

(NB: I hope that description makes sense?)

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Jason-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jason-users
Reply | Threaded
Open this post in threaded view
|

Re: Messaging asynchronously wrt the reasoning cycle

Rafael H Bordini-2
Hi Alan,

I'm not sure I fully understand all you are doing but I'll mention a
couple of things that might help. I'm explicitly CCing Jomi because it's
difficult to keep track of all changes in Jason so if I say something
wrong Jomi can correct me.

1) It doesn't seem to me a good idea for you to delay an act() called
from a particular reasoning cycle until a whole coversation/agreement
takes place. That will make the agent block; all the stuff about
"suspended intentions" exist exactly to avoid that. Have a look had the
synchronous version of .send was implemented to see the support for
suspending an intention; it seems to me that this might help you.

2) There is a method (see the Jason architecture diagram which takes up
a whole page of the Jason book) that is used to select one particular
message to be handled at a given reasoning cycle (provided it's
"socially acceptable"). That method is a good place for "polling
messages" and seeing which ones you need to handle and what they will
mean for your underlying architecture (e.g., resume a suspended intention).

Best of luck!

Rafael


On 06/11/2012 23:06, Alan Gordon White wrote:

> Actually, I'm not sure that subject string is the best description.
>
> If I understand correctly, a Jason agent will normally handle received
> messages within the normal reasoning cycle - so (for example) if a
> message is sent prior to an action being executed, any response will
> not be processed by the agent until after said action is completed and
> the reasoning cycle iterates back round.
>
> What I'd like to do, though, is to have a 'contract-formation' phase
> for multiagent action; namely to have a messaging sequence where agent
> A confirms that agent B will perform some action, when requested.  I'm
> trying to make this transparent in terms of the asl files, so my
> thoughts are to implement it at an AgArch level.
>
> My intent is that at each action, the agent checks the plan and
> confirms that all actions not handled locally have the relevant
> dependency relationships formed - if not, these relationships are
> formed.  In certain cases this may not be possible to perform all this
> relationship formation in one go (i.e. if relevant arguments are being
> ground during plan runtime), so I want to perform this upon every plan
> step.
>
> So I'm trying to figure out if one of a few possible approaches would
> be possible;
> 1) A performs a conversation with B prior to executing the next
> action, within the act() method; essentially it waits for a set
> timeout OR the appropriate message receipt before performing the act
> method.  If it's possible to continuously poll messages (would the
> buf() method allow this?), taking only the relevant ones, I guess this
> could be reasonably simple.
> 2) A takes the same basic approach, except that act() will skip until
> the desired responses are found (i.e. the agents intention selection /
> action performance are effectively suspended until the conversation(s)
> are complete)
>
> (NB: I hope that description makes sense?)
>


------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Jason-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jason-users
Reply | Threaded
Open this post in threaded view
|

Re: Messaging asynchronously wrt the reasoning cycle

Alan Gordon White
Hi Rafael

Sorry if it wasn't clear. Hopefully this explains it a bit.

What I want to do is to establish a dependency relationship between  
one agent delegating a task (within the current plan) and the other  
performing it; and I want to do this as early as possible in the  
execution of the plan.

For example, if an agent is executing an atomic plan along the lines  
of move(A, B), load(Cargo, B), move(B, C), transfer(Cargo, Truck1);  
the last action would be performed by some other agent called Truck1.  
What I want to do, is to have the agent contact Truck1 and inform it  
that it will be executing a 'transfer' action in the future (and to  
form this relationship as early as possible).

The reason for this is part of some underlying assumptions I'm making  
about the multiagent planning and execution process.  Essentially,  
these dependency relationships are being formed to support a Joint  
Intentions/Responsibility style approach, establishing a  
responsibility of Truck1 to inform the dependant agent if (in one  
case) it becomes damaged and unable to perform said transfer act.

(I'm making some simplifying assumptions regarding temporal issues in  
scheduling, etc, for these purposes)

Unfortunately, I can't establish all these dependency relationships  
between agents at plan selection time, because certain arguments may  
not become ground until later in the plan - under certain cases, I may  
need to form such a relationship immediately before the next action  
execution.

At the moment I'm looking at the act() method in order to do this  
messaging work for atomic as well as non-atomic intentions.  I'm  
trying to work out the best approach to take, though, so suspending  
until a messaging cycle completes sounds like it might be the best way.

Cheers,
Alan


Quoting Rafael H Bordini <[hidden email]> on Wed, 07 Nov 2012  
16:47:30 -0200:

> Hi Alan,
>
> I'm not sure I fully understand all you are doing but I'll mention a
> couple of things that might help. I'm explicitly CCing Jomi because it's
> difficult to keep track of all changes in Jason so if I say something
> wrong Jomi can correct me.
>
> 1) It doesn't seem to me a good idea for you to delay an act() called
> from a particular reasoning cycle until a whole coversation/agreement
> takes place. That will make the agent block; all the stuff about
> "suspended intentions" exist exactly to avoid that. Have a look had the
> synchronous version of .send was implemented to see the support for
> suspending an intention; it seems to me that this might help you.
>
> 2) There is a method (see the Jason architecture diagram which takes up
> a whole page of the Jason book) that is used to select one particular
> message to be handled at a given reasoning cycle (provided it's
> "socially acceptable"). That method is a good place for "polling
> messages" and seeing which ones you need to handle and what they will
> mean for your underlying architecture (e.g., resume a suspended intention).
>
> Best of luck!
>
> Rafael
>
>
> On 06/11/2012 23:06, Alan Gordon White wrote:
>> Actually, I'm not sure that subject string is the best description.
>>
>> If I understand correctly, a Jason agent will normally handle received
>> messages within the normal reasoning cycle - so (for example) if a
>> message is sent prior to an action being executed, any response will
>> not be processed by the agent until after said action is completed and
>> the reasoning cycle iterates back round.
>>
>> What I'd like to do, though, is to have a 'contract-formation' phase
>> for multiagent action; namely to have a messaging sequence where agent
>> A confirms that agent B will perform some action, when requested.  I'm
>> trying to make this transparent in terms of the asl files, so my
>> thoughts are to implement it at an AgArch level.
>>
>> My intent is that at each action, the agent checks the plan and
>> confirms that all actions not handled locally have the relevant
>> dependency relationships formed - if not, these relationships are
>> formed.  In certain cases this may not be possible to perform all this
>> relationship formation in one go (i.e. if relevant arguments are being
>> ground during plan runtime), so I want to perform this upon every plan
>> step.
>>
>> So I'm trying to figure out if one of a few possible approaches would
>> be possible;
>> 1) A performs a conversation with B prior to executing the next
>> action, within the act() method; essentially it waits for a set
>> timeout OR the appropriate message receipt before performing the act
>> method.  If it's possible to continuously poll messages (would the
>> buf() method allow this?), taking only the relevant ones, I guess this
>> could be reasonably simple.
>> 2) A takes the same basic approach, except that act() will skip until
>> the desired responses are found (i.e. the agents intention selection /
>> action performance are effectively suspended until the conversation(s)
>> are complete)
>>
>> (NB: I hope that description makes sense?)
>>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Jason-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jason-users
>
>



--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Jason-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jason-users
Reply | Threaded
Open this post in threaded view
|

Re: Messaging asynchronously wrt the reasoning cycle

Jomi Fred Hubner-4
Hi Alan,

it is clearer now. I am not sure about the best way to approach your problem (specially due to the details of your project), but what about using selectIntention: only select intentions that have passed on your controls?

BTW, a similar problem could be solved by an *organisational* approach. You have a set of goals shared among agents and before staring anything, the agents have to commit themselves to that goals. Only when enough agents are committed, the "global" plan starts. It is somehow things work with MOISE framework. In that case the plan is global, outside the agents, and managed by the organisational platform.

HTH,

Jomi

On 07/11/2012, at 21:25, Alan Gordon White wrote:

> Hi Rafael
>
> Sorry if it wasn't clear. Hopefully this explains it a bit.
>
> What I want to do is to establish a dependency relationship between  
> one agent delegating a task (within the current plan) and the other  
> performing it; and I want to do this as early as possible in the  
> execution of the plan.
>
> For example, if an agent is executing an atomic plan along the lines  
> of move(A, B), load(Cargo, B), move(B, C), transfer(Cargo, Truck1);  
> the last action would be performed by some other agent called Truck1.  
> What I want to do, is to have the agent contact Truck1 and inform it  
> that it will be executing a 'transfer' action in the future (and to  
> form this relationship as early as possible).
>
> The reason for this is part of some underlying assumptions I'm making  
> about the multiagent planning and execution process.  Essentially,  
> these dependency relationships are being formed to support a Joint  
> Intentions/Responsibility style approach, establishing a  
> responsibility of Truck1 to inform the dependant agent if (in one  
> case) it becomes damaged and unable to perform said transfer act.
>
> (I'm making some simplifying assumptions regarding temporal issues in  
> scheduling, etc, for these purposes)
>
> Unfortunately, I can't establish all these dependency relationships  
> between agents at plan selection time, because certain arguments may  
> not become ground until later in the plan - under certain cases, I may  
> need to form such a relationship immediately before the next action  
> execution.
>
> At the moment I'm looking at the act() method in order to do this  
> messaging work for atomic as well as non-atomic intentions.  I'm  
> trying to work out the best approach to take, though, so suspending  
> until a messaging cycle completes sounds like it might be the best way.
>
> Cheers,
> Alan
>
>
> Quoting Rafael H Bordini <[hidden email]> on Wed, 07 Nov 2012  
> 16:47:30 -0200:
>
>> Hi Alan,
>>
>> I'm not sure I fully understand all you are doing but I'll mention a
>> couple of things that might help. I'm explicitly CCing Jomi because it's
>> difficult to keep track of all changes in Jason so if I say something
>> wrong Jomi can correct me.
>>
>> 1) It doesn't seem to me a good idea for you to delay an act() called
>> from a particular reasoning cycle until a whole coversation/agreement
>> takes place. That will make the agent block; all the stuff about
>> "suspended intentions" exist exactly to avoid that. Have a look had the
>> synchronous version of .send was implemented to see the support for
>> suspending an intention; it seems to me that this might help you.
>>
>> 2) There is a method (see the Jason architecture diagram which takes up
>> a whole page of the Jason book) that is used to select one particular
>> message to be handled at a given reasoning cycle (provided it's
>> "socially acceptable"). That method is a good place for "polling
>> messages" and seeing which ones you need to handle and what they will
>> mean for your underlying architecture (e.g., resume a suspended intention).
>>
>> Best of luck!
>>
>> Rafael
>>
>>
>> On 06/11/2012 23:06, Alan Gordon White wrote:
>>> Actually, I'm not sure that subject string is the best description.
>>>
>>> If I understand correctly, a Jason agent will normally handle received
>>> messages within the normal reasoning cycle - so (for example) if a
>>> message is sent prior to an action being executed, any response will
>>> not be processed by the agent until after said action is completed and
>>> the reasoning cycle iterates back round.
>>>
>>> What I'd like to do, though, is to have a 'contract-formation' phase
>>> for multiagent action; namely to have a messaging sequence where agent
>>> A confirms that agent B will perform some action, when requested.  I'm
>>> trying to make this transparent in terms of the asl files, so my
>>> thoughts are to implement it at an AgArch level.
>>>
>>> My intent is that at each action, the agent checks the plan and
>>> confirms that all actions not handled locally have the relevant
>>> dependency relationships formed - if not, these relationships are
>>> formed.  In certain cases this may not be possible to perform all this
>>> relationship formation in one go (i.e. if relevant arguments are being
>>> ground during plan runtime), so I want to perform this upon every plan
>>> step.
>>>
>>> So I'm trying to figure out if one of a few possible approaches would
>>> be possible;
>>> 1) A performs a conversation with B prior to executing the next
>>> action, within the act() method; essentially it waits for a set
>>> timeout OR the appropriate message receipt before performing the act
>>> method.  If it's possible to continuously poll messages (would the
>>> buf() method allow this?), taking only the relevant ones, I guess this
>>> could be reasonably simple.
>>> 2) A takes the same basic approach, except that act() will skip until
>>> the desired responses are found (i.e. the agents intention selection /
>>> action performance are effectively suspended until the conversation(s)
>>> are complete)
>>>
>>> (NB: I hope that description makes sense?)
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>> Stay in control, update software, and manage PCs from one command center
>> Diagnose problems and improve visibility into emerging IT issues
>> Automate, monitor and manage. Do more in less time with Central
>> http://p.sf.net/sfu/logmein12331_d2d
>> _______________________________________________
>> Jason-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jason-users
>>
>>
>
>
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Jason-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jason-users

--
Jomi Fred Hubner
Federal University of Santa Catarina
Department of Automation and Systems Engineering
PO Box 476, Florianópolis, SC
88040-900 Brazil
http://www.das.ufsc.br/~jomi


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Jason-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jason-users
Reply | Threaded
Open this post in threaded view
|

Re: Messaging asynchronously wrt the reasoning cycle

Rafael H Bordini-2
In reply to this post by Alan Gordon White
Hi Alan,

That's indeed an interesting problem and definitely another place to
look at is the selectIntention as Jomi suggested. That's where you'll
find out if a particular action is to be executed next: it'll be the
action at the current position of execution of the topmost plan of the
selected intention. That'll be "immediately before" the "next action"
(if it's an action to be executed in that selected intention).

Cheers,

Rafael


On 07/11/2012 21:25, Alan Gordon White wrote:

> Hi Rafael
>
> Sorry if it wasn't clear. Hopefully this explains it a bit.
>
> What I want to do is to establish a dependency relationship between one
> agent delegating a task (within the current plan) and the other
> performing it; and I want to do this as early as possible in the
> execution of the plan.
>
> For example, if an agent is executing an atomic plan along the lines of
> move(A, B), load(Cargo, B), move(B, C), transfer(Cargo, Truck1); the
> last action would be performed by some other agent called Truck1. What I
> want to do, is to have the agent contact Truck1 and inform it that it
> will be executing a 'transfer' action in the future (and to form this
> relationship as early as possible).
>
> The reason for this is part of some underlying assumptions I'm making
> about the multiagent planning and execution process. Essentially, these
> dependency relationships are being formed to support a Joint
> Intentions/Responsibility style approach, establishing a responsibility
> of Truck1 to inform the dependant agent if (in one case) it becomes
> damaged and unable to perform said transfer act.
>
> (I'm making some simplifying assumptions regarding temporal issues in
> scheduling, etc, for these purposes)
>
> Unfortunately, I can't establish all these dependency relationships
> between agents at plan selection time, because certain arguments may not
> become ground until later in the plan - under certain cases, I may need
> to form such a relationship immediately before the next action execution.
>
> At the moment I'm looking at the act() method in order to do this
> messaging work for atomic as well as non-atomic intentions. I'm trying
> to work out the best approach to take, though, so suspending until a
> messaging cycle completes sounds like it might be the best way.
>
> Cheers,
> Alan
>
>
> Quoting Rafael H Bordini <[hidden email]> on Wed, 07 Nov 2012
> 16:47:30 -0200:
>
>> Hi Alan,
>>
>> I'm not sure I fully understand all you are doing but I'll mention a
>> couple of things that might help. I'm explicitly CCing Jomi because it's
>> difficult to keep track of all changes in Jason so if I say something
>> wrong Jomi can correct me.
>>
>> 1) It doesn't seem to me a good idea for you to delay an act() called
>> from a particular reasoning cycle until a whole coversation/agreement
>> takes place. That will make the agent block; all the stuff about
>> "suspended intentions" exist exactly to avoid that. Have a look had the
>> synchronous version of .send was implemented to see the support for
>> suspending an intention; it seems to me that this might help you.
>>
>> 2) There is a method (see the Jason architecture diagram which takes up
>> a whole page of the Jason book) that is used to select one particular
>> message to be handled at a given reasoning cycle (provided it's
>> "socially acceptable"). That method is a good place for "polling
>> messages" and seeing which ones you need to handle and what they will
>> mean for your underlying architecture (e.g., resume a suspended
>> intention).
>>
>> Best of luck!
>>
>> Rafael
>>
>>
>> On 06/11/2012 23:06, Alan Gordon White wrote:
>>> Actually, I'm not sure that subject string is the best description.
>>>
>>> If I understand correctly, a Jason agent will normally handle received
>>> messages within the normal reasoning cycle - so (for example) if a
>>> message is sent prior to an action being executed, any response will
>>> not be processed by the agent until after said action is completed and
>>> the reasoning cycle iterates back round.
>>>
>>> What I'd like to do, though, is to have a 'contract-formation' phase
>>> for multiagent action; namely to have a messaging sequence where agent
>>> A confirms that agent B will perform some action, when requested. I'm
>>> trying to make this transparent in terms of the asl files, so my
>>> thoughts are to implement it at an AgArch level.
>>>
>>> My intent is that at each action, the agent checks the plan and
>>> confirms that all actions not handled locally have the relevant
>>> dependency relationships formed - if not, these relationships are
>>> formed. In certain cases this may not be possible to perform all this
>>> relationship formation in one go (i.e. if relevant arguments are being
>>> ground during plan runtime), so I want to perform this upon every plan
>>> step.
>>>
>>> So I'm trying to figure out if one of a few possible approaches would
>>> be possible;
>>> 1) A performs a conversation with B prior to executing the next
>>> action, within the act() method; essentially it waits for a set
>>> timeout OR the appropriate message receipt before performing the act
>>> method. If it's possible to continuously poll messages (would the
>>> buf() method allow this?), taking only the relevant ones, I guess this
>>> could be reasonably simple.
>>> 2) A takes the same basic approach, except that act() will skip until
>>> the desired responses are found (i.e. the agents intention selection /
>>> action performance are effectively suspended until the conversation(s)
>>> are complete)
>>>
>>> (NB: I hope that description makes sense?)
>>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>> Stay in control, update software, and manage PCs from one command center
>> Diagnose problems and improve visibility into emerging IT issues
>> Automate, monitor and manage. Do more in less time with Central
>> http://p.sf.net/sfu/logmein12331_d2d
>> _______________________________________________
>> Jason-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jason-users
>>
>>
>
>
>

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Jason-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jason-users
Reply | Threaded
Open this post in threaded view
|

Re: Messaging asynchronously wrt the reasoning cycle

Rafael H Bordini-2
In reply to this post by Alan Gordon White
PS: regarding the other comment made by Jomi, one of the various
interesting things to do, at some point, might be to contrast your
approach to JaCaMo (jacamo.sf.net) where the coordination problem would
be dealt by the Moise organisational level. as with anything, there
would be advantages and disadvantages, I imagine.


On 07/11/2012 21:25, Alan Gordon White wrote:

> Hi Rafael
>
> Sorry if it wasn't clear. Hopefully this explains it a bit.
>
> What I want to do is to establish a dependency relationship between one
> agent delegating a task (within the current plan) and the other
> performing it; and I want to do this as early as possible in the
> execution of the plan.
>
> For example, if an agent is executing an atomic plan along the lines of
> move(A, B), load(Cargo, B), move(B, C), transfer(Cargo, Truck1); the
> last action would be performed by some other agent called Truck1. What I
> want to do, is to have the agent contact Truck1 and inform it that it
> will be executing a 'transfer' action in the future (and to form this
> relationship as early as possible).
>
> The reason for this is part of some underlying assumptions I'm making
> about the multiagent planning and execution process. Essentially, these
> dependency relationships are being formed to support a Joint
> Intentions/Responsibility style approach, establishing a responsibility
> of Truck1 to inform the dependant agent if (in one case) it becomes
> damaged and unable to perform said transfer act.
>
> (I'm making some simplifying assumptions regarding temporal issues in
> scheduling, etc, for these purposes)
>
> Unfortunately, I can't establish all these dependency relationships
> between agents at plan selection time, because certain arguments may not
> become ground until later in the plan - under certain cases, I may need
> to form such a relationship immediately before the next action execution.
>
> At the moment I'm looking at the act() method in order to do this
> messaging work for atomic as well as non-atomic intentions. I'm trying
> to work out the best approach to take, though, so suspending until a
> messaging cycle completes sounds like it might be the best way.
>
> Cheers,
> Alan
>
>
> Quoting Rafael H Bordini <[hidden email]> on Wed, 07 Nov 2012
> 16:47:30 -0200:
>
>> Hi Alan,
>>
>> I'm not sure I fully understand all you are doing but I'll mention a
>> couple of things that might help. I'm explicitly CCing Jomi because it's
>> difficult to keep track of all changes in Jason so if I say something
>> wrong Jomi can correct me.
>>
>> 1) It doesn't seem to me a good idea for you to delay an act() called
>> from a particular reasoning cycle until a whole coversation/agreement
>> takes place. That will make the agent block; all the stuff about
>> "suspended intentions" exist exactly to avoid that. Have a look had the
>> synchronous version of .send was implemented to see the support for
>> suspending an intention; it seems to me that this might help you.
>>
>> 2) There is a method (see the Jason architecture diagram which takes up
>> a whole page of the Jason book) that is used to select one particular
>> message to be handled at a given reasoning cycle (provided it's
>> "socially acceptable"). That method is a good place for "polling
>> messages" and seeing which ones you need to handle and what they will
>> mean for your underlying architecture (e.g., resume a suspended
>> intention).
>>
>> Best of luck!
>>
>> Rafael
>>
>>
>> On 06/11/2012 23:06, Alan Gordon White wrote:
>>> Actually, I'm not sure that subject string is the best description.
>>>
>>> If I understand correctly, a Jason agent will normally handle received
>>> messages within the normal reasoning cycle - so (for example) if a
>>> message is sent prior to an action being executed, any response will
>>> not be processed by the agent until after said action is completed and
>>> the reasoning cycle iterates back round.
>>>
>>> What I'd like to do, though, is to have a 'contract-formation' phase
>>> for multiagent action; namely to have a messaging sequence where agent
>>> A confirms that agent B will perform some action, when requested. I'm
>>> trying to make this transparent in terms of the asl files, so my
>>> thoughts are to implement it at an AgArch level.
>>>
>>> My intent is that at each action, the agent checks the plan and
>>> confirms that all actions not handled locally have the relevant
>>> dependency relationships formed - if not, these relationships are
>>> formed. In certain cases this may not be possible to perform all this
>>> relationship formation in one go (i.e. if relevant arguments are being
>>> ground during plan runtime), so I want to perform this upon every plan
>>> step.
>>>
>>> So I'm trying to figure out if one of a few possible approaches would
>>> be possible;
>>> 1) A performs a conversation with B prior to executing the next
>>> action, within the act() method; essentially it waits for a set
>>> timeout OR the appropriate message receipt before performing the act
>>> method. If it's possible to continuously poll messages (would the
>>> buf() method allow this?), taking only the relevant ones, I guess this
>>> could be reasonably simple.
>>> 2) A takes the same basic approach, except that act() will skip until
>>> the desired responses are found (i.e. the agents intention selection /
>>> action performance are effectively suspended until the conversation(s)
>>> are complete)
>>>
>>> (NB: I hope that description makes sense?)
>>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>> Stay in control, update software, and manage PCs from one command center
>> Diagnose problems and improve visibility into emerging IT issues
>> Automate, monitor and manage. Do more in less time with Central
>> http://p.sf.net/sfu/logmein12331_d2d
>> _______________________________________________
>> Jason-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jason-users
>>
>>
>
>
>

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Jason-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jason-users
Reply | Threaded
Open this post in threaded view
|

Re: Messaging asynchronously wrt the reasoning cycle

Alan Gordon White
In reply to this post by Jomi Fred Hubner-4
Hi Jomi

SelectIntention would be ideal, except that it (as I understand)  
wouldn't be called during execution of an atomic plan.  I can envisage  
a situation where the agent to perform some action might only be  
identified after the execution of an earlier plan action.

(NB; for simplicity, I'm explicitly stating the actors within action  
args and using that to infer the dependency formation requirements -  
i.e. so a plan could have something like .findClosestTruck(T,  
"London"); moveTo(T, "London"))

WRT to goal commitment; the one thing is that I'm using the dependency  
formation to underly a failure anticipation/response approach.  The  
idea (behind my implementation) is that if an obliged agent loses  
confidence in being able to perform some task, the dependant is able  
to modify or reform the plan in response; the goal is to have the  
distributed plan being modified / repaired in a similar manner to a  
single agent maintaining a hierarchical plan.

I'm not familiar with MOISE (yet), so I need to have a look first  
(particularly wrt the global plan concept).

Quoting Jomi Fred Hubner <[hidden email]> on Wed, 7 Nov 2012 21:43:08 -0200:

> Hi Alan,
>
> it is clearer now. I am not sure about the best way to approach your  
>  problem (specially due to the details of your project), but what  
> about using selectIntention: only select intentions that have passed  
>  on your controls?
>
> BTW, a similar problem could be solved by an *organisational*  
> approach. You have a set of goals shared among agents and before  
> staring anything, the agents have to commit themselves to that  
> goals. Only when enough agents are committed, the "global" plan  
> starts. It is somehow things work with MOISE framework. In that case  
>  the plan is global, outside the agents, and managed by the  
> organisational platform.
>
> HTH,
>
> Jomi
>
> On 07/11/2012, at 21:25, Alan Gordon White wrote:
>
>> Hi Rafael
>>
>> Sorry if it wasn't clear. Hopefully this explains it a bit.
>>
>> What I want to do is to establish a dependency relationship between
>> one agent delegating a task (within the current plan) and the other
>> performing it; and I want to do this as early as possible in the
>> execution of the plan.
>>
>> For example, if an agent is executing an atomic plan along the lines
>> of move(A, B), load(Cargo, B), move(B, C), transfer(Cargo, Truck1);
>> the last action would be performed by some other agent called Truck1.
>> What I want to do, is to have the agent contact Truck1 and inform it
>> that it will be executing a 'transfer' action in the future (and to
>> form this relationship as early as possible).
>>
>> The reason for this is part of some underlying assumptions I'm making
>> about the multiagent planning and execution process.  Essentially,
>> these dependency relationships are being formed to support a Joint
>> Intentions/Responsibility style approach, establishing a
>> responsibility of Truck1 to inform the dependant agent if (in one
>> case) it becomes damaged and unable to perform said transfer act.
>>
>> (I'm making some simplifying assumptions regarding temporal issues in
>> scheduling, etc, for these purposes)
>>
>> Unfortunately, I can't establish all these dependency relationships
>> between agents at plan selection time, because certain arguments may
>> not become ground until later in the plan - under certain cases, I may
>> need to form such a relationship immediately before the next action
>> execution.
>>
>> At the moment I'm looking at the act() method in order to do this
>> messaging work for atomic as well as non-atomic intentions.  I'm
>> trying to work out the best approach to take, though, so suspending
>> until a messaging cycle completes sounds like it might be the best way.
>>
>> Cheers,
>> Alan
>>
>>
>> Quoting Rafael H Bordini <[hidden email]> on Wed, 07 Nov 2012
>> 16:47:30 -0200:
>>
>>> Hi Alan,
>>>
>>> I'm not sure I fully understand all you are doing but I'll mention a
>>> couple of things that might help. I'm explicitly CCing Jomi because it's
>>> difficult to keep track of all changes in Jason so if I say something
>>> wrong Jomi can correct me.
>>>
>>> 1) It doesn't seem to me a good idea for you to delay an act() called
>>> from a particular reasoning cycle until a whole coversation/agreement
>>> takes place. That will make the agent block; all the stuff about
>>> "suspended intentions" exist exactly to avoid that. Have a look had the
>>> synchronous version of .send was implemented to see the support for
>>> suspending an intention; it seems to me that this might help you.
>>>
>>> 2) There is a method (see the Jason architecture diagram which takes up
>>> a whole page of the Jason book) that is used to select one particular
>>> message to be handled at a given reasoning cycle (provided it's
>>> "socially acceptable"). That method is a good place for "polling
>>> messages" and seeing which ones you need to handle and what they will
>>> mean for your underlying architecture (e.g., resume a suspended intention).
>>>
>>> Best of luck!
>>>
>>> Rafael
>>>
>>>
>>> On 06/11/2012 23:06, Alan Gordon White wrote:
>>>> Actually, I'm not sure that subject string is the best description.
>>>>
>>>> If I understand correctly, a Jason agent will normally handle received
>>>> messages within the normal reasoning cycle - so (for example) if a
>>>> message is sent prior to an action being executed, any response will
>>>> not be processed by the agent until after said action is completed and
>>>> the reasoning cycle iterates back round.
>>>>
>>>> What I'd like to do, though, is to have a 'contract-formation' phase
>>>> for multiagent action; namely to have a messaging sequence where agent
>>>> A confirms that agent B will perform some action, when requested.  I'm
>>>> trying to make this transparent in terms of the asl files, so my
>>>> thoughts are to implement it at an AgArch level.
>>>>
>>>> My intent is that at each action, the agent checks the plan and
>>>> confirms that all actions not handled locally have the relevant
>>>> dependency relationships formed - if not, these relationships are
>>>> formed.  In certain cases this may not be possible to perform all this
>>>> relationship formation in one go (i.e. if relevant arguments are being
>>>> ground during plan runtime), so I want to perform this upon every plan
>>>> step.
>>>>
>>>> So I'm trying to figure out if one of a few possible approaches would
>>>> be possible;
>>>> 1) A performs a conversation with B prior to executing the next
>>>> action, within the act() method; essentially it waits for a set
>>>> timeout OR the appropriate message receipt before performing the act
>>>> method.  If it's possible to continuously poll messages (would the
>>>> buf() method allow this?), taking only the relevant ones, I guess this
>>>> could be reasonably simple.
>>>> 2) A takes the same basic approach, except that act() will skip until
>>>> the desired responses are found (i.e. the agents intention selection /
>>>> action performance are effectively suspended until the conversation(s)
>>>> are complete)
>>>>
>>>> (NB: I hope that description makes sense?)
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>>> Stay in control, update software, and manage PCs from one command center
>>> Diagnose problems and improve visibility into emerging IT issues
>>> Automate, monitor and manage. Do more in less time with Central
>>> http://p.sf.net/sfu/logmein12331_d2d
>>> _______________________________________________
>>> Jason-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/jason-users
>>>
>>>
>>
>>
>>
>> --
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>> Stay in control, update software, and manage PCs from one command center
>> Diagnose problems and improve visibility into emerging IT issues
>> Automate, monitor and manage. Do more in less time with Central
>> http://p.sf.net/sfu/logmein12331_d2d
>> _______________________________________________
>> Jason-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jason-users
>
> --
> Jomi Fred Hubner
> Federal University of Santa Catarina
> Department of Automation and Systems Engineering
> PO Box 476, Florianópolis, SC
> 88040-900 Brazil
> http://www.das.ufsc.br/~jomi
>
>
>



--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Jason-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jason-users