Architecture
This page is intended to provide a comprehensive overview of the architecture underpinning the KubeROS platform.
Fundamentally, KubeROS is built on top of Kubernetes with a dedicated control plane. This control plane is specifically designed to process deployment requests and meticulously schedule them to target locations while taking into accout the nuances of robotic applications and the specifications of the ROS 2 framework.
Overview
KubeROS platform consists of the following components:
- KubeROS control plane
- KubeROS API server: handling API requests and interacting among various system elements.
- Scheduler: responsible for allocating ros2 modules across the entire platform.
- Controller: monitors the system state, making necessary adjustments to maintain the desired state.
- Resource manager: manages the available resources and provides the system state for the scheduler and controller
- Software manager: manages the software running on the platform, ensuring updates, removals are performed correctly.
Infrastructre Abstraction and Communication
KubeROS aims to be a general platform that capable of facilitating the deployment of ROS 2 based robotic applications, across a spectrum of scenarios - from industrial to service robotics. Thus, during the design phase, we have considered many factors, including the security requirements and resource accessability.
To simplify the complex interaction with hardware and improve usability, KubeROS abstracts the underlying infrastructure as follow:
Main Cluster at the Edge:
Edge servers (On-prem) and robot's onboard devices form the main Kubernetes cluster. For prevention of single-point failure, we highly recommend deploying both the Kubernetes and KubeROS control planes redundantly across multiple edge servers. These edge resources can either be bare metal or Virtual Machines (VMs).
Recommandedly, the control plane of Kubernetes and KubeROS are deployed redundantly to multiple edge servers, to prevent the single-failure error. The edge resources can be bare metal or Virtual Machines (VMs).
For use cases that demand extremely high security and lack cloud access, developers can use the KubeROS API server within their local network to deploy, update, and monitor their ROS 2 software across the entire fleet.
This setup is particularly suitable for:
- Autonomous Mobile Robots (AMRs)
- Mobile Manipulator
- Static manipulator performing autonomous task
- Research labs and organizations looking to lower the entry barrier to using ROS 2
Main Cluster Extension through VPN
For use cases where cloud access is available, your main cluster can be extended with VMs from the cloud through VPN tunnels. This method can eliminate the need for vertically scaling up your edge server.
Leveraging the cloud resources provides the flexibility to scale the number of VMs up or down, based on your workload profile and fluctuations in demand.
The establishment of a VPN connection to the public cloud and the provisioning of VMs are typically handled by your faculty's IT administrator, due to security considerations. As a KubeROS administrator, your role is simply to incorporate these resources into your main cluster.
In future developments, KubeROS aims to automate this process using SDKs from public cloud providers. However, setting up a VPN largely depends on your local IT infrastructure and security policies.
This strategy is notably advantageous for:
- Manufacturing sectors
- Logistics sectors
- Public facilities such as hospitals
- Research labs and organizations intending to utilize cloud computing to enhance task performance
Connection to Third-Party Cluster (Multi-Cluster Support)
For use cases where robots can retrieve resources from the third party clusters, we propose to adopt a bridge-based solution to reuse the ROS 2 software modules in the cloud. The ROS 2 modules deployed within third-party clusters can then provide cloud-based software services to the robots.
In practical terms, we implement this by instantiating a gPRC server within the main cluster that subscribes to the ROS 2 messages and encodes them into protocol buffers (Protobuf). Concurrently, a gRPC client is established to receive and republish these messages in ROS 2 on the other side.
[Due to the technical complexities involved in this feature, we plan to introduce it in the second release.]
Discussion and Feedback
Our mission is to build a general platform for the robotics community, aimed at simplifying and accelerating the deployment process of your ROS 2 software.
Considering the wide range of use-cases, each with distinct specifications and requirements, we recognize the value of learning directly from your experiences.
Throughout the development process, we would greatly appreciate any feedback or comments you might have. We're glad to hear your stories and firsthand experiences concerning the deployment of ROS 2 software. This will provide us with crucial insights that can help improve the platform's functionality and user-friendliness.
Additionally, as we explore the potential benefits of incorporating cloud computing into robotics, we're eager to understand your perspective on using cloud computing within your applications.
You are welcome to share your comments anytime in our GitHub repository via the following link: