ROS

The ROS plugin connects the ROS network on your ROS based robot to the DroneDeploy Robotics Portal. Unlike the ROSBridge plugin, the ROS plugin hooks in directly to ROS without needing any other software installed on the robot - the ROS plugin will appear as a ROS node to other ROS components on your robot.

The ROS plugin is bidirectional; it can both subscribe to ROS messages and send them upstream to the DroneDeploy Robotics Portal, as well as receive downstream message from the DroneDeploy Robotics Portal and publish them into the ROS network.

Data Model

The data model for the message sent and received by the ROS plugin are determined by the ROS message topics used on the ROS network to which the plugin is connected.

Receiving (Upstream) Messages

In order to receive ROS messages from your robot, the ROS plugin needs to understand the dialect of the ROS messages being used. In order to do this, the ROS plugin needs access to the ROS message files (see here for more information) which describe the messages in use. You will need to configure the ROS plugin with the location of these files, as described in the Configuration section.

Note

The ROS plugin searches for message files once each time that it starts up; if you change or create a message file while the Agent is running, you will need to disable and then re-enable the ROS plugin so that it searches for new messages.

The ROS plugin will automatically discover the topics being published on the connected ROS network, and expose them as data URIs that you can read data from. The content of ROS messages is automatically converted into a JSON representation to allow access and binding to individual message fields.

Once the message files have been discovered by the Agent, then when ROS message topics become available (i.e. when a ROS node begins advertising a topic) the topic, and the fields contained therein, will become visible in the data picker:

ROS messages received automatically have two pieces of metadata applied:

Metadata Field	Description	Example
`ros.type`	The ROS message type of the original message.	`"geometry_msgs/Twist"`
`ros.node`	The name of the ROS node which published the message.	`"sensor1"`

Sending (Downstream) Messages

In order to send ROS messages to your robot, the ROS plugin needs to understand the dialect of the ROS messages being used. In order to do this, the ROS plugin needs access to the ROS message files (see here for more information) which describe the messages in use. You will need to configure the ROS plugin with the location of these files, as described in the Configuration section.

The ROS plugin needs to know the ROS message type for each downstream message being sent. You should include this information in the Metadata field for each control message, for example:

{
  "ros.type": "geometry_msgs/Twist"
}

The ROS plug needs the contents of each downstream message being sent, in the Payload Template field, to be structured in a particular JSON representation. For example, the contents of the geometry_msgs/PoseStamped message might look like:

{
"header":{
    "stamp": {
      "secs": 0,
      "nsecs": 0
    },
    "frame_id": "map",
    "seq": 1
  },
"pose":{
    "position": {
      "x": 1,
      "y": 2,
      "z": 3
    },
    "orientation": {
      "x": 0,
      "y": 0,
      "z": 0,
      "w": 1
    }
  }
}

Configuration

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

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

The ROS plugin understands the following configuration parameters:

Name	Description	Units	Default
`enabled`	Whether to enable the ROS plugin or not.		false
`name`	How this instance of the ROS plugin should be named.		"ros"
`logLevel`	The logging verbosity: 1 - very quiet, 6 - very talkative.		4
`ROS_MASTER_URI`	The URI where the ROS plugin can contact the ROS master node on the robot. You will need to set this to suit your robot: it should be set to match your `ROS_MASTER_URI` environment variable.
`ROS_PACKAGE_PATH`	A colon delimited list of paths in which ROS packages can be found on your robot. The ROS plugin needs to know this information so that it can find the ROS `msg` files which your robot uses to communicate. You will need to set this to suit your robot: it should be set to match your `ROS_PACKAGE_PATH`environment variable.
`ROS_NAMESPACE`	Allows pushing the ROS plugin's node down into a namespace.
`ROS_LOG_DIR`	Allows changing the ROS log directory the ROS plugin's node will use: this typically has no affect, since the plugin does not itself log any messages to the ROS system.
`ROS_HOSTNAME`	Allows changing the ROS hostname used by the ROS plugin's node.
`pollingPeriod`	How frequently the ROS plugin should look for any new ROS topics which are available to subscribe to.	ms	2000
`keepOldTopics`	Whether topics which no longer have any ROS publishers should continue to be listed as available or not.		false
`publisherLifetime`	When the ROS plugin publishes a downstream message from the platform, a ROS publisher is created and advertised by the ROS plugin's node. This setting determines how long that publisher should continue to be advertised after each downstream message. If set to a non-positive value, then the plugin's ROS publishers will never expire.	s	300
`delayNewPubs`	When the ROS plugin publishes a downstream message from the platform, a ROS publisher is created and advertised by the ROS plugin's node. This setting determines how long the ROS plugin should wait between creating the publisher and transmitting the first message. Allowing a short delay here may help other ROS nodes from missing the published message if they are slow at subscribing.	ms	0
`runRosTests`	When set to true, the ROS plugin will perform some tests at startup. If you have issues with configuring the ROS plugin to work correctly with your robot's ROS installation, these tests may assist in diagnosis. ‼️ These tests will publish some simple ROS messages. They should not interfere with operation on most sane ROS systems, but please take care when running the tests.		false
`rosLogLevel`	Controls log verbosity from the underlying ROS library; this is only required for advanced diagnostic purposes: 1 - very quiet, 6 - very talkative.		1
`blacklistServices`	The ROS component ignores some ROS standard tooling services such as RVIZ, RQT, and ROSTOPIC by default. This config parameter can be used to specify the blacklist services in the regex format. If it is desired to not ignore these services, an empty list should be defined.		`[<br/>` `".rviz._[0-9]+",` ".rqt.[0-9]+", ".rostopic.[0-9]" `]`

ROS

Data Model​

Receiving (Upstream) Messages​

Sending (Downstream) Messages​

Configuration​

Data Model

Receiving (Upstream) Messages

Sending (Downstream) Messages

Configuration