Sequential divergence synchro / event input processing

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 schemeExample 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 imageLarger versionLarger 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.