About component architectures...
Herman Bruyninckx <[email protected]>
| Newsgroups | gmane.science.robotics.orocos.user |
|---|---|
| Message-ID | <Pine.LNX.4.44.0204251001380.1054-100000@pc25-213.mech.kuleuven.ac.be> |
Some thoughts about component architectures... (Feedback is _very_ welcome!) Some initial description about the set of generic Orocos component architectures has already been given in the minutes of the Toulouse meeting, but more discussion and fine-tuning is necessary, I think. In the three component architectures we mentioned (Feedback control, Robotic service, Autonomous system), we always seem to come up with a `supervisor': the subcomponent that ``knows all'' about the component, and that configures the other sub-components, and gives them work to do. I am not too happy with a `supervisor' because that is such a general name that covers too many different things we want to separate. For example, I think that, in terms of Software Patterns, the `supervisor' is really two things: - Configurator (what the people in LAAS call ``control flow'' I guess), which takes care of the proper initialization of its internal sub-components and their communication. A key property of a configurator is that it intervenes _only once_ (per configuration action) for the objects or components that it configures. - Mediator (``data flow'') that accepts service requests from the user and divides those into actions for its sub-components. A key property of a Mediator is that it intervenes in _every_ interaction between the objects or components it mediates. This seems the case to me for all service requests that enter the component. Maybe it's even more, but I hope not, in order to keep things simple. Should we make separate sub-component for each of these ``roles'' or should we do just that: call it supervisor, and give it different roles (Configurator, Mediator) to play? I hope (and am quite sure) to be able to use existing Software Pattern names as much as possible, because this helps a lot in documenting what we mean. How much of all this is really generic for _all_ the components we need? Herman -- K.U.Leuven, Mechanical Engineering, Robotics Research Group <http://www.mech.kuleuven.ac.be/~bruyninc> +32 16 322480