RTT 2.0 Roadmap: my personal summary...

Submitted by bruyninc on Fri, 2009-02-27 14:25

Dear colleagues,

here is my personal summary of the last weeks of 2.0 roadmap discussions. I
have not particular motivation to post this but the fact that such a
summary will be needed sooner or later anyway :-)

I acknowledge all of you who have provided feedback or remarks at some time
during the long discussion threads, but also some people who I discussed
with offline. In particular Klas Nilsson, from Lund Technical University,
who is very knowledgable in realtime robot control since he designed the
new (realtime Java + Xenomai based!) controller for the ABB robots, _and_
who introduced me to the "4C" concerns paper by Radestock and Eisenbach
(1996). Besides Klas, I have now also better understood the value (and
limitations) of the "codel" principle of Genom developed by LAAS
<https://softs.laas.fr/openrobots/wiki/genom>.

I present a very "bird's eye view" on RTT, and I am motivated by the
scientific drive to find a _minimal_ amount of fundamentally different,
"orthogonal" concepts with which to provide a _complete_ description of all
we want to do within the RTT scope.

So, here I go...

The first thing that is needed is a "refactoring" of some of the Orocos
terminology (both for minimality and completeness):
- reusing exactly matching concept descriptions from widely accepted
international standards such as UML2, etc. Markus is taking care of that
to some extent already.
- reformulating RTT's goals and programming primitives in the "4C" context
(see below for more details).
- giving the single-thread "Activity" the central place in the TaskContext,
with PeriodicActivity as a special case. NonPeriodicActivity should
disappear.

Secondly, using an asynchronous message passing (AMP) infrastructure as the
basis for all inter-activity communication and event passing would lead to
a smaller, better defined and hence more comprehensible and maintainable
code. AMP is a generic (i.e., minimal and complete) _mechanism_ with which
many (all?) of the IPC _policies_ can be implemented. Without loss of
online efficiency and performance _if_ the most appropriate implementation
(= serialization of the calculations involved in all 4Cs) can be generated
automatically. (See the following paragraph for a presentation of the three
different "use cases".)

Thirdly, a three-layered structure in RTT according to component complexity
would also bring improved comprehensibility (and better opportunities for
code generation and other model-driven engineering tools). Over the last
couple of years, I have found the following three "use cases" or "orders of
system complexity" to be _minimal_ and _complete_:
- Class 1: "Centralized hardware, centralized state".
- Class 2: "Decentralized hardware, centralized state".
- Class 3: "decentralized hardware, decentralized state".
(Class 4, centralized hardware, decentralized state, does not occur in
robotics, but does occur in, e.g., server virtualization.)

A PLC-driven machine (cola vending machine, coffee machine) is an example
of Class 1: there is one single Activity that reads/writes to all hardware
via memory mapped IO, and it has complete knowledge about the state of the
whole system. All Computation (see below for more details about the 4Cs of
which Computation is one) is done sequentially, and hence synchronously.

A modern robot or machine tool are examples of Class 2, differing only from
Class 1 by the fact that some hardware is to be accessed via a "fieldbus".
This introduces the lowest complexity of asynchronous programming, but only
for hardware drivers, and not for the logic of the application program
Computations, which are still possible in one single Activity, and in a
synchronous way (because the device drivers provide a "data port" like
decoupling between the hardware and the Activity software).

Class 3 are the "multi-robot" or "multi-intelligent sensor" systems, in
which the application's Computations must be done in various Activities
that have to Coordinate themselves.

Fourthly, the "four functionality concerns" (4C) of systems and components:
- Computation: the computations that are behind the functionality of the
application; e.g., control algorithm, Kalman Filter, motion planner,
computer vision algorithm, kinematics transformation, etc.
Computation is the core reason of existence of each TaskContext Activity.
- Communication: getting events and data from one Activity to another one,
including support for (serialization policies of) event handling, data
port buffering/blocking policies, etc.
- Configuration: very much the current RTT configuration concept.
- Coordination: the code with which one coordinates the Computations in
different Activities, as well as their Communication. A Finite State
Machine is the mathematical concept for internal Coordination within
one single Activity ;
CSP and Petri nets are Coordination models for multiple Activities,
where CSP is a policy that reduces the flexibility to such an extent that
the multi-Activity system can be understood with (little more than) the
single-activity, synchronous FSM model.
RTT has already much of the 4C functionalities available, but
structuring/decoupling them according to the 4C classes would help a lot in
making things easier to understand. (Providing corresponding examples in OCL
would be great.)

Finally, the relationship between single-Activity Coordination and Finite
State Machines in RTT's TaskContext. In the discussions about this topic,
we were looking about the best way to implement FSM with the available RTT
primitives and code. However, I now think we should _reverse_ the view on
this problem, and make sure that all single-activity TaskContexts show
themselves to the outside world as behaviour that can be _modelled_ by the
concept of a perfect, mathematically formalizable State Machine. The core
concept there is that everything that takes place in such a TaskContext
should happen in "atomic", uninterruptable "codels" (= pieces of
computations). The atomicity is _not_ to be guaranteed wrt to other
activities (within RTT or not) but it is limited to all "internal" aspects
of Coordination between Communication (= the handling of events, and the
reading or writing to DataPorts), Computation (= the application
functionality running in the Activity), and Configuration. In other words,
we are back to where Peter and myself started 7 years ago: configurable
serialization of the 4Cs within one single-activity TaskContext! (That is,
"Class 1" system complexity.) Where we made a (conceptual) mistake is to
not limit ourselves to Class 1, but to (implicitly!) assume that we were
also solving "Class 2/3" system complexity, but that is not true:
"codel"-like atomicity cannot be guaranteed in multi-Activity
(decentralized state) or decentralized hardware cases...

If each TaskContext can be modelled as a perfect FSM (with, of course, the
inevitable "semantic deviation points" as documented and configurable
options), RTT is fully ready to be part of a model-driven engineering
toolchain, and its corresponding code generation and formal verification.

So, that's all folcks! Feedback, of course, very much welcome...

Herman

‹ [GSOC]Please review and contribute to project application form Second call for Google summer of code ideas. ›
»

RTT 2.0 Roadmap: my personal summary...

Submitted by Sylvain Joyeux on Mon, 2009-03-02 10:50.

> The first thing that is needed is a "refactoring" of some of the Orocos
> terminology (both for minimality and completeness):
> - reusing exactly matching concept descriptions from widely accepted
> international standards such as UML2, etc. Markus is taking care of that
> to some extent already.
Okay ... I may have some harsh words in the following paragraph. I just hope
that nobody will take it personally.

