Cross-platform robot operating system and method, robot and medium

Abstract

The invention relates to the technical field of robots, and discloses a cross-platform robot operating system and method, a robot and a medium, the system comprises an operating system layer, a function library layer and a distributed node layer; the operating system layer is configured to provide an application programming interface for accessing system resources for the function library layer based on preset operating systems, and abstracts differences among different preset operating systems through the application programming interface; the function library layer is configured to access system resources through an application programming interface and realize distributed communication based on a data distribution service protocol; the distributed node layer is used for realizing development and operation of application nodes, and the application nodes are mutually identified in a network based on distributed communication and establish communication channels; and the distributed node layer performs data interaction with an external robot operating system through distributed communication. The problem that in the prior art, a robot operating system is poor in compatibility and adaptability is solved.

Description

Background Art

[0002] The existing robot operating systems mainly include ROS1 (Robot Operating System 1) and ROS2 (Robot Operating System 2). Among them, although the programming interface of ROS1 is simple and easy to use, it is not efficient enough when dealing with complex distributed real-time systems and cannot meet the needs of modern robot systems for high-efficiency and low-latency communication; although ROS2 has higher communication efficiency, its programming interface is more complicated.

[0003] Due to the compatibility issues between ROS1 and ROS2 on different operating systems, the related technology usually builds a robot operating system based on one of ROS1 or ROS2. For example, a Chinese patent application with publication number CN117349047A discloses a robot software architecture, including: an Android system and a ROS2 system. The Android system is used to handle user interaction, and the ROS2 system is responsible for robot control functions. The two are isolated and run through virtual machines, and the communication between the Android system and the ROS2 system relies on shared memory and the DDS protocol.

[0004] However, in the above solution, it is necessary to rely on virtual machines to isolate the operating environments of the Android system and the ROS2 system. Although the virtual machine provides a certain degree of system separation and isolation, it also introduces an additional architecture layer, which increases additional requirements for the underlying hardware, resulting in poor compatibility of the software architecture on different operating systems. In addition, the software architecture is mainly based on the DDS protocol of ROS2 for distributed communication. For operating systems using ROS1, it is impossible to communicate directly through this architecture, and additional conversion or reconstruction operations must be performed, which has poor adaptability.

[0005] In summary, the current existing technologies have the problem of poor compatibility and adaptability of robot operating systems. Summary of the invention

[0006] The present application provides a cross-platform robot operating system, a cross-platform robot operating method, a robot and a computer-readable storage medium, aiming to solve the problems of poor compatibility and adaptability of robot operating systems in the prior art and to achieve cross-platform interaction of the robot operating system.

[0007] Additional aspects and advantages of the disclosure will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be learned by practice of the disclosure.

[0008] According to the first aspect of the present disclosure, a cross-platform robot operating system is provided, which includes: an operating system layer, a function library layer and a distributed node layer; wherein: the operating system layer is used to interact with a preset operating system where the robot hardware is located, and the operating system layer is configured to provide the function library layer with an application programming interface for accessing system resources based on the preset operating system, and abstract the differences between different preset operating systems through the application programming interface; the function library layer runs on the operating system layer, and is used to realize distributed communication of the robot, and the function library layer is configured to access system resources through the application programming interface, and realize distributed communication based on a data distribution service protocol; the distributed node layer is used to realize the development and operation of application nodes, and each of the application nodes recognizes each other in the network based on the distributed communication and establishes a communication channel; the distributed node layer interacts with an external robot operating system for data through the distributed communication.

[0009] In an exemplary embodiment of the present disclosure, based on the aforementioned solution, the distributed node layer further includes a bridging module, which is used to perform data interaction with nodes in the ROS1 operating system and / or the ROS2 operating system based on the distributed communication.

[0010] In an exemplary embodiment of the present disclosure, based on the aforementioned scheme, the bridging module also includes a node discovery unit, a protocol adaptation unit and a format conversion unit, wherein the node discovery unit is used to discover and synchronize nodes in the ROS1 operating system and / or the ROS2 operating system; the protocol adaptation unit is used to perform communication protocol conversion on the ROS1 operating system and / or the ROS2 operating system; and the format conversion unit is used to convert the message format between the cross-platform robot operating system and the ROS1 operating system and / or the ROS2 operating system.

[0011] In an exemplary embodiment of the present disclosure, based on the above scheme, the operating system layer includes a hardware abstraction module, a resource management module, a system call interface module, a device driver management module, a network management module and an operating system adaptation module. The hardware abstraction module is used to abstract and shield the underlying hardware details and provide a unified hardware interface for the function library layer; the resource management module is used to manage the allocation and scheduling of system resources to ensure that the function library layer can access and use the system resources; the system call interface module is used to provide a standardized system call interface, allowing the function library layer to access the underlying functions of the operating system through the application programming interface; the device driver management module is used to manage the driver of the robot hardware device and provide a peripheral access interface; the network management module is used to manage network connections and communication resources to support the needs of distributed communication; the operating system adaptation module is used to adapt to different preset operating systems and abstract the differences between different preset operating systems.

[0012] In an exemplary embodiment of the present disclosure, based on the aforementioned solution, the function library layer also includes a resource allocation module, which is used to dynamically allocate and adjust the CPU core binding of each of the application nodes through the environment variables and real-time system calls provided by the operating system layer.

[0013] In an exemplary embodiment of the present disclosure, based on the aforementioned scheme, the resource allocation module includes a demand detection unit, a core binding unit, a dynamic adjustment unit and an adaptive scheduling unit; wherein the demand detection unit is used to determine the demand information and priority information of the application node through the environment variables provided by the operating system layer, and the core binding unit is used to allocate the CPU core binding to the corresponding application node according to the demand information and priority information; the dynamic adjustment unit is used to monitor the CPU resource occupancy of each of the application nodes in real time through the performance monitoring interface of the operating system layer, and in response to resource overload, trigger the dynamic adjustment mechanism to optimize the CPU core binding; the adaptive scheduling unit is used to monitor the operation status of each of the application nodes in real time, and in response to node overload, automatically allocate the application node to an available idle CPU core.

[0014] In an exemplary embodiment of the present disclosure, based on the aforementioned scheme, the functional library layer also includes a synchronization module, which is used to automatically align messages from different sensors according to timestamps based on an approximate time synchronization algorithm when receiving a sensor data stream, and perform data processing and fusion with minimal delay.

[0015] In an exemplary embodiment of the present disclosure, based on the above-mentioned solution, the method of automatically aligning messages from different sensors according to timestamps based on an approximate time synchronization algorithm includes:

[0016] according to:

[0017]

[0018] Automatically align messages from the different sensors; wherein T sync (t) represents the calculated time synchronization point, N represents the number of sensors, T i (t) represents the timestamp of sensor i at time t, Δt i represents the time deviation of sensor i at time t, d i (t) represents the data delay of sensor i at time t, f i (t) represents the sampling frequency of sensor i, θ i (t) represents the clock offset of sensor i, θ ref (t) represents the value of the reference clock at time t, ω i (t) represents the rate of change of the clock offset of sensor i over time, Δ net (t) represents the jitter effect caused by network transmission.

[0019] In an exemplary embodiment of the present disclosure, based on the aforementioned scheme, the function library layer also includes: a policy configuration module, which is used to monitor the network status and node load in real time, and dynamically configure the service quality policy of the data distribution service protocol through the application programming interface provided by the operating system layer.

[0020] In an exemplary embodiment of the present disclosure, based on the aforementioned solution, the preset operating system is any one of a Linux operating system, a Windows operating system, a Unix operating system, and a macOS operating system.

[0021] In an exemplary embodiment of the present disclosure, based on the above-mentioned solution, the function library layer further includes a component module, which is used to provide basic function support, and the component module accesses the system resources through the application programming interface.

