[ros-users] Current state of SMACH in ROS

[Herman Bruyninckx]

On Sun, 19 Feb 2012, Ingo Lütkebohle wrote:

> On Sun, Feb 19, 2012 at 6:11 PM, Herman Bruyninckx
> <Herman.Bruyninckx at 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.
>
Event-driven processing is, indeed, a major "gap" in robotics, and in
general in the whole Computer Science education, as far as I am concerned.
It's where "good old-fashioned" industrial robotics excelled (but in a much
narrower context than what is needed for future service robotics), and that
experience seems to have been almost completely forgotten in modern
developments (in robotics).

> 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.

I don't think so! It's _way_ better to refactor your components than to
impose such horrible legacy on your coordinator. But fundamental
refactoring of existing "nodes" is not something that I hear or read about
often in a ROS context; the probably reason is because there are so few
thorough discussions about the "ROS component model"...?

> 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.

ROS has data flow as its basic inter-process communication; sending "pure"
events as data flow is easy and correct. So, there is nothing in ROS that
fundamentally prohibits a pure event-driven coordination.

>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).

Hence, TSP is not the right thing to advocate... :-)

> 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.

As it should be! The communication middleware should be chosen fully
independently from the communication architecture. (In principle, at least,
since there often are performance requirements that some middlewares cannot
provide.)

> 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,

It's not good practice to let components know about the identity of the
other components they are communicating with...

> 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.

Yes. And to some extent that is true. Although I personally prefer to have
someone with domain knowledge. :-)

> 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

Herman