DDS -> Ros2 publisher stay silent

[K1]

Following issue eProsima/FastDDS-SH#55, I made some progress.

client.yaml looks like this:

systems:
    dds:
      type: dds
      dynamic types:
        struct std_msgs__String:
          string: "data"
      types-from: ros2
      participant:
        file_path: "wan_config.xml"
        profile_name: soss_profile_client

    ros2:
      type: ros2

routes:
    ros2_to_dds: { from: ros2, to: dds }
    dds_to_ros2: { from: dds, to: ros2 }

topics:
    chatter: { type: "std_msgs/String", route: ros2_to_dds, remap: { dds: "chatterddsC" } }
    chatterddsS: { type: "std_msgs/String", route: dds_to_ros2, remap: { ros2: "chatter" } }

and, server.yaml is:

systems:
    ros2:
      type: ros2
    dds:
      type: dds
      types-from: ros2
      dynamic types:
        struct std_msgs__String: # This name can't have any '/', as explained later on this section.
          string: "data"
      participant:
        file_path: "wan_config.xml"
        profile_name: soss_profile_server

routes:
    ros2_to_dds: { from: ros2, to: dds }
    dds_to_ros2: { from: dds, to: ros2 }

topics:
    chatterddsC: { type: "std_msgs/String", route: dds_to_ros2, remap: { ros2: "chatter" } }
    #chatter: { type: "std_msgs/String", route: ros2_to_dds, remap: { dds: "chatterddsC" } }

I ignored ''ros2_to_dds'' route on server side to avoid recursion problem. This is most close format to WAN example I can run without eProsima/FastDDS-SH#55 happening.

Now, on client side I get

[soss-dds]: configured!
[soss-dds]: publisher created. topic: chatterddsC, type: std_msgs/String
[soss-dds]: subscriber created. topic: chatterddsS, type: std_msgs/String
[soss-dds][publisher]: translate message: soss -> dds (chatterddsC) 
[soss-dds][publisher]: translate message: soss -> dds (chatterddsC) 
[soss-dds][publisher]: translate message: soss -> dds (chatterddsC) 
[soss-dds][publisher]: translate message: soss -> dds (chatterddsC) 
[soss-dds][publisher]: matched (chatterddsC) 
[soss-dds][publisher]: translate message: soss -> dds (chatterddsC) 
[soss-dds][publisher]: translate message: soss -> dds (chatterddsC) 
[soss-dds][publisher]: translate message: soss -> dds (chatterddsC) 

and server side is:

[soss-dds]: configured!
[soss-dds]: subscriber created. topic: chatterddsC, type: std_msgs/String
[soss-dds][subscriber]: matched (chatterddsC) 
[soss-dds][subscriber]: translate message: dds -> soss (chatterddsC) 
[soss-dds][subscriber]: translate message: dds -> soss (chatterddsC) 
[soss-dds][subscriber]: translate message: dds -> soss (chatterddsC) 
[soss-dds][subscriber]: translate message: dds -> soss (chatterddsC) 

But ros2 listener node (on server side) does not show anything. while it looks SOSS has registered a publisher on this topic:

# ros2 topic info /chatter
Type: std_msgs/msg/String
Publisher count: 1
Subscription count: 1

Please note that weird "std_msgs/msg/String" type in ros2 console. Also, ros2 topic echo fails to show anything:

ros2 topic echo /chatter std_msgs/msg/String -> none
ros2 topic echo /chatter std_msgs/String -> none
ros2 topic echo /chatter  -> none

[Jose Antonio Moral]

Good morning and sorry about the delay. During the process of investigating your issue, we ran with another (potentially) bigger problem, regarding SOSS-ROS2 SystemHandle compilation for ROS 2 Foxy and Ubuntu 20.04; this kept us busy for a while. Anyway, there is already an open issue on github about this topic, so we will try to reproduce your scenario with a previous ROS 2 version. I recall trying last friday with ROS 2 Dashing and did not have any problems regarding the provided YAML file (your problem in issue eProsima/FastDDS-SH#55 seemed like an introduced typo in the configuration file), but didn't have the time to deploy and test the full WAN scenario yet.

[K1]

That is definitely not a typo in YAML, I have carefully checked that. It throws YAML parser exception if remap key has 2 levels of dictionary instead of one, this line from repo example folder always cause the crash

remap: { ros2: { type: "std_msgs/String", topic: chatter } }
or 
remap: { ros2: { type: "std_msgs/String", topic: "chatter" } }

While this one works fine:

remap: { ros2: "chatter", type: "std_msgs/String" }

But back to this issue eProsima/FastDDS-SH#56, it looks everything is working except publishing /chatter topic on Ros2 domain, plus registered topic has wrong type (std_msgs/msg/String instead of std_msgs/String)

[K1]

@jamoralp, I think your problem regarding RCLCPP is not from ROS package (I can't figure out why it happens only on binary version), but I fixed it by adding the dependency into ros2-test package.
That problem and few other warnings fixed here:

keivanh@f2c7b8f

[Jose Antonio Moral]

Good morning, I know it has been a long time, but any updates on this?

Regarding the recursion problems, we implemented a mechanism to avoid messages being sent back within integration service when there are opposite routes declared to the same topic. Check it out here: #139

[K1]

Our development tasks shifted away from ROS2 for a while, but we are going to start that part of project again so we will definitely need to fix these issues with ROS2. I will check updates and will get back to you with results.
Thank you