[0022] In an exemplary embodiment of the present disclosure, based on the aforementioned scheme, the component modules include: a coordinate transformation unit, a log unit, a parameter unit and a diagnostic unit; wherein the coordinate transformation unit is used to convert sensor data between different coordinate systems; the log unit is used to record the operating status and error information of the operating system in real time; the parameter unit is used to parse and manage parameters from instruction information; the diagnostic unit is used to monitor the operating status of the operating system in real time, generate a health report and issue a warning when the system is abnormal.

[0023] In an exemplary embodiment of the present disclosure, based on the above solution, the conversion of sensor data between different coordinate systems includes: according to homogeneous coordinate transformation:

[0024] P r =Rrs P s +T rs

[0025] Change the sensor data to the reference coordinate system; where P r represents the homogeneous coordinate representation of the sensor data in the reference coordinate system, P s represents the homogeneous coordinate representation of sensor data in the sensor coordinate system, T rs represents the translation vector from the sensor coordinate system to the reference coordinate system, R rs Represents the rotation matrix from the sensor coordinate system to the reference coordinate system.

[0026] In an exemplary embodiment of the present disclosure, based on the aforementioned scheme, the distributed node layer includes a topic management module and a visualization module; wherein the topic management module is used to provide topic publishing, subscription, management and monitoring functions; the visualization module is used to display visualization data and system status through a visualization interface.

[0027] In an exemplary embodiment of the present disclosure, based on the aforementioned solution, the function library layer also includes a development language module, which is used to provide an interface for development through a programming language, and the programming language includes one or more of C++, Java, Python, Go and JavaScript.

[0028] In an exemplary embodiment of the present disclosure, based on the above-mentioned solution, the distributed node layer further includes an agent module, which is used to provide support for multiple programming languages ​​so that each application node can interact using different programming languages.

[0029] According to a second aspect of the present disclosure, a robot is provided, configured with a cross-platform robot operating system as described in any of the above embodiments, the robot including any one of a legged robot, a quadrupedal robot, a bipedal robot, a wheeled robot, a wheel-legged robot, a quadrupedal robot, a humanoid robot, a cleaning robot, a transport robot, a mobile robot and a robotic arm.

[0030] According to a third aspect of the present disclosure, a cross-platform robot operation method is provided, which is applied to a cross-platform robot operating system as described in any of the above embodiments, and the method includes: providing an application programming interface for accessing system resources based on a preset operating system, and abstracting the differences between different preset operating systems through the application programming interface; accessing system resources through the application programming interface, and realizing distributed communication based on a data distribution service protocol; based on the distributed communication, mutually identifying and establishing a communication channel in the network; wherein the distributed node layer interacts with an external robot operating system through the distributed communication.

[0031] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided, on which computer program code instructions are stored. When the computer program code instructions are called by a processor of a robot, the robot executes the cross-platform robot operation method as described in the above embodiments.

[0032] It can be seen from the above technical solution that the present disclosure has at least one of the following advantages and positive effects:

[0033] The cross-platform robot operating system disclosed in the present invention includes an operating system layer, a function library layer, and a distributed node layer. On the one hand, the operating system layer provides an application programming interface that abstracts the differences between different operating systems, shielding the differences between different operating systems, so that the function library layer and the distributed node layer do not need to care about the specific implementation of the underlying preset operating system, thereby realizing the operation of the system in multiple operating system environments, significantly improving the compatibility of the robot operating system; on the other hand, the distributed node layer, through distributed communication, not only enables each application node to recognize each other and establish a communication channel in the network, but also enables data interaction with the external robot operating system, improving the adaptability of the robot operating system; on the other hand, the function library layer implements distributed communication in the robot operating system based on the data distribution service protocol, meeting the efficiency and real-time requirements of the robot operating system in multi-node collaboration. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0035] Figure 1 This is a structural block diagram of a cross-platform robot operating system in one embodiment of the present disclosure;

[0036] Figure 2 This is a block diagram of the operating system layer structure in one embodiment of the present disclosure;

[0037] Figure 3 This is a structural block diagram of a function library layer in an embodiment of the present disclosure;

[0038] Figure 4 A structural block diagram of a resource allocation module in an embodiment of the present disclosure;

[0039] Figure 5 A structural block diagram of a component module in an embodiment of the present disclosure;

[0040] Figure 6A structural block diagram of a distributed node layer in an embodiment of the present disclosure;

[0041] Figure 7 A structural block diagram of a bridge module in an embodiment of the present disclosure;

[0042] Figure 8 This is a structural block diagram of another cross-platform robot operating system in one embodiment of the present disclosure;

[0043] Fig. 9 is a schematic diagram of a robot according to an embodiment of the present disclosure;

[0044] Fig.10 is a schematic diagram of a robot according to another embodiment of the present disclosure;

[0045] Fig.11 is a schematic diagram of a robot according to yet another embodiment of the present disclosure;

[0046] Fig.12 It is a flowchart of a cross-platform robot operation method in one embodiment of the present disclosure;

[0047] Fig.13 A schematic diagram schematically shows a structure of a computer system of an electronic device according to some embodiments of the present disclosure;

[0048] Fig.14 is a schematic diagram of a computer-readable storage medium according to some embodiments of the present disclosure.

[0049] In the drawings, the same or corresponding reference numerals represent the same or corresponding parts. DETAILED DESCRIPTION

[0050] The specific implementation methods of the present application are further described in detail below in conjunction with the accompanying drawings and examples. The following examples are used to illustrate the present application, but are not intended to limit the scope of the present application. Similarly, the following examples are only some embodiments of the present application rather than all embodiments, and all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of this application.

[0051] In the description of the present invention, terms such as "center", "longitudinal", "lateral", "length", "width", "thickness", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "clockwise", "counterclockwise", "axial", "radial", etc. indicating directions or positional relationships are based on the drawings and are only for the convenience of description and simplified description. They do not mean that the device or element must have a specific direction, be constructed and operated in a specific direction, and cannot be regarded as a limitation of the present invention.

[0052] The terms "first" and "second" are used for description only and do not indicate relative importance or imply the number of technical features. Therefore, the "first" and "second" features may explicitly or implicitly include at least one of the features. The meaning of "plurality" is at least two, unless otherwise explicitly defined.

[0053] Unless otherwise specified, the terms "installed", "connected", "connected", "fixed", etc. should be understood in a broad sense, and may be fixedly connected, detachably connected, or integrated; may be mechanically connected, electrically connected, or able to communicate with each other; may be directly connected or indirectly connected through an intermediate medium, and may be the internal connectivity of two elements or the interaction relationship between two elements.

[0054] In the present invention, when a first feature is “above” or “below” a second feature, it may be that the first and second features are in direct contact, or the first and second features are in indirect contact through an intermediate medium. Moreover, when a first feature is “above”, “above” or “above” a second feature, it may be that the first feature is directly above or obliquely above the second feature, or it may simply mean that the first feature is higher in level than the second feature. When a first feature is “below”, “below” or “below” a second feature, it may be that the first feature is directly below or obliquely below the second feature, or it may simply mean that the first feature is lower in level than the second feature.

[0055] In an exemplary embodiment of the present disclosure, firstly a cross-platform robot operating system is provided. Figure 1 The structure block diagram of a cross-platform robot operating system in one embodiment of the present disclosure is schematically shown. Figure 1 As shown, the cross-platform robot operating system 100 includes an operating system layer 1, a function library layer 2, and a distributed node layer 3. Among them, the operating system layer 1 is used to interact with the preset operating system where the robot hardware is located. The operating system layer is configured to provide the function library layer with an application programming interface for accessing system resources based on the preset operating system, and the differences between different preset operating systems are abstracted through the application programming interface; the function library layer 2 runs on the operating system layer and is used to realize distributed communication within the robot system. The function library layer is configured to access system resources through the application programming interface and realize distributed communication based on the data distribution service protocol; the distributed node layer 3 is used to realize the development and operation of application nodes in the robot, and each application node recognizes each other in the network based on distributed communication and establishes a communication channel; the distributed node layer interacts with the external robot operating system through distributed communication.

