Generic Relay Setup

If you're trying to set up a relay for an image topic, a camera, or a pointcloud, use this as an introduction to how relay software is configured. See Setting up an image topic relay or Setting up a pointcloud topic relay for those use cases!

Overview

Setting up a topic relay involves configuration at both ends. Since the generic relay nodes must support a wider range of options, they also require noticeably more configuration than special-purpose nodes.

To see the material covered in this tutorial applied to DRCHubo, see launch files backpack.launch and workstation.launch.

Setting up the "startpoint"

The general-purpose startpoint node is request_link_startpoint.py in the opportunistic_link package. This node requires 3 parameters to be set:

• input_topic_name - the name of the original topic you want to relay, such as /rosout_agg

• topic_type - the name of the message type of the topic, such as std_msgs/String You must provide both package and type names, or the node will be unable to import the necessary dependencies!

• request_service - the name of the service used to forward messages between the startpoint and endpoint, such as /rosout_agg/data

In general, the following is a good pattern to use:

input_topic_name = "/rosout_agg"
topic_type = "rosgraph_msgs/Log"
request_service = input_topic_name + "/data"

Setting up the "endpoint"

The general-purpose endpoint node is request_link_endpoint.py in the opportunistic_link package. This node requires 7 parameters to be set:

• output_topic_name - the name of the relayed topic, such as /rosout_agg/relay

• topic_type - the name of the message type of the topic, such as std_msgs/String You must provide both package and type names, or the node will be unable to import the necessary dependencies!

• request_service - the name of the service used to forward messages between the startpoint and endpoint, such as /rosout_agg/data

• rate_ctrl - the name of the service to to set the rate, in hz, to attempt to republish at - in reality, the republish rate is effectively limited by the available bandwidth - for example, /rosout_agg/rate

• default_rate - sets the default republish rate

• latched - selects if the publisher should latch the last message published, which means that the last message will be available to all future subscribers

• override_timestamps - selects if the publisher should reset the message timestamps to the time of receipt. This is useful in particularly high-latency or low-rate environments where the time delta between sending and receiving a message would cause problems with TF. This is a bit ugly, since it means that timestamps no longer identify when a message was sent, but this is usually safe so long as TF data is similarly delayed. If your messages are delayed but TF is not, you should try increasing the TF cache time before setting this parameter.

To make your life easier, these parameters are tightly coupled to the settings for the startpoint. The only values that can be independently chosen are output_topic_name, latched, and override_timestamps. The choice of output_topic_name should be simple and easy to understand. In almost all scenarios, setting latched to true provides the most reliable performance. Conversely, in most scenarios, override_timestamps should be set to false. In general, the following is a good pattern to use:

output_topic_name = input_topic_name + "/relay"
topic_type = rosgraph_msgs/Log
request_service = input_topic_name + "/data"
rate_ctrl = input_topic_name + "/rate"
default_rate = 20
latched = true
override_timestamps = false