On Tue, 29 Jan 2013, Adolfo Rodríguez Tsouroukdissian wrote:

            The solution proposed in [1] (see original post for link) uses
            a plugin mechanism for
            implementing controllers, which enforces single-threaded
            execution and passing data by
            pointers. It just does not allow the use case of clients
            running with different update
            policies (lower frequency, non-periodic triggering). How would
            you go about this?.

Add a timer input port to your component, and let the _scheduling_ be done
by the function you attach to that port.

Ah, yes, you got me there. A timer that triggers callbacks allows to keep a
plugin-based approach with all controllers serialized in a single thread, yet also
allows to have different duty cycles. Thanks for sticking my head out of the component
mindset here.

If that is the result of my "ranting", I am very happy!

Because I have
learned that a real roboticist _has_ to work within several "paradigms",
and the component-based paradigm is only one of them :-) What I just
brought to your attention is from the "operating system paradigm", which
you are very probably familiar with; that paradigm "conforms to" the more
generic one of "shared resource management".

I am interested in learning
whether there is het another "meta"-level on top of that :-)

Good, keep us posted! We happen to be doing the same thing in house the
last week(s)... More difficult than I thought at the beginning to get it
"right" _and_ "reusable" in more contexts than just this one of controller
management.

More of this will be discussed at the "MDE for robotics" workshop at the
upcoming European Robotics Forum in Lyon, on March 20th.

Adolfo

Herman