Important notice for existing Real-Time Toolkit users

Submitted by sspr on Thu, 2009-04-09 09:20

Orocos-users

This summer, the Real-Time Toolkit will undergo its upgrade to reach version
2.0. This means some functions or classes will change. It is our intention to
make the transition for existing RTT-1.0 users as painless as
possible. In order to do so, the following objectives are set forth:

* To aim for simplification: pure out semantics of the functions and objects
* To not add complexity and to get a uniform 'look and feel'.
* To rename functions or classes if their semantics change
* To provide scripts that do necessary renames of changed functions, classes,
includes etc. in user code
* To provide detailed transition notes to guide you in all this

The discussions about the topics of change were already started on the orocos-
dev mailing list. See this page: http://www.orocos.org/wiki/rtt/rtt-2.0 for
the summary of that discussion. Though nothing is carved in stone yet.

The proposed major work packages are:
* Data Ports simplification: Sylvain Joyeux proposed a new data port model
which improves component reusability, interoperability with other frameworks
and is more logical.
* Method/Event/Command simplification: Peter Soetens proposed to offer a simpler
'Message' primitive instead of Command and unify Method and Message with the
Event interface and on the CORBA interface. This simplifies the Orocos
client/server aka request/reply model for component communication.
* Application examples: Using the improved interface, write 3 or 4 typical
getting started applications, which new users can use to start from.
* RTT source and namespace reordering: Headers and classes not meant for users
will be moved in sub-directories and nested namespaces.
* UML 2.0 state machine script integration using Lua: Markus Klotzbucher
proposes a way to define UML 2.0 state machines in Orocos, which are described
in the Lua language
(see the link above for more details)

We'd like to get answers from users on these 5 questions:
1. Which of these packages are important or not important to you ?
2. Which of these changes would/could impact you a lot ?
3. Which is missing, what had you hoped that RTT 2.0 would solve/improve ?
4. Would you consider switching to RTT 2.0 or stay at RTT 1.x ?
5. Which tooling do you miss most when working with the RTT (give an example
of existing tools in other frameworks if possible)

Now is your chance to answer and influence this change for the better.

To state things clear: RTT 2.0 is *not* a major overhaul. A major part of the
API and the concepts will remain the same.

Please reply to orocos-dev, orocos-users or on the website forum where this
post is also available. No discussion will take place on the 'orocos' announce
list. I'll be on holidays for a week, so feel free to fire along, I won't argue
with you :-)

Peter

Important notice for existing Real-Time Toolkit users

Submitted by snrkiwi on Wed, 2009-04-22 13:40.

On Apr 9, 2009, at 05:18 , Peter Soetens wrote:

> The proposed major work packages are:
> * Data Ports simplification: Sylvain Joyeux proposed a new data port
> model
> which improves component reusability, interoperability with other
> frameworks
> and is more logical.
> * Method/Event/Command simplification: Peter Soetens proposed to
> offer a simpler
> 'Message' primitive instead of Command and unify Method and Message
> with the
> Event interface and on the CORBA interface. This simplifies the Orocos
> client/server aka request/reply model for component communication.
> * Application examples: Using the improved interface, write 3 or 4
> typical
> getting started applications, which new users can use to start from.
> * RTT source and namespace reordering: Headers and classes not meant
> for users
> will be moved in sub-directories and nested namespaces.
> * UML 2.0 state machine script integration using Lua: Markus
> Klotzbucher
> proposes a way to define UML 2.0 state machines in Orocos, which are
> described
> in the Lua language
> (see the link above for more details)
>
> We'd like to get answers from users on these 5 questions:
> 1. Which of these packages are important or not important to you ?

App examples and UML 2.0 support

> 2. Which of these changes would/could impact you a lot ?

All

> 3. Which is missing, what had you hoped that RTT 2.0 would solve/
> improve ?

Simplification of CMake build system.

> 4. Would you consider switching to RTT 2.0 or stay at RTT 1.x ?

Switch, though the level of complaining/questions the ML will get are
directly proportional to the amount of change from 1.x to 2.0

> 5. Which tooling do you miss most when working with the RTT (give an
> example
> of existing tools in other frameworks if possible)

> Now is your chance to answer and influence this change for the better.
>
> To state things clear: RTT 2.0 is *not* a major overhaul. A major
> part of the
> API and the concepts will remain the same.

Good! :-)
S

Important notice for existing Real-Time Toolkit users

Submitted by sspr on Wed, 2009-04-22 17:00.

On Wednesday 22 April 2009 14:24:33 S Roderick wrote:
> > 1. Which of these packages are important or not important to you ?
>
> App examples and UML 2.0 support
>
> > 2. Which of these changes would/could impact you a lot ?
>
> All
>
> > 3. Which is missing, what had you hoped that RTT 2.0 would solve/
> > improve ?
>
> Simplification of CMake build system.
>
> > 4. Would you consider switching to RTT 2.0 or stay at RTT 1.x ?
>
> Switch, though the level of complaining/questions the ML will get are
> directly proportional to the amount of change from 1.x to 2.0
>
> > 5. Which tooling do you miss most when working with the RTT (give an
> > example
> > of existing tools in other frameworks if possible)
> >
> > Now is your chance to answer and influence this change for the better.
> >
> > To state things clear: RTT 2.0 is *not* a major overhaul. A major
> > part of the
> > API and the concepts will remain the same.
>
> Good! :-)
> S

Thanks for your feed back.

Peter

Important notice for existing Real-Time Toolkit users

Submitted by Vandenbroucke Sander on Mon, 2009-04-20 07:25.

>
> We'd like to get answers from users on these 5 questions:
> 1. Which of these packages are important or not important to you ?
All.

> 2. Which of these changes would/could impact you a lot ?
All.

> 3. Which is missing, what had you hoped that RTT 2.0 would
solve/improve ?
I have a few points to add:
a: clear separation between service and implementation, as discussed
before (see strategy design pattern). The implementation is either hard
coded or determined by a configuration, deployment or whatever you like
to call it manager.
For example an AtomicQueue is currently verry memory-hungry (both code
and data). Using an other algorithm for this is not trivial. This is
currently blocking me from upgrading OROCOS.

b: We have a protocol over CAN and Ethernet to communicate with our
objects (TaskContext's). For both protocols quite a bit of code is
written to make it work. Our CAN protocol is partially based on DLib. So
it would be nice to have a DLib supporting the full TaskContext
interface. The objective should be: reuse protocol independent code.

c: We have created a "TimedEvent" because it was lacking. Basically when
it is fired execution is delayed for a defined amount of time and is not
repetitive. This service will be appreciated.

> 4. Would you consider switching to RTT 2.0 or stay at RTT 1.x ?
Not before issues a, b and c.

> 5. Which tooling do you miss most when working with the RTT (give an
> example
> of existing tools in other frameworks if possible)
None.

Kind regards.
Sander.

Important notice for existing Real-Time Toolkit users

Submitted by sspr on Tue, 2009-04-21 07:25.

On Monday 20 April 2009 09:14:01 Vandenbroucke Sander wrote:
> > 3. Which is missing, what had you hoped that RTT 2.0 would
>
> solve/improve ?
> I have a few points to add:
> a: clear separation between service and implementation, as discussed
> before (see strategy design pattern). The implementation is either hard
> coded or determined by a configuration, deployment or whatever you like
> to call it manager.
> For example an AtomicQueue is currently verry memory-hungry (both code
> and data). Using an other algorithm for this is not trivial. This is
> currently blocking me from upgrading OROCOS.

Could you suggest an interface/coding construct to easily change the queing
algorithm ? Are you thinking about #ifdefs or plain o->setQueue( new MyQueue )
?

>
> b: We have a protocol over CAN and Ethernet to communicate with our
> objects (TaskContext's). For both protocols quite a bit of code is
> written to make it work. Our CAN protocol is partially based on DLib. So
> it would be nice to have a DLib supporting the full TaskContext
> interface. The objective should be: reuse protocol independent code.

What is majorly lacking in dlib is event support. It could be/is likely that
the 2.0 changes will facilitate events over dlib as well, if you can live with
the fact that events will only be fired from your local component, but that
remote ones will be able to subscribe to it (using a proxy).

>
> c: We have created a "TimedEvent" because it was lacking. Basically when
> it is fired execution is delayed for a defined amount of time and is not
> repetitive. This service will be appreciated.

Is this something you can share ? (even just the interface/use case would be
great)

Peter

Important notice for existing Real-Time Toolkit users

Submitted by Vandenbroucke Sander on Tue, 2009-04-21 09:55.

> > I have a few points to add:
> > a: clear separation between service and implementation, as discussed
> > before (see strategy design pattern). The implementation is either
hard
> > coded or determined by a configuration, deployment or whatever you
like
> > to call it manager.
> > For example an AtomicQueue is currently verry memory-hungry (both
code
> > and data). Using an other algorithm for this is not trivial. This is
> > currently blocking me from upgrading OROCOS.
>
> Could you suggest an interface/coding construct to easily change the
> queing
> algorithm ? Are you thinking about #ifdefs or plain o->setQueue( new
> MyQueue )
> ?
>
With ifdeffing you cover the worst case in any case, witch is not always
desired. Especially not where a small footprint is desired.

I prefer the o->setQueue(...) approach. I allows you to use different
algorithms in one application. So you can chose the most appropriate.
For example communication between components in the same thread doesn't
need locking in the other case a thread-safe algorithm can be used. A
job for a "Configuration/Deployment component/srcipt". If you are
working on a driver you might want to use a user defined queue
implementation.

I attached an UML class diagram for illustration.

This could be used for any communication object.

> >
> > b: We have a protocol over CAN and Ethernet to communicate with our
> > objects (TaskContext's). For both protocols quite a bit of code is
> > written to make it work. Our CAN protocol is partially based on
DLib. So
> > it would be nice to have a DLib supporting the full TaskContext
> > interface. The objective should be: reuse protocol independent code.
>
> What is majorly lacking in dlib is event support. It could be/is
likely
> that
> the 2.0 changes will facilitate events over dlib as well, if you can
live
> with
> the fact that events will only be fired from your local component, but
> that
> remote ones will be able to subscribe to it (using a proxy).
>
Ok.

> >
> > c: We have created a "TimedEvent" because it was lacking. Basically
when
> > it is fired execution is delayed for a defined amount of time and is
not
> > repetitive. This service will be appreciated.
>
> Is this something you can share ? (even just the interface/use case
would
> be
> great)
>
I'll try to sketch a UML diagram for this as well.

Sander.

Important notice for existing Real-Time Toolkit users

Submitted by Klaas Gadeyne on Fri, 2009-04-17 14:45.

On Thu, Apr 9, 2009 at 11:18 AM, Peter Soetens <peter [dot] soetens [..] ...> wrote:
[...]

Let me identify the bullet points first:

> The proposed major work packages are:

a] Data Ports simplification: Sylvain Joyeux proposed a new data port model
> which improves component reusability, interoperability with other frameworks
> and is more logical.

b] Method/Event/Command simplification: Peter Soetens proposed to
offer a simpler
> 'Message' primitive instead of Command and unify Method and Message with the
> Event interface and on the CORBA interface. This simplifies the Orocos
> client/server aka request/reply model for component communication.

c] Application examples: Using the improved interface, write 3 or 4 typical
> getting started applications, which new users can use to start from.

d] RTT source and namespace reordering: Headers and classes not meant for users
> will be moved in sub-directories and nested namespaces.

e] UML 2.0 state machine script integration using Lua: Markus Klotzbucher
> proposes a way to define UML 2.0 state machines in Orocos, which are described
> in the Lua language
> (see the link above for more details)

> We'd like to get answers from users on these 5 questions:
> 1. Which of these packages are important or not important to you ?

All of them are important to us.

> 2. Which of these changes would/could impact you a lot ?

Same answer.

> 3. Which is missing, what had you hoped that RTT 2.0 would solve/improve ?

I remember some people (justifiably) complaining about the imprecise
semantics of UML. Unfortunately, it seems to me (and a lot of 'ok I
misunderstood this' messages on this list seem to prove that) that the
semantics of email discussions are even worse of those of UML.
Therefore, I am currently unsure wether RTT 2.0 will bring what I
expect from it.

Some examples from the top of my head (certainly not exhaustive) to
which I can't recall having seen them answered in the RTT 2.0
discussions on the ML:

[1/ It's been a while since I've had hands on orocos experience, so
forgive any unforgivable error/mistakes/assumptions from my part
below]
[2/ Please also forgive any semantically unclear statements below :)]

- What will RTT 2.0 do with respect to the loose coupling between
taskContexts and activities? Will it still be possible to create a
TaskContext whose well-functioning wholy depends on the fact that it
is run in a NonPeriodicActivity and then connect that TaskContext to a
periodicActivity via the deployers xml file?
- How about the interaction between activity b] and e]? E.g.
currently there's is no straighforward way of using UML::callEvents in
orocos FSM. In UML, a UML::operation (in the interface of an object)
can either result in a callEvent for the "Classifier FSM behaviour" of
that object or be implemented as a UML::method. In RTT 1.x, using a
RTT:Method the latter behaviour is realized easily, but the former is
very cumbersome.
- Similar question about time events. How will I have to use a
UML::TimeEvent in a FSM in RTT 2.0 ? Will there still be a
TimerComponent which I have to set up, or will it be more like
AUTOSAR, which considers the TimeService as a part of the
infrastructure?
- Will the refactored Events still be in the public API of a
TaskContext, so that peer TaskContexts can signal the Event of their
peer?

In conclusion, for me personally, it would be very nice to see a
_mockup_ of the RTT 2.0 API (and possible FSM diagrams) before the
'start-to-code' phase. IOW, How will the TaskContext interface look
like in RTT 2.0?
And since I know the RTT 2.0 release manager is a big fan of TDD... :-)

> 4. Would you consider switching to RTT 2.0 or stay at RTT 1.x ?

Will you keep to do release updates of RTT 1.x? ;-))

> 5. Which tooling do you miss most when working with the RTT (give an example
> of existing tools in other frameworks if possible)

A GUI, such that all the cumbersome and errorprone typing work and
decyphering ugly compiler errors is history.

> Now is your chance to answer and influence this change for the better.

[...]

> I'll be on holidays for a week, so feel free to fire along, I won't argue
> with you :-)

Finally! :-)

Klaas

Important notice for existing Real-Time Toolkit users

Submitted by sspr on Wed, 2009-04-22 21:00.

On Friday 17 April 2009 16:42:29 Klaas Gadeyne wrote:
...
>
> I remember some people (justifiably) complaining about the imprecise
> semantics of UML. Unfortunately, it seems to me (and a lot of 'ok I
> misunderstood this' messages on this list seem to prove that) that the
> semantics of email discussions are even worse of those of UML.
> Therefore, I am currently unsure wether RTT 2.0 will bring what I
> expect from it.
>
> Some examples from the top of my head (certainly not exhaustive) to
> which I can't recall having seen them answered in the RTT 2.0
> discussions on the ML:
>
> [1/ It's been a while since I've had hands on orocos experience, so
> forgive any unforgivable error/mistakes/assumptions from my part
> below]
> [2/ Please also forgive any semantically unclear statements below :)]
>
> - What will RTT 2.0 do with respect to the loose coupling between
> taskContexts and activities? Will it still be possible to create a
> TaskContext whose well-functioning wholy depends on the fact that it
> is run in a NonPeriodicActivity and then connect that TaskContext to a
> periodicActivity via the deployers xml file?

I didn't have any plans about this yet. Would you be satisfied with a hook in
the component which allows you to check the activity before it is finally
assigned ?

> - How about the interaction between activity b] and e]? E.g.
> currently there's is no straighforward way of using UML::callEvents in
> orocos FSM. In UML, a UML::operation (in the interface of an object)
> can either result in a callEvent for the "Classifier FSM behaviour" of
> that object or be implemented as a UML::method. In RTT 1.x, using a
> RTT:Method the latter behaviour is realized easily, but the former is
> very cumbersome.

I needed a big drawing on a whiteboard before I understood this statement. UML
separates specifying interface from specifying implementation. In the RTT,
these are thightly coupled (except for events). We need to brainstorm about
how we are impacted by this or better, how and if we need to apply it to our
application domain. I see no use in copying the UML semantics one by one,
since they are way to abstract in my opinion. I prefer to present the user a
domain specific (ie robot & machine control) language, which may be inspired on
the flexibility UML provides.

> - Similar question about time events. How will I have to use a
> UML::TimeEvent in a FSM in RTT 2.0 ? Will there still be a
> TimerComponent which I have to set up, or will it be more like
> AUTOSAR, which considers the TimeService as a part of the
> infrastructure?

The TimerComponent is a workaround. Since time is such a fundamental part of
the applications we wish to write, I'll gladly review any proposal for a time
event primitive.

> - Will the refactored Events still be in the public API of a
> TaskContext, so that peer TaskContexts can signal the Event of their
> peer?

Only if you chose to add it as a method/message. BUT: if you want to emit an
event from the scripting interface, you'll need to add it anyway. And I've
experienced it to be *very* useful to be able to emit an event from the
TaskBrowser to check/influence components behaviour during debugging.

>
> In conclusion, for me personally, it would be very nice to see a
> _mockup_ of the RTT 2.0 API (and possible FSM diagrams) before the
> 'start-to-code' phase. IOW, How will the TaskContext interface look
> like in RTT 2.0?
> And since I know the RTT 2.0 release manager is a big fan of TDD... :-)

Take a look at the RTT 2.0 wiki, and specifically here:

http://www.orocos.org/node/1244

These are suggestions.

>
> > 4. Would you consider switching to RTT 2.0 or stay at RTT 1.x ?
>
> Will you keep to do release updates of RTT 1.x? ;-))

For 2009, I see no problems for maintaining 1.x. Maybe afterwards, someone
else may need to take over.

>
> > 5. Which tooling do you miss most when working with the RTT (give an
> > example of existing tools in other frameworks if possible)
>
> A GUI, such that all the cumbersome and errorprone typing work and
> decyphering ugly compiler errors is history.

Ack.

>
> > Now is your chance to answer and influence this change for the better.
>
> [...]
>
> > I'll be on holidays for a week, so feel free to fire along, I won't argue
> > with you :-)
>
> Finally! :-)

I hope you enjoyed that utterly short period of your life.

Peter

Important notice for existingReal-Time Toolkit users

Submitted by Vandenbroucke Sander on Thu, 2009-04-23 07:50.

> > - Will the refactored Events still be in the public API of a
> > TaskContext, so that peer TaskContexts can signal the Event of their
> > peer?
>
> Only if you chose to add it as a method/message. BUT: if you want to
emit
> an
> event from the scripting interface, you'll need to add it anyway. And
I've
> experienced it to be *very* useful to be able to emit an event from
the
> TaskBrowser to check/influence components behaviour during debugging.
>
> >
> > In conclusion, for me personally, it would be very nice to see a
> > _mockup_ of the RTT 2.0 API (and possible FSM diagrams) before the
> > 'start-to-code' phase. IOW, How will the TaskContext interface look
> > like in RTT 2.0?
> > And since I know the RTT 2.0 release manager is a big fan of TDD...
:-)
>
> Take a look at the RTT 2.0 wiki, and specifically here:
>
> http://www.orocos.org/node/1244
>
I had a look at this page. These proposals will make an upgrade to RTT
2.0 a hard job for us.
- We use synchronous execution of events a lot (in callers thread).
Switching to methods will not be trivial.

