All rapyuta.io docs are open source. See something that's wrong or unclear? Submit a pull request.Make a contribution
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.
Native network: A native network allows you to communicate between different ROS environments as described in the following scenarios.
Routed Network: A routed network allows you to communicate between different ROS environments as described in the following scenarios.
For this illustration, let’s assume the following network and packages.
We deploy the packages described above in the following configuration.
The result is as follows
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.
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 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.