An aircraft flies in an orderly manner in the air, takes off and lands on time, as if it were the aircraft itself, and in fact, it needs continuous coordination with airports, runways, routes and ground resource systems.
This is precisely what "Tatai" means: it is responsible for coordinating decentralized aircraft and resources on the ground and in the air, so that the aircraft can operate in an orderly manner according to their respective missions. This unified control and coordination becomes increasingly important as aircraft become more numerous and their routes more complex.
It's the same with physical intelligence.
A physical task that is essentially a collaboration of multiple roles: on-premises devices such as robots and cameras, cloud computing, training and reasoning programs, and the communication and operating environments that connect these roles.
As more robots invest in R&D and applications, the complexity and cost of this collaboration will increase: devices need a single access, tasks need to be deployed separately, clouds and on-premises need to configure networks repeatedly, different devices and programs have problems, and devices, networks, and programs need to be checked one by one.
Thus, when robots move from "single" to a larger "group of machines", physically intelligent robots also need a new "tower" that not only "puts the devices in" but manages the distributed computing, equipment, and execution processes of a unified organization so that they work efficiently around the same task.
To solve this problem, Qinghai University and Qinhua University co-developed and open-source cloud native pipeline platform RLark, which focuses on embodied-runtime and mission-level cross-group network connectivity technologies for the operation of embodied devices, opening up two key links: "How real devices are unified" and "How cross-regional tasks are connected".
On the one hand, a unified operating environment for robots, cameras and body-equipped devices enables devices to be applied, timed and replicated like GPUs; on the other hand, task-level isolation of cross-cluster communications for different tasks and network traffic characteristics, and optimization of small packet transmission performance, improving the efficiency of cloud and on-premises synchronization.
Ultimately, RLark can integrate cloud computing, edge nodes, and embedded devices into a unified resource system and run as a complete task unit. It allows access, deployment, and communication configuration completed in an experiment to be replicated in subsequent tasks. Operators can access and unify management devices through a single command line, and researchers can deploy training, reasoning, and real-world interaction programs to different clusters through a single task configuration.
Currently, RLark has completed 3 clusters of unified tubes, covering nearly 100 cloud-side nodes, covering 4 types of embedded devices, which can be started in about 10 seconds after a task is submitted. At the same time, RLark further combines the training framework to open a cross-regional collection, training and authentication loop. It provides the foundation support for larger-scale embedded intelligence experiments with larger devices and more complex collaboration scenarios.
RLark will open up a whole range of capabilities from user interfaces, APIs, back-end services, to task compilation, cross-group connectivity and the running of embedded devices, lowering the use threshold for embedded infrastructure, allowing more teams to directly deploy and use it.
This is not a complete listing.
Project documentation: rlark.readthedocs.io
This is a quick start: github.com/RLinf/RLark#quick-start
From equipment access to real machine training
Cross-geographical testing of physical intelligence
In order to verify whether cloud computing and on-premises equipment can run in sync around the same task, the team combined RLark with the reinforced learning infrastructure framework RLinf to complete a cross-regional real-world test between the Guangdong cloud GPU cluster and the Beijing robot site.
The experiment involved multiple executive roles such as field robots and cameras, cloud GPUs, and training, reasoning, and real-machine interaction.
On-the-spot equipment for interaction and data collection
Cloud GPUs are responsible for training computing, and the trained strategies are used to follow real-machine interactions.
RLark is responsible for device applications, cross-cluster deployments, task instance connectivity and running state compilation.
RLinf is responsible for training computing and data collaboration, which together support the running of experiments.
This experiment focused on verifying not only "can't connect devices", but whether RLark can make a complex experiment that would have required multiple configurations, multi-process collaboration, faster to prepare, easier to run, and form a complete collection, training, and verification loop.
5 minutes to complete the equipment piping:
Unified application of cloud and end-to-end resources
During the experimental preparation phase, the operators first accessed the cloud GPU cluster with the cluster of live devices to RLark, where the clusters of agents synchronized node capacity, resource information, and runtime. Then, through embodied-runtime, they accessed the adapted arm robots and cameras while running the embodied devices, registering the real hardware as the task's applicationable, programmable resources.
In the test environment, the intake of body equipment drops from the traditional 1 hour to 5 minutes. Once the access is complete, the researchers can view the location, type and availability of the two resources on the platform, and continue to apply and reuse them in subsequent experiments without having to re-access the equipment each time.
Start the task in 10 seconds:
One mission configuration, organized in two locations
Once the resources are ready, the researchers declare the required resources, number of instances, and deployment location of each role through a task configuration, defining the roles of training, reasoning, and real-machine interaction. For example, training roles use cloud GPUs and real-machine interaction roles apply to live robots and cameras that belong together to the same mission.
After the task is submitted, RLark will configure and send it to the corresponding cluster, creating execution instances by the Agent, and establishing cross-cluster communication relationships between instances.
In a test environment where the resource has been accessed and has run conditions, the task can be started on the platform side within 10 seconds of submitting the task, without the need for step-by-step log-in devices and deployment procedures respectively.
All the links are running:
Implementation of the collection of aluminum, training of aluminum, authentication of the closed circuit
After the mission is started, the on-site robot continues to generate interactive data with the camera, and the cloud is retransmitted by RLinf for training; post-training updates are then used to follow up real-machine interaction, forming a continuous cycle of collection, training, and verification.
The experiment ran continuously for about 36 minutes and progressed to 323 global steps, running the entire chain of device applications, cross-cluster scheduling, machine data relay, cloud training and strategy updates.
In the process of running, researchers can view the status of each role from the same task input and observe anomalies along the execution of instances, nodes, devices and log locations. Subsequent device replacements, adjustment of role sizes or algorithm parameters can directly modify and reuse task configurations, reducing the work of reconstructing experimental processes.
Through this experiment, RLark organized devices, calculators, and execution programs that were originally distributed in different locations into the same task, validating the ability of cloud computing to synchronize with on-premises devices around the same task, achieving integrated synchronization from resource access, task startup to continuous operation.
Special test for communication optimization:
Cross-regional machine training is more efficient
RLark combines virtual addresses, gVisor user-mode networking and SSH security channels to create communication channels for distributed cloud and on-premises execution instances, unifying the platform's maintaining routing, channel and transfer relationships, and supporting real-time data forwarding and strategy synchronization. On this basis, it further optimizes data flow, reduces unnecessary cross-domain transfers, and synchronizes task-level cross-cluster communication optimization by training the RLinf framework.
To further validate the communication capabilities of this cross-regional mission link, the team conducted special tests for mission-level cross-cluster network connectivity.
In a restricted network environment, RLark's large packet single-stream throughput increased by about 49% compared to the VPN solutions tested, small packet single-stream throughput increased by about 14%; in a high-bandwidth environment, large packet single-stream throughput was close to 2 Gbps.
Higher transmission efficiency provides a more stable communications base for the continuous transmission of models, interactive data, and operational information between the cloud and on-premises. Compared to traditional EasyTier programs, RLark significantly reduces the cartons caused by network transmission during cross-regional real-time mission operations.
RLark Technical Path: Through Equipment Access and Mission Operation
In order for a physical task to function properly, it is not only necessary to access the device, but also how to deploy the task, how to communicate between different clusters, and how to locate problems in the process.
RLark uses a control and data-separated architecture to integrate resources distributed across cloud, edge, and experimental sites into unified management.
RLark's overall technical architecture
The user manages resources and submits tasks through a Web controller, API, or command line tool (CLI); the controller assumes the coordinating responsibilities of the "tower", maintaining the unified resource information, task configuration, and communication relationships; the agent in each cluster is responsible for the deployment of local tasks, resource synchronization and state retransmission.
The "Tatai" is mainly supported by four core technologies:
Self-development and operation of body equipment plugins:
Making robots a resource for managing the timing
RLark integrates cloud computing, edge nodes and hardware such as robots, cameras, and other devices into a unified resource system. Each cluster of Agents continues to control synchronized resource information and operating status, allowing users to view the location, type, and availability of resources from the same input.
For embodied devices, RLark developed embodied-runtime, which, through unified hardware abstraction, transforms real-world devices such as robots, cameras, into recognizable, applicable, and programmable resources in cloud native systems, enabling them to collaborate with computing resources such as GPUs in task compilation.
This process is accomplished in sync with the device plug-in when running: the device plug-in discovers and registers the adapted hardware and provides its resource information to Kubernetes; the clusters of agents to the control side synchronize resource information with the operating state, forming a unified resource view covering cloud computing, edge nodes and on-premises equipment.
Researchers can therefore declare the type and number of GPUs, mechanical arms and cameras used by the platform's unified organization in the same task configuration. Robots are transformed from external devices that need to be connected and configured separately into task resources that can be applied, allocated and replicated together with computing power.
Optimization of cross-cluster communication at task level:
Let's make a real connection between different characters in the same mission
RLark has developed mission-level cross-cluster networking technology that connects execution instances from different clusters in the same mission using virtual addresses and SSH security channels to provide a unified communication channel for cloud training, reasoning and real-world interaction. On this basis, the training framework can further optimize mission deployment and data flow, reducing unnecessary cross-domain transmissions.
First, RLark builds and manages network channels to achieve cross-domain connectivity. Its core is to unite the execution instances of communication addresses with actual deployment locations: the platform allocates virtual addresses as instances, receives traffic through the TUN virtual network interface, is processed by the gVisor user mode network feed, and is then transferred to the other end via SSH security channels.
On this basis, the RLinf framework is based on channels provided by RLark for localized adaptation of traffic. The technology is derived from RLinf's real-world robot strategy learning system USER, which supports continuous data collection and update model strategies during real-machine interaction. In collaboration with RLark, RLinf will organize data processing, reasoning with real-machine interactions on the edge, allowing high-frequency interactions and raw data processing to be close to completion, and then transmitting the data required for cross-cluster path retrain training through RLark's available cross-cluster channels.
See the team's technical paper published in the RSS 2026 column RLinf-USER: A Unified and Extensible System for Real-World Online Policy Learning in Embodied AI column
Declared Task Arrangement:
Let the experiment change from a script spell to a configuration.
RLark uses a three-tiered model of Job, Task, and Worker to describe a physical experiment using a custom task type: Job represents the entire task, Task describes executive roles such as training, reasoning, and real-machine interaction, and Worker is the actual executive instance of those roles.
The user declares the resources, number of instances, and deployment location required by each character through a configuration.
After the task is submitted, the control panel will deploy the configuration and send it to the corresponding cluster, where the Agent creates the Worker and retransmits the status. The platform unifies the Worker in the clusters, by continuous coordination, to align the actual operating state with the task configuration.
Subsequent experiments can be repeated with the same configuration, adjusting the device, role size and deployment location as needed; with phase-dependent processes, workflow can also organize multiple jobs, reducing the maintenance of multiple sets of startup scripts and manually attaching experimental steps.
Mission-level operational observations:
Let the problem be positioned layer by layer along the task link
When missions run abnormally, how do you quickly know where the problem is?
RLark uses the same task mainline to associate Job, Task, Worker with related nodes, devices, events, and logs. Each cluster of Agent relay states is unified on the control panel, allowing the user to view the entire task and execution roles from a single input.
When the task is not progressing as expected, the user can go along the roles of the roles of the roles of the roles of the roles of the roles of the roles of the roles of the roles of the roles of the roles of the roles of the roles of the roles of the roles of the roles of the roles of the roles of the roles of the roles of the roles of the roles of the roles.
The platform provides simultaneous Web Terminal and TensorBoard inputs, supporting further inspection of the operating environment, device access and training processes, reducing multi-machine logging, cross-system searches and verification of abnormal information.
Together, we build a new "Tara" that is physically intelligent and sustainable.
Intelligent hardware and operating environments are still changing rapidly.
New robots, cameras and sensors are continuing to gain access; network conditions in different locations need to be verified one by one; and more new engineering problems will arise as the scale of the experiment expands, including scheduling, communication and abnormal recovery.
This means that having physical intelligence requires not just a tool that can "bring devices in", but a set of infrastructures that can be continuously expanded, reused and evolved together.
RLark opted for open source, with the goal of converting the infrastructure experience of device adaptation, task configuration, and real-world experiments into replicable capabilities. Administrators can manage clusters, nodes, device information, and infrastructure components through the platform; R&D personnel can configure collection, training, and evaluation tasks through the Web Console, and execute workflow, communication domains, storage, logs, and remote terminal management processes. RLark also provides APIs for access to existing algorithm frameworks and R&D tool chains.
Subsequently, RLark will continue to improve device and chip adaptation, light operating time, cross-domain communication, task abnormalities recovery and experimental configuration replication.
We welcome robot and chip manufacturers to participate in device adaptation, we welcome algorithm teams to share data collection, training and verification scenarios, and we welcome infrastructure developers to participate in task planning, networking and operational observation capacity building.
We also look forward to working with the open-source community to build this new "tower" that supports the move to a larger, more complex landscape.
The project address is github.com/RLinf/RLark
Welcome to Star, deploy trials, submit issues or participate in contributions.