Sander.

Important notice for existing Real-Time Toolkit users

Submitted by bruyninc on Fri, 2009-04-17 15:10.

On Fri, 17 Apr 2009, Klaas Gadeyne wrote:

[...]
Thanks for your couple of "deep" comments!

> - What will RTT 2.0 do with respect to the loose coupling between
> taskContexts and activities? Will it still be possible to create a
> TaskContext whose well-functioning wholy depends on the fact that it
> is run in a NonPeriodicActivity and then connect that TaskContext to a
> periodicActivity via the deployers xml file?

These are semantic errors (or rather, "holes") in RTT, in my opinion. Going
towards a more explicit 'component meta-model' is a potential answer to
this kind of problems; in other words, the TaskContext should add this kind
of requirements to its "inspectable interface", so that tools like the
deployer can check for (in)consistency...

[...]
> - Similar question about time events. How will I have to use a
> UML::TimeEvent in a FSM in RTT 2.0 ?

What makes a timer-triggered event different from another event, as far as
the state machine semantics go? (They _do_ give problems, if the timer
events come too fast for the TaskContext to process, but that can never be
avoided in an application-independent way, in my opinion.)

> Will there still be a TimerComponent which I have to set up, or will it
> be more like AUTOSAR, which considers the TimeService as a part of the
> infrastructure?

Both scenarios are not so different, I think: only the "Configuation"
workflow differs. A possible answer in the right direction might be along
the lines of one of the remarks on the Orocos Workshop two weeks ago: our
current TaskContext implementation has only a "provided interface" support,
and not a "required interface" support. That means that the deployer (or
another activity in charge of configuring an application) cannot check what
services are to be started, or to find out when a deployment file is
inconsistent, etc.

> - Will the refactored Events still be in the public API of a TaskContext,
> so that peer TaskContexts can signal the Event of their peer?

Do you have suggestions (not) to do it in this way?

> In conclusion, for me personally, it would be very nice to see a
> _mockup_ of the RTT 2.0 API (and possible FSM diagrams) before the
> 'start-to-code' phase. IOW, How will the TaskContext interface look
> like in RTT 2.0?
> And since I know the RTT 2.0 release manager is a big fan of TDD... :-)

<http://en.wikipedia.org/wiki/TDD>? :-)

Herman

Important notice for existing Real-Time Toolkit users

Submitted by fosini on Wed, 2009-04-22 12:45.

On Fri, Apr 17, 2009 at 5:05 PM, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> wrote:

> On Fri, 17 Apr 2009, Klaas Gadeyne wrote:
>
> [...]
> Thanks for your couple of "deep" comments!
>
> > - What will RTT 2.0 do with respect to the loose coupling between
> > taskContexts and activities? Will it still be possible to create a
> > TaskContext whose well-functioning wholy depends on the fact that it
> > is run in a NonPeriodicActivity and then connect that TaskContext to a
> > periodicActivity via the deployers xml file?
>
> These are semantic errors (or rather, "holes") in RTT, in my opinion. Going
> towards a more explicit 'component meta-model' is a potential answer to
> this kind of problems; in other words, the TaskContext should add this kind
> of requirements to its "inspectable interface", so that tools like the
> deployer can check for (in)consistency...
>
> [...]
> > - Similar question about time events. How will I have to use a
> > UML::TimeEvent in a FSM in RTT 2.0 ?
>
> What makes a timer-triggered event different from another event, as far as
> the state machine semantics go? (They _do_ give problems, if the timer
> events come too fast for the TaskContext to process, but that can never be
> avoided in an application-independent way, in my opinion.)
>
> > Will there still be a TimerComponent which I have to set up, or will it
> > be more like AUTOSAR, which considers the TimeService as a part of the
> > infrastructure?
>
> Both scenarios are not so different, I think: only the "Configuation"
> workflow differs. A possible answer in the right direction might be along
> the lines of one of the remarks on the Orocos Workshop two weeks ago: our
> current TaskContext implementation has only a "provided interface" support,
> and not a "required interface" support. That means that the deployer (or
> another activity in charge of configuring an application) cannot check what
> services are to be started, or to find out when a deployment file is
> inconsistent, etc.

How would a "required interface" be specified?
In the current RTT I would enforce activity type requirements (periodic,
nonperiodic) at runtime in the activateHook() of a TaskContext by means of
getActivity()->isPeriodic() and log an error message + return false if the
requirements are not satisfied.
I really like the idea of setting requirements for a TaskContext's activity,
and it would be great to have some kind of mechanism for setting them in a
less verbose way, and at an earlier time (e.g., when setting a TaskContext's
activity).

>
> > - Will the refactored Events still be in the public API of a TaskContext,
> > so that peer TaskContexts can signal the Event of their peer?
>
> Do you have suggestions (not) to do it in this way?
>
> > In conclusion, for me personally, it would be very nice to see a
> > _mockup_ of the RTT 2.0 API (and possible FSM diagrams) before the
> > 'start-to-code' phase. IOW, How will the TaskContext interface look
> > like in RTT 2.0?
> > And since I know the RTT 2.0 release manager is a big fan of TDD... :-)
>
> <http://en.wikipedia.org/wiki/TDD>? :-)
>
> Herman
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

Important notice for existing Real-Time Toolkit users

Submitted by markus.klotzbuecher on Wed, 2009-04-22 17:40.

On Wed, Apr 22, 2009 at 02:39:43PM +0200, Adolfo Rodríguez Tsouroukdissian wrote:
> Both scenarios are not so different, I think: only the "Configuation"
> workflow differs. A possible answer in the right direction might be along
> the lines of one of the remarks on the Orocos Workshop two weeks ago: our
> current TaskContext implementation has only a "provided interface" support,
> and not a "required interface" support. That means that the deployer (or
> another activity in charge of configuring an application) cannot check what
> services are to be started, or to find out when a deployment file is
> inconsistent, etc.
>
> How would a "required interface" be specified?
> In the current RTT I would enforce activity type requirements (periodic,
> nonperiodic) at runtime in the activateHook() of a TaskContext by means of
> getActivity()->isPeriodic() and log an error message + return false if the
> requirements are not satisfied.

But thats really a workaround. What we want in the longer run is to be
able to describe such constraints in a _declarative_ way (opposed to
imperatively coding this). Maybe this information could be held in
some kind of "manifest" file associated which each component which
then can be taken into account by the "configurer" (deployer)?

> I really like the idea of setting requirements for a TaskContext's activity,
> and it would be great to have some kind of mechanism for setting them in a less
> verbose way, and at an earlier time (e.g., when setting a TaskContext's
> activity).

Having an activity of a type is one constraint, but there could be
many more: ports which are required to be connected or might be
optional, required component methods etc.

>From a modeling POV this is a clear case for OCL[1] or similar.

Best regards
Markus

[1] http://en.wikipedia.org/wiki/Object_Constraint_Language

Important notice for existing Real-Time Toolkit users

Submitted by Klaas Gadeyne on Wed, 2009-04-22 18:20.

On Wed, Apr 22, 2009 at 7:38 PM, Markus Klotzbücher
<markus [dot] klotzbuecher [..] ...> wrote:
> On Wed, Apr 22, 2009 at 02:39:43PM +0200, Adolfo Rodríguez Tsouroukdissian wrote:
>> Both scenarios are not so different, I think: only the "Configuation"
>> workflow differs. A possible answer in the right direction might be along
>> the lines of one of the remarks on the Orocos Workshop two weeks ago: our
>> current TaskContext implementation has only a "provided interface" support,
>> and not a "required interface" support. That means that the deployer (or
>> another activity in charge of configuring an application) cannot check what
>> services are to be started, or to find out when a deployment file is
>> inconsistent, etc.
>>
>> How would a "required interface" be specified?
>> In the current RTT I would enforce activity type requirements (periodic,
>> nonperiodic) at runtime in the activateHook() of a TaskContext by means of
>> getActivity()->isPeriodic() and log an error message + return false if the
>> requirements are not satisfied.
>
> But thats really a workaround. What we want in the longer run is to be
> able to describe such constraints in a _declarative_ way (opposed to
> imperatively coding this). Maybe this information could be held in
> some kind of "manifest" file associated which each component which
> then can be taken into account by the "configurer" (deployer)?
>
>> I really like the idea of setting requirements for a TaskContext's activity,
>> and it would be great to have some kind of mechanism for setting them in a less
>> verbose way, and at an earlier time (e.g., when setting a TaskContext's
>> activity).
>
> Having an activity of a type is one constraint, but there could be
> many more: ports which are required to be connected or might be
> optional, required component methods etc.
>
> From a modeling POV this is a clear case for OCL[1] or similar.

I might be (and probably am) wrong, but I always thought that OCL was
meant to specify constraints on the _meta_-model level. E.g, you
could specify in OCL that one cannot connect dataPorts of type double
with dataPorts of type String, given the orocos meta-model.
However, I think we are talking here about constraints which are
inherent to a particular component _implementation_, and not limits
imposed by the meta-model (at least not the _current_ orocos
metamodel).

