On Wed, Jun 24, 2009 at 16:14, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
>
> On Wednesday 24 June 2009 10:51:02 Peter Soetens wrote:
> > I just finished reading this interesting LWN.net article about design
> > patterns in the Linux kernel.
> > http://lwn.net/SubscriberLink/336262/b82ca0894facd94c/
> After having read it, I personally think that this "midlayer" term is not
> relevant to RTT. I think that RTT, right now, is already a library.

And still an RTT component's programming pattern is very distinct from
what ROS nodes look like. If it's not a midlayer, than at least
something else. A few years ago, a group did a classification of
robotics frameworks (was it ROSTA ?). They claimed that Orocos/RTT
(back then) wasn't really middleware, but more a framework. I'm sure
we didn't have CORBA back then, but the point is, frameworks impose a
restriction. The article claims that restrictions will always beg for
special cases, which the framework must work around, which leads to
complexity and inefficiency.

>
> The problem ExecutionEngine::startContexts() has does not come from this
> midlayer-vs-library concepts but a "let's do a completely magic method"
> problem. This method is supposed to relieve the caller from any knowledge
> about the execution state. This not only makes the method's implementation
> complex and error-prone, but also is IMO useless because some method that
> would call startContexts (or TaskContext::start or TaskContext::stop) should
> already be aware of the actual task context state. If it is not, it has no
> business meddling with it and the result should be an error (possibly an
> exception).

This may be true, but the point I wanted to make is that we could
implement the EE in two ways: the library way and the midlayer way. As
an example I pick the 'sharing an EE between multiple TaskContexs'. A
feature present today.
The library way goes like this:

// Inside user's TaskContext: (TC derives from RunnableInterface)
void step() {
   // my code...
   this->engine()->processCommands();
   this->child->step();
   // other code
   this->child->stop();
   // etc.
}

The midlayer way goes like this (schematically, because it would be
already too much code to post here, '->' means 'calls'; {...} means
'executes statements' ):

'thread'->EE::step{
->processcommands;
->processevents;...;
->TC::updateHook;
->{updateHook of all child TC's}
etc
}

What is remarkable here is that the concept of 'sharing' an EE between
multiple TC's is present in both cases, but only in the 'midlayer'
case, the EE must accommodate code for it (see startContexs). In the
library case, there is no need for that (the 'child' TC is just a TC
with a SlaveActivity).

>
> And, in general, magic methods are bad. They give a false sense of security.
> False, because they delay when problem appear. I personally came to strongly
> preferring approaches that validate prerequisites early.
>
> On TaskContext. The purpose of the TaskContext is to provide an integration
> path between the computation and the coordination (as Herman puts them). For
> that, you actually need to provide a model of your computation, and that model
> is called TaskContext. So, it is in my opinion not a midlayer (providing
> generic functionality for a set of specific devices for instance), but a model
> (structuring code so that other parts can use the now structured code in
> various ways).

That's true. Maybe the problem is more in the current EE's
implementation and less in the TC as it stands today.

>
> For the record, I think that removing that strong focus of RTT would be
> killing it altogether. It is what makes tools like genom or RTT worthwile in a
> context where everybody else focusses on communication libraries (like ROS).

I couldn't agree more. I wasn't really on the path of changing the
concepts, but more on the path of how users can express these concepts
in code.

> Both approaches are complementary, and what makes RTT interesting is the
> ability to integrate an already written task context into different
> communication libraries in a way that is transparent to the task context
> itself.
>
> Meaning that you could take your integrated system (i.e. computation +
> coordination) from CORBA and move it to ROS. And that is possible *because*
> RTT requires the robot designer to describe its computation/coordination in
> terms of RTT primitives through the use of TaskContext and friends.
>
> So, to summarize, it's in my opinion not a bug, it's a feature.

I agree fully with these statements.

Peter

On Wed, 24 Jun 2009, Sylvain Joyeux wrote:

> On Wednesday 24 June 2009 10:51:02 Peter Soetens wrote:
>> I just finished reading this interesting LWN.net article about design
>> patterns in the Linux kernel.
>> http://lwn.net/SubscriberLink/336262/b82ca0894facd94c/
> After having read it, I personally think that this "midlayer" term is not
> relevant to RTT. I think that RTT, right now, is already a library.
>
> The problem ExecutionEngine::startContexts() has does not come from this
> midlayer-vs-library concepts but a "let's do a completely magic method"
> problem. This method is supposed to relieve the caller from any knowledge
> about the execution state. This not only makes the method's implementation
> complex and error-prone, but also is IMO useless because some method that
> would call startContexts (or TaskContext::start or TaskContext::stop) should
> already be aware of the actual task context state. If it is not, it has no
> business meddling with it and the result should be an error (possibly an
> exception).
>
> And, in general, magic methods are bad. They give a false sense of security.
> False, because they delay when problem appear. I personally came to strongly
> preferring approaches that validate prerequisites early.

Or that only give "advice" to components to do things, and let _them_
actually do it. (Or not, if their internal state gives good reasons for
this decision.)

> On TaskContext. The purpose of the TaskContext is to provide an integration
> path between the computation and the coordination (as Herman puts them).

And Configuration _and_ Communication! It's really a "best practice"(?) in
the tradeoff between the desired design goal of "loose coupling" on the one
hand, and the "performance" and "minimal set of concepts" goal on the other
hand. (Please comment on this bold statement! :-) Anyway, you can expect
more "best practice" statements or questions from me in the near future, to
show that I am seriously working on the BRICS project: Best practices in
robotics :-))

