Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

Proxying ROS communications -- enabling containerized ROS deployments in distributed multi-host environments

Arne Wendt, Thorsten Schüppstuhl

TL;DR

This paper tackles the challenge of running ROS in containerized, distributed multi-host environments where bidirectional communication must span containerized and non-containerized nodes. It analyzes ROS XMLRPC Master/Slave APIs and TCPROS data transport, evaluates Docker networking modes, and demonstrates that none of the stock modes satisfy all deployment requirements. To address this gap, it proposes a layer-7 ROS proxy (rosproxy) that runs in a container, transparently intercepting and rewriting XMLRPC calls and proxying TCPROS connections to enable cross-segment ROS communication without modifying nodes or Docker. The solution is runtime-agnostic, improves deployment reproducibility at the edge, and could inform future work with ROS 2 DDS-based transports and cloud robotics scenarios.

Abstract

With the ability to use containers at the edge, they pose a unified solution to combat the complexity of distributed multi-host ROS deployments, as well as individual ROS-node and dependency deployment. The bidirectional communication in ROS poses a challenge to using containerized ROS deployments alongside non-containerized ones spread over multiple machines though. We will analyze the communication protocol employed by ROS, and the suitability of different container networking modes and their implications on ROS deployments. Finally, we will present a layer 7 transparent proxy server architecture for ROS, as a solution to the identified problems. Enabling the use of ROS not only in containerized environments, but proxying ROS between network segments in general.

Proxying ROS communications -- enabling containerized ROS deployments in distributed multi-host environments

TL;DR

This paper tackles the challenge of running ROS in containerized, distributed multi-host environments where bidirectional communication must span containerized and non-containerized nodes. It analyzes ROS XMLRPC Master/Slave APIs and TCPROS data transport, evaluates Docker networking modes, and demonstrates that none of the stock modes satisfy all deployment requirements. To address this gap, it proposes a layer-7 ROS proxy (rosproxy) that runs in a container, transparently intercepting and rewriting XMLRPC calls and proxying TCPROS connections to enable cross-segment ROS communication without modifying nodes or Docker. The solution is runtime-agnostic, improves deployment reproducibility at the edge, and could inform future work with ROS 2 DDS-based transports and cloud robotics scenarios.

Abstract

With the ability to use containers at the edge, they pose a unified solution to combat the complexity of distributed multi-host ROS deployments, as well as individual ROS-node and dependency deployment. The bidirectional communication in ROS poses a challenge to using containerized ROS deployments alongside non-containerized ones spread over multiple machines though. We will analyze the communication protocol employed by ROS, and the suitability of different container networking modes and their implications on ROS deployments. Finally, we will present a layer 7 transparent proxy server architecture for ROS, as a solution to the identified problems. Enabling the use of ROS not only in containerized environments, but proxying ROS between network segments in general.
Paper Structure (21 sections, 4 figures)

This paper contains 21 sections, 4 figures.

Table of Contents

  1. Introduction
  2. ROS and docker -- related works
  3. Docker networking and ROS
  4. ROS communications
  5. XMLRPC -- Master- & Slave-API
  6. Master-API
  7. Slave-API
  8. TCPROS
  9. Docker networking-mode fitness for ROS
  10. Bridged
  11. Host
  12. ipvlan & macvlan
  13. IPAM
  14. Overlay
  15. Problem Statement
  16. ...and 6 more sections

Figures (4)

  • Figure 1: Order of communications in ROS: Advertising topic /chat by node talker and subscribing from node listener. Arrows showing direction of communications channel establishment, and XMLRPC method call and return value.
  • Figure 2: docker default bridge networking topology
  • Figure 3: Networking topology and connections, when using containerized ROS nodes with proposed rosproxy
  • Figure 4: rosproxy schematic operation principle and connection topology