So either you could solve this by changing the current meta-model
(e.g. not (or only in a limited way) allowing to change the activity
after a Component has been "implemented".
Either one could use the constraint approach described above (and I
also prefer the declarative way which you sketch).
Currently I don't know what would be the best solution (or wether
there's a third alternative)

Klaas

Important notice for existing Real-Time Toolkit users

Submitted by markus.klotzbuecher on Wed, 2009-04-22 21:45.

On Wed, Apr 22, 2009 at 08:14:46PM +0200, Klaas Gadeyne wrote:
> On Wed, Apr 22, 2009 at 7:38 PM, Markus Klotzbücher
> <markus [dot] klotzbuecher [..] ...> wrote:
> > On Wed, Apr 22, 2009 at 02:39:43PM +0200, Adolfo Rodríguez Tsouroukdissian wrote:
...
> >> I really like the idea of setting requirements for a TaskContext's activity,
> >> and it would be great to have some kind of mechanism for setting them in a less
> >> verbose way, and at an earlier time (e.g., when setting a TaskContext's
> >> activity).
> >
> > Having an activity of a type is one constraint, but there could be
> > many more: ports which are required to be connected or might be
> > optional, required component methods etc.
> >
> > From a modeling POV this is a clear case for OCL[1] or similar.
>
> I might be (and probably am) wrong, but I always thought that OCL was
> meant to specify constraints on the _meta_-model level. E.g, you

An OCL constraint is specified in the context of a
classifier. UML::Component or UML::Class are classifiers, therefore
RTT::Component are too (e.g. a TaskContext is a class) which implies
that adding constraints to RTT::TaskContext is ok!

> could specify in OCL that one cannot connect dataPorts of type double
> with dataPorts of type String, given the orocos meta-model.
> However, I think we are talking here about constraints which are
> inherent to a particular component _implementation_, and not limits
> imposed by the meta-model (at least not the _current_ orocos
> metamodel).
>
> So either you could solve this by changing the current meta-model
> (e.g. not (or only in a limited way) allowing to change the activity
> after a Component has been "implemented".

What exactly do you mean here?

> Either one could use the constraint approach described above (and I
> also prefer the declarative way which you sketch).
> Currently I don't know what would be the best solution (or wether
> there's a third alternative)

Best regards
Markus

Important notice for existing Real-Time Toolkit users

Submitted by Klaas Gadeyne on Wed, 2009-04-22 21:55.

On Wed, Apr 22, 2009 at 11:40 PM, Markus Klotzbücher
<markus [dot] klotzbuecher [..] ...> wrote:
> On Wed, Apr 22, 2009 at 08:14:46PM +0200, Klaas Gadeyne wrote:
>> On Wed, Apr 22, 2009 at 7:38 PM, Markus Klotzbücher
>> <markus [dot] klotzbuecher [..] ...> wrote:
>> > On Wed, Apr 22, 2009 at 02:39:43PM +0200, Adolfo Rodríguez Tsouroukdissian wrote:
> ...
>> >> I really like the idea of setting requirements for a TaskContext's activity,
>> >> and it would be great to have some kind of mechanism for setting them in a less
>> >> verbose way, and at an earlier time (e.g., when setting a TaskContext's
>> >> activity).
>> >
>> > Having an activity of a type is one constraint, but there could be
>> > many more: ports which are required to be connected or might be
>> > optional, required component methods etc.
>> >
>> > From a modeling POV this is a clear case for OCL[1] or similar.
>>
>> I might be (and probably am) wrong, but I always thought that OCL was
>> meant to specify constraints on the _meta_-model level. E.g, you
>
> An OCL constraint is specified in the context of a
> classifier. UML::Component or UML::Class are classifiers, therefore
> RTT::Component are too (e.g. a TaskContext is a class) which implies
> that adding constraints to RTT::TaskContext is ok!

Exactly, but what we were talking about here is adding constraints to
particular _implementations_ (instances) of RTT::TaskContext. One
cannot say that there is a constraint on RTT:TaskContext. E.g. in the
case _you_ design a TaskContext which relies on a NonPeriodicActivity
for well-functioning, the constraint is only there for your specific
TaskContext, not for the RTT:TaskContext in general.

>> could specify in OCL that one cannot connect dataPorts of type double
>> with dataPorts of type String, given the orocos meta-model.
>> However, I think we are talking here about constraints which are
>> inherent to a particular component _implementation_, and not limits
>> imposed by the meta-model (at least not the _current_ orocos
>> metamodel).
>>
>> So either you could solve this by changing the current meta-model
>> (e.g. not (or only in a limited way) allowing to change the activity
>> after a Component has been "implemented".
>
> What exactly do you mean here?

The current meta-model of orocos components has a loose coupling
between TaskContext and Activities. This could be made more "rigid".

>> Either one could use the constraint approach described above (and I
>> also prefer the declarative way which you sketch).
>> Currently I don't know what would be the best solution (or wether
>> there's a third alternative)
>
> Best regards
> Markus
>

Important notice for existing Real-Time Toolkit users

Submitted by markus.klotzbuecher on Thu, 2009-04-23 09:15.

On Wed, Apr 22, 2009 at 11:51:05PM +0200, Klaas Gadeyne wrote:
> On Wed, Apr 22, 2009 at 11:40 PM, Markus Klotzbücher
> <markus [dot] klotzbuecher [..] ...> wrote:
> > On Wed, Apr 22, 2009 at 08:14:46PM +0200, Klaas Gadeyne wrote:
> >> On Wed, Apr 22, 2009 at 7:38 PM, Markus Klotzbücher
> >> <markus [dot] klotzbuecher [..] ...> wrote:
> >> > On Wed, Apr 22, 2009 at 02:39:43PM +0200, Adolfo Rodríguez Tsouroukdissian wrote:
> > ...
> >> >> I really like the idea of setting requirements for a TaskContext's activity,
> >> >> and it would be great to have some kind of mechanism for setting them in a less
> >> >> verbose way, and at an earlier time (e.g., when setting a TaskContext's
> >> >> activity).
> >> >
> >> > Having an activity of a type is one constraint, but there could be
> >> > many more: ports which are required to be connected or might be
> >> > optional, required component methods etc.
> >> >
> >> > From a modeling POV this is a clear case for OCL[1] or similar.
> >>
> >> I might be (and probably am) wrong, but I always thought that OCL was
> >> meant to specify constraints on the _meta_-model level. E.g, you
> >
> > An OCL constraint is specified in the context of a
> > classifier. UML::Component or UML::Class are classifiers, therefore
> > RTT::Component are too (e.g. a TaskContext is a class) which implies
> > that adding constraints to RTT::TaskContext is ok!
>
> Exactly, but what we were talking about here is adding constraints to
> particular _implementations_ (instances) of RTT::TaskContext. One
> cannot say that there is a constraint on RTT:TaskContext. E.g. in the

But the relationship between TaskContext and any OROCOS Component is
"only" specialisation, not instantiation. We're still at the modeling
level. So if we can specify constraints on TaskContext why not on
subclasses of it?

A more practical problem is, I learned, is that there a few good OCL
implementations around and I'm not aware of any OCL library which we
could use for building a smart "deployer-ng".

Regards
Markus

Important notice for existing Real-Time Toolkit users

Submitted by Klaas Gadeyne on Thu, 2009-04-23 20:30.

On Thu, Apr 23, 2009 at 11:10 AM, Markus Klotzb?cher
<markus [dot] klotzbuecher [..] ...> wrote:
[...]
>> >> > From a modeling POV this is a clear case for OCL[1] or similar.
>> >>
>> >> I might be (and probably am) wrong, but I always thought that OCL was
>> >> meant to specify constraints on the _meta_-model level. E.g, you
>> >
>> > An OCL constraint is specified in the context of a
>> > classifier. UML::Component or UML::Class are classifiers, therefore
>> > RTT::Component are too (e.g. a TaskContext is a class) which implies
>> > that adding constraints to RTT::TaskContext is ok!
>>
>> Exactly, but what we were talking about here is adding constraints to
>> particular _implementations_ (instances) of RTT::TaskContext. One
>> cannot say that there is a constraint on RTT:TaskContext. E.g. in the
>
> But the relationship between TaskContext and any OROCOS Component is
> "only" specialisation, not instantiation. We're still at the modeling
> level. So if we can specify constraints on TaskContext why not on
> subclasses of it?

What I meant with "implementation" above is the fact that your own
taskcontext is on the model-level and not on the meta-model level (and
each model can be seen as ...).
See e.g. this thread IIRC
<http://lists.gforge.enseeiht.fr/pipermail/topcased-users/2009-January/002668.html>

Klaas
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

Important notice for existing Real-Time Toolkit users

Submitted by markus.klotzbuecher on Fri, 2009-04-24 07:20.

On Thu, Apr 23, 2009 at 10:28:58PM +0200, Klaas Gadeyne wrote:
> On Thu, Apr 23, 2009 at 11:10 AM, Markus Klotzb?cher
> <markus [dot] klotzbuecher [..] ...> wrote:
> [...]
> >> >> > From a modeling POV this is a clear case for OCL[1] or similar.
> >> >>
> >> >> I might be (and probably am) wrong, but I always thought that OCL was
> >> >> meant to specify constraints on the _meta_-model level. E.g, you
> >> >
> >> > An OCL constraint is specified in the context of a
> >> > classifier. UML::Component or UML::Class are classifiers, therefore
> >> > RTT::Component are too (e.g. a TaskContext is a class) which implies
> >> > that adding constraints to RTT::TaskContext is ok!
> >>
> >> Exactly, but what we were talking about here is adding constraints to
> >> particular _implementations_ (instances) of RTT::TaskContext. One
> >> cannot say that there is a constraint on RTT:TaskContext. E.g. in the
> >
> > But the relationship between TaskContext and any OROCOS Component is
> > "only" specialisation, not instantiation. We're still at the modeling
> > level. So if we can specify constraints on TaskContext why not on
> > subclasses of it?
>
> What I meant with "implementation" above is the fact that your own
> taskcontext is on the model-level and not on the meta-model level (and
> each model can be seen as ...).
> See e.g. this thread IIRC
> <http://lists.gforge.enseeiht.fr/pipermail/topcased-users/2009-January/002668.html>

Yes, but this is a limitation of the toolchain, not of OCL in
principle, agreed?

Regards
Markus
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

Important notice for existing Real-Time Toolkit users

Submitted by Klaas Gadeyne on Sat, 2009-04-25 08:00.

On Fri, Apr 24, 2009 at 9:15 AM, Markus Klotzbücher
<markus [dot] klotzbuecher [..] ...> wrote:
> On Thu, Apr 23, 2009 at 10:28:58PM +0200, Klaas Gadeyne wrote:
>> On Thu, Apr 23, 2009 at 11:10 AM, Markus Klotzb?cher
>> <markus [dot] klotzbuecher [..] ...> wrote:
>> [...]
>> >> >> > From a modeling POV this is a clear case for OCL[1] or similar.
>> >> >>
>> >> >> I might be (and probably am) wrong, but I always thought that OCL was
>> >> >> meant to specify constraints on the _meta_-model level. E.g, you
>> >> >
>> >> > An OCL constraint is specified in the context of a
>> >> > classifier. UML::Component or UML::Class are classifiers, therefore
>> >> > RTT::Component are too (e.g. a TaskContext is a class) which implies
>> >> > that adding constraints to RTT::TaskContext is ok!
>> >>
>> >> Exactly, but what we were talking about here is adding constraints to
>> >> particular _implementations_ (instances) of RTT::TaskContext. One
>> >> cannot say that there is a constraint on RTT:TaskContext. E.g. in the
>> >
>> > But the relationship between TaskContext and any OROCOS Component is
>> > "only" specialisation, not instantiation. We're still at the modeling
>> > level. So if we can specify constraints on TaskContext why not on
>> > subclasses of it?
>>
>> What I meant with "implementation" above is the fact that your own
>> taskcontext is on the model-level and not on the meta-model level (and
>> each model can be seen as ...).
>> See e.g. this thread IIRC
>> <http://lists.gforge.enseeiht.fr/pipermail/topcased-users/2009-January/002668.html>
>
> Yes, but this is a limitation of the toolchain, not of OCL in
> principle, agreed?

I think you're right, but I'm not familiar enough with OCL to be sure.

Klaas
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

Important notice for existing Real-Time Toolkit users

Submitted by fosini on Thu, 2009-04-23 09:50.

On Thu, Apr 23, 2009 at 11:10 AM, Markus Klotzb?cher <
markus [dot] klotzbuecher [..] ...> wrote:

> On Wed, Apr 22, 2009 at 11:51:05PM +0200, Klaas Gadeyne wrote:
> > On Wed, Apr 22, 2009 at 11:40 PM, Markus Klotzbücher
> > <markus [dot] klotzbuecher [..] ...> wrote:
> > > On Wed, Apr 22, 2009 at 08:14:46PM +0200, Klaas Gadeyne wrote:
> > >> On Wed, Apr 22, 2009 at 7:38 PM, Markus Klotzbücher
> > >> <markus [dot] klotzbuecher [..] ...> wrote:
> > >> > On Wed, Apr 22, 2009 at 02:39:43PM +0200, Adolfo Rodríguez
> Tsouroukdissian wrote:
> > > ...
> > >> >> I really like the idea of setting requirements for a TaskContext's
> activity,
> > >> >> and it would be great to have some kind of mechanism for setting
> them in a less
> > >> >> verbose way, and at an earlier time (e.g., when setting a
> TaskContext's
> > >> >> activity).
> > >> >
> > >> > Having an activity of a type is one constraint, but there could be
> > >> > many more: ports which are required to be connected or might be
> > >> > optional, required component methods etc.
> > >> >
> > >> > From a modeling POV this is a clear case for OCL[1] or similar.
> > >>
> > >> I might be (and probably am) wrong, but I always thought that OCL was
> > >> meant to specify constraints on the _meta_-model level. E.g, you
> > >
> > > An OCL constraint is specified in the context of a
> > > classifier. UML::Component or UML::Class are classifiers, therefore
> > > RTT::Component are too (e.g. a TaskContext is a class) which implies
> > > that adding constraints to RTT::TaskContext is ok!
> >
> > Exactly, but what we were talking about here is adding constraints to
> > particular _implementations_ (instances) of RTT::TaskContext. One
> > cannot say that there is a constraint on RTT:TaskContext. E.g. in the
>
> But the relationship between TaskContext and any OROCOS Component is
> "only" specialisation, not instantiation. We're still at the modeling
> level. So if we can specify constraints on TaskContext why not on
> subclasses of it?
>
> A more practical problem is, I learned, is that there a few good OCL
> implementations around and I'm not aware of any OCL library which we
> could use for building a smart "deployer-ng".

Speaking of ambiguities, I started reading this post thinking OCL = Orocos
Component Library, and after not understanding a thing, I realized that in
this thread OCL = Object Constraint Language, :-s

>
>
> Regards
> Markus
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

Important notice for existing Real-Time Toolkit users

Submitted by sspr on Wed, 2009-04-22 17:00.

On Wednesday 22 April 2009 14:39:43 Adolfo Rodríguez Tsouroukdissian wrote:
> On Fri, Apr 17, 2009 at 5:05 PM, Herman Bruyninckx <
>
> Herman [dot] Bruyninckx [..] ...> wrote:
> > On Fri, 17 Apr 2009, Klaas Gadeyne wrote:
> >
> > [...]
> > Thanks for your couple of "deep" comments!
> >
> > > - What will RTT 2.0 do with respect to the loose coupling between
> > > taskContexts and activities? Will it still be possible to create a
> > > TaskContext whose well-functioning wholy depends on the fact that it
> > > is run in a NonPeriodicActivity and then connect that TaskContext to a
> > > periodicActivity via the deployers xml file?
> >
> > These are semantic errors (or rather, "holes") in RTT, in my opinion.
> > Going towards a more explicit 'component meta-model' is a potential
> > answer to this kind of problems; in other words, the TaskContext should
> > add this kind of requirements to its "inspectable interface", so that
> > tools like the deployer can check for (in)consistency...
> >
> > [...]
> >
> > > - Similar question about time events. How will I have to use a
> > > UML::TimeEvent in a FSM in RTT 2.0 ?
> >
> > What makes a timer-triggered event different from another event, as far
> > as the state machine semantics go? (They _do_ give problems, if the timer
> > events come too fast for the TaskContext to process, but that can never
> > be avoided in an application-independent way, in my opinion.)
> >
> > > Will there still be a TimerComponent which I have to set up, or will it
> > > be more like AUTOSAR, which considers the TimeService as a part of the
> > > infrastructure?
> >
> > Both scenarios are not so different, I think: only the "Configuation"
> > workflow differs. A possible answer in the right direction might be along
> > the lines of one of the remarks on the Orocos Workshop two weeks ago: our
> > current TaskContext implementation has only a "provided interface"
> > support, and not a "required interface" support. That means that the
> > deployer (or another activity in charge of configuring an application)
> > cannot check what services are to be started, or to find out when a
> > deployment file is inconsistent, etc.
>
> How would a "required interface" be specified?

At the Method/Message/Event level, this is adding these primitives to a special
interface object, which allows deployment logic to link your required primitives
to provided primitives in other components. For example:

// add the setResolution Method to the CameraInterface
this->provides("CameraInterface")->addMethod(&setResolution, "Description",...);
// provide more...
 
// require the getObstacles Method from the MappingInterface
this->requires("MappingInterface")->addMethod(&getObstacles);
// require more...

In case you omit the interface name (so this->provides()->...) you add the
method to the main interface of your component.

This new mechanism allows to
1. Define true Orocos requires & provides interfaces in C++
2. Link them at deployment time.

> In the current RTT I would enforce activity type requirements (periodic,
> nonperiodic) at runtime in the activateHook() of a TaskContext by means of
> getActivity()->isPeriodic() and log an error message + return false if the
> requirements are not satisfied.
> I really like the idea of setting requirements for a TaskContext's
> activity, and it would be great to have some kind of mechanism for setting
> them in a less verbose way, and at an earlier time (e.g., when setting a
> TaskContext's activity).

Good idea. So you propose something like a

// in use component class:
bool setActivityHook(ActivityInterface* new_act) {
   if (new_act->isPeriodic() )
      return false;
   return true; // require non-periodic activities.
}

Peter

Important notice for existing Real-Time Toolkit users

Submitted by Sylvain Joyeux on Thu, 2009-04-23 08:35.

In the end, what you are trying to rebuild (as a lot of people out there) is a
complete type system, and because of C++ lack of introspection you have to
reimplement all of it.

For instance, your isPeriodic thing is no good for me. because
ActivityInterface would require to have isBlaBla methods for all types of
activities ever imagined.

IMO the most efficient way to handle the requirement/verification process is at
the tool level, not at the library level. Simply writing specification in
whatever textual format you prefer, and checking that your deployment matches
your specification. It has multiple advantages:
- you write a code generator that makes sure the actual code matches the
specification
- you can verify deployments before running the components
- you make the information available to other tools (think "planning",
"functional layer controllers", "safety bags", "configuration management").

And because it is linked to the "I'd rather have Eclipse support" remark from
Herman, /I don't/. I'd rather have a command line tool (which I already have),
and let Eclipse or whatever IDE interface with that tool. Why ? Because
Eclipse is putting all my computers on their knees, it's slow and it's not
vim.

Sylvain

Important notice for existing Real-Time Toolkit users

Submitted by bruyninc on Mon, 2009-04-27 05:50.

On Thu, 23 Apr 2009, Sylvain Joyeux wrote:

> In the end, what you are trying to rebuild (as a lot of people out there) is a
> complete type system, and because of C++ lack of introspection you have to
> reimplement all of it.
>
> For instance, your isPeriodic thing is no good for me. because
> ActivityInterface would require to have isBlaBla methods for all types of
> activities ever imagined.

I follow your remark!

> IMO the most efficient way to handle the requirement/verification process is at
> the tool level, not at the library level. Simply writing specification in
> whatever textual format you prefer, and checking that your deployment matches
> your specification. It has multiple advantages:
> - you write a code generator that makes sure the actual code matches the
> specification
> - you can verify deployments before running the components
> - you make the information available to other tools (think "planning",
> "functional layer controllers", "safety bags", "configuration management").

Ok!

> And because it is linked to the "I'd rather have Eclipse support" remark from
> Herman, /I don't/. I'd rather have a command line tool (which I already have),
> and let Eclipse or whatever IDE interface with that tool. Why ? Because
> Eclipse is putting all my computers on their knees, it's slow and it's not
> vim.

You are answering your own comment: having a command line tool allows
Eclipse integration! Without having to _need_ Eclipse, because your last
comment is valid too. But, _no_ industry is going to commit to a bunch of
software if there is no IDE support. The good news is that both communities
(the "hackers" and the "suits") can be satisfied without having to do work
twice: provide good 'command line tools' and then provide an Eclipse plugin
around it.

Herman

Important notice for existing Real-Time Toolkit users

Submitted by markus.klotzbuecher on Wed, 2009-04-22 17:55.

On Wed, Apr 22, 2009 at 05:06:14PM +0200, Peter Soetens wrote:
> On Wednesday 22 April 2009 14:39:43 Adolfo Rodríguez Tsouroukdissian wrote:
> > On Fri, Apr 17, 2009 at 5:05 PM, Herman Bruyninckx <
...
> > >
> > > Both scenarios are not so different, I think: only the "Configuation"
> > > workflow differs. A possible answer in the right direction might be along
> > > the lines of one of the remarks on the Orocos Workshop two weeks ago: our
> > > current TaskContext implementation has only a "provided interface"
> > > support, and not a "required interface" support. That means that the
> > > deployer (or another activity in charge of configuring an application)
> > > cannot check what services are to be started, or to find out when a
> > > deployment file is inconsistent, etc.
> >
> > How would a "required interface" be specified?
>
> At the Method/Message/Event level, this is adding these primitives to a special
> interface object, which allows deployment logic to link your required primitives
> to provided primitives in other components. For example:
>
>

> // add the setResolution Method to the CameraInterface
> this->provides("CameraInterface")->addMethod(&setResolution, "Description",...);
> // provide more...
> 
> // require the getObstacles Method from the MappingInterface
> this->requires("MappingInterface")->addMethod(&getObstacles);
> // require more...
>

Are you *really* sure this should be done at this low level? I'm very
in doubt about this! This will make testing harder and increase
component interface complexity...

In addition you cover only a very small amount of possible
constraints. How would you express: this component requires "MethodA"
OR "MethodB"?

> In case you omit the interface name (so this->provides()->...) you add the
> method to the main interface of your component.
>
> This new mechanism allows to
> 1. Define true Orocos requires & provides interfaces in C++
> 2. Link them at deployment time.
>
> > In the current RTT I would enforce activity type requirements (periodic,
> > nonperiodic) at runtime in the activateHook() of a TaskContext by means of
> > getActivity()->isPeriodic() and log an error message + return false if the
> > requirements are not satisfied.
> > I really like the idea of setting requirements for a TaskContext's
> > activity, and it would be great to have some kind of mechanism for setting
> > them in a less verbose way, and at an earlier time (e.g., when setting a
> > TaskContext's activity).
>
> Good idea. So you propose something like a
>

> // in use component class:
> bool setActivityHook(ActivityInterface* new_act) {
>    if (new_act->isPeriodic() )
>       return false;
>    return true; // require non-periodic activities.
> }
>

I disagree! This way it will fail, but we don't know why, and even if
a message is logged we our "Configurer" will not know at a semantic
level. I really think this should be dealt with outside of the core
RTT, and certainly not in C++.

Best regards
Markus

Important notice for existing Real-Time Toolkit users

Submitted by Klaas Gadeyne on Fri, 2009-04-17 15:30.

On Fri, Apr 17, 2009 at 5:05 PM, Herman Bruyninckx
<Herman [dot] Bruyninckx [..] ...> wrote:
> On Fri, 17 Apr 2009, Klaas Gadeyne wrote:
>
> [...]
> Thanks for your couple of "deep" comments!
>
>> - What will RTT 2.0 do with respect to the loose coupling between
>> taskContexts and activities? Will it still be possible to create a
>> TaskContext whose well-functioning wholy depends on the fact that it
>> is run in a NonPeriodicActivity and then connect that TaskContext to a
>> periodicActivity via the deployers xml file?
>
> These are semantic errors (or rather, "holes") in RTT, in my opinion. Going
> towards a more explicit 'component meta-model' is a potential answer to
> this kind of problems; in other words, the TaskContext should add this kind
> of requirements to its "inspectable interface", so that tools like the
> deployer can check for (in)consistency...
>
> [...]
>> - Similar question about time events. How will I have to use a
>> UML::TimeEvent in a FSM in RTT 2.0 ?
>
> What makes a timer-triggered event different from another event, as far as
> the state machine semantics go? (They _do_ give problems, if the timer
> events come too fast for the TaskContext to process, but that can never be
> avoided in an application-independent way, in my opinion.)

Semantic confusion number 1 :-)
I was referring to the API of the FSM scripting language. Currently I
(think I would) need to write _a lot_ of (useless workaround) code to
be able to use a TimeEvent in the scripting language. I wondered how
Markus/Peter saw this in 2.0.

>> Will there still be a TimerComponent which I have to set up, or will it
>> be more like AUTOSAR, which considers the TimeService as a part of the
>> infrastructure?
>
> Both scenarios are not so different, I think: only the "Configuation"
> workflow differs.

Agreed. But the configuration workflow can be a lot of work to set up.

> A possible answer in the right direction might be along
> the lines of one of the remarks on the Orocos Workshop two weeks ago: our
> current TaskContext implementation has only a "provided interface" support,
> and not a "required interface" support.

Hey, I'm not the only UML fan in this world :-]

> That means that the deployer (or another activity in charge of configuring an application) cannot check what services are to be started, or to find out when a deployment file is
> inconsistent, etc.
>
>> - Will the refactored Events still be in the public API of a TaskContext,
>> so that peer TaskContexts can signal the Event of their peer?
>
> Do you have suggestions (not) to do it in this way?

I think it seems more logical to be only able to "subscribe" to an
event of a (peer) TaskContext, and not being able to fire it. If you
need to ask another component to fire an event, you might as well use
the method interface I guess.

>> In conclusion, for me personally, it would be very nice to see a
>> _mockup_ of the RTT 2.0 API (and possible FSM diagrams) before the
>> 'start-to-code' phase. IOW, How will the TaskContext interface look
>> like in RTT 2.0?
>> And since I know the RTT 2.0 release manager is a big fan of TDD... :-)
>
> <http://en.wikipedia.org/wiki/TDD>? :-)

Trick Daddy Dollars, indeed ;-)

Important notice for existing Real-Time Toolkit users

Submitted by fosini on Thu, 2009-04-09 13:45.

On Thu, Apr 9, 2009 at 11:18 AM, Peter Soetens <peter [dot] soetens [..] ...>wrote:

> Dear RTT user,
>
> This summer, the Real-Time Toolkit will undergo its upgrade to reach
> version
> 2.0. This means some functions or classes will change. It is our intention
> to
> make the transition for existing RTT-1.0 users as painless as possible. In
> order to do so, the following objectives are set forth:
>
> * To aim for simplification: pure out semantics of the functions and
> objects
> * To not add complexity and to get a uniform 'look and feel'.
> * To rename functions or classes if their semantics change
> * To provide scripts that do necessary renames of changed functions,
> classes,
> includes etc. in user code
> * To provide detailed transition notes to guide you in all this
>
> The discussions about the topics of change were already started on the
> orocos-
> dev mailing list. See this page: http://www.orocos.org/wiki/rtt/rtt-2.0for
> the summary of that discussion. Though nothing is carved in stone yet.
>
> The proposed major work packages are:
> * Data Ports simplification: Sylvain Joyeux proposed a new data port model
> which improves component reusability, interoperability with other
> frameworks
> and is more logical.
> * Method/Event/Command simplification: Peter Soetens proposed to offer a
> simpler
> 'Message' primitive instead of Command and unify Method and Message with
> the
> Event interface and on the CORBA interface. This simplifies the Orocos
> client/server aka request/reply model for component communication.
> * Application examples: Using the improved interface, write 3 or 4 typical
> getting started applications, which new users can use to start from.
> * RTT source and namespace reordering: Headers and classes not meant for
> users
> will be moved in sub-directories and nested namespaces.
> * UML 2.0 state machine script integration using Lua: Markus Klotzbucher
> proposes a way to define UML 2.0 state machines in Orocos, which are
> described
> in the Lua language
> (see the link above for more details)
>
> We'd like to get answers from users on these 5 questions:
> 1. Which of these packages are important or not important to you ?

Classification from highest priority to lowest-priority:
1) Data Ports simplification & Method/Event/Command simplification, sharing
the highest priority: As these two packages progress, updates on how they
will affect backwards-compatibility (bw-c) will be greatly appreciated
(e.g., data flow interface will break bw-c, method interface will not, ...)

2) Build system overhaul (not listed above): I'd like to see a simpler and
more decoupled build system, since this is one of the first potential
obstacles a user will run into (unless he/she uses precompiled binaries).
It's frustrating to spend time hacking your way around the build system to
get a clean build, when you're aching to try out Orocos ;). We don't want to
dissapoint potential users in such an early stage of their trial. I would
not mix this item with source and namespace reordering, because I put very
different priorities to them.

3) Application examples: Always appreciated. Good for lowering the learning
curve and showing best-practices for common scenarios.

4) RTT source and namespace reordering: Now seems a good time to do it, but
I don't have any big complains on the subject. Although the class count may
be overwhelming, I usually surf the Doxygen doc quite easily.

5) UML 2.0 state machine script integration using Lua: I put it here not
because it's unimportant, but because I see it becoming a reality on a
longer term than the above packages.

> 2. Which of these changes would/could impact you a lot ?

> 3. Which is missing, what had you hoped that RTT 2.0 would solve/improve ?

- The build system overhaul (see question 1)
- This is more fine-grained, but I'd like to see a discussion on the
wiki/lists about the details of "Full distribution support", particularly
concerning out-of-band or through-CORBA data flows. What alternatives will
be available? what _must_ vs. what _could_ go through CORBA, will there be
integrated support for some form of out-of-band data flow, or will it be an
interface for users to implement?

>
> 4. Would you consider switching to RTT 2.0 or stay at RTT 1.x ?

Switch and don't look back (and hope a somewhat painless migration will be
possible)

>
> 5. Which tooling do you miss most when working with the RTT (give an
> example
> of existing tools in other frameworks if possible)
>

When introducing new people to Orocos I see (by far and large) one main
recurring feature people would like, either as part of Orocos, or as an
external but Orocos-compatible module: an environment for
visualization/simulation. I know there has been a lot of activity in what
concerns the Orocos-Blender integration. However, I would like to know more
about the current status of the project, its scope, etc. I have seen
these<http://people.mech.kuleuven.be/%7Ebruyninc/hb46/blender/chapter_robotanimation.html>
three <http://www.orocos.org/node/783>
links<http://people.mech.kuleuven.be/%7Ebruyninc/blender/roadmap.html>,
but I would definitely appreciate more information (please point me in the
right direction if it is already available). Maybe the slides or a brief
text of what was covered in the recent Euron meeting talk on "Blender for
robotics" would be nice.

