All rapyuta.io docs are open source. See something that's wrong or unclear? Submit a pull request.Make a contribution
Native Network is a beta feature.
A native network allows you to communicate between different ROS environments as described in the following scenarios.
Native networks eliminate the need of creating a separate routed network for the local communication and significantly decreases the latency as the communication doesn’t involve a cloud bridge for individual ROS environments for communication.
In case of native network, multiple ROS environments (all ros nodes sharing the same ROS_MASTER_URI are considered a single ROS environment) can discover each other (these could be filtered based on the list of topics/services provided) and the communication happens in a peer-to-peer manner. Each ROS environment has its own ROS master and the rapyuta.io platform uses a sub-component based on the open-source FKIE multimaster to achieve it.
for tf topic: if you don’t add tf_prefix, don’t expose the topic as there is a possibility of mixing of tf.
Compression, QOS, and Service Timeout are not applicable in the case of native networks.
For the use case, let’s take an example of 3 ROS packages:
We want to establish communication between these 3 ROS packages. To simplify this communication, you can use a native network that serves as the best medium for communication.
The result is as follows
We can establish this communication by using a cloud routed network. However, using a routed network involves cloud bridge for each ROS environment that adds latency when service/action/topics are being called in the same local area network.
Communication through a native network is happening in a peer-to-peer manner that means the subscriber directly makes a connection with the publisher thereby eliminating the latency in each hop-on of messages as in the case of a routed network via cloud bridge. This results in low-latency communication.
You can see the list of publishers whitelisted in your package components in your rostopic list command.
Native network is very similar to the local single ROS master environment.
When you subscribe to a topic from a different ROS environment, this subscriber information is kept locally and only shared if a topic is whitelisted in a package component.
When you deploy a native network to the cloud, it is considered as a cloud native network. Any compute resources (CPU/memory) consumed by this native network deployment count against your cloud deployment hours quota.
When creating a cloud native network, the Resource limit field defines the memory allocation and computational capability of the native network. These resources are reserved in the platform for effective ROS communication. You can choose the resource limit of a native network based on the following requirements.
You can connect your deployments to more than one cloud native networks for redundancy.
When you deploy a native network to a device, it is considered as a device native network. This allows for ultra low latency peer-to-peer connections between ros nodes in a Local Area Network(LAN) i.e ONLY deployments on devices on the same LAN can bind to it.
Native networks can be deployed to devices that fulfill the following requirements:
To use device native networks the user needs to re-onboard the device (to install and enable the new services). Also ensure that cpuset and memory cgroups are enabled.
If the user re-onboards the device the user needs to go and reset the
network_interface config variable.
For instance use native networks with a Raspberry-Pi consider adding the following in /boot/cmdline.txt.
cgroup_enable=cpuset cgroup_enable=memory cgroup_memory=1
On reboot, devices configured using DHCP may boot up with a new IP address and the network configuration of a deployed native network becomes invalid. This can be avoided by assigning a static IP to the device you intend to deploy a native network to esp in production systems.