[0056] Below, the functional principles of the operating system layer, function library layer and distributed node layer in the cross-platform robot operating system are explained in detail.

[0057] Among them, the operating system layer can represent the basic layer of the cross-platform robot operating system, which is used to interact with the preset operating system that carries the robot hardware. Exemplarily, the preset operating system is the Linux operating system, Windows operating system, Unix operating system, macOS operating system and other operating systems suitable for robots. The operating system layer provides access to system resources for the upper function library layer by providing a unified application programming interface (Application Programming Interface, API). System resources may include processor resources, memory, network resources, image processing units, I / O devices and other resources. The operating system layer can shield the differences between different operating systems through the API, so that the function library layer can directly access system resources without paying attention to the implementation details of the specific operating system.

[0058] In actual operation, when the function library layer or application node needs to access system resources, it will send a request to the operating system layer through the API; after receiving the request, the operating system layer converts it into the corresponding system call according to the specific implementation of the preset operating system, and requests the underlying operating system to perform the corresponding operation; after the underlying operating system processes the request, the operating system layer returns the execution result to the upper layer through the API. In addition, since different operating systems have different architectures, system call methods, and resource management mechanisms, the operating system layer can abstract these differences through the API, unify the underlying details of different operating systems into standardized interfaces, so that the function library layer and the application node layer do not need to make additional modifications when executing on different operating systems, thereby achieving cross-platform compatibility. In actual operation, the operating system layer first identifies the operating environment, such as the Linux operating system, Windows operating system, etc., and loads the corresponding underlying interface.

[0059] The function library layer runs on top of the operating system layer and can be used to implement distributed communication within the robot system. It can access system resources through the API provided by the operating system layer and implement distributed communication based on the Data Distribution Service (DDS) protocol, providing basic support for distributed communication for upper-level application nodes, ensuring efficient and reliable data exchange between different nodes. Among them, the DDS protocol is a communication middleware standard for real-time distributed systems, providing data distribution services in a publish / subscribe mode. Through a flexible quality service mechanism, it allows dynamic adjustment of communication strategies according to the requirements of different tasks to meet the real-time and reliability requirements of distributed systems.

[0060] Specifically, as the middle layer in the cross-platform robot operating system, the function library layer obtains access rights to system resources through the API provided by the operating system layer to support the operation of distributed communication and node management. In addition, the function library layer can be used to enable each application node in the robot system to achieve distributed communication. It establishes a distributed communication channel based on the data distribution service protocol to ensure that the nodes can exchange information efficiently and reliably. In actual operation, each application node publishes or subscribes to a specific topic through the DDS protocol with the support of the function library layer; the function library layer identifies other nodes in the network through the automatic discovery mechanism and establishes a communication connection; when a node publishes a message, the function library layer will ensure reliable transmission of the message according to the pre-set quality of service (QoS) parameters, and transmit the data to the node subscribed to the topic within the set delay time. Secondly, the function library layer ensures that the communication between nodes meets the specific real-time and reliability requirements through the QoS mechanism of the DDS protocol. The QoS parameters can be adjusted according to the needs of the application scenario, such as improving the reliability of communication or reducing transmission delays to meet different task requirements.

[0061] The distributed node layer can represent the direct level used to develop and run robot application nodes and realize the physical functions of the robot. Each application node recognizes each other in the network through the distributed communication mechanism of the function library layer, and establishes a communication channel to ensure that each node can work together. The distributed node layer not only supports communication between nodes within the robot, but also exchanges data with the external robot operating system through the DDS protocol to achieve collaboration between cross-platform robot operating systems.

[0062] Specifically, the distributed node layer can be used to implement the development and operation of application nodes in the robot system. Each application node corresponds to an independent functional module in the robot system, such as a sensor data processing module, a motion control module, etc. The functions of the application node can be defined and configured through the distributed node layer. In actual operation, the application node calls the system resources through the API of the function library layer in the distributed node layer to perform its defined tasks; in the development stage, the application node communicates with the underlying resources through the programming interface of the distributed node layer to complete tasks such as data reading, calculation, and execution of control instructions; each application node can run independently or concurrently, and use the distributed communication mechanism to coordinate work with other nodes. In addition, the application node uses the DDS protocol through the distributed node layer to exchange data and establish a communication channel.

[0063] Secondly, the distributed node layer not only realizes the communication between the application nodes inside the robot, but also can exchange data with the external robot operating system through the distributed communication protocol. In actual operation, the distributed node layer can discover and connect to the nodes in the external robot operating system through the cross-system function of the DDS protocol. Once a communication channel is established with the external system, the distributed node layer will ensure the reliability, real-time and security of data transmission according to the QoS parameter settings. The specific forms of data interaction can include sharing of sensor data, exchange of control instructions, task coordination, etc.

[0064] The above-mentioned cross-platform robot operating system, on the one hand, the operating system layer abstracts the differences between different operating systems by providing a unified API, so that the robot operating system can run on multiple operating system platforms, thereby improving the compatibility of the system. On the other hand, the function library layer implements distributed communication through the DDS protocol, which can ensure efficient and real-time data exchange between nodes, and uses the API of the operating system layer to directly access the resources of the underlying operating system. For different operating systems, the function library layer can use system resources in a unified manner to implement operations such as data transmission and task scheduling, thereby simplifying the development process. On the other hand, the distributed node layer supports automatic node identification and communication channel establishment to ensure collaborative work between nodes. At the same time, it interacts with external operating systems through a distributed communication mechanism to achieve multi-robot operating system collaboration and enhance the adaptability and scalability of the system. Below, the cross-platform robot operating system will be further described in another example embodiment.

[0065] In this embodiment, reference Figure 2 As shown, the operating system layer 1 may include a hardware abstraction module 101, a resource management module 102, a system call interface module 103, a device driver management module 104, a network management module 105, and an operating system adaptation module 106. Through the collaborative work of the above modules, the operating system layer can effectively manage and schedule the underlying hardware resources, system resources, and communication resources.

[0066] Among them, the hardware abstraction module 101 can be used to abstract and shield the underlying hardware details and provide a unified hardware interface for the upper layer. Through the hardware abstraction module, the upper layer, such as the function library layer, can directly access hardware resources such as CPU, memory, I / O devices, etc. without having to worry about specific hardware differences. For example, when an application node needs to process a task, it can request the CPU's computing resources or access I / O devices such as sensors or actuators through the hardware abstraction module. The hardware abstraction module maps these resource requirements to specific hardware interfaces and feeds the results back to the function library layer.

[0067] The resource management module 102 can be used to manage the allocation and scheduling of system resources, such as memory management, CPU time slice allocation, network and storage resource management, etc., which can ensure that the function library layer can efficiently access and use system resources. For example, when the function library layer issues a request, such as allocating a certain amount of memory for data storage or calculation, the resource management module will determine the current system resource usage and allocate corresponding memory resources.

[0068] The system call interface module 103 can be used to provide a standardized system call interface, allowing the function library layer to access the underlying functions of the operating system through the API. This module is responsible for receiving call requests from the upper layer and converting them into the specific implementation of the underlying operating system. Specifically, when the function library layer needs to perform underlying operations, such as file reading and writing, process creation, etc., it initiates a request by calling the API interface, and the system call interface module receives and converts the request into the specific implementation of the underlying operating system. For example, the function library layer can open a file through an API request, and the system call interface module converts it into the file processing mechanism of the operating system and returns the result to the function library layer.

