Comms with ROS2 on QEMU
I am running a demo ROS2 talker on a FreeBSD-based OS on QEMU. It is called minimal_publisher
and is publishing to chatter
. The talker is from demo_nodes_cpp
provided by the vanilla install of ROS2 dashing.
I then run the corresponding listener on the host machine, subscribing to chatter
.
The talker on QEMU looks like its publishing just fine (printing a string of Publishing: 'Hello, world! [count]'
; however, the listener doesn't pick anything up.
ros2 node list
shows both nodes, but ros2 topic list
does not show the chatter
topic. It only shows parameter_events
and rosout
.
This setup worked for me with ROS[1], running roscore
on the host. In that case, though, I was able to explicitly point the talker running on QEMU to the master via ROS_HOSTNAME
and ROS_MASTER_UID
, I think.
I would appreciate some help in getting my ROS2 publishers and subscribers similarly working across the QEMU boundary.
First thing to check: make sure UDP multicast is working between all involved hosts/emus.
See the first part of ROS 2 Overview > Troubleshooting to check. Also: Getting started with ros2doctor.
The troubleshooting recommends running
ros2 multicast
and, if that fails, then modifying firewall rules and checking forMULTICAST
tags viaifconfig
.My target environment doesn't support python (yet), so I'm not able to build and use ros2cli (unless I'm mistaken, which would make me happy...). I can send and receive multicast packets on the host (via
ros2 multicast
), but I can't runros2 multicast send
in the QEMU environment andros2 multicast receive
on the host...ifconfig
does showMULTICAST
in the flags section of both interfaces displayed byifconfig
on QEMU and I've confirmed that the firewall is not enabled.To get this demo going, is there a way to simplify this process by reverting to something closer to the ROS1 discovery/communication paradigm? Eventually, I want to be able to use the fully featured, distributed discovery provided by ROS2, but I need to ...(more)
You could see whether configuring things for unicast discovery works. There are a couple of Q&As on this site about that. It comes down to editing the Fast RTPS configuration to disable multicast.
There's no guarantee of course that this is your problem. It was just the first thing I would check.
Also: you don't absolutely need to use the
ros2 multicast
verb. Any tool which can check multicast capabilities could be used. Software based routers/interfaces sometimes don't implement the necessary routing (IGMP snooping, etc). It could be that's what happening here, but it could be something else completely as well.I ran a fairly quick test based on this code, which (I think) demos multicast capability. It worked just fine back and forth between the host and QEMU.
I also tried to establish unicast discovery based on this ROS answer and eProsima documentation (see section on Initial Peers and subsequent tip on disabling multicast). I've posted my DEFAULT_FASTRTPS_PROFILES.xml file.
Still, when I run the talker from within QEMU, it shows up on the host in response to
ros2 node list
, but the topic does not appear when I runros2 topic list
on the host.Some other observations:
ros2 node info /minimal_publisher
produces the following error:If I run the talker and then the listener on QEMU (or visa versa), the second one fails with the following error:
It does look like something isn't behaving as it should. Particularly in the network stack/interfacing code.
Seeing your other questions: could this be caused by your compiler infrastructure? Have you tried running any of the examples/tests that come with the DDS implementation? That would be one/a few layers of abstraction less, while still being more complex than a bare multicast test.
There is always the chance it's actually a problem in the ROS 2 code, but that's not entirely apparent right now.
As I'm currently building with
-DBUILD_TESTING=NO
, the tests inrmw
don't get built. I've tried to find an easy workaround for this, but it'll take some time, as I also need to build the google test suite.To avoid communicating host-> guest, I tried running one of the composed publisher/subscribers. It seems to do better, but I get the following when I initiate. As you can see, the subscriber prints an empty message: