Hi all,
I have 3 tasks called Task1, Task2 and Task3. I would like task 1 to have a periodic activity (say 50Hz), and tasks 2 and 3 to be updated right after Task1::update() finishes.
I could use FBSched to get several tasks executed in a row (on the same thread).
But what I want is to have Task2 and Task3 update in parallel (check my scheme below).
Example control scheme
I can see 2 different configurations (which are equivalent to me):
A) Task1 and Task2 run serially on Thread1 via FBSched and Task3 runs on another thread Thread2
-> Task3 needs to be synchronised to Task1
B) All 3 tasks run on different threads
-> Task2 and Task3 need to be synchronised to Task1
I am not too sure which setup to use in order to achieve the task synchro (in either of these configs).
Let's say I try to setup config B). I was thinking of using event ports to wake Task2 and Task3 up on Task1's update completion. But then my question is: will the activation of Task2 and Task3 be fast and deterministic (ie: do I keep the realtime-ness)?
I ask this question because from what I understand of orocos, the events received by Task2 and Task3 are queued in their respective ExecutionEngines on reception (this is RT). But I am not sure when the ExecutionEngine is stepped (ie when it is awakened). Is it straight away after the event is queued (in which case the setup keeps realtime-ness) or is it stepped at another moment (potentially breaking RT)?
I have tried to read all I could about this but I could not find the answer...
Thanks,
Antoine.
Larger image
Here is the image
Larger version
Sequential divergence synchro / event input processing
On Fri, Aug 28, 2015 at 6:21 PM, <antoine [dot] rennuit [..] ...>
wrote:
> Hi all,
>
> I have 3 tasks called Task1, Task2 and Task3. I would like task 1 to have a
> periodic activity (say 50Hz), and tasks 2 and 3 to be updated right after
> Task1::update() finishes.
>
> I could use FBSched to get several tasks executed in a row (on the same
> thread).
>
> But what I want is to have Task2 and Task3 update in parallel (check my
> scheme below).
>
> [img_assist|nid=5343|title=Example control
> scheme|desc=|link=none|align=center|width=200|height=112]
>
For completeness, link to forum post:
http://www.orocos.org/forum/orocos/orocos-users/sequential-divergence-sy...
The image is not shown in the email message.
> I can see 2 different configurations (which are equivalent to me):
> A) Task1 and Task2 run serially on Thread1 via FBSched and Task3 runs
> on
> another thread Thread2
> -> Task3 needs to be synchronised to Task1
> B) All 3 tasks run on different threads
> -> Task2 and Task3 need to be synchronised to Task1
>
> I am not too sure which setup to use in order to achieve the task synchro
> (in
> either of these configs).
>
> Let's say I try to setup config B). I was thinking of using event ports to
> wake Task2 and Task3 up on Task1's update completion. But then my question
> is: will the activation of Task2 and Task3 be fast and deterministic (ie:
> do
> I keep the realtime-ness)?
>
> I ask this question because from what I understand of orocos, the events
> received by Task2 and Task3 are queued in their respective ExecutionEngines
> on reception (this is RT). But I am not sure when the ExecutionEngine is
> stepped (ie when it is awakened). Is it straight away after the event is
> queued (in which case the setup keeps realtime-ness) or is it stepped at
> another moment (potentially breaking RT)?
>
Using event ports will not break real-time constraints. Your components
should update() (or any other callback that you might have registered) when
new data arrives to the port.
Adolfo.
> I have tried to read all I could about this but I could not find the
> answer...
>
> Thanks,
>
> Antoine.
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
Sequential divergence synchro / event input processing
Hello Adolfo,
Thanks for your reply.
From what I understand crossing your answer and other readings, the component awakening mecanism on event is RT but there is a minor overhead associated to it (for the thread awakening I guess).
Does this mean that when using strictly sequential activities FBSched should be used (in order to reduce scheduling latencies - as stated in the FBSched doc https://github.com/kmarkus/fbsched) and when more complex control architectures are expected (like the one in the above scheme) the event awakening mecanism can be used?
Basically the component awakening on event has a small overhead but allows more complex architectures, is that right?
Thanks,
Antoine.