RTI pub/subs are not able to communicate with eProsima FastDDS pub/subs

16 posts / 0 new
Last post
Offline
Last seen: 1 month 2 weeks ago
Joined: 11/03/2020
Posts: 22
RTI pub/subs are not able to communicate with eProsima FastDDS pub/subs

I'm running a bunch of tests trying to get FastDDS C++ publishers and subscribers to work with RTI's DDS implementation. My end goal is to have Unity apps use a native DDS implementation.

 

This is the basic IDL I'm using to generate code

 

// Nike.idl

struct Messenger {

   string msg;

};

 

I have built an eProsima FastDDS C++ project with this IDL, and I have generated a C++ project using RTI's code generator with the same IDL.

I can then run a FastDDS pub and sub, and data is sent and received as expected. Same results with RTI's pub and sub.

But when I try to get a FastDDS sub receive data from an RTI pub, the RTI generated programs throw an error about the remote reader usinng a non-addressable location

 

COMMENDSrWriterService_assertRemoteReader:Discovered remote reader with GUID 0X10F8CF0,0XD8000000,0X1000000,0X200C7 using a non-addressable locator. This can occur if the transport is not installed and/or enabled in the local participant. See https://community.rti.com/kb/what-does-cant-reach-locator-error-message-mean for additional info.
can't reach: locator: 16://558C:F000:0000:0000:0000:0000:0000:0000:7412

 

This is what the DDS Spy tool says:

 

 

Here is the FastDDS sub reading in the black, and the RTI pub and sub writing and listening in the blue:

 

I followed that link produed in that error and read what it said

https://community.rti.com/kb/what-does-cant-reach-locator-error-message-mean

 

So, I understand what the problem is. I'm just not sure how to remedy it. I built both the FastDDS project and the RTI project straight out of the box.

Offline
Last seen: 1 month 2 weeks ago
Joined: 11/14/2017
Posts: 20

Hello g_reimer,

I've seen similar messages when interoperating FastRTPS and Connext, but these often do not prevent basic connectivity.
One thing that does have an effect is the type object compression used by default in Connext 6; this is (AFAIK) not supported in FastRTPS, but it can be disabled in Connext 6 by adding the following to the USER_QOS_PROFILES.xml file, under the <participant_qos> section:

<discovery_config>
  <endpoint_type_object_lb_serialization_threshold>
    -1
  </endpoint_type_object_lb_serialization_threshold>
</discovery_config>

This will disable the typeObject compression in your Connext 6 application, and may enable communications with the FastRTPS app.

Could you give this a try & reply back here?

Thanks!

Howard's picture
Offline
Last seen: 2 days 21 hours ago
Joined: 11/29/2012
Posts: 131

So, why do you need to use FastDDS as well as RTI Connext DDS?

Programming in Unity requires C#.  How are you expecting to have  an "end goal is to have Unity apps use a native DDS implementation"?  What DDS do you plan on using in your Unity apps?

RTI currently has 2 paths for using RTI Connext DDS in Unity...one is soon to be superceeded by the other.

1) Using RTI Connector for C#, https://rticommunity.github.io/rticonnextdds-connector-cs/

2) We will have a full .NET Standard 2.0 C# API for DDS compatible with Unity in our next release.  Unfortunately, our current C# API work only on Windows/Visual Studio.

 

Offline
Last seen: 1 month 2 weeks ago
Joined: 11/03/2020
Posts: 22

My plan is to somehow integrate the C# API (DLLs and all) into the Unity project and hope that something works. I haven't yet looked into it. I'm currently trying to verify that FastDDS will even work with Connext because our core simulation runs on FastDDS so that we can retain an open source license.

When I tried using the C# Connector I couldn't get anthing to work. The build scripts did nothing, and the Visual Studio example solutions it has won't open without crashing.

 

My company has various Unity apps that are all part of a single simulation, and the whole simulation uses DDS for communications. Because Unity doesn't use native DDS, we're currently using a TCP server that bridges Unity apps and DDS communications.

We're trying desparately to get rid of the middlelayer TCP server and run everything pure DDS.

Offline
Last seen: 1 month 2 weeks ago
Joined: 11/03/2020
Posts: 22

When you say Windows/Visual Studio, does that mean no support for Unity/Android deployment?
Our Unity apps are designed to run on Android tablets.

Offline
Last seen: 1 month 2 weeks ago
Joined: 11/03/2020
Posts: 22

I'm not sure to squeeze that block in. Does this look good?

 

<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:noNamespaceSchemaLocation="C:/Program Files/rti_connext_dds-6.0.1/bin/../resource/schema/rti_dds_qos_profiles.xsd">
    <!-- QoS Library containing the QoS profile used in the generated example.

        A QoS library is a named set of QoS profiles.
    -->
    <qos_library name="Nike_Library">

        <!-- QoS profile used to configure reliable communication between the DataWriter
             and DataReader created in the example code.

             A QoS profile groups a set of related QoS.
        -->

        <discovery_config>
          <endpoint_type_object_lb_serialization_threshold>
            -1
          </endpoint_type_object_lb_serialization_threshold>
        </discovery_config>
        
        <qos_profile name="Nike_Profile" base_name="BuiltinQosLib::Generic.StrictReliable" is_default_qos="true">
            <!-- QoS used to configure the data writer created in the example code -->
            <datawriter_qos>
                <publication_name>
                    <name>NikeDataWriter</name>
                </publication_name>
            </datawriter_qos>

            <!-- QoS used to configure the data reader created in the example code -->
            <datareader_qos>
                <subscription_name>
                    <name>NikeDataReader</name>
                </subscription_name>
            </datareader_qos>
            <participant_qos>
                <!--
                The participant name, if it is set, will be displayed in the
                RTI tools, making it easier for you to tell one
                application from another when you're debugging.
                -->
                <participant_name>
                    <name>NikeParticipant</name>
                    <role_name>NikeParticipantRole</role_name>
                </participant_name>

            </participant_qos>
        </qos_profile>



    </qos_library>
