Each Service manages its own input and output. OpenCV Service manages the input of a camera, and the output of processed images. The Speech Recognition Service manages the input of the microphone, and the output of recognized words. The GUIService manages the input of data being delivered to the GUI and output of human interaction/control to the other Services. The Speech Service manages the input of text and output to the speakers.
A complex robots has many inputs and outputs. A "normal" sequential program can not manage all the possibilities all the time.
In this system, simple services are allowed to interact to produce different states, e.g. (an IDLE state, a FIND_OBJECT state.. etc) At some point more services can be easily added and the states can be weighted, so that AVOID_COLLISION state overrides FIND_OBJECT...
I'm hoping to produce robust and complex behaviors with a group of simple services. It's a little like Conway's Game of Life - where there are a set of extremely simple rules (services), but the outcome can be very complex. For example, interesting patterns or behaviors emerge such as gliders guns, breeders, etc.
It might fit in a sequential program if the execution was single threaded and blocked on input/output or polled input/output. In MRL each Service is multi-threaded. To manage this, I have been experimenting with allowing the services to move data into discrete states - this prevents the need for locking, blocking, or polling data, and allows multiple services to interact with one another simultaneously...
I hope I did not butcher that explanation (too much)
.png)
larger images?
The text in the diagrams is realy hard to read, think it got scaled when you uploaded the images.
How's that mogul?
max image upload size was 500x500 - changed it to accomidate giant diagrams...
Does this make sense to you? It's on the edge of my own perception. I do a lot of OOP but diagraming a state machine is rather new to me.
Sense
Well, I can read it now. But I think I'm missing the big picture, why do you need a state machine in the first place?
The diagrams, looks like something that will fit easily into a "normal" sequential program. Do you process more than one image at the same time?
So, no, it does not make sense to me yet. But I havent been around actualy playing with MRL yet, so i'm not that well enlightent either.
Big Picture
MRL is a collection of (simple) Services.
Each Service manages its own input and output. OpenCV Service manages the input of a camera, and the output of processed images. The Speech Recognition Service manages the input of the microphone, and the output of recognized words. The GUIService manages the input of data being delivered to the GUI and output of human interaction/control to the other Services. The Speech Service manages the input of text and output to the speakers.
A complex robots has many inputs and outputs. A "normal" sequential program can not manage all the possibilities all the time.
In this system, simple services are allowed to interact to produce different states, e.g. (an IDLE state, a FIND_OBJECT state.. etc) At some point more services can be easily added and the states can be weighted, so that AVOID_COLLISION state overrides FIND_OBJECT...
A lot of inspiration has come from Dr. Brookes & his Subsumption Architecture.
I'm hoping to produce robust and complex behaviors with a group of simple services. It's a little like Conway's Game of Life - where there are a set of extremely simple rules (services), but the outcome can be very complex. For example, interesting patterns or behaviors emerge such as gliders guns, breeders, etc.
It might fit in a sequential program if the execution was single threaded and blocked on input/output or polled input/output. In MRL each Service is multi-threaded. To manage this, I have been experimenting with allowing the services to move data into discrete states - this prevents the need for locking, blocking, or polling data, and allows multiple services to interact with one another simultaneously...
I hope I did not butcher that explanation (too much)