All rapyuta.io docs are open source. See something that's wrong or unclear? Submit a pull request.Make a contribution
A routed network allows you to communicate between different ROS environments as described in the following scenarios.
In latency sensitive applications, when all the ROS environments are in (For example, in case of simulation), it is advised to use native network. For more information, click here.
In case of routed network, the rapyuta.io platform relies on a sub-component called the cloud bridge for implicitly establishing a communication channel between two or more ROS environments. It is an application-level bridge that offers many compelling features to ROS developers including augmented ROS over the public internet and dedicated features for dynamic multi-robot ROS communication.
When a user deploys a routed network to the cloud it is considered a cloud routed network. Any compute resources (CPU/memory) consumed by this routed network deployment count against your cloud deployment hours quota.
Package deployments in the cloud OR device can connect to a cloud routed network.
When creating a cloud routed network, the Resource limit field defines the memory allocation and computational capability of the routed network. These resources are reserved in the platform for effective ROS communication. You can choose the resource limit of a routed network based on the following requirements.
For the use case, let’s take an example of 3 ROS packages:
We want to establish a communication between 3 different ROS packages publishing and subscribing to each other. To overcome the heterogeneous infrastructure of networks between different packages, we can create a cloud routed network, for example, cloud_network_1, and use it at the time of deployments of each package as described in the following.
The result is as follows
In certain cases where communication is latency-sensitive or has high throughput, the user can choose to deploy a routed network to a device. While avoiding a round trip of information to the cloud minimizes latency and allows for better throughput ONLY deployments on devices on the same local area network can bind to it.
Routed networks can be deployed to a device with the following parameters:
On reboot, devices configured using DHCP may boot up with a new IP address and the network configuration of a deployed routed network becomes invalid. This can be avoided by assigning a static IP to the device you intend to deploy a routed network to esp in production systems.
For the use case, let’s take an example of 3 ROS packages:
We want to establish a communication between these 3 ROS packages. You can use a device routed network and use it at the time of deployments of each package as described in the following.
The result is as follows
We can achieve the communication by using a cloud routed network. However, using a cloud routed network might cause a latency in the communication even if the devices are sharing the same local area network.
Read scenarios hyperlink to http://localhost:1313/5_deep-dives/53_networking-and-communication/534_ros-communication/#illustrating-a-multi-robot-scenario
Avoid complex hardcoded logic in launchfiles that lives with the source code or binary and automatically add/remove prefixes to ROS interfaces(topics/services/actions). Additionally, it is more flexible/dynamic to assign and use deploy-time identities than hard-coded robot names.
The process of assigning an identity to a robot and the mechanisms to consume/discover identities of all alive robots is described in the ROS environment aliases topic.
The mechanisms and features offered by the platform to deal with automatic prefix addition and removal is described in the scoping and targeting topics.
When deploying a component to a robot in a multi-robot scenario, the platform expects the user to input a unique alias per component , thereby, assigning a stable identity to that deployment for the period of its lifetime.
This alias defined at deploy-time uniquely identifies the robot in the scope of an ensemble of connected peers.
All components in the same package (each potentially deployed in a physically different device/location) or linked dependent deployments are considered a part of an ensemble.
The platform detects duplicates aliases explicitly for the case of components and deployment and its immediate parent.
This alias is available to Deployment Executables (both cloud and device) through RIO_ROS_ENV_ALIAS environment variable.
In the case of siblings (two deployments depending on the same parent), the component with a duplicate alias is considered a conflict and may enter an error state. The user must be careful and ensure the uniqueness of identities present in this case.
rapyuta.io automatically exposes a latched ROS topic /rapyuta_io_peers of type std_msgs/String, which contains the list of all connected peers aliases, the first entity is always the alias of the local bridge.
For example, My_alias,peer_1,peer_2
The end-user can potentially use this in their ROS applications for discovering connected robots.
There may be more than one bridge locally depending on how you deployed the packages and components so you may receive multiple messages. In each case, the first element is always the alias of the bridge that published this message.
In this configuration, a user may declare a topic/service/action as scoped by selecting the Scoped option.
This indicates that when a component is deployed its local ROS interfaces (topic/service/action) get automatically prefixed/namespaced bits own dynamic identity (its own ROS environment alias) as seen by all other robots/peers in the ensemble in their respective ROS graph.
For example, suppose robotA publishes /odom topic in its local ROS environment. While routing /odom to either of the robot peers (for instance a controller) the topic is prefixed with that specific robot’s name, in this case, /robotA/odom.
You can express scoped as: A scoped topic is a mapping from a /topic to /robot-peer-name/topic.
/odom ——-> /robotP/odom
If in the ROS message logs you experience the error: incoming connection failed: unable to receive data from sender, check sender’s logs for details, please ignore it. The error message is generated by ROS internally as a side effect of the sniffing done by the cloud bridge to determine metadata related to ROS message type for the service. It has no other effects on your code and/or the code’s functionality, and you can safely ignore it.
In this configuration, a user may declare a topic/service/action as targeted by selecting the Targeted option.
This indicates that when a component is deployed its local ROS interfaces (topic/service/action) containing a prefix/namespace corresponding to another individual peer’s dynamic identity (peers ROS environment alias) gets routed to the corresponding peer and automatically unwraps the prefix/namespace in its ROS graph.
For example, suppose robots in a particular scenario subscribe to the topic /cmd_vel to move and a central controller needs to ask a specific robot, say robotA, to move, then it needs to be able to target only robotA and send messages to its /cmd_vel subscription.
The controller in the above scenario publishes /robotA/cmd_vel topic. While routing /robotA/cmd_vel the bridge strips the prefix robotA and publish the messages on the topic /cmd_vel in robotA’s local ROS environment.
You can express targeted as: A targeted topic is a mapping from /robot-alias/topic to /topic.
/robotP/cmd_vel ———–> /cmd_vel
When a package allows for inbound ROS interfaces, you must provide hints to leverage the automatic targeting feature. The platform introspects the package to determine if it must enforce the unique identity constraints required for multi-robot communication.
As the platform follows a provider only semantic, determining this is straightforward for scoped as it is based on the identity of the deployment itself. It gets complicated for targeting as this depends on the identity of other peers. When a package is the first to be deployed (or root in any particular subtree of dependants) it becomes necessary to provide a hint to indicate that the interfaces will participate in communication topologies that require the presence of a stable unique identity.
To provide this hint while creating the package, in the Additional Information section, when one adds inbound ROS topics/services/actions one can select the can be targeted. This metadata is used by the platform to bridge communications and enforce alias constraints.