I also back Herman's suggestion of a "a (portable) GUI interface to the
reporting and the online browsing".

Finally, I would greatly appreciate comments on the long-term (post 2.0)
goals that drive the Orocos project, at least the ones in the minds of its
current designers and developers.

Thanks for all the hard work that is being put on this great project!

>
> Now is your chance to answer and influence this change for the better.
>
> To state things clear: RTT 2.0 is *not* a major overhaul. A major part of
> the
> API and the concepts will remain the same.
>
> Please reply to orocos-dev, orocos-users or on the website forum where this
> post is also available. No discussion will take place on the 'orocos'
> announce
> list. I'll be on holidays for a week, so feel free to fire along, I won't
> argue
> with you :-)
>
> Peter
>
> --
> Peter Soetens -- FMTC -- <http://www.fmtc.be>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

Important notice for existing Real-Time Toolkit users

Submitted by fosini on Thu, 2009-04-09 13:45.

On Thu, Apr 9, 2009 at 11:18 AM, Peter Soetens <peter [dot] soetens [..] ...>wrote:

3) Application examples: Always appreciated. Good for lowering the learning
curve and showing best-practices for common scenarios.

5) UML 2.0 state machine script integration using Lua: I put it here not
because it's unimportant, but because I see it becoming a reality on a
longer term than the above packages.

