Skip to main content

Telemetry Receiver

The Telemetry Receiver component allows you configure what telemetry data you want from which callsigns on the local network. By adding callsigns, sources and destinations to this component's configuration you can subscribe to data from multiple robots on the local network, then forward the received data on to the destination you define.

Please note that in order for other robots' data to be available, there must be both a Telemetry Gateway component configured for one of the agents on the network, and each of the other robots must have a Telemetry Sender component configured to point to the gateway.

Configuration

To use the Telemetry Receiver plugin, your agent will need a section in its agent-settings.json file which enables the telemetry-receiver component, as shown below. For more information on how to configure the agent plugins, see Agent Configuration.

...
"components": [
...
{
"enabled": false, // set this to true to enable this plugin
"id": "telemetry-receiver", // the unique identifier for this plugin - don't change this
"settings": {
"address": "192.168.0.10:8080", // the local network address and port of the Telemetry Gateway component
"logLevel": 1 // the log level for this component. Choose a range between 1 (least verbose) to 6 (most verbose),
"subscriptions": [
{
"callsigns": ["my-robot-callsign"], // the callsigns of the robots whose data you want to consume on this robot
"sources": ["/rosbridge/odom"], // the sources you want to retrieve from the robots on the LAN
"destination": "/rosbridge-control/odom", // where you want to send the data you receive
"destinationType": "nav_msgs/Odometry" // the destination type of the data. If you omit this setting the type will be std_msgs/String
}
]
}
},
...
]

The subscriptions array represents a set of definitions for data you want from a set of callsigns, i.e. other robots on the LAN. For each subscription you supply a list of callsigns from which you want to stream data, you provide a list of sources that you want to retrieve (for example, ROSBridge Odometry data), and then where you want to send it (destination). Destination must be a component which accepts control, such as ROS or MAVlink.

Destination Type can be omitted and destination components will choose sensible defaults, if they can.

When defining the sources you want to capture, you may also define their TTL, Deadline and whether you want them to be resent if they fail (retry). These are described below.

ParameterUsageExample
ttl (Time to Live)The amount of time a message is allowed to be queued before it is considered expiredttl=10s
dl (Deadline)The amount of time the agent will try sending a specific message post before giving updl=100ms
dqp (Dequeuing Policy)Determines which of the available queued messages should be sent next: refer to the documentation for the Teleop Sender plugin.dqp="FIFO"
txp (Transmission Policy)Determines how messages should be transmitted, and whether acknowledgements of successful transmissions should be required: refer to the documentation for the Teleop Sender plugin.txp="UNARY"
int (Interval)The desired time between messages, i.e. the sample intervalint=300ms

These parameters can be appended to the sources as a query string. For example:

/rosbridge/odom?int=1s&dl=300ms&ttl=2s&dqp="FIFO" will instruct the agent to:

Queue a message for sending every 1 second, sending the oldest queued messages first.

Try for 300 milliseconds to send the message, then abandon the attempt and try again; however if a message gets to be 2 seconds old, then just abandon it entirely and move on to the next.

The units of time allowed are summarized below:

Abbreviation / UnitExample
h - Hour2h
m - Minute34m
s - Second15s
ms - Millisecond800ms
us - Microsecond400us
ns - Nanosecond80ns