Echo only show discovery messages

[PierreNeumann]

I'm trying to debug my installation with the echo example.

I'm on ubuntu 22.04 and I start DDS router in a docker image with debug enabled.

Should I see every messages sent by the demo_nodes_cpp talker node ?
Because I see only Discovery Messages.

I also tried to use ros2 commandline with :
ros2 topic pub /chatter std_msgs/String "data: Hello world"

and the behavior is the same.

[rsanchez15]

Hi @PierreNeumann

There are two things to take into account here:

1. The echo participant should be configured to display the incoming data as this is disabled by default. Here you have an example on how to configure this participant in order to display the data discovery information, the user data and with or without verbose information.
2. The DDS Router does not forward the data automatically as it is thought to be as efficient as possible. This way, the DDS Router does not receive any data until it discovers a data consuming entity (a listener in this case) which requires this data. Therefore, if you have a deployment as follows

   talker <-> ddsrouter_1 <-> ddsrouter_2 <-> listener
   

   the ddsrouter_1 won't forward any data until ddsrouter_2 discovers the listener.

[PierreNeumann]

Hi @rsanchez15,

Can the talker and ddsrouter_1 be on the same machine ? With ddsrouter_1 running in a docker image with --network=host and the talker using the local ros2 installation ?

Because i'm testing the wan capability on a local network, I drop multicast traffic with iptables :

 iptables -I OUTPUT -o ens18 -p udp -d 239.255.0.1 --dport 7400 -j DROP
 iptables -I INPUT -i ens18 -p udp -d 239.255.0.1 --dport 7400 -j DROP

Did you see a problem with this ?

My current configurations are the followings :

router1

######################
# WAN SERVER EXAMPLE #
######################

##################################
# CONFIGURATION VERSION
version: v3.0                                                     # 0

##################################
# ALLOWED TOPICS

allowlist:
  - name: rt/chatter                               
    type: std_msgs::msg::dds_::String_

##################################
# PARTICIPANTS
participants:

##################################
# SIMPLE PARTICIPANT
# This participant will subscribe to topics in allowlist in domain 0 and listen every message published there

  - name: SimpleParticipant                               
    kind: local                                         
    domain: 0                                              

##################################
# WAN SERVER
# This participant will subscribe to topics in allowlist using Initial Peers Discovery protocol awaiting connections.

  - name: WanParticipant                                          
    kind: wan                                               
    listening-addresses:
      - ip: 10.10.0.208                                          
        port: 11666                                            
        transport: tcp

router2

######################
# WAN CLIENT EXAMPLE #
######################

##################################
# CONFIGURATION VERSION
version: v3.0                                              

##################################
# ALLOWED TOPICS

allowlist:                                 
  - name: rt/chatter                       
    type: std_msgs::msg::dds_::String_

##################################
# PARTICIPANTS
participants:

##################################
# SIMPLE PARTICIPANT
# This participant will subscribe to topics in allowlist in domain 1 and listen every message published there

  - name: SimpleParticipant                           
    kind: local                                           
    domain: 1                                               

##################################
# INITIAL PEERS CLIENT
# This participant will subscribe to topics in allowlist using Initial Peers Discovery protocol connecting to remote.

  - name: WanParticipant                                  
    kind: wan                                               
    connection-addresses:                                     
      - ip: 10.10.0.208
        port: 11666
        transport: tcp

[juanlofer-eprosima]

Hi @PierreNeumann

Yes, the talker and ddsrouter_1 can indeed be on the same machine.

My guess is that what you might be experiencing is a problem related to Shared Memory Transport, arising when entities in a Docker container (launched with --net=host) try to communicate with others from the same host through the aforementioned transport variant.

Please have a look at this comment for more details on this issue. You may test running the DDS-Router Docker container with --net=host AND --ipc=host, making sure the host name within Docker (usually root) and that of the host itself coincide (easy way: execute the host commands as superuser).

Please do not hesitate to contact us if the issue persists.
Cheers

[PierreNeumann]

It works now :)
Thank you @rsanchez15 and @juanlofer-eprosima.

There was two things :
1 ) The option --ipc=host was missing
2 ) I wasn't exactly using the listener node :
- This command works : ROS_DOMAIN_ID=1 ros2 run demo_nodes_cpp listener
- This command don't : ROS_DOMAIN_ID=1 ros2 topic echo chatter

But if I enter the first command, then the ros2 topic echo will work.
Have you an idea of what's happening here ?
Because I was expecting that the second command will work the same as the listener.

[jparisu]

But if I enter the first command, then the ros2 topic echo will work.
Have you an idea of what's happening here ?
Because I was expecting that the second command will work the same as the listener.

This is a curious case.
The ros2 topic echo <topic> command raises a subscriber in any ros2 topic. However, it has no information about the topic itself until there is other ros2 entity using this topic in the same network. Thus, creating an echo entity in one side will not be able to create the subscription, which is the trigger for the DDS Router to create the bridge and the publication and subscription in both sides.

In conclusion, it happens as @rsanchez15 said. There is no communication until a consumer (subscription) exists. And there is no subscription created with echo until there is any other entity in its net using that topic.

[PierreNeumann]

Very clear, thank you @jparisu