[ros-users] Current state of SMACH in ROS

Herman Bruyninckx Herman.Bruyninckx at mech.kuleuven.be
Mon Feb 20 13:34:24 UTC 2012


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

> On Mon, Feb 20, 2012 at 1:02 PM, Herman Bruyninckx
> <Herman.Bruyninckx at mech.kuleuven.be> wrote:
>> My "horrible legacy" remark was targeted at the component implementations
>> that are now massively invading the internet, not about SMACH.
>
> Ok, good :-)
>
>> 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.
>
> I'm afraid our terminology is getting confused, or at least I am
> confused. What is your definition of "behavior"?

All of the following: "dynamics", "relation between values on ports of a
component", "input/output relationships", ...

> For me, a behavior is the combination of several tasks to achive a
> goal.

Ok, I see. Not my semantics, really, but mine is biased by a history in
control theory and dynamical systems, and less in "AI" :-)

> Tasks, in my terminology, are a "piece of work to be done". In
> contrast, in the OROCOS documentation, I sometimes see the term "task"
> being used to describe the component that does something.

That could then be an unfortunately given name :-)

> Is that the meaning you're using?
Sort of. Because there are more things you can "do" then to provide
(continuous) "behaviour". For example, Coordination is _discrete_
behaviour (that is, the relationship between "events in" and "events out"
is necessarily a discrete algebra or so).

>>> 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.
>
> I wasn't going to, as previously explained.
>
>> 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).
>
> Ok.
>
> That said, despite the (welcome) correction on terminology,
> essentially we agree that its not component itself being configured,
> right?

I am not so sure whether I understand this senstence, since it is not
syntactically correct (I think).

>>> 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.
>
> In fact, it doesn't. I don't get this. Earlier, you were very specific
> that its not the port being configured, its the middleware, and now
> when I say that, the TSP is _not_ being configured, only the
> middleware could be (and, in fact, isn't either in my own
> implementation), you say that that's the same all of a sudden?

_every_ component has configurability, in my universe. Sometimes it's not
made explicit, most of the times it is not exploited, but it _is_ there. (I
am interested in getting to know some use cases that arguably do not need
configurable components, by the way.)

>> Than you have been doing quite biased reading :-)
>
> Would you care to provide a specific reference, then? "coordination"
> is very general search term that turns up many other approaches, and
> "event-driven coordination" in turn seems to have been very specific.

It is very specific, and it is the "paradigm" that we are trying to
introduce in the community. Not much to read about this, yet,
unfortunately.

>> Our internet and
>> telephony systems are not working like that: the connections mostly
>> remains, but the addressee configurations change dynamically.
>
> Well, the history of internet and telephony technology is sufficiently
> complicated to make it not as clear cut as that (and "connection" has
> many meanings in that context), but I get your point.
>
> cheers,
> -- 
> Ingo Lütkebohle

Herman


More information about the ros-users mailing list