[OROCOSUSERS] Operation returns Vector of string - runs more than 1 Time

Hi,

Today I got a strange issue, and I think it is not my mistake since I
created it from scratch with a clean code.
Now I want to create a service plugin with an operation which will return a
vector of string.
after finishing the code I used it and the service working, and returning
the vector correctly but what I found after enabling the log is strange.
The log lines is printed more than one time however I called the operation
only one time.

my code is

```
std::vector<std::string> testOP();
//...

this->addOperation("runTestOP", &testOP, this).doc("");
//...

std::vector<std::string> testOP()
{
RTT::log(RTT::Debug) << "Hi I am test OP" << RTT::endlog();
return getOwner()->getPeerList();
}
```

my script is

```
loadService ("Deployer", "myService")
import("MyComponent")
loadComponent("Component1", "MyComponent")
loadComponent("Component1", "MyComponent")
```

from terminal

```
deployer -s script.ops -ldebug
..
Deployer [S]> myService.runTestOP
7.867 [ Debug ][Logger] Hi I am test OP
7.868 [ Debug ][Logger] Hi I am test OP
7.868 [ Debug ][Logger] Hi I am test OP
7.868 [ Debug ][Logger] Hi I am test OP
7.868 [ Debug ][Logger] Hi I am test OP
7.868 [ Debug ][Logger] Hi I am test OP
7.868 [ Debug ][Logger] Hi I am test OP
7.868 [ Debug ][Logger] Hi I am test OP
7.868 [ Debug ][Logger] Hi I am test OP
7.868 [ Debug ][Logger] Hi I am test OP
= { [camera1, camera2 ], size = 2, capacity = 2 }

```

What is wrong with my code? Please if there is anything I can provide more
let me know.

Aladdin

[OROCOSUSERS] Operation returns Vector of string - runs more tha

Hi,

I quickly made a simple test where the operation has a vector output (Here
<https://github.com/keivanzavari/operations_test>).

I am able to reproduce the concept. Seems that the logger is called more
times than the function/operation itself. It gets called 8 times (both info
& debug)...
Don't think it's a problem, probably more of a policy. But the developers
have to verify this.

Regards
Keivan

On 3 August 2016 at 10:37, AlaaEldeen, AbdAlrahman <
alaaeldeen [dot] abdalrahman [..] ...> wrote:

> Hi,
>
> Today I got a strange issue, and I think it is not my mistake since I
> created it from scratch with a clean code.
> Now I want to create a service plugin with an operation which will return
> a vector of string.
> after finishing the code I used it and the service working, and returning
> the vector correctly but what I found after enabling the log is strange.
> The log lines is printed more than one time however I called the operation
> only one time.
>
> my code is
>
> ```
> std::vector<std::string> testOP();
> //...
>
> this->addOperation("runTestOP", &testOP, this).doc("");
> //...
>
> std::vector<std::string> testOP()
> {
> RTT::log(RTT::Debug) << "Hi I am test OP" << RTT::endlog();
> return getOwner()->getPeerList();
> }
> ```
>
> my script is
>
> ```
> loadService ("Deployer", "myService")
> import("MyComponent")
> loadComponent("Component1", "MyComponent")
> loadComponent("Component1", "MyComponent")
> ```
>
> from terminal
>
> ```
> deployer -s script.ops -ldebug
> ..
> Deployer [S]> myService.runTestOP
> 7.867 [ Debug ][Logger] Hi I am test OP
> 7.868 [ Debug ][Logger] Hi I am test OP
> 7.868 [ Debug ][Logger] Hi I am test OP
> 7.868 [ Debug ][Logger] Hi I am test OP
> 7.868 [ Debug ][Logger] Hi I am test OP
> 7.868 [ Debug ][Logger] Hi I am test OP
> 7.868 [ Debug ][Logger] Hi I am test OP
> 7.868 [ Debug ][Logger] Hi I am test OP
> 7.868 [ Debug ][Logger] Hi I am test OP
> 7.868 [ Debug ][Logger] Hi I am test OP
> = { [camera1, camera2 ], size = 2, capacity = 2 }
>
> ```
>
> What is wrong with my code? Please if there is anything I can provide more
> let me know.
>
> Aladdin
>
>

[OROCOSUSERS] Operation returns Vector of string - runs more tha

Hi Aladdin and Keivan,

thanks for your report and the test case implementation.

It is definitely not the desired behavior that the operation is called more
than once, but it is "only" the OCL TaskBrowser or the underlying
FusedMCallDataSource class which suffer from this issue and not a general
problem with the operations implementation. If you would call the operation
from a script or from C++, it only executes once, as expected.

The same issue has already been reported with two backtraces at different
stages of the operation call in https://github.com/orocos-
toolchain/rtt/issues/108, but without mentioning many details.
Unfortunately there was no time to work on a solution yet.

Regards,
Johannes

On Thu, Aug 4, 2016 at 9:33 AM, Keivan Zavari <keivan [dot] zavari [..] ...>
wrote:

> Hi,
>
> I quickly made a simple test where the operation has a vector output (Here
> <https://github.com/keivanzavari/operations_test>).
>
> I am able to reproduce the concept. Seems that the logger is called more
> times than the function/operation itself. It gets called 8 times (both
> info & debug)...
> Don't think it's a problem, probably more of a policy. But the developers
> have to verify this.
>
> Regards
> Keivan
>
> On 3 August 2016 at 10:37, AlaaEldeen, AbdAlrahman <
> alaaeldeen [dot] abdalrahman [..] ...> wrote:
>
>> Hi,
>>
>> Today I got a strange issue, and I think it is not my mistake since I
>> created it from scratch with a clean code.
>> Now I want to create a service plugin with an operation which will return
>> a vector of string.
>> after finishing the code I used it and the service working, and returning
>> the vector correctly but what I found after enabling the log is strange.
>> The log lines is printed more than one time however I called the
>> operation only one time.
>>
>> my code is
>>
>> ```
>> std::vector<std::string> testOP();
>> //...
>>
>> this->addOperation("runTestOP", &testOP, this).doc("");
>> //...
>>
>> std::vector<std::string> testOP()
>> {
>> RTT::log(RTT::Debug) << "Hi I am test OP" << RTT::endlog();
>> return getOwner()->getPeerList();
>> }
>> ```
>>
>> my script is
>>
>> ```
>> loadService ("Deployer", "myService")
>> import("MyComponent")
>> loadComponent("Component1", "MyComponent")
>> loadComponent("Component1", "MyComponent")
>> ```
>>
>> from terminal
>>
>> ```
>> deployer -s script.ops -ldebug
>> ..
>> Deployer [S]> myService.runTestOP
>> 7.867 [ Debug ][Logger] Hi I am test OP
>> 7.868 [ Debug ][Logger] Hi I am test OP
>> 7.868 [ Debug ][Logger] Hi I am test OP
>> 7.868 [ Debug ][Logger] Hi I am test OP
>> 7.868 [ Debug ][Logger] Hi I am test OP
>> 7.868 [ Debug ][Logger] Hi I am test OP
>> 7.868 [ Debug ][Logger] Hi I am test OP
>> 7.868 [ Debug ][Logger] Hi I am test OP
>> 7.868 [ Debug ][Logger] Hi I am test OP
>> 7.868 [ Debug ][Logger] Hi I am test OP
>> = { [camera1, camera2 ], size = 2, capacity = 2 }
>>
>> ```
>>
>> What is wrong with my code? Please if there is anything I can provide
>> more let me know.
>>
>> Aladdin
>>
>>
>
>
> --
>
> Kind regards,
> Keivan Zavari
>
> Rue de Weert St. Georges 219
> 1390 Nethen
> Belgium
>
> Mob : *+32 489 001 206*
>

[OROCOSUSERS] Orchestration

Hi all,

I am putting in place an orchestrator component within my orocos network. This orchestrator is due to enable / disable (i.e. start / stop in orocos language) some parts of the network depending on a state machine (within the orchestrator component) - the state machine is a 3rd party (I am not using orocos state machines).

I have several questions related to the implementation details of my orchestrator:

1. My state machine (within the orchestrator component) is supposed to react to user events, I was thinking to link my GUI and the orchestrator with operations (e.g. to transition from auto to manual mode when the user clicks on a button). Are the orocos operations the right mechanism to use in my case?
2. I need to implement 2 parallel components within a FBSched (they both output to the same 3rd component within the FBSched). They will never be running at the same time as one corresponds to the manual mode and the other one to the auto mode. I am not sure which mechanism I should use to be able to run these 2 parallel components in my FBSched. Any idea?

Thanks,

Antoine.

[OROCOSUSERS] Orchestration

On Wed, 10 Aug 2016, Antoine Rennuit wrote:

> Hi all,
>
> I am putting in place an orchestrator component within my orocos network. This orchestrator is
> due to enable / disable (i.e. start / stop in orocos language) some parts of the network
> depending on a state machine (within the orchestrator component) - the state machine is a 3rd
> party (I am not using orocos state machines).
>
> I have several questions related to the implementation details of my orchestrator:
>
> 1. My state machine (within the orchestrator component) is supposed to react to user events, I
> was thinking to link my GUI and the orchestrator with operations (e.g. to transition from
> auto to manual mode when the user clicks on a button). Are the orocos operations the right
> mechanism to use in my case?

I would decouple the GUI and the realtime part via a send-and-forget event communication
channel.

> 2. I need to implement 2 parallel components within a FBSched (they both output to the same 3rd
> component within the FBSched). They will never be running at the same time as one
> corresponds to the manual mode and the other one to the auto mode. I am not sure which
> mechanism I should use to be able to run these 2 parallel components in my FBSched. Any
> idea?

I would go for two _functions_ that are executed in a "scheduler"
_function_ instead of putting things in RTT components. Because from your
concise decription I see no arguments in favour of the RTT component overhead. Do you?
(Some remark holds for your first question.)

> Thanks,
>
> Antoine.

Herman

[OROCOSUSERS] Orchestration

Hi Herman,

Thanks for your answers.

For the answer on question 2, do you mean that the 2 functions would lie in a single component and simply being called depending on a "mode" property (or so)?

Cheers,

Antoine.

________________________________________
De : Orocos Users <OROCOSUSERS [..] ...> de la part de Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
Envoyé : mercredi 10 août 2016 17:57
À : OROCOSUSERS [..] ...
Objet : Re: [OROCOSUSERS] Orchestration

On Wed, 10 Aug 2016, Antoine Rennuit wrote:

> Hi all,
>
> I am putting in place an orchestrator component within my orocos network. This orchestrator is
> due to enable / disable (i.e. start / stop in orocos language) some parts of the network
> depending on a state machine (within the orchestrator component) - the state machine is a 3rd
> party (I am not using orocos state machines).
>
> I have several questions related to the implementation details of my orchestrator:
>
> 1. My state machine (within the orchestrator component) is supposed to react to user events, I
> was thinking to link my GUI and the orchestrator with operations (e.g. to transition from
> auto to manual mode when the user clicks on a button). Are the orocos operations the right
> mechanism to use in my case?

I would decouple the GUI and the realtime part via a send-and-forget event communication
channel.

> 2. I need to implement 2 parallel components within a FBSched (they both output to the same 3rd
> component within the FBSched). They will never be running at the same time as one
> corresponds to the manual mode and the other one to the auto mode. I am not sure which
> mechanism I should use to be able to run these 2 parallel components in my FBSched. Any
> idea?

I would go for two _functions_ that are executed in a "scheduler"
_function_ instead of putting things in RTT components. Because from your
concise decription I see no arguments in favour of the RTT component overhead. Do you?
(Some remark holds for your first question.)

> Thanks,
>
> Antoine.

Herman

[OROCOSUSERS] Orchestration

On Wed, 10 Aug 2016, Antoine Rennuit wrote:

> Hi Herman,
>
> Thanks for your answers.
>
> For the answer on question 2, do you mean that the 2 functions would lie
> in a single component and simply being called depending on a "mode"
> property (or so)?

Indeed. This is by far the best approach, if there are no urgent reasons to
run separate components.

> Cheers,
>
> Antoine.

Herman

> ________________________________________
> De : Orocos Users <OROCOSUSERS [..] ...> de la part de Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> Envoyé : mercredi 10 août 2016 17:57
> À : OROCOSUSERS [..] ...
> Objet : Re: [OROCOSUSERS] Orchestration
>
> On Wed, 10 Aug 2016, Antoine Rennuit wrote:
>
>> Hi all,
>>
>> I am putting in place an orchestrator component within my orocos network. This orchestrator is
>> due to enable / disable (i.e. start / stop in orocos language) some parts of the network
>> depending on a state machine (within the orchestrator component) - the state machine is a 3rd
>> party (I am not using orocos state machines).
>>
>> I have several questions related to the implementation details of my orchestrator:
>>
>> 1. My state machine (within the orchestrator component) is supposed to react to user events, I
>> was thinking to link my GUI and the orchestrator with operations (e.g. to transition from
>> auto to manual mode when the user clicks on a button). Are the orocos operations the right
>> mechanism to use in my case?
>
> I would decouple the GUI and the realtime part via a send-and-forget event communication
> channel.
>
>> 2. I need to implement 2 parallel components within a FBSched (they both output to the same 3rd
>> component within the FBSched). They will never be running at the same time as one
>> corresponds to the manual mode and the other one to the auto mode. I am not sure which
>> mechanism I should use to be able to run these 2 parallel components in my FBSched. Any
>> idea?
>
> I would go for two _functions_ that are executed in a "scheduler"
> _function_ instead of putting things in RTT components. Because from your
> concise decription I see no arguments in favour of the RTT component overhead. Do you?
> (Some remark holds for your first question.)
>
>> Thanks,
>>
>> Antoine.
>
> Herman

[OROCOSUSERS] Orchestration

> On Aug 10, 2016, at 12:35, Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> wrote:
>
> On Wed, 10 Aug 2016, Antoine Rennuit wrote:
>
>> Hi Herman,
>>
>> Thanks for your answers.
>>
>> For the answer on question 2, do you mean that the 2 functions would lie
>> in a single component and simply being called depending on a "mode"
>> property (or so)?
>
> Indeed. This is by far the best approach, if there are no urgent reasons to
> run separate components.

My only comment on this approach is that it does not scale. If you end up adding more motion modes, you will end up with an overly complex component. Obviously this isn’t an issue with two modes, but perhaps something to keep in mind.

HTH
S

>
>> Cheers,
>>
>> Antoine.
>
> Herman
>
>> ________________________________________
>> De : Orocos Users <OROCOSUSERS [..] ...> de la part de Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
>> Envoyé : mercredi 10 août 2016 17:57
>> À : OROCOSUSERS [..] ...
>> Objet : Re: [OROCOSUSERS] Orchestration
>>
>> On Wed, 10 Aug 2016, Antoine Rennuit wrote:
>>
>>> Hi all,
>>>
>>> I am putting in place an orchestrator component within my orocos network. This orchestrator is
>>> due to enable / disable (i.e. start / stop in orocos language) some parts of the network
>>> depending on a state machine (within the orchestrator component) - the state machine is a 3rd
>>> party (I am not using orocos state machines).
>>>
>>> I have several questions related to the implementation details of my orchestrator:
>>>
>>> 1. My state machine (within the orchestrator component) is supposed to react to user events, I
>>> was thinking to link my GUI and the orchestrator with operations (e.g. to transition from
>>> auto to manual mode when the user clicks on a button). Are the orocos operations the right
>>> mechanism to use in my case?
>>
>> I would decouple the GUI and the realtime part via a send-and-forget event communication
>> channel.
>>
>>> 2. I need to implement 2 parallel components within a FBSched (they both output to the same 3rd
>>> component within the FBSched). They will never be running at the same time as one
>>> corresponds to the manual mode and the other one to the auto mode. I am not sure which
>>> mechanism I should use to be able to run these 2 parallel components in my FBSched. Any
>>> idea?
>>
>> I would go for two _functions_ that are executed in a "scheduler"
>> _function_ instead of putting things in RTT components. Because from your
>> concise decription I see no arguments in favour of the RTT component overhead. Do you?
>> (Some remark holds for your first question.)
>>
>>> Thanks,
>>>
>>> Antoine.
>>
>> Herman

[OROCOSUSERS] Orchestration

On Sun, 14 Aug 2016, S Roderick wrote:

>> On Aug 10, 2016, at 12:35, Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> wrote:
>>
>> On Wed, 10 Aug 2016, Antoine Rennuit wrote:
>>
>>> Hi Herman,
>>>
>>> Thanks for your answers.
>>>
>>> For the answer on question 2, do you mean that the 2 functions would lie
>>> in a single component and simply being called depending on a "mode"
>>> property (or so)?
>>
>> Indeed. This is by far the best approach, if there are no urgent reasons to
>> run separate components.
>
> My only comment on this approach is that it does not scale.

Do components scale...?

> If you end up adding more motion modes, you will end up with an overly complex
> component.

If you have to add more motion nodes, you'd better introduce explicit
hierarchy in coordination, and not just rely on whatever type of flat
scaling. In other words, scaling motion requires changing the functional as
well as the coordination models.

> Obviously this isn’t an issue with two modes, but perhaps
> something to keep in mind.
>
> HTH
> S

Herman

>
>>
>>> Cheers,
>>>
>>> Antoine.
>>
>> Herman
>>
>>> ________________________________________
>>> De : Orocos Users <OROCOSUSERS [..] ...> de la part de Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
>>> Envoyé : mercredi 10 août 2016 17:57
>>> À : OROCOSUSERS [..] ...
>>> Objet : Re: [OROCOSUSERS] Orchestration
>>>
>>> On Wed, 10 Aug 2016, Antoine Rennuit wrote:
>>>
>>>> Hi all,
>>>>
>>>> I am putting in place an orchestrator component within my orocos network. This orchestrator is
>>>> due to enable / disable (i.e. start / stop in orocos language) some parts of the network
>>>> depending on a state machine (within the orchestrator component) - the state machine is a 3rd
>>>> party (I am not using orocos state machines).
>>>>
>>>> I have several questions related to the implementation details of my orchestrator:
>>>>
>>>> 1. My state machine (within the orchestrator component) is supposed to react to user events, I
>>>> was thinking to link my GUI and the orchestrator with operations (e.g. to transition from
>>>> auto to manual mode when the user clicks on a button). Are the orocos operations the right
>>>> mechanism to use in my case?
>>>
>>> I would decouple the GUI and the realtime part via a send-and-forget event communication
>>> channel.
>>>
>>>> 2. I need to implement 2 parallel components within a FBSched (they both output to the same 3rd
>>>> component within the FBSched). They will never be running at the same time as one
>>>> corresponds to the manual mode and the other one to the auto mode. I am not sure which
>>>> mechanism I should use to be able to run these 2 parallel components in my FBSched. Any
>>>> idea?
>>>
>>> I would go for two _functions_ that are executed in a "scheduler"
>>> _function_ instead of putting things in RTT components. Because from your
>>> concise decription I see no arguments in favour of the RTT component overhead. Do you?
>>> (Some remark holds for your first question.)
>>>
>>>> Thanks,
>>>>
>>>> Antoine.
>>>
>>> Herman
>
>

[OROCOSUSERS] Orchestration

Le 14 août 2016 15:03, "Herman Bruyninckx" <Herman [dot] Bruyninckx [..] ...>
a écrit :
>
> On Sun, 14 Aug 2016, S Roderick wrote:
>
>>> On Aug 10, 2016, at 12:35, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> wrote:
>>>
>>> On Wed, 10 Aug 2016, Antoine Rennuit wrote:
>>>
>>>> Hi Herman,
>>>>
>>>> Thanks for your answers.
>>>>
>>>> For the answer on question 2, do you mean that the 2 functions would
lie
>>>> in a single component and simply being called depending on a "mode"
>>>> property (or so)?
>>>
>>>
>>> Indeed. This is by far the best approach, if there are no urgent
reasons to
>>> run separate components.
>>
>>
>> My only comment on this approach is that it does not scale.
>
>
> Do components scale...?

no, they don't, and the lesson can be painfull to learn ... :-(

Scalability should be addressed progressively, or it will delay a lot your
return on investment.

It's better to do targeted refactoring on need, instead of paying in
advance for something you'll probably never need.

>
>
>> If you end up adding more motion modes, you will end up with an overly
complex
>> component.
>
>
> If you have to add more motion nodes, you'd better introduce explicit
> hierarchy in coordination, and not just rely on whatever type of flat
> scaling. In other words, scaling motion requires changing the functional
as
> well as the coordination models.
>
>
>> Obviously this isn’t an issue with two modes, but perhaps
>> something to keep in mind.
>>
>> HTH
>> S
>
>
> Herman
>
>
>>
>>>
>>>> Cheers,
>>>>
>>>> Antoine.
>>>
>>>
>>> Herman
>>>
>>>> ________________________________________
>>>> De : Orocos Users <OROCOSUSERS [..] ...> de la part de Herman
Bruyninckx <Herman [dot] Bruyninckx [..] ...>
>>>> Envoyé : mercredi 10 août 2016 17:57
>>>> À : OROCOSUSERS [..] ...
>>>> Objet : Re: [OROCOSUSERS] Orchestration
>>>>
>>>> On Wed, 10 Aug 2016, Antoine Rennuit wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am putting in place an orchestrator component within my orocos
network. This orchestrator is
>>>>> due to enable / disable (i.e. start / stop in orocos language) some
parts of the network
>>>>> depending on a state machine (within the orchestrator component) -
the state machine is a 3rd
>>>>> party (I am not using orocos state machines).
>>>>>
>>>>> I have several questions related to the implementation details of my
orchestrator:
>>>>>
>>>>> 1. My state machine (within the orchestrator component) is supposed
to react to user events, I
>>>>> was thinking to link my GUI and the orchestrator with operations
(e.g. to transition from
>>>>> auto to manual mode when the user clicks on a button). Are the
orocos operations the right
>>>>> mechanism to use in my case?
>>>>
>>>>
>>>> I would decouple the GUI and the realtime part via a send-and-forget
event communication
>>>> channel.
>>>>
>>>>> 2. I need to implement 2 parallel components within a FBSched (they
both output to the same 3rd
>>>>> component within the FBSched). They will never be running at the
same time as one
>>>>> corresponds to the manual mode and the other one to the auto mode.
I am not sure which
>>>>> mechanism I should use to be able to run these 2 parallel
components in my FBSched. Any
>>>>> idea?
>>>>
>>>>
>>>> I would go for two _functions_ that are executed in a "scheduler"
>>>> _function_ instead of putting things in RTT components. Because from
your
>>>> concise decription I see no arguments in favour of the RTT component
overhead. Do you?
>>>> (Some remark holds for your first question.)
>>>>
>>>>> Thanks,
>>>>>
>>>>> Antoine.
>>>>
>>>>
>>>> Herman
>>
>>

[OROCOSUSERS] Orchestration

I definitely share this point of view, the control network should not be over engineered!

________________________________
De : Orocos Users <OROCOSUSERS [..] ...> de la part de Willy Lambert <lambert [dot] willy [..] ...>
Envoyé : mardi 16 août 2016 17:19
À : OROCOSUSERS [..] ...
Objet : Re: [OROCOSUSERS] Orchestration

Le 14 août 2016 15:03, "Herman Bruyninckx" <Herman [dot] Bruyninckx [..] ...<mailto:Herman [dot] Bruyninckx [..] ...>> a écrit :
>
> On Sun, 14 Aug 2016, S Roderick wrote:
>
>>> On Aug 10, 2016, at 12:35, Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...<mailto:Herman [dot] Bruyninckx [..] ...>> wrote:
>>>
>>> On Wed, 10 Aug 2016, Antoine Rennuit wrote:
>>>
>>>> Hi Herman,
>>>>
>>>> Thanks for your answers.
>>>>
>>>> For the answer on question 2, do you mean that the 2 functions would lie
>>>> in a single component and simply being called depending on a "mode"
>>>> property (or so)?
>>>
>>>
>>> Indeed. This is by far the best approach, if there are no urgent reasons to
>>> run separate components.
>>
>>
>> My only comment on this approach is that it does not scale.
>
>
> Do components scale...?

no, they don't, and the lesson can be painfull to learn ... :-(

Scalability should be addressed progressively, or it will delay a lot your return on investment.

It's better to do targeted refactoring on need, instead of paying in advance for something you'll probably never need.

>
>
>> If you end up adding more motion modes, you will end up with an overly complex
>> component.
>
>
> If you have to add more motion nodes, you'd better introduce explicit
> hierarchy in coordination, and not just rely on whatever type of flat
> scaling. In other words, scaling motion requires changing the functional as
> well as the coordination models.
>
>
>> Obviously this isn't an issue with two modes, but perhaps
>> something to keep in mind.
>>
>> HTH
>> S
>
>
> Herman
>
>
>>
>>>
>>>> Cheers,
>>>>
>>>> Antoine.
>>>
>>>
>>> Herman
>>>
>>>> ________________________________________
>>>> De : Orocos Users <OROCOSUSERS [..] ...<mailto:OROCOSUSERS [..] ...>> de la part de Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...<mailto:Herman [dot] Bruyninckx [..] ...>>
>>>> Envoyé : mercredi 10 août 2016 17:57
>>>> À : OROCOSUSERS [..] ...<mailto:OROCOSUSERS [..] ...>
>>>> Objet : Re: [OROCOSUSERS] Orchestration
>>>>
>>>> On Wed, 10 Aug 2016, Antoine Rennuit wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am putting in place an orchestrator component within my orocos network. This orchestrator is
>>>>> due to enable / disable (i.e. start / stop in orocos language) some parts of the network
>>>>> depending on a state machine (within the orchestrator component) - the state machine is a 3rd
>>>>> party (I am not using orocos state machines).
>>>>>
>>>>> I have several questions related to the implementation details of my orchestrator:
>>>>>
>>>>> 1. My state machine (within the orchestrator component) is supposed to react to user events, I
>>>>> was thinking to link my GUI and the orchestrator with operations (e.g. to transition from
>>>>> auto to manual mode when the user clicks on a button). Are the orocos operations the right
>>>>> mechanism to use in my case?
>>>>
>>>>
>>>> I would decouple the GUI and the realtime part via a send-and-forget event communication
>>>> channel.
>>>>
>>>>> 2. I need to implement 2 parallel components within a FBSched (they both output to the same 3rd
>>>>> component within the FBSched). They will never be running at the same time as one
>>>>> corresponds to the manual mode and the other one to the auto mode. I am not sure which
>>>>> mechanism I should use to be able to run these 2 parallel components in my FBSched. Any
>>>>> idea?
>>>>
>>>>
>>>> I would go for two _functions_ that are executed in a "scheduler"
>>>> _function_ instead of putting things in RTT components. Because from your
>>>> concise decription I see no arguments in favour of the RTT component overhead. Do you?
>>>> (Some remark holds for your first question.)
>>>>
>>>>> Thanks,
>>>>>
>>>>> Antoine.
>>>>
>>>>
>>>> Herman
>>
>>

[orocosusers] Components update on start

Hi all,

I have noticed that my components are updated (just once) when they are started (even though no even triggers the update).

Is this behavior documented? Alternatively, anyone knows why I observe this behavior? I would like to understand why my component is updated in such as case.

Kind regards,

Antoine.

[OROCOSUSERS] Orchestration

Hi Stephen, hi Herman,

The pros and cons (or say limits) of the solution are clear.

Thanks ;)

Antoine.

________________________________________
De : Orocos Users <OROCOSUSERS [..] ...> de la part de Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
Envoyé : dimanche 14 août 2016 14:44
À : OROCOSUSERS [..] ...
Objet : Re: [OROCOSUSERS] Orchestration

On Sun, 14 Aug 2016, S Roderick wrote:

>> On Aug 10, 2016, at 12:35, Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> wrote:
>>
>> On Wed, 10 Aug 2016, Antoine Rennuit wrote:
>>
>>> Hi Herman,
>>>
>>> Thanks for your answers.
>>>
>>> For the answer on question 2, do you mean that the 2 functions would lie
>>> in a single component and simply being called depending on a "mode"
>>> property (or so)?
>>
>> Indeed. This is by far the best approach, if there are no urgent reasons to
>> run separate components.
>
> My only comment on this approach is that it does not scale.

Do components scale...?

> If you end up adding more motion modes, you will end up with an overly complex
> component.

If you have to add more motion nodes, you'd better introduce explicit
hierarchy in coordination, and not just rely on whatever type of flat
scaling. In other words, scaling motion requires changing the functional as
well as the coordination models.

> Obviously this isn’t an issue with two modes, but perhaps
> something to keep in mind.
>
> HTH
> S

Herman

>
>>
>>> Cheers,
>>>
>>> Antoine.
>>
>> Herman
>>
>>> ________________________________________
>>> De : Orocos Users <OROCOSUSERS [..] ...> de la part de Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
>>> Envoyé : mercredi 10 août 2016 17:57
>>> À : OROCOSUSERS [..] ...
>>> Objet : Re: [OROCOSUSERS] Orchestration
>>>
>>> On Wed, 10 Aug 2016, Antoine Rennuit wrote:
>>>
>>>> Hi all,
>>>>
>>>> I am putting in place an orchestrator component within my orocos network. This orchestrator is
>>>> due to enable / disable (i.e. start / stop in orocos language) some parts of the network
>>>> depending on a state machine (within the orchestrator component) - the state machine is a 3rd
>>>> party (I am not using orocos state machines).
>>>>
>>>> I have several questions related to the implementation details of my orchestrator:
>>>>
>>>> 1. My state machine (within the orchestrator component) is supposed to react to user events, I
>>>> was thinking to link my GUI and the orchestrator with operations (e.g. to transition from
>>>> auto to manual mode when the user clicks on a button). Are the orocos operations the right
>>>> mechanism to use in my case?
>>>
>>> I would decouple the GUI and the realtime part via a send-and-forget event communication
>>> channel.
>>>
>>>> 2. I need to implement 2 parallel components within a FBSched (they both output to the same 3rd
>>>> component within the FBSched). They will never be running at the same time as one
>>>> corresponds to the manual mode and the other one to the auto mode. I am not sure which
>>>> mechanism I should use to be able to run these 2 parallel components in my FBSched. Any
>>>> idea?
>>>
>>> I would go for two _functions_ that are executed in a "scheduler"
>>> _function_ instead of putting things in RTT components. Because from your
>>> concise decription I see no arguments in favour of the RTT component overhead. Do you?
>>> (Some remark holds for your first question.)
>>>
>>>> Thanks,
>>>>
>>>> Antoine.
>>>
>>> Herman
>
>

[OROCOSUSERS] Orchestration

Understood! Thanks a lot, it helped.

Antoine

-------- Original message --------
From: Herman Bruyninckx
Date:10/08/2016 19:32 (GMT+01:00)
To: OROCOSUSERS [..] ...
Subject: Re: [OROCOSUSERS] Orchestration

On Wed, 10 Aug 2016, Antoine Rennuit wrote:

> Hi Herman,
>
> Thanks for your answers.
>
> For the answer on question 2, do you mean that the 2 functions would lie
> in a single component and simply being called depending on a "mode"
> property (or so)?

Indeed. This is by far the best approach, if there are no urgent reasons to
run separate components.

> Cheers,
>
> Antoine.

Herman

> ________________________________________
> De : Orocos Users <OROCOSUSERS [..] ...> de la part de Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> Envoyé : mercredi 10 août 2016 17:57
> À : OROCOSUSERS [..] ...
> Objet : Re: [OROCOSUSERS] Orchestration
>
> On Wed, 10 Aug 2016, Antoine Rennuit wrote:
>
>> Hi all,
>>
>> I am putting in place an orchestrator component within my orocos network. This orchestrator is
>> due to enable / disable (i.e. start / stop in orocos language) some parts of the network
>> depending on a state machine (within the orchestrator component) - the state machine is a 3rd
>> party (I am not using orocos state machines).
>>
>> I have several questions related to the implementation details of my orchestrator:
>>
>> 1. My state machine (within the orchestrator component) is supposed to react to user events, I
>> was thinking to link my GUI and the orchestrator with operations (e.g. to transition from
>> auto to manual mode when the user clicks on a button). Are the orocos operations the right
>> mechanism to use in my case?
>
> I would decouple the GUI and the realtime part via a send-and-forget event communication
> channel.
>
>> 2. I need to implement 2 parallel components within a FBSched (they both output to the same 3rd
>> component within the FBSched). They will never be running at the same time as one
>> corresponds to the manual mode and the other one to the auto mode. I am not sure which
>> mechanism I should use to be able to run these 2 parallel components in my FBSched. Any
>> idea?
>
> I would go for two _functions_ that are executed in a "scheduler"
> _function_ instead of putting things in RTT components. Because from your
> concise decription I see no arguments in favour of the RTT component overhead. Do you?
> (Some remark holds for your first question.)
>
>> Thanks,
>>
>> Antoine.
>
> Herman