>
>> 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.
>
>
> 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.
Nice summary.
>
>
>> 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.
Adolfo
>
> Cheers,
>>
>> Adolfo.
>>
>
>
(text/plain)