[0069] The device driver management module 104 can be used to manage the driver programs of the robot hardware devices, provide access interfaces to various peripherals, such as sensors, actuators, etc., and present these interfaces to the function library layer through APIs. For example, when it is necessary to obtain data from a sensor or perform an operation through an actuator, the function library layer accesses these devices through API requests. The device driver management module is responsible for interacting with the driver programs of these devices to ensure that sensor data can be collected and passed to the function library layer, or that the actuator can complete the task according to the instructions.

[0070] The network management module 105 can be used to manage network connections and communication resources to support the needs of distributed communication. This module ensures that each node can transmit data and collaborate in real time through the network. For example, when a node in the distributed node layer needs to communicate with other nodes, it can request network resources through the function library layer. The network management module will ensure the establishment of network channels and allocate necessary bandwidth, priority, etc. to nodes according to needs to ensure the real-time and reliability of distributed communication. During the distributed communication process, the network management module can also dynamically adjust the use of network resources to avoid communication bottlenecks.

[0071] The operating system adaptation module 106 can be used to adapt to different preset operating systems, such as Linux operating system, Windows operating system, Unix operating system, macOS operating system, etc. For example, when the system runs in different operating system environments, the operating system adaptation module will identify the current operating system and provide appropriate API call conversion according to its characteristics. For example, on a Linux system, the operating system adaptation module can process operations such as files and processes through the POSIX standard interface.

[0072] In some embodiments, reference Figure 3 As shown, the function library layer 2 may include a synchronization module 201, a policy configuration module 202, a resource allocation module 203, a component module 204, and a language development module 205. The following is a detailed introduction to each module in the function library layer.

[0073] The synchronization module 201 can be used to automatically align messages from different sensors according to timestamps based on an approximate time synchronization algorithm when receiving a sensor data stream, and perform data processing and fusion with minimal delay.

[0074] Specifically, the synchronization module can receive data streams from multiple sensors, and the data generated by each sensor is timestamped. The sensors can be lidar sensors, inertial measurement units, ultrasonic sensors, temperature sensors, pressure sensors and other sensors set in the robot structure. The synchronization module uses an approximate time synchronization algorithm to process data with different timestamps. The algorithm determines whether it belongs to the same time window based on the timestamp of each sensor data stream. The synchronization module automatically adjusts the data of different sensors by parsing the timestamps so that they can be aligned in the time dimension. After the data is aligned, the synchronization module processes and fuses the data with minimal delay. Minimum delay can mean that the time from data reception to processing completion is shortened as much as possible to ensure that the system can respond in real time. The aligned sensor data will be fused to produce more accurate and complete robot sensor data.

[0075] In some embodiments, the synchronization module may include a timestamp parsing unit, a time window management unit, an approximate time synchronization algorithm unit, a data alignment unit, a delay and error management unit, and a data processing and fusion unit.

[0076] Among them, the timestamp parsing unit can be used to parse and manage the data timestamps from multiple sensors to accurately record the time when each piece of data was generated. Specifically, this unit is responsible for reading and parsing the timestamp information in the sensor data stream and comparing it with standard time bases, such as system time, NTP server time, etc. In addition, the timestamps of different sensors may use different formats or resolutions. The timestamp parsing unit converts these timestamps in different formats into a consistent time base for subsequent processing. When receiving the data packet from each sensor, the timestamp parsing unit classifies the data packet according to the timestamp and maintains an independent time series queue for each sensor.

[0077] The time window management unit can align data streams from different sensors at similar time points by setting time windows, ensuring that all data can be processed within the same time range. For each timestamp, the time window management unit can evaluate whether it belongs to the set synchronization window. If data from multiple sensors falls within the same window, it is considered that they are observations from the same time point. If some sensor data does not fall within the current time window, the unit can adjust the time window size in a timely manner to adapt to the time delay and sampling frequency differences of different sensors.

[0078] The approximate time synchronization algorithm unit can dynamically adjust the time deviation between different sensor data based on the approximate time synchronization algorithm to ensure that the data is consistent in the time dimension. Specifically, the approximate time synchronization algorithm unit can parse the timestamp and calculate the time deviation of each sensor based on the clock difference and sampling frequency of the sensor. Then, the approximate time synchronization algorithm is used to dynamically adjust the synchronization window in combination with the characteristics of the sensor, such as sampling frequency, clock drift, etc., to ensure that the data of each sensor is aligned within a reasonable time range. At the same time, the unit can allow time deviation within a small range based on influencing factors such as network delay and data transmission jitter, and reduce synchronization errors through a tolerance mechanism. If some sensor data is delayed or has a large clock offset, the approximate time synchronization algorithm unit will adaptively adjust the synchronization algorithm, expand or reduce the synchronization window to match the characteristics of different sensors, and ensure the consistency of the sensor data stream in time.

[0079] For example, the process of adjusting the time deviation between different sensor data by the approximate time synchronization algorithm unit can be expressed by the following formula (1):

[0080]

[0081] Among them, T sync (t) represents the calculated time synchronization point, that is, the alignment time of all sensor data, N represents the number of sensors, T i(t) represents the timestamp of sensor i at time t, Δt i represents the time deviation of sensor i at time t, d i (t) represents the data delay of sensor i at time t, f i (t) represents the sampling frequency of sensor i, θ i (t) represents the clock offset of sensor i, θ ref (t) represents the value of the reference clock at time t, ω i (t) represents the rate of change of the clock offset of sensor i over time, Δ net (t) represents the jitter effect caused by network transmission.

[0082] The data alignment unit can align the data from different sensors at the same time point based on the parsed timestamp and time window results for subsequent data processing and fusion. In addition, if the timestamps are not completely synchronized, the data alignment unit will interpolate or predict the missing data to fill the data gaps.

[0083] The delay and error management unit can be used to manage the data delay and error of each sensor to ensure that the delay is minimized and the error range is controlled when aligning the data. For example, the delay and error management unit can monitor the data delay of each sensor in real time, including network transmission delay, hardware response time, etc. According to the monitoring results, the approximate time synchronization algorithm and time window are dynamically adjusted to adapt to the delay requirements in different scenarios. When the delay of a sensor exceeds the preset threshold, the delay and error management unit can take compensatory measures, such as using historical data to predict missing values ​​or perform data interpolation. In addition, the management unit will also evaluate the overall synchronization error of the operating system. When the error exceeds the acceptable range, an alarm will be issued or a resynchronization mechanism will be triggered to ensure the accuracy of data processing.

[0084] The data processing and fusion unit can be used to process and fuse the aligned data in real time so as to fuse multi-source data into a single piece of information for decision making or control. For example, different sensor data can be weighted according to the signal-to-noise ratio, accuracy, etc. of different sensors to ensure the accuracy of the fused data.

[0085] In this embodiment, the policy configuration module 202 can be used to monitor the network status and node load in real time, and dynamically configure the service quality policy of the data distribution service protocol through the application programming interface provided by the operating system layer.

[0086] Among them, the policy configuration module can dynamically adjust the service quality policy of the data distribution service protocol by real-time monitoring of the network status and node load to optimize the communication performance and resource allocation of the system. Specifically, the policy configuration module can monitor the network status of the robot operating system in real time, including key parameters such as network bandwidth, delay, jitter, and packet loss rate. When it detects that the network performance is degraded or the network load is too high, it issues a request to adjust the QoS policy to ensure the real-time and reliability of communication. In addition, the module monitors the processing load of each application node in real time, including CPU occupancy, memory usage, task scheduling time, etc. Through the resource management unit of the operating system layer, the policy configuration module can obtain the resource usage of each node and identify which nodes are in an overloaded or idle state. Moreover, the policy configuration module can dynamically adjust the QoS parameters of DDS according to the monitored network and node status through the API provided by the operating system layer. For example, when the network load is high, the bandwidth requirement of communication can be reduced, or when the node load is heavy, the priority transmission of data can be increased. In addition, the policy configuration module can adopt a feedback control mechanism to automatically adjust the QoS policy of the DDS protocol at regular intervals or when the system detects that the performance index exceeds the threshold.

