<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The solution proposed in [1] (see original post for link) uses a plugin mechanism for<br>
implementing controllers, which enforces single-threaded execution and passing data by<br>
pointers. It just does not allow the use case of clients running with different update<br>
policies (lower frequency, non-periodic triggering). How would you go about this?.<br>
</blockquote>
<br></div>
Add a timer input port to your component, and let the _scheduling_ be done<br>
by the function you attach to that port.</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As Johnny 5 would say: iiiiinput ;-)<br>
<br>
<br>
Another way of looking at this problem is as follows: ROS/Orocos "force"<br>
developers to thing in the "component based" design paradigm in which all<br>
computations are in (hidden in) components and the data is flowing around<br>
in "publish/subscribe" topics; however,<br>
control functionalities have, since ages too already, best been done in a<br>
"functional programming" paradigm, where the data are shared, never copied,<br>
and certainly<br>
not streamed around between computations.<br>
<br>
When different tasks are serialized in a single thread, connection policies that don't<br>
handle concurrency can be used. In such cases data can be passed around as pointers or<br>
references. Unfortunately ROS and Orocos don't yet do this for you. You could do it in<br>
the manager, though, the information is there.<br>
</blockquote>
<br></div>
ROS and Orocos should not do this for us; a "Computational model" tool<br>
should. And that tool should be independent of ROS or Orocos. Calling<br>
something a "manager" is not really a good idea, since it invites people to<br>
add any kind of functionality that other parts in the system can not deal<br>
with in a good way. I am suggestion a design in which the "manager" is<br>
doing the "Coordination & Configuration" of several new<br>
complementary/decoupled responsibilities:<br>
- timing port<br>
- time interrupt handling: input to schedule function and to execution<br>
function<br>
- scheduling function to compute the to-be-serially-executed computations<br>
- execution of these computations<br>
- shared data resource management (e.g., via an "immutable data" policy).<br>
This includes adding computations to the schedule for logging etc.<br>
<br>
I see all of these already present in the material you provided, but I try<br>
to add some structural design to couple them together in a configurable<br>
way.</blockquote><div><br>Nice summary.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
One further disclaimer: I'm aiming at having a prototype controller manager in about<br>
six weeks, so I'm trying to make the best possible compromise between what's already<br>
out there and what can be done in such a time frame. I won't achieve peace on earth,<br>
but hopefully a solid step in the right direction.<br>
</blockquote>
<br></div></div>
I understand, of course, that incremental developments make sense. But can<br>
you explain what parts of your suggestion you consider to be "solid", and<br>
which ones are "to be thrown away"? Because we should agree on the solid<br>
parts, in order not to waste time on temporary stuff.<br>
<br>
What I consider "solid" are the suggestions to develop a "computational<br>
model" tool, including the above-mentioned functions and data structures to<br>
be implemented inside a ROS node or Orocos component (without depending on<br>
ROS or Orocos). We have work going on in this direction.<br></blockquote><div><br>Agreed. Let's focus on that. More on the next post.<br><br>Adolfo<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<br>
<br>
Adolfo.<span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
</font></span></blockquote></div><br><br>