Hello,
I have a theoretical question regarding the component model of OROCOS:
Can OROCOS components be implemented:
- in one thread, using cooperative multitasking
- in separate threads
- in separative processes
- on separate computers?
If all of these options are possible, are they all supported one as good as the
other, or is there an option, which is the preferred way to run components
in parallel?
Best regards:
Uwe Fechner
OROCOS component model
On Wed, 1 Feb 2012, Uwe Fechner wrote:
> Hello,
>
> I have a theoretical question regarding the component model of OROCOS:
>
> Can OROCOS components be implemented:
> - in one thread, using cooperative multitasking
> - in separate threads
> - in separative processes
> - on separate computers?
>
> If all of these options are possible, are they all supported one as good as the
> other, or is there an option, which is the preferred way to run components
> in parallel?
The scope of Orocos has always been to be the best framework possible for
in-process component based systems. That means Orocos/RTT has support for
very efficient inter-component communication in-process (lockfree buffers)
<http://people.mech.kuleuven.be/~psoetens/doc/Lock-Free-FOSDEM.pdf>
and inbetween-process (message queues)
<http://orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-transports-mqueue.html>
<http://people.mech.kuleuven.be/~orocos/pub/stable/documentation/rtt/v2.4.x/doc-xml/orocos-components-manual.html#orocos-mqueue>.
For multi-cpu/computer communication, you should rely on external middleware.
Since the beginning, Orocos/RTT has had very good CORBA support, but there
is no lock-in at all to CORBA
<http://people.mech.kuleuven.be/~orocos/pub/stable/documentation/rtt/v2.4.x/doc-xml/orocos-transports-corba.html>.
Since the rise of ROS, the importance (but
not the quality...) of ROS-based transport has increased, so there is also
data flow integration between RTT and ROS.
<http://people.mech.kuleuven.be/~orocos/pub/stable/documentation/rtt/v2.4.x/doc-xml/orocos-typekit-plugin.html>.
<http://www.ros.org/wiki/orocos_ros_integration>.
> Best regards:
>
> Uwe Fechner
Herman
OROCOS component model
On 02/02/12 15:44, Herman Bruyninckx wrote:
> On Wed, 1 Feb 2012, Uwe Fechner wrote:
>
>> Hello,
>>
>> I have a theoretical question regarding the component model of OROCOS:
>>
>> Can OROCOS components be implemented:
>> - in one thread, using cooperative multitasking
>> - in separate threads
>> - in separative processes
>> - on separate computers?
>>
>> If all of these options are possible, are they all supported one as good as the
>> other, or is there an option, which is the preferred way to run components
>> in parallel?
>
> The scope of Orocos has always been to be the best framework possible for
> in-process component based systems. That means Orocos/RTT has support for
> very efficient inter-component communication in-process (lockfree buffers)
> <http://people.mech.kuleuven.be/~psoetens/doc/Lock-Free-FOSDEM.pdf>
I get a 403 on this link.
Does "in-process" include "multiple threads"?
Geoff
OROCOS component model
On Feb 2, 2012, at 02:08 , Geoffrey Biggs wrote:
> On 02/02/12 15:44, Herman Bruyninckx wrote:
>> On Wed, 1 Feb 2012, Uwe Fechner wrote:
>>
>>> Hello,
>>>
>>> I have a theoretical question regarding the component model of OROCOS:
>>>
>>> Can OROCOS components be implemented:
>>> - in one thread, using cooperative multitasking
>>> - in separate threads
>>> - in separative processes
>>> - on separate computers?
>>>
>>> If all of these options are possible, are they all supported one as good as the
>>> other, or is there an option, which is the preferred way to run components
>>> in parallel?
>>
>> The scope of Orocos has always been to be the best framework possible for
>> in-process component based systems. That means Orocos/RTT has support for
>> very efficient inter-component communication in-process (lockfree buffers)
>> <http://people.mech.kuleuven.be/~psoetens/doc/Lock-Free-FOSDEM.pdf>
>
> I get a 403 on this link.
>
> Does "in-process" include "multiple threads"?
All of our OROCOS deployments are multi-thread within one process. As with Herman's other comments, CORBA works well for inter-process communications, but there are certainly other alternatives.
S
OROCOS component model
On Thu, 2 Feb 2012, S Roderick wrote:
> On Feb 2, 2012, at 02:08 , Geoffrey Biggs wrote:
>
>> On 02/02/12 15:44, Herman Bruyninckx wrote:
>>> On Wed, 1 Feb 2012, Uwe Fechner wrote:
>>>
>>>> Hello,
>>>>
>>>> I have a theoretical question regarding the component model of OROCOS:
>>>>
>>>> Can OROCOS components be implemented:
>>>> - in one thread, using cooperative multitasking
>>>> - in separate threads
>>>> - in separative processes
>>>> - on separate computers?
>>>>
>>>> If all of these options are possible, are they all supported one as good as the
>>>> other, or is there an option, which is the preferred way to run components
>>>> in parallel?
>>>
>>> The scope of Orocos has always been to be the best framework possible for
>>> in-process component based systems. That means Orocos/RTT has support for
>>> very efficient inter-component communication in-process (lockfree buffers)
>>> <http://people.mech.kuleuven.be/~psoetens/doc/Lock-Free-FOSDEM.pdf>
>>
>> I get a 403 on this link.
>>
>> Does "in-process" include "multiple threads"?
>
> All of our OROCOS deployments are multi-thread within one process. As with Herman's other comments, CORBA works well for inter-process communications, but there are certainly other alternatives.
Most definitely! DDS and HLA are high on my personal agenda :-)
(Some groups at NASA are using DDS...)
> S
Herman
OROCOS component model
On 02/02/12 22:16, Herman Bruyninckx wrote:
> On Thu, 2 Feb 2012, S Roderick wrote:
>> All of our OROCOS deployments are multi-thread within one process. As
>> with Herman's other comments, CORBA works well for inter-process
>> communications, but there are certainly other alternatives.
>
> Most definitely! DDS and HLA are high on my personal agenda :-)
> (Some groups at NASA are using DDS...)
We've had DDS support in OpenRTM for nearly a year now. We're very
satisfied with it. The QoS capabilities are awesome, the performance is
great, and the implementation we mostly use comes with a full set of
tools, including an online inspection tool and a logger. I don't know
why anyone would write their own inter-process transport with solutions
like that available (and standardised!). ;)
Geoff
OROCOS component model
On Fri, 3 Feb 2012, Geoffrey Biggs wrote:
> On 02/02/12 22:16, Herman Bruyninckx wrote:
>> On Thu, 2 Feb 2012, S Roderick wrote:
>>> All of our OROCOS deployments are multi-thread within one process. As
>>> with Herman's other comments, CORBA works well for inter-process
>>> communications, but there are certainly other alternatives.
>>
>> Most definitely! DDS and HLA are high on my personal agenda :-)
>> (Some groups at NASA are using DDS...)
>
> We've had DDS support in OpenRTM for nearly a year now. We're very satisfied
> with it. The QoS capabilities are awesome, the performance is great, and the
> implementation we mostly use comes with a full set of tools, including an
> online inspection tool and a logger. I don't know why anyone would write
> their own inter-process transport with solutions like that available (and
> standardised!). ;)
Indeed, I am also wondering what the robotics community is wasting its time
on, sigh...
What implementation are you using?
> Geoff
Herman
OROCOS component model
On 03/02/12 16:15, Herman Bruyninckx wrote:
> On Fri, 3 Feb 2012, Geoffrey Biggs wrote:
>
>> On 02/02/12 22:16, Herman Bruyninckx wrote:
>>> On Thu, 2 Feb 2012, S Roderick wrote:
>>>> All of our OROCOS deployments are multi-thread within one process. As
>>>> with Herman's other comments, CORBA works well for inter-process
>>>> communications, but there are certainly other alternatives.
>>>
>>> Most definitely! DDS and HLA are high on my personal agenda :-)
>>> (Some groups at NASA are using DDS...)
>>
>> We've had DDS support in OpenRTM for nearly a year now. We're very
>> satisfied with it. The QoS capabilities are awesome, the performance
>> is great, and the implementation we mostly use comes with a full set
>> of tools, including an online inspection tool and a logger. I don't
>> know why anyone would write their own inter-process transport with
>> solutions like that available (and standardised!). ;)
>
> Indeed, I am also wondering what the robotics community is wasting its time
> on, sigh...
>
> What implementation are you using?
We started out with RTI's implementation. They have a program where they
provide free one-year licenses to universities, research institutes, and
companies doing R&D. The licenses are renewable yearly for as long as
you continue to meet the criteria. Our currently-released support only
works with RTI's implementation, as it relies on a proprietary extension
(loading QoS settings from an XML file, but this is not exactly a killer
feature so it's not really holding us to RTI). RTI's implementation is
the one with all the awesome tools that I mentioned. Being able to
visually inspect which components are not living up to their promises is
great.
I've spoken to someone from NASA about their use of DDS (Hans Utz, I
think it was), and they're also using RTI's implementation. Apparently
the RTI implementation had difficulties with the extreme lag in space
communications, which they had to get RTI to fix.
There's also OpenDDS, which uses ACE internally and also relies on TAO
for some functionality, and recently, PrismTech released their DDS
implementation as open-source (LGPL, no less!), so we're adding support
for that as well. Because the DDS API is standardised, our goal is to
support any conforming implementation specialisation and let the user
choose.
Unfortunately, the wire protocol itself is not quite through the
standardisation process yet, so implementations talking to each other is
theoretically not a guarantee. In reality, I've seen demonstrations of
five different implementations in use together as a single system
several times now.
Geoff
OROCOS component model
Dear Geoff,
Quoting Geoffrey Biggs <geoffrey [dot] biggs [..] ....j
:
> On 03/02/12 16:15, Herman Bruyninckx wrote:
>> On Fri, 3 Feb 2012, Geoffrey Biggs wrote:
>>
>>> On 02/02/12 22:16, Herman Bruyninckx wrote:
>>>> On Thu, 2 Feb 2012, S Roderick wrote:
>>>>> All of our OROCOS deployments are multi-thread within one process. As
>>>>> with Herman's other comments, CORBA works well for inter-process
>>>>> communications, but there are certainly other alternatives.
>>>>
>>>> Most definitely! DDS and HLA are high on my personal agenda :-)
>>>> (Some groups at NASA are using DDS...)
>>>
>>> We've had DDS support in OpenRTM for nearly a year now. We're very
>>> satisfied with it. The QoS capabilities are awesome, the performance
>>> is great, and the implementation we mostly use comes with a full set
>>> of tools, including an online inspection tool and a logger. I don't
>>> know why anyone would write their own inter-process transport with
>>> solutions like that available (and standardised!). ;)
>>
>> Indeed, I am also wondering what the robotics community is wasting its time
>> on, sigh...
>>
>> What implementation are you using?
>
> We started out with RTI's implementation. They have a program where they
> provide free one-year licenses to universities, research institutes, and
> companies doing R&D. The licenses are renewable yearly for as long as
> you continue to meet the criteria. Our currently-released support only
> works with RTI's implementation, as it relies on a proprietary extension
> (loading QoS settings from an XML file, but this is not exactly a killer
> feature so it's not really holding us to RTI). RTI's implementation is
> the one with all the awesome tools that I mentioned. Being able to
> visually inspect which components are not living up to their promises is
> great.
Do you have QoS-support already in your OpenRTM component model?!
>
> I've spoken to someone from NASA about their use of DDS (Hans Utz, I
> think it was), and they're also using RTI's implementation. Apparently
> the RTI implementation had difficulties with the extreme lag in space
> communications, which they had to get RTI to fix.
>
> There's also OpenDDS, which uses ACE internally and also relies on TAO
> for some functionality, and recently, PrismTech released their DDS
> implementation as open-source (LGPL, no less!), so we're adding support
> for that as well. Because the DDS API is standardised, our goal is to
> support any conforming implementation specialisation and let the user
> choose.
>
> Unfortunately, the wire protocol itself is not quite through the
> standardisation process yet, so implementations talking to each other is
> theoretically not a guarantee. In reality, I've seen demonstrations of
> five different implementations in use together as a single system
> several times now.
>
> Geoff
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
Nico
OROCOS component model
On Thu, 2 Feb 2012, Geoffrey Biggs wrote:
> On 02/02/12 15:44, Herman Bruyninckx wrote:
>> On Wed, 1 Feb 2012, Uwe Fechner wrote:
>>
>>> Hello,
>>>
>>> I have a theoretical question regarding the component model of OROCOS:
>>>
>>> Can OROCOS components be implemented:
>>> - in one thread, using cooperative multitasking
>>> - in separate threads
>>> - in separative processes
>>> - on separate computers?
>>>
>>> If all of these options are possible, are they all supported one as good as the
>>> other, or is there an option, which is the preferred way to run components
>>> in parallel?
>>
>> The scope of Orocos has always been to be the best framework possible for
>> in-process component based systems. That means Orocos/RTT has support for
>> very efficient inter-component communication in-process (lockfree buffers)
>> <http://people.mech.kuleuven.be/~psoetens/doc/Lock-Free-FOSDEM.pdf>
>
> I get a 403 on this link.
Mmm, indeed...
> Does "in-process" include "multiple threads"?
In my semantics, both mean exactly the same thing. Or rather, "in-process
IPC" and "inter-thread communication". (Which leads to a semantic "Catch
22", if we expand "IPC" into "Inter-Process Communication"... :-))
> Geoff
Herman
OROCOS component model
On Feb 1, 2012, at 16:28 , Uwe Fechner wrote:
> Hello,
>
> I have a theoretical question regarding the component model of OROCOS:
>
> Can OROCOS components be implemented:
> - in one thread, using cooperative multitasking
> - in separate threads
> - in separative processes
> - on separate computers?
>
> If all of these options are possible, are they all supported one as good as the
> other, or is there an option, which is the preferred way to run components
> in parallel?
It depends on your system architecture, latency requirements, and a whole host of other factors. All the above are possible, and they all have trade offs and complications. You'd be better off asking a more specific question …
HTH
Stephen
OROCOS component model
On 03/02/12 17:31, Nico Hochgeschwender wrote:
> Dear Geoff,
>
> Quoting Geoffrey Biggs <geoffrey [dot] biggs [..] ....j
:
>
>> On 03/02/12 16:15, Herman Bruyninckx wrote:
>>> What implementation are you using?
>>
>> We started out with RTI's implementation. They have a program where they
>> provide free one-year licenses to universities, research institutes, and
>> companies doing R&D. The licenses are renewable yearly for as long as
>> you continue to meet the criteria. Our currently-released support only
>> works with RTI's implementation, as it relies on a proprietary extension
>> (loading QoS settings from an XML file, but this is not exactly a killer
>> feature so it's not really holding us to RTI). RTI's implementation is
>> the one with all the awesome tools that I mentioned. Being able to
>> visually inspect which components are not living up to their promises is
>> great.
>
> Do you have QoS-support already in your OpenRTM component model?!
If you use our DDS transport support, then yes, you get all the QoS
support that DDS offers *for the transport*. (It doesn't magically give
you QoS guarantees for things like execution time of the component.) We
get this for free by using DDS.
Geoff