Quantcast

Pre-processing actions in atomic plans

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Pre-processing actions in atomic plans

Alan Gordon White
Hi all

I've been doing a bit of work involving some pre-processing -  
essentially checking preconditions of the next and subsequent intended  
means - of actions before they are performed.    This involves  
inserting an additional set of steps before the return for  
selectIntention (in a custom Agent class, of course).

However, this doesn't work for atomic plans, which skip that  
particular call - is there a way, either within the Agent or  
associated Arch classes - to make sure a piece of code is executed in  
the period after the current action completes, and before the next  
action is executed?

(for example, before a move(A,B) action is executed, to check that the  
agent contains at(A) in its percepts, that the road A->B is open, and  
the agent is in a reasonable health/fuel status)

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



------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Jason-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jason-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pre-processing actions in atomic plans

Rafael H Bordini-2
Hi Alan,

Jomi is the best person to answer this, but in case he takes long to
answer, I think the answer is yes, as you suggest: the "act()" method of
the AgArch class is where the action is sent, through the
"infrastructure", for the environment to execute it. You can always
customize this class and do the checking there (if needed you could
access annotations of the action there, etc), but that's at the Java
level, not the delcarative level. If that works for you, have a look on
demos/examples on how to customise the Agent Architecture, and the Jason
book also explains in general terms how to do it.

Cheers,

Rafael


On 07/10/2012 19:09, Alan Gordon White wrote:

> Hi all
>
> I've been doing a bit of work involving some pre-processing -
> essentially checking preconditions of the next and subsequent intended
> means - of actions before they are performed.    This involves
> inserting an additional set of steps before the return for
> selectIntention (in a custom Agent class, of course).
>
> However, this doesn't work for atomic plans, which skip that
> particular call - is there a way, either within the Agent or
> associated Arch classes - to make sure a piece of code is executed in
> the period after the current action completes, and before the next
> action is executed?
>
> (for example, before a move(A,B) action is executed, to check that the
> agent contains at(A) in its percepts, that the road A->B is open, and
> the agent is in a reasonable health/fuel status)
>


------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Jason-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jason-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pre-processing actions in atomic plans

Jomi Hubner
Hi Alan,

besides the "act()" method suggested by Rafael, which seems to likely fit your requirements, the method "reasoningCycleStarting", in the agent architecture, is called before each reasoning cycle and is a good place to code something that should be done every cycle. For instance, by looking at getC().getActionFeedback() you can check if there is an action already finished in the environment but not yet processed in the agent (because some atomic intention is running).

HTH,

Jomi


On 08/10/2012, at 17:44, Rafael H Bordini wrote:

> Hi Alan,
>
> Jomi is the best person to answer this, but in case he takes long to
> answer, I think the answer is yes, as you suggest: the "act()" method of
> the AgArch class is where the action is sent, through the
> "infrastructure", for the environment to execute it. You can always
> customize this class and do the checking there (if needed you could
> access annotations of the action there, etc), but that's at the Java
> level, not the delcarative level. If that works for you, have a look on
> demos/examples on how to customise the Agent Architecture, and the Jason
> book also explains in general terms how to do it.
>
> Cheers,
>
> Rafael
>
>
> On 07/10/2012 19:09, Alan Gordon White wrote:
>> Hi all
>>
>> I've been doing a bit of work involving some pre-processing -
>> essentially checking preconditions of the next and subsequent intended
>> means - of actions before they are performed.    This involves
>> inserting an additional set of steps before the return for
>> selectIntention (in a custom Agent class, of course).
>>
>> However, this doesn't work for atomic plans, which skip that
>> particular call - is there a way, either within the Agent or
>> associated Arch classes - to make sure a piece of code is executed in
>> the period after the current action completes, and before the next
>> action is executed?
>>
>> (for example, before a move(A,B) action is executed, to check that the
>> agent contains at(A) in its percepts, that the road A->B is open, and
>> the agent is in a reasonable health/fuel status)
>>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> 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


------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Jason-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jason-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pre-processing actions in atomic plans

