How to share an activity among different components

I have three components: a CAN component a motor driver component and a
control component

What I want to do is have all of them using the same activity (periodic)
but have the guarantee that the different updateHook will be called in
the following order:

CAN
motor driver
controller

I had the idea that it should be doable using slave activities or child
execution engines, but I really have no clue as to exactly how. It seems
that what I would like to have is a slaveactivity that gets execute()'d
automatically by its master.

Infos ?

Thanks

How to share an activity among different components

On Apr 20, 2011, at 08:05 , Sylvain Joyeux wrote:

> I have three components: a CAN component a motor driver component and a
> control component
>
> What I want to do is have all of them using the same activity (periodic)
> but have the guarantee that the different updateHook will be called in
> the following order:
>
> CAN
> motor driver
> controller
>
> I had the idea that it should be doable using slave activities or child
> execution engines, but I really have no clue as to exactly how. It seems
> that what I would like to have is a slaveactivity that gets execute()'d
> automatically by its master.
>
> Infos ?

This is how we "coordinate" this in v1 ... I suspect similar will work in v2.

Add a Coordinator component, that is the master, with a (periodic) activity
Make the 3 existing components slaves of the Coordinator, with slave activities
At least with the deployer and XML files, we had to ensure that the Coordinator is created first and lists all the slave components as peers. I don't remember why.
A state machine in the Coordinator has a state that does something like the following

   state WORK
 {
          entry
              {
                  try Component1.start()
                     try Component2.start()
                     try Component3.start()
             }
          run
                {
                  if Component1.isRunning() then do Component1.update()
                      if Component2.isRunning() then do Component2.update()
                      if Component3.isRunning() then do Component3.update()
              }
          exit
               {
                  do Component3.stop()
                       do Component2.stop()
                       do Component1.stop()
               }
          ...
        }



Caveats
- you can't check whether the components actually started or not (in the entry() func), as there's a known bug (ticket already exists for this, not sure if it got fixed or not)
- for some reason that I don't recall, we ended up using the isRunning() check in the run loop

This is the only way we ever got this to work ... I'd love to know if there's an easier/better way ...
S

How to share an activity among different components

On 04/20/2011 02:18 PM, S Roderick wrote:
> Caveats
> - you can't check whether the components actually started or not (in the entry() func), as there's a known bug (ticket already exists for this, not sure if it got fixed or not)
> - for some reason that I don't recall, we ended up using the isRunning() check in the run loop
>
> This is the only way we ever got this to work ... I'd love to know if there's an easier/better way ...
I actually was looking for a special kind of activity. I was really
looking for something in which the components are kept decoupled. It is
just that they would share the same activity (something no component
needs to know).

How to share an activity among different components

On Apr 20, 2011, at 09:11 , Sylvain Joyeux wrote:

> On 04/20/2011 02:18 PM, S Roderick wrote:
>> Caveats
>> - you can't check whether the components actually started or not (in the entry() func), as there's a known bug (ticket already exists for this, not sure if it got fixed or not)
>> - for some reason that I don't recall, we ended up using the isRunning() check in the run loop
>>
>> This is the only way we ever got this to work ... I'd love to know if there's an easier/better way ...
> I actually was looking for a special kind of activity. I was really looking for something in which the components are kept decoupled. It is just that they would share the same activity (something no component needs to know).

How are you wanting to decouple them further, if you already have a known execution order? Something has to encode that knowledge somewhere ... In my solution, the only thing that knows about the components is the Coordinator, which is where that knowledge lives. The components themselves are unaware of anyone or anything else.
S

How to share an activity among different components

On 04/20/2011 03:15 PM, Stephen Roderick wrote:
> On Apr 20, 2011, at 09:11 , Sylvain Joyeux wrote:
>
>> On 04/20/2011 02:18 PM, S Roderick wrote:
>>> Caveats
>>> - you can't check whether the components actually started or not (in the entry() func), as there's a known bug (ticket already exists for this, not sure if it got fixed or not)
>>> - for some reason that I don't recall, we ended up using the isRunning() check in the run loop
>>>
>>> This is the only way we ever got this to work ... I'd love to know if there's an easier/better way ...
>> I actually was looking for a special kind of activity. I was really looking for something in which the components are kept decoupled. It is just that they would share the same activity (something no component needs to know).
>
> How are you wanting to decouple them further, if you already have a known execution order? Something has to encode that knowledge somewhere ... In my solution, the only thing that knows about the components is the Coordinator, which is where that knowledge lives. The components themselves are unaware of anyone or anything else.
Well, the execution order (in my case) is a matter of scheduling (it is
better for the overall behaviour), not component functionality.

