Help us make these docs great!

All rapyuta.io docs are open source. See something that's wrong or unclear? Submit a pull request.

Make a contribution

ROS Native Networks

Native Network is a beta feature.

A native network allows you to communicate between different ROS environments as described in the following scenarios.

  • ROS environments that are deployed in the cloud.
  • ROS environments that are deployed in the device within the same local area network.

This eliminates the need of creating a separate routed network for the local communication and significantly decreases the latency as the communication doesn’t involve a cloud bridge for individual ROS environments for communication.

In case of native network, all the connected ROS environments can discover each other and the communication happens in a peer-to-peer manner. Each ROS environment has its own ROS master and the rapyuta.io platform uses a sub-component based on FKIE multimaster to achieve it.

Cloud Native Network

When you deploy a native network to the cloud, it is considered as a cloud native network. Any compute resources (CPU/memory) consumed by this routed network deployment count against your cloud deployment hours quota.

Resource Limit

When creating a cloud native network, the Resource limit field defines the memory allocation and computational capability of the native network. These resources are reserved in the platform for effective ROS communication. You can choose the resource limit of a native network based on the following requirements.

  • number of topics/services/actions
  • number of publishers/subscribers/services that will be activated under a particular native network.

You can connect your deployments to more than one cloud native networks for redundancy.

Use Case

For the use case, let’s take an example of 3 ROS packages:

  • package_A, package_B, and package_C are deployed in the cloud.

We want to establish communication between these 3 ROS packages. To simplify this communication, you can use a native network that serves as the best medium for communication.

  • Deploy package_A binding to the native network, native_network_1, as deployment_A.
  • Deploy package_B binding to the native network, native_network_1, as deployment_B.
  • Deploy package_C binding to the native network, native_network_1, as deployment_C.

The result is as follows

  • We have established communication between the packages deployment in the cloud (as they are considered as being in the same local area network)

We can establish this communication by using a cloud routed network. However, using a routed network involves cloud bridge for each ROS environment that adds latency when service/action/topics are being called in the same local area network.

Pros

  • Communication through a native network is happening in a peer-to-peer manner that means the subscriber directly makes TCPROS connection with the publisher thereby eliminating the latency in each hop-on of messages as in the case of a routed network via cloud bridge. This results in low-latency communication.

  • You can see the list of publishers whitelisted in your package components in your rostopic list command.

  • Native network is very similar to the local single ROS master environment.

Cons

  • The cloud native network is only applicable only for local communication.

When you subscribe to a topic from a different ROS environment, this subscriber information is kept locally and only shared if a topic is whitelisted in a package component.

Device Native Network

Currently supported for cloud runtime only. You can use a routed network instead of a device native network as of now.

Multi-Robot Communication

  • Communication is happening in a peer-peer manner, which means different ROS masters or environments are connected via platform using a sub-component based on FKIE multi master nodes (master-discovery and master-sync). These two nodes are responsible for establishing the communication between ROS masters that are in the same network.
  • Native network doesn’t share the parameters between different ROS environments.
  • Platform only whitelists the topics/service mentioned in the package component, and the platform doesn’t interpret or listen to the data flowing between them unlike in case of a routed network thus reducing the latency. It only shares publisher/service information on the network.
  • Scoped or targeted topics (service or action) are the functionalities of a routed network. In the case of a native network, topics are whitelisted in the form of /*/topics and you can use remap or add namespaces to these topics for communication. For more information on remapping, click here.
  • While deploying a package, you can mention ROS Environment Alias in case of native network as well. Users can use $RIO_ROS_ENV_ALIAS environment variable set by rapyuta.io add ROS_NAMESPACE in your ROS environment, which will help you in doing namespacing.

for tf topic: if you don’t add tf_prefix, don’t expose the topic as there is a possibility of mixing of tf.

Compression, QOS, and Service Timeout are not applicable in the case of native networks.