Hi all, I have 2 periodic components in the deployer which run at the same frequency. Since the start command for each component is run in sequence, the second component is a bit in delay with respect to the other one, which depends on the code of the startHook.
At the end I get the 2 running components, but there is a delay among them, which is not deterministic and can cause some problems.
So I need to synchronize the two blocks. Is the only way to do that to use an output port on the first block that triggers the execution of the other block? Or is there another way to do that?
Synchroniza components
On Wed, 6 Mar 2013, mirko [dot] comparetti [..] ... wrote:
> Hi all,
> I have 2 periodic components in the deployer which run at the same frequency.
> Since the
startcommand for each component is run in sequence,> the second component is a bit in delay with respect to the other one, which
> depends on the code of the
startHook.>
> At the end I get the 2 running components, but there is a delay among them,
> which is not deterministic and can cause some problems.
>
> So I need to synchronize the two blocks.
What are the synchronization tolerances?
> Is the only way to do that to use an
> output port on the first block that triggers the execution of the other
> block?
That is one possibility.
> Or is there another way to do that?
- use a timer component, that sends timing events to which both other
components react. This is definitely what you need for a multi-"CPU"
system.
- deploy (the to be synchronized) the functionalities inside both
components into the same component, and execute the time-critical parts
sequentially. For a single-CPU system, this is probably the best.
Herman
Synchroniza components
On Mar 7, 2013, at 00:00 , Herman Bruyninckx wrote:
> On Wed, 6 Mar 2013, mirko [dot] comparetti [..] ... wrote:
>
>> Hi all,
>> I have 2 periodic components in the deployer which run at the same frequency.
>> Since the
startcommand for each component is run in sequence,>> the second component is a bit in delay with respect to the other one, which
>> depends on the code of the
startHook.>>
>> At the end I get the 2 running components, but there is a delay among them,
>> which is not deterministic and can cause some problems.
>>
>> So I need to synchronize the two blocks.
>
> What are the synchronization tolerances?
>
>> Is the only way to do that to use an
>> output port on the first block that triggers the execution of the other
>> block?
>
> That is one possibility.
>
>> Or is there another way to do that?
> - use a timer component, that sends timing events to which both other
> components react. This is definitely what you need for a multi-"CPU"
> system.
> - deploy (the to be synchronized) the functionalities inside both
> components into the same component, and execute the time-critical parts
> sequentially. For a single-CPU system, this is probably the best.
3) Use a coordinator component to explicitly sequence the other two components. Particularly useful when you are sequencing N components at the same frequency.
S
Synchroniza components
On Thu, 7 Mar 2013, S Roderick wrote:
> On Mar 7, 2013, at 00:00 , Herman Bruyninckx wrote:
>
>> On Wed, 6 Mar 2013, mirko [dot] comparetti [..] ... wrote:
>>
>>> Hi all,
>>> I have 2 periodic components in the deployer which run at the same frequency.
>>> Since the
startcommand for each component is run in sequence,>>> the second component is a bit in delay with respect to the other one, which
>>> depends on the code of the
startHook.>>>
>>> At the end I get the 2 running components, but there is a delay among them,
>>> which is not deterministic and can cause some problems.
>>>
>>> So I need to synchronize the two blocks.
>>
>> What are the synchronization tolerances?
>>
>>> Is the only way to do that to use an
>>> output port on the first block that triggers the execution of the other
>>> block?
>>
>> That is one possibility.
>>
>>> Or is there another way to do that?
>> - use a timer component, that sends timing events to which both other
>> components react. This is definitely what you need for a multi-"CPU"
>> system.
>> - deploy (the to be synchronized) the functionalities inside both
>> components into the same component, and execute the time-critical parts
>> sequentially. For a single-CPU system, this is probably the best.
>
> 3) Use a coordinator component to explicitly sequence the other two components. Particularly useful when you are sequencing N components at the same frequency.
This _is_ the "timer component" architecture, isn't it...?
("Coordination" for me has a different meaning: instead of the "scheduling"
of the execution of components, it decides about which "behaviour" the
components should have.)
> S
Herman
Synchroniza components
Hi all,
What I did now is to create a periodic component which only writes on a
port a value that is used to trigger the other components throug a
dedicated event port (which neglects the value on that port). Maybe I did
on my own the Timer component, but unfortunately I was not able to find a
page about how to use it.
Anyway, I don't know the tolerance actually, but I suppose that there is a
sort of lag in the port readings that is the one that causes a delay which
makes my code not to work... I'm investigating it...
I'd rather try also this one «- deploy (the to be synchronized) the
functionalities inside both components into the same component, and execute
the time-critical parts sequentially. For a single-CPU system, this is
probably the best.» but I don't understand how to do that.
Thank you again for your help
Regards,
- - -
Mirko D. Comparetti
M.Sc., Eng'r, *PhD Student*
Politecnico di Milano - Electronics, Information and Bioengineering
Department (DEIB)
Neuro Engineering and medicAl Robotics Lab,
Piazza Leonardo da Vinci, 32
20133 Milan, Italy
www.nearlab.polimi.it
Email: mirko [dot] comparetti [..] ...
Phone: +39 02 2399 9013
Fax: +39 02 2399 9003
- .... . / -- .. -. -.. / .. ... / .-.. .. -.- . / .- / .--. .- .-. .- -.-.
.... ..- - .
.. - / .-- --- .-. -.- ... / --- -. .-.. -.-- / .-- .... . -. / .. - / ..
... / --- .--. . -.
2013/3/7 S Roderick <kiwi [dot] net [..] ...>
> On Mar 7, 2013, at 00:00 , Herman Bruyninckx wrote:
>
> > On Wed, 6 Mar 2013, mirko [dot] comparetti [..] ... wrote:
> >
> >> Hi all,
> >> I have 2 periodic components in the deployer which run at the same
> frequency.
> >> Since the
startcommand for each component is run in> sequence,
> >> the second component is a bit in delay with respect to the other one,
> which
> >> depends on the code of the
startHook.> >>
> >> At the end I get the 2 running components, but there is a delay among
> them,
> >> which is not deterministic and can cause some problems.
> >>
> >> So I need to synchronize the two blocks.
> >
> > What are the synchronization tolerances?
> >
> >> Is the only way to do that to use an
> >> output port on the first block that triggers the execution of the other
> >> block?
> >
> > That is one possibility.
> >
> >> Or is there another way to do that?
> > - use a timer component, that sends timing events to which both other
> > components react. This is definitely what you need for a multi-"CPU"
> > system.
> > - deploy (the to be synchronized) the functionalities inside both
> > components into the same component, and execute the time-critical parts
> > sequentially. For a single-CPU system, this is probably the best.
>
> 3) Use a coordinator component to explicitly sequence the other two
> components. Particularly useful when you are sequencing N components at the
> same frequency.
> S
>
>
>
Synchroniza components
On Thu, 7 Mar 2013, Mirko Daniele Comparetti wrote:
> Hi all,
> What I did now is to create a periodic component which only writes on a port a value that is
> used to trigger the other components throug a dedicated event port (which neglects the value on
> that port). Maybe I did on my own the Timer component, but unfortunately I was not able to find
> a page about how to use it.
> Anyway, I don't know the tolerance actually, but I suppose that there is a sort of lag in the
> port readings that is the one that causes a delay which makes my code not to work... I'm
> investigating it...
If you use a "timer component" to trigger other components, there is often
a delay introduced, caused by the scheduling of the processes in which the
components have been deployed. In other words, hard realtime performance
can only be achieved when all the computations involved in the hard
realtime part of the system are done within one single component.
> I'd rather try also this one «- deploy (the to be synchronized) the functionalities inside both
> components into the same component, and execute the time-critical parts sequentially. For a
> single-CPU system, this is probably the best.» but I don't understand how to do that.
This is _the traditional_ way of doing things, like for example Simulink or
20Sim or LabView do it: they take your "control diagram", generate one
single C file from it, and hook it up to the computation trigger of the
component in which that C file (in compiled form, of course) is running.
(In an Orocos RTT component, the computation would be triggered by the
updatehook(), but all component frameworks have something similar.
> Thank you again for your help
>
> Regards,
> - - -
> Mirko D. Comparetti
Herman
Synchroniza components
2013/3/8 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
> On Thu, 7 Mar 2013, Mirko Daniele Comparetti wrote:
>
>> Hi all,
>> What I did now is to create a periodic component which only writes on a
>> port a value that is
>> used to trigger the other components throug a dedicated event port (which
>> neglects the value on
>> that port). Maybe I did on my own the Timer component, but unfortunately I
>> was not able to find
>> a page about how to use it.
>> Anyway, I don't know the tolerance actually, but I suppose that there is a
>> sort of lag in the
>> port readings that is the one that causes a delay which makes my code not
>> to work... I'm
>> investigating it...
>
>
> If you use a "timer component" to trigger other components, there is often
> a delay introduced, caused by the scheduling of the processes in which the
> components have been deployed. In other words, hard realtime performance
> can only be achieved when all the computations involved in the hard
> realtime part of the system are done within one single component.
>
Wouldn't it be possible to acheive such a thing with several
components in the same process/thread ? Or do you mean that low level
control loop can not be done with Orocos ? I find it very practical to
be able to split the loop in blocks like you would do in the modelling
level. I can see the "Then use a model to generate your loop" ;p but I
don't know such a thing yet. I'm very attached to the introspective
capabilities of Orocos that helps a lot when setting up a new loop.
>
>> I'd rather try also this one «- deploy (the to be synchronized) the
>> functionalities inside both
>> components into the same component, and execute the time-critical parts
>> sequentially. For a
>> single-CPU system, this is probably the best.» but I don't understand how
>> to do that.
>
>
> This is _the traditional_ way of doing things, like for example Simulink or
> 20Sim or LabView do it: they take your "control diagram", generate one
> single C file from it, and hook it up to the computation trigger of the
> component in which that C file (in compiled form, of course) is running.
> (In an Orocos RTT component, the computation would be triggered by the
> updatehook(), but all component frameworks have something similar.
>
>
>> Thank you again for your help
>>
>> Regards,
>> - - -
>> Mirko D. Comparetti
>
>
> Herman
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
Synchroniza components
On Fri, 8 Mar 2013, Willy Lambert wrote:
> 2013/3/8 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>> On Thu, 7 Mar 2013, Mirko Daniele Comparetti wrote:
>>
>>> Hi all,
>>> What I did now is to create a periodic component which only writes on a
>>> port a value that is
>>> used to trigger the other components throug a dedicated event port (which
>>> neglects the value on
>>> that port). Maybe I did on my own the Timer component, but unfortunately I
>>> was not able to find
>>> a page about how to use it.
>>> Anyway, I don't know the tolerance actually, but I suppose that there is a
>>> sort of lag in the
>>> port readings that is the one that causes a delay which makes my code not
>>> to work... I'm
>>> investigating it...
>>
>> If you use a "timer component" to trigger other components, there is often
>> a delay introduced, caused by the scheduling of the processes in which the
>> components have been deployed. In other words, hard realtime performance
>> can only be achieved when all the computations involved in the hard
>> realtime part of the system are done within one single component.
>>
>
> Wouldn't it be possible to acheive such a thing with several
> components in the same process/thread ?
That is exactly what I am saying. But if you "blindly" deploying RTT
TaskContexts in the same process, the chances are still there that you will
pay the "context switching" overhead (even though everything is running in
one thread!) because the "ports" in between the components are triggered
only once per execution of that same thread, and hence it can take a couple
of process triggers before that data has moved between components.
> Or do you mean that low level
> control loop can not be done with Orocos ?
Of course it can, but depending on your timing constraints, you can opt for
a "component based" architecture, or a "computation based" architecture.
The latter is "faster" in general, but the former is a lot more robust
against data inconsistencies. For example, the "lock-free buffer" that
Peter put into the RTT infrastructure is doing magic for you behind the
screens.
> I find it very practical to
> be able to split the loop in blocks like you would do in the modelling
> level. I can see the "Then use a model to generate your loop" ;p but I
> don't know such a thing yet. I'm very attached to the introspective
> capabilities of Orocos that helps a lot when setting up a new loop.
This message is the Nth (N>>1) one that puts the finger on a very missing
software support in open source robotics and control: the modelling and
deployment tools for "control loops"...
We have some developments in this direction in the pipeline, as has been
mentioned a couple of time on the "-dev" mailinglist already. But don't
hold your breath...
Herman
Synchroniza components
2013/3/8 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
> On Fri, 8 Mar 2013, Willy Lambert wrote:
>
>> 2013/3/8 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>>>
>>> On Thu, 7 Mar 2013, Mirko Daniele Comparetti wrote:
>>>
>>>> Hi all,
>>>> What I did now is to create a periodic component which only writes on a
>>>> port a value that is
>>>> used to trigger the other components throug a dedicated event port
>>>> (which
>>>> neglects the value on
>>>> that port). Maybe I did on my own the Timer component, but unfortunately
>>>> I
>>>> was not able to find
>>>> a page about how to use it.
>>>> Anyway, I don't know the tolerance actually, but I suppose that there is
>>>> a
>>>> sort of lag in the
>>>> port readings that is the one that causes a delay which makes my code
>>>> not
>>>> to work... I'm
>>>> investigating it...
>>>
>>>
>>> If you use a "timer component" to trigger other components, there is
>>> often
>>> a delay introduced, caused by the scheduling of the processes in which
>>> the
>>> components have been deployed. In other words, hard realtime performance
>>> can only be achieved when all the computations involved in the hard
>>> realtime part of the system are done within one single component.
>>>
>>
>> Wouldn't it be possible to acheive such a thing with several
>> components in the same process/thread ?
>
>
> That is exactly what I am saying. But if you "blindly" deploying RTT
> TaskContexts in the same process, the chances are still there that you will
> pay the "context switching" overhead (even though everything is running in
> one thread!) because the "ports" in between the components are triggered
> only once per execution of that same thread, and hence it can take a couple
> of process triggers before that data has moved between components.
>
>
>> Or do you mean that low level
>> control loop can not be done with Orocos ?
>
>
> Of course it can, but depending on your timing constraints, you can opt for
> a "component based" architecture, or a "computation based" architecture.
> The latter is "faster" in general, but the former is a lot more robust
> against data inconsistencies. For example, the "lock-free buffer" that
> Peter put into the RTT infrastructure is doing magic for you behind the
> screens.
>
>
>> I find it very practical to
>> be able to split the loop in blocks like you would do in the modelling
>> level. I can see the "Then use a model to generate your loop" ;p but I
>> don't know such a thing yet. I'm very attached to the introspective
>> capabilities of Orocos that helps a lot when setting up a new loop.
>
>
> This message is the Nth (N>>1) one that puts the finger on a very missing
> software support in open source robotics and control: the modelling and
> deployment tools for "control loops"...
>
Are there any closed source, or commercial solutions ?
> We have some developments in this direction in the pipeline, as has been
> mentioned a couple of time on the "-dev" mailinglist already. But don't
> hold your breath...
>
> Herman
Synchroniza components
On Fri, 8 Mar 2013, Willy Lambert wrote:
[...]
>>> Or do you mean that low level
>>> control loop can not be done with Orocos ?
>>
>> Of course it can, but depending on your timing constraints, you can opt for
>> a "component based" architecture, or a "computation based" architecture.
>> The latter is "faster" in general, but the former is a lot more robust
>> against data inconsistencies. For example, the "lock-free buffer" that
>> Peter put into the RTT infrastructure is doing magic for you behind the
>> screens.
>>
>>> I find it very practical to
>>> be able to split the loop in blocks like you would do in the modelling
>>> level. I can see the "Then use a model to generate your loop" ;p but I
>>> don't know such a thing yet. I'm very attached to the introspective
>>> capabilities of Orocos that helps a lot when setting up a new loop.
>>
>> This message is the Nth (N>>1) one that puts the finger on a very missing
>> software support in open source robotics and control: the modelling and
>> deployment tools for "control loops"...
>
> Are there any closed source, or commercial solutions ?
The closed source solutions are currently optimizing the "computation
based" architecture, but are lacking support for the "component based"
approach :-) Within a year or so, Orocos will have both.
<bold prediction>
Within two-three years, we will have _tool_ support for both, on par with
the commercial offerings...
<bold prediction>
>> We have some developments in this direction in the pipeline, as has been
>> mentioned a couple of time on the "-dev" mailinglist already. But don't
>> hold your breath...
Herman
Synchroniza components
Dear all,
So given the possible 2 cicle delay on the ports, I need to find a solution
to that... Do I need to create one macro component that includes the
functionalities of all the others via operations?
I'd like the use of ports because it allows me to create the blocks and
connect them in a Simulink-like structure. Is there the possibility to
create one single executable file from a deployment schema? Or has it to be
created manually?
Sorry for my questions, but I'm facing some problems in finding the way to
do that. I'm also using modules which are not developed by me (like the
kuka_lwr component) which have several ports for the data flow.
Thank you,
Regards,
- - -
Mirko D. Comparetti
M.Sc., Eng'r, *PhD Student*
Politecnico di Milano - Electronics, Information and Bioengineering
Department (DEIB)
Neuro Engineering and medicAl Robotics Lab,
Piazza Leonardo da Vinci, 32
20133 Milan, Italy
www.nearlab.polimi.it
Email: mirko [dot] comparetti [..] ...
Phone: +39 02 2399 9013
Fax: +39 02 2399 9003
- .... . / -- .. -. -.. / .. ... / .-.. .. -.- . / .- / .--. .- .-. .- -.-.
.... ..- - .
.. - / .-- --- .-. -.- ... / --- -. .-.. -.-- / .-- .... . -. / .. - / ..
... / --- .--. . -.
2013/3/8 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Fri, 8 Mar 2013, Willy Lambert wrote:
>
> [...]
>
> Or do you mean that low level
>>>> control loop can not be done with Orocos ?
>>>>
>>>
>>> Of course it can, but depending on your timing constraints, you can opt
>>> for
>>> a "component based" architecture, or a "computation based" architecture.
>>> The latter is "faster" in general, but the former is a lot more robust
>>> against data inconsistencies. For example, the "lock-free buffer" that
>>> Peter put into the RTT infrastructure is doing magic for you behind the
>>> screens.
>>>
>>> I find it very practical to
>>>> be able to split the loop in blocks like you would do in the modelling
>>>> level. I can see the "Then use a model to generate your loop" ;p but I
>>>> don't know such a thing yet. I'm very attached to the introspective
>>>> capabilities of Orocos that helps a lot when setting up a new loop.
>>>>
>>>
>>> This message is the Nth (N>>1) one that puts the finger on a very missing
>>> software support in open source robotics and control: the modelling and
>>> deployment tools for "control loops"...
>>>
>>
>> Are there any closed source, or commercial solutions ?
>>
>
> The closed source solutions are currently optimizing the "computation
> based" architecture, but are lacking support for the "component based"
> approach :-) Within a year or so, Orocos will have both.
> <bold prediction>
> Within two-three years, we will have _tool_ support for both, on par with
> the commercial offerings...
> <bold prediction>
>
>
> We have some developments in this direction in the pipeline, as has been
>>> mentioned a couple of time on the "-dev" mailinglist already. But don't
>>> hold your breath...
>>>
>>
> Herman
>
>
Synchroniza components
On Mon, 11 Mar 2013, Mirko Daniele Comparetti wrote:
> Dear all,
> So given the possible 2 cicle delay on the ports, I need to find a solution to that... Do I need
> to create one macro component that includes the functionalities of all the others via
> operations?
If I understand you correctly, that is another phrasing of what I call a
"Computational component" model, indeed. (Depends a bit on your semantics
of "operations"...)
> I'd like the use of ports because it allows me to create the blocks and connect them in a
> Simulink-like structure. Is there the possibility to create one single executable file from a
> deployment schema? Or has it to be created manually?
These are _computational_ component models and tools, which make a lot of
sense, but they are not part of Orocos (not yet, at least), but
complementary.
> Sorry for my questions, but I'm facing some problems in finding the way to do that. I'm also
> using modules which are not developed by me (like the kuka_lwr component) which have several
> ports for the data flow.
>
> Thank you,
>
> Regards,
>
> Mirko D. Comparetti
Herman
>
> M.Sc., Eng'r, PhD Student
> Politecnico di Milano - Electronics, Information and Bioengineering Department (DEIB)
> Neuro Engineering and medicAl Robotics Lab,
> Piazza Leonardo da Vinci, 32
> 20133 Milan, Italy
> www.nearlab.polimi.it
>
> Email: mirko [dot] comparetti [..] ...
> Phone: +39 02 2399 9013
> Fax: +39 02 2399 9003
>
> - .... . / -- .. -. -.. / .. ... / .-.. .. -.- . / .- / .--. .- .-. .- -.-. .... ..- - .
> .. - / .-- --- .-. -.- ... / --- -. .-.. -.-- / .-- .... . -. / .. - / .. ... / --- .--. . -.
>
>
> 2013/3/8 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Fri, 8 Mar 2013, Willy Lambert wrote:
>
> [...]
> Or do you mean that low level
> control loop can not be done with Orocos ?
>
>
> Of course it can, but depending on your timing constraints, you
> can opt for
> a "component based" architecture, or a "computation based"
> architecture.
> The latter is "faster" in general, but the former is a lot more
> robust
> against data inconsistencies. For example, the "lock-free buffer"
> that
> Peter put into the RTT infrastructure is doing magic for you
> behind the
> screens.
>
> I find it very practical to
> be able to split the loop in blocks like you would do
> in the modelling
> level. I can see the "Then use a model to generate
> your loop" ;p but I
> don't know such a thing yet. I'm very attached to the
> introspective
> capabilities of Orocos that helps a lot when setting
> up a new loop.
>
>
> This message is the Nth (N>>1) one that puts the finger on a very
> missing
> software support in open source robotics and control: the
> modelling and
> deployment tools for "control loops"...
>
>
> Are there any closed source, or commercial solutions ?
>
>
> The closed source solutions are currently optimizing the "computation
> based" architecture, but are lacking support for the "component based"
> approach :-) Within a year or so, Orocos will have both.
> <bold prediction>
> Within two-three years, we will have _tool_ support for both, on par with
> the commercial offerings...
> <bold prediction>
>
> We have some developments in this direction in the pipeline, as
> has been
> mentioned a couple of time on the "-dev" mailinglist already. But
> don't
> hold your breath...
>
>
> Herman
>
>
>
>
--
KU Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
Vice-President Research euRobotics <http://www.eu-robotics.net>
Open RObot COntrol Software <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
Synchroniza components
2013/3/11 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Mon, 11 Mar 2013, Mirko Daniele Comparetti wrote:
>
> Dear all,
>> So given the possible 2 cicle delay on the ports, I need to find a
>> solution to that... Do I need
>> to create one macro component that includes the functionalities of all
>> the others via
>> operations?
>>
>
> If I understand you correctly, that is another phrasing of what I call a
> "Computational component" model, indeed. (Depends a bit on your semantics
> of "operations"...)
With operations I meant the "orocos operations", so instead of having
several blocks connected with ports, I create one component wich uses
orocos operations to handle data exchange, is it correct? Or can I still
use the ports in that macro-component without having the delay problem?
What if I'm using modules which are not developed by me, like the lwr_fri
component?
How to make a static deployment then?
I'd like the use of ports because it allows me to create the blocks and
>> connect them in a
>> Simulink-like structure. Is there the possibility to create one single
>> executable file from a
>> deployment schema? Or has it to be created manually?
>>
>
> These are _computational_ component models and tools, which make a lot of
> sense, but they are not part of Orocos (not yet, at least), but
> complementary.
>
Ok, I was trying to make an example of what is in my mind...
Sorry for my questions, but I'm facing some problems in finding the way to
>> do that. I'm also
>> using modules which are not developed by me (like the kuka_lwr component)
>> which have several
>> ports for the data flow.
>>
>> Thank you,
>>
>> Regards,
>>
>> Mirko D. Comparetti
>>
>
> Herman
>
>
>
>> M.Sc., Eng'r, PhD Student
>> Politecnico di Milano - Electronics, Information and Bioengineering
>> Department (DEIB)
>> Neuro Engineering and medicAl Robotics Lab,
>> Piazza Leonardo da Vinci, 32
>> 20133 Milan, Italy
>> www.nearlab.polimi.it
>>
>> Email: mirko [dot] comparetti [..] ....**it<mirko [dot] comparetti [..] ...>
>> Phone: +39 02 2399 9013
>> Fax: +39 02 2399 9003
>>
>> - .... . / -- .. -. -.. / .. ... / .-.. .. -.- . / .- / .--. .- .-. .-
>> -.-. .... ..- - .
>> .. - / .-- --- .-. -.- ... / --- -. .-.. -.-- / .-- .... . -. / .. - / ..
>> ... / --- .--. . -.
>>
>>
>> 2013/3/8 Herman Bruyninckx <Herman.Bruyninckx@mech.**kuleuven.be<Herman [dot] Bruyninckx [..] ...>
>> >
>> On Fri, 8 Mar 2013, Willy Lambert wrote:
>>
>> [...]
>> Or do you mean that low level
>> control loop can not be done with Orocos ?
>>
>>
>> Of course it can, but depending on your timing constraints,
>> you
>> can opt for
>> a "component based" architecture, or a "computation based"
>> architecture.
>> The latter is "faster" in general, but the former is a lot
>> more
>> robust
>> against data inconsistencies. For example, the "lock-free
>> buffer"
>> that
>> Peter put into the RTT infrastructure is doing magic for you
>> behind the
>> screens.
>>
>> I find it very practical to
>> be able to split the loop in blocks like you would do
>> in the modelling
>> level. I can see the "Then use a model to generate
>> your loop" ;p but I
>> don't know such a thing yet. I'm very attached to the
>> introspective
>> capabilities of Orocos that helps a lot when setting
>> up a new loop.
>>
>>
>> This message is the Nth (N>>1) one that puts the finger on a
>> very
>> missing
>> software support in open source robotics and control: the
>> modelling and
>> deployment tools for "control loops"...
>>
>>
>> Are there any closed source, or commercial solutions ?
>>
>>
>> The closed source solutions are currently optimizing the "computation
>> based" architecture, but are lacking support for the "component based"
>> approach :-) Within a year or so, Orocos will have both.
>> <bold prediction>
>> Within two-three years, we will have _tool_ support for both, on par with
>> the commercial offerings...
>> <bold prediction>
>>
>> We have some developments in this direction in the pipeline,
>> as
>> has been
>> mentioned a couple of time on the "-dev" mailinglist already.
>> But
>> don't
>> hold your breath...
>>
>>
>> Herman
>>
>>
>>
>>
>>
> --
> KU Leuven, Mechanical Engineering, Robotics Research Group
> <http://people.mech.kuleuven.**be/~bruyninc
> Vice-President Research euRobotics <http://www.eu-robotics.net>
> Open RObot COntrol Software <http://www.orocos.org>
> Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org
> >
>
>
Synchroniza components
On Mon, 11 Mar 2013, Mirko Daniele Comparetti wrote:
> 2013/3/11 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Mon, 11 Mar 2013, Mirko Daniele Comparetti wrote:
>
> Dear all,
> So given the possible 2 cicle delay on the ports, I need to find a
> solution to that... Do I need
> to create one macro component that includes the functionalities of all
> the others via
> operations?
>
> If I understand you correctly, that is another phrasing of what I call a
> "Computational component" model, indeed. (Depends a bit on your semantics
> of "operations"...)
>
>
> With operations I meant the "orocos operations", so instead of having several blocks connected
> with ports, I create one component wich uses orocos operations to handle data exchange, is it
> correct?
That is correct, but not efficient: you will have similar delays as in your
first solution, in general.
Herman
> Or can I still use the ports in that macro-component without having the delay problem?
> What if I'm using modules which are not developed by me, like the lwr_fri component?
>
> How to make a static deployment then?
>
> I'd like the use of ports because it allows me to create the blocks and
> connect them in a
> Simulink-like structure. Is there the possibility to create one single
> executable file from a
> deployment schema? Or has it to be created manually?
>
>
> These are _computational_ component models and tools, which make a lot of
> sense, but they are not part of Orocos (not yet, at least), but
> complementary.
>
> Ok, I was trying to make an example of what is in my mind...
>
> Sorry for my questions, but I'm facing some problems in finding the way
> to do that. I'm also
> using modules which are not developed by me (like the kuka_lwr
> component) which have several
> ports for the data flow.
>
> Thank you,
>
> Regards,
>
> Mirko D. Comparetti
>
>
> Herman
>
>
> M.Sc., Eng'r, PhD Student
> Politecnico di Milano - Electronics, Information and Bioengineering Department
> (DEIB)
> Neuro Engineering and medicAl Robotics Lab,
> Piazza Leonardo da Vinci, 32
> 20133 Milan, Italy
> www.nearlab.polimi.it
>
> Email: mirko [dot] comparetti [..] ...
> Phone: +39 02 2399 9013
> Fax: +39 02 2399 9003
>
> - .... . / -- .. -. -.. / .. ... / .-.. .. -.- . / .- / .--. .- .-. .- -.-.
> .... ..- - .
> .. - / .-- --- .-. -.- ... / --- -. .-.. -.-- / .-- .... . -. / .. - / .. ...
> / --- .--. . -.
>
>
> 2013/3/8 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Fri, 8 Mar 2013, Willy Lambert wrote:
>
> [...]
> Or do you mean that low level
> control loop can not be done with Orocos ?
>
>
> Of course it can, but depending on your timing constraints, you
> can opt for
> a "component based" architecture, or a "computation based"
> architecture.
> The latter is "faster" in general, but the former is a lot more
> robust
> against data inconsistencies. For example, the "lock-free buffer"
> that
> Peter put into the RTT infrastructure is doing magic for you
> behind the
> screens.
>
> I find it very practical to
> be able to split the loop in blocks like you would do
> in the modelling
> level. I can see the "Then use a model to generate
> your loop" ;p but I
> don't know such a thing yet. I'm very attached to the
> introspective
> capabilities of Orocos that helps a lot when setting
> up a new loop.
>
>
> This message is the Nth (N>>1) one that puts the finger on a very
> missing
> software support in open source robotics and control: the
> modelling and
> deployment tools for "control loops"...
>
>
> Are there any closed source, or commercial solutions ?
>
>
> The closed source solutions are currently optimizing the "computation
> based" architecture, but are lacking support for the "component based"
> approach :-) Within a year or so, Orocos will have both.
> <bold prediction>
> Within two-three years, we will have _tool_ support for both, on par with
> the commercial offerings...
> <bold prediction>
>
> We have some developments in this direction in the pipeline, as
> has been
> mentioned a couple of time on the "-dev" mailinglist already. But
> don't
> hold your breath...
>
>
> Herman
>
>
>
>
>
> --
> KU Leuven, Mechanical Engineering, Robotics Research Group
> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> Vice-President Research euRobotics <http://www.eu-robotics.net>
> Open RObot COntrol Software <http://www.orocos.org>
> Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
>
>
>
>
--
KU Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
Vice-President Research euRobotics <http://www.eu-robotics.net>
Open RObot COntrol Software <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
Synchroniza components
On Mon, Mar 11, 2013 at 4:32 PM, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> wrote:
> On Mon, 11 Mar 2013, Mirko Daniele Comparetti wrote:
>
> 2013/3/11 Herman Bruyninckx <Herman.Bruyninckx@mech.**kuleuven.be<Herman [dot] Bruyninckx [..] ...>
>> >
>> On Mon, 11 Mar 2013, Mirko Daniele Comparetti wrote:
>>
>> Dear all,
>> So given the possible 2 cicle delay on the ports, I need to
>> find a
>> solution to that... Do I need
>> to create one macro component that includes the
>> functionalities of all
>> the others via
>> operations?
>>
>> If I understand you correctly, that is another phrasing of what I call a
>> "Computational component" model, indeed. (Depends a bit on your semantics
>> of "operations"...)
>>
>>
>> With operations I meant the "orocos operations", so instead of having
>> several blocks connected
>> with ports, I create one component wich uses orocos operations to handle
>> data exchange, is it
>> correct?
>>
>
> That is correct, but not efficient: you will have similar delays as in your
> first solution, in general.
>
...and possibly non-thread-safe if the operation is executed in the caller
thread, and caller/callee live in separate threads. Ports manage
concurrency for you.
Adolfo.
> Herman
>
>
>
Synchroniza components
On Mon, 11 Mar 2013, Adolfo Rodríguez Tsouroukdissian wrote:
> On Mon, Mar 11, 2013 at 4:32 PM, Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> wrote:
> On Mon, 11 Mar 2013, Mirko Daniele Comparetti wrote:
>
> 2013/3/11 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Mon, 11 Mar 2013, Mirko Daniele Comparetti wrote:
>
> Dear all,
> So given the possible 2 cicle delay on the ports, I need to
> find a
> solution to that... Do I need
> to create one macro component that includes the
> functionalities of all
> the others via
> operations?
>
> If I understand you correctly, that is another phrasing of what I call a
> "Computational component" model, indeed. (Depends a bit on your
> semantics
> of "operations"...)
>
>
> With operations I meant the "orocos operations", so instead of having
> several blocks connected
> with ports, I create one component wich uses orocos operations to handle
> data exchange, is it
> correct?
>
> That is correct, but not efficient: you will have similar delays as in your
> first solution, in general.
>
> ...and possibly non-thread-safe if the operation is executed in the caller thread, and
> caller/callee live in separate threads. Ports manage concurrency for you.
Absolutely! But at the (possible) cost of efficiency. The trade-off is
yours, and don't expect a software framework to be able to provide a "one
size fits all" solution, irrespective of the trade-off...
> Adolfo.
Herman
Synchroniza components
Ok, but now I don't understand the modularity; I try to make an example
related to what I'm doing: I did a component for some calulations (an
interpolator which can interpolate from the starting point to the target
point given some constraint on the trajectory). In my deployment schema, I
was importing it 3 times because I needed to do some calculations on 3
different variables with different constraints on the trajectory. For doing
that, do I need to "cut&paste" the code and create a class in the new
component and use it three times?
In that case I'm missing the modularity of that and the possibility to use
the same "block" in different control loops.
Thank you,
- - -
Mirko D. Comparetti
M.Sc., Eng'r, *PhD Student*
Politecnico di Milano - Electronics, Information and Bioengineering
Department (DEIB)
Neuro Engineering and medicAl Robotics Lab,
Piazza Leonardo da Vinci, 32
20133 Milan, Italy
www.nearlab.polimi.it
Email: mirko [dot] comparetti [..] ...
Phone: +39 02 2399 9013
Fax: +39 02 2399 9003
- .... . / -- .. -. -.. / .. ... / .-.. .. -.- . / .- / .--. .- .-. .- -.-.
.... ..- - .
.. - / .-- --- .-. -.- ... / --- -. .-.. -.-- / .-- .... . -. / .. - / ..
... / --- .--. . -.
2013/3/11 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Mon, 11 Mar 2013, Mirko Daniele Comparetti wrote:
>
> 2013/3/11 Herman Bruyninckx <Herman.Bruyninckx@mech.**kuleuven.be<Herman [dot] Bruyninckx [..] ...>
>> >
>> On Mon, 11 Mar 2013, Mirko Daniele Comparetti wrote:
>>
>> Dear all,
>> So given the possible 2 cicle delay on the ports, I need to
>> find a
>> solution to that... Do I need
>> to create one macro component that includes the
>> functionalities of all
>> the others via
>> operations?
>>
>> If I understand you correctly, that is another phrasing of what I call a
>> "Computational component" model, indeed. (Depends a bit on your semantics
>> of "operations"...)
>>
>>
>> With operations I meant the "orocos operations", so instead of having
>> several blocks connected
>> with ports, I create one component wich uses orocos operations to handle
>> data exchange, is it
>> correct?
>>
>
> That is correct, but not efficient: you will have similar delays as in your
> first solution, in general.
>
> Herman
>
>
> Or can I still use the ports in that macro-component without having the
>> delay problem?
>> What if I'm using modules which are not developed by me, like the lwr_fri
>> component?
>>
>> How to make a static deployment then?
>>
>> I'd like the use of ports because it allows me to create the
>> blocks and
>> connect them in a
>> Simulink-like structure. Is there the possibility to create
>> one single
>> executable file from a
>> deployment schema? Or has it to be created manually?
>>
>>
>> These are _computational_ component models and tools, which make a lot of
>> sense, but they are not part of Orocos (not yet, at least), but
>> complementary.
>>
>> Ok, I was trying to make an example of what is in my mind...
>>
>> Sorry for my questions, but I'm facing some problems in
>> finding the way
>> to do that. I'm also
>> using modules which are not developed by me (like the kuka_lwr
>> component) which have several
>> ports for the data flow.
>>
>> Thank you,
>>
>> Regards,
>>
>> Mirko D. Comparetti
>>
>>
>> Herman
>>
>>
>> M.Sc., Eng'r, PhD Student
>> Politecnico di Milano - Electronics, Information and Bioengineering
>> Department
>> (DEIB)
>> Neuro Engineering and medicAl Robotics Lab,
>> Piazza Leonardo da Vinci, 32
>> 20133 Milan, Italy
>> www.nearlab.polimi.it
>>
>> Email: mirko [dot] comparetti [..] ....**it<mirko [dot] comparetti [..] ...>
>> Phone: +39 02 2399 9013
>> Fax: +39 02 2399 9003
>>
>> - .... . / -- .. -. -.. / .. ... / .-.. .. -.- . / .- / .--. .- .-.
>> .- -.-.
>> .... ..- - .
>> .. - / .-- --- .-. -.- ... / --- -. .-.. -.-- / .-- .... . -. / ..
>> - / .. ...
>> / --- .--. . -.
>>
>>
>> 2013/3/8 Herman Bruyninckx <Herman.Bruyninckx@mech.**kuleuven.be<Herman [dot] Bruyninckx [..] ...>
>> >
>> On Fri, 8 Mar 2013, Willy Lambert wrote:
>>
>> [...]
>> Or do you mean that low level
>> control loop can not be done with Orocos ?
>>
>>
>> Of course it can, but depending on your timing
>> constraints, you
>> can opt for
>> a "component based" architecture, or a "computation
>> based"
>> architecture.
>> The latter is "faster" in general, but the former is a
>> lot more
>> robust
>> against data inconsistencies. For example, the
>> "lock-free buffer"
>> that
>> Peter put into the RTT infrastructure is doing magic
>> for you
>> behind the
>> screens.
>>
>> I find it very practical to
>> be able to split the loop in blocks like you
>> would do
>> in the modelling
>> level. I can see the "Then use a model to generate
>> your loop" ;p but I
>> don't know such a thing yet. I'm very attached to
>> the
>> introspective
>> capabilities of Orocos that helps a lot when
>> setting
>> up a new loop.
>>
>>
>> This message is the Nth (N>>1) one that puts the finger
>> on a very
>> missing
>> software support in open source robotics and control:
>> the
>> modelling and
>> deployment tools for "control loops"...
>>
>>
>> Are there any closed source, or commercial solutions ?
>>
>>
>> The closed source solutions are currently optimizing the
>> "computation
>> based" architecture, but are lacking support for the "component
>> based"
>> approach :-) Within a year or so, Orocos will have both.
>> <bold prediction>
>> Within two-three years, we will have _tool_ support for both, on
>> par with
>> the commercial offerings...
>> <bold prediction>
>>
>> We have some developments in this direction in the
>> pipeline, as
>> has been
>> mentioned a couple of time on the "-dev" mailinglist
>> already. But
>> don't
>> hold your breath...
>>
>>
>> Herman
>>
>>
>>
>>
>>
>> --
>> KU Leuven, Mechanical Engineering, Robotics Research Group
>> <http://people.mech.kuleuven.**be/~bruyninc
>> Vice-President Research euRobotics <http://www.eu-robotics.net>
>> Open RObot COntrol Software <http://www.orocos.org>
>> Associate Editor JOSER <http://www.joser.org>, IJRR <
>> http://www.ijrr.org>
>>
>>
>>
>>
>>
> --
> KU Leuven, Mechanical Engineering, Robotics Research Group
> <http://people.mech.kuleuven.**be/~bruyninc
> Vice-President Research euRobotics <http://www.eu-robotics.net>
> Open RObot COntrol Software <http://www.orocos.org>
> Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org
> >
>
Synchroniza components
On Mon, 11 Mar 2013, Mirko Daniele Comparetti wrote:
> Ok, but now I don't understand the modularity; I try to make an example related to what I'm
> doing: I did a component for some calulations (an interpolator which can interpolate from the
> starting point to the target point given some constraint on the trajectory). In my deployment
> schema, I was importing it 3 times because I needed to do some calculations on 3 different
> variables with different constraints on the trajectory. For doing that, do I need to "cut&paste"
> the code and create a class in the new component and use it three times?
>
> In that case I'm missing the modularity of that and the possibility to use the same "block" in
> different control loops.
Compilers have been smart enough since ages to not copy code of functions
that is being used several times :-) They are not smart enough typically to
solve your "race conditions" or "pre-emptability problems" or
"multi-threading problems" that can come with your particular _use_ of the
functions...
In other words, components are by far not the only way that "modularity"
can be achieved. And they are definitely not the only way to achieve that
goal!
> Thank you,
>
> Mirko D. Comparetti
Herman
>
> M.Sc., Eng'r, PhD Student
> Politecnico di Milano - Electronics, Information and Bioengineering Department (DEIB)
> Neuro Engineering and medicAl Robotics Lab,
> Piazza Leonardo da Vinci, 32
> 20133 Milan, Italy
> www.nearlab.polimi.it
>
> Email: mirko [dot] comparetti [..] ...
> Phone: +39 02 2399 9013
> Fax: +39 02 2399 9003
>
> - .... . / -- .. -. -.. / .. ... / .-.. .. -.- . / .- / .--. .- .-. .- -.-. .... ..- - .
> .. - / .-- --- .-. -.- ... / --- -. .-.. -.-- / .-- .... . -. / .. - / .. ... / --- .--. . -.
>
>
> 2013/3/11 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Mon, 11 Mar 2013, Mirko Daniele Comparetti wrote:
>
> 2013/3/11 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Mon, 11 Mar 2013, Mirko Daniele Comparetti wrote:
>
> Dear all,
> So given the possible 2 cicle delay on the ports, I need to
> find a
> solution to that... Do I need
> to create one macro component that includes the
> functionalities of all
> the others via
> operations?
>
> If I understand you correctly, that is another phrasing of what I call a
> "Computational component" model, indeed. (Depends a bit on your
> semantics
> of "operations"...)
>
>
> With operations I meant the "orocos operations", so instead of having
> several blocks connected
> with ports, I create one component wich uses orocos operations to handle
> data exchange, is it
> correct?
>
>
> That is correct, but not efficient: you will have similar delays as in your
> first solution, in general.
>
> Herman
>
> Or can I still use the ports in that macro-component without having the delay
> problem?
> What if I'm using modules which are not developed by me, like the lwr_fri
> component?
>
> How to make a static deployment then?
>
> I'd like the use of ports because it allows me to create the
> blocks and
> connect them in a
> Simulink-like structure. Is there the possibility to create one
> single
> executable file from a
> deployment schema? Or has it to be created manually?
>
>
> These are _computational_ component models and tools, which make a lot of
> sense, but they are not part of Orocos (not yet, at least), but
> complementary.
>
> Ok, I was trying to make an example of what is in my mind...
>
> Sorry for my questions, but I'm facing some problems in finding
> the way
> to do that. I'm also
> using modules which are not developed by me (like the kuka_lwr
> component) which have several
> ports for the data flow.
>
> Thank you,
>
> Regards,
>
> Mirko D. Comparetti
>
>
> Herman
>
>
> M.Sc., Eng'r, PhD Student
> Politecnico di Milano - Electronics, Information and Bioengineering
> Department
> (DEIB)
> Neuro Engineering and medicAl Robotics Lab,
> Piazza Leonardo da Vinci, 32
> 20133 Milan, Italy
> www.nearlab.polimi.it
>
> Email: mirko [dot] comparetti [..] ...
> Phone: +39 02 2399 9013
> Fax: +39 02 2399 9003
>
> - .... . / -- .. -. -.. / .. ... / .-.. .. -.- . / .- / .--. .- .-. .-
> -.-.
> .... ..- - .
> .. - / .-- --- .-. -.- ... / --- -. .-.. -.-- / .-- .... . -. / .. - /
> .. ...
> / --- .--. . -.
>
>
> 2013/3/8 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Fri, 8 Mar 2013, Willy Lambert wrote:
>
> [...]
> Or do you mean that low level
> control loop can not be done with Orocos ?
>
>
> Of course it can, but depending on your timing constraints,
> you
> can opt for
> a "component based" architecture, or a "computation based"
> architecture.
> The latter is "faster" in general, but the former is a lot
> more
> robust
> against data inconsistencies. For example, the "lock-free
> buffer"
> that
> Peter put into the RTT infrastructure is doing magic for you
> behind the
> screens.
>
> I find it very practical to
> be able to split the loop in blocks like you would do
> in the modelling
> level. I can see the "Then use a model to generate
> your loop" ;p but I
> don't know such a thing yet. I'm very attached to the
> introspective
> capabilities of Orocos that helps a lot when setting
> up a new loop.
>
>
> This message is the Nth (N>>1) one that puts the finger on a
> very
> missing
> software support in open source robotics and control: the
> modelling and
> deployment tools for "control loops"...
>
>
> Are there any closed source, or commercial solutions ?
>
>
> The closed source solutions are currently optimizing the "computation
> based" architecture, but are lacking support for the "component based"
> approach :-) Within a year or so, Orocos will have both.
> <bold prediction>
> Within two-three years, we will have _tool_ support for both, on par
> with
> the commercial offerings...
> <bold prediction>
>
> We have some developments in this direction in the pipeline,
> as
> has been
> mentioned a couple of time on the "-dev" mailinglist
> already. But
> don't
> hold your breath...
>
>
> Herman
>
>
>
>
>
> --
> KU Leuven, Mechanical Engineering, Robotics Research Group
> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> Vice-President Research euRobotics <http://www.eu-robotics.net>
> Open RObot COntrol Software <http://www.orocos.org>
> Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
>
>
>
>
>
> --
> KU Leuven, Mechanical Engineering, Robotics Research Group
> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> Vice-President Research euRobotics <http://www.eu-robotics.net>
> Open RObot COntrol Software <http://www.orocos.org>
> Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
>
>
>
>
--
KU Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
Vice-President Research euRobotics <http://www.eu-robotics.net>
Open RObot COntrol Software <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
Synchroniza components
On 03/07/2013 06:00 AM, Herman Bruyninckx wrote:
> On Wed, 6 Mar 2013, mirko [dot] comparetti [..] ... wrote:
>
>> Hi all,
>> I have 2 periodic components in the deployer which run at the same frequency.
>> Since the
startcommand for each component is run in sequence,>> the second component is a bit in delay with respect to the other one, which
>> depends on the code of the
startHook.>>
>> At the end I get the 2 running components, but there is a delay among them,
>> which is not deterministic and can cause some problems.
>>
>> So I need to synchronize the two blocks.
> What are the synchronization tolerances?
>
>> Is the only way to do that to use an
>> output port on the first block that triggers the execution of the other
>> block?
> That is one possibility.
>
>> Or is there another way to do that?
> - use a timer component, that sends timing events to which both other
> components react. This is definitely what you need for a multi-"CPU"
> system.
That is an option I already used in the past. You run the timer
component periodically and the other two component react through an
input event port on the output timer port.
> - deploy (the to be synchronized) the functionalities inside both
> components into the same component, and execute the time-critical parts
> sequentially. For a single-CPU system, this is probably the best.
>
> Herman
Synchroniza components
On Thu, Mar 7, 2013 at 9:07 AM, Tinne De Laet
<tinne [dot] delaet [..] ...> wrote:
> On 03/07/2013 06:00 AM, Herman Bruyninckx wrote:
>> On Wed, 6 Mar 2013, mirko [dot] comparetti [..] ... wrote:
>> - use a timer component, that sends timing events to which both other
>> components react. This is definitely what you need for a multi-"CPU"
>> system.
> That is an option I already used in the past. You run the timer
> component periodically and the other two component react through an
> input event port on the output timer port.
+1. We do that too. We wrote our own timer component with output
ports running at a few different frequencies we needed.
Synchroniza components
On Mon, Mar 11, 2013 at 1:34 AM, Andrew Wagner <drewm1980 [..] ...> wrote:
> On Thu, Mar 7, 2013 at 9:07 AM, Tinne De Laet
> <tinne [dot] delaet [..] ...> wrote:
> > On 03/07/2013 06:00 AM, Herman Bruyninckx wrote:
> >> On Wed, 6 Mar 2013, mirko [dot] comparetti [..] ... wrote:
> >> - use a timer component, that sends timing events to which both other
> >> components react. This is definitely what you need for a multi-"CPU"
> >> system.
> > That is an option I already used in the past. You run the timer
> > component periodically and the other two component react through an
> > input event port on the output timer port.
>
> +1. We do that too. We wrote our own timer component with output
> ports running at a few different frequencies we needed.
>
Hey Andrew,
Is there a reason why OCL's timer component [1] didn't fit your needs, so
you had to write your own?.
[1]
http://www.orocos.org/stable/documentation/ocl/v2.x/api/html/classOCL_1_...
Adolfo.
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
Synchroniza components
On Mon, Mar 11, 2013 at 10:02 AM, Adolfo Rodríguez Tsouroukdissian
<adolfo [dot] rodriguez [..] ...> wrote:
> On Mon, Mar 11, 2013 at 1:34 AM, Andrew Wagner <drewm1980 [..] ...> wrote:
>> +1. We do that too. We wrote our own timer component with output
>> ports running at a few different frequencies we needed.
> Is there a reason why OCL's timer component [1] didn't fit your needs, so
> you had to write your own?.
> [1]
> http://www.orocos.org/stable/documentation/ocl/v2.x/api/html/classOCL_1_...
>
> Adolfo.
Hi Adolpho, our "masterTimer" component outputs several timing signals
that are decimated by amounts we configure in properties files. It
looks like that Timer component only outputs one signal. I'm also not
sure if it existed in the version of orocos we were running when we
wrote masterTimer, but that's not relevant now.
Cheers,
Andrew
Synchroniza components
On Tue, 12 Mar 2013, Andrew Wagner wrote:
> On Mon, Mar 11, 2013 at 10:02 AM, Adolfo Rodríguez Tsouroukdissian
> <adolfo [dot] rodriguez [..] ...> wrote:
>> On Mon, Mar 11, 2013 at 1:34 AM, Andrew Wagner <drewm1980 [..] ...> wrote:
>>> +1. We do that too. We wrote our own timer component with output
>>> ports running at a few different frequencies we needed.
>> Is there a reason why OCL's timer component [1] didn't fit your needs, so
>> you had to write your own?.
>> [1]
>> http://www.orocos.org/stable/documentation/ocl/v2.x/api/html/classOCL_1_...
>>
>> Adolfo.
>
> Hi Adolpho, our "masterTimer" component outputs several timing signals
> that are decimated by amounts we configure in properties files. It
> looks like that Timer component only outputs one signal. I'm also not
> sure if it existed in the version of orocos we were running when we
> wrote masterTimer, but that's not relevant now.
If your version is an improvement wrt what is available in the repository,
please consider sending in a "patch" :-) (Via the Bugzilla infrastructure.)
> Cheers,
> Andrew
Herman
Synchroniza components
Dear Herman,
It is not a thing of great beauty, but I have attached our masterTimer
component. The default license for our lab is LGPL, but I doubt it
matters; this is not generic code; it's just in case someone wants
something to pattern match off of. The (unrounded) freqencies for the
clock signals are loaded from a .cpf file. masterTimer runs at the
highest frequency, and everything else is divided down.
Cheers,
Andrew
On Tue, Mar 12, 2013 at 2:06 PM, Herman Bruyninckx
<Herman [dot] Bruyninckx [..] ...> wrote:
> On Tue, 12 Mar 2013, Andrew Wagner wrote:
>
>> On Mon, Mar 11, 2013 at 10:02 AM, Adolfo Rodríguez Tsouroukdissian
>> <adolfo [dot] rodriguez [..] ...> wrote:
>>>
>>> On Mon, Mar 11, 2013 at 1:34 AM, Andrew Wagner <drewm1980 [..] ...>
>>> wrote:
>>>>
>>>> +1. We do that too. We wrote our own timer component with output
>>>> ports running at a few different frequencies we needed.
>>>
>>> Is there a reason why OCL's timer component [1] didn't fit your needs, so
>>> you had to write your own?.
>>> [1]
>>>
>>> http://www.orocos.org/stable/documentation/ocl/v2.x/api/html/classOCL_1_...
>>>
>>> Adolfo.
>>
>>
>> Hi Adolpho, our "masterTimer" component outputs several timing signals
>> that are decimated by amounts we configure in properties files. It
>> looks like that Timer component only outputs one signal. I'm also not
>> sure if it existed in the version of orocos we were running when we
>> wrote masterTimer, but that's not relevant now.
>
>
> If your version is an improvement wrt what is available in the repository,
> please consider sending in a "patch" :-) (Via the Bugzilla infrastructure.)
>
>> Cheers,
>> Andrew
>
>
> Herman
Synchroniza components
Hi,
I have a related problem:
I've three components A, B and C
C computes a function of the outputs of A and B, for simplicity let's say
just the sum of both.
Thus C has to do this computation when A AND B are ready.
A and B use input from another component D, connected with an event port,
such that A and B will wake up and make their computations more or less at
the same time.
To trigger C, I use at the moment two event ports for the input from A and
B, with a check to proceed to the actual computation if the other event
(=data received) happened
before (using a flag).
Now I've two questions:
1)In case C gets triggered while C was performing the flag check, what will
happen? Will C continue the check (and raise a flag) and call the update
hook again, after the
running update was completed OR will C quit the running update and start a
new update (probably/hopefully not)?
2)Is my method ok, or is there another way to trigger C that would be
better?
*I saw the timer option, but how to ensure completion of A and B with this?
*Also a separate scheduler was proposed (With the overhead of yet another
component?), but how would this look like: an extra component that gets
triggered by the output of
D (like A and B are triggered now), that then 'calls' a function on A and B
, and after polling their success, 'call' C? OR
let the scheduler send out 'timer'-like 'events' (no real data, just
triggering an event port on the components) in the right order (but how to
acknowledge the success of
the A and B computation? => an 'event' back?)
Synchroniza components
On Tue, Mar 12, 2013 at 2:06 PM, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> wrote:
> On Tue, 12 Mar 2013, Andrew Wagner wrote:
>
> On Mon, Mar 11, 2013 at 10:02 AM, Adolfo Rodríguez Tsouroukdissian
>> <adolfo.rodriguez@pal-**robotics.com <adolfo [dot] rodriguez [..] ...>>
>> wrote:
>>
>>> On Mon, Mar 11, 2013 at 1:34 AM, Andrew Wagner <drewm1980 [..] ...>
>>> wrote:
>>>
>>>> +1. We do that too. We wrote our own timer component with output
>>>> ports running at a few different frequencies we needed.
>>>>
>>> Is there a reason why OCL's timer component [1] didn't fit your needs, so
>>> you had to write your own?.
>>> [1]
>>> http://www.orocos.org/stable/**documentation/ocl/v2.x/api/**
>>> html/classOCL_1_**1TimerComponent.html<http://www.orocos.org/stable/documentation/ocl/v2.x/api/html/classOCL_1_1TimerComponent.html>
>>>
>>> Adolfo.
>>>
>>
>> Hi Adolpho, our "masterTimer" component outputs several timing signals
>> that are decimated by amounts we configure in properties files. It
>> looks like that Timer component only outputs one signal. I'm also not
>> sure if it existed in the version of orocos we were running when we
>> wrote masterTimer, but that's not relevant now.
>>
>
Admittedly the Doxygen doc is not the best resource, as it does not reflect
the port/operation interfaces, but you can set up 'n' output ports, each
independently configurable in terms of frequency and periodic or single
shot trigger mode. Single-port output is also supported, but the 'legacy
mode' for setting up triggers with the timer component.
Adolfo.
>
> If your version is an improvement wrt what is available in the repository,
> please consider sending in a "patch" :-) (Via the Bugzilla infrastructure.)
>
> Cheers,
>> Andrew
>>
>
> Herman
Synchroniza components
Hi Herman!
I am happy to share the code, but it has application-specific hard
coded names for the timing signal output ports, etc... It could make
a decent example, however.
The general consensus in our group is that we publish our codes (i.e.
qpoases, acado, casadi); we just haven't bothered discussing yet about
how we will license our flight codes since they are very application
specific (also, it's a big complex system that usually only works
under deadline pressure).
Cheers,
Andrew
On Tue, Mar 12, 2013 at 2:06 PM, Herman Bruyninckx
<Herman [dot] Bruyninckx [..] ...> wrote:
> On Tue, 12 Mar 2013, Andrew Wagner wrote:
>
>> On Mon, Mar 11, 2013 at 10:02 AM, Adolfo Rodríguez Tsouroukdissian
>> <adolfo [dot] rodriguez [..] ...> wrote:
>>>
>>> On Mon, Mar 11, 2013 at 1:34 AM, Andrew Wagner <drewm1980 [..] ...>
>>> wrote:
>>>>
>>>> +1. We do that too. We wrote our own timer component with output
>>>> ports running at a few different frequencies we needed.
>>>
>>> Is there a reason why OCL's timer component [1] didn't fit your needs, so
>>> you had to write your own?.
>>> [1]
>>>
>>> http://www.orocos.org/stable/documentation/ocl/v2.x/api/html/classOCL_1_...
>>>
>>> Adolfo.
>>
>>
>> Hi Adolpho, our "masterTimer" component outputs several timing signals
>> that are decimated by amounts we configure in properties files. It
>> looks like that Timer component only outputs one signal. I'm also not
>> sure if it existed in the version of orocos we were running when we
>> wrote masterTimer, but that's not relevant now.
>
>
> If your version is an improvement wrt what is available in the repository,
> please consider sending in a "patch" :-) (Via the Bugzilla infrastructure.)
>
>> Cheers,
>> Andrew
>
>
> Herman