> For
> that, you actually need to provide a model of your computation, and that model
> is called TaskContext.

I would rather call it a "container", with all the necessary(?) handles, and a
lot of "cross sectional infrastructure" code (logging, FSM, safe data
exchange, ...), but with a minimum(?) of imposed policies.

> So, it is in my opinion not a midlayer (providing
> generic functionality for a set of specific devices for instance), but a model
> (structuring code so that other parts can use the now structured code in
> various ways).
>
> For the record, I think that removing that strong focus of RTT would be
> killing it altogether.

Yes! It should even try to enforce the focus, instead of going in the
opposite direction, in my opinion.

Herman

> It is what makes tools like genom or RTT worthwile in a
> context where everybody else focusses on communication libraries (like ROS).
> Both approaches are complementary, and what makes RTT interesting is the
> ability to integrate an already written task context into different
> communication libraries in a way that is transparent to the task context
> itself.
>
> Meaning that you could take your integrated system (i.e. computation +
> coordination) from CORBA and move it to ROS. And that is possible *because*
> RTT requires the robot designer to describe its computation/coordination in
> terms of RTT primitives through the use of TaskContext and friends.
>
> So, to summarize, it's in my opinion not a bug, it's a feature.

On Jun 24, 2009, at 10:14 , Sylvain Joyeux wrote:

> On Wednesday 24 June 2009 10:51:02 Peter Soetens wrote:
>> I just finished reading this interesting LWN.net article about design
>> patterns in the Linux kernel.
>> http://lwn.net/SubscriberLink/336262/b82ca0894facd94c/
> After having read it, I personally think that this "midlayer" term
> is not
> relevant to RTT. I think that RTT, right now, is already a library.
>
> The problem ExecutionEngine::startContexts() has does not come from
> this
> midlayer-vs-library concepts but a "let's do a completely magic
> method"
> problem. This method is supposed to relieve the caller from any
> knowledge
> about the execution state. This not only makes the method's
> implementation
> complex and error-prone, but also is IMO useless because some method
> that
> would call startContexts (or TaskContext::start or
> TaskContext::stop) should
> already be aware of the actual task context state. If it is not, it
> has no
> business meddling with it and the result should be an error
> (possibly an
> exception).
>
> And, in general, magic methods are bad. They give a false sense of
> security.
> False, because they delay when problem appear. I personally came to
> strongly
> preferring approaches that validate prerequisites early.
>
> On TaskContext. The purpose of the TaskContext is to provide an
> integration
> path between the computation and the coordination (as Herman puts
> them). For
> that, you actually need to provide a model of your computation, and
> that model
> is called TaskContext. So, it is in my opinion not a midlayer
> (providing
> generic functionality for a set of specific devices for instance),
> but a model
> (structuring code so that other parts can use the now structured
> code in
> various ways).
>
> For the record, I think that removing that strong focus of RTT would
> be
> killing it altogether. It is what makes tools like genom or RTT
> worthwile in a
> context where everybody else focusses on communication libraries
> (like ROS).
> Both approaches are complementary, and what makes RTT interesting is
> the
> ability to integrate an already written task context into different
> communication libraries in a way that is transparent to the task
> context
> itself.
>
> Meaning that you could take your integrated system (i.e. computation +
> coordination) from CORBA and move it to ROS. And that is possible
> *because*
> RTT requires the robot designer to describe its computation/
> coordination in
> terms of RTT primitives through the use of TaskContext and friends.
>
> So, to summarize, it's in my opinion not a bug, it's a feature.

I agree with much of what Sylvain says. I'm not personally sure
whether I would classify RTT as a midlayer or library, according to
that article, but I do think that RTT's ease of putting together
networks of components, and the ability to transparently make those
components run on different communications libraries is very helpful.
I find that RTT also helps structure your approach so that you *are
not* depending on particular communication library attributes.

YMMV
Stephen