> 2. Which of these changes would/could impact you a lot ?

> 3. Which is missing, what had you hoped that RTT 2.0 would solve/improve ?

>
> 4. Would you consider switching to RTT 2.0 or stay at RTT 1.x ?

Switch and don't look back (and hope a somewhat painless migration will be
possible)

>
> 5. Which tooling do you miss most when working with the RTT (give an
> example
> of existing tools in other frameworks if possible)
>

I also back Herman's suggestion of a "a (portable) GUI interface to the
reporting and the online browsing".

Finally, I would greatly appreciate comments on the long-term (post 2.0)
goals that drive the Orocos project, at least the ones in the minds of its
current designers and developers.

Thanks for all the hard work that is being put on this great project!

Important notice for existing Real-Time Toolkit users

Submitted by sspr on Wed, 2009-04-22 16:55.

On Thursday 09 April 2009 15:41:09 Adolfo Rodríguez Tsouroukdissian wrote:
> On Thu, Apr 9, 2009 at 11:18 AM, Peter Soetens <peter [dot] soetens [..] ...>wrote:
> > We'd like to get answers from users on these 5 questions:
> > 1. Which of these packages are important or not important to you ?
>
> Classification from highest priority to lowest-priority:
> 1) Data Ports simplification & Method/Event/Command simplification, sharing
> the highest priority: As these two packages progress, updates on how they
> will affect backwards-compatibility (bw-c) will be greatly appreciated
> (e.g., data flow interface will break bw-c, method interface will not, ...)

Ok.

>
> 2) Build system overhaul (not listed above): I'd like to see a simpler and
> more decoupled build system, since this is one of the first potential
> obstacles a user will run into (unless he/she uses precompiled binaries).
> It's frustrating to spend time hacking your way around the build system to
> get a clean build, when you're aching to try out Orocos ;). We don't want
> to dissapoint potential users in such an early stage of their trial. I
> would not mix this item with source and namespace reordering, because I put
> very different priorities to them.

I wanted to do the cleanup tasks first. So build system + namespace/directory
changes (Public API vs internal).

>
> 3) Application examples: Always appreciated. Good for lowering the learning
> curve and showing best-practices for common scenarios.

Ok.

>
> 4) RTT source and namespace reordering: Now seems a good time to do it, but
> I don't have any big complains on the subject. Although the class count may
> be overwhelming, I usually surf the Doxygen doc quite easily.

Ok.

>
> 5) UML 2.0 state machine script integration using Lua: I put it here not
> because it's unimportant, but because I see it becoming a reality on a
> longer term than the above packages.

Ok.

>
> > 2. Which of these changes would/could impact you a lot ?
> >
> >
> > 3. Which is missing, what had you hoped that RTT 2.0 would solve/improve
> > ?
>
> - The build system overhaul (see question 1)
> - This is more fine-grained, but I'd like to see a discussion on the
> wiki/lists about the details of "Full distribution support", particularly
> concerning out-of-band or through-CORBA data flows. What alternatives will
> be available? what _must_ vs. what _could_ go through CORBA, will there be
> integrated support for some form of out-of-band data flow, or will it be an
> interface for users to implement?

The main reason for out-of-band communication would be to allow integration
with other frameworks like ROS on the 'data flow level' (so orocos data ports
to ROS data packets). In typical Orocos style, out of band would be specified
as an interface that users can extend/implement.

>
> > 4. Would you consider switching to RTT 2.0 or stay at RTT 1.x ?
>
> Switch and don't look back (and hope a somewhat painless migration will be
> possible)
>
> > 5. Which tooling do you miss most when working with the RTT (give an
> > example
> > of existing tools in other frameworks if possible)
>
> When introducing new people to Orocos I see (by far and large) one main
> recurring feature people would like, either as part of Orocos, or as an
> external but Orocos-compatible module: an environment for
> visualization/simulation. I know there has been a lot of activity in what
> concerns the Orocos-Blender integration. However, I would like to know more
> about the current status of the project, its scope, etc. I have seen
> these<http://people.mech.kuleuven.be/%7Ebruyninc/hb46/blender/chapter_robot
>animation.html> three <http://www.orocos.org/node/783>
> links<http://people.mech.kuleuven.be/%7Ebruyninc/blender/roadmap.html>,
> but I would definitely appreciate more information (please point me in the
> right direction if it is already available). Maybe the slides or a brief
> text of what was covered in the recent Euron meeting talk on "Blender for
> robotics" would be nice.
>
> I also back Herman's suggestion of a "a (portable) GUI interface to the
> reporting and the online browsing".
>
> Finally, I would greatly appreciate comments on the long-term (post 2.0)
> goals that drive the Orocos project, at least the ones in the minds of its
> current designers and developers.
>

In general, one could say that the goals of the current Orocos developers is
to build and control robots or machines, more than developing Orocos itself.
We all set up our tool chain for creating our software, and Orocos is just a
part in that. New kinds of applications will require new tools, which drives
new developments in Orocos. For me, it's more important that 'Orocos can
control all kinds of robots' than 'Orocos makes Model Driven Engineering
possible'. In other terms, I hope Orocos becomes one of the references for
'Best Practice in Robotics', independent of what your background or vision is.

Peter

Important notice for existing Real-Time Toolkit users

Submitted by sspr on Wed, 2009-04-22 16:55.

Ok.

I wanted to do the cleanup tasks first. So build system + namespace/directory
changes (Public API vs internal).

>
> 3) Application examples: Always appreciated. Good for lowering the learning
> curve and showing best-practices for common scenarios.

Ok.

>
> 5) UML 2.0 state machine script integration using Lua: I put it here not
> because it's unimportant, but because I see it becoming a reality on a
> longer term than the above packages.

Ok.

Peter

Important notice for existing Real-Time Toolkit users

Submitted by Leopold Palomo-... on Thu, 2009-04-23 03:00.

A Dimecres 22 Abril 2009, Peter Soetens va escriure:
> On Thursday 09 April 2009 15:41:09 Adolfo Rodríguez Tsouroukdissian wrote:
> > On Thu, Apr 9, 2009 at 11:18 AM, Peter Soetens
<peter [dot] soetens [..] ...>wrote:
[...]

