Ask Your Question

Use ros2-FastRTPS with standalone FastRTPS programs

asked 2019-03-27 09:38:49 -0500

murokill gravatar image


is it possible to create some publisher in ros2 with Fast-RTPS as middleware and on the other side receive published topics on the standalone (non ros2) FastRTPS programs?

I've even created an .idl file with simple string message (compiles with colcon and copied to eProsima project directory. Next I've created header with fastrtpsgen tool). But the topics don't see each other...

Knows somewhere the right rules/setting for my goal?

Many thanks!

edit retag flag offensive close merge delete



Please don't ask multiple versions of questions that's poor etiquette as it potentially causes multiple people to try to help you. Also your other question has much more helpful details that might be able to help someone answer your question here. Please see our support guidelines:

Since this is a question this is the right place so I'll close the other one. Please edit your question here to add more details. The easier it is for someone to reproduce your problem the easier it is for them to help you.

tfoote gravatar image tfoote  ( 2019-03-27 14:08:40 -0500 )edit

@murokill were you able to reach a solution for the issue or is it still pending?

slmat27 gravatar image slmat27  ( 2019-04-03 02:37:37 -0500 )edit

3 Answers

Sort by ยป oldest newest most voted

answered 2019-05-14 13:12:46 -0500

WeekendWar gravatar image

updated 2019-05-16 15:32:29 -0500

@murokill, I've been fighting the same battle. I was just able to get the ROS2 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 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.

1. 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 with rt, the topic names matched. Code below is the updated code that was generated using 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 = 0;
     PParam.rtps.builtin.leaseDuration = c_TimeInfinite;
     mp_participant = Domain::createParticipant(PParam);
     if(mp_participant == nullptr)
         return false;


     // 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 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 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 generated file, StringPubSubTypes.cxx, with the line 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. The key is inserting the dds_:: and adding the _ at the end of the String base type.

namespace std_msgs {
    namespace msg  {

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 ... (more)

edit flag offensive delete link more


@WeekendWar hi! I am facing the same problem with mismatching types (FastRTPS publisher type and ROS2 subscriber type). Would you please provide more details about how to create the same types for FastRTPS standalone app and ROS2 node? For example if I want to send ROS2 std_msgs/String type, what should I put to FastRTPS IDL file? If possible, provide code examples please. Help would be much appreciated. Thank you.

Alyasko gravatar image Alyasko  ( 2019-05-16 05:56:03 -0500 )edit

@Alyasko, I updated my answer with some formatting to help highlight the answers. I also added a few code snippets. These will make sense if you've generated your code using the fastrtpsgen tool from eProsima using the -example option. If not, then I recommend you go through the Getting Started mentioned in my posting above. Hope it helps.

WeekendWar gravatar image WeekendWar  ( 2019-05-16 15:34:52 -0500 )edit

This post was very good and helped me to solve this my communication problem as well - thank you so much! Is there any way to adapt the way fastrtpsgen is generating the type name convention, e.g. changing the way ROS2 generates the IDL file?

Bearnd gravatar image Bearnd  ( 2019-05-28 07:00:20 -0500 )edit

There's an example project that demonstrates talking between native FastRTPS and ROS2 here if it's useful to anyone.

david.hodo gravatar image david.hodo  ( 2019-06-08 12:22:35 -0500 )edit

answered 2019-03-28 21:42:41 -0500

Geoff gravatar image

Without seeing and testing your code (which even the GitHub issue doesn't have) it's hard to make a judgement on what the actual cause is, but I can give some pointers.

ROS wraps DDS and in doing so it uses things like mangling rules to represent namespaces, topic naming patterns to help separate ROS topics and raw DDS topics, etc. It also uses a domain that may be different from the default domain of FastRTPS. Here are a few things you can check to get you started.

  • Make sure that the ROS_DOMAIN_ID environment parameter is set so that ROS uses the same domain ID as your plain FastRTPS application is using, or set the domain ID used by the FastRTPS application to match the ROS one.
  • Make sure that your plain FastRTPS application is using a topic name that the ROS application can see and understand. There is a design article about how ROS topic names map to DDS names. You can also find sporadic discussions about this via this issue search. If you are unsure of what topic names the ROS side is using, you could try listing all found topics from the FastRTPS side.
edit flag offensive delete link more

answered 2020-03-27 06:19:40 -0500

TSC gravatar image

For everyone still having this issue, I added a fix to the FastRTPSGen tool that through an argument passed to the fastrrpsgen script (-typeros2), the type naming will be generated with the structure compatible with ROS2 topics. So now there is no need to change the naming manually after generating the code.

Hope this helps!

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2019-03-27 09:38:49 -0500

Seen: 1,186 times

Last updated: Mar 27