 Orocos Real-Time ToolkitSmarter realtime. Safer threads
|
|
question about implementation of DataPortBase
Hi, I have subclassed the DataPorts, and now I am bothered by the fact that connected() is not virtual in class DataPortBase (as I learned after a couple of hours searching and thinking I did not understand c++ after all..). I can of course try to modify, but I wonder why this decision was taken; could you please explain? Cheers, Theo. question about implementation of DataPortBaseSubmitted by sspr on Wed, 2009-03-25 12:35.
On Wednesday 25 March 2009 09:12:09 t [dot] j [dot] a [dot] devries [..] ... wrote: Because there was no need at that time presumably. I see no problems in making Peter |
question about implementation of DataPortBase
Could you tell us why you are subclassing DataPortBase ? That would be a
valuable input for the new data flow interface.
Sylvain
Re: question about implementation of DataPortBase
Could you tell us why you are subclassing DataPortBase ? That would be a
valuable input for the new data flow interface.
Sylvain
I have actually subclassed ReadDataPort and WriteDataPort. Let me try to explain why. There are two reasons.
1. We wanted to be able to make a multi-level part-of hierarchy of TaskContexts (components), just like in Simulink or 20-sim. Hence, a component can be described as a composition of interconnected subcomponents. Then, it should e.g. be possible to connect the output of a subcomponent to the corresponding output of its parent. In order to support such constructions, I subclassed the ports. Maybe that my implementation is not perfect, but it suits our purpose; it is working well. It would be great if something alike is possible with the new data flow interface. When desired, we could have a more detailed discussion on implementation aspects, but I personally prefer to not do this on a forum, as I need pictures to explain and/or understand.
2. We implemented a standard sequence sense-calculate-actuate in updateHook(), and then write user code in senseHook(), calculateHook() and actuateHook(). This has been discussed in the forum elsewhere as well. In our approach, the intention of senseHook is to get information from outside of the system (e.g., from hardware or from a bus) into particular ports, which we call sensorPorts. Analogous for actuatorPorts. That is, sensorPorts and actuatorPorts are special in terms of configuring and realizing hardware access etc. For that purpose, I am currently developing code in subclasses of the orocos read- and write ports.
Does this explanation help or would you like to learn more?
Cheers, Theo.
question about implementation of DataPortBase
On Thu, Mar 26, 2009 at 01:01:47PM -0000, t [dot] j [dot] a [dot] devries [..] ... wrote:
...
> I have actually subclassed ReadDataPort<T> and WriteDataPort<T>. Let
> me try to explain why. There are two reasons.
>
> 1. We wanted to be able to make a multi-level part-of hierarchy of
> TaskContexts (components), just like in Simulink or 20-sim. Hence, a
> component can be described as a composition of interconnected
> subcomponents. Then, it should e.g. be possible to connect the
> output of a subcomponent to the corresponding output of its
> parent. In order to support such constructions, I subclassed the
> ports. Maybe that my implementation is not perfect, but it suits our
> purpose; it is working well. It would be great if something alike is
> possible with the new data flow interface. When desired, we could
> have a more detailed discussion on implementation aspects, but I
> personally prefer to not do this on a forum, as I need pictures to
> explain and/or understand.
...
> Does this explanation help or would you like to learn more?
I would like to learn more :-) I think what you describe -
composability of components - is a really important feature. Can you
describe in more detail what it took to make it work?
Thanks!
Markus
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
question about implementation of DataPortBase
On Thursday 26 March 2009 15:14:32 Markus Klotzb?cher wrote:
> On Thu, Mar 26, 2009 at 01:01:47PM -0000, t [dot] j [dot] a [dot] devries [..] ... wrote:
> ...
>
> > I have actually subclassed ReadDataPort<T> and WriteDataPort<T>. Let
> > me try to explain why. There are two reasons.
> >
> > 1. We wanted to be able to make a multi-level part-of hierarchy of
> > TaskContexts (components), just like in Simulink or 20-sim. Hence, a
> > component can be described as a composition of interconnected
> > subcomponents. Then, it should e.g. be possible to connect the
> > output of a subcomponent to the corresponding output of its
> > parent. In order to support such constructions, I subclassed the
> > ports. Maybe that my implementation is not perfect, but it suits our
> > purpose; it is working well. It would be great if something alike is
> > possible with the new data flow interface. When desired, we could
> > have a more detailed discussion on implementation aspects, but I
> > personally prefer to not do this on a forum, as I need pictures to
> > explain and/or understand.
>
> ...
>
> > Does this explanation help or would you like to learn more?
>
> I would like to learn more :-) I think what you describe -
> composability of components - is a really important feature. Can you
> describe in more detail what it took to make it work?
Composing components in a big data-flow component is one thing. How do you
compose the execution/scripting API's ?
* Are all sub components peers of the parent component ?
* Does starting the parent cause to start all the children ?
* Do all children share the same activity or ExecutionEngine of the parent or
are they operating largely independent ?
Peter
--
Peter Soetens -- FMTC -- <http://www.fmtc.be>
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
Re: question about implementation of DataPortBase
On Thursday 26 March 2009 15:14:32 Markus Klotzb?cher wrote: and WriteDataPort. Let
> On Thu, Mar 26, 2009 at 01:01:47PM -0000, t [dot] j [dot] a [dot] devries [..] ... wrote:
> ...
>
> > I have actually subclassed ReadDataPort
> > me try to explain why. There are two reasons.
> >
> > 1. We wanted to be able to make a multi-level part-of hierarchy of
> > TaskContexts (components), just like in Simulink or 20-sim. Hence, a
> > component can be described as a composition of interconnected
> > subcomponents. Then, it should e.g. be possible to connect the
> > output of a subcomponent to the corresponding output of its
> > parent. In order to support such constructions, I subclassed the
> > ports. Maybe that my implementation is not perfect, but it suits our
> > purpose; it is working well. It would be great if something alike is
> > possible with the new data flow interface. When desired, we could
> > have a more detailed discussion on implementation aspects, but I
> > personally prefer to not do this on a forum, as I need pictures to
> > explain and/or understand.
>
> ...
>
> > Does this explanation help or would you like to learn more?
>
> I would like to learn more :-) I think what you describe -
> composability of components - is a really important feature. Can you
> describe in more detail what it took to make it work?
Composing components in a big data-flow component is one thing. How do you
compose the execution/scripting API's ?
* Are all sub components peers of the parent component ?
* Does starting the parent cause to start all the children ?
* Do all children share the same activity or ExecutionEngine of the parent or
are they operating largely independent ?
Peter
--
Peter Soetens -- FMTC --
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>Composing components in a big data-flow component is one thing.
Well, for me it is a _good_ thing; it makes components much more reuseable.
>How do you
compose the execution/scripting API's ?
I have an implementation that works for us, but I'm not sure if it would be good for anyone; probably not. We do not use scripting much, although I currently see no fundamental problems here.
>* Are all sub components peers of the parent component ?
Yes, surely! Without that, it would not work well.
>* Does starting the parent cause to start all the children ?
Yes, just like activate, configure, etc..; very convenient, I think...
>* Do all children share the same activity or ExecutionEngine of the parent or
are they operating largely independent ?
The activity of the main component (the root TC) is determined by the creator. By default, subcomponents get a SlaveActivity, unless the creator (which is typically the parent in our case) explicitly sets another activity. A common usage pattern is that the maincomponent is periodic, and that some child(s) (and its subcomponents) down in the hierarchy get a non-periodic activity.
Theo.
question about implementation of DataPortBase
On Thu, Mar 26, 2009 at 04:10:33PM +0100, Peter Soetens wrote:
> On Thursday 26 March 2009 15:14:32 Markus Klotzb?cher wrote:
> > On Thu, Mar 26, 2009 at 01:01:47PM -0000, t [dot] j [dot] a [dot] devries [..] ... wrote:
> > ...
> >
> > > I have actually subclassed ReadDataPort<T> and WriteDataPort<T>. Let
> > > me try to explain why. There are two reasons.
> > >
> > > 1. We wanted to be able to make a multi-level part-of hierarchy of
> > > TaskContexts (components), just like in Simulink or 20-sim. Hence, a
> > > component can be described as a composition of interconnected
> > > subcomponents. Then, it should e.g. be possible to connect the
> > > output of a subcomponent to the corresponding output of its
> > > parent. In order to support such constructions, I subclassed the
> > > ports. Maybe that my implementation is not perfect, but it suits our
> > > purpose; it is working well. It would be great if something alike is
> > > possible with the new data flow interface. When desired, we could
> > > have a more detailed discussion on implementation aspects, but I
> > > personally prefer to not do this on a forum, as I need pictures to
> > > explain and/or understand.
> >
> > ...
> >
> > > Does this explanation help or would you like to learn more?
> >
> > I would like to learn more :-) I think what you describe -
> > composability of components - is a really important feature. Can you
> > describe in more detail what it took to make it work?
>
> Composing components in a big data-flow component is one thing. How do you
I admit I have no clear idea how composability should be implemented,
I just think it will become very important. But I'll try to answer
your questions:
> compose the execution/scripting API's ?
Why would this need to be decomposed? Each sub-component is triggered
is some way and then runs its scripts and fsms.
> * Are all sub components peers of the parent component ?
That certainly would make sense.
> * Does starting the parent cause to start all the children ?
Yes!
> * Do all children share the same activity or ExecutionEngine of the parent or
> are they operating largely independent ?
I think each child should have its own execution engine, because it
should be agnostic of the fact that its contained or not. Regarding
the Activity I believe that either sharing or "individual" could be
possible. This will vary from case to case and would be likely defined
(configured!) by the composite component. Configuration of
sub-components is a similar issue: Probably a composite component will
hard-code some configuration of sub-components, but will have to
export other configuration to the composite component user. I'm not
sure how this would best be done (yet).
Regards
Markus
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
Re: question about implementation of DataPortBase
On Thu, Mar 26, 2009 at 04:10:33PM +0100, Peter Soetens wrote: and WriteDataPort. Let
> On Thursday 26 March 2009 15:14:32 Markus Klotzb?cher wrote:
> > On Thu, Mar 26, 2009 at 01:01:47PM -0000, t [dot] j [dot] a [dot] devries [..] ... wrote:
> > ...
> >
> > > I have actually subclassed ReadDataPort
> > > me try to explain why. There are two reasons.
> > >
> > > 1. We wanted to be able to make a multi-level part-of hierarchy of
> > > TaskContexts (components), just like in Simulink or 20-sim. Hence, a
> > > component can be described as a composition of interconnected
> > > subcomponents. Then, it should e.g. be possible to connect the
> > > output of a subcomponent to the corresponding output of its
> > > parent. In order to support such constructions, I subclassed the
> > > ports. Maybe that my implementation is not perfect, but it suits our
> > > purpose; it is working well. It would be great if something alike is
> > > possible with the new data flow interface. When desired, we could
> > > have a more detailed discussion on implementation aspects, but I
> > > personally prefer to not do this on a forum, as I need pictures to
> > > explain and/or understand.
> >
> > ...
> >
> > > Does this explanation help or would you like to learn more?
> >
> > I would like to learn more :-) I think what you describe -
> > composability of components - is a really important feature. Can you
> > describe in more detail what it took to make it work?
>
> Composing components in a big data-flow component is one thing. How do you
I admit I have no clear idea how composability should be implemented,
I just think it will become very important. But I'll try to answer
your questions:
> compose the execution/scripting API's ?
Why would this need to be decomposed? Each sub-component is triggered
is some way and then runs its scripts and fsms.
> * Are all sub components peers of the parent component ?
That certainly would make sense.
> * Does starting the parent cause to start all the children ?
Yes!
> * Do all children share the same activity or ExecutionEngine of the parent or
> are they operating largely independent ?
I think each child should have its own execution engine, because it
should be agnostic of the fact that its contained or not. Regarding
the Activity I believe that either sharing or "individual" could be
possible. This will vary from case to case and would be likely defined
(configured!) by the composite component. Configuration of
sub-components is a similar issue: Probably a composite component will
hard-code some configuration of sub-components, but will have to
export other configuration to the composite component user. I'm not
sure how this would best be done (yet).
Regards
Markus
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
It seems that your ideas align with what I implemented, Markus. Related to the last issue you discuss: there's more to be said about my extensions in terms of configuration and coordination. However, I'm afraid that I have a business interest to protect, so I cannot go into detail on that right now. Sorry! But you guys are bright, you will probably come up with something better...
Theo.