Routed network is a rapyuta.io resource to enable ROS communication between different ROS package deployments. Binding a routed network resource to your deployment will enable other deployments on the same routed network to consume ROS topics/services/actions as defined in the package. Data flow occurs only when another package chooses to subscribe to a topic, call a service or call an action.
For the purpose of this illustration, lets assume the following network and packages.
We deploy the packages described above in the following configuration.
The result is as follows
A routed network can be deployed to a cloud or to a device.
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 bind to a cloud routed network. When you create a cloud routed network, you must define the resource limit of the routed network.
When creating a cloud routed network, the Resource limit field define the memory allocation and computational ability 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.
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.
On reboot devices configured using DHCP may boot up with a new IP address. This will cause the network configuration of a routed network deployed on it to become 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.
Follow this walkthrough to create and use a routed network.