[ros-users] [Orocos-users] Joint controller manager

[Herman Bruyninckx]

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 :-)

>             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.

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.

> Nice summary.

Thanks!

>             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.
> 
> Agreed. Let's focus on that. More on the next post.

Thanks!

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