Alan Gordon White
Hi Jomi, Rafael

Thanks.  I've been working on this lately, although I've hit a problem  
in terms of the act() method - namely, the maintenance method I'm  
running before action execution can change the intendedMeans stack  
(i.e. forms and inserts a new set of plan steps).  This works fine  
with non-atomic intentions, but I'm not sure how to integrate it with  
the act() method (for example, as I'd need to handle internal actions  
inserted by the planner, re-instantiate the ActionExec to perform, etc  
- which seems messy).

reasonCycleStarting sounds ideal, however; but one thing I'm trying to  
figure out, will the Belief Base be fully 'up to date' at this point?  
(i.e. will percepts have been handled and added into the BB, even  
before the selectEvent method is called?)

Thanks,
Alan

Quoting Jomi Hubner <[hidden email]> on Mon, 8 Oct 2012 21:24:17 -0300:

> Hi Alan,
>
> besides the "act()" method suggested by Rafael, which seems to  
> likely fit your requirements, the method "reasoningCycleStarting",  
> in the agent architecture, is called before each reasoning cycle and  
>  is a good place to code something that should be done every cycle.  
> For instance, by looking at getC().getActionFeedback() you can check  
>  if there is an action already finished in the environment but not  
> yet processed in the agent (because some atomic intention is running).
>
> HTH,
>
> Jomi
>
>
> On 08/10/2012, at 17:44, Rafael H Bordini wrote:
>
>> Hi Alan,
>>
>> Jomi is the best person to answer this, but in case he takes long to
>> answer, I think the answer is yes, as you suggest: the "act()" method of
>> the AgArch class is where the action is sent, through the
>> "infrastructure", for the environment to execute it. You can always
>> customize this class and do the checking there (if needed you could
>> access annotations of the action there, etc), but that's at the Java
>> level, not the delcarative level. If that works for you, have a look on
>> demos/examples on how to customise the Agent Architecture, and the Jason
>> book also explains in general terms how to do it.
>>
>> Cheers,
>>
>> Rafael
>>
>>
>> On 07/10/2012 19:09, Alan Gordon White wrote:
>>> Hi all
>>>
>>> I've been doing a bit of work involving some pre-processing -
>>> essentially checking preconditions of the next and subsequent intended
>>> means - of actions before they are performed.    This involves
>>> inserting an additional set of steps before the return for
>>> selectIntention (in a custom Agent class, of course).
>>>
>>> However, this doesn't work for atomic plans, which skip that
>>> particular call - is there a way, either within the Agent or
>>> associated Arch classes - to make sure a piece of code is executed in
>>> the period after the current action completes, and before the next
>>> action is executed?
>>>
>>> (for example, before a move(A,B) action is executed, to check that the
>>> agent contains at(A) in its percepts, that the road A->B is open, and
>>> the agent is in a reasonable health/fuel status)
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> _______________________________________________
>> 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
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> 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.



------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Jason-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jason-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pre-processing actions in atomic plans

Jomi Hubner

On 15/10/2012, at 12:41, Alan Gordon White wrote:

> reasonCycleStarting sounds ideal, however; but one thing I'm trying to  
> figure out, will the Belief Base be fully 'up to date' at this point?  
> (i.e. will percepts have been handled and added into the BB, even  
> before the selectEvent method is called?)

The reasonCycleStarting is called before the reasoning cycle, so the BB wasn't updated yet. But you can override the buf(...) method, calling super.buf and then running your mechanism. With this approach you ensure that the BB is updated.

HTH

Jomi


