Home
This repository consists of experimental software. While the important components have been extensively tested and are used daily, they may exhibit undesirable and unexpected behavior. Many of these components are written in Python and depend on various 'nice' language features like dynamic and duck typing and the ability to import additional libraries at runtime. A consequence of this functionality is that none of the software in this repository directly handles dependencies. Since the "dependencies" are set at runtime, the conventional ROS dependency process through catkin_make is not possible. As a result, you must manually ensure that the dependencies have been built!
With those issues said, the current components have been tested in a variety of ways and use cases.
The goal of the teleoperation link components inside this repository is to produce a general-purpose, robust, easy-to-use, and as-high-performance-as-reasonable network relay system for ROS. The raison d'être for this software is that while ROS natively supports distributed networked systems, it does not do so in a way that is directly suitable for limited-bandwidth datalinks. Even with GbE links, one can easily saturate the datalink between a robot and user workstation. In particular, ROS provides no inherent support for deduplication of data flow (i.e. two subscribers each get their own copies of data sent over the same network link) and encourages the unnecessary sending of particularly heavy-weight data (e.x. TF) that can better be handled by generating it at either end of the link. Therefore, this software is designed to serve as relay that uses a combination of existing ROS transport mechanisms and newly developed ones to reduce the data demands of robot operation, in particular with a focus on application towards teleoperation and supervised autonomy.
Certain experimental components enable multi-master distributed operation - however, these components are not used currently for the DRC.
Note - this software, while enabling similar functionality to the ROS Multi-Master project, is completely different with different goals and development philosophy. Use these packages if you want a link system designed specifically for low-bandwidth operations, or use Multi-Master if you want a system that behaves as close to "normal" ROS as possible.
The core architecture of this software consists of links that relay an ROS topic from one computer to another. Each link has two parts:
-
link_startpoint - Subscribes to the original topic. Using two services, it controls the flow and rate of data that it republishes. This node should be run on the computer where the original topic is published.
-
link_endpoint - Republishes the topic at the other end of the link. Connected to the startpoint, it automatically controls the flow of data depending on how many subscribers are connected.
This general architecture can be seen in the diagram below. link_startpoints and link_endpoints are shown in the magenta box.
Two general-purpose nodes written in Python implement this architecture - however, for high-performance use cases such as image and pointcloud transfer, additional special-purpose nodes written in C++ are provided. The image and pointcloud transfer nodes provide drop-in data compression to reduce bandwidth usage. Image compression is provided using the ROS image_transport library, while pointcloud compression is provided by either ZLIB or PCL's octree compression.
These packages aim to provide an ROS datalink that is virtually identical to the normal ROS system for publishers and subscribers. As always, you will publish and subscribe to topics. While the topics will obviously have different names, all functionality will be the same except (potentially) for specific very rare cases.
Fair warning, this flexibility comes at a cost - these packages require significant thoughtful configuration for any most use cases. Every single topic to be relayed must be explicitly configured to go through the link packages, and malformed configurations can produce extremely hard-to-debug errors. Running these nodes by hand is tricky, and we strongly advise using launch files to make your life easier.
Additionally, this flexibility is achieved by using a potentially large number of nodes - a general rule of thumb is that the nodes necessary for the link is 2n where n is the number of topics being sent over the relay. In general, this relay system should be used for as few topics as possible - it is a good habit in general for work over restricted datalinks to use as little data as possible - since it does impose additional processing requirements, especially when using image and pointcloud transfer.