[0087] In this embodiment, the resource allocation module 203 can be used to dynamically allocate and adjust the CPU core binding of each application node through the environment variables and real-time system calls provided by the operating system layer.

[0088] Among them, the resource allocation module can flexibly adjust the binding relationship between nodes and CPU cores by real-time monitoring of the CPU load and task requirements in the system, ensuring that high-priority and real-time tasks get sufficient computing resources, while optimizing the overall load balancing and resource utilization of the system. In addition, the module can dynamically allocate or reallocate CPU cores according to the urgency of the task and the load of the node to maximize system performance and avoid resource waste or overload.

[0089] In some embodiments, reference Figure 4 As shown, the resource allocation module 203 may include a demand detection unit 2031 , a core binding unit 2032 , a dynamic adjustment unit 2033 and an adaptive scheduling unit 2034 .

[0090] Among them, the demand detection unit 2031 can be used to determine the demand information and priority information of the application node through the environment variables provided by the operating system layer. Specifically, the demand detection unit can collect the demand information of each application node through the environment variables provided by the operating system layer, including the CPU computing resources required by each node, the priority of the task, the real-time requirements, the memory usage, etc. In addition, the unit can also parse the system configuration file or the operating parameters of the node to determine the resource requirements of the node, and monitor the priority information of the node to ensure that resources can be allocated to important or high-real-time tasks first.

[0091] The core binding unit 2032 can be used to bind and allocate CPU cores to corresponding application nodes based on demand information and priority information. Specifically, the core binding unit can execute the core allocation strategy based on the demand information and priority information provided by the demand detection unit, and allocate CPU cores that meet the requirements to each application node to ensure that each node can obtain appropriate computing resources. In addition, the core binding unit can also adopt static or dynamic binding strategies. For high-priority or real-time tasks, one or more CPU cores can be specifically bound to ensure that the computing resources of these tasks are not preempted by other tasks; for low-priority tasks, the core binding unit can allow these tasks to share CPU resources to avoid core idleness.

[0092] The dynamic adjustment unit 2033 can be used to monitor the CPU resource occupancy of each application node in real time through the performance monitoring interface of the operating system layer, and in response to resource overload, trigger the dynamic adjustment mechanism to optimize the CPU core binding. Specifically, the dynamic adjustment unit can monitor the CPU occupancy rate, computing load, processing delay and other indicators of each application node in real time through the performance monitoring interface of the operating system layer. When the resource consumption of an application node exceeds the preset threshold, the unit will trigger the dynamic adjustment mechanism. The dynamic adjustment mechanism can solve the overload problem by releasing the currently bound CPU core resources or allocating additional core resources to the overloaded nodes. At the same time, the dynamic adjustment unit can also reduce the core resources occupied by low-priority tasks based on priority information and reallocate them to high-priority tasks.

[0093] The adaptive scheduling unit 2034 can be used to monitor the operation of each application node in real time, and automatically allocate the application node to the available idle CPU core in response to the node overload. Specifically, the adaptive scheduling unit can regularly check the operation status and CPU core utilization of each node through the load monitoring interface of the operating system layer. If a node is overloaded and the bound CPU core has reached saturation, the unit will automatically find the idle or low-load CPU core in the current system and migrate or allocate the node to these cores. In addition, the adaptive scheduling unit can ensure that each node in the system can obtain computing resources under the premise of load balancing through an adaptive scheduling algorithm, and predict load changes by monitoring historical data, and allocate appropriate CPU cores in advance to avoid overload. When a new node joins the system, the adaptive scheduling unit can automatically allocate appropriate core resources for it, while balancing the resources of other nodes to ensure the load balancing and efficient operation of the entire system.

[0094] In this embodiment, the component module 204 can be used to provide basic functional support, and the component module accesses system resources through an application programming interface. Among them, the component module can represent a unit for providing system basic functional support, which can access system resources through an application programming interface provided by the operating system layer, and provide the required basic functional services for the upper layer application nodes, and provide necessary support for the development and operation of the application nodes.

[0095] In some embodiments, reference Figure 5 As shown, the component module 204 may include a coordinate transformation unit 2041 , a log unit 2042 , a parameter unit 2043 , and a diagnosis unit 2044 .

[0096] The coordinate transformation unit 2041 can be used to transform sensor data between different coordinate systems. Specifically, the coordinate transformation unit obtains the position and posture data of the sensor and transforms the data of all sensors into a unified coordinate system in combination with the reference coordinate system in the cross-platform robot operating system to ensure data consistency between sensors and facilitate data fusion and further processing.

[0097] For example, the sensor data can be transformed into the reference coordinate system in the cross-platform robot operating system using homogeneous coordinate transformation. The coordinate transformation process can be expressed by the following formula (2):

[0098] P r =R rs P s +T rs (2)

[0099] Among them, P r represents the homogeneous coordinate representation of the sensor data in the reference coordinate system, Ps represents the homogeneous coordinate representation of sensor data in the sensor coordinate system; T rs represents the translation vector from the sensor coordinate system to the reference coordinate system; R rs represents the rotation matrix from the sensor coordinate system to the reference coordinate system. In addition, the rotation matrix R rs Based on the sensor's orientation quaternion q=pq w ,q x ,q y ,q z ] is used for calculation, and the calculation process is shown in the following formula (3):

[0100]

[0101] q w is the scalar part of the quaternion, used to represent the magnitude of the rotation; q x ,q y and q z It is the vector part of the quaternion, which is used to represent the direction of the rotation axis.

[0102] The log unit 2042 can be used to record the operating status and error information of the operating system in real time. Specifically, the log unit can monitor the operating status of the system in real time through the API interface provided by the operating system, and write key information such as startup time, node loading status, task execution records, etc. into the log file. When a system abnormality or error occurs, the unit can capture the error code and related debugging information, and record detailed error logs to facilitate system debugging and troubleshooting.

[0103] The parameter unit 2043 can be used to parse and manage parameters from the instruction information. Specifically, the parameter unit can receive and parse parameter setting information from system instructions or application nodes, which may include system configuration options, dynamic parameters at runtime, and specific parameters that need to be adjusted during the tuning process.

[0104] The diagnostic unit 2044 can be used to monitor the operating status of the operating system in real time, generate a health report, and issue a warning when the system is abnormal. Specifically, the diagnostic unit can monitor the operating status of the operating system and application nodes in real time through the performance monitoring API interface provided by the operating system. When an operating abnormality is detected, such as excessive CPU usage, task timeout, or node failure, the diagnostic unit will trigger an early warning mechanism and remind through log recording, alarm prompts, or sending notifications to the upper layer.

[0105] In this embodiment, the development language module 205 can be used to provide an interface for development using a programming language, where the programming languages ​​include C++, Java, Python, Go, JavaScript, and other programming languages ​​that can be used in a robot operating system.

[0106] Specifically, the development language module provides developers with a flexible development environment, so that the system can use different languages ​​to write applications and control logic, which is convenient for cross-platform and multi-scenario applications. First, the development language module provides standardized API interfaces for each language. Developers can access the basic functions of the system resources and function library layer through these interfaces. At the same time, each programming language interface can be encapsulated so that developers can use the native characteristics of the language to interact with the underlying system. Secondly, the development language module can map the system API to the grammatical structure of different programming languages ​​through the language binding mechanism, for example, binding to classes and methods in C++, binding to function interfaces in Python, and using objects and method calls in Java. These bindings ensure that different languages ​​can interact with the system in a way that conforms to their own language characteristics. In addition, the development language module can provide an interface for communication between languages, so that different language modules can interact through data interfaces, message passing or shared memory. For example, Python modules can call underlying optimization functions written in C++, and Java modules can communicate with modules written in Go.

