Skip to main content

Telemetry Sender

The Telemetry Sender component configures how the DroneDeploy Agent sends real-time telemetry streams to the Robot Automation Platform and LAN based telemetry gateways. By default there is one configured to send telemetry to the Robot Automation Platform, however you can configure others to send data on the local network, as long as at least one agent installation has the related Telemetry Gateway component configured.

Configuration

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

Warning

If you disable the default sender named 'cloud' (with the remote DroneDeploy API address) you will not be able to see real time data from this robot on the Robot Automation Portal.

...
"components": [
...
{
"enabled": false,
"id": "telemetry-sender",
"settings": {
"name": "cloud",
"address": "192.168.0.10",
"defaultDeadline": 300,
"defaultTtl": 500,
"defaultDQPolicy": "FIFO",
"defaultTxPolicy": "UNARY",
"logLevel": 3
}
},
...
]

The Telemetry Sender plugin understands the following configuration parameters:

NameDescriptionDefaultUnits
enabledWhether to enable the telemetry sender plugin or not.false
nameHow this instance of the telemetry sender plugin should be named. Multiple instances of the plugin each require a unique name to differentiate them."cloud"
logLevelThe logging verbosity: 1 - very quiet, 6 - very talkative3
addressRequired: the local network address of a configured Telemetry Gateway component on another Agent; or the address of the Robot Automation Portal.
defaultDeadlineThe maximum length of time which each attempt at sending a message over the network is allowed to run for, before the attempt is considered failed. The plugin will automatically attempt to resend failed messages.
Deadline values of less than 300ms are allowed, however a value of 0ms is invalid, and will be automatically converted to a deadline of 100ms.
300ms
defaultTtlThe time which incoming message data is considered to remain valid, before becoming 'stale'. Message data is held in a queue while it is waiting to be sent; once a message becomes stale, the message is deleted from the queue and will never be sent. This value should always be higher than the deadline.500ms
defaultDQPolicySelects the policy which is used to choose which of the messages currently queued to be sent should be selected next. Valid values are:
"FIFO" - Messages are always transmitted in the order they are received, oldest message first. If the TTL is set to a long time, that means that the messages being received at the portal could be quite old, but this provides the highest confidence that important messages will eventually get through.
"FILO" - Messages are sent in reverse order, with the newest message being sent first, and the oldest queued message being sent last. This means messages will arrive in the portal out of order. You probably don't want this option.
"LAST" - The newest message which is newer than the last message successfully transmitted will be sent next, and any older messages will be abandoned. This option is best for live data where latency is important.
"FIFO"
defaultTxPolicySelects the method which is used for transmitting messages. Valid values are:
"UNARY" - Messages are sent one at a time, and the receiver confirms each message has arrived correctly. This ensures that no messages are lost in transit. However, the rate at which messages can be sent will be limited by your network latency - if you have 200ms ping to the server, then you will only be able to send messages at a rate of 5Hz.
"FF" - Messages are sent as a continuous stream, without any confirmation that each message has arrived correctly. This allows a much higher rate of transmission, but allows the possibility that some messages may be lost in transit due to network disruptions.
"UNARY"
Warning

The "STREAM" option for defaultTxPolicy is not supported when sending to a local Telemetry Gateway, only directly to the Robot Automation Portal.