Revision history [back]

@murokill, I've been fighting the same battle. I was just able to get the ROS2 examples_rclcpp_minimal_publisher/subscriber working with a variant of the eProsima Fast-RTPS code generated by pretty much following the steps on the eProsima Fast-RTPS "Getting Started" page. I pulled the String.idl IDL file from my ROS2 installation in place of the sample IDL snippet shown in the webpage. On my system, it was at /opt/ros/crystal/share/std_msgs/msg. I'm running Ubuntu 18.04.2 LTS. There were two things I had to do to get it to work beyond the basic stuff you find fairly easily in tutorials. I used WireShark to dig into the RTPS UDP and Multicast packets to help clue me in on these updates.

In eProsima's code generated from your String.idl file, you'll need to prefix your topic in StringPublisher::init() and StringSubscriber::init() with "rt/". This tells eProsima Fast-RTPS that you are trying to talk with ROS2 nodes. I found this tidbit here in ROS2 documentation. For example, my topic was "hailstate" for the ROS2 publisher/subscriber and I wanted it to be the same on the eProsima publisher/subscriber, but it wasn't showing up that way. Once I prefixed my topic using the following line, Rparam.topic.topicName = "rt/hailstate";, the topic names matched.
My next problem was that my types didn't match. When running four nodes (ROS2 examples_rclcpp_minimal_publisher, ROS2 examples_rclcpp_minimal_subscriber, eProsima subscriber, and eProsima publisher), the "ros2 topic list -t" command would show my topic with two different types. One type for the eProsima topic [std_msgs::msg::String] and a different type for the ROS2 topic [std_msgs/String]. Because of this type mismatch, the topics were still different. I changed the topic in the constructor, StringPubSubType::StringPubSybType(), in the fastrtpsgen generated file, StringPubSubTypes.cxx, with the line setName("std_msgs::msg::dds_::String_");. I just changed the type from the default specified by eProsima to what it shows now. After this, all four nodes started communicating with each other.

If there is a way to do this without feeling like I had to hack it, I'd be very interested to know what it is. I've started digging a little deeper into ROS2 msg and srv files to see if there is a better way to generate code that will work for ROS2 and eProsima without having to manually update files.

@murokill, I've been fighting the same battle. I was just able to get the ROS2 ~~examples_rclcpp_minimal_publisher/subscriber~~ examples_rclcpp_minimal_publisher and examples_rclcpp_minimal_subscriber working with a variant of the eProsima Fast-RTPS code generated by pretty much following the steps on the eProsima Fast-RTPS "Getting Started" page. I pulled the ~~String.idl~~ String.idl IDL file from my ROS2 installation in place of the sample IDL snippet shown in the webpage. On my system, it was at ~~/opt/ros/crystal/share/std_msgs/msg.~~ /opt/ros/crystal/share/std_msgs/msg. I'm running Ubuntu 18.04.2 LTS. There were two things I had to do to get it to work beyond the basic stuff you find fairly easily in tutorials. I used WireShark to dig into the RTPS UDP and Multicast packets to help clue me in on these updates.

1. In eProsima's code generated from your String.idl file, you'll need to prefix your topic in ~~StringPublisher::init() and StringSubscriber::init()~~ StringPublisher::init() and StringSubscriber::init() with ~~"rt/".~~ rt. This tells eProsima Fast-RTPS that you are trying to talk with ROS2 nodes. I found this tidbit here in ROS2 documentation. For example, my topic was ~~"hailstate"~~ /hailstate for the ROS2 publisher/subscriber and I wanted it to be the same on the eProsima publisher/subscriber, but it wasn't showing up that way. Once I prefixed my topic with rt, the topic names matched. Code below is the updated code that was generated using ~~the following line, Rparam.topic.topicName~~ fastrtpsgen -example CMake String.idl in generated file StringPublisher.cxx. The same change on the last line would need to be made in the StringSubscriber.cxx:

bool StringPublisher::init() { ParticipantAttributes PParam; PParam.rtps.builtin.domainId = "rt/hailstate";, the topic names matched.

0; PParam.rtps.builtin.leaseDuration = c_TimeInfinite; PParam.rtps.setName("epro_publisher"); mp_participant = Domain::createParticipant(PParam); if(mp_participant == nullptr) { return false; } Domain::registerType(mp_participant, static_cast<TopicDataType*>(&myType)); // Create Publisher PublisherAttributes Wparam; Wparam.topic.topicKind = NO_KEY; Wparam.topic.topicDataType = myType.getName(); Wparam.topic.topicName = "rt/hailstate";
2. My next problem was that my types didn't match. When running four nodes (ROS2 examples_rclcpp_minimal_publisher, ROS2 examples_rclcpp_minimal_subscriber, eProsima subscriber, and eProsima publisher), the ~~"ros2~~ ros2 topic list -t" -t command would show my topic with two different types. One type for the eProsima topic ~~[std_msgs::msg::String]~~ std_msgs::msg::String and a different type for the ROS2 topic ~~[std_msgs/String].~~ std_msgs/String even though I used the ROS String.idl file to create the eProsima logic. Because of this type mismatch, the topics were still technically different. I changed the topic in the constructor, ~~StringPubSubType::StringPubSybType(), in the fastrtpsgen~~ StringPubSubType::StringPubSybType(), in the fastrtpsgen generated file, ~~StringPubSubTypes.cxx,~~ StringPubSubTypes.cxx, with the line ~~setName("std_msgs::msg::dds_::String_");.~~ setName("std_msgs::msg::dds_::String_"); line shown in the code snippet below. I just changed the type from the default specified by eProsima to what it shows now. After this, all four nodes started communicating with each ~~other.~~

other. The key is inserting the dds_:: and adding the _ at the end of the String base type.

namespace std_msgs {
    namespace msg  {
        StringPubSubType::StringPubSubType() 
        {
            setName("std_msgs::msg::dds_::String_");