From: Jomi H. <jom...@gm...> - 2022-05-17 19:12:40
|
Hi Burak, I still do not fully understand your application (and its problem). Anyway, the instruction -color(_,ID)[source(_)] could be revised. If color/2 is perceived, it usually does not work to remove it from the BB because in the next cycle the agent will perceive it again and the belief will be reintroduced. Belief with [source(percept)] reflect the environment, and thus they are not directly manipulated by the agent. The agent can, of course, *act* on the environment so to change it and then, as consequence, perceive something different. If the case where color/2 comes from communication (as in the app you sent), the receiver can remove the belief and it remains “removed”. However, I think that belief told by other agent should preferably be removed by them (using untell performative). The best practice is that the agent changes only beliefs it has included, which have [source(self)] — what we sometimes call “mental notes”. However, I am not sure if this issue is related to the problem we are facing with a different environment. HTH, Jomi > On 13 May 2022, at 11:13, Burak Karaduman <bbu...@gm...> wrote: > > Hi Rafael, > > I realised that I shared the wrong code. I am sending the correct one. > > This version works, but first, you are going to see that agents run so fast even to trigger the same plan twice. Therefore, I added this condition (ID-ID2)<2. > > This implementation does not have any environment. It does not give any intention error. However, when I use an environment that has a colour sensor, it gives the intention not to finish the error. > > So if I define these plans as [automic] it may work? > > Thank you. > > > > > Rafael H Bordini <r.b...@ac...>, 13 May 2022 Cum, 04:36 tarihinde şunu yazdı: > Hi Burak, > > As far as I'm aware there is no implicit timeout for intentions. There could be and error in the actions that the intention execute, and I'm not sure if a failure to delete a belief also causes the intention to abort. This is very likely to happened because you manually deleting beliefs that are being created from perception (if I understood correctly) without making the plan atomic. Also, if you want a plan to trigger due to a belief addition, it should start > +color(... > And not > +!color > > > On Thu, 12 May 2022, 18:17 Burak Karaduman, <bbu...@gm...> wrote: > Hi Jomi, > > Thank you for your reply. Let me summarize the story for you, > > +!color(red,ID) : color(red,ID2) ..... > > For example, a sensor reads the colours of the incoming bricks. The first brick is red and has the ID 0, then this creates a belief addition as the head of the plan shows. { +!color(red,ID) }. > > Then, the second brick comes after 5 minutes, which is red and id is 1. > > In this case, this context matching should be triggered {+!color(red,ID) : color(red,ID2) & (ID-ID2)<2 & not ID == ID2} > > However, until the arrival of the second red brick, I think an implicit timeout mechanism is self-triggered and kills the intention by giving ''the intention could not finish error''. If that timeout was disabled, then it could work and wait until the occurrence of the next event. > > Maybe a blind commitment pattern is suitable. But, for this kind of work, I should be able to disable this timeout easily. I think I have already tried .wait commands. > > The intention should not be frozen, but patient enough for the next events. This code works on the computer without any environment, but when I deploy the code onto a system of course physical events do not happen that often. > > Best regards. > > > > > > Jomi Hubner <jom...@gm...>, 12 May 2022 Per, 13:41 tarihinde şunu yazdı: > Dear Burak, > > I wasn’t able to figure out the error that is happening. Is there something more in the error message? (Besides intention could not finish) > > Anyway, any intention can be suspended and resumed latter. The .wait internal action can be used for that, but also .suspend and .resume. > > Maybe the idea of commitments can also help you: > https://github.com/jason-lang/jason/blob/master/doc/tech/patterns.adoc#commitment > > HTH, > > Jomi > > > On 10 May 2022, at 17:06, Burak Karaduman <bbu...@gm...> wrote: > > > > Dear all, > > > > I have an agent code which is as follows: > > > > > > +!color(red,ID) : color(red,ID2) & (ID-ID2)<2 & not ID == ID2 <- push(ID,ID2); mediumPress; .print("A"); .print("Pushing:",red," ",red); -color(_,ID)[source(_)]; -color(_,ID2)[source(_)]. > > > > +!color(red,ID) : color(_,ID2) & (ID-ID2)<2 & not ID == ID2 <- reject(ID2); ejectProduct; .print("B"); -color(_,ID2)[source(_)]. > > > > +!color(OC,ID) : color(red,ID2) & (ID-ID2)<2 & not ID == ID2<- push(ID,ID2);.print("C"); mediumPress; .print("Pushing:",OC," ",red); -color(_,ID)[source(_)]; -color(_,ID2)[source(_)]. > > > > +!color(OC,ID) : color(OC,ID2) & (ID-ID2)<2 & not ID == ID2 <- push(ID,ID2);.print("D"); mediumPress; .print("Pushing:",OC," ",OC); -color(_,ID)[source(_)]; -color(_,ID2)[source(_)]. > > > > +!color(OC,ID) : color(OC2,ID2) & not OC==OC2 & (ID-ID2)<2 & not ID == ID2 <- .print("E"); reject(ID2); ejectProduct; -color(_,ID2)[source(_)]. > > > > The code runs well with a textual environment because the occurrence of the events is quite frequent. Therefore, the next contextual change happens right after the completion of the previous event. The planning mechanism is simple, various consecutive products which have IDs keep coming and the agent is trying to match these products according to their colours. It also uses IDs for comparison because agents run so fast to generate the same event (i.e same products with the same IDs). > > > > However, when I deploy this code to a physical system I get an "Intention could not finish" error, the occurrence of events can have long time periods because of the physical environment. For example product red with ID 0 is generated, then product blue with ID 1 can be generated after 2 minutes or hours. Is it possible to define a timeout for the intention? Or is it possible to await it forever etc? > > > > Best regards. > > > > > > -- > > Burak KARADUMAN, > > Ph.D. Student at the University of Antwerp & Flanders Make, > > Modeling Intelligent Complex Software & Systems (MICSS-Lab), > > G236, Department of Computer Science, Faculty of Science, Campus Middelheim, > > Middelheimlaan 1, 2020 Antwerp, Belgium > > > > _______________________________________________ > > Jason-users mailing list > > Jas...@li... > > https://lists.sourceforge.net/lists/listinfo/jason-users > > > > -- > Burak KARADUMAN, > Ph.D. Student at the University of Antwerp & Flanders Make, > Modeling Intelligent Complex Software & Systems (MICSS-Lab), > G236, Department of Computer Science, Faculty of Science, Campus Middelheim, > Middelheimlaan 1, 2020 Antwerp, Belgium > > _______________________________________________ > Jason-users mailing list > Jas...@li... > https://lists.sourceforge.net/lists/listinfo/jason-users > > > -- > Burak KARADUMAN, > Ph.D. Student at the University of Antwerp & Flanders Make, > Modeling Intelligent Complex Software & Systems (MICSS-Lab), > G236, Department of Computer Science, Faculty of Science, Campus Middelheim, > Middelheimlaan 1, 2020 Antwerp, Belgium > > <Question.zip> |