So, yes, I thought of having an activity or another mechanism that would
allow me to deploy my tasks the way I wanted to (without writing a
specific component).

How to share an activity among different components

On Apr 20, 2011, at 10:24 , Sylvain Joyeux wrote:

> On 04/20/2011 03:15 PM, Stephen Roderick wrote:
>> On Apr 20, 2011, at 09:11 , Sylvain Joyeux wrote:
>>
>>> On 04/20/2011 02:18 PM, S Roderick wrote:
>>>> Caveats
>>>> - you can't check whether the components actually started or not (in the entry() func), as there's a known bug (ticket already exists for this, not sure if it got fixed or not)
>>>> - for some reason that I don't recall, we ended up using the isRunning() check in the run loop
>>>>
>>>> This is the only way we ever got this to work ... I'd love to know if there's an easier/better way ...
>>> I actually was looking for a special kind of activity. I was really looking for something in which the components are kept decoupled. It is just that they would share the same activity (something no component needs to know).
>>
>> How are you wanting to decouple them further, if you already have a known execution order? Something has to encode that knowledge somewhere ... In my solution, the only thing that knows about the components is the Coordinator, which is where that knowledge lives. The components themselves are unaware of anyone or anything else.
> Well, the execution order (in my case) is a matter of scheduling (it is better for the overall behaviour), not component functionality.
>
> So, yes, I thought of having an activity or another mechanism that would allow me to deploy my tasks the way I wanted to (without writing a specific component).

Hang on, who decides the scheduling? Isn't that something like the Coordinator component I referred to? Someone, somewhere, has the knowledge encoded ...
S

How to share an activity among different components

On 04/20/2011 04:50 PM, Stephen Roderick wrote:
> On Apr 20, 2011, at 10:24 , Sylvain Joyeux wrote:
>
>> On 04/20/2011 03:15 PM, Stephen Roderick wrote:
>>> On Apr 20, 2011, at 09:11 , Sylvain Joyeux wrote:
>>>
>>>> On 04/20/2011 02:18 PM, S Roderick wrote:
>>>>> Caveats
>>>>> - you can't check whether the components actually started or not (in the entry() func), as there's a known bug (ticket already exists for this, not sure if it got fixed or not)
>>>>> - for some reason that I don't recall, we ended up using the isRunning() check in the run loop
>>>>>
>>>>> This is the only way we ever got this to work ... I'd love to know if there's an easier/better way ...
>>>> I actually was looking for a special kind of activity. I was really looking for something in which the components are kept decoupled. It is just that they would share the same activity (something no component needs to know).
>>>
>>> How are you wanting to decouple them further, if you already have a known execution order? Something has to encode that knowledge somewhere ... In my solution, the only thing that knows about the components is the Coordinator, which is where that knowledge lives. The components themselves are unaware of anyone or anything else.
>> Well, the execution order (in my case) is a matter of scheduling (it is better for the overall behaviour), not component functionality.
>>
>> So, yes, I thought of having an activity or another mechanism that would allow me to deploy my tasks the way I wanted to (without writing a specific component).
>
> Hang on, who decides the scheduling? Isn't that something like the Coordinator component I referred to? Someone, somewhere, has the knowledge encoded ...
Yes. Except that this scheduling is static and is designed by the system
deployer (in this case, me). I just don't want to introduce a component
in the middle just to do that.

To get generic, I would like something that exists in RT systems for a
while: an activity in which components are given a place and a period
(the period being an integral number of times the "master" period)

Maybe I'll write that, actually ...

How to share an activity among different components

On Apr 20, 2011, at 11:02 , Sylvain Joyeux wrote:

> On 04/20/2011 04:50 PM, Stephen Roderick wrote:
>> On Apr 20, 2011, at 10:24 , Sylvain Joyeux wrote:
>>
>>> On 04/20/2011 03:15 PM, Stephen Roderick wrote:
>>>> On Apr 20, 2011, at 09:11 , Sylvain Joyeux wrote:
>>>>
>>>>> On 04/20/2011 02:18 PM, S Roderick wrote:
>>>>>> Caveats
>>>>>> - you can't check whether the components actually started or not (in the entry() func), as there's a known bug (ticket already exists for this, not sure if it got fixed or not)
>>>>>> - for some reason that I don't recall, we ended up using the isRunning() check in the run loop
>>>>>>
>>>>>> This is the only way we ever got this to work ... I'd love to know if there's an easier/better way ...
>>>>> I actually was looking for a special kind of activity. I was really looking for something in which the components are kept decoupled. It is just that they would share the same activity (something no component needs to know).
>>>>
>>>> How are you wanting to decouple them further, if you already have a known execution order? Something has to encode that knowledge somewhere ... In my solution, the only thing that knows about the components is the Coordinator, which is where that knowledge lives. The components themselves are unaware of anyone or anything else.
>>> Well, the execution order (in my case) is a matter of scheduling (it is better for the overall behaviour), not component functionality.
>>>
>>> So, yes, I thought of having an activity or another mechanism that would allow me to deploy my tasks the way I wanted to (without writing a specific component).
>>
>> Hang on, who decides the scheduling? Isn't that something like the Coordinator component I referred to? Someone, somewhere, has the knowledge encoded ...
> Yes. Except that this scheduling is static and is designed by the system deployer (in this case, me). I just don't want to introduce a component in the middle just to do that.
>
> To get generic, I would like something that exists in RT systems for a while: an activity in which components are given a place and a period (the period being an integral number of times the "master" period)
>
> Maybe I'll write that, actually ...

So an activity that isn't coupled to a component ... ok. But won't you end up encoding in that entity (somehow) the execution order you are interested in? For more than the most trivial cases, isn't that heading back in the direction of a statemachine ... which leads to a component ... which puts you back where we are now?

Also, I don't get what you mean with "integral number of times the master period". Are you trying to schedule components to not run every cycle of the master, or is this your intended way to cycle between multiple components (e.g set A on every 4th cycle from 1 = 1,5,9, B every 4th from 2 = 2,6,10, etc leading to a sequence of A,B,C,D,A,B,C,D on cycles of the master)?
S

How to share an activity among different components

On 04/20/2011 05:12 PM, Stephen Roderick wrote:
> So an activity that isn't coupled to a component ... ok. But won't you end up encoding in that entity (somehow) the execution order you are interested in? For more than the most trivial cases, isn't that heading back in the direction of a statemachine ... which leads to a component ... which puts you back where we are now?
Yes, in general, I can implement my use case in a state machine in a
coordination component. Now, as always, it is also a matter of
reusability (there are quite a few use cases for something like that)
and I personally feel that it is more part of the "activity" semantic
than of the "component" semantic.

Moreover, using a component for that has the drawback that the
underlying components become dependent on this coordination component,
i.e. you can't run them separately anymore (i.e. you can't start/stop
them separately). I'm not saying it is bad, but it's something I'd like
to avoid.

> Also, I don't get what you mean with "integral number of times the master period". Are you trying to schedule components to not run every cycle of the master, or is this your intended way to cycle between multiple components (e.g set A on every 4th cycle from 1 = 1,5,9, B every 4th from 2 = 2,6,10, etc leading to a sequence of A,B,C,D,A,B,C,D on cycles of the master)?
I have the feeling that the second option you are offering is a more
general case of the first. So let's say I would go for the second option.

Here's the thing: it is "a pattern". That you put this pattern in a
component or in an activity class does not really matter, as it is meant
to be used as-is (i.e. configured and then running transparently). I
just want

* an implementation of a scheme like this
* extend the orogen deployment spec to make this scheme easily usable

I was asking on the ML as I was wondering if such a patter already
existed or not. It seems not ;-)

How to share an activity among different components

On Apr 20, 2011, at 11:35 , Sylvain Joyeux wrote:

> On 04/20/2011 05:12 PM, Stephen Roderick wrote:
>> So an activity that isn't coupled to a component ... ok. But won't you end up encoding in that entity (somehow) the execution order you are interested in? For more than the most trivial cases, isn't that heading back in the direction of a statemachine ... which leads to a component ... which puts you back where we are now?
> Yes, in general, I can implement my use case in a state machine in a coordination component. Now, as always, it is also a matter of reusability (there are quite a few use cases for something like that) and I personally feel that it is more part of the "activity" semantic than of the "component" semantic.
>
> Moreover, using a component for that has the drawback that the underlying components become dependent on this coordination component, i.e. you can't run them separately anymore (i.e. you can't start/stop them separately). I'm not saying it is bad, but it's something I'd like to avoid.

I don't get this bit. The component implementation isn't affected by its use by a Coordinator component, so I presume you are referring to being unable to use the component in both a master/slave activity, as well as using it separately in some other manner (ie being able to independantly start/stop it)? If so, then we run into this sometimes. Sometimes we want the same component to be slave to one master at one time, and slave to another master at a different time.

>> Also, I don't get what you mean with "integral number of times the master period". Are you trying to schedule components to not run every cycle of the master, or is this your intended way to cycle between multiple components (e.g set A on every 4th cycle from 1 = 1,5,9, B every 4th from 2 = 2,6,10, etc leading to a sequence of A,B,C,D,A,B,C,D on cycles of the master)?
> I have the feeling that the second option you are offering is a more general case of the first. So let's say I would go for the second option.

I wasn't actually suggesting the second option, I was trying to understand what you were proposing. I wouldn't personally suggest that this option ...

> Here's the thing: it is "a pattern". That you put this pattern in a component or in an activity class does not really matter, as it is meant to be used as-is (i.e. configured and then running transparently). I just want
>
> * an implementation of a scheme like this
> * extend the orogen deployment spec to make this scheme easily usable
>
> I was asking on the ML as I was wondering if such a patter already existed or not. It seems not ;-)

Some of what you're talking about overlaps with issues we have, so I'm just trying to better understand what you're thinking of adding to RTT, in case we'd like to help out or slightly modify the approach.
S

How to share an activity among different components

On 04/20/2011 05:58 PM, Stephen Roderick wrote:
> On Apr 20, 2011, at 11:35 , Sylvain Joyeux wrote:
>
>> On 04/20/2011 05:12 PM, Stephen Roderick wrote:
>>> So an activity that isn't coupled to a component ... ok. But won't you end up encoding in that entity (somehow) the execution order you are interested in? For more than the most trivial cases, isn't that heading back in the direction of a statemachine ... which leads to a component ... which puts you back where we are now?
>> Yes, in general, I can implement my use case in a state machine in a coordination component. Now, as always, it is also a matter of reusability (there are quite a few use cases for something like that) and I personally feel that it is more part of the "activity" semantic than of the "component" semantic.
>>
>> Moreover, using a component for that has the drawback that the underlying components become dependent on this coordination component, i.e. you can't run them separately anymore (i.e. you can't start/stop them separately). I'm not saying it is bad, but it's something I'd like to avoid.
>
> I don't get this bit. The component implementation isn't affected by its use by a Coordinator component, so I presume you are referring to being unable to use the component in both a master/slave activity, as well as using it separately in some other manner (ie being able to independantly start/stop it)? If so, then we run into this sometimes. Sometimes we want the same component to be slave to one master at one time, and slave to another master at a different time.
When you say "different times", do you mean "during the same execution"
or "in different executions" ?

To repeat myself (because these days I have an even harder time making
myself clear, apologies for that). I don't think there is a fundamental
problem with the Coordinator component approach. It's just that it does
not fit the way we deploy systems right now, as you don't start/stop a
component by calling start/stop on it anymore, but by *first* starting a
"scheduling" component and *then* calling start/stop on it.

In principle, it is something I can encode in our supervision layer,
it's just that I feel it is adding more complexity to the system for no
added value, in the case where a simple "scheduling-like" activity is
enough. I.e. I would rather keep it at the activity level than at the
level of a full-blown component.

>>> Also, I don't get what you mean with "integral number of times the master period". Are you trying to schedule components to not run every cycle of the master, or is this your intended way to cycle between multiple components (e.g set A on every 4th cycle from 1 = 1,5,9, B every 4th from 2 = 2,6,10, etc leading to a sequence of A,B,C,D,A,B,C,D on cycles of the master)?
>> I have the feeling that the second option you are offering is a more general case of the first. So let's say I would go for the second option.
>
> I wasn't actually suggesting the second option, I was trying to understand what you were proposing. I wouldn't personally suggest that this option ...
Miswording from my part. I got your idea.

