Multimachine communication

[claireyywang]

How about a verb called “yell” (or something more clever), where the program just spins and sends “hello-world” and it’s hostname once per second, over both a hard-coded ROS2/DDS topic and a “custom” multicast UDP packet as well. At the same time, it is listening for other messages on that same ROS2 topic and/or UDP multicast port and printing a summary table periodically of which other hosts it has heard from, message counts, and so on. This would help debug the current #1 problem we are seeing, where people have messaging working on localhost but can’t receive those messages on another host. This spins into a debug cycle of trying to figure out if the problem lies with their software, their network configuration, DDS discovery or transport bugs, the network infrastructure, and so on. Currently we debug this using known-good ros2 nodes such as examples_rclpy_minimal_* , wireshark, ping, ros2multicast, ros2node, and so on, but having a nicer way to do it would be great.

Run ros2 doctor call command to test pub/sub, multicast send/receive quality across multiple machines. The command outputs a summary table /1s.

MULTIMACHINE COMMUNICATION SUMMARY
Topic: knockknock, Published Msg Count: 20
Subscribed from:
                Hostname             Msg Count /2s
Multicast Group/Port: 225.0.0.1/49150, Sent Msg Count: 20
Received from:
                Hostname             Msg Count /2s
                Claires-MBP          3         
------------------------------------------------------------

Test cases will be submitted in a separate PR.

[jacobperron]

Unless I'm missing the point, I assume we would want two different verbs for testing multi-machine communication: one for sending data (publish ROS messages, send multicast data, etc) and other for receiving. The implementation as it stands is sending/receiving data to/from the same process, which may bypass the network interface (e.g. intra-process pub/sub). (I missed the point)

Beside this, I've left some other minor comments and nitpicks.

[claireyywang]

@jacobperron The bypassing network part explained why I wasn't able to get pub/sub working on two machines when testing. Thanks for pointing it out! I copied the feature request in the PR description for completeness. Based on my understanding, it seems like they want one verb to do it all. What do you think? If that's not the best way to do it, I'd be happy to refactor the code and split it into send/pub and receive/sub.

[jacobperron]

Thanks for updating the description, it's helpful to have the context! I think I missed the point originally; you can disregard my previous comment.

There shouldn't be any network bypassing happening if there are different hosts on the same ROS network. Double check that they are using the same ROS_DOMAIN_ID. I think we can make some improvements to the executor/send-receive loop too.

[jacobperron]

In addition to my minor comments below, it would also be nice to have a unit test that exercises the new verb.

[jacobperron]

LGTM!

Just a couple minor comments.

[claireyywang]

CI
Linux
Linux-aarch64
osx
windows
windows-container

[claireyywang]

Linux-aarch64:
windows-container:

[jacobperron]

FYI, this is the old (soon-to-be deprecated) way of doing this. Use launch_testing.actions.ReadyToTest() instead.

[claireyywang]

CI again
linux
linux-aarch64
osx
windows
windows-container