Hi,
I'm trying to interface a ROS2 subscriber with a DDS publisher. To keep things simple, I'm starting with using a built-in message type from ROS2: trajectory_msgs/msg/JointTrajectory
On the DDS publisher side, I've utilized this repository to get the .idl equivalent of ros2 message types: https://github.com/Antoniolm/ros-data-types . I've successfully generated the TypePlugin and TypeSupport classes, compiled and linked them to my application.
From the earlier posts, I understand that due to name mangling, we neet to prefix the topic names in DDS nodes with "rt/" in order to make them visible on ROS2, which I also did. The topic I'm publishing from the DDS node is visible on both RTI Admin Console and ROS2:
However, when I try to "echo" this topic, or write a ROS2 subscriber by using the built-in ROS2 trajectory_msgs/msg/JointTrajectory, I'm not receiving what DDS publisher is sending.
Trying to echo it on ROS2 gives the following:
I have realized that, "ros2 topic info" for the DDS publisher topic shows the message type in C++ namespace syntax, instead of the typical ROS2 "trajectory_msgs/msg/JointTrajectory" syntax.
If I write a pure ROS2 publisher for this message type, I indeed get topic type as "trajectory_msgs/msg/JointTrajectory". 
My question is, should I use a different kind of syntax on the subscriber side for this built in ros message?
I'm using:
Subscriber: ROS2 Galactic (with default DDS vendor Eclipse Cyclone)
Publisher: RTI Connext Version: 6.0.1.
Thanks in advance
Best regards
Goksan
Hello Goksan,
I suspect the issue may be the data type name and nesting in the IDL files.
The IDL types defined at https://github.com/Antoniolm/ros-data-types were created for the initial ('Ardent') release of ROS2, and have since evolved in ROS2 to add an additonal layer of nesting and some naming changes.
You can find an updated version of the repo at https://github.com/neil-rti/ros-data-types
This updated version includes the changes in data type nesting and naming, for example:
An earlier type definition might look like this:
module std_msgs {module msg {
struct Bool {
boolean data;
};
};
};
The newer versions look like this:
module std_msgs {module msg {
module dds_ {
struct Bool_ {
boolean data;
};
};
};
};
Note the added layer of nesting under "dds_", and the trailing underscore on the struct name "Bool_".
This matches the types that are generated in the ROS2 build system. The expected data type may not be visible in RTI Admin Console when viewing a ROS2 node using rmw_cyclonedds_cpp due to CycloneDDS not supporting data type forwarding in its discovery info. The data type can be made visible by using an RMW/DDS combination that supports type forwarding, such as rmw_connextdds (or the older / deprecated rmw_connext_cpp).
One other note about the updated IDL types repository -- it includes a build option to create UNBOUNDED strings and sequences, instead of the default (bounded).
ROS2 data types that include strings and sequences are almost always unbounded, so these IDL data types should be built with this option for best interoperability with ROS2.
Note that BOUNDED publishers can send to UNBOUNDED subscribers without issue, but UNBOUNDED publishers cannot send to BOUNDED subscribers (the connection will be refused).
There's also an interop-demo repo at https://github.com/neil-rti/ros2-interop-demos that uses the above (updated) IDL repo for a few interoperability demos with ROS2, mostly using RViz or TurtleSim on the ROS2 side to show interop with native Connext DDS applications.
Please let me know if the above does not resolve the issue, or if you have further questions.
Thanks!
Neil
Hi Neil,
Thank you for the thorough explanation. With the links you've shared, it was possible to get DDS publisher sending ROS native message types to ROS subsriber nodes.
Best regards
Goksan