My experience is that mostly nobody knows UML. Everybody talks about it, but
use it "as they see fit" (i.e. take a graphical tool, makes nice diagrams, but
does not care about the actual meaning of what they're doing). Here's the
harsh part: the big reason why is that UML is hugely bloated spec that no one
in its right mind would dig in. The only persons mad enough to do it are the
one that actually develop the spec, or research in model-driven engineering (I
won't start a flamewar by saying what I think about most of MDE-related
research). And because they actually tried to cover so much stuff, in as
componentized as possible, leading to a Java-standard-library kind of model.
It makes things very VERY complicated.

Other example: the OMG robotics component model. This is horrible. Not because
it does not cover everything, but because *it does* and every little piece has
its own class. I don't like OMG standards for that. I personally think that
Orocos should try to merge as much concepts as possible into one single
implementation instead of trying to map stuff to the gazillions of little
pieces that are advocated by OMG standards. The current component model of
Orocos is actually very simple, and would be even more simple if Peter's
propositions are implemented.

> A modern robot or machine tool are examples of Class 2, differing only from
> Class 1 by the fact that some hardware is to be accessed via a "fieldbus".
> This introduces the lowest complexity of asynchronous programming, but only
> for hardware drivers, and not for the logic of the application program
> Computations, which are still possible in one single Activity, and in a
> synchronous way (because the device drivers provide a "data port" like
> decoupling between the hardware and the Activity software).

> Class 3 are the "multi-robot" or "multi-intelligent sensor" systems, in
> which the application's Computations must be done in various Activities
> that have to Coordinate themselves.
For me, that is already the case for a robot. But YMMV.

> - Coordination: the code with which one coordinates the Computations in
> different Activities, as well as their Communication. A Finite State
> Machine is the mathematical concept for internal Coordination within
> one single Activity ;
> CSP and Petri nets are Coordination models for multiple Activities,
> where CSP is a policy that reduces the flexibility to such an extent
> that the multi-Activity system can be understood with (little more than)
> the single-activity, synchronous FSM model.
> RTT has already much of the 4C functionalities available, but
> structuring/decoupling them according to the 4C classes would help a lot in
> making things easier to understand. (Providing corresponding examples in
> OCL would be great.)
On the coordination side: I would like you to let me know where you stand. One
great feature of the current RTT is that, thanks to the default TaskContext
automata, one can use Orocos components while relying on other coordination
mechanisms (I think about plan-based mechanisms here ...). Just because you
can spawn the task contexts and coordinate them *from outside*. I think it is
a very important feature, and I'd like to be sure that it remains in your
vision.

If you would ask me what should be the main development goal for RTT right
now, I would answer "reducing the class count". There is already way too much
classes that are lying around for no purpose other than "having one class
represent one thing". See the DataFlowInterface. It is actually only used by
TaskContext, and will probably never be used by any other class. So *why* have
it as a separate class ? And there are number of such examples.

All and all, I do agree on most of your points. What would be very nice is for
us to make/have a roadmap. Because I'm not paid to rewrite Orocos from
scratch, but to use it. Even though I'm trying to contribute (of course).

»

RTT 2.0 Roadmap: my personal summary...

Submitted by sspr on Wed, 2009-03-04 21:10.

On Monday 02 March 2009 11:46:45 Sylvain Joyeux wrote:
> If you would ask me what should be the main development goal for RTT right
> now, I would answer "reducing the class count". There is already way too
> much classes that are lying around for no purpose other than "having one
> class represent one thing". See the DataFlowInterface. It is actually only
> used by TaskContext, and will probably never be used by any other class. So
> *why* have it as a separate class ? And there are number of such examples.

When asking this question, one has to consider the alternatives. Today we
have:

this->ports()->addPort( &dataport, "Description");

Where ports() returns a DataFlowInterface object (which isn't an 'interface'
in the Java meaning of the word).
One way of reducing the class count is to merge all 'dynamic interface' parts
of the TC to one big 'TaskContextInterface' object. Something like:
this->interface()->addPort( &dataport, "Description");
this->interface()->addMethod( &method, "Description");
// ...

One could go even further and put all these methods into the TaskContext class
itself:
this->addPort( &dataport, "Description");
this->addMethod( &method, "Description");
// ...

We have to wonder what we're winning in each case. The last case leads to a
huge (probably overwhelming) object (on the API level), the former case may be
to much fragmented. The reason things were separated into objects was to allow
encapsulation and let the class structure reflect the different composite parts
of an Orocos component.

Maybe DataFlowInterface wasn't your best example, there are places (like the
ExecutionEngine or scripting classes) where the fragmentation is probably much
worse.

Now that we're talking API, a discussion we had a few years ago was about the
'registration' functions of the interface parts. Why doesn't a DataPort allow
to write in the TC constructor:

Mycomponent() 
  : public TaskContext("component"),
    the_port("name","description",this)
{}

where the whole addPort thing can be omitted. The main reason this proposal
didn't pass is because of our distinction between 'scripting/CORBA'
registration and 'pure C++ only' registration of interface parts. Thus:

// only locally accessible from C++ (1):
this->methods()->addMethod(&meth);
// accessible in C++,scripting and CORBA (2):
this->methods()->addMethod(&meth, "Description");

The idea was that we didn't want to decide at RTT compile time if scripting
should be included or not, but let the user decide at component compile time
if the scripting complexity should be dragged into (t)his component. Since
we're using templates, the extra C++ code was not generated in case (1),
leading to a smaller footprint.

I wonder (seriously) if this is ever used, ie, wouldn't users of (1) disable
scripting in RTT completely in the first place ?

>
> All and all, I do agree on most of your points. What would be very nice is
> for us to make/have a roadmap. Because I'm not paid to rewrite Orocos from
> scratch, but to use it. Even though I'm trying to contribute (of course).

The problem with roadmaps (on websites) is that they tend to age quickly. I'm
prepared to put up a page again (and am trying to do so for RTT 2.0) but you
might not get what you asked for...

Peter

»

RTT 2.0 Roadmap: my personal summary...

Submitted by bruyninc on Thu, 2009-03-05 12:10.

A short follow up on the discussion between Sylvain and myself...

- just to make sure: I will not object (at all!) against incremental
improvements (such as Sylvain's refactoring patches) even if they are not
"perfect" in my long-term, broad view! Every improvement is gratefully
welcomed.
- I think the apparent "tension" between the short-term development and the
long-term, "network transparanet services" with respect to the
communication aspects of Orocos is indeed only apparent and it can be
easily solved without loosing long-term viability: let the DataPort
features indeed be implemented as simple 'send and forget' (with some
_internal_ configuration options, such as 'remembering the last value,
which are very good for the debugging and reporting infrastructure for
individual components) while any more complex communication policy is taken
care of by active components that manage one or more DataPorts. The
overhead of this extra component is not necessary for more coupled
applications, while it is inevitable for the more complex and distributed
ones, but in the latter case one is willing to pay this price.

Herman

»

RTT 2.0 Roadmap: my personal summary...

Submitted by Sylvain Joyeux on Thu, 2009-03-05 12:35.

> - I think the apparent "tension" between the short-term development and the
> long-term, "network transparanet services" with respect to the
> communication aspects of Orocos is indeed only apparent and it can be
> easily solved without loosing long-term viability: let the DataPort
> features indeed be implemented as simple 'send and forget' (with some
> _internal_ configuration options, such as 'remembering the last value,
> which are very good for the debugging and reporting infrastructure for
> individual components) while any more complex communication policy is
> taken care of by active components that manage one or more DataPorts. The
> overhead of this extra component is not necessary for more coupled
> applications, while it is inevitable for the more complex and distributed
> ones, but in the latter case one is willing to pay this price.

For once, I fully agree with that statement ;-)

