The Psyche application (turquoise bottom box in the diagram) is the interface between the automaton and the mind (PAM.P2). See PAM.P2 architecture: https://www.academia.edu/9997454/PAM.P2
The final Psyche design does allow for a socket library or messaging library to fit in the box labeled "Sockets". Either can work. See Psyche architecture: https://www.academia.edu/11360510/Psyche In this design, Monitors are for interioception. Sensors are for exterioception. Actuators are for action execution and proprioception. The monitors and sensors contain timers that will periodically poll the device and deliver messages (percepts, datasets, etc.) to the Mind. The Timer component is a server-based timer that raises an Elapsed event in your application after a specified number of milliseconds defined by the Interval property have elapsed. You can configure the Timer object to raise the event just once or repeatedly. Typically, a Timer object is declared at the class level so that it stays in scope as long as it is needed. You can then handle its Elapsed event to provide regular processing. For example, suppose you have a critical server that must be kept running 24 hours a day, 7 days a week. You could create a service that uses a Timer object to periodically check the server and ensure that the system is up and running. If the system is not responding, the service could attempt to restart the server or notify an administrator. (from https://msdn.microsoft.com/en-us/library/system.timers.timer%28v=vs.110%29.aspx ) The heart of ZeroMQ is "the socket". The main part of ZeroMQ is the socket. It's not the traditional socket, but it's a socket that provides a layer of abstraction on top of the traditional socket API, which frees us from the complexity and the repeated tasks that we do in our applications. ZeroMQ supports several types of sockets (the type of the socket is defined as an attribute value in the socket itself). The different combinations of socket types in the sending and receiving ends give us different communication patterns that we will explore some of them in this article. (from http://www.codeproject.com/Articles/488207/ZeroMQ-via-Csharp-Introduction) In the revised Psyche architecture, we're now we're down to only one semaphore on the receiver. The remaining activity occurs through events on timers, or events raised in the Receiver. I've coded everything in the Psyche already except the device API for the robot. Hopefully done with that by Sunday, the Ides of March. Thanks for the feedback. Your thoughts are always appreciated and welcome. Cheers, Michael. Date: Fri, 13 Mar 2015 16:11:10 -0700 From: [email protected] To: [email protected] Subject: Re: [agi] Psyche semaphore... What are the timers for exactly? I would go to a more event based model. I would bypass .net and other OS specific stuff. Zeromq instead of TCPIP has a lot of advantages: 1) works between processes and between threads; 2) supports pub-sub (great for events!) as well as simple message passing; 3) supports more complex fan-in, fan-out message patterns; 4) very fast, no middleman choke point Hope that helps or gives you some alternatives. - s On 03/08/2015 06:54 PM, Piaget Modeler via AGI wrote: Sometimes we're dealing with a lot of high fallutin' AI-esque algorithms and lose sight of the basics. In this case no special handling, just socket messaging, events and timers. ~PM Date: Sun, 8 Mar 2015 20:55:17 -0400 Subject: Re: [agi] Psyche semaphore... From: [email protected] To: [email protected] If a thread, for example, created other threads as it tried to solve some problem, then the little o problem could become a big o problem. But it did not sound like that was the situation that was being described. Jim Bromer On Sun, Mar 8, 2015 at 8:49 PM, Jim Bromer <[email protected]> wrote: Microsoft .net has events that can be posted which will be read by another part of the code (including but not necessarily other threads). I cannot remember just how it is executed but I remember from long ago that the modern processors all have many exception processes which means that code can be interrupted in order to do something with 'external' (virtual or actual -peripheral or software) data. So a semaphore reading loop should not be absolutely necessary. However, most programs use some kind of loop and even if data is sent through an event in .net, I just used the event type data (the type of event that I defined) to fill in a variable in the other thread which was then read in a loop that examined the variable along with other variables. The problem is that even if you found an event-like method (or a software exception-like thing) the demand that the timer loop exit gracefully almost means that it will definitely need to stay within its main program loop. If you found an event-like action that you could use you might set the timer to 0 or something like that and let it exit according to the timer=0 plan or something. That would allow the program to react without checking some kind of event variable. However, you probably have to ask the java people about that. I don't like simple software switches that have to be read over and over again until they are set when they are only set once. However, modern processors don't recommend that the programmer uses dynamic code. It would be fairly easy to use dynamic code (with C++) to change the execution code if that was something that really was important. So the program follows one code path until the condition occurs in which case the execution code is changed a little. Stick in a new branch or something like that. With C++ and all the layers that we have between us and the machine code you would have to use different pieces of code like different function calls. But again, unless that was part of the fundamental nature of how your program is going to work, all the little function calls that you need only to be able to deal with the condition then adds extra jumps between the function particles. So it is really the same thing - there is going to be some extra little stuff in the code just to deal with the occasional conditional - unless you want to use a bunch of really small functions that are strung together anyway. You could do that in java but is it really going to make your program more efficient. Anyway, does it make sense for you to worry about details like little o stuff? Jim Bromer On Sun, Mar 8, 2015 at 4:46 AM, Piaget Modeler via AGI <[email protected]> wrote: I'm working on a Psyche application this week which interacts with a device on behalf of an AI "mind". Here's a proposed call tree diagram. What do you think? Terminated is a boolean semaphore object that tells the timers that the program is done, and that the timers should terminate gracefully. An event will set the Terminated semaphore object to True. The only problem is that the semaphore will be continually read by all the timers when determining whether to exit their timer loop. Is there a better way? Your thoughts? ~PM AGI | Archives | Modify Your Subscription AGI | Archives | Modify Your Subscription AGI | Archives | Modify Your Subscription AGI | Archives | Modify Your Subscription ------------------------------------------- AGI Archives: https://www.listbox.com/member/archive/303/=now RSS Feed: https://www.listbox.com/member/archive/rss/303/21088071-f452e424 Modify Your Subscription: https://www.listbox.com/member/?member_id=21088071&id_secret=21088071-58d57657 Powered by Listbox: http://www.listbox.com
