Problem with RTI analyzer when using Qos xml file

Hello there

I have been fiddling with QoS profiles for an application. I have attempted to create a library with a number of profiles to be used for different entitites. My profiles inherit from various profiles in the builtin profiles.

The default profile is:

<qos_profile name="LwDefault" base_name="BuiltinQosLibExp::Generic.KeepLastReliable.TransientLocal"


Multicast TTL setting not being passed or set


We need DDS to be picked up over multiple subnets. I know that the default Multicast TTL setting is 1, which won't alllow this. I found the article here:


Routing Service Manual Liveliness


A simplified setup of our system is below:

Subsystem 1 (domain 0) --> Routing Service --> Rest of system (using Manual liveliness QoS settings, domain 1)

prevent loading QoS files more than once

I've got a plug in architecture that uses DDS and several QoS files, plug-ins can be started and stopped at any time.   So when I load QoS files into the DomainParticipantFactory, I also put them into a Vector<String>.   This way I can test to see if they're already loaded before adding them preventing errors when loading a QoS file multiple times.   


Is there a more elegant solution to doing this?     


RTI Connext Micro unique API and QoS

I am evaluating microDDS and am looking for a description of some of the micro DDS unique API's used in some of the examples provided with micro DDS.  These APIs are not described in the "RTI Connext Micro API and QoS Guide".  Specifically, in the HelloWorld_dpde example:

1. Configuration of the registry via RT_Registry_register()  for strings "wh", "rh",  "_udp" and  "dpde" strings.  What is the purpose of this function call and what is the signficance of the strings?


Using Machine Learning to Maintain Pub/Sub System QoS in Dynamic Environments

Dear Sir,

Please look over the following paper and inform me whether we can use RTI to maintain publish/subscribe system QoS in dynamic environments:


And I want also to know whether we can use machine learning techniques with RTI to maintain QoS for publish/subscribe system via autonomic adaptation.

Best regards,

Shadi Abudalfa


QoS ==> XML list

I saw a question in the General Questions forum related to default values of QoS parameters.  The answer pointed the user to the API reference guide.  However, that is still a very point-and-click (and time) intensive method to get the desired information for more than a few settings.  Does there exist a single document or web page which gives a comprehensive list of all settings and their related XML translation?  The "rti_dds_profiles.xsd" file does seem to contain much of this data but not in an easily read format...


The Robot Application Programming Interface Delegate (RAPID) is a set of software data structures and routines that simplify the process of communicating between multiple diverse robots and their command and control systems. RAPID is not intended to be an all-encompassing API for robot communication, but rather it’s a compatibility layer that permits tools and robotic assets to exchange data and information and allows operators to communicate with heterogeneous robots in a uniform way. RAPID is a compatibility layer that delegates information between robots that speak different languages.

The RAPID specification includes definitions and APIs for messages and services that support supervisory telerobotics operations over near-Earth time delay. RAPID is not a middleware specification, although safety and time-delay capabilities do imply requirements on implementing middleware systems. As currently implemented, the RAPID system can be considered a software reference implementation for remote operations.

For more information, contact David.S.Mittman@jpl.nasa.gov.



Subscribe to RSS - QoS