Communication between OpenDDS and ROS2 (eprosima Fast DDS)

[spelletier1996]

I would like to establish a communication between non ROS2 program running OpenDDS and ROS2 with eprosima Fast DDS as the middleware. I have been using the turtlesim example nodes as well as its respective topics (specifically the /turtle1/cmd_vel topic) but have not succeeded in actually establishing either a subscription or actual publication of data. ROS2 seems to be able to see the OpenDDS topics but something is missing preventing the final publishing. If any of the OpenDDS devs have any experience with OpenDDS and Fast DDS interoperability or with ROS2 your insight would be much appreciated.

What we have tried so far:

• Tried to both publish and subscribe using the Turtlesim cmd_vel example
• Found the OpenDDS topics in both the RQT topic monitor and ros2 topic info
• Matched the IDL data types with those build into ROS2 (geometry_msgs/msg/Twist)
• Updated the QoS policy to match that of ROS2 fast DDS as close as possible

Apologies if this is not the appropriate place for this type of question.

[mitza-oci]

We can help with this. Please add some combination of logs, wireshark packet capture, and steps to reproduce the issue. It would be ideal to have a minimal example using eProsima's DDS without ROS2, but since the ROS2 code is open source (and we are familiar with it) we can work with that too.

[spelletier1996]

Steps to reproduce:

• Install ROS2 Humble
• Install ROS2 Turtlesim using sudo apt install ros-humble-turtlesim
• Run the ROS2 TurtleSim Node ros2 run turtlesim turtlesim_node
• Publish to the /turtle1/cmd_vel topic using the Twist_ datatype to control the turtle via this code snippet, config file, and idl

The publisher is recognised by the ros command line tool ros2 topic info /turtle1/cmd_vel --verbose
which produces this output

Type: geometry_msgs/msg/Twist

Publisher count: 2

Node name: _CREATED_BY_BARE_DDS_APP_
Node namespace: _CREATED_BY_BARE_DDS_APP_
Topic type: geometry_msgs/msg/Twist
Endpoint type: PUBLISHER
GID: 01.03.18.c0.4d.8d.df.c1.80.28.f4.3f.00.00.00.03.00.00.00.00.00.00.00.00
QoS profile:
  Reliability: RELIABLE
  History (Depth): UNKNOWN
  Durability: VOLATILE
  Lifespan: Infinite
  Deadline: Infinite
  Liveliness: AUTOMATIC
  Liveliness lease duration: Infinite

Node name: teleop_turtle
Node namespace: /
Topic type: geometry_msgs/msg/Twist
Endpoint type: PUBLISHER
GID: 01.0f.fc.cb.d1.80.ac.d1.01.00.00.00.00.00.12.03.00.00.00.00.00.00.00.00
QoS profile:
  Reliability: RELIABLE
  History (Depth): UNKNOWN
  Durability: VOLATILE
  Lifespan: Infinite
  Deadline: Infinite
  Liveliness: AUTOMATIC
  Liveliness lease duration: Infinite

Subscription count: 1

Node name: turtlesim
Node namespace: /
Topic type: geometry_msgs/msg/Twist
Endpoint type: SUBSCRIPTION
GID: 01.0f.fc.cb.ce.7d.ba.a6.01.00.00.00.00.00.1b.04.00.00.00.00.00.00.00.00
QoS profile:
  Reliability: RELIABLE
  History (Depth): UNKNOWN
  Durability: VOLATILE
  Lifespan: Infinite
  Deadline: Infinite
  Liveliness: AUTOMATIC
  Liveliness lease duration: Infinite

With the second publisher visible being the ros2 run turtlesim turtle_teleop_key keyboard control node

the publisher seems to be recognised in the topic monitor as well but the subscriber never actually receives any of the messages where as the teleop_key works as intended and the published messages can be seen moving the turtle and with ros2 topic echo /turtle1/cmd_vel

At debug level 10 here is a snippet of the terminal output of the openDDS publish attempts

