ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

Dynamically handling network interfaces

Hi, I would like to present here a discussion originated in the ROS 2 Middleware Working Group.

While developing a simple ROS 2 robot setup, we noticed a few strange behaviors related to how ROS 2 and the underlying RMW implementation handled the available network interfaces.

Considering ROS 2 Galactic, we have that only the network interfaces that are present at startup of your ROS 2 application will be used for communication by the RMW.

This happens with both major RMW implementations fast-dds and cyclonedds.

Let’s examine some situations where this is a problem.

  • You have a service that starts your ROS 2 application as soon as the system boots up. This may result in one or more network interfaces to not be ready yet: they will be ignored by ROS 2.
  • You have a running ROS 2 application and then you decide to connect a new interface for debugging purposes (e.g. via usb). Your application will not send any message there.

Currently, the only solution in both cases consists in the user having to fully restart the ROS 2 application whenever it’s necessary to start using a new interface that just came up.
This may be ok-ish in the first case, but it’s definitely not possible in the second one! You would lose all the state of your robot!

What do you think of these situations?
They can definitely be handled at the system level, but it would be non trivial, requiring custom solutions depending on the architecture and a good amount of Linux knowledge.
I think that these problems are relevant enough that they need an easily integrated solution at the application level.

Possibilities from a user perspective could be the following:

  • Provide a “use all interfaces” default RMW mode. This mode will automatically use all available interfaces at startup and it will monitor for the creation of new ones. When a new interface is created, it will be used.
  • Provide RMW reset APIs. This could be used by the user to send a signal to restart the RMW since a new interface is now available. Restarting the RMW would not require to restart the application.

FYI @wjwwood @Jaime_Martin_Losa @MiguelCompany @joespeed @eboasson @asorbini_rti