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.
The below list of topics are explained:
The rapyuta.io platform offers an elegant solution for multiple robots communication as a primary feature. In the rapyuta paradigm, the component of each package is treated as an isolated ROS environment. While declaring the package you are only required to provide the topics/services/actions required to be exposed by that particular component. The platform is then responsible for connecting, managing and securing the ROS environments together. We introduce a set of new features aimed at making it a lot easier to use multiple robots.
To illustrate a scenario involving multiple robots we turn to an example involving the world’s favorite sport - soccer. Similar topologies are often relevant in real-world applications of robots such as warehouses where a coordinator controls multiple AMR/AGVs
Imagine a game of robot soccer where players are robots, and their coach is a controller unit.
The players follow a simple convention
Now if the coach (controller) needs to use this information from all players(robots) in the field. To deal with multiple players(robots) it is necessary to create a convention that allows him to specifically access information about one specific player(robot) and issue commands to one specific player(robot).
In the ROS community, the common approach used in multi-robot communication scenarios is to prefix or namespace the interfaces (topics/services/actions) by a unique identity typically the name of the robot.
Following this convention, if the coach(controller)
This isvachieved using carefully crafted launchfiles using remaps (e.g. /move to /robot_A/move), conditionals (e.g. unless ns!=“” or if robot_name==“robot_A”), arguments(e.g. robot_name:=robot_A) and namespaces(e.g. <node ns=robot_A>). This mandates the delicate arrangement of files is frozen while building the software and consistently distributed to all involved agents. As the needs/software change and the number of variables and robots increase, this approach becomes increasingly error-prone.
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.
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 ROSmsg 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 so as 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 identitiy (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.
When a package declares a ROS interface like a ROS topic/service/action, it is automatically made available to ROS nodes of other deployments linked via the available design patterns like a dependent deployment.
Conside a sample composition such that two deployments:
that depend on a deployment S (corresponding to package P). The user would quickly recognize that C1 and C2 are effectively sibling deployments with respect to a parent deployment S.
In this scenario, the following ROS specific interfaces are defined by the packages Q1 and Q2 corresponding to C1 and C2 respectively.
This set up is illustrated as shown below.
In such circumstances, availability of a topic/service/action is dictated by the inbound interfaces defined by the package P. In the above example, only /test_topic and /test_service (seen as /C2/test_service) are available to ROS nodes in the deployment S, while /test_topic2 will not.
A key side effect is all of the deployments that depend on S (C1 and C2) will also have available an identical configuration of ROS topics/services/actions to their ROS nodes. In this case, /test_topic and /test_service (seen as /C2/test_service).
Special case: when package P is the publicly provided Rapyuta IO Local Communication Broker package, the package is then equivalent to a package with an Allow All inbound ROS interface configuration. This implies all of the ROS topics/services/actions provided by any child deployments are available to all dependent siblings. In the above example, /test_topic, /test_topic2 and /test_service (seen as /C2/test_service) are available to both C1 and C2 (and any other siblings).
rapyuta.io makes ROS topics/actions/services available to the rosgraph in the target deployment based on the composition. However, data does not flow unless a ROS node within a particular deployment tries to consume it by subscribing to a topic or performing a service request.