Sylvain

»

RTT 2.0 Roadmap: my personal summary...

Submitted by bruyninc on Thu, 2009-03-05 14:50.

On Thu, 5 Mar 2009, Sylvain Joyeux wrote:

>> - I think the apparent "tension" between the short-term development and the
>> long-term, "network transparanet services" with respect to the
>> communication aspects of Orocos is indeed only apparent and it can be
>> easily solved without loosing long-term viability: let the DataPort
>> features indeed be implemented as simple 'send and forget' (with some
>> _internal_ configuration options, such as 'remembering the last value,
>> which are very good for the debugging and reporting infrastructure for
>> individual components) while any more complex communication policy is
>> taken care of by active components that manage one or more DataPorts. The
>> overhead of this extra component is not necessary for more coupled
>> applications, while it is inevitable for the more complex and distributed
>> ones, but in the latter case one is willing to pay this price.
>
> For once, I fully agree with that statement ;-)
>
That's what I have experienced many times in the last decade: especially
with Peter and Klaas I have had extremely heated discussions, but at the
end it turned out that we were almost always in very good agreement, but
often talking about complementary aspects of the project... :-) But every
single "heated discussion" was very useful, in order to get more clarity in
the minds of the people (including myself) and (hopefully) also in the code
and the documentation...

Herman

»

RTT 2.0 Roadmap: my personal summary...

Submitted by Sylvain Joyeux on Thu, 2009-03-05 10:45.

> Maybe DataFlowInterface wasn't your best example, there are places (like
> the ExecutionEngine or scripting classes) where the fragmentation is
> probably much worse.
>
> Now that we're talking API, a discussion we had a few years ago was about
> the 'registration' functions of the interface parts. Why doesn't a DataPort
> allow to write in the TC constructor:
> 

> Mycomponent()
>
>   : public TaskContext("component"),
>
>     the_port("name","description",this)
> {}
>

Actually, one thing the current interface allows right now is to share ports
between different task contexts. It is corner case as well, but can be nice.

Actually, now that I think of it, it allows for the load-balancing case that
is missing in the new data flow ;-)

Sylvain

»

RTT 2.0 Roadmap: my personal summary...

Submitted by snrkiwi on Wed, 2009-03-04 22:20.

On Mar 4, 2009, at 16:07 , Peter Soetens wrote:

> On Monday 02 March 2009 11:46:45 Sylvain Joyeux wrote:
>> If you would ask me what should be the main development goal for
>> RTT right
>> now, I would answer "reducing the class count". There is already
>> way too
>> much classes that are lying around for no purpose other than
>> "having one
>> class represent one thing". See the DataFlowInterface. It is
>> actually only
>> used by TaskContext, and will probably never be used by any other
>> class. So
>> *why* have it as a separate class ? And there are number of such
>> examples.
>
> When asking this question, one has to consider the alternatives.
> Today we
> have:
> 

> this->ports()->addPort( &dataport, "Description");
>

> Where ports() returns a DataFlowInterface object (which isn't an
> 'interface'
> in the Java meaning of the word).
> One way of reducing the class count is to merge all 'dynamic
> interface' parts
> of the TC to one big 'TaskContextInterface' object. Something like:
> 
> this->interface()->addPort( &dataport, "Description");
> this->interface()->addMethod( &method, "Description");
> // ...
>

> One could go even further and put all these methods into the
> TaskContext class
> itself:
> 
> this->addPort( &dataport, "Description");
> this->addMethod( &method, "Description");
> // ...
>

> We have to wonder what we're winning in each case. The last case
> leads to a
> huge (probably overwhelming) object (on the API level), the former
> case may be
> to much fragmented. The reason things were separated into objects
> was to allow
> encapsulation and let the class structure reflect the different
> composite parts
> of an Orocos component.
>
> Maybe DataFlowInterface wasn't your best example, there are places
> (like the
> ExecutionEngine or scripting classes) where the fragmentation is
> probably much
> worse.
>
> Now that we're talking API, a discussion we had a few years ago was
> about the
> 'registration' functions of the interface parts. Why doesn't a
> DataPort allow
> to write in the TC constructor:
> 
> Mycomponent()
>  : public TaskContext("component"),
>    the_port("name","description",this)
> {}
>

I've almost suggested this last option a couple of times now, if only
to reduce the amount of typing required. I also regularly end up
forgetting to add the port with "this->ports()..." after adding a new
port, only to run the program, get an error, go back and fix it, and
cycle again.

IIRC all the APIs would work like the above, except for methods which
currently *require* that their parameters be textually described. Else
you get a lovely boost static assert ...

> where the whole addPort thing can be omitted. The main reason this
> proposal
> didn't pass is because of our distinction between 'scripting/CORBA'
> registration and 'pure C++ only' registration of interface parts.
> Thus:
> 

> // only locally accessible from C++ (1):
> this->methods()->addMethod(&meth);
> // accessible in C++,scripting and CORBA (2):
> this->methods()->addMethod(&meth, "Description");
>

>
> The idea was that we didn't want to decide at RTT compile time if
> scripting
> should be included or not, but let the user decide at component
> compile time
> if the scripting complexity should be dragged into (t)his component.
> Since
> we're using templates, the extra C++ code was not generated in case
> (1),
> leading to a smaller footprint.
>
> I wonder (seriously) if this is ever used, ie, wouldn't users of (1)
> disable
> scripting in RTT completely in the first place ?

Is there no middle ground we can come up with? If using scripting
then defaults to self-registering ports/methods/events/... with both C+
+ and scripting (2), otherwise self-registers only C++ (1)?

Begs the question of what is the use case for most Orocos users?

S

»

RTT 2.0 Roadmap: my personal summary...

Submitted by bruyninc on Thu, 2009-03-05 07:10.

On Wed, 4 Mar 2009, S Roderick wrote:

[...]
> Begs the question of what is the use case for most Orocos users?
--> "Begs the question of what is the use case for most _potential_ Orocos
users?" We should not look too much to only the curent sample of users:
they're just too damned good :-)

Herman

»

RTT 2.0 Roadmap: my personal summary...

Submitted by bruyninc on Mon, 2009-03-02 11:25.

On Mon, 2 Mar 2009, Sylvain Joyeux wrote:

