Hello,
We would like to use OpenSplice DDS to transport data between
taskcontexts in an orocos-xenomai process, as well as between the orocos
process and other processes running on the same (or different) machine.
DDS makes it very easy to transfer data using the publish-subscribe
model, with QoS.
However, OpenSplice DDS does not work in realtime with Xenomai. A thread
using DDS functions gets dropped from realtime, because it calls
non-realtime functions.
Are there ways to run a hard real time control loop while simultaneously
grabbing its required data via DDS? One solution I can think of is as
follows:
Create two TaskContexts, A and B. TC A will be periodic, non-realtime
scheduled with ORO_SCHED_OTHER. It will periodically read data via DDS
and push it out of a dataport that is connected to TC B. TC B will the
periodic, hard realtime controller, scheduled with ORO_SCHED_RT. The
basis of this solution is the assumption that a hard realtime
taskcontext can read from a dataport connected to a non-realtime
taskcontext. Is this correct?
Are there other ways to do this? For example, having two threads in a
taskcontext scheduled with ORO_SCHED_RT. One thread will be the
controller and will run in hard-realtime. The other thread will call DDS
functions and will therefore be dropped by Xenomai into non-realtime.
Thanks in advance,
Sagar
using non-realtime library function calls in a realtime componen
Hi Sagar,
On Mon, Oct 8, 2012 at 1:45 AM, Sagar Behere <sagar [dot] behere [..] ...> wrote:
> Hello,
>
> We would like to use OpenSplice DDS to transport data between
> taskcontexts in an orocos-xenomai process, as well as between the orocos
> process and other processes running on the same (or different) machine.
> DDS makes it very easy to transfer data using the publish-subscribe
> model, with QoS.
>
> However, OpenSplice DDS does not work in realtime with Xenomai. A thread
> using DDS functions gets dropped from realtime, because it calls
> non-realtime functions.
>
> Are there ways to run a hard real time control loop while simultaneously
> grabbing its required data via DDS? One solution I can think of is as
> follows:
>
> Create two TaskContexts, A and B. TC A will be periodic, non-realtime
> scheduled with ORO_SCHED_OTHER. It will periodically read data via DDS
> and push it out of a dataport that is connected to TC B. TC B will the
> periodic, hard realtime controller, scheduled with ORO_SCHED_RT. The
> basis of this solution is the assumption that a hard realtime
> taskcontext can read from a dataport connected to a non-realtime
> taskcontext. Is this correct?
I would do it like this, AFAIK the CORBA and ROS transports work in a
similar way.
Ruben
> Are there other ways to do this? For example, having two threads in a
> taskcontext scheduled with ORO_SCHED_RT. One thread will be the
> controller and will run in hard-realtime. The other thread will call DDS
> functions and will therefore be dropped by Xenomai into non-realtime.
>
> Thanks in advance,
> Sagar
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
Xenomai support added to RTI Connext DDS
Hello,
I wanted to make everyone aware that RTI recently added support for Xenomai to their latest version of DDS. RTI Connext DDS 5.0.0
You can find all the details and links to download the libraries at: http://community.rti.com/content/forum-topic/howto-use-dds-xenomai-configure-xenomai-and-run-rti-connext-dds
I would like to also clear some confusion regarding the discussion in this thread about RTI's new RTI Open Community Source License. It is not the same as the old IR&D license. With the IR&D, as was mentioned, each project applying for the license has to be individually approved by RTI. On the other hand with the Open Community Source License RTI approves the Infrastructure Community once and then every project that is part of IC (including future projects) is automatically approved. In fact virtually every community qualifies without condition.
Note that the projects within the Infrastructure Community are not restricted to Academic Institutions or IR&D projects. Regular commercial projects from companies are also included. So once approved the Infrastructure Community is *very open* and moreover you get the latest source.
The IR&D license is still available. If you qualify for an IR&D license do not only get the license to RTI DDS. But you also get all the tools and add-on packages for free. So basically the projects within the Infrastructure Community that qualify for IR&D license get free access to the rest of the RTI tool-suite.
I'm one of the ex-Stanford roboticists from RTI. So is our CEO Stan Schneider. We'd love to help the Orocos community use our products and we would be happy to issue an IC certificate to the entire Orocos community. This will get everyone 100% free RTI DDS with no cost or strings under a very open license. Of course, educational institutions get our entire range of products (including tools, routing, etc.) for free (always have).
We may also help with support for DDS in Orocos. We have a community portal were we would be more than happy to answer questions and offer support. See http://community.rti.com
Best regards,
Gerardo CTO, Real-Time Innovations, Inc.
using non-realtime library function calls in a realtime componen
2012/10/8 Ruben Smits <ruben [dot] smits [..] ...>
> Hi Sagar,
>
> On Mon, Oct 8, 2012 at 1:45 AM, Sagar Behere <sagar [dot] behere [..] ...>
> wrote:
> > Hello,
> >
> > We would like to use OpenSplice DDS to transport data between
> > taskcontexts in an orocos-xenomai process, as well as between the orocos
> > process and other processes running on the same (or different) machine.
> > DDS makes it very easy to transfer data using the publish-subscribe
> > model, with QoS.
> >
> > However, OpenSplice DDS does not work in realtime with Xenomai. A thread
> > using DDS functions gets dropped from realtime, because it calls
> > non-realtime functions.
> >
> > Are there ways to run a hard real time control loop while simultaneously
> > grabbing its required data via DDS? One solution I can think of is as
> > follows:
> >
> > Create two TaskContexts, A and B. TC A will be periodic, non-realtime
> > scheduled with ORO_SCHED_OTHER. It will periodically read data via DDS
> > and push it out of a dataport that is connected to TC B. TC B will the
> > periodic, hard realtime controller, scheduled with ORO_SCHED_RT. The
> > basis of this solution is the assumption that a hard realtime
> > taskcontext can read from a dataport connected to a non-realtime
> > taskcontext. Is this correct?
>
> I would do it like this, AFAIK the CORBA and ROS transports work in a
> similar way.
>
You don't actually have to create a task context for
converting/transporting your data if you can provide a 'DDS transport' for
your type!
That's the way current transports work (Mqueue, Yarp) - I don't know for
CORBA and ROS (creating a task context under the scene was the v1 way to
go...)
You can have a look at the Yarp transport if you need a base to start
developing a DDS transport:
https://gitorious.org/orocos-communication/yarp-transport
I think developing a DDS transport will be useful for other Orocos users.
Do not hesitate to publish it; you can even push it on the
orocos-communication Gitorious project!
Charles.
>
> Ruben
>
> > Are there other ways to do this? For example, having two threads in a
> > taskcontext scheduled with ORO_SCHED_RT. One thread will be the
> > controller and will run in hard-realtime. The other thread will call DDS
> > functions and will therefore be dropped by Xenomai into non-realtime.
> >
> > Thanks in advance,
> > Sagar
> > --
> > Orocos-Users mailing list
> > Orocos-Users [..] ...
> > http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
>
> --
> Ruben Smits, Phd
> Chief Technology Officer
> Intermodalics BVBA
> +32479511786
> www.intermodalics.eu
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
using non-realtime library function calls in a realtime componen
On Mon, 8 Oct 2012, Charles Lesire-Cabaniols wrote:
>
>
> 2012/10/8 Ruben Smits <ruben [dot] smits [..] ...>
> Hi Sagar,
>
> On Mon, Oct 8, 2012 at 1:45 AM, Sagar Behere <sagar [dot] behere [..] ...> wrote:
> > Hello,
> >
> > We would like to use OpenSplice DDS to transport data between
> > taskcontexts in an orocos-xenomai process, as well as between the orocos
> > process and other processes running on the same (or different) machine.
> > DDS makes it very easy to transfer data using the publish-subscribe
> > model, with QoS.
> >
> > However, OpenSplice DDS does not work in realtime with Xenomai. A thread
> > using DDS functions gets dropped from realtime, because it calls
> > non-realtime functions.
> >
> > Are there ways to run a hard real time control loop while simultaneously
> > grabbing its required data via DDS? One solution I can think of is as
> > follows:
> >
> > Create two TaskContexts, A and B. TC A will be periodic, non-realtime
> > scheduled with ORO_SCHED_OTHER. It will periodically read data via DDS
> > and push it out of a dataport that is connected to TC B. TC B will the
> > periodic, hard realtime controller, scheduled with ORO_SCHED_RT. The
> > basis of this solution is the assumption that a hard realtime
> > taskcontext can read from a dataport connected to a non-realtime
> > taskcontext. Is this correct?
>
> I would do it like this, AFAIK the CORBA and ROS transports work in a
> similar way.
I agree.
>
>
> You don't actually have to create a task context for converting/transporting your data if you can
> provide a 'DDS transport' for your type!
> That's the way current transports work (Mqueue, Yarp) - I don't know for CORBA and ROS (creating
> a task context under the scene was the v1 way to go...)
>
> You can have a look at the Yarp transport if you need a base to start developing a DDS transport:
> https://gitorious.org/orocos-communication/yarp-transport
>
> I think developing a DDS transport will be useful for other Orocos users.
I defintely agree!
DDS is a much better middleware approach than most of the ones I have seen
being created by roboticists over the last ten years :-)
(Historical note; DDS was _also_ created by roboticists from Stanford
University, who founded Real-Time Innovations in the 1990s, but then had to
move away from robotics to aviation and space, because robotics was not yet
interested in middleware at that time...)
> Do not hesitate to publish it; you can even push it on the orocos-communication Gitorious
> project!
>
> Charles.
Herman
> Ruben
>
> > Are there other ways to do this? For example, having two threads in a
> > taskcontext scheduled with ORO_SCHED_RT. One thread will be the
> > controller and will run in hard-realtime. The other thread will call DDS
> > functions and will therefore be dropped by Xenomai into non-realtime.
> >
> > Thanks in advance,
> > Sagar
> > --
> > Orocos-Users mailing list
> > Orocos-Users [..] ...
> > http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
>
> --
> Ruben Smits, Phd
> Chief Technology Officer
> Intermodalics BVBA
> +32479511786
> www.intermodalics.eu
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
>
>
--
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>
using non-realtime library function calls in a realtime componen
On 10/08/2012 10:10 AM, Herman Bruyninckx wrote:
> On Mon, 8 Oct 2012, Charles Lesire-Cabaniols wrote:
>
>>
>>
>> 2012/10/8 Ruben Smits<ruben [dot] smits [..] ...>
>> Hi Sagar,
>>
>> On Mon, Oct 8, 2012 at 1:45 AM, Sagar Behere<sagar [dot] behere [..] ...> wrote:
>> > Hello,
>> >
>> > We would like to use OpenSplice DDS to transport data between
>> > taskcontexts in an orocos-xenomai process, as well as between the orocos
>> > process and other processes running on the same (or different) machine.
>> > DDS makes it very easy to transfer data using the publish-subscribe
>> > model, with QoS.
>> >
>> > However, OpenSplice DDS does not work in realtime with Xenomai. A thread
>> > using DDS functions gets dropped from realtime, because it calls
>> > non-realtime functions.
>> >
>> > Are there ways to run a hard real time control loop while simultaneously
>> > grabbing its required data via DDS? One solution I can think of is as
>> > follows:
>> >
>> > Create two TaskContexts, A and B. TC A will be periodic, non-realtime
>> > scheduled with ORO_SCHED_OTHER. It will periodically read data via DDS
>> > and push it out of a dataport that is connected to TC B. TC B will the
>> > periodic, hard realtime controller, scheduled with ORO_SCHED_RT. The
>> > basis of this solution is the assumption that a hard realtime
>> > taskcontext can read from a dataport connected to a non-realtime
>> > taskcontext. Is this correct?
>>
>> I would do it like this, AFAIK the CORBA and ROS transports work in a
>> similar way.
>
> I agree.
>
>>
>>
>> You don't actually have to create a task context for converting/transporting your data if you can
>> provide a 'DDS transport' for your type!
>> That's the way current transports work (Mqueue, Yarp) - I don't know for CORBA and ROS (creating
>> a task context under the scene was the v1 way to go...)
>>
>> You can have a look at the Yarp transport if you need a base to start developing a DDS transport:
>> https://gitorious.org/orocos-communication/yarp-transport
>>
>> I think developing a DDS transport will be useful for other Orocos users.
>
> I defintely agree!
>
> DDS is a much better middleware approach than most of the ones I have seen
> being created by roboticists over the last ten years :-)
> (Historical note; DDS was _also_ created by roboticists from Stanford
> University, who founded Real-Time Innovations in the 1990s, but then had to
> move away from robotics to aviation and space, because robotics was not yet
> interested in middleware at that time...)
>
>> Do not hesitate to publish it; you can even push it on the orocos-communication Gitorious
>> project!
Oh wow! I had no idea others were interested in this :)
I was planning a series of coding hacks to make DDS work
For-Me-For-Now(tm), but it seems that developing a DDS transport is the
'clean' way to go.
I don't know much about DDS, or orocos internals for that matter, but
okay, I'm willing to do this and of course it'll be open source and
available for the community.
I will read the code for the YARP/mqueue transports and join the
developers mailing list where I can ask more detailed questions.
Thanks and regards,
Sagar
using non-realtime library function calls in a realtime componen
On Oct 8, 2012, at 8:27 PM, Sagar Behere wrote:
> On 10/08/2012 10:10 AM, Herman Bruyninckx wrote:
>> On Mon, 8 Oct 2012, Charles Lesire-Cabaniols wrote:
>>> 2012/10/8 Ruben Smits<ruben [dot] smits [..] ...>
>>> Do not hesitate to publish it; you can even push it on the orocos-communication Gitorious
>>> project!
>
> Oh wow! I had no idea others were interested in this :)
>
> I was planning a series of coding hacks to make DDS work
> For-Me-For-Now(tm), but it seems that developing a DDS transport is the
> 'clean' way to go.
>
> I don't know much about DDS, or orocos internals for that matter, but
> okay, I'm willing to do this and of course it'll be open source and
> available for the community.
>
> I will read the code for the YARP/mqueue transports and join the
> developers mailing list where I can ask more detailed questions.
We added DDS support to our middleware over a year ago and have never looked back. In my opinion, there is simply no comparison between DDS and any other transport for data-flow communications, and the implementation we used (RTI) was considerably faster in our tests than our CORBA-based transport. The fact that RTI's implementation supports real-time data transfer and that the C++ API is standardised (so software written for one implementation can be used for others with no, or minimal, code changes) are also great features, but the killer feature is the QoS settings that are available. Everything you need to set to control the efficiency, real-time safety and reliability of every individual communication is there.
For example, if you want a specific instance of DDS to be real-time safe, you can configure QoS settings to ensure that all memory is allocated at setup time by specifying the maximum number of history samples to keep, size of arrays, maximum number of connections to allow, etc.
The only downside of DDS that I've found, at least for RTI's implementation, is that there is a serialisation cost even if the communication is between two processes on the same computer. This is apparently necessarily to support DDS features such as history and introspection. We found that this cost set a minimum time for local shared memory-based communication. In our case (on a modern i7 with 16GB of RAM) this started at about 40us for 16B of data and started rising when the data size got to 8KB, rising to less than 500us for 256KB. It's not huge, but it is something to be aware of in real-time use. This observation may not be valid for other implementations of DDS.
In my opinion, the only difficulty with DDS in robotics is convincing others that they can and should be using it over inventing their own transports.
Geoff
using non-realtime library function calls in a realtime componen
On 10/08/2012 03:11 PM, Geoffrey Biggs wrote:
> We added DDS support to our middleware over a year ago and have never looked back. In my opinion, there is simply no comparison between DDS and any other transport for data-flow communications, and the implementation we used (RTI) was considerably faster in our tests than our CORBA-based transport. The fact that RTI's implementation supports real-time data transfer and that the C++ API is standardised (so software written for one implementation can be used for others with no, or minimal, code changes) are also great features, but the killer feature is the QoS settings that are available. Everything you need to set to control the efficiency, real-time safety and reliability of every individual communication is there.
>
> For example, if you want a specific instance of DDS to be real-time safe, you can configure QoS settings to ensure that all memory is allocated at setup time by specifying the maximum number of history samples to keep, size of arrays, maximum number of connections to allow, etc.
>
> The only downside of DDS that I've found, at least for RTI's implementation, is that there is a serialisation cost even if the communication is between two processes on the same computer. This is apparently necessarily to support DDS features such as history and introspection. We found that this cost set a minimum time for local shared memory-based communication. In our case (on a modern i7 with 16GB of RAM) this started at about 40us for 16B of data and started rising when the data size got to 8KB, rising to less than 500us for 256KB. It's not huge, but it is something to be aware of in real-time use. This observation may not be valid for other implementations of DDS.
>
> In my opinion, the only difficulty with DDS in robotics is convincing others that they can and should be using it over inventing their own transports.
Interesting return of experience. While I was super-interested in DDS in
general, people started to tell me that its configuration was
close-to-hell. What is your point of view on that ?
Sylvain
using non-realtime library function calls in a realtime componen
On Oct 8, 2012, at 11:01 PM, Sylvain Joyeux wrote:
> On 10/08/2012 03:11 PM, Geoffrey Biggs wrote:
>> We added DDS support to our middleware over a year ago and have never looked back. In my opinion, there is simply no comparison between DDS and any other transport for data-flow communications, and the implementation we used (RTI) was considerably faster in our tests than our CORBA-based transport. The fact that RTI's implementation supports real-time data transfer and that the C++ API is standardised (so software written for one implementation can be used for others with no, or minimal, code changes) are also great features, but the killer feature is the QoS settings that are available. Everything you need to set to control the efficiency, real-time safety and reliability of every individual communication is there.
>>
>> For example, if you want a specific instance of DDS to be real-time safe, you can configure QoS settings to ensure that all memory is allocated at setup time by specifying the maximum number of history samples to keep, size of arrays, maximum number of connections to allow, etc.
>>
>> The only downside of DDS that I've found, at least for RTI's implementation, is that there is a serialisation cost even if the communication is between two processes on the same computer. This is apparently necessarily to support DDS features such as history and introspection. We found that this cost set a minimum time for local shared memory-based communication. In our case (on a modern i7 with 16GB of RAM) this started at about 40us for 16B of data and started rising when the data size got to 8KB, rising to less than 500us for 256KB. It's not huge, but it is something to be aware of in real-time use. This observation may not be valid for other implementations of DDS.
>>
>> In my opinion, the only difficulty with DDS in robotics is convincing others that they can and should be using it over inventing their own transports.
> Interesting return of experience. While I was super-interested in DDS in general, people started to tell me that its configuration was close-to-hell. What is your point of view on that ?
In my experience, it's no harder than any other system, including 100% self-implemented systems. If you have no constraints, you can safely leave RTI's at the default and get good performance. Otherwise, you need to know what your specific constraints are and design your system properly, remembering that DDS is a part of your system, and not a magic bullet. Understand your communication patterns, understand your communication channels, understand your time and memory constraints, and design your system accordingly. DDS provides the facilities necessary to do so but with sensible defaults (at least for RTI's implementation), which I prefer to a transport that provides no flexibility. The downside is a somewhat steep learning curve to learn all the options available and how they interact with operating system settings. I suspect that this is the part where RTI makes the most money on support contracts.
Be wary of over-configuring, too. Like a Gentoo ricer, you can set things that sound like they'll make things faster, but actually make things slower.
Also I want to be clear that RTI's implementation is not perfect. I've had good experience with it, but it's not powered by magic. I've had an interesting discussion with someone from NASA working on the Robonaut (which uses RTI's DDS) about meetings they had with RTI where they had to explain to the RTI people that a significant lag - I forget the figure but it was at least tens of seconds - must be handled properly by the transport. Apparently RTI's implementation at that point assumed a not necessarily reliable but none-the-less relatively local link. You really do need to understand your requirements and your constraints, and the capabilities of the middleware itself, to use DDS effectively.
Geoff
using non-realtime library function calls in a realtime componen
On 10/08/2012 04:28 PM, Geoffrey Biggs wrote:
> On Oct 8, 2012, at 11:01 PM, Sylvain Joyeux wrote:
>> On 10/08/2012 03:11 PM, Geoffrey Biggs wrote:
>>> We added DDS support to our middleware over a year ago and have never looked back. In my opinion, there is simply no comparison between DDS and any other transport for data-flow communications, and the implementation we used (RTI) was considerably faster in our tests than our CORBA-based transport. The fact that RTI's implementation supports real-time data transfer and that the C++ API is standardised (so software written for one implementation can be used for others with no, or minimal, code changes) are also great features, but the killer feature is the QoS settings that are available. Everything you need to set to control the efficiency, real-time safety and reliability of every individual communication is there.
>>>
>>> For example, if you want a specific instance of DDS to be real-time safe, you can configure QoS settings to ensure that all memory is allocated at setup time by specifying the maximum number of history samples to keep, size of arrays, maximum number of connections to allow, etc.
>>>
>>> The only downside of DDS that I've found, at least for RTI's implementation, is that there is a serialisation cost even if the communication is between two processes on the same computer. This is apparently necessarily to support DDS features such as history and introspection. We found that this cost set a minimum time for local shared memory-based communication. In our case (on a modern i7 with 16GB of RAM) this started at about 40us for 16B of data and started rising when the data size got to 8KB, rising to less than 500us for 256KB. It's not huge, but it is something to be aware of in real-time use. This observation may not be valid for other implementations of DDS.
>>>
>>> In my opinion, the only difficulty with DDS in robotics is convincing others that they can and should be using it over inventing their own transports.
>> Interesting return of experience. While I was super-interested in DDS in general, people started to tell me that its configuration was close-to-hell. What is your point of view on that ?
> In my experience, it's no harder than any other system, including 100% self-implemented systems.
Oh, don't worry, you are preaching to the choir.
> If you have no constraints, you can safely leave RTI's at the default and get good performance. Otherwise, you need to know what your specific constraints are and design your system properly, remembering that DDS is a part of your system, and not a magic bullet. Understand your communication patterns, understand your communication channels, understand your time and memory constraints, and design your system accordingly. DDS provides the facilities necessary to do so but with sensible defaults (at least for RTI's implementation), which I prefer to a transport that provides no flexibility. The downside is a somewhat steep learning curve to learn all the options available and how they interact with operating system settings. I suspect that this is the part where RTI makes the most money on support contracts.
>
> Be wary of over-configuring, too. Like a Gentoo ricer, you can set things that sound like they'll make things faster, but actually make things slower.
+10000000
>
> Also I want to be clear that RTI's implementation is not perfect. I've had good experience with it, but it's not powered by magic. I've had an interesting discussion with someone from NASA working on the Robonaut (which uses RTI's DDS) about meetings they had with RTI where they had to explain to the RTI people that a significant lag - I forget the figure but it was at least tens of seconds - must be handled properly by the transport. Apparently RTI's implementation at that point assumed a not necessarily reliable but none-the-less relatively local link. You really do need to understand your requirements and your constraints, and the capabilities of the middleware itself, to use DDS effectively.
Everything you say sounds like a pretty good system design to me: sane
defaults, and if you do have a more complex application, then you need
to dig in.
However, you are only talking about RTI. How are the open-source DDS
implementation comparing (as e.g. opendds ?)
using non-realtime library function calls in a realtime componen
On Oct 8, 2012, at 11:49 PM, Sylvain Joyeux wrote:
> Everything you say sounds like a pretty good system design to me: sane defaults, and if you do have a more complex application, then you need to dig in.
>
> However, you are only talking about RTI. How are the open-source DDS implementation comparing (as e.g. opendds ?)
I don't really feel like I have enough experience with the others to comment. I've used them, but only a little.
I found RTI's the easiest to set up and get going, but I also had trouble with some of RTI's tools, which are Java-based and not very happy with my Linux version. RTI officially only supports specific versions of specific distributions of Linux, but in reality if you have the necessary library versions, it will run. Except for, apparently, the absurdly useful system introspection and real-time data logging tools. RTI's option to use an XML file for configuration was very, very useful, making it easier to experiment with QoS configurations.
I also found, while setting up OpenDDS, that it's use of TAO in some of its features (not directly related to communication) to be a bit annoying, in terms of dependencies.
OpenSplice DDS only went open source relatively recently, so it's the one I have the least experience with.
There are also implementations from at least three other vendors, and they do have actual working compatibility, if the fairly comprehensive demo they give at every OMG meeting is to be believed. I don't have any experience with using them.
Geoff
using non-realtime library function calls in a realtime componen
On 10/08/2012 05:20 PM, Geoffrey Biggs wrote:
> On Oct 8, 2012, at 11:49 PM, Sylvain Joyeux wrote:
>> Everything you say sounds like a pretty good system design to me: sane defaults, and if you do have a more complex application, then you need to dig in.
>>
>> However, you are only talking about RTI. How are the open-source DDS implementation comparing (as e.g. opendds ?)
>
> I don't really feel like I have enough experience with the others to comment. I've used them, but only a little.
>
> I found RTI's the easiest to set up and get going, but I also had trouble with some of RTI's tools, which are Java-based and not very happy with my Linux version. RTI officially only supports specific versions of specific distributions of Linux, but in reality if you have the necessary library versions, it will run. Except for, apparently, the absurdly useful system introspection and real-time data logging tools. RTI's option to use an XML file for configuration was very, very useful, making it easier to experiment with QoS configurations.
>
> I also found, while setting up OpenDDS, that it's use of TAO in some of its features (not directly related to communication) to be a bit annoying, in terms of dependencies.
>
> OpenSplice DDS only went open source relatively recently, so it's the one I have the least experience with.
I downloaded the LGPLv3 OpenSplice Community Edition (v5.5.1) two days
ago and fiddled with it a few times since. While I haven't checked it
for performance, it has made a very favorable impression in terms of
usability.
Pros:
1. The download tarball contains the sources, as well as precompiled
binaries and libs. 32 and 64 bit versions are available. Both are for
specific kernels/libstdc++ versions. Ignoring the recommendations, I
installed it on 4 different linux boxen, all with different (and
different from the recommended) software versions(ubuntu 10.04 through
debian wheezy). In all cases, everything just worked. Compiling from
source was not required.
2. Language bindings for C, C++ with Corba, Standalone C++, and Java
3. The getting started tutorial is remarkably good! It shows you how to
make a chat application in C, incrementally introducing and explaining
new features of dds in every chapter.
4. There are many large and small examples for all language bindings.
All which I tested, compiled and executed without a single warning on
different gcc versions.
5. Considering the complexity of DDS, I liked the fact that it took less
than two hours to go through some docs+examples and have a working
helloworld. It seems to have sane QoS defaults, and the tutorial
mentions the QoS settings that you most likely want to change.
6. There are plenty of tools/services for model based development,
tuning of a live system, for generating XML configs via GUIs, plugging
in a RDBMS via ODBC etc.
Cons:
1. The language reference manuals are all in PDF. If you are used to
doxygen API docs, it's annoying to search through a PDF file.
2. The tutorial covers only C. There is a C++ API reference pdf, but
some aspects of using C++ are a bit unclear. I had to look at the
provided examples (there's lots) and form my own hypotheses.
3. Some of the nicer tools are commercial and not included with the
community edition.
OpenDDS seems really good too and they support a large number of
operating systems, and compilers. The signal-to-noise ratio on their
website is very high, especially compared to the OpenSplice webpages.
One of their guys did an interesting comparison of OpenDDS vs ØMQ under
different scenarios
http://mnb.ociweb.com/mnb/MiddlewareNewsBrief-201004.html
and later discussed it actively on the ØMQ list.
One reason I became cautious about OpenDDS though, was this thread
http://forums.opensplice.org/index.php?/topic/950-publisher-and-subscrib...
It gave the impression that maybe OpenDDS doesn't support a publisher
and subscriber in the same process. IF this is the case, then it seems
to rule out its use in orocos. Of course, maybe the poster was confused,
but the quick response from the OpenSplice guy kind of tipped the
balance in OpenSplice's favor :)
Just my $0.02
Regards,
Sagar
using non-realtime library function calls in a realtime componen
>
> 2. The tutorial covers only C. There is a C++ API reference pdf, but
> some aspects of using C++ are a bit unclear. I had to look at the
> provided examples (there's lots) and form my own hypotheses.
>
Do you know about this? http://code.google.com/p/simd-cxx/
> One reason I became cautious about OpenDDS though, was this thread
>
> http://forums.opensplice.org/index.php?/topic/950-publisher-and-subscrib...
>
> It gave the impression that maybe OpenDDS doesn't support a publisher
> and subscriber in the same process. IF this is the case, then it seems
> to rule out its use in orocos. Of course, maybe the poster was confused,
> but the quick response from the OpenSplice guy kind of tipped the
> balance in OpenSplice's favor :)
>
In my opinion you shouldn't worry about that.
One of the biggest advantages of Orocos is its in-process communication
that is extremely efficient and hard-real time. Since it use the in-process
shared memory,serialization of data is not required.
The problems come when you want inter-process communication. Historically
(orocos 1.X) the only way was CORBA. Today more transport exist, as we know.
I don't know about my application, but IMHO, DDS make sense for
inter-process communication, while for in-process communication the most
efficient option is to use Orocos itself.
Davide
using non-realtime library function calls in a realtime componen
On Tue, 9 Oct 2012, Sagar Behere wrote:
[...]
Thanks _a lot_ for your very informative summary of experiences with
OpenDDS!!!
> One reason I became cautious about OpenDDS though, was this thread
> http://forums.opensplice.org/index.php?/topic/950-publisher-and-subscrib...
>
> It gave the impression that maybe OpenDDS doesn't support a publisher
> and subscriber in the same process. IF this is the case, then it seems
> to rule out its use in orocos.
No, not at all! We designed Orocos/RTT to be communication middleware
agnostic, _except_ for in-process communication. On other words, the
"weakness" of OpenDDS is not at all a weakness in realtime contexts,
because RTT has _very good_ alternatives. And that's not a coincidence: we
knew that generic middleware would always be worse than the very
application/platform specific optimal architectures that hard realtime
developers will want to use :-)
> Of course, maybe the poster was confused,
> but the quick response from the OpenSplice guy kind of tipped the
> balance in OpenSplice's favor :)
>
> Just my $0.02
>
> Regards,
> Sagar
Herman
using non-realtime library function calls in a realtime componen
On 10/09/2012 10:10 AM, Herman Bruyninckx wrote:
> On Tue, 9 Oct 2012, Sagar Behere wrote:
>
> [...]
>
> Thanks _a lot_ for your very informative summary of experiences with
> OpenDDS!!!
OpenSplice ;-)
>> One reason I became cautious about OpenDDS though, was this thread
>> http://forums.opensplice.org/index.php?/topic/950-publisher-and-subscrib...
>>
>>
>> It gave the impression that maybe OpenDDS doesn't support a publisher
>> and subscriber in the same process. IF this is the case, then it seems
>> to rule out its use in orocos.
>
> No, not at all! We designed Orocos/RTT to be communication middleware
> agnostic, _except_ for in-process communication. On other words, the
> "weakness" of OpenDDS is not at all a weakness in realtime contexts,
> because RTT has _very good_ alternatives. And that's not a coincidence: we
> knew that generic middleware would always be worse than the very
> application/platform specific optimal architectures that hard realtime
> developers will want to use :-)
It seems like you (and Davide Faconti, in another post) are hinting that
the appropriate use of DDS is for transporting data between an Orocos
process and the rest of the world. This in turn implies a design where
you have an Orocos process, with all its TaskContexts interconnected by
Orocos dataports, and one "Gateway" TaskContext that communicates with
the rest of the world.
My motivation for getting into DDS is slightly different. I imagine a
system( system==1+ nodes, 1+ processes in each node, 1+ threads in each
process) that has ONE "data highway/bus" (DDS Domain) going through it.
(Think of it as a software CAN bus, with QoS). The nodes, their
processes, and the processes' threads are all directly connected to this
highway, and there can be publishers/subscribers in any of them. You can
add new functionality to the system by putting that functionality in a
thread of an existing process or a separate application process or in a
new node stuck onto the bus. This would depend on the requirements. You
can take functionality out of a thread and run it on a process on
another node, if you wish to. If and only if communication between
certain endpoints is not fast enough via this data highway, then and
only then should a more efficient, point-to-point connection (like an
orocos data port, or maybe ØMQ) be considered. Thus, DDS offers a common
API and removes the distinction between the participating entities..
they may a thread, or they may be processes on the same or different
machine. (This is partly inspired by ØMQ, which offers the same API for
inproc, IPC, TCP and multicast.) For a scenario like this, a DDS
implementation that doesn't support pubs/subs within the same process
becomes a bottleneck.
Since I haven't actually worked with DDS, it might be the case that its
within-process performance is so poor, that it can't be used for that in
any practical application. Are you suggesting this to be the case, or
were you making a more theoretical point by stating that, "Even if DDS
can't support within-process communication, that is still okay, because
most use cases don't require it."?
Regards,
Sagar
using non-realtime library function calls in a realtime componen
>
> It seems like you (and Davide Faconti, in another post) are hinting that
> the appropriate use of DDS is for transporting data between an Orocos
> process and the rest of the world.
No. What I mean is that you can use DDS to transport data from an Orocos
component X in process A to another Orocos component Y in process B.
Orocos (contrariwise to ROS) doesn't oblige you to have one process for one
component. You can pack several components into 1 single process. If
components share the same process, use RTT transport, if they don't use
DDS transport.
>From the point of view of the component itself, there should be no
difference and, ideally, the transport mechanism is decided at deployment
time, not at compilation time.
This in turn implies a design where
> you have an Orocos process, with all its TaskContexts interconnected by
> Orocos dataports, and one "Gateway" TaskContext that communicates with
> the rest of the world.
>
This would be the quickest way, unless you don't dig into internals of RTT
itself and you add the DDS transport in RTT.
The problem of the Gateway approach is that you need a _different_ gateway
for each applications, since you have to create the specific ports.
>
> My motivation for getting into DDS is slightly different. I imagine a
> system( system==1+ nodes, 1+ processes in each node, 1+ threads in each
> process) that has ONE "data highway/bus" (DDS Domain) going through it.
>
Me too :)
> (Think of it as a software CAN bus, with QoS). The nodes, their
> processes, and the processes' threads are all directly connected to this
> highway, and there can be publishers/subscribers in any of them. You can
> add new functionality to the system by putting that functionality in a
> thread of an existing process or a separate application process or in a
> new node stuck onto the bus. This would depend on the requirements. You
> can take functionality out of a thread and run it on a process on
> another node, if you wish to.
+1
> If and only if communication between
> certain endpoints is not fast enough via this data highway, then and
> only then should a more efficient, point-to-point connection (like an
> orocos data port, or maybe ØMQ) be considered.
Don't agree about this point: it would make much more sense to have the
application (the Deployer?) setting (by default) the RTT in-process
transport for components deployed on the same process and the DDS (or
CORBA, YARP, ROS, 0MQ...) for those ports between components in different
nodes/processes.
"Fast enough" is something different to measure.
> Thus, DDS offers a common
> API and removes the distinction between the participating entities..
>
No, the common API should be provided by RTT, which should hide the API of
DDS in the same way that nowadays it hides Xenomai, CORBA, etc.
> they may a thread, or they may be processes on the same or different
> machine. (This is partly inspired by ØMQ, which offers the same API for
> inproc, IPC, TCP and multicast.) For a scenario like this, a DDS
> implementation that doesn't support pubs/subs within the same process
> becomes a bottleneck.
>
the difference I see here is that you talk like "let's include RTT into
DDS", while I suggest "let's include DDS into RTT". :-)
>
> Since I haven't actually worked with DDS, it might be the case that its
> within-process performance is so poor, that it can't be used for that in
> any practical application.
It shouldn't, but it potentially add operations which are not needed. On
the other hand it worth to give it a try: may be they have an
implementation using shared memory that is equally efficient.
But I can hear the voice of Herman saying that shared memory isn't hard
real-time ;-)
> Are you suggesting this to be the case, or
> were you making a more theoretical point by stating that, "Even if DDS
> can't support within-process communication, that is still okay, because
> most use cases don't require it."?
>
I disagree... any real-time application DO require in-process
communication. This is the reason why ROS is spoiling robotic community ;-)
Davide
using non-realtime library function calls in a realtime componen
On 10/09/2012 11:03 AM, Davide Faconti wrote:
>
>
> It seems like you (and Davide Faconti, in another post) are hinting that
> the appropriate use of DDS is for transporting data between an Orocos
> process and the rest of the world.
>
>
> No. What I mean is that you can use DDS to transport data from an Orocos
> component X in process A to another Orocos component Y in process B.
> Orocos (contrariwise to ROS) doesn't oblige you to have one process for
> one component. You can pack several components into 1 single process. If
> components share the same process, use RTT transport, if they don't
> use DDS transport.
> From the point of view of the component itself, there should be no
> difference and, ideally, the transport mechanism is decided at
> deployment time, not at compilation time.
>
> This in turn implies a design where
> you have an Orocos process, with all its TaskContexts interconnected by
> Orocos dataports, and one "Gateway" TaskContext that communicates with
> the rest of the world.
>
>
> This would be the quickest way, unless you don't dig into internals of
> RTT itself and you add the DDS transport in RTT.
> The problem of the Gateway approach is that you need a _different_
> gateway for each applications, since you have to create the specific ports.
>
>
> My motivation for getting into DDS is slightly different. I imagine a
> system( system==1+ nodes, 1+ processes in each node, 1+ threads in each
> process) that has ONE "data highway/bus" (DDS Domain) going through it.
>
>
> Me too :)
>
> (Think of it as a software CAN bus, with QoS). The nodes, their
> processes, and the processes' threads are all directly connected to this
> highway, and there can be publishers/subscribers in any of them. You can
> add new functionality to the system by putting that functionality in a
> thread of an existing process or a separate application process or in a
> new node stuck onto the bus. This would depend on the requirements. You
> can take functionality out of a thread and run it on a process on
> another node, if you wish to.
>
>
> +1
>
> If and only if communication between
> certain endpoints is not fast enough via this data highway, then and
> only then should a more efficient, point-to-point connection (like an
> orocos data port, or maybe ØMQ) be considered.
>
>
> Don't agree about this point: it would make much more sense to have the
> application (the Deployer?) setting (by default) the RTT in-process
> transport for components deployed on the same process and the DDS (or
> CORBA, YARP, ROS, 0MQ...) for those ports between components in
> different nodes/processes.
>
> "Fast enough" is something different to measure.
>
> Thus, DDS offers a common
> API and removes the distinction between the participating entities..
>
>
> No, the common API should be provided by RTT, which should hide the API
> of DDS in the same way that nowadays it hides Xenomai, CORBA, etc.
Yes, what you say makes a lot of sense. I hadn't appreciated the full
impact of having a DDS transport for RTT. Thanks for clarifying. Could
you clarify one more point:
If the DDS implementation does not support a publisher and subscriber in
the same process, then is it correct to say that a DDS transport for RTT
based on that DDS implementation cannot be used for connecting
taskcontexts in the same process? This seems rather obvious.. so if you
wish to use the DDS transport between TC A and B in the same process,
and then have a different process on a different computer subscribe to
the topics flowing between A and B.. well, you can't. Ergo, it is good
to use a DDS implementation that does not have the within-process
restriction.
> Since I haven't actually worked with DDS, it might be the case that its
> within-process performance is so poor, that it can't be used for that in
> any practical application.
>
>
> It shouldn't, but it potentially add operations which are not needed. On
> the other hand it worth to give it a try: may be they have an
> implementation using shared memory that is equally efficient.
> But I can hear the voice of Herman saying that shared memory isn't hard
> real-time ;-)
The OpenSplice docs do say that in their implementation, each node has
one big lump of shared memory, which is always used for communication
between processes of the same physical box. Communication between
different boxen is handled by a 'network-scheduler' the schedules the
transports based on QoS. They claim that the shared memory makes the
implementation very fast and efficient. In fact, in the latest
(commercial) version, I see a deployment options of 'SingleProcess' and
'Federated' (which can be mixed)
http://www.prismtech.com/opensplice/products/scalability-usability
/Sagar
using non-realtime library function calls in a realtime componen
>
> Yes, what you say makes a lot of sense. I hadn't appreciated the full
> impact of having a DDS transport for RTT. Thanks for clarifying. Could you
> clarify one more point:
>
> If the DDS implementation does not support a publisher and subscriber in
> the same process, then is it correct to say that a DDS transport for RTT
> based on that DDS implementation cannot be used for connecting taskcontexts
> in the same process?
Probably yes.
> This seems rather obvious.. so if you wish to use the DDS transport
> between TC A and B in the same process, and then have a different process
> on a different computer subscribe to the topics flowing between A and B..
> well, you can't. Ergo, it is good to use a DDS implementation that does not
> have the within-process restriction.
Forget for one second about DDS and RTT. From an abstract point of view,
what you want are:
1) "ports" which move data from one point to another using the
publish-subscribe model.
2) the freedom to deploy component as you wish: on the same process or on
two different nodes. ideally your code should NOT change according to the
way you deploy components. Not only, you don't even want to recompile it.
So, the port is just an abstraction. Think now about familiar concepts in
OOP, such as base classes and polymorphism. The base class (let's call it
Port) provide an abstraction, while the derived classes (PortRTT and
PortDDS) provide an implementation.
You can decide at run-time to instantiate either PortRTT or PortDDS, but
from the point of view of your code , you just see the API provided by the
abstract Port.
Let's come back to the point: you worry too much about DDS. The decision to
use DDS, or posix MQ or RTT in-process transport (or whatever) can be taken
at deployment time. When you deploy the system you have knowledge of where
component are (their node and process), so you have all the information to
take the right decision to instantiate a certain implementation of the
transport mechanism or another.
Of course your question is, what happen if at the beginning I was sure that
inter-process communication wasn't needed on a certain port and all of a
sudden some components come from the "outside" and want to subscribe? Then
you don't have DDS when you do want to have DDS.
This is an interesting question indeed and I don't really have a fully
satisfactory answer here. A solution might be that under the hood the
publisher always instantiate the two implementations, RTT in-process
transport and DDS publisher. So when you write on a port, you are actually
publishing on two transport "middlewares". But since the amount of
processing/overhead is proportional to the number of subscribers, this
shouldn't represent any waste (just a worse footprint maybe, but not a
computational overhead).
I am sure that Sylvain can figure out a more clever solution :-D
> It shouldn't, but it potentially add operations which are not needed. On
>> the other hand it worth to give it a try: may be they have an
>> implementation using shared memory that is equally efficient.
>> But I can hear the voice of Herman saying that shared memory isn't hard
>> real-time ;-)
>>
>
> The OpenSplice docs do say that in their implementation, each node has one
> big lump of shared memory, which is always used for communication between
> processes of the same physical box. Communication between different boxen
> is handled by a 'network-scheduler' the schedules the transports based on
> QoS. They claim that the shared memory makes the implementation very fast
> and efficient. In fact, in the latest (commercial) version, I see a
> deployment options of 'SingleProcess' and 'Federated' (which can be mixed)
>
> http://www.prismtech.com/**opensplice/products/**scalability-usability<h...
>
> /Sagar
>
Good to know.
Davide
using non-realtime library function calls in a realtime componen
On 10/09/2012 11:03 AM, Davide Faconti wrote:
>
> I disagree... any real-time application DO require in-process
> communication. This is the reason why ROS is spoiling robotic
> community ;-)
RTT can do realtime IPC using posix MQ
using non-realtime library function calls in a realtime componen
2012/10/9 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> On 10/09/2012 11:03 AM, Davide Faconti wrote:
>
>>
>> I disagree... any real-time application DO require in-process
>> communication. This is the reason why ROS is spoiling robotic community ;-)
>>
> RTT can do realtime IPC using posix MQ
>
>
Indeed. But DDS has a LOT of things that the MQ implementation don't have,
in particular the QoS part, something badly needed for "serious"
applications (and ignored so far in the robotic community).
But this is just the top of the iceberg: DDS won't me as fast as MQ, but
gives to you a lot more IMHO.
Davide
using non-realtime library function calls in a realtime componen
On 10/09/2012 11:51 AM, Davide Faconti wrote:
>
>
> 2012/10/9 Sylvain Joyeux <sylvain [dot] joyeux [..] ...
> <mailto:sylvain [dot] joyeux [..] ...>>
>
> On 10/09/2012 11:03 AM, Davide Faconti wrote:
>
>
> I disagree... any real-time application DO require in-process
> communication. This is the reason why ROS is spoiling robotic
> community ;-)
>
> RTT can do realtime IPC using posix MQ
>
>
>
> Indeed. But DDS has a LOT of things that the MQ implementation don't
> have, in particular the QoS part, something badly needed for "serious"
> applications (and ignored so far in the robotic community).
My hunch is that you don't need QoS if you don't use shared,
bandwidth-limited medium. Localhost communication hardly falls in that
category.
> But this is just the top of the iceberg: DDS won't me as fast as MQ,
> but gives to you a lot more IMHO.
Not my point. I was just reacting to the "any real-time application does
require in-process communication". Not true, one can do IPC and keep RT
behaviour.
Sylvain
using non-realtime library function calls in a realtime componen
On 10/09/2012 12:02 PM, Sylvain Joyeux wrote:
>
>>
>> Indeed. But DDS has a LOT of things that the MQ implementation don't
>> have, in particular the QoS part, something badly needed for
>> "serious" applications (and ignored so far in the robotic community).
> My hunch is that you don't need QoS if you don't use shared,
> bandwidth-limited medium. Localhost communication hardly falls in that
> category.
For those that don't know what the posix MQ can do: they only work on
same-host IPC.
using non-realtime library function calls in a realtime componen
On Tue, Oct 09, 2012 at 12:07:33PM +0200, Sylvain Joyeux wrote:
> For those that don't know what the posix MQ can do: they only work on
> same-host IPC.
Once again - we should not limit ourselves to a particular implementation. For
example, QNX provides distributed, real-time POSIX message queues.
Unfortunately, Linux is not a reference OS when it comes to the real-time
issues...
using non-realtime library function calls in a realtime componen
On Tue, Oct 9, 2012 at 12:07 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
> On 10/09/2012 12:02 PM, Sylvain Joyeux wrote:
>
>>
>>
>>> Indeed. But DDS has a LOT of things that the MQ implementation don't
>>> have, in particular the QoS part, something badly needed for "serious"
>>> applications (and ignored so far in the robotic community).
>>>
>> My hunch is that you don't need QoS if you don't use shared,
>> bandwidth-limited medium. Localhost communication hardly falls in that
>> category.
>>
> For those that don't know what the posix MQ can do: they only work on
> same-host IPC.
>
>
The question, as I said before, "what if (at run-time) a component on node
B wants to subscribe to a certain dataport in node A and this new
subscription wasn't expected?".
If the transport mechanism chosen was the MQ, than this is not possible. We
would need component A to be able to instantiate the DDS publishing at
run-time, am I wrong? Would it me difficult to do that?
ROS, just to make example, supports this kind of loose coupling that is
very convenient. System deployment is resolved completely at run-time, and
no previous knowledge about where the processes are is needed.
Davide
using non-realtime library function calls in a realtime componen
On Tue, Oct 9, 2012 at 12:16 PM, Davide Faconti
<faconti [..] ...> wrote:
...
>
> The question, as I said before, "what if (at run-time) a component on node B
> wants to subscribe to a certain dataport in node A and this new subscription
> wasn't expected?".
> If the transport mechanism chosen was the MQ, than this is not possible. We
> would need component A to be able to instantiate the DDS publishing at
> run-time, am I wrong? Would it me difficult to do that?
This was the whole point of RTT 2.0 :-) Our ports (both IN *and* OUT)
are multi-transport. So you can receive data from anywhere, using any
transport at the same time, and the other way around.
Peter
using non-realtime library function calls in a realtime componen
This seems relevant to the discussion. It looks like RTI didn't want to lose out to PrismTech.
http://www.rti.com/company/news/infrastructure-community.html
Having the source certainly beats getting binaries only and needing to renew our license every year like we used to.
Geoff
using non-realtime library function calls in a realtime componen
On 10/10/2012 11:02 AM, Geoffrey Biggs wrote:
> This seems relevant to the discussion. It looks like RTI didn't want to lose out to PrismTech.
>
> http://www.rti.com/company/news/infrastructure-community.html
Nice. RTI is offering the latest version under their community licencse,
as compared to PrismTech, whose community edition lags behind their
commercial one by one major release
Their "open source" license seems to be home-cooked.
http://www.rti.com/downloads/IC-license.html
It is not one of the approved OSI licenses
http://opensource.org/licenses/index.html
[ I'm not a lawyer; but licensing burned me once. ]
For a fun (if that's your sort of thing) read:
RTI seems to use the term 'Open Source 2.0'
http://www.rti.com/company/news/open-source-2-0.html
and PrismTech's CTO took a potshot
http://www.prismtech.com/blog/genuine-open-source-software-angelo-corsaro
/Sagar
using non-realtime library function calls in a realtime componen
It is clear that there is a problem with the RTI license is this
"Infrastructure
Community".
Basically those who get the code "open" can be only those
institutions/companies which have been approved by RTI. So, if you are not
in the "club", no source code.
On the other hand, you can apparently distribute binaries to anyone under
some restrictions that I consider reasonable from a company point of view.
So companies might accept this license from a pragmatic point of view but
academy, probably, will consider this extremely limiting.
Just my two cents...
Davide
using non-realtime library function calls in a realtime componen
On Oct 10, 2012, at 6:37 PM, Davide Faconti wrote:
> It is clear that there is a problem with the RTI license is this "Infrastructure Community".
>
> Basically those who get the code "open" can be only those institutions/companies which have been approved by RTI. So, if you are not in the "club", no source code.
> On the other hand, you can apparently distribute binaries to anyone under some restrictions that I consider reasonable from a company point of view.
>
> So companies might accept this license from a pragmatic point of view but academy, probably, will consider this extremely limiting.
So in other words, it's basically the same as their old "R&D licence" system. I guess nothing has really changed, then.
Certainly, it seems a stretch to actually call it "open source."
Geoff
using non-realtime library function calls in a realtime componen
On 10/09/2012 12:16 PM, Davide Faconti wrote:
>
>
> The question, as I said before, "what if (at run-time) a component on
> node B wants to subscribe to a certain dataport in node A and this new
> subscription wasn't expected?".
You don't expect subscriptions, or connections, in RTT. You connect
ports at runtime.
> If the transport mechanism chosen was the MQ, than this is not
> possible. We would need component A to be able to instantiate the DDS
> publishing at run-time, am I wrong? Would it me difficult to do that?
>
> ROS, just to make example, supports this kind of loose coupling that
> is very convenient. System deployment is resolved completely at
> run-time, and no previous knowledge about where the processes are is
> needed.
Except that ROS requires you to use the ROS transport.
With RTT, you deploy ANY port on ANY transport at runtime. No strings
attached. As I said on a previous answer, a given port can even be
SIMULTANEOUSLY using multiple transports. Which is something we use heavily.
So, yes, you have a completely decoupled system.
using non-realtime library function calls in a realtime componen
>
> With RTT, you deploy ANY port on ANY transport at runtime. No strings
> attached. As I said on a previous answer, a given port can even be
> SIMULTANEOUSLY using multiple transports. Which is something we use heavily.
>
> So, yes, you have a completely decoupled system.
>
>
Good news for Sagar, aren't they?
using non-realtime library function calls in a realtime componen
>
> But this is just the top of the iceberg: DDS won't me as fast as MQ, but
> gives to you a lot more IMHO.
>
> Not my point. I was just reacting to the "any real-time application does
> require in-process communication". Not true, one can do IPC and keep RT
> behaviour.
>
>
I stand corrected ;-)
using non-realtime library function calls in a realtime componen
On Tue, Oct 09, 2012 at 11:03:59AM +0200, Davide Faconti wrote:
> > Are you suggesting this to be the case, or were you making a more
> > theoretical point by stating that, "Even if DDS can't support
> > within-process communication, that is still okay, because most use cases
> > don't require it."?
> >
>
> I disagree... any real-time application DO require in-process
> communication. This is the reason why ROS is spoiling robotic community ;-)
I disagree... On QNX one can build a real-time application that consists of
several processes (and even distribute them across different PCs). The
performance will be worst, but still deterministic.
It is simply more convenient to manage components from a standard shell if they
are mapped to processes.
using non-realtime library function calls in a realtime componen
On 10/09/2012 10:49 AM, Sagar Behere wrote:
> It seems like you (and Davide Faconti, in another post) are hinting that
> the appropriate use of DDS is for transporting data between an Orocos
> process and the rest of the world. This in turn implies a design where
> you have an Orocos process, with all its TaskContexts interconnected by
> Orocos dataports, and one "Gateway" TaskContext that communicates with
> the rest of the world.
Not at all. A single task contexts (and even a single port !) can be
transported by different layers. As an example: we connect ports using
Posix MQ when the tasks are within the same machine, using no transport
at all when they are in the same process and using CORBA when they are
on different machines. The same port can be connected by all three
transports at the same time, depending on the context.
using non-realtime library function calls in a realtime componen
>
> However, you are only talking about RTI. How are the open-source DDS
> implementation comparing (as e.g. opendds ?)
>
I was trying to find an answer to this question, but I haven't found any
real data that compares OpenSplice and RTI. For your information (I like to
add noise) someone might want to look at with http://www.opendds.org/
Davide
using non-realtime library function calls in a realtime componen
On Mon, Oct 08, 2012 at 10:11:29PM +0900, Geoffrey Biggs wrote:
> In my opinion, the only difficulty with DDS in robotics is convincing others
> that they can and should be using it over inventing their own transports.
The difficulty I have found in using "heavy weight" middleware solutions is
their portability. For example, I have not found any implementation of CORBA
that works on QNX (*). On the other hand, "lightweight" solutions like 0MQ just
works or require only trivial patching.
I am afraid that there may be a similar problem with platforms like Xenomai...
(*) It was some years ago, so maybe this was solved in the meantime.
using non-realtime library function calls in a realtime componen
On Oct 8, 2012, at 10:53 PM, Piotr Trojanek wrote:
> On Mon, Oct 08, 2012 at 10:11:29PM +0900, Geoffrey Biggs wrote:
>> In my opinion, the only difficulty with DDS in robotics is convincing others
>> that they can and should be using it over inventing their own transports.
>
> The difficulty I have found in using "heavy weight" middleware solutions is
> their portability. For example, I have not found any implementation of CORBA
> that works on QNX (*). On the other hand, "lightweight" solutions like 0MQ just
> works or require only trivial patching.
>
> I am afraid that there may be a similar problem with platforms like Xenomai...
>
> (*) It was some years ago, so maybe this was solved in the meantime.
RTI and one of the other DDS providers (I can't remember which, it may have been Prismtech's) provide versions of DDS for embedded systems. I've also heard that RTI also provides good support for operating systems such as QNX, as a lot of their customers rely on QNX as well.
Geoff
using non-realtime library function calls in a realtime componen
On 10/08/2012 03:11 PM, Geoffrey Biggs wrote:
> On Oct 8, 2012, at 8:27 PM, Sagar Behere wrote:
>> On 10/08/2012 10:10 AM, Herman Bruyninckx wrote:
>>> On Mon, 8 Oct 2012, Charles Lesire-Cabaniols wrote:
>>>> 2012/10/8 Ruben Smits<ruben [dot] smits [..] ...>
>>>> Do not hesitate to publish it; you can even push it on the orocos-communication Gitorious
>>>> project!
>>
>> Oh wow! I had no idea others were interested in this :)
>>
>> I was planning a series of coding hacks to make DDS work
>> For-Me-For-Now(tm), but it seems that developing a DDS transport is the
>> 'clean' way to go.
>>
>> I don't know much about DDS, or orocos internals for that matter, but
>> okay, I'm willing to do this and of course it'll be open source and
>> available for the community.
>>
>> I will read the code for the YARP/mqueue transports and join the
>> developers mailing list where I can ask more detailed questions.
>
> We added DDS support to our middleware over a year ago and have never looked back. In my opinion, there is simply no comparison between DDS and any other transport for data-flow communications, and the implementation we used (RTI) was considerably faster in our tests than our CORBA-based transport. The fact that RTI's implementation supports real-time data transfer and that the C++ API is standardised (so software written for one implementation can be used for others with no, or minimal, code changes) are also great features, but the killer feature is the QoS settings that are available. Everything you need to set to control the efficiency, real-time safety and reliability of every individual communication is there.
>
> For example, if you want a specific instance of DDS to be real-time safe, you can configure QoS settings to ensure that all memory is allocated at setup time by specifying the maximum number of history samples to keep, size of arrays, maximum number of connections to allow, etc.
Have you used RTI DDS with Xenomai? When you configure your DDS code as
you mention above, does your thread run in Xenomai primary mode?
I have not checked with OpenSplice DDS if configuring QoS the way you
describe it will keep the thread in realtime. The only reference to
OpenSplice+Xenomai is this forum post, which seems to indicate that
having the whole of OpenSplice DDS compiled against the Xenomai POSIX
skin isn't impossible
http://forums.opensplice.org/index.php?/topic/1789-dds-and-xenomai/
My reasons for choosing OpenSplice is that it has a community edition
licensed under LGPLv3. Even their commercial edition is LGPLv3.
Is there a reason you specifically chose RTI over OpenSplice?
/Sagar
using non-realtime library function calls in a realtime componen
On Oct 8, 2012, at 10:20 PM, Sagar Behere wrote:
> On 10/08/2012 03:11 PM, Geoffrey Biggs wrote:
>> We added DDS support to our middleware over a year ago and have never looked back. In my opinion, there is simply no comparison between DDS and any other transport for data-flow communications, and the implementation we used (RTI) was considerably faster in our tests than our CORBA-based transport. The fact that RTI's implementation supports real-time data transfer and that the C++ API is standardised (so software written for one implementation can be used for others with no, or minimal, code changes) are also great features, but the killer feature is the QoS settings that are available. Everything you need to set to control the efficiency, real-time safety and reliability of every individual communication is there.
>>
>> For example, if you want a specific instance of DDS to be real-time safe, you can configure QoS settings to ensure that all memory is allocated at setup time by specifying the maximum number of history samples to keep, size of arrays, maximum number of connections to allow, etc.
>
> Have you used RTI DDS with Xenomai? When you configure your DDS code as
> you mention above, does your thread run in Xenomai primary mode?
I have not tried with Xenomai. We use it with the rtpreempt Linux kernel patches and get satisfactory real time performance.
> I have not checked with OpenSplice DDS if configuring QoS the way you
> describe it will keep the thread in realtime. The only reference to
> OpenSplice+Xenomai is this forum post, which seems to indicate that
> having the whole of OpenSplice DDS compiled against the Xenomai POSIX
> skin isn't impossible
>
> http://forums.opensplice.org/index.php?/topic/1789-dds-and-xenomai/
>
> My reasons for choosing OpenSplice is that it has a community edition
> licensed under LGPLv3. Even their commercial edition is LGPLv3.
>
> Is there a reason you specifically chose RTI over OpenSplice?
We chose RTI because they offered good support at a good price (i.e. free because we're a research institute), and because, through our involvement with the OMG, we could nag people fairly high up at RTI whenever we had problems. :)
Geoff
using non-realtime library function calls in a realtime componen
On Oct 8, 2012, at 4:57 PM, Charles Lesire-Cabaniols wrote:
> I think developing a DDS transport will be useful for other Orocos users.
> Do not hesitate to publish it; you can even push it on the orocos-communication Gitorious project!
Support for DDS in Orocos would be of enormous benefit. If someone implements it, please release it so we can all use it!
Geoff
using non-realtime library function calls in a realtime componen
>
> Support for DDS in Orocos would be of enormous benefit. If someone
> implements it, please release it so we can all use it!
>
+1