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.

As Johnny 5 would say: iiiiinput ;-)


      Another way of looking at this problem is as follows: ROS/Orocos "force"
      developers to thing in the "component based" design paradigm in which all
      computations are in (hidden in) components and the data is flowing around
      in "publish/subscribe" topics; however,
      control functionalities have, since ages too already, best been done in a
      "functional programming" paradigm, where the data are shared, never copied,
      and certainly
      not streamed around between computations.

When different tasks are serialized in a single thread, connection policies that don't
handle concurrency can be used. In such cases data can be passed around as pointers or
references. Unfortunately ROS and Orocos don't yet do this for you. You could do it in
the manager, though, the information is there.

ROS and Orocos should not do this for us; a "Computational model" tool
should. And that tool should be independent of ROS or Orocos. Calling
something a "manager" is not really a good idea, since it invites people to
add any kind of functionality that other parts in the system can not deal
with in a good way. I am suggestion a design in which the "manager" is
doing the "Coordination & Configuration" of several new
complementary/decoupled responsibilities:
- timing port
- time interrupt handling: input to schedule function and to execution
  function
- scheduling function to compute the to-be-serially-executed computations
- execution of these computations
- shared data resource management (e.g., via an "immutable data" policy).
  This includes adding computations to the schedule for logging etc.

I see all of these already present in the material you provided, but I try
to add some structural design to couple them together in a configurable
way.

One further disclaimer: I'm aiming at having a prototype controller manager in about
six weeks, so I'm trying to make the best possible compromise between what's already
out there and what can be done in such a time frame. I won't achieve peace on earth,
but hopefully a solid step in the right direction.

I understand, of course, that incremental developments make sense. But can
you explain what parts of your suggestion you consider to be "solid", and
which ones are "to be thrown away"? Because we should agree on the solid
parts, in order not to waste time on temporary stuff.

What I consider "solid" are the suggestions to develop a "computational
model" tool, including the above-mentioned functions and data structures to
be implemented inside a ROS node or Orocos component (without depending on
ROS or Orocos). We have work going on in this direction.

Cheers,

Adolfo.