[0107] In some embodiments, reference Figure 6 As shown, the distributed node layer 3 may include a bridge module 301, a theme management module 302, a visualization module 303 and an agent module 304. Below, each module in the distributed node layer is introduced in detail.

[0108] Among them, the bridge module 301 can be used to interact with nodes in the ROS1 operating system and / or the ROS2 operating system based on distributed communication. Specifically, the bridge module can be used to implement communication bridging between the cross-platform robot operating system and the ROS1 or ROS2 operating system. Through this module, the cross-platform robot operating system can interact with nodes in the ROS1 or ROS2 operating system. In some embodiments, reference Figure 7 As shown, the bridging module 301 may include a node discovery unit 3011 , a protocol adaptation unit 3012 and a format conversion unit 3013 .

[0109] Among them, the node discovery unit 3011 can be used to discover and synchronize nodes in the ROS1 operating system and / or ROS2 operating system. Exemplarily, the node discovery unit can discover active ROS1 nodes through the ROS master node in ROS1, and the automatic discovery mechanism based on the DDS protocol automatically detects active ROS2 nodes by monitoring the DDS traffic in the network. At the same time, the discovered nodes will be recorded and added to the node mapping table of the cross-platform robot operating system to ensure that the cross-platform robot operating system can interact with ROS1 nodes and ROS2 nodes. When a node is found to be offline or invalid, the node discovery unit will remove the node from the mapping table and notify the cross-platform robot operating system to disconnect the communication channel with the node.

[0110] The protocol adapter unit 3012 can be used to convert the communication protocol of the ROS1 operating system and / or the ROS2 operating system. Exemplarily, when interacting with the ROS1 operating system, since the ROS1 system uses the ROS communication protocol based on TCP / IP, the protocol adapter unit can convert the distributed communication protocol of the cross-platform robot operating system into the TCP / IP protocol of ROS1. When interacting with the ROS2 operating system, since ROS2 uses the DDS protocol for communication between nodes, the protocol adapter unit 3012 can adapt the communication protocol in the cross-platform robot operating system to the DDS protocol in ROS2, ensuring that the nodes of the cross-platform robot operating system can communicate with the ROS2 nodes in a distributed manner. Moreover, the protocol adapter unit supports protocol conversion of bidirectional data streams, ensuring that the cross-platform robot operating system can send data to the ROS1 / ROS2 nodes and receive data from the ROS1 / ROS2 nodes.

[0111] The format conversion unit 3013 can be used to convert the information format between the cross-platform robot operating system and the ROS1 operating system or the ROS2 operating system. Specifically, the format conversion unit can automatically identify the format type of each piece of information based on information such as metadata, data type, and information header information of the information. When the cross-platform robot operating system sends information to the ROS1 operating system, the format conversion unit can convert the information into the TCP / IP data packet format of ROS1 and perform serialization processing to ensure that the information can be transmitted in the node of ROS1. When the cross-platform robot operating system sends information to the ROS2 operating system, the format conversion unit can convert the information into a ROS2 compatible information format, that is, a binary information structure supported by the DDS protocol. The nodes in ROS2 receive data through the DDS protocol and decode the received binary data into the original information format based on the deserialization mechanism. When the ROS1 operating system or the ROS2 operating system sends information to the cross-platform robot operating system, the format conversion unit converts the format of the information into a compatible format used in the cross-platform robot operating system.

[0112] In the present embodiment, the topic management module 302 can be used to provide the functions of publishing, subscribing, managing and monitoring the topic. Specifically, the topic management module can support message communication based on the publish / subscribe mode, and each application node publishes data or subscribes to the topics published by other nodes through the module. In addition, the topic management module can provide global management of all published and subscribed topics, including life cycle management, priority allocation and access control of the topics. In addition, the topic management module can monitor the transmission status of each topic in real time, including data transmission delay, bandwidth usage, message publishing frequency and reception success rate.

[0113] In this embodiment, the visualization module 303 can be used to display the visualization data and system status through a visualization interface. Specifically, the visualization module can be used to display the data, sensor information, system status and task execution status of each application node in a graphical manner. Visual data types include: sensor data, CPU usage, memory usage, communication status, node health status and task execution progress. In addition, the visualization module can also intuitively display the logs and diagnostic information of the cross-platform robot operating system to help developers quickly identify and locate problems in the system. The visualization module can also support the search, filtering and sorting functions of the logs to facilitate the screening of key information by time or category.

[0114] In this embodiment, the proxy module 304 can be used to provide support for multiple programming languages, so that each application node can interact using different programming languages. Specifically, the proxy module is mainly used to provide a communication bridge between nodes written in different programming languages, so that nodes written in different languages ​​can communicate with each other and exchange data through the module. Through the proxy module, developers can use nodes in different languages ​​to publish and subscribe to topics and exchange data.

[0115] Figure 8 This is a schematic diagram of a cross-platform robot operating system structure block diagram in another embodiment of the present disclosure, with reference to Figure 8 As shown, the cross-platform robot operating system includes an operating system layer 1, a function library layer 2 and a distributed node layer 3. Among them, the operating system layer 1 includes a hardware abstraction module 101, a resource management module 102, a system call interface module 103, a device driver management module 104, a network management module 105 and an operating system adaptation module 106. The function library layer 2 includes a synchronization module 201, a policy configuration module 202, a resource allocation module 203, a component module 204 and a language development module 205. The distributed node layer 3 may include a bridge module 301, a theme management module 302, a visualization module 303 and an agent module 304.

[0116] Specifically, the cross-platform robot operating system consists of an operating system layer 1, a function library layer 2, and a distributed node layer 3, each of which has different functions.

[0117] The operating system layer 1 is the foundation of the system and is responsible for interacting with the underlying hardware and operating system. It can shield the differences between different hardware platforms through the hardware abstraction module 101 to ensure that the upper-level applications do not need to care about the specific hardware configuration. The resource management module 102 can be used to manage the allocation and scheduling of system resources to ensure efficient operation of the system. The system call interface module 103 can provide a standardized system call interface for the function library layer to access the underlying system resources. The device driver management module 104 can be used to manage the drivers of various hardware devices to ensure effective access to sensors and actuators. The network management module 105 can be used to manage network connections and communication resources to support communication between distributed nodes. The operating system adaptation module 106 can be used to ensure that the system can adapt to different operating systems, such as Linux, Windows, etc., to achieve cross-platform compatibility.

[0118] The function library layer 2 runs on the operating system layer and is responsible for providing core function support and distributed communication mechanism for the robot system. The synchronization module 201 can be used to process and align data from multiple sensors to ensure that the data can be fused and processed in real time. The policy configuration module 202 can be used to dynamically adjust the service quality policy of the data distribution service protocol according to the network status and node load to optimize the communication performance. The resource allocation module 203 can be used to dynamically allocate and adjust CPU core resources through the operating system interface to ensure system load balancing and efficient operation. The component module 204 can provide basic function support for the system, such as logging, coordinate transformation, parameter management, etc., to ensure the maintainability and debugging capabilities of the system. The language development module 205 can provide development interfaces for multiple programming languages, support languages ​​such as C++, Python, Java, etc., to ensure that developers can use different languages ​​for system development.

[0119] The distributed node layer 3 can be used to manage and coordinate the various application nodes in the system to ensure that the application nodes can work together through a distributed communication mechanism. The bridge module 301 can be used to achieve interoperability between the cross-platform robot operating system and the ROS1 or ROS2 operating system, and ensure smooth data exchange between different platform systems through protocol conversion and node synchronization. The theme management module 302 can be used to manage and monitor the theme publishing and subscription mechanism in the system to ensure that each node can achieve data interaction through the theme. The visualization module 303 can provide a visual display of the system status, display sensor data, system performance and task execution status through a graphical interface, and help developers monitor and analyze the system operation in real time. The proxy module 304 can support the interaction of multiple programming languages, act as a communication bridge between different language nodes, and enable nodes in different programming languages ​​to achieve data interaction and cooperation through a unified interface. The cross-platform robot operating system greatly enhances the flexibility, scalability and compatibility of the system, and is suitable for a variety of robot platforms and complex distributed application scenarios.