>
> Thanks,
> Alan
>
> Quoting Jomi Hubner <[hidden email]> on Mon, 8 Oct 2012 21:24:17 -0300:
>
>> Hi Alan,
>>
>> besides the "act()" method suggested by Rafael, which seems to  
>> likely fit your requirements, the method "reasoningCycleStarting",  
>> in the agent architecture, is called before each reasoning cycle and  
>> is a good place to code something that should be done every cycle.  
>> For instance, by looking at getC().getActionFeedback() you can check  
>> if there is an action already finished in the environment but not  
>> yet processed in the agent (because some atomic intention is running).
>>
>> HTH,
>>
>> Jomi
>>
>>
>> On 08/10/2012, at 17:44, Rafael H Bordini wrote:
>>
>>> Hi Alan,
>>>
>>> Jomi is the best person to answer this, but in case he takes long to
>>> answer, I think the answer is yes, as you suggest: the "act()" method of
>>> the AgArch class is where the action is sent, through the
>>> "infrastructure", for the environment to execute it. You can always
>>> customize this class and do the checking there (if needed you could
>>> access annotations of the action there, etc), but that's at the Java
>>> level, not the delcarative level. If that works for you, have a look on
>>> demos/examples on how to customise the Agent Architecture, and the Jason
>>> book also explains in general terms how to do it.
>>>
>>> Cheers,
>>>
>>> Rafael
>>>
>>>
>>> On 07/10/2012 19:09, Alan Gordon White wrote:
>>>> Hi all
>>>>
>>>> I've been doing a bit of work involving some pre-processing -
>>>> essentially checking preconditions of the next and subsequent intended
>>>> means - of actions before they are performed.    This involves
>>>> inserting an additional set of steps before the return for
>>>> selectIntention (in a custom Agent class, of course).
>>>>
>>>> However, this doesn't work for atomic plans, which skip that
>>>> particular call - is there a way, either within the Agent or
>>>> associated Arch classes - to make sure a piece of code is executed in
>>>> the period after the current action completes, and before the next
>>>> action is executed?
>>>>
>>>> (for example, before a move(A,B) action is executed, to check that the
>>>> agent contains at(A) in its percepts, that the road A->B is open, and
>>>> the agent is in a reasonable health/fuel status)
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Don't let slow site performance ruin your business. Deploy New Relic APM
>>> Deploy New Relic app performance management and know exactly
>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>> http://p.sf.net/sfu/newrelic-dev2dev
>>> _______________________________________________
>>> 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
>>
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> _______________________________________________
>> 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.
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> 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


------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Jason-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jason-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pre-processing actions in atomic plans

Alan Gordon White
Thanks.  It does, I think, albeit I need to figure out how to ensure  
the method calls are made precisely after the previous action has  
completed and before the next action executes (this is in order to  
avoid worrying about fluent states existing in the BB).

Putting the call into act() would be ideal for this, except that my  
code can alter the IntendedMeans stack - which raises issues with (for  
example) handling newly inserted internal actions as a new next step.

(To be clear what happens in my code;

A call is made to the method maintain(Intention i)
- this parses through the most ground IntendedMeans, using some  
pre/post condition knowledge to estimate the subsequent BB state and  
ergo predict action success or failure. Fluents aren't specified for  
actions, so calling in the 'middle' of an execution action can produce  
some funny results and false negatives.
- If a future action is determined as likely to fail, an HTN planner  
generates a new plan from the current state and inserts it directly  
into the stack, setting a new current step.
- This works fine in selectIntention, but makes a few assumptions that  
the call takes place 'in between' actions, and with an up-to-date BB  
as of method call.

It is almost certainly needlessly complicated and obtuse in  
implementation, as a result of learning as-I-go, but unfortunately I  
don't have the time to refactor it properly)

Quoting Jomi Hubner <[hidden email]> on Tue, 16 Oct 2012 08:22:41 -0300:

>
> On 15/10/2012, at 12:41, Alan Gordon White wrote:
>
>> reasonCycleStarting sounds ideal, however; but one thing I'm trying to
>> figure out, will the Belief Base be fully 'up to date' at this point?
>> (i.e. will percepts have been handled and added into the BB, even
>> before the selectEvent method is called?)
>
> The reasonCycleStarting is called before the reasoning cycle, so the  
>  BB wasn't updated yet. But you can override the buf(...) method,  
> calling super.buf and then running your mechanism. With this  
> approach you ensure that the BB is updated.
>
> HTH
>
> Jomi
>
>

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



------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Jason-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jason-users
Loading...