[ros-users] Current state of SMACH in ROS

[Ingo Lütkebohle]

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.

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

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

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.

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

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? So you'd only let
the ports know what kind of communication to establish. 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).
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. 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.

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