[0120] In one embodiment of the present disclosure, a robot is also provided, which is configured with a cross-platform robot operating system in any of the above embodiments, and the robot includes any one of a legged robot, a quadrupedal robot, a bipedal robot, a wheeled robot, a wheel-legged robot, a quadrupedal robot, a humanoid robot, a cleaning robot, a transport robot, a mobile robot and a robotic arm.

[0121] like Fig. 9 As shown, a structural schematic diagram of a bipedal robot is exemplarily shown.

[0122] like Fig.10 As shown, a structural schematic diagram of a four-wheeled legged robot is exemplified.

[0123] like Fig.11 As shown, a structural schematic diagram of a humanoid robot is exemplarily shown.

[0124] Next, in the embodiment of the present disclosure, a cross-platform robot operation method is also provided, which can be applied to the cross-platform robot operating system in the above embodiment. Fig.12 As shown, the cross-platform robot operation method includes the following steps:

[0125] Step S1201, providing an application programming interface for accessing system resources based on a preset operating system, and abstracting the differences between different preset operating systems through the application programming interface;

[0126] Step S1202, accessing system resources through an application programming interface, and implementing distributed communication based on a data distribution service protocol;

[0127] Step S1203, identifying each other in the network based on distributed communication and establishing a communication channel;

[0128] Among them, the distributed node layer interacts with the external robot operating system through distributed communication.

[0129] Specifically, in step S1201, the operating system layer can provide an API for accessing system resources according to different preset operating systems, such as Linux, Windows, etc., so as to shield the differences between different operating systems through the API and achieve cross-platform compatibility. In addition, the function library layer and the distributed node layer can call the underlying resources through this API without having to care about the specific implementation differences of the operating system. The operating system layer is responsible for converting these API calls into system calls of the current operating system to achieve abstract processing of hardware and resources.

[0130] In step S1202, the function library layer can access system resources through the API provided by the operating system layer to perform tasks, data calculations and other operations. At the same time, the function library layer implements distributed communication within the robot system based on the DDS protocol. During the execution process, the function library layer accesses system resources such as memory allocation and CPU usage through API requests. The operating system layer is responsible for processing these requests and returning the corresponding resources. In addition, the function library layer uses the publish / subscribe mechanism of the DDS protocol to communicate between nodes. Each application node exchanges data in the system by publishing messages or subscribing to topics. The DDS protocol also controls the reliability, real-time and bandwidth utilization of data transmission through QoS to adapt to different application scenarios.

[0131] In step S1203, each application node automatically discovers other nodes in the network through the DDS protocol of the function library layer, and establishes communication channels as needed. These communication channels are used for data transmission between nodes to ensure the coordinated work of the distributed control system. When the system starts or nodes join, the distributed node layer automatically discovers nodes through the DDS protocol, and the nodes initiate communication requests by publishing topics or subscribing to specific topics. When a node publishes data, other nodes that subscribe to the data will automatically receive the data through the DDS protocol and perform collaborative processing through the established communication channels. The whole process occurs dynamically, and nodes can join or exit the network at any time, and the system automatically adjusts the communication structure according to demand.

[0132] In addition, the distributed node layer establishes a communication channel with external robot operating systems, such as ROS1 system or ROS2 system, through the cross-system communication capability of the DDS protocol. In this way, robot operating systems on different platforms can collaborate in real time. For example, in a multi-robot collaborative operation scenario, multiple operating systems can share sensor data, calculation results, or assign tasks to achieve efficient cross-system cooperation.

[0133] In addition, in an exemplary embodiment of the present disclosure, an electronic device capable of implementing the above-mentioned cross-platform robot operation method is also provided.

[0134] Those skilled in the art will appreciate that various aspects of the present disclosure may be implemented as systems, methods or program products. Therefore, various aspects of the present disclosure may be specifically implemented in the following forms, namely: complete hardware embodiments, complete software embodiments (including firmware, microcode, etc.), or embodiments combining hardware and software aspects, which may be collectively referred to herein as "circuits", "modules" or "systems".

[0135] Refer to the following Fig.13 1300 according to this embodiment of the present disclosure is described. Fig.13 The electronic device 1300 shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0136] like Fig.13 As shown, the electronic device 1300 is in the form of a general computing device. The components of the electronic device 1300 may include, but are not limited to: at least one processing unit 1310, at least one storage unit 1320, a bus 1330 connecting different system components (including the storage unit 1320 and the processing unit 1310), and a display unit 1340.

[0137] The storage unit stores program codes, which can be executed by the processing unit 1310, so that the processing unit 1310 executes the steps according to various exemplary embodiments of the present disclosure described in the above “Exemplary Method” section of this specification.

[0138] The storage unit 1320 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 1321 and / or a cache memory unit 1322 , and may further include a read-only memory unit (ROM) 1323 .

[0139] The storage unit 1320 may also include a program / utility 1324 having a set (at least one) of program modules 1325, such program modules 1325 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment.

[0140] Bus 1330 may represent one or more of several types of bus structures, including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

[0141] The electronic device 1300 may also communicate with one or more external devices 1370 (e.g., keyboards, pointing devices, Bluetooth devices, etc.), may also communicate with one or more devices that enable a user to interact with the electronic device 1300, and / or communicate with any device that enables the electronic device 1300 to communicate with one or more other computing devices (e.g., routers, modems, etc.). Such communication may be performed via an input / output (I / O) interface 1350. Furthermore, the electronic device 1300 may also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) via a network adapter 1360. As shown, the network adapter 1360 communicates with other modules of the electronic device 1300 via a bus 1330. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the electronic device 1300, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0142] Through the description of the above embodiments, it is easy for those skilled in the art to understand that the example embodiments described here can be implemented by software, or by software combined with necessary hardware. Therefore, the technical solution according to the embodiment of the present disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a terminal device, or a network device, etc.) to execute the method according to the embodiment of the present disclosure.

[0143] In an exemplary embodiment of the present disclosure, a computer-readable storage medium is also provided, on which a program product capable of implementing the above method of the present specification is stored. In some possible embodiments, various aspects of the present disclosure can also be implemented in the form of a program product, which includes a program code. When the program product is run on a terminal device, the program code is used to enable the terminal device to execute the steps according to various exemplary embodiments of the present disclosure described in the above "Exemplary Method" section of the present specification.

[0144] refer to Fig.14 As shown, a program product 1400 for implementing the training method of the feature extraction model described above according to an embodiment of the present disclosure is described, which can adopt a portable compact disk read-only memory (CD-ROM) and include program code, and can be run on a terminal device, such as a personal computer. However, the program product of the present disclosure is not limited thereto, and in this document, a readable storage medium can be any tangible medium containing or storing a program, which can be used by or in combination with an instruction execution system, an apparatus, or a device.

[0145] The program product may use any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0146] Computer readable signal media may include data signals propagated in baseband or as part of a carrier wave, in which readable program code is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Readable signal media may also be any readable medium other than a readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0147] The program code contained on the readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wired, optical cable, electromagnetic waves, etc., or any suitable combination of the foregoing.

[0148] Program code for performing the operations of the present disclosure may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, etc., and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as a separate software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving a remote computing device, the remote computing device may be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (e.g., through the Internet using an Internet service provider).