> For me, it's more important that
> 'Orocos can control all kinds of robots' than 'Orocos makes Model Driven
> Engineering possible'. In other terms, I hope Orocos becomes one of the
> references for 'Best Practice in Robotics', independent of what your
> background or vision is.

for me, this is the key ...

Leo

Important notice for existing Real-Time Toolkit users

Submitted by Leopold Palomo-... on Thu, 2009-04-23 03:00.

for me, this is the key ...

Leo

Important notice for existing Real-Time Toolkit users

Submitted by bruyninc on Thu, 2009-04-09 10:00.

On Thu, 9 Apr 2009, Peter Soetens wrote:

[...]
> The proposed major work packages are:
[...]
> * Method/Event/Command simplification: Peter Soetens proposed to offer a simpler
> 'Message' primitive instead of Command and unify Method and Message with the
> Event interface and on the CORBA interface. This simplifies the Orocos
> client/server aka request/reply model for component communication.

I think that what this simplification would bring is the following:
- to remove the overhead of having to keep 'state' information about a
Command execution in both components involved (the one calling the
Command and the one servicing the Command).
- to shift this "Coordination" burden to the content of both components.
Is this a correct interpretation? If so, what would we loose by introducing
this simplification? Personally, I think we would not loose much, since
Orocos' focus is on providing the minimal, flexible infrastructure to allow
inter-component cooperation, and trying to guarantee some form of Command
coordination is too difficult in the case where components are really
distributed over a network with unreliable communication...

Any comments on this?

> * UML 2.0 state machine script integration using Lua: Markus Klotzbucher
> proposes a way to define UML 2.0 state machines in Orocos, which are described
> in the Lua language

I would not make the decision yet to move to Lua! Let's first study this
alternative in a bit more technical detail, certainly with respect to the
realtime safeness of Lua...

> 3. Which is missing, what had you hoped that RTT 2.0 would solve/improve ?
> 5. Which tooling do you miss most when working with the RTT (give an example
> of existing tools in other frameworks if possible)

I don't know whether this is RTT's responsibility, but a (portable) GUI
interface to the reporting and the online browsing would be very useful...
Examples: the CLAM project has a "RTT-like" C++ framwork for the functional
infrastructure of working with data and event flows (focused on audio, but
the code base is not really depending on the kind of data!), and combines
it with a graphical programming environment from which a GUI can be
compiled. Some screenshots are here:
<http://clam-project.org/screenshots.html>
The concept and design are nice, but I would prefer to hook into a
framework that has more international traction (such as "something" from
the Eclipse or Apache ecosystems...)

> To state things clear: RTT 2.0 is *not* a major overhaul. A major part of the
> API and the concepts will remain the same.
It's not a major "overhaul", but is _is_ a major "change" :-)

Herman

Important notice for existing Real-Time Toolkit users

Submitted by sspr on Tue, 2009-04-21 07:25.

On Thursday 09 April 2009 11:55:27 Herman Bruyninckx wrote:
> On Thu, 9 Apr 2009, Peter Soetens wrote:
>
> [...]
>
> > The proposed major work packages are:
>
> [...]
>
> > * Method/Event/Command simplification: Peter Soetens proposed to offer a
> > simpler 'Message' primitive instead of Command and unify Method and
> > Message with the Event interface and on the CORBA interface. This
> > simplifies the Orocos client/server aka request/reply model for component
> > communication.
>
> I think that what this simplification would bring is the following:
> - to remove the overhead of having to keep 'state' information about a
> Command execution in both components involved (the one calling the
> Command and the one servicing the Command).

Exactly.

> - to shift this "Coordination" burden to the content of both components.

I'm not sure I get that point, but it is indeed 'shifted' and mainly:
make explicit. Commands now have implicit synchronisation when done in
scripting. This is removed and the user must explicitly synchronise (by
polling a method or subscribing to an event) with a peer if he wants to.

> Is this a correct interpretation? If so, what would we loose by introducing
> this simplification? Personally, I think we would not loose much, since
> Orocos' focus is on providing the minimal, flexible infrastructure to allow
> inter-component cooperation, and trying to guarantee some form of Command
> coordination is too difficult in the case where components are really
> distributed over a network with unreliable communication...

Yes, this approach will also reduce the from-and-back calling behind the
scenes.

>
> Any comments on this?
>
> > * UML 2.0 state machine script integration using Lua: Markus Klotzbucher
> > proposes a way to define UML 2.0 state machines in Orocos, which are
> > described in the Lua language
>
> I would not make the decision yet to move to Lua! Let's first study this
> alternative in a bit more technical detail, certainly with respect to the
> realtime safeness of Lua...

Study == TDD (aka 'Meten is Weten', 'to measure is to know')

>
> > 3. Which is missing, what had you hoped that RTT 2.0 would solve/improve
> > ? 5. Which tooling do you miss most when working with the RTT (give an
> > example of existing tools in other frameworks if possible)
>
> I don't know whether this is RTT's responsibility, but a (portable) GUI
> interface to the reporting and the online browsing would be very useful...
> Examples: the CLAM project has a "RTT-like" C++ framwork for the functional
> infrastructure of working with data and event flows (focused on audio, but
> the code base is not really depending on the kind of data!), and combines
> it with a graphical programming environment from which a GUI can be
> compiled. Some screenshots are here:
> <http://clam-project.org/screenshots.html>
> The concept and design are nice, but I would prefer to hook into a
> framework that has more international traction (such as "something" from
> the Eclipse or Apache ecosystems...)

Yes, it's lacking tool #1.

Peter

Important notice for existing Real-Time Toolkit users

Submitted by bruyninc on Tue, 2009-04-21 08:20.

On Tue, 21 Apr 2009, Peter Soetens wrote:

> On Thursday 09 April 2009 11:55:27 Herman Bruyninckx wrote:
>> On Thu, 9 Apr 2009, Peter Soetens wrote:
>> [...]
>>> The proposed major work packages are:
>> [...]
>>> * Method/Event/Command simplification: Peter Soetens proposed to offer a
>>> simpler 'Message' primitive instead of Command and unify Method and
>>> Message with the Event interface and on the CORBA interface. This
>>> simplifies the Orocos client/server aka request/reply model for component
>>> communication.
>> I think that what this simplification would bring is the following:
>> - to remove the overhead of having to keep 'state' information about a
>> Command execution in both components involved (the one calling the
>> Command and the one servicing the Command).
>
> Exactly.
>
>> - to shift this "Coordination" burden to the content of both components.
>
> I'm not sure I get that point, but it is indeed 'shifted' and mainly:
> make explicit. Commands now have implicit synchronisation when done in
> scripting. This is removed and the user must explicitly synchronise (by
> polling a method or subscribing to an event) with a peer if he wants to.

That was more or less what I wanted to say under the "Coordination" issue :-)

>> Is this a correct interpretation? If so, what would we loose by introducing
>> this simplification? Personally, I think we would not loose much, since
>> Orocos' focus is on providing the minimal, flexible infrastructure to allow
>> inter-component cooperation, and trying to guarantee some form of Command
>> coordination is too difficult in the case where components are really
>> distributed over a network with unreliable communication...
>
> Yes, this approach will also reduce the from-and-back calling behind the
> scenes.

>> Any comments on this?
>>> * UML 2.0 state machine script integration using Lua: Markus Klotzbucher
>>> proposes a way to define UML 2.0 state machines in Orocos, which are
>>> described in the Lua language
>> I would not make the decision yet to move to Lua! Let's first study this
>> alternative in a bit more technical detail, certainly with respect to the
>> realtime safeness of Lua...
>
> Study == TDD (aka 'Meten is Weten', 'to measure is to know')
>
>>
>>> 3. Which is missing, what had you hoped that RTT 2.0 would solve/improve
>>> ? 5. Which tooling do you miss most when working with the RTT (give an
>>> example of existing tools in other frameworks if possible)
>>
>> I don't know whether this is RTT's responsibility, but a (portable) GUI
>> interface to the reporting and the online browsing would be very useful...
>> Examples: the CLAM project has a "RTT-like" C++ framwork for the functional
>> infrastructure of working with data and event flows (focused on audio, but
>> the code base is not really depending on the kind of data!), and combines
>> it with a graphical programming environment from which a GUI can be
>> compiled. Some screenshots are here:
>> <http://clam-project.org/screenshots.html>
>> The concept and design are nice, but I would prefer to hook into a
>> framework that has more international traction (such as "something" from
>> the Eclipse or Apache ecosystems...)
>
> Yes, it's lacking tool #1.

>
> Peter

Herman

Important notice for existing Real-Time Toolkit users

Submitted by markus.klotzbuecher on Thu, 2009-04-09 21:40.

On Thu, Apr 09, 2009 at 11:55:27AM +0200, Herman Bruyninckx wrote:
> On Thu, 9 Apr 2009, Peter Soetens wrote:

> > * UML 2.0 state machine script integration using Lua: Markus Klotzbucher
> > proposes a way to define UML 2.0 state machines in Orocos, which are described
> > in the Lua language
>
> I would not make the decision yet to move to Lua! Let's first study this
> alternative in a bit more technical detail, certainly with respect to the
> realtime safeness of Lua...

Yes, before using Lua for anything real-time it certainly needs more
investigation. Still, even if it turned out to be completly useless
for this matter (which I don't believe, of course) I am conviced the
RTT would still very much benefit from such an extension language:

1) For loading/parsing/setting up a pure C/C++ FSM
2) For doing advanced configuration
3) As a scriptable taskbrowser
4) As a component prototyping language
5) For avoiding C++ for the large part of applications which are _not_
hard real-time
...

Of course there are other scripting languages which could serve a
similar purpose, e.g. Emacs Lisp, ...

Best regards
Markus