Dynamically handling network interfaces

Next Generation ROS
1

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

7 Likes
2

@alsora

I know this one is kinda old thread, but I am curious that if you find the reasonable work-around or method to address this situation.

thanks,
Tomoya

3

No progress on this.
However I saw that the new Fastdds 2.5.0 mentions that it allows detections of new networks at runtime
https://fast-dds.docs.eprosima.com/en/latest/notes/notes.html

Maybe @MiguelCompany can provide more details on it?

1 Like
4

@alsora
CC: @MiguelCompany

thank you so much for introducing 15.10. Dynamic network interfaces — Fast DDS 2.5.0 documentation, which looks good.

the use cases that we have is the following.

image
image1682Ă—795 109 KB

  • the above situations are so likely to happen after application started.
  • cannot expect the help from user like smartphone, it should be able to self-healing function.

I was considering a few ideas,

  • use linux interfaces. (man 7 netlink NETLINK_ROUTE) application can listen on socket to receive network interface create/delete/up/down events.
  • NetworkManager DBus event
  • App service depends on systemd device units

ROS 2 / DDS ability would be really nice, so that we do not need reset the whole application.

2 Likes