>> Here's the thing: it is "a pattern". That you put this pattern in a component or in an activity class does not really matter, as it is meant to be used as-is (i.e. configured and then running transparently). I just want
>>
>> * an implementation of a scheme like this
>> * extend the orogen deployment spec to make this scheme easily usable
>>
>> I was asking on the ML as I was wondering if such a patter already existed or not. It seems not ;-)
>
> Some of what you're talking about overlaps with issues we have, so I'm just trying to better understand what you're thinking of adding to RTT, in case we'd like to help out or slightly modify the approach.
Having a solution that fit all our needs would be good indeed :P

How to share an activity among different components

On Wed, 20 Apr 2011, Sylvain Joyeux wrote:

> On 04/20/2011 05:58 PM, Stephen Roderick wrote:
>> On Apr 20, 2011, at 11:35 , Sylvain Joyeux wrote:
>>
>>> On 04/20/2011 05:12 PM, Stephen Roderick wrote:
>>>> So an activity that isn't coupled to a component ... ok. But won't you end up encoding in that entity (somehow) the execution order you are interested in? For more than the most trivial cases, isn't that heading back in the direction of a statemachine ... which leads to a component ... which puts you back where we are now?
>>> Yes, in general, I can implement my use case in a state machine in a coordination component. Now, as always, it is also a matter of reusability (there are quite a few use cases for something like that) and I personally feel that it is more part of the "activity" semantic than of the "component" semantic.
>>>
>>> Moreover, using a component for that has the drawback that the underlying components become dependent on this coordination component, i.e. you can't run them separately anymore (i.e. you can't start/stop them separately). I'm not saying it is bad, but it's something I'd like to avoid.
>>
>> I don't get this bit. The component implementation isn't affected by its use by a Coordinator component, so I presume you are referring to being unable to use the component in both a master/slave activity, as well as using it separately in some other manner (ie being able to independantly start/stop it)? If so, then we run into this sometimes. Sometimes we want the same component to be slave to one master at one time, and slave to another master at a different time.
> When you say "different times", do you mean "during the same execution"
> or "in different executions" ?
>
> To repeat myself (because these days I have an even harder time making
> myself clear, apologies for that). I don't think there is a fundamental
> problem with the Coordinator component approach. It's just that it does
> not fit the way we deploy systems right now, as you don't start/stop a
> component by calling start/stop on it anymore, but by *first* starting a
> "scheduling" component and *then* calling start/stop on it.
>
> In principle, it is something I can encode in our supervision layer,
> it's just that I feel it is adding more complexity to the system for no
> added value, in the case where a simple "scheduling-like" activity is
> enough. I.e. I would rather keep it at the activity level than at the
> level of a full-blown component.

My two cents... The "activity level" is concerned with the _physical
resources_ that your application is using, and should indeed be decoupled
from the _application_-level component Coordination. Nevertheless, also the
physical resources require Coordination; this Coordination, however, could
be done outside of the Orocos/RTT context, with other means. But it
_remains_ Coordination :-) (I sometimes call it the "Container" part of the
component model.)

>>>> Also, I don't get what you mean with "integral number of times the master period". Are you trying to schedule components to not run every cycle of the master, or is this your intended way to cycle between multiple components (e.g set A on every 4th cycle from 1 = 1,5,9, B every 4th from 2 = 2,6,10, etc leading to a sequence of A,B,C,D,A,B,C,D on cycles of the master)?
>>> I have the feeling that the second option you are offering is a more general case of the first. So let's say I would go for the second option.
>>
>> I wasn't actually suggesting the second option, I was trying to understand what you were proposing. I wouldn't personally suggest that this option ...
> Miswording from my part. I got your idea.
>
>>> Here's the thing: it is "a pattern". That you put this pattern in a component or in an activity class does not really matter, as it is meant to be used as-is (i.e. configured and then running transparently). I just want
>>>
>>> * an implementation of a scheme like this
>>> * extend the orogen deployment spec to make this scheme easily usable
>>>
>>> I was asking on the ML as I was wondering if such a patter already existed or not. It seems not ;-)
>>
>> Some of what you're talking about overlaps with issues we have, so I'm just trying to better understand what you're thinking of adding to RTT, in case we'd like to help out or slightly modify the approach.
> Having a solution that fit all our needs would be good indeed :P

Herman

How to share an activity among different components

On 04/21/2011 06:51 AM, Herman Bruyninckx wrote:
>> In principle, it is something I can encode in our supervision layer,
>> it's just that I feel it is adding more complexity to the system for no
>> added value, in the case where a simple "scheduling-like" activity is
>> enough. I.e. I would rather keep it at the activity level than at the
>> level of a full-blown component.
>
> My two cents... The "activity level" is concerned with the _physical
> resources_ that your application is using, and should indeed be decoupled
> from the _application_-level component Coordination. Nevertheless, also the
> physical resources require Coordination; this Coordination, however, could
> be done outside of the Orocos/RTT context, with other means. But it
> _remains_ Coordination :-) (I sometimes call it the "Container" part of the
> component model.)
I agree. The activity (or container, I actually like container much
better) is definitely of the overall coordination (and its choice is
part of the configuration of the coordination)

Sylvain

How to share an activity among different components

On Wed, 20 Apr 2011, S Roderick wrote:

> On Apr 20, 2011, at 08:05 , Sylvain Joyeux wrote:
>
>> I have three components: a CAN component a motor driver component and a
>> control component
>>
>> What I want to do is have all of them using the same activity (periodic)
>> but have the guarantee that the different updateHook will be called in
>> the following order:
>>
>> CAN
>> motor driver
>> controller
>>
>> I had the idea that it should be doable using slave activities or child
>> execution engines, but I really have no clue as to exactly how. It seems
>> that what I would like to have is a slaveactivity that gets execute()'d
>> automatically by its master.
>>
>> Infos ?
>
> This is how we "coordinate" this in v1 ... I suspect similar will work in v2.
>
> Add a Coordinator component, that is the master, with a (periodic) activity
> Make the 3 existing components slaves of the Coordinator, with slave activities
> At least with the deployer and XML files, we had to ensure that the Coordinator is created first and lists all the slave components as peers. I don't remember why.
> A state machine in the Coordinator has a state that does something like the following
> 
>       state WORK
>     {
>              entry
>          {
>                      try Component1.start()
>                         try Component2.start()
>                         try Component3.start()
>                 }
>              run
>            {
>                      if Component1.isRunning() then do Component1.update()
>                  if Component2.isRunning() then do Component2.update()
>                  if Component3.isRunning() then do Component3.update()
>          }
>              exit
>           {
>                      do Component3.stop()
>                   do Component2.stop()
>                   do Component1.stop()
>           }
>              ...
>    }
>
>
>
> Caveats
> - you can't check whether the components actually started or not (in the entry() func), as there's a known bug (ticket already exists for this, not sure if it got fixed or not)
> - for some reason that I don't recall, we ended up using the isRunning() check in the run loop
>
> This is the only way we ever got this to work ... I'd love to know if there's an easier/better way ...

I cannot improve on your design. The RTT tooling can be improved, to make
the support of such design simpler, of course.

> S

Herman

How to share an activity among different components

On Apr 20, 2011, at 08:43 , Herman Bruyninckx wrote:

> On Wed, 20 Apr 2011, S Roderick wrote:
>
>> On Apr 20, 2011, at 08:05 , Sylvain Joyeux wrote:
>>
>>> I have three components: a CAN component a motor driver component and a
>>> control component
>>>
>>> What I want to do is have all of them using the same activity (periodic)
>>> but have the guarantee that the different updateHook will be called in
>>> the following order:
>>>
>>> CAN
>>> motor driver
>>> controller
>>>
>>> I had the idea that it should be doable using slave activities or child
>>> execution engines, but I really have no clue as to exactly how. It seems
>>> that what I would like to have is a slaveactivity that gets execute()'d
>>> automatically by its master.
>>>
>>> Infos ?
>>
>> This is how we "coordinate" this in v1 ... I suspect similar will work in v2.
>>
>> Add a Coordinator component, that is the master, with a (periodic) activity
>> Make the 3 existing components slaves of the Coordinator, with slave activities
>> At least with the deployer and XML files, we had to ensure that the Coordinator is created first and lists all the slave components as peers. I don't remember why.
>> A state machine in the Coordinator has a state that does something like the following
>> 
>>   state WORK
>>         {
>>          entry
>>              {
>>                  try Component1.start()
>>                     try Component2.start()
>>                     try Component3.start()
>>             }
>>          run
>>                {
>>                  if Component1.isRunning() then do Component1.update()
>>                      if Component2.isRunning() then do Component2.update()
>>                      if Component3.isRunning() then do Component3.update()
>>              }
>>          exit
>>               {
>>                  do Component3.stop()
>>                       do Component2.stop()
>>                       do Component1.stop()
>>               }
>>          ...
>>        }
>> 
>>
>>
>> Caveats
>> - you can't check whether the components actually started or not (in the entry() func), as there's a known bug (ticket already exists for this, not sure if it got fixed or not)
>> - for some reason that I don't recall, we ended up using the isRunning() check in the run loop
>>
>> This is the only way we ever got this to work ... I'd love to know if there's an easier/better way ...
>
> I cannot improve on your design. The RTT tooling can be improved, to make
> the support of such design simpler, of course.

Agreed, I think the approach is fairly sound, but it would be nice if it wasn't quite as typing-involved ... still, it 'aint that bad!!

We also use the above to schedule multiple different components per state, which is incredbily useful for complex systems.
S

How to share an activity among different components

On Wed, 20 Apr 2011, Stephen Roderick wrote:

> On Apr 20, 2011, at 08:43 , Herman Bruyninckx wrote:
>
>> On Wed, 20 Apr 2011, S Roderick wrote:
>>
>>> On Apr 20, 2011, at 08:05 , Sylvain Joyeux wrote:
>>>
>>>> I have three components: a CAN component a motor driver component and a
>>>> control component
>>>>
>>>> What I want to do is have all of them using the same activity (periodic)
>>>> but have the guarantee that the different updateHook will be called in
>>>> the following order:
>>>>
>>>> CAN
>>>> motor driver
>>>> controller
>>>>
>>>> I had the idea that it should be doable using slave activities or child
>>>> execution engines, but I really have no clue as to exactly how. It seems
>>>> that what I would like to have is a slaveactivity that gets execute()'d
>>>> automatically by its master.
>>>>
>>>> Infos ?
>>>
>>> This is how we "coordinate" this in v1 ... I suspect similar will work in v2.
>>>
>>> Add a Coordinator component, that is the master, with a (periodic) activity
>>> Make the 3 existing components slaves of the Coordinator, with slave activities
>>> At least with the deployer and XML files, we had to ensure that the Coordinator is created first and lists all the slave components as peers. I don't remember why.
>>> A state machine in the Coordinator has a state that does something like the following
>>> 
>>>       state WORK
>>>     {
>>>              entry
>>>          {
>>>                      try Component1.start()
>>>                         try Component2.start()
>>>                         try Component3.start()
>>>                 }
>>>              run
>>>            {
>>>                      if Component1.isRunning() then do Component1.update()
>>>                  if Component2.isRunning() then do Component2.update()
>>>                  if Component3.isRunning() then do Component3.update()
>>>          }
>>>              exit
>>>           {
>>>                      do Component3.stop()
>>>                   do Component2.stop()
>>>                   do Component1.stop()
>>>           }
>>>              ...
>>>    }
>>>
>>>
>>>
>>> Caveats
>>> - you can't check whether the components actually started or not (in the entry() func), as there's a known bug (ticket already exists for this, not sure if it got fixed or not)
>>> - for some reason that I don't recall, we ended up using the isRunning() check in the run loop
>>>
>>> This is the only way we ever got this to work ... I'd love to know if there's an easier/better way ...
>>
>> I cannot improve on your design. The RTT tooling can be improved, to make
>> the support of such design simpler, of course.
>
> Agreed, I think the approach is fairly sound, but it would be nice if it
> wasn't quite as typing-involved ...

I fully agree. But that's "just" a matter of providing a "Domain Specific
Language" that hides most of the (repetitive) typing behind simple
"language primitives". Alternatively, we are now preparing a 'template'
architecture ("best practice pattern", whatever you want to call it), for
some commonly occurring problems. All this, I consider part of 'tool chain
support'.

> still, it 'aint that bad!!
>
> We also use the above to schedule multiple different components per
> state, which is incredbily useful for complex systems.

And this was to reason why we wanted this (admittedly, low level) primitive
so badly in RTT :-)

> S

Herman