</dds>

Howard's picture
Offline
Last seen: 2 days 21 hours ago
Joined: 11/29/2012
Posts: 131

RTI's current C# API only works on Windows.  It does will not work if you try to run on Android.  It's based on .NET Core, and not .NET Standard.  In our next release, we'll have a new C# API based on .NET Standard, which should allow it to run on any platform that supports .NET Standard, including Android.

RTI Connector for C# is a stop-gap that could be used on Android, but you'll have to build it yourself and it works only with RTI Connext DDS.  So while you have access to the source for RTI Connector, you would still need a commercial version of RTI Connext DDS to incorporate into your company's simulation product.

Howard's picture
Offline
Last seen: 2 days 21 hours ago
Joined: 11/29/2012
Posts: 131

        <discovery_config>
          <endpoint_type_object_lb_serialization_threshold>
            -1
          </endpoint_type_object_lb_serialization_threshold>
        </discovery_config>

is a sub part of the Domain Participant QOS structure.  If you use an XML editor, like Visual Studio, and the XML schema at the top of the file, rti_dds_qos_profiles.xsd, should be used by the editor to help you edit the file.

You'll end up with something like:

            <participant_qos>
                <discovery_config>
                    <endpoint_type_object_lb_serialization_threshold> -a </endpoint_type_object_lb_serialization_threshold>
                </discovery_config>
            </participant_qos>

 

Offline
Last seen: 1 month 2 weeks ago
Joined: 11/03/2020
Posts: 22

Alrighty then. Thanks for your input, Howard. This has saved me hours of troubleshooting knowing what's possible.

Offline
Last seen: 1 month 2 weeks ago
Joined: 11/03/2020
Posts: 22

One more question, is it possible to integrate the current C# API into Unity for Windows deployment?
Would a C# RTI Connext build work with FastDDS? I'm still exploring this path.

Howard's picture
Offline
Last seen: 2 days 21 hours ago
Joined: 11/29/2012
Posts: 131

Unfortunately, I don't think so.  Unity requires the C# API to comply to .Net Standard.  So, I think you would have to use C# through RTI Connector if you want to work with Unity (Windows or otherwise).

RTI's programming language bindings, including C#, all work on top of the same C API-based Connext core engine.  So, assuming you can get a C/C++/Java-based Connext DDS application to interoperate with FastDDS, there shouldn't be any issues getting a C# Connext DDS application to interoperate.

 

Howard's picture
Offline
Last seen: 2 days 21 hours ago
Joined: 11/29/2012
Posts: 131

By the way, what's your company?  What kind of simulation systems do you produce?

Offline
Last seen: 1 month 2 weeks ago
Joined: 11/03/2020
Posts: 22

We do medical/paramedic simulations.

 

Quick question, I was told by someone in this thread that the C# connector is no longer maintained. So is it still usable?
https://community.rti.com/forum-topic/c-connector-build-script-doesnt-run-and-cnat-open-vs-solutions

Howard's picture
Offline
Last seen: 2 days 21 hours ago
Joined: 11/29/2012
Posts: 131

Interesting!  So, while RTI is not continuing to develop the C# integration of RTI Connector, RTI Connector itself is still an active project.  We will not be doing any more work on the C# part in anticipation of the upcoming full .NET Standard compliant C# DDS API.  So, don't expect any bug fixes, but certainly what's in Github now should be compilable and usable, i.e., works.

But RTI Connector is not a commercial product and so you'd have to rely on the community for any sort of support.

Finally, RTI Connector itself uses RTI Connext DDS, which is a commercial product and requires a commercial license.  If you plan on using RTI Connector in your system, even though RTI Connector doesn't require a commercial license, RTI Connext DDS does.  If you want to discuss how to go about doing that, I can put you in touch with the right people.

Offline
Last seen: 3 days 38 min ago
Joined: 04/02/2013
Posts: 152

Hi,

We now recommend the Preview release for the new .NET DDS API (compatible with .NET standard 2.0, including .NET 5). A production-ready release is expected by Q1 2021.

 

The preview is hosted on nuget and it requires a Connext DDS license file.

 

You can start using as follows:

$ dotnet new --install Rti.ConnextDds.Templates::0.0.5-alpha

$ mkdir MyExample

$ cd MyExample

$ dotnet new dds-console

 

That will generate a simple hello-world style application with a publisher and a subscriber. You can then build and run it:

$ export RTI_LICENSE_FILE=...

$ dotnet run -p MyExamplePublisher

$ dotnet run -p MyExampleSubscriber

 

You can still use Connector, but it is no longer maintained. It's also available as a nuget package: https://www.nuget.org/packages/RTI.Connext.Connector/0.3.3-alpha02

Offline
Last seen: 3 days 38 min ago
Joined: 04/02/2013
Posts: 152

I forgot to mention that the new .NET DDS API Preview is currently supported on Windows, x64 Linux and macOS, but not on ARM (yet).