rti DDS 5.3.1 and ROS2 eloquent, topic not received

10 posts / 0 new
Last post
Offline
Last seen: 3 weeks 3 days ago
Joined: 10/08/2018
Posts: 9
rti DDS 5.3.1 and ROS2 eloquent, topic not received

I want to get a native rti DDS 5.3.1 application running with ROS2 eloquent. For this, I have written a plugin for the rti routing service and set it up to convert messages from native DDS topic to ROS2 eloquent topics.

According to the rtiadminconsole everyting seems fine. The Match Analyses has no complains and I can subscribe and receive the ROS2 topic within the rtiadminconsole. However, in the ROS2 subscriber the subscriber callback method is never called.

How can I further investiagte this issue?

Keywords:
Offline
Last seen: 3 weeks 5 days ago
Joined: 11/14/2017
Posts: 11

Hi Andreas,

This sounds like something within the RS plugin, separate from anything specific to ROS2.

Depending on your needs, you may be able to do this directly (without RS); since ROS2 is typically built on top of DDS, all of its communications are on DDS as well.
This means that interop between native DDS apps and ROS2(on DDS) apps enjoy the standards-based interoperability of DDS, with any version of Connext.

The key is to use ROS2 data types in your native DDS applications, for any topics that you'd like to interop with ROS2 applications.
That, and (of course): compatible QoS, and a matching topic name.

For example, suppose I wanted a native DDS application to move the default turtle in 'turtlesim'; this would need:
 - Data type: geometry_msgs::msg::dds_::Twist_
 - Topic name: rt/turtle1/cmd_vel
 - QoS: Reliable or BestEffort (ROS2 has limited options).
That's it.   No RS needed, and it's similarly straightforward for a native DDS app to interact with ROS2 services, actions, or parameters.
You have complete freedom to intermix native DDS and ROS2 components -- because ROS2 is a DDS application.

I've placed an IDL file of all of the data type definitions used in ROS2 'eloquent' at: https://github.com/neil-rti/ros-data-types/blob/master/all_msgs/ros2interop/ros2-eloquent-all.idl
-- this can be used with RTI DDS code generator to create the typesupport code for whatever part of ROS2 you'd like to use in your native DDS applications.

Please reply if this seems like a better option -- or if not, so we can get some attention onto the trouble with the RS plug-in you're creating.

Thanks!

Offline
Last seen: 3 weeks 3 days ago
Joined: 10/08/2018
Posts: 9

Hi neil-rti

Thanks for your explanation. The reason we decided to use the routing service is that moving our whole code base from our own data types to the ROS2 data types is too much effort especially when we don't know yet if it really works. We believe that the routing service allows us the integration of some ROS2 components into our system. This way we don't have to rebuild the whole system with ROS2 but can move step by step.

Below I have a screenshot showing that the topics match (between the RTI Routing Service and the ROS2 node (transform_subscriber)). I can subscrube to the "rt/rcv_transform" topic within the rtiadminconsole and do receive the messages. Therefore, I believe the data types match and the QoS settings as well. You can also see that field names of the ROS2 node have a "_" at the end.

Matched topic in rtiadminconsole

I appreciate any further help. It would be so great if we could integrate ROS2 into our native rti DDS application.

Offline
Last seen: 3 weeks 3 days ago
Joined: 10/08/2018
Posts: 9

Hi neil-rti

Me again. Do you have a ROS2 template USER_QOS_PROFIL.xml? If yes, could you please share it.

Cheers,

Andreas

Offline
Last seen: 3 weeks 5 days ago
Joined: 11/14/2017
Posts: 11

Hi Andreas,

Actually, I've been using the default USER_QOS_PROFILE.xml file that is created by RTI Codegen, and will sometimes change it to use Generic.BestEffort reliability -- but otherwise, have not needed any special settings to interoperate with ROS2.

Try using RTI CodeGen to create a pub&sub example for geometry_msgs::msg::dds_::TransformStamped_ data type, and publish to ROS2 using the unmodified USER_QOS_PROFILES.xml file from the generated example.

Questions: does the callback in the ROS2 application (for received samples) get called when another ROS2 application publishes to it?
Also -- what is the ROS2 application that is receiving the published samples?    Can they be received by (for instance) rqt?

Thanks - Neil

Offline
Last seen: 3 weeks 3 days ago
Joined: 10/08/2018
Posts: 9

Hi neil-rti

I created a geometry_msgs::msg::dds_::TransformStamped_ publisher. When I don't have any USER_QOS_PROFILES.xml present, the publisher and the subscriber match (seen in the rtiadminconsole) and the subscriber receives the messages. Then, I created a USER_QOS_PROFILES.xml with the command /opt/rti_connext_dds-5.3.1/bin/rtiddsgen -create examplefiles -update typefiles -language C++11 -I idl idl/geometry_msgs/msg/TransformStamped.idl. Now when I start the publisher, I get the following error:

PRESParticipant_checkTransportInfoMatching:Warning: discovered remote participant 'RTI Administration Console' using the 'shmem' transport with class ID 16777216. This class ID does not match the class ID 2 of the same transport in the local participant 'minimal_publisher'. These two participants will not communicate over the 'shmem' transport. Check the value of the property 'dds.transport.use_510_compatible_locator_kinds' in the local participant. See https://community.rti.com/kb/what-causes-error-discovered-remote-participant for additional info. COMMENDBeWriterService_assertRemoteReader:Discovered remote reader with GUID 0X101B8B9,0XF38BCC9E,0XB4C09B41,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: shmem://508B:2F0F:1EDD:2470:D06A:ACC9:0000:0000:7410 COMMENDSrWriterService_assertRemoteReader:Discovered remote reader with GUID 0X101B8B9,0XF38BCC9E,0XB4C09B41,0X20087 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: shmem://508B:2F0F:1EDD:2470:D06A:ACC9:0000:0000:7410 COMMENDSrWriterService_assertRemoteReader:Discovered remote reader with GUID 0X101B8B9,0XF38BCC9E,0XB4C09B41,0X4C7 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: shmem://508B:2F0F:1EDD:2470:D06A:ACC9:0000:0000:7410 COMMENDSrWriterService_assertRemoteReader:Discovered remote reader with GUID 0X101B8B9,0XF38BCC9E,0XB4C09B41,0X3C7 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: shmem://508B:2F0F:1EDD:2470:D06A:ACC9:0000:0000:7410 DDS_ResourceLimitsQosPolicy_is_consistent_w_historyI:inconsistent QoS policies: history.depth and resource_limits.max_samples (max_samples_per_instance is unlimited)

DDS_Subscriber_create_datareader_disabledI:ERROR: Inconsistent QoS DDSDataReader_impl::create_disabledI:!create reader DDSDataReader_impl::createI:!create reader initialize:!create DataReader connext::details::EntityUntypedImpl::initialize:!failed (see previous errors) >>> [rcutils|error_handling.c:107] rcutils_set_error_state() This error state is being overwritten: 'C++ exception during construction of Requester, at /tmp/binarydeb/ros-eloquent-rcl-interfaces-0.8.0/obj-x86_64-linux-gnu/rosidl_typesupport_connext_cpp/rcl_interfaces/srv/dds_connext/get_parameters__type_support.cpp:704' with this new error message: 'failed to create replier, at /tmp/binarydeb/ros-eloquent-rmw-connext-cpp-0.8.1/src/rmw_service.cpp:138' rcutils_reset_error() should be called after error handling to avoid this. <<< terminate called after throwing an instance of 'rclcpp::exceptions::RCLError' what(): could not create service: failed to create replier, at /tmp/binarydeb/ros-eloquent-rmw-connext-cpp-0.8.1/src/rmw_service.cpp:138, at /tmp/binarydeb/ros-eloquent-rcl-0.8.4/src/rcl/service.c:179

I guess the first part comes from the fact that I have the rtiadminconsole open but the errors on the buttom seems some rti DDS / ROS2 problem. Do you ever encoutered this? I attached the USER_QOS_PROFILES.xml

File Attachments: 
Offline
Last seen: 3 weeks 3 days ago
Joined: 10/08/2018
Posts: 9

Hi neil-rti

Are you still here? I would really appreciate your help.

Kind Regards,

Andreas

Offline
Last seen: 3 weeks 5 days ago
Joined: 11/14/2017
Posts: 11

Hi Andreas,

Apologies for the delay -- I'm not sure why I'm not getting notifications on this thread; will investigate.

Yes, that warning is caused by the use of "510 compatibility" in the Connext ROS2 RMW.
(this is being removed in the upcoming 'Foxy' release of ROS 2, see this link)

To resolve, add the following to your participant_qos settings on the non-ROS2 side:

<participant_qos>
  <property>
    <value>
      <element>
        <name>dds.transport.use_510_compatible_locator_kinds</name>
        <value>1</value>
      </element>
    </value>
  </property>
</participant_qos>            

Hope this helps (will look into notifications here).

Offline
Last seen: 3 weeks 3 days ago
Joined: 10/08/2018
Posts: 9

Hi neil-rti

After a clean rebuild (after I "activated" rti DDS 5.3.1 as middelware) it seems to work. Do I assume correctly that a rebuild is needed when the rmw is changed e.g. from standard to rti? What actually is this "510 compatibility mode"?

Kind regards,

Andreas

Offline
Last seen: 3 weeks 5 days ago
Joined: 11/14/2017
Posts: 11

Hi Andreas,

This gets a little bit into the internals of DDS: 510 compatibility mode is a way of dealing with earlier implementations of DDS wherein the transport identifier for Shared Memory was using a different value than what is used today. When an earlier and a recent DDS would try to connect on the same platform with shared memory transport enabled, the ID's would not match and no shared memory connection would be made, even though everything else would otherwise work (and a connection using some other transport might then be selected, such as UDP loopback). The QoS setting tells the newer DDS to accept the older transport ID as valid for shared memory.

More details on the message can be found here.

BTW, I toggled the notifications checkbox and I'm now back to receiving email updates on this thread.

Thanks -- Neil