[ros-users] Current state of SMACH in ROS

[Herman Bruyninckx]

On Mon, 20 Feb 2012, Ingo Lütkebohle wrote:

> On Mon, Feb 20, 2012 at 8:53 AM, Herman Bruyninckx
> <Herman.Bruyninckx at mech.kuleuven.be> wrote:
>> 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).
>
> Well, the "narrow context" is probably not an accident here, but that
> remains to be seen.
>
>>
>>> 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.
>
> As much as I like the general ideas being put forward here, I think
> there is currently very little /quantifiable/ evidence that proves the
> superiority of this approach. I would therefore, at least for the
> moment, be cautious about calling other ways of doing things "horrible
> legacy". In fact, I would say that using SMACH or similar solutions is
> already a step forward for many systems.

My "horrible legacy" remark was targeted at the component implementations
that are now massively invading the internet, not about SMACH.

> In general, my intuition is that both of the approaches we have talked
> about have their place, and neither should be used exclusively.

Just wait long enough, and any intuition will be proven wrong. Be
pro-active, and have the pleasure to be the first one to prove your
intuition wrong :-)

>> 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 didn't say otherwise.
>
>>> 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... :-)
>
> I think there may be a misunderstanding here, though I can't tell for
> sure, because you didn't say why it is not right thing to advocate.
> Please let me know why you think that, so that I can react to it.

As I mentioned in another posting: TSP mixes up the coordination of
behaviour with the coordination of execution of tasks. These are two
different things so it makes sense not to mix them in one software tool.

> Just in case, because I think that might be the misunderstanding: I'm
> not suggesting that TSP be the interface for coordination. I'm
> suggesting that the information that the TSP provides would be an
> excellent basis for keeping a coordination component informed of the
> state of the system in a generic fashion.

"the state": see my remark above about behavioural state and computational
state.

>>> 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...
>
> Right, but I didn't say that, I only said to let them know the
> identity of the /channel/.

Even that is probably too much to give to a component.

> The fundamental issue here may be that in the component-model view,
> establishing communication is performed by configuring "ports", which
> are part of the same process, but provided by the framework, and hence
> not considered to be part of the "component", right?

"Ports" are the interface to what is part of the component and what is not.

> So you'd only let
> the ports know what kind of communication to establish.

Not really: each Port _can_ only do the kind of communication that it is
designed for; its the _communication_ middleware that has to be configured
(both in connectivity, as in QoS of the communication transfer).

> My use of the
> term "client" and "server" is ambiguous in this regard, because it
> doesn't specify whether the ports or the internals are informed.
>
> The thing is, the TSP describes a very similar separation for
> different reasons. It doesn't make use of the term "port", because the
> TSP implementations we have studied don't have a concept of external
> configurability (beyond those provided by the underlying middleware).

So, it _has_ configurability, and sweeping it under the carpet is not good.

> That said, this would be trivial to add, and the client interface
> respectively server-interface would be the logical choice to do so,
> and this would be completely transparent to the component as such.
>
> btw, I should note that I'm actually already talking implementation
> here, which I think is a crucial matter. From the event-driven
> coordination papers I have read so far, they all talk about
> establishing and tearing down communication links as a matter of
> course.

Than you have been doing quite biased reading :-) Our internet and
telephony systems are not working like that: the connections mostly
remains, but the addressee configurations change dynamically.

> There is a constant re-configuration going on, without the
> slightest consideration of the cost (both in time and in
> synchronization) this entails when done naively.

yes, that's why I mentioned your "biased reading" of communication
coordination :-)

> cheers,
>
Herman