In this article
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 contributionROS Communication
The rapyuta.io platform relies on a resource called ROS network for establishing a communication channel between two or more ROS environments.
Using a network resource to your deployment will enable other deployments on the same network to consume ROS topics/services/actions as defined in the package component. Data flow occurs only when another package chooses to subscribe to a topic, call a service or call an action.
ROS Network Types
-
Native network: 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.
-
Routed Network: A routed 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 (can be in same or different networks)
- A combination of both
Illustrated Example
For this illustration, let’s assume the following network and packages.
- You have a routed network networkN
- You have PackageA publishing “topicA”
- You have PackageB publishing “serviceB”
We deploy the packages described above in the following configuration.
- Deploy PackageA binding to the network networkN as DeploymentA
- Deploy PackageB binding to the network networkN as DeploymentB
The result is as follows
- ROS nodes in DeploymentA can now call “serviceB”
- ROS nodes in DeploymentB can now subscribe to “topicA”
Multi-Robot ROS Communication
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 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.
Illustrating a Multi-Robot Scenario
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
- A player moves to a position when it receives a message on the /move topic
- A player publishes its pose and location through /odom.
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)
- wants to move robot A in a specific direction, it must explicitly publish /robotA/move that is subscribed by robot A (or /robotB/move and /robotC/move to robot B and robot C respectively)
- wants to seek odom from robot A, it must explicitly subscribe to /robotA/odom that is published by robot A (or /robotB/odom and /robotC/odom from robot B and robot C respectively)
This is achieved 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.
