A Unified Management and Control Plane for Cloud Native Robots Wi... Sitong Mao, Huan Wei & Yin Ding

In this talk, Wei Wan and Ding Ying discuss the integration of KubeEdge for unified management and control of cloud-native robotics. The speaker outlines the shift in robotics from isolated control systems to multi-robot collaboration and AI enhancements, necessitating a platform that can manage real-time operations at the edge while maintaining cloud-scale governance. They explain how KubeEdge facilitates this by providing edge autonomy for real-time tasks while leveraging a Kubernetes ecosystem for resource management, development efficiency, and lightweight infrastructure. The presentation highlights specific features of KubeEdge, such as edge autonomy, task orchestration, and cloud-edge collaboration capabilities, and concludes with a live demo showcasing robots performing tasks based on natural language processing inputs.

Okay, good afternoon everyone. Welcome to our talk at the KubeCon Cloud Native Con Europe 2026. My name is Wei Wan and I'm a KubeEdge TSC member. I'm joined by my co-speaker Ding Ying, also a KubeEdge Today, we are going to present a unified management and a control plane for cloud native robots with KubeEdge. Our first Um we are very excited on the keynote again. It's It's the

uh presentation on the uh KubeCon uh first day. Um uh let's start with the the backgrounds. Uh Uh we all know the field of of robotics is moving from the uh the the isolated control system to multi-robot collaboration, remote operation, continuous continuous upgrades, and AI enhancements. That requires a new platform which can handle both the satellite real-time behavior and the cloud scale government. Uh so how how

KubeEdge fits fits into this this uh this requirement? KubeEdge can give the robotic systems edge edge autonomy for the real-time operation and the cloud native engineering. discipline for the uh scalable for this for this for this sca- scalable delivery. And Um and uh the Uh KubeEdge KubeEdge is is is is uniquely positioned to bridge the this gap. It uh provides the robotic system um with the edge

edge edge autonomy for the uh critical real-time operation while bridging the cloud-native For the uh scalable, reliable reliable systems, and and this this convergence uh delivers many concrete benefits. The first is uh smarter robots. And the the cloud can can cons- can centralize the resources like the AI models, global maps, knowledge bases, and policies. Then the the edge will handle the the local sensing, real-time inference, and

the immediate control. This turns robots into the into the collaborative cloud-native cloud edge intelligent agents moving beyond the isolated automation units. And the second is the uh it brings more more economical. And the uh the development team can reuse the rich ecosystem built around the Kubernetes. Uh that means the the logging, monitoring, and the multi-site operation. There's no need for the uh development team to build the

separate platforms for every new robot types of uh projects. And furthermore, the computer the the the compute workloads can dynamically shift between the cloud and edge based on demands. And also, it uh brings more more uh lightweight solution. Uh KubeEdge fundamentally will reuse the Kubernetes APIs and the control plane patterns. So, we can see all the all the things including the the edge applications, edge devices, they

are all in one one cluster. So, this this will dramatically reduces the over head of the reinventing the core core infrastructure for the scheduling, configuration management, and the loading updates, etc. uh final benefit is the more it it brings the faster development iteration. Uh you know from the coding to the uh simulating to the testing deployment uh for the robots, we have the over-the-air uh updates. All

these all these uh flow uh the may be the the entire development life cycle can follow a unified cloud native workflow like the CI/CD. So, this will make the the practices like the version release, canary rollouts, low outs, and low backs standard and the repeatable. And uh for those who are uh less familiar with KubeEdge, let me briefly introduce the uh KubeEdge project. KubeEdge is the first

open source project designed specifically for the edge computing scenarios with cloud native principles. It is a built for edge cloud collaboration. Its core mission is to deliver a consistent development and the uh life cycle for the um applications and resources, data, and the devices across the cloud and edge. It's openly governed and is a key Now, it's a key project connecting the cloud native and edge computing

ecosystems. Now, it has a vibrant community with 8,400 GitHub stars, 2,400 forks, and contributions from about 1,600 developers across more than 100 organizations. Uh so, uh this is a high-level view of the extends the Kubernetes control plane to the edge. The cloud core component runs in the cloud, while the edge core component runs on on each edge node. So, this design allows allows users to manage pods

at the edge using the uh the familiar Kubernetes APIs. I I I just said before, all these other stuff will be in just one one cluster. So, it's very different from the uh the K3s or K3OS. So, in in this way, uh the KubeEdge will will provide the mechanisms for the reliable offline operations and uh uh efficient data transmission. Uh KubeEdge has a very important feature we

call this edge edge edge autonomy. In detail, cloud core will will process the list of watch from the API server. And then, the cloud core will will get the uh the local the will get the the the latest list of watch information of the local nodes and the store it in the uh local database. You can see we have a very lightweight database. And so in so

in this way, even if the the the network between the edge and cloud is blocked, all the stuff in the edge can run very very smoothly. So, this is a very important important for the edge computer edge computing scenarios. As we know, in the in the original Kubernetes design, if the network between the workload and the control plane is is is disconnected, then the pods on the

on the workload will will be drained to the another node. But, in the edge computing scenarios, this this is not not allowed. And also, KubeEdge has a very important uh cloud-edge collaboration. That means in the cloud, it can manage all the um both in the cloud and in the edge. And And besides besides this, we also we uh capability to manage all the edge edge uh devices.

You can implement the mapper framework to uh to to write write programs to um to connect different um devices like the Modbus, Bluetooth, etc. And um And I'm building on building upon this foundation, we propose we propose a uh design based on KubeEdge. uh this design layers is the cloud native abstraction on top of the robotics systems. the cloud plane will handle the high-level orchestration, task management,

and the global state. While the edge plane, managed by the KubeEdge, is where the robot's nodes reside. So, these nodes run on the run the the actual robot applications and can leverage the local message buses like the ROS. This design provides a unified control plane for both the cloud scale management and the edge level operation. And we can see we have Here we have two channels. One

channel on the right is the is the meta meta meta data channel provided by by KubeEdge and and and uh Kubernetes. And on the on the on the left we have the DDS channel. That's That's for the uh for the business data uh between the cloud and the the and the each lo- each robot's node. Um okay, uh that concludes the first part of of our talk

talk covering the motivation, architecture, and the code designs. I will now hand over to my partner Ding uh he will dive into the intelligence monitoring, task planning, and the specific technical implementations. Yeah, thank you. Thank you, Huang. So, um hopefully that will be uh big exciting part. So, this part is have a real example say how we implement a robot controlled by the cloud. So, I think

for you guys are very familiar with uh Kubernetes is not uh strange it's very familiar. So, basically uh in the bottom left you can see we have uh defined the three part of a CRDs. So, it's exact concept. So, the robot CRD we define the robot status, capacity capacities for the task describe the task. So, basically from point A to point B or could be divided by

to the subtask to A, B, C or uh we can show uh to the end I will show a live demo. And the other one is a robot sync CRD. So, basically uh defined through the cloud cloud the side synchronization and the registration informations. Basically, uh there will be uh you can divide develop a three type of operators. Basically, uh three controllers. Task controller, basically, uh you

watch the task resource defined in the cloud, then you select the correct node and according to the correct robot, then you assign the task to the robot. And then up later updated the the robot resource and the task resource. And the robot controller basically watch the change of the robot status based on the collected data from the client side. And then or you can send command to

your client side to control the robot. And the third one controller is called registration controller. Basically, it is the controller you uh control the new robot registration because in the Kubernetes concept as every edge node is drawing cluster, then how we control this one? Basically, you listen to the registration message and you control the heartbeat uh to monitor the status of your robot the status. After a

registration successful registration also the handshake information all this stuff details. Then after successful registration we create the robot resource. They maintain the through the robot sync control And you can see in the real example on the left side is the ROS the robot OS that's the uh a real robot. You can see there's a a bunch of a sensors attached to it camera distance sensor lidar and

also of course a small control unit there and the bottom left is the simulator. So uh the this robot we build based on the ROS the robot OS. So that OS can collect the data or all the sensor uh aggregated on the robot then pass through to the cloud process. in the cloud side this should be very familiar. We use a Prometheus to to do the data

monitoring. Basically we gather the metric the data metrics from and the store in the Prometheus time series database then we can uh use the rule based alerts. You can see you can send alert or you can monitoring and we use a graph now to have a I mean GUI the graphic UI you can watch for all the metrics and you can see the trend and also you

can set up the alert. And another part we are doing basically how we generate the action sequence for the robot. So, for this one, we integrate with the NLP, the natural language uh NLP, the uh natural language process to understand the natural language and to uh using LM to to plan the task. Uh basically uh you can see uh on the client, the raw ROS node. We