(46088|46088) TransportClient::send_i: no links for publication 010318c0.4d8ddfc1.b4083af9.00000003(1022fa75), not sending element 0x5623711faa98 for transaction: 1869.
(46088|46088) WriteDataContainer::data_delivered 0x5623711faa98
(46088|46088) WriteDataContainer::data_delivered: domain 0 topic rt/turtle1/cmd_vel publication 010318c0.4d8ddfc1.b4083af9.00000003(1022fa75) seq# 1869 released.
(46088|46088) WriteDataContainer::data_delivered: Inserting acked_sequence: 1869
(46088|46088) WriteDataContainer::data_delivered - broadcasting wait_for_acknowledgments update.
(46088|46088) DataWriterImpl::create_sample_data_message: from publication 010318c0.4d8ddfc1.b4083af9.00000003(1022fa75) sending data sample: SAMPLE_DATA (0x00), Length: 52, Byte order: Little Endian, CDR Encapsulation, Sequence: 0x74, Timestamp: 1668026374.883774000, Publication: 010318c0.4d8ddfc1.b4083af9.00000003(1022fa75) .
(46088|46088) TransportClient::send_i: no links for publication 010318c0.4d8ddfc1.b4083af9.00000003(1022fa75), not sending element 0x5623711faa98 for transaction: 1870.
(46088|46088) WriteDataContainer::data_delivered 0x5623711faa98
(46088|46088) WriteDataContainer::data_delivered: domain 0 topic rt/turtle1/cmd_vel publication 010318c0.4d8ddfc1.b4083af9.00000003(1022fa75) seq# 1870 released.
(46088|46088) WriteDataContainer::data_delivered: Inserting acked_sequence: 1870
(46088|46088) WriteDataContainer::data_delivered - broadcasting wait_for_acknowledgments update.
(46088|46088) DataWriterImpl::create_sample_data_message: from publication 010318c0.4d8ddfc1.b4083af9.00000003(1022fa75) sending data sample: SAMPLE_DATA (0x00), Length: 52, Byte order: Little Endian, CDR Encapsulation, Sequence: 0x74, Timestamp: 1668026374.883794000, Publication: 010318c0.4d8ddfc1.b4083af9.00000003(1022fa75) .

In terms of wireshark I'm unsure what I should be looking for, I am able to see the initial acknowledge attempt from OpenDDS and the FastDDS communication but don't really understand what I am looking for or what I should share here.

Let me know if there's anything else that could make this easier or is unclear I very much appreciate the help!

[mitza-oci]

Steps to reproduce:

* Install ROS2 Humble

* Install ROS2 Turtlesim using `sudo apt install ros-humble-turtlesim`

* Run the ROS2 TurtleSim Node `ros2 run turtlesim turtlesim_node`

Is there something we can run that doesn't require a graphical desktop? Would be great to just SSH in to the build server and run commands. If not we can set up a full desktop.

• Publish to the /turtle1/cmd_vel topic using the Twist_ datatype to control the turtle via this code snippet, config file, and idl

Please add the specific steps to compile and run

TransportClient::send_i: no links for publication

The DataWriter doesn't have any matched DataReaders to send this data sample. So the part of the log we're looking for involves discovery.

Wireshark

This article may be helpful https://objectcomputing.com/resources/publications/sett/october-2021-wireshark-and-opendds

[spelletier1996]

I've setup an example repo with build steps in the readme.

It's a simple example attempting to publish a test string to the /chatter topic

Should be able to run the basic ROS2 command line listener node using ros2 run demo_nodes_cpp listener

Seem to be running into the same discovery issue you mentioned with this example aswell

[mitza-oci]

I got this output from meson:

Run-time dependency opendds found: NO (tried pkgconfig and cmake)

[spelletier1996]

Repo updated with opendds install script and instructions, make sure to delete the build folder and redo the build steps after installing.

Quick note: meson expects OpenDDS to be installed and findable by either pkg-config or cmake FindPackage

[spelletier1996]

So it seems that I have fixed the problem (atleast for a basic string message)

There were two problems first one relevant to opendds. The default DatawriterQoS representation value is left blank for openDDS while for ROS2 is set to DDS::XCDR_DATA_REPRESENTATION;

Secondly there was an ip mismatch which was easily fixed by setting DCPSInfoRepo to localhost.

Both solved by the help of the RTI Admin Console tool that allows match analysis to see which QoS settings are mismatched.

Hopefully the bit about XCDR is useful for anyone trying to do this in the future.

[mitza-oci]

When it was set to the default and didn't work, did you observe OFFERED_INCOMPATIBLE_QOS (using listener or condition) in the OpenDDS application?

[Liu-Le0117]

Hello @spelletier1996 and OpenDDS team,

I've been closely following the discussion in #3974 regarding communication between OpenDDS and ROS2 using eprosima Fast DDS. It's great to see the progress made on basic string messages.

My project also involves integrating OpenDDS with ROS2, but extends beyond simple strings to include more complex data types like sensor data, status information, and control commands. Have there been any developments in transmitting these more complex data types?

Additionally, I wonder if the OpenDDS team might have insights or suggestions on this topic. The resolution of the DatawriterQoS and IP mismatch issues was enlightening, and I'm curious if similar approaches could be applied for complex data types.

Any guidance or advice from either @spelletier1996 or the OpenDDS team would be greatly appreciated. Thank you for your contributions to the community and for any help you can provide.

Best regards

[mitza-oci]

Any supported IDL data type should be interoperable using XCDR2 (assuming the remote system also supports XCDR2). Details are in the OpenDDS Developer's Guide.
If you find an example of supported IDL not working please open a new issue with steps to reproduce the issue.