On Sun, Feb 19, 2012 at 6:11 PM, Herman Bruyninckx
<Herman.Bruyninckx@mech.kuleuven.be> wrote:
> If I understand correctly what you mean, my short answer is "yes"! The
> Coordinator just does the event processing, and most of the events
> resulting from this will trigger re-configurations of the components that
> process the data flow. In other words, there is no need for the FSM to do
> the data flow itself. Take the obvious example of the Board of a company:
> their decisions are not processing the data in the company itself, but are
> giving signals to the upper management to change something in the way the
> whole company deals with its data (or products, for that matter).

Thanks for the clarification, and that is an excellent metaphor.
Thanks also to Christian for providing the term "event-driven
coordination", this gave me some references to follow-up on (not very
many close to robotics, though...) In general, this concept sounds
very elegant, and I'm really quite intrigued.

One pre-requisite of this approach seems to be that the components are
prepared to be coordinated in such a way. It is my belief that not all
components can be changed for that, and that therefore, a data-passing
facility within an engine such as SMACH is still necessary.

However, assuming components /can/ be changed (and I see the
advantages of that), the question would be how to make this approach
possible on ROS. I'm still convinced that the Task-State-Pattern (TSP)
is the appropriate communication pattern, because it provides a
generic monitoring facility. However, it does not, in itself, provide
a receiver for coordination events (the task-state events are not
coordination events in the sense of you guys, though they are of
course ideal for consumption by a coordination engine to track a
component's state).

The event-driven coordination literature I found seems to be very
concerned with configuring communication channels. In fact, it looks
to be the primary way for coordination components to influence the
system. I'm not sure whether they mean actual TCP or similar
connections by that, but "channel" seems to be a pretty generic term.
I would think that this could be realized in fairly easily in any TSP
implementation by having the coordination component create a channel
identifier and letting both client and server know about it, so that
they include it in messages (client) and filter for it (server).
Listening for such configuration information shouldn't be hard to do
for most TSP implementations. On the server side, task requests
without a proper channel could then be rejected, and the client may
even be optimized to not send requests unless a channel is explicitly
configured.

Do you think that would fulfill your requirements?

> That's also the reason why a good manager can job-hop to companies with
> very different activities without much problems: his coordination skills
> are reusable, even with limited domain knowledge :-)

*lol* I concur, managers like to think of themselves that way.
However, coordination is just one aspect -- at some point, a decision
on what should be done needs to be made. That is why I like the
metaphor: I think I've been more concerned with decision making, to
the extent that I have viewed everything from the perspective.

cheers,

-- 
Ingo Lütkebohle
Bielefeld University
http://www.techfak.uni-bielefeld.de/~iluetkeb/

PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B