send the user request uh you can see in the graph. The the actual robot node is the edge node, and that's a ROS data robot itself. Um so, in the robot, they have the uh con- robot controller basically uh you define the robot cap- uh capabilities as defined by the developer. And the agent is the core orchestrator to understand the request and then gather the task sequence

reason and update the the actual action plan. And the the observer the robot observer through the sensors collect data and make the next step decision and do the execution. And uh so, you can see the the big picture is in the cloud side, we have a uh power uh more computer power. So, it can handle most of the computation basically uh planning uh the global and also

store the global map. So, you would do do the global optimization. And also, you store all the a of frames and the story in the cloud side because on the client side you have only limited resource. And on the edge side, basically you we perform the initial pre-processing data and you cut the this to cut the key frame and then also you do the pulse tracking. Get

data from the robot to the pulse tracking and also you the the node receive the synchronization data from the cloud and you can get a updated local map. So basically cloud side you have the global map in the edge node you only have a subset um a low density the global map but it's more detailed um your recent local map. So that's about the work but let

me show a demo. It's more interesting to show how this work together and get it working. So basically you can see the demo will be um that will play a little bit after I explain what's going on. So the demo is we have a three robots in this graph um ABC and or you can see the red, green or blue and we try use NLP to define

the task. Basically um I really explain when the live video playing. Basically I say for robot A please transport goods one to point. the second robot robot B you need to transfer the goods number two to a different location and the robot C you transfer another one. And so the challenge is uh, how you can let the robot to understand that this is natural language and so

this one is only happen in the cloud side. So, you have enough power to compute and deploy your NLP, uh, AI model to understand your, uh, you can do the natural language in, uh, natural language processing to understand it. And that's based on the your LLM, the large language model. And then you transfer, uh, the prediction, the control task to And also another challenge we were, uh,

trying to resolve, to resolve is, and the when you scale up, when you have more and more robots, there's some, if you don't have a global view, you don't have a global, uh, planning, it may cause congestions, very the, uh, collisions or accidents. So, uh, that's we are using the cloud side to have a global, uh, view and make a global decisions. And also, uh, the in

the real world, a lot of robots is deployed on the warehouse. Your cloud, your cloud is in the data center. So, uh, how do you control your data accessing and to send the your request to the remote, uh, data warehouse and also, uh, how you synchronize the data, that's all controlled by the, uh, KubeEdge. So, that one we have a even the transfer channel is not reliable,

you can have, internet broken between the warehouse and your cloud. When they restored, we can re, uh, we can assure the desired state will synchronize to the edge side, then you can have your task assigned to the warehouse after the tender connection restored. So, you can see the benefit. You have NLP understanding and E2E deployment and um So, in the real world the feedback saying um the

management efficiency improved about 1 25% and also the you add a new type of a robot is from months the process to only days. Let me show the video. So, oh, it's so fast. Before I clean. So, basically uh Okay, drag. So, basically on the dialogue in dialogue box you can see uh the whole process. You could you reset? Okay. So, basically in the dialogue you can

the initial message will be uh the three robots register say I'm a robot green and robot red and we have a controller say, "Okay, I'm the controller." And then uh we will type say robot one, please transfer one to port A, the other one to I don't know if you can read, but uh message saying to port B. So, then uh based on the cloud, we understand

this language, and we uh say, "Oh, you I understand what's your task will the the goal is transfer uh uh two goods, one uh panda from port A, another one to port B, and then we have a three robots available. So, in the cloud side, we plan how the task will be. Say, "Okay, we assign task to uh robot one, two, three. They have a different task."

for the execution. So, this is a planning. So, we can you can see we decide, "Okay, we assign a task to uh different robot." Uh robot one, two, three, they have a different task. And then the execution happened. This is the simulation. Uh we run this on a simulator. This is actual video. This is the robot's the camera video. You can uh So, this is the global

view to see the before you see a uh actual camera video supposed to what the robot see. This is the simulator to show the actual task how executed. We have a three robot, red, green, and blue. They are picking up the different different the goods and deliver to a different place. This is simulate a uh It's a simplified version is actually what's happening in the warehouse, how

you can use the robot to efficiently to put uh the the So actual the real It's fine. That's all that the real uh uh scenario will be in a warehouse. You have a so many robots, you have a lot of a goods to deliver, you have a different address put into a different shelf or to the different vehicle. So this is simplified version. So uh a dispatcher

just reads a what this one goes to is either real people or it is just a robot say a scanner say what find this package on the truck one on the truck two. So that's the simulation is actually is simplified a simplified version. It's the happening in the real warehouse. Cool. Uh we have about Yeah, thank you. Uh this with the demo we conclude our talk today

and that's our GitHub. You can see we have not only a robot sig, we have a security sig and the node sig. There's a lot of a interesting topic. If you are interested, please come to our GitHub to see the actual commit and you can contribute. Uh we are always welcome the contributions contributors. And then we have a Slack channel. You can go and also you can

go to CNCF Slack. We have a courage channel. That's our official channel. You can ask questions or collaborated collaborations. And yeah, thank you. Uh We have about Yeah, also I will have about 3 minutes Q&A. Yeah, thank you. Yeah, if you have questions. Thank you for the presentations. I have a question regarding the number that you mentioned like at you mentioned at 24% increase in efficiency and

30% reduction in the in to which method do you compare this number? Thank you. >> you mean the the number is our customer reply say uh when you deploy a new kind of a robot in the warehouse, so you should be take months to understand to do and then into the system. Now this just days. They just have a new one then register to Register to the

to the cloud. Yeah, register to the database and then we actually the fleet we all called. >> It's be a one of the robot in the fleet and you can join and then because your warehouse maybe you used to have 100 shelf, but then you have 150 shelf, you need a more robot. So it's a very quickly to onboard a new robot, I mean >> to into

your fleet to do the work. >> like because you mentioned then 25% efficiency like before before Q edge what's a method this is it is used? The the one is because you can utilize your cloud. You have a global map, so you can see how you transfer, you can find a short because each robot only have a local view, but that one have a global view. We

can more efficiently dispatch the robot to pick up the goods and define and then you can use non-useful stay in the station. You don't for charging or and also this no congestions because you have a global view, you have a smart but it also depend on your algorithm. You need have a smart routing algorithm to make sure it's more it's easy to achieve because you have a

global view and then you have an unlimited power computer resource. It needs technically in the cloud compared to the small robot. Thank you. you also showed that you have the ROS nodes and everything which are also on the robot. Are those ROS nodes also then orchestrated by the edge node? Is this all done also on the edge side on inside or is this completely separate? You mean

this one, right? Yeah, exactly. >> The orchestrator orchestrate that you this orchestration happen is this local is not there's a two different orchestration is a are you orchestrate resource from the cloud? This is the only uh Which one you talking about agent or Everything which is in the ROS ecosystem basically. Are you also orchestrating for the ROS deployment for everything which you actually run? Uh you mean

uh that robot node is actually all right. >> server for example. >> Yeah, that that's is happening with push from the cloud to the robot node. Robot node push into the actual ROS. So that orchestration is only So which orchestrator you are talking about? This >> observer is not part of uh kube edge. I mean No, no, it's not part of >> It's not uh orchestrated by

kube edge. No, no, it's not containerized. It's in the ROS. It it's not containerized. It is could be containerized. Is uh we push it it depend on what uh It is containerized, right? Um yeah, we have we have the uh uh the robot CID and the robot will will running as as a pod. Mhm. Yeah, to represent um a real ROS. Mhm. Okay. Yeah. Thank you. This

this a >> part of this. Yeah, yeah. It's a container. Hi. I have one small question about the communication, let's say between the cloud and the edge. Communication? Yeah. One slide over. This one? No, a bit more, but anyways, you were showing somewhere that you are doing the communication between the edge and the cloud using something like 4G or Wi-Fi. I Is this like flexible in regards

to the protocol that you use because a lot of the times Wi-Fi might be too like power hungry for use cases with robots, so Uh so you you can see we have a local database at the edge in in the edge core. And this this this database uh SQLite. It's very very lightweight and it will store the metadata um from the the the control plane. Yeah. Yeah,

you said the communication part You said 5G or 4G is not our choice because some place they don't have an internet connection. So we have the real customer, they have a uh mine vehicle, they put the our node over there. They are on a remote uh mine. They don't have a carriage They only have a self self cellular carriage. They have to use the uh cellular network

to connect back. They don't have a line or local Wi-Fi or All right. Thank you. Thank you.