Robot to Robot LAN Connectivity

The DroneDeploy agent provides the ability to share data between robots on a local area network (LAN) which opens up a variety of applications. For example:

1. Collect data from one robot, process it on another, and share it with a 3rd robot
2. Subscribe to data from a robot in remote location via the Cloud, process that data locally then share it with a number of robots either on the LAN or in the Cloud
3. Master data on one robot, then share it with several robots simultaneously

This tutorial steps you through subscribing to one robot's data from another. We'll refer to the robot generating the data as the 'Sender Robot', and the robot subscribing to the data the 'Receiver Robot'. We'll assume both robots are running ROS on Ubuntu.

Setup the Agents

Firstly, ensure the DroneDeploy Agent is installed and configured on each of the robots, following the instructions here.

To more easily see what's happening, on each of these machines we'll stop the default systemd service and instead run the agent in the foreground. On each machine, in a bash terminal do the following:

sudo systemctl stop rocos-agent

Before we run the agent in the foreground we'll update the configuration on each robot to activate the LAN connectivity.

On both the Sender and Receiver Robots

The configuration changes are identical for each robot so they're only shown here once. Duplicate the instructions below for both the Sender and Receiver robots.

We'll open the agent configuration file for editing:

sudo nano /etc/opt/rocos-agent/agent.json

Configure the LAN Sender

This step enables a telemetry sender which allows the agent on both the Sender and Receiver robots to dial a gateway on the LAN for sending and receiving telemetry. In a subsequent step we'll configure the component which provides the gateway functionality.

In the text editor that is displayed, navigate to the "components" top-level property, which is a JSON array. Find an object with id "teleop-sender", then:

1. Duplicate the entire object
2. Change the name of the new object to 'teleop-local'
3. Change the address property of the second object to the IP address of the Sender robot
4. Increase the log level to '4' so we get more information about how it's interacting with the local gateway

... 
{
    "enabled": true,
    "id": "teleop-sender",
    "settings": {
      "name": "teleop-platform",
      "address": "api2.rocos.io:80",
      "logLevel": 1,
      "defaultDeadline": 300,
      "defaultTtl": 500,
      "defaultDQPolicy": "LAST",
      "defaultTxPolicy": "STREAM"
    }
  },
{
    "enabled": true,
    "id": "teleop-sender",
    "settings": {
      "name": "teleop-local",
      "address": "192.168.1.12:8080",
      "logLevel": 4,
      "defaultDeadline": 300,
      "defaultTtl": 500,
      "defaultDQPolicy": "LAST",
      "defaultTxPolicy": "STREAM"
    }
  },  						
...

On the Sender Robot

Now we've configured both robots to have a sender component, we'll configure a gateway on the Sender. The gateway is the component on the LAN which receivers connections from Senders and Receivers, and matches subscriptions from the Receiver up with any registered Senders which have the data the Receiver is interested in.

For this tutorial the gateway is configured on the Sender, but it doesn't have to be. It can be configured on the Receiver, or on a completely different robot or ground control station, as long as the robots can reach each other across the LAN.

Configure the Telemetry Gateway

In a bash shell to the Sender robot, run the following command (it may still be open from the previous step):

sudo nano /etc/opt/rocos-agent/agent.json

In the editor that appears, find the "components" property and within it, a JSON object with id "telemetry-gateway". Then do the following:

1. Ensure the "enabled" property is set to "true"
2. Change the log level to "4" so we have more visibility of what is happening when we eventually run the solution
3. Change the address property to the address where other robots can reach this Sender robot on the LAN (an example is provided below).

...
{ 
  "enabled": true,
  "id": "telemetry-gateway",
  "settings": {
      "address": "192.168.1.12:8080",
      "logLevel": 4
   }
},
...

On the Receiver Robot

We've now configured components to establish send and receive connections on both robots, the component which brokers telemetry data between senders and receivers on the Sender robot, and we'll now configure the component which tells the agent on the Receiver robot what to do with the telemetry data it receives.

Configure the Telemetry Receiver

We'll now configure the telemetry receiver component to tell it what telemetry to subscribe to, and what to do with the data when they're received. This configuration tells the agent on the Receiver robot which callsign and telemetry URI to subscribe to, and where to send it when it arrives.

Within the "components" array, find the the object with id "telemetry-receiver", then:

1. Ensure it is enabled by setting the "enabled" property to "true"
2. Change the address to match the same address you entered above when you configured the the LAN Sender, and the same address the Telemetry Gateway component has configured (example address shown below)
3. Increase the log level to "4" for more debug visibility later when we test the solution
4. Add a subscription. You can configure multiple subscriptions - each subscription can specify multiple sources and callsigns, but for each subscription you can only choose one destination. If you need a second destination or a variety of sources and callsigns, simply duplicate this object within the 'subscriptions' array.

Within a subscription object, the sources property is an array of URIs on the Sender whose telemetry you want to stream to the Receiver.

The callsigns property is an array of robot callsigns where the telemetry originates from (in this case, the Sender's callsign)

The destination property is the URI relative to the Receiver where you want to publish the data when it arrives. In this case it uses the ros component to send the data to a new topic in ROS on the Receiver. For convenience later, we suggest the destination topic includes the Sender's callsign so it's obvious where the data has originated from later when viewing the Receiver's data.

The destinationType property tells the component what the message type is of the destination topic. If the topic does not exist in ROS the telemetry receiver component will create it with this message type. If you don't specific a message type the topic is created with the type std_msgs/String message type.

...
{
  "enabled": true,
  "id": "telemetry-receiver",
  "settings": {
      "address": "192.168.1.12:8080",
      "logLevel": 4,
      "subscriptions": [
      {
         "sources": ["/ros/odom"],
         "callsigns": ["sender-callsign"],
         "destination":"/ros/sender-callsign/odom",
         "destinationType": "nav_msgs/Odometry"						
      }
 ] 
},					
...

We've now told the agent on the Receiver agent which data sources to subscribe to for which callsigns, and where to send the data when it arrives.

Still on the Receiver robot, we'll configure the agent to accept control messages so that we're able to route messages to the ros component.

Configure the Receiver Robot for ROS Control

This step is required to enable the telemetry-receiver component to write messages to ROS locally.

Within the "components" array, find the object with id "ros", then:

1. Ensure "enabled" is set to "true"
2. Ensure the ROS___MASTER_URI property is set correctly to point to the Receiver's instance of ROS
3. Ensure the ROS_PACKAGE___PATH property is set correctly to point to the ROS message definitions

...
 {
    "enabled": true,
    "id": "ros",
    "settings": {
      "logLevel": 1,
      "name": "ros",
      "ROS_MASTER_URI": "http://127.0.0.1:11311",
      "ROS_PACKAGE_PATH": "/opt/ros/melodic/share"
    }
  },					
...

Run the Solution

You're now ready to run the agent on both robots to test the LAN sending and receiving.

Assuming ROS is running on both the Sender and Receiver robots, start their agents in the foreground by running the following in a bash shell:

sudo rocos-agent -d

Watch carefully for any errors displayed. The most common cause of errors is misconfigured IP addresses and callsigns.

If it looks like both agents are running happily, you can open the Robot Automation Portal, navigate to the Receiver robot in the robots list, navigate to the Live Data Viewer and see the "/ros/sender-callsign/odom" topic data being published from the Sender via the Receiver.

You've now configured one robot to subscribe to data from another robot, effectively relaying ROS topic data to the cloud through an intermediate robot.