>> The first thing that is needed is a "refactoring" of some of the Orocos
>> terminology (both for minimality and completeness):
>> - reusing exactly matching concept descriptions from widely accepted
>> international standards such as UML2, etc. Markus is taking care of that
>> to some extent already.
> Okay ... I may have some harsh words in the following paragraph. I just hope
> that nobody will take it personally.
>
> My experience is that mostly nobody knows UML. Everybody talks about it, but
> use it "as they see fit" (i.e. take a graphical tool, makes nice diagrams, but
> does not care about the actual meaning of what they're doing). Here's the
> harsh part: the big reason why is that UML is hugely bloated spec that no one
> in its right mind would dig in. The only persons mad enough to do it are the
> one that actually develop the spec, or research in model-driven engineering (I
> won't start a flamewar by saying what I think about most of MDE-related
> research). And because they actually tried to cover so much stuff, in as
> componentized as possible, leading to a Java-standard-library kind of model.
> It makes things very VERY complicated.

But complex software systems _are_ complicated... What do you advocate
instead? The endless creation of yet another project that is motivated by
doing things in a simple way, but doesn't scale at all in the long run...?

> Other example: the OMG robotics component model. This is horrible. Not because
> it does not cover everything, but because *it does* and every little piece has
> its own class. I don't like OMG standards for that. I personally think that
> Orocos should try to merge as much concepts as possible into one single
> implementation instead of trying to map stuff to the gazillions of little
> pieces that are advocated by OMG standards.

I am very much against that "monolithic" approach. Configuration complexity
can be hidden (to some extent) behind tool support.

> The current component model of
> Orocos is actually very simple, and would be even more simple if Peter's
> propositions are implemented.

Yes, but this component model needs to evolve towards more complex systems,
sooner or later, involving all the "bloat" that goas with it.
Your reaction is normal but typical for someone whose use case is limited
to only one of the three system complexity classes that I keep on talking
about; and since you are "single-system-minded", you think there is no need
for other systems, and the corresponding software support :-)
I do agree with you that every system-class developer should be able to
work with Orocos without having to use or know the "bloat" that goes with
the more complex level(s).

>> A modern robot or machine tool are examples of Class 2, differing only from
>> Class 1 by the fact that some hardware is to be accessed via a "fieldbus".
>> This introduces the lowest complexity of asynchronous programming, but only
>> for hardware drivers, and not for the logic of the application program
>> Computations, which are still possible in one single Activity, and in a
>> synchronous way (because the device drivers provide a "data port" like
>> decoupling between the hardware and the Activity software).
>
>> Class 3 are the "multi-robot" or "multi-intelligent sensor" systems, in
>> which the application's Computations must be done in various Activities
>> that have to Coordinate themselves.
> For me, that is already the case for a robot. But YMMV.
That's why I also mention "multi-intelligent sensor" systems :-)

>> - Coordination: the code with which one coordinates the Computations in
>> different Activities, as well as their Communication. A Finite State
>> Machine is the mathematical concept for internal Coordination within
>> one single Activity ;
>> CSP and Petri nets are Coordination models for multiple Activities,
>> where CSP is a policy that reduces the flexibility to such an extent
>> that the multi-Activity system can be understood with (little more than)
>> the single-activity, synchronous FSM model.
>> RTT has already much of the 4C functionalities available, but
>> structuring/decoupling them according to the 4C classes would help a lot in
>> making things easier to understand. (Providing corresponding examples in
>> OCL would be great.)
> On the coordination side: I would like you to let me know where you stand. One
> great feature of the current RTT is that, thanks to the default TaskContext
> automata, one can use Orocos components while relying on other coordination
> mechanisms (I think about plan-based mechanisms here ...). Just because you
> can spawn the task contexts and coordinate them *from outside*. I think it is
> a very important feature, and I'd like to be sure that it remains in your
> vision.
It is! Coordination is (and should always be!) an "outside" activity.
That's why I advocate looking at other frameworks such as OSGi etc. And why
I want 2.0 to cut out all Coordination parts, while still keeping/making
the remaining rest ready for external coordination :-)

> If you would ask me what should be the main development goal for RTT right
> now, I would answer "reducing the class count". There is already way too much
> classes that are lying around for no purpose other than "having one class
> represent one thing".

I fully agree and that's why I am making this effort of finding/describing
the _least amount_ of different concepts that we really need.

> See the DataFlowInterface. It is actually only used by
> TaskContext, and will probably never be used by any other class. So *why* have
> it as a separate class ? And there are number of such examples.
I agree. In the "4C" view, the DataFlowInterface belongs to the
Communication part of the whole system, and that indeed works only between
Computation parts (read, TaskContexts).

> All and all, I do agree on most of your points. What would be very nice is for
> us to make/have a roadmap. Because I'm not paid to rewrite Orocos from
> scratch, but to use it. Even though I'm trying to contribute (of course).

And we are _very_ grateful for what you are doing! :-)

Having a roadmap is the goal of this discussion... Since I think both of us
agree a lot already, we just have to wait for the others to say "Yes,
you're right!" :-)

Herman

»

RTT 2.0 Roadmap: my personal summary...

Submitted by Sylvain Joyeux on Mon, 2009-03-02 12:10.

On Monday 02 March 2009 12:22:12 Herman Bruyninckx wrote:
> On Mon, 2 Mar 2009, Sylvain Joyeux wrote:
> >> The first thing that is needed is a "refactoring" of some of the Orocos
> >> terminology (both for minimality and completeness):
> >> - reusing exactly matching concept descriptions from widely accepted
> >> international standards such as UML2, etc. Markus is taking care of
> >> that to some extent already.
> >
> > Okay ... I may have some harsh words in the following paragraph. I just
> > hope that nobody will take it personally.
> >
> > My experience is that mostly nobody knows UML. Everybody talks about it,
> > but use it "as they see fit" (i.e. take a graphical tool, makes nice
> > diagrams, but does not care about the actual meaning of what they're
> > doing). Here's the harsh part: the big reason why is that UML is hugely
> > bloated spec that no one in its right mind would dig in. The only persons
> > mad enough to do it are the one that actually develop the spec, or
> > research in model-driven engineering (I won't start a flamewar by saying
> > what I think about most of MDE-related research). And because they
> > actually tried to cover so much stuff, in as componentized as possible,
> > leading to a Java-standard-library kind of model. It makes things very
> > VERY complicated.
>
> But complex software systems _are_ complicated... What do you advocate
> instead? The endless creation of yet another project that is motivated by
> doing things in a simple way, but doesn't scale at all in the long run...?
No. A design which thinks about implementation instead of a design which
thinks about abstract specifications. That's what UML is for me: the gazillions
of concepts can be reduced tenfold just because *on the implementation side*
they are all coins of the same object.

> > Other example: the OMG robotics component model. This is horrible. Not
> > because it does not cover everything, but because *it does* and every
> > little piece has its own class. I don't like OMG standards for that. I
> > personally think that Orocos should try to merge as much concepts as
> > possible into one single implementation instead of trying to map stuff to
> > the gazillions of little pieces that are advocated by OMG standards.
>
> I am very much against that "monolithic" approach. Configuration complexity
> can be hidden (to some extent) behind tool support.
Nope, because then you end up with a non-manageable piece of code. This is not
about being monolithic, this is about "cutting the cake at the right place".
Some stuff are fine left monolithic. Other need specific

Again, specification is fine at an abstract level. Having to be driven by it at
the implementation side leads stuff that is completely unelegant.

> > The current component model of
> > Orocos is actually very simple, and would be even more simple if Peter's
> > propositions are implemented.
>
> Yes, but this component model needs to evolve towards more complex systems,
> sooner or later, involving all the "bloat" that goas with it.
> Your reaction is normal but typical for someone whose use case is limited
> to only one of the three system complexity classes that I keep on talking
> about; and since you are "single-system-minded", you think there is no need
> for other systems, and the corresponding software support :-)
Oh yes. I only did my PhD on multi-robot systems. What is funny is that, as
far as I understood, you do agree that the "asynchronous" case is to be left
to the coordination layer (i.e. leaving alone the rest), and therefore concur
to both Peter's and my point of view.