[0149] In addition, the above-mentioned figures are only schematic illustrations of the processes included in the method according to the exemplary embodiments of the present disclosure, and are not intended to be limiting. It is easy to understand that the processes shown in the above-mentioned figures do not indicate or limit the time sequence of these processes. In addition, it is also easy to understand that these processes can be performed synchronously or asynchronously, for example, in multiple modules.

[0150] Through the description of the above embodiments, it is easy for those skilled in the art to understand that the example embodiments described here can be implemented by software, or by software combined with necessary hardware. Therefore, the technical solution according to the embodiment of the present disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the embodiment of the present disclosure.

[0151] Finally, the above preferred embodiments are only used to illustrate the technical solutions of the present application and are not restrictive. Although the present application has been described in detail, those skilled in the art should understand that changes in form and details can be made thereto without departing from the scope defined by the claims of the present application.

Claims

1. A cross-platform robot operating system, characterized in that: It includes operating system layer, function library layer and distributed node layer; among which: An operating system layer, used for interacting with a preset operating system in which the robot hardware resides, the operating system layer being configured to provide the function library layer with an application programming interface for accessing system resources based on the preset operating system, and abstracting the differences between different preset operating systems through the application programming interface; A function library layer, running on the operating system layer, for implementing distributed communication of the robot, wherein the function library layer is configured to access system resources through the application programming interface and implement distributed communication based on a data distribution service protocol; A distributed node layer, used to realize the development and operation of application nodes, and each of the application nodes recognizes each other in the network and establishes a communication channel based on the distributed communication; Wherein, the distributed node layer exchanges data with the external robot operating system through the distributed communication.

2. The cross-platform robot operating system according to claim 1, characterized in that: The distributed node layer also includes: A bridge module is used to perform data interaction with nodes in the ROS1 operating system and / or the ROS2 operating system based on the distributed communication.

3. The cross-platform robot operating system according to claim 2, characterized in that: The bridging module further comprises: A node discovery unit, used to discover and synchronize nodes in the ROS1 operating system and / or the ROS2 operating system; A protocol adaptation unit, configured to perform communication protocol conversion on the ROS1 operating system and / or the ROS2 operating system; A format conversion unit is used to convert the message format between the cross-platform robot operating system and the ROS1 operating system and / or the ROS2 operating system.

4. The cross-platform robot operating system according to claim 1, characterized in that: The operating system layer includes: A hardware abstraction module is used to abstract and shield the underlying hardware details and provide a unified hardware interface for the function library layer; A resource management module, used to manage the allocation and scheduling of system resources, and ensure that the function library layer can access and use the system resources; A system call interface module, used to provide a standardized system call interface, allowing the function library layer to access the underlying functions of the operating system through the application programming interface; The device driver management module is used to manage the driver programs of the robot hardware devices and provide peripheral access interfaces; A network management module, used to manage network connections and communication resources to support the requirements of the distributed communication; The operating system adaptation module is used to adapt to different preset operating systems and abstract the differences between different preset operating systems.

5. The cross-platform robot operating system according to claim 1, characterized in that: The functional library layer also includes: The resource allocation module is used to dynamically allocate and adjust the CPU core binding of each of the application nodes through the environment variables and real-time system calls provided by the operating system layer.

6. The cross-platform robot operating system according to claim 5, characterized in that: The resource allocation module comprises: A demand detection unit, used to determine demand information and priority information of the application node through environment variables provided by the operating system layer; A core binding unit, configured to bind and allocate the CPU core to the corresponding application node according to the demand information and the priority information; A dynamic adjustment unit, configured to monitor the CPU resource occupancy of each of the application nodes in real time through a performance monitoring interface of the operating system layer, and trigger a dynamic adjustment mechanism in response to resource overload to optimize the CPU core binding; The adaptive scheduling unit is used to monitor the operation status of each of the application nodes in real time, and automatically allocate the application node to an available idle CPU core in response to a node overload.

7. The cross-platform robot operating system according to claim 1, characterized in that: The functional library layer also includes: The synchronization module is used to automatically align messages from different sensors according to timestamps based on an approximate time synchronization algorithm when receiving sensor data streams, and perform data processing and fusion with minimum delay.

8. The cross-platform robot operating system according to claim 7, characterized in that: The approximate time synchronization algorithm automatically aligns messages from different sensors according to timestamps, including: according to: Automatically aligning messages from the different sensors; wherein T sync (t) represents the calculated time synchronization point, N represents the number of sensors, T i (t) represents the timestamp of sensor i at time t, Δt i represents the time deviation of sensor i at time t, d i (t) represents the data delay of sensor i at time t, f i (t) represents the sampling frequency of sensor i, θ i (t) represents the clock offset of sensor i, θ ref (t) represents the value of the reference clock at time t, ω i (t) represents the rate of change of the clock offset of sensor i over time, Δ net (t) represents the jitter effect caused by network transmission.

9. The cross-platform robot operating system according to claim 1, characterized in that: The functional library layer also includes: The policy configuration module is used to monitor the network status and node load in real time, and dynamically configure the service quality policy of the data distribution service protocol through the application programming interface provided by the operating system layer.

10. The cross-platform robot operating system according to claim 1, characterized in that: The preset operating system is any one of the Linux operating system, Windows operating system, Unix operating system, and macOS operating system.

11. The cross-platform robot operating system according to claim 1, characterized in that: The functional library layer also includes: The component module is used to provide basic function support, and the component module accesses the system resources through the application programming interface.

12. The cross-platform robot operating system according to claim 11, characterized in that: The component modules include: A coordinate transformation unit for converting sensor data between different coordinate systems; A log unit, used to record the operating status and error information of the operating system in real time; A parameter unit, used to parse and manage parameters from instruction information; The diagnostic unit is used to monitor the operating status of the operating system in real time, generate health reports and issue warnings when the system is abnormal.

13. The cross-platform robot operating system according to claim 12, characterized in that: The converting of sensor data between different coordinate systems comprises: According to the homogeneous coordinate transformation: P r =R rs P s +T rs Change the sensor data to the reference coordinate system; where P r represents the homogeneous coordinate representation of the sensor data in the reference coordinate system, P s represents the homogeneous coordinate representation of sensor data in the sensor coordinate system, T rs represents the translation vector from the sensor coordinate system to the reference coordinate system, R rs Represents the rotation matrix from the sensor coordinate system to the reference coordinate system.

14. The cross-platform robot operating system according to claim 1, characterized in that: The distributed node layer also includes: Theme management module is used to provide topic publishing, subscription, management and monitoring functions; The visualization module is used to display visualization data and system status through a visualization interface.

15. The cross-platform robot operating system according to claim 1, characterized in that: The functional library layer also includes: The development language module is used to provide an interface for development using a programming language, wherein the programming language includes one or more of C++, Java, Python, Go, and JavaScript.

16. The cross-platform robot operating system according to claim 15, characterized in that: The distributed node layer also includes: The proxy module is used to provide support for multiple programming languages ​​so that each application node can interact using different programming languages.

17. A robot, characterized in that: A cross-platform robot operating system is configured as described in any one of claims 1-16, and the robot includes any one of a legged robot, a quadruped robot, a bipedal robot, a wheeled robot, a wheel-legged robot, a quadrupedal robot, a humanoid robot, a cleaning robot, a transport robot, a mobile robot and a robotic arm.

18. A cross-platform robot operation method, applied to the cross-platform robot operating system as claimed in any one of claims 1 to 16, characterized in that: The method comprises: Providing an application programming interface for accessing system resources based on a preset operating system, and abstracting the differences between different preset operating systems through the application programming interface; Accessing system resources through the application programming interface and implementing distributed communication based on the data distribution service protocol; Recognize each other and establish a communication channel in the network based on the distributed communication; Wherein, the distributed node layer interacts with the external operating system through the distributed communication.

19. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer program code instructions, which, when called by a processor of a robot, enable the robot to execute the cross-platform robot operation method as claimed in claim 18.

Images