> It is! Coordination is (and should always be!) an "outside" activity.
> That's why I advocate looking at other frameworks such as OSGi etc. And why
> I want 2.0 to cut out all Coordination parts, while still keeping/making
> the remaining rest ready for external coordination :-)
Great then.

> > If you would ask me what should be the main development goal for RTT
> > right now, I would answer "reducing the class count". There is already
> > way too much classes that are lying around for no purpose other than
> > "having one class represent one thing".
>
> I fully agree and that's why I am making this effort of finding/describing
> the _least amount_ of different concepts that we really need.

Well. Let's take the "communication" part. My point about concepts vs.
implementation is the following: would you really need a
CommunicationInterface class or would you (as an implementer) just integrate
it transparently, sharing the implementation between the TaskContext, Port and
Message classes ? I would do the second. Just because it would probably make
the API easier to grasp (less entry points).

Sylvain

»

RTT 2.0 Roadmap: my personal summary...

Submitted by bruyninc on Mon, 2009-03-02 12:20.

On Mon, 2 Mar 2009, Sylvain Joyeux wrote:

> On Monday 02 March 2009 12:22:12 Herman Bruyninckx wrote:
>> On Mon, 2 Mar 2009, Sylvain Joyeux wrote:
>>>> The first thing that is needed is a "refactoring" of some of the Orocos
>>>> terminology (both for minimality and completeness):
>>>> - reusing exactly matching concept descriptions from widely accepted
>>>> international standards such as UML2, etc. Markus is taking care of
>>>> that to some extent already.
>>>
>>> Okay ... I may have some harsh words in the following paragraph. I just
>>> hope that nobody will take it personally.
>>>
>>> My experience is that mostly nobody knows UML. Everybody talks about it,
>>> but use it "as they see fit" (i.e. take a graphical tool, makes nice
>>> diagrams, but does not care about the actual meaning of what they're
>>> doing). Here's the harsh part: the big reason why is that UML is hugely
>>> bloated spec that no one in its right mind would dig in. The only persons
>>> mad enough to do it are the one that actually develop the spec, or
>>> research in model-driven engineering (I won't start a flamewar by saying
>>> what I think about most of MDE-related research). And because they
>>> actually tried to cover so much stuff, in as componentized as possible,
>>> leading to a Java-standard-library kind of model. It makes things very
>>> VERY complicated.
>>
>> But complex software systems _are_ complicated... What do you advocate
>> instead? The endless creation of yet another project that is motivated by
>> doing things in a simple way, but doesn't scale at all in the long run...?
> No. A design which thinks about implementation instead of a design which
> thinks about abstract specifications. That's what UML is for me: the gazillions
> of concepts can be reduced tenfold just because *on the implementation side*
> they are all coins of the same object.
>
>>> Other example: the OMG robotics component model. This is horrible. Not
>>> because it does not cover everything, but because *it does* and every
>>> little piece has its own class. I don't like OMG standards for that. I
>>> personally think that Orocos should try to merge as much concepts as
>>> possible into one single implementation instead of trying to map stuff to
>>> the gazillions of little pieces that are advocated by OMG standards.

In principle, I feel exactly the same. The difference between us, maybe, is
that I accept UML2 as a standard that has (too?) deeply penetrated
education and tooling in order to neglect. But I would never advocate
trying to use everything that is in UML, on the contrary: the
identification of the smallest amount of relevant material from the
standard is a Good Thing for Orocos... Both concept-wise and
implementation-wise.

>> I am very much against that "monolithic" approach. Configuration complexity
>> can be hidden (to some extent) behind tool support.
> Nope, because then you end up with a non-manageable piece of code. This is not
> about being monolithic, this is about "cutting the cake at the right place".
> Some stuff are fine left monolithic. Other need specific

What you call "cutting the cake at the right place" is what I call
"appropriate decoupling" (I think). So, we agree here. But even
well-decoupled designs will need more and more tool support, since designs
of modern and future systems will be too complex to fit in the mind of one
single person. And, in addition and maybe more importantly, system designs
will be done in a distributed way, much like open source works already
since a long time.

> Again, specification is fine at an abstract level. Having to be driven by
> it at the implementation side leads stuff that is completely unelegant.
I turn this reasoning upside down: abstract specifications should take
implementation into account as much as possible, and those that can marry
conceptual clarity with implementation simplicity (and, hence(?), quality)
will be successful. I hope our combined efforts can bring Orocos into this
latter category :-)

>>> The current component model of
>>> Orocos is actually very simple, and would be even more simple if Peter's
>>> propositions are implemented.
>>
>> Yes, but this component model needs to evolve towards more complex systems,
>> sooner or later, involving all the "bloat" that goas with it.
>> Your reaction is normal but typical for someone whose use case is limited
>> to only one of the three system complexity classes that I keep on talking
>> about; and since you are "single-system-minded", you think there is no need
>> for other systems, and the corresponding software support :-)
> Oh yes. I only did my PhD on multi-robot systems. What is funny is that, as
> far as I understood, you do agree that the "asynchronous" case is to be left
> to the coordination layer (i.e. leaving alone the rest), and therefore concur
> to both Peter's and my point of view.
It does!
(At least, that's my "abstract conceptual" view on these things :-))

>> It is! Coordination is (and should always be!) an "outside" activity.
>> That's why I advocate looking at other frameworks such as OSGi etc. And why
>> I want 2.0 to cut out all Coordination parts, while still keeping/making
>> the remaining rest ready for external coordination :-)
> Great then.
>
>>> If you would ask me what should be the main development goal for RTT
>>> right now, I would answer "reducing the class count". There is already
>>> way too much classes that are lying around for no purpose other than
>>> "having one class represent one thing".
>>
>> I fully agree and that's why I am making this effort of finding/describing
>> the _least amount_ of different concepts that we really need.
>
> Well. Let's take the "communication" part. My point about concepts vs.
> implementation is the following: would you really need a
> CommunicationInterface class or would you (as an implementer) just integrate
> it transparently, sharing the implementation between the TaskContext, Port and
> Message classes ? I would do the second. Just because it would probably make
> the API easier to grasp (less entry points).
I fully agree that Communication is the first thing to tackle. For several
reasons: it's a bit overcomplex at this moment; it's fundamental to all the
rest (Computation, Configuration and Coordination); it is independent of
all that other "rest"; Orocos has already a good new design (in the form of
Peter's asynchronous message passing infrastructure); it's the most mature
part from a computer science point of view.

Herman

»

RTT 2.0 Roadmap: my personal summary...

Submitted by Markus Klotzbücher (not verified) on Fri, 2009-02-27 19:45.

I agree mostly, some minor remarks below.

On Fri, Feb 27, 2009 at 03:22:54PM +0100, Herman Bruyninckx wrote:
> Dear colleagues,
>
> here is my personal summary of the last weeks of 2.0 roadmap discussions. I
> have not particular motivation to post this but the fact that such a
> summary will be needed sooner or later anyway :-)
>
> I acknowledge all of you who have provided feedback or remarks at some time
> during the long discussion threads, but also some people who I discussed
> with offline. In particular Klas Nilsson, from Lund Technical University,
> who is very knowledgable in realtime robot control since he designed the
> new (realtime Java + Xenomai based!) controller for the ABB robots, _and_
> who introduced me to the "4C" concerns paper by Radestock and Eisenbach
> (1996). Besides Klas, I have now also better understood the value (and
> limitations) of the "codel" principle of Genom developed by LAAS
> <https://softs.laas.fr/openrobots/wiki/genom>.
>
> I present a very "bird's eye view" on RTT, and I am motivated by the
> scientific drive to find a _minimal_ amount of fundamentally different,
> "orthogonal" concepts with which to provide a _complete_ description of all
> we want to do within the RTT scope.
>
> So, here I go...
>
> The first thing that is needed is a "refactoring" of some of the Orocos
> terminology (both for minimality and completeness):
> - reusing exactly matching concept descriptions from widely accepted
> international standards such as UML2, etc. Markus is taking care of that
> to some extent already.
> - reformulating RTT's goals and programming primitives in the "4C" context
> (see below for more details).
> - giving the single-thread "Activity" the central place in the TaskContext,
> with PeriodicActivity as a special case. NonPeriodicActivity should
> disappear.

And I would suggest that the term "thread" should go with it, unless
we are explicitly referring the low level OS primitve. From the view
of an OROCOS "user" it shouldn't matter how it is implemented.

> Secondly, using an asynchronous message passing (AMP) infrastructure as the
> basis for all inter-activity communication and event passing would lead to
> a smaller, better defined and hence more comprehensible and maintainable
> code. AMP is a generic (i.e., minimal and complete) _mechanism_ with which
> many (all?) of the IPC _policies_ can be implemented. Without loss of
> online efficiency and performance _if_ the most appropriate implementation
> (= serialization of the calculations involved in all 4Cs) can be generated
> automatically. (See the following paragraph for a presentation of the three
> different "use cases".)

I'm all for it! Simplification by building higher level abstractions
from lower level primitives is the key. And given that *where* a
message is sent is taken care by Coordination, there will be no way to
hard-code communication partners, thereby taking care of your concern
you expressed recently.

> Thirdly, a three-layered structure in RTT according to component complexity
> would also bring improved comprehensibility (and better opportunities for
> code generation and other model-driven engineering tools). Over the last
> couple of years, I have found the following three "use cases" or "orders of
> system complexity" to be _minimal_ and _complete_:
> - Class 1: "Centralized hardware, centralized state".
> - Class 2: "Decentralized hardware, centralized state".
> - Class 3: "decentralized hardware, decentralized state".
> (Class 4, centralized hardware, decentralized state, does not occur in
> robotics, but does occur in, e.g., server virtualization.)

The three use cases make perfect sense to me, though I can't really
imagine how they would materialize themselves in the RTT?

[...]

> Finally, the relationship between single-Activity Coordination and Finite
> State Machines in RTT's TaskContext. In the discussions about this topic,
> we were looking about the best way to implement FSM with the available RTT
> primitives and code. However, I now think we should _reverse_ the view on
> this problem, and make sure that all single-activity TaskContexts show
> themselves to the outside world as behaviour that can be _modelled_ by the
> concept of a perfect, mathematically formalizable State Machine. The core
> concept there is that everything that takes place in such a TaskContext
> should happen in "atomic", uninterruptable "codels" (= pieces of
> computations). The atomicity is _not_ to be guaranteed wrt to other
> activities (within RTT or not) but it is limited to all "internal" aspects
> of Coordination between Communication (= the handling of events, and the
> reading or writing to DataPorts), Computation (= the application
> functionality running in the Activity), and Configuration. In other words,
> we are back to where Peter and myself started 7 years ago: configurable
> serialization of the 4Cs within one single-activity TaskContext! (That is,
> "Class 1" system complexity.) Where we made a (conceptual) mistake is to
> not limit ourselves to Class 1, but to (implicitly!) assume that we were
> also solving "Class 2/3" system complexity, but that is not true:
> "codel"-like atomicity cannot be guaranteed in multi-Activity
> (decentralized state) or decentralized hardware cases...

One thing which I believe would be important and I guess is covered by
this FSM concept is unifying UML-style events (=occurences of
something). So an incoming "message" can have different semantics,
e.g. mean "invoke operationX" or "500us timer expired". This seems
trivial but it essentially unifies singleActivity and
PeriodicActivity. The only difference is the type of events they react
to.

Best regards
Markus

»

RTT 2.0 Roadmap: my personal summary...

Submitted by bruyninc on Sun, 2009-03-01 15:35.

On Fri, 27 Feb 2009, Markus Klotzbücher wrote:

>
> I agree mostly, some minor remarks below.
>
> On Fri, Feb 27, 2009 at 03:22:54PM +0100, Herman Bruyninckx wrote:
>> Dear colleagues,
>>
>> here is my personal summary of the last weeks of 2.0 roadmap discussions. I
>> have not particular motivation to post this but the fact that such a
>> summary will be needed sooner or later anyway :-)
>>
>> I acknowledge all of you who have provided feedback or remarks at some time
>> during the long discussion threads, but also some people who I discussed
>> with offline. In particular Klas Nilsson, from Lund Technical University,
>> who is very knowledgable in realtime robot control since he designed the
>> new (realtime Java + Xenomai based!) controller for the ABB robots, _and_
>> who introduced me to the "4C" concerns paper by Radestock and Eisenbach
>> (1996). Besides Klas, I have now also better understood the value (and
>> limitations) of the "codel" principle of Genom developed by LAAS
>> <https://softs.laas.fr/openrobots/wiki/genom>.
>>
>> I present a very "bird's eye view" on RTT, and I am motivated by the
>> scientific drive to find a _minimal_ amount of fundamentally different,
>> "orthogonal" concepts with which to provide a _complete_ description of all
>> we want to do within the RTT scope.
>>
>> So, here I go...
>>
>> The first thing that is needed is a "refactoring" of some of the Orocos
>> terminology (both for minimality and completeness):
>> - reusing exactly matching concept descriptions from widely accepted
>> international standards such as UML2, etc. Markus is taking care of that
>> to some extent already.
>> - reformulating RTT's goals and programming primitives in the "4C" context
>> (see below for more details).
>> - giving the single-thread "Activity" the central place in the TaskContext,
>> with PeriodicActivity as a special case. NonPeriodicActivity should
>> disappear.
>
> And I would suggest that the term "thread" should go with it, unless
> we are explicitly referring the low level OS primitve. From the view
> of an OROCOS "user" it shouldn't matter how it is implemented.

Indeed... It would be ideal if the specific implementation could be _fully_
hidden behind a configuration.

>> Secondly, using an asynchronous message passing (AMP) infrastructure as the
>> basis for all inter-activity communication and event passing would lead to
>> a smaller, better defined and hence more comprehensible and maintainable
>> code. AMP is a generic (i.e., minimal and complete) _mechanism_ with which
>> many (all?) of the IPC _policies_ can be implemented. Without loss of
>> online efficiency and performance _if_ the most appropriate implementation
>> (= serialization of the calculations involved in all 4Cs) can be generated
>> automatically. (See the following paragraph for a presentation of the three
>> different "use cases".)
>
> I'm all for it! Simplification by building higher level abstractions
> from lower level primitives is the key. And given that *where* a
> message is sent is taken care by Coordination, there will be no way to
> hard-code communication partners, thereby taking care of your concern
> you expressed recently.
>
>> Thirdly, a three-layered structure in RTT according to component complexity
>> would also bring improved comprehensibility (and better opportunities for
>> code generation and other model-driven engineering tools). Over the last
>> couple of years, I have found the following three "use cases" or "orders of
>> system complexity" to be _minimal_ and _complete_:
>> - Class 1: "Centralized hardware, centralized state".
>> - Class 2: "Decentralized hardware, centralized state".
>> - Class 3: "decentralized hardware, decentralized state".
>> (Class 4, centralized hardware, decentralized state, does not occur in
>> robotics, but does occur in, e.g., server virtualization.)
>
> The three use cases make perfect sense to me, though I can't really
> imagine how they would materialize themselves in the RTT?

They would each involve a different "best practice" implementation of
TaskContexts. For example. Class 1 _could_ be implemented in the "deeply
embedded" way, without any overhead of DataPorts, and with only the ISR to
deal with asynchronicity (in hardware IO). Class 2 can be implemented with
only a finite state machine as Coordination.
Basically, I see the "details" of all this as a major part of your PhD
thesis! :-)

> [...]
>> Finally, the relationship between single-Activity Coordination and Finite
>> State Machines in RTT's TaskContext. In the discussions about this topic,
>> we were looking about the best way to implement FSM with the available RTT
>> primitives and code. However, I now think we should _reverse_ the view on
>> this problem, and make sure that all single-activity TaskContexts show
>> themselves to the outside world as behaviour that can be _modelled_ by the
>> concept of a perfect, mathematically formalizable State Machine. The core
>> concept there is that everything that takes place in such a TaskContext
>> should happen in "atomic", uninterruptable "codels" (= pieces of
>> computations). The atomicity is _not_ to be guaranteed wrt to other
>> activities (within RTT or not) but it is limited to all "internal" aspects
>> of Coordination between Communication (= the handling of events, and the
>> reading or writing to DataPorts), Computation (= the application
>> functionality running in the Activity), and Configuration. In other words,
>> we are back to where Peter and myself started 7 years ago: configurable
>> serialization of the 4Cs within one single-activity TaskContext! (That is,
>> "Class 1" system complexity.) Where we made a (conceptual) mistake is to
>> not limit ourselves to Class 1, but to (implicitly!) assume that we were
>> also solving "Class 2/3" system complexity, but that is not true:
>> "codel"-like atomicity cannot be guaranteed in multi-Activity
>> (decentralized state) or decentralized hardware cases...
>
> One thing which I believe would be important and I guess is covered by
> this FSM concept is unifying UML-style events (=occurences of
> something). So an incoming "message" can have different semantics,
> e.g. mean "invoke operationX" or "500us timer expired". This seems
> trivial but it essentially unifies singleActivity and
> PeriodicActivity. The only difference is the type of events they react
> to.

I think and hope you are right :-)

Herman

> Best regards
> Markus
>

--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 322480
Coordinator of EURON (European Robotics Research Network)
<http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

»

RTT 2.0 Roadmap: my personal summary...

Submitted by Sylvain Joyeux on Mon, 2009-03-02 10:55.

---------- Forwarded Message ----------

Subject: Re: [Orocos-Dev] RTT 2.0 Roadmap: my personal summary...
Date: Monday 02 March 2009
From: Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
To: Herman Bruyninckx <herman [dot] bruyninckx [..] ...>

> They would each involve a different "best practice" implementation of
> TaskContexts. For example. Class 1 _could_ be implemented in the "deeply
> embedded" way, without any overhead of DataPorts
what do you mean by "overhead of DataPorts" ? Is data ports the overhead in
this sentence ?

> and with only the ISR to
> deal with asynchronicity (in hardware IO). Class 2 can be implemented with
> only a finite state machine as Coordination.
> Basically, I see the "details" of all this as a major part of your PhD
> thesis! :-)

Sylvain

-------------------------------------------------------

---------- Forwarded Message ----------

Subject: Re: [Orocos-Dev] RTT 2.0 Roadmap: my personal summary...
Date: Monday 02 March 2009
From: Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
To: Sylvain Joyeux <sylvain [dot] joyeux [..] ...>

On Mon, 2 Mar 2009, Sylvain Joyeux wrote:

>> They would each involve a different "best practice" implementation of
>> TaskContexts. For example. Class 1 _could_ be implemented in the "deeply
>> embedded" way, without any overhead of DataPorts
> what do you mean by "overhead of DataPorts" ? Is data ports the overhead in
> this sentence ?

If you have two activities (TaskContexts) in two different 'threads' of
your application and you want them to share data, orocos provides DataPorts
for safe and deterministic exchange of data. However, there is an overhead
involved in supporting this safety and determinism (buffering, locking,
waiting,...) which can be totally eliminated when you have the two
activities running only in one single thread: you can _impose_ a
serialization which makes locking etc unnecessary because plain simple
shared data will work.

Herman

PS Any reason why not to send this part of the thread on the
mailinglist...?

-------------------------------------------------------

»

RTT 2.0 Roadmap: my personal summary...

Submitted by Sylvain Joyeux on Mon, 2009-03-02 11:00.

> > what do you mean by "overhead of DataPorts" ? Is data ports the overhead
> > in this sentence ?
>
> If you have two activities (TaskContexts) in two different 'threads' of
> your application and you want them to share data, orocos provides DataPorts
> for safe and deterministic exchange of data. However, there is an overhead
> involved in supporting this safety and determinism (buffering, locking,
> waiting,...) which can be totally eliminated when you have the two
> activities running only in one single thread: you can _impose_ a
> serialization which makes locking etc unnecessary because plain simple
> shared data will work.

Okay, but then the problem does not lie with the ports, but with the data
connection (i.e. the thing that moves data from one port to the other). The
new data ports I'm designing could allow for optimization on the "serialized"
case for instance.

In my mind, a goal should be that all primitives that describe components
(nowadays data flow ports, commands, methods and events) should be available on
all architectures that Orocos is supposed to be usable on. Of course, some
"policies" -- as you like to call them -- would be unavailable.

Sylvain

»

RTT 2.0 Roadmap: my personal summary...

Submitted by bruyninc on Mon, 2009-03-02 11:10.

On Mon, 2 Mar 2009, Sylvain Joyeux wrote:

>>> what do you mean by "overhead of DataPorts" ? Is data ports the overhead
>>> in this sentence ?
>>
>> If you have two activities (TaskContexts) in two different 'threads' of
>> your application and you want them to share data, orocos provides DataPorts
>> for safe and deterministic exchange of data. However, there is an overhead
>> involved in supporting this safety and determinism (buffering, locking,
>> waiting,...) which can be totally eliminated when you have the two
>> activities running only in one single thread: you can _impose_ a
>> serialization which makes locking etc unnecessary because plain simple
>> shared data will work.
>
> Okay, but then the problem does not lie with the ports, but with the data
> connection (i.e. the thing that moves data from one port to the other).

That could indeed be true. Hopefully. :-) (I see currently no reason to
think it is not true.)

> The
> new data ports I'm designing could allow for optimization on the "serialized"
> case for instance.

Great :-)

> In my mind, a goal should be that all primitives that describe components
> (nowadays data flow ports, commands, methods and events) should be available on
> all architectures that Orocos is supposed to be usable on. Of course, some
> "policies" -- as you like to call them -- would be unavailable.

My feeling and believe are that there are really at least three classes of
system complexities (see one of my previous emails) and providing them in
separate (but interoperable!) parts of the framework makes things easier
for those who only need support for the simpler systems...

Herman

>
> Sylvain
>

»

RTT 2.0 Roadmap: my personal summary...

Submitted by Vandenbroucke Sander on Fri, 2009-02-27 15:25.

> - giving the single-thread "Activity" the central place in the
> TaskContext,
> with PeriodicActivity as a special case. NonPeriodicActivity should
> disappear.
>
What exactly do you mean with this? We find the NonPeriodicActivity very
use full in some cases.

Sander.

»

RTT 2.0 Roadmap: my personal summary...

Submitted by Sylvain Joyeux on Mon, 2009-03-02 11:05.

> The naming problem is the following: saying something is _not_ something
> else gives a lot of semantic consistency problems (and hence it obscures
> clear interpretation, as we have experienced time and again on the Orocos
> mailinglist...). In other words, there will be dozens of different possible
> non-periodic activities, so putting them all under the same category
> creates confusion.
I do see your point here ... It is just that I never had a problem with it as
for me a class (as in programming element) is a class (as in concepts): all
non-periodic activities are subclasses of NonPeriodicActivity. Which is
actually the case so no problem (for me).

I don't remember anybody having problems with NonPeriodicActivity In the time
I has been on the ML, so ...

Sylvain

»

RTT 2.0 Roadmap: my personal summary...

Submitted by bruyninc on Mon, 2009-03-02 11:10.

On Mon, 2 Mar 2009, Sylvain Joyeux wrote:

>> The naming problem is the following: saying something is _not_ something
>> else gives a lot of semantic consistency problems (and hence it obscures
>> clear interpretation, as we have experienced time and again on the Orocos
>> mailinglist...). In other words, there will be dozens of different possible
>> non-periodic activities, so putting them all under the same category
>> creates confusion.
> I do see your point here ... It is just that I never had a problem with it as
> for me a class (as in programming element) is a class (as in concepts): all
> non-periodic activities are subclasses of NonPeriodicActivity. Which is
> actually the case so no problem (for me).

The separation between the PeriodicActivity class and the
NonPeriodicActivity is not a good one! Too unbalanced...

> I don't remember anybody having problems with NonPeriodicActivity In the time
> I has been on the ML, so ...

...so your memory is selective :-)

Herman
>
> Sylvain

»

RTT 2.0 Roadmap: my personal summary...

Submitted by bruyninc on Fri, 2009-02-27 16:25.

On Fri, 27 Feb 2009, Vandenbroucke Sander wrote:

>> - giving the single-thread "Activity" the central place in the
>> TaskContext,
>> with PeriodicActivity as a special case. NonPeriodicActivity should
>> disappear.
>>
> What exactly do you mean with this? We find the NonPeriodicActivity very
> use full in some cases.
>
The _name_ should disappear, but the _concept_ should be the default! It
_is_ useful, and in more than just _some_ cases :-)

Hermabn

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

»

RTT 2.0 Roadmap: my personal summary...

Submitted by Sylvain Joyeux on Mon, 2009-03-02 11:25.

---------- Forwarded Message ----------

Subject: Re: [Orocos-Dev] RTT 2.0 Roadmap: my personal summary...
Date: Monday 02 March 2009
From: Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
To: Herman Bruyninckx <herman [dot] bruyninckx [..] ...>

On Friday 27 February 2009 17:22:44 Herman Bruyninckx wrote:
> On Fri, 27 Feb 2009, Vandenbroucke Sander wrote:
> >> - giving the single-thread "Activity" the central place in the
> >> TaskContext,
> >> with PeriodicActivity as a special case. NonPeriodicActivity should
> >> disappear.
> >
> > What exactly do you mean with this? We find the NonPeriodicActivity very
> > use full in some cases.
>
> The _name_ should disappear, but the _concept_ should be the default! It
> _is_ useful, and in more than just _some_ cases :-)
Agreed. Now, I don't see why the name should go away. We have currently three
basic types of activities (names are from me):
* the "NoThread" activity that has recently been added by Peter, and
serializes operations between different task contexts (i.e. the callee runs in
the thread of the caller).
* the "NonPeriodic" activity which is a "call step() on me" activity
* the "Periodic" activity.

For me, all three have a clear meaning and should remain (names included ;-)).

In other words: I don't see your problem with NonPeriodicActivity

Sylvain
-------------------------------------------------------

---------- Forwarded Message ----------

Subject: Re: [Orocos-Dev] RTT 2.0 Roadmap: my personal summary...
Date: Monday 02 March 2009
From: Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
To: Sylvain Joyeux <sylvain [dot] joyeux [..] ...>

On Mon, 2 Mar 2009, Sylvain Joyeux wrote:

> On Friday 27 February 2009 17:22:44 Herman Bruyninckx wrote:
>> On Fri, 27 Feb 2009, Vandenbroucke Sander wrote:
>>>> - giving the single-thread "Activity" the central place in the
>>>> TaskContext,
>>>> with PeriodicActivity as a special case. NonPeriodicActivity should
>>>> disappear.
>>>
>>> What exactly do you mean with this? We find the NonPeriodicActivity very
>>> use full in some cases.
>>
>> The _name_ should disappear, but the _concept_ should be the default! It
>> _is_ useful, and in more than just _some_ cases :-)
> Agreed. Now, I don't see why the name should go away. We have currently
three
> basic types of activities (names are from me):
> * the "NoThread" activity that has recently been added by Peter, and
> serializes operations between different task contexts (i.e. the callee runs
in
> the thread of the caller).
> * the "NonPeriodic" activity which is a "call step() on me" activity
> * the "Periodic" activity.
>
> For me, all three have a clear meaning and should remain (names included
;-)).
>
> In other words: I don't see your problem with NonPeriodicActivity

Strange... you must have been working for too long with Orocos! :-)

The naming problem is the following: saying something is _not_ something
else gives a lot of semantic consistency problems (and hence it obscures
clear interpretation, as we have experienced time and again on the Orocos
mailinglist...). In other words, there will be dozens of different possible
non-periodic activities, so putting them all under the same category
creates confusion.

Herman

-------------------------------------------------------

»