Robot operating system, robot cross-platform development architectures, and robot cross-platform development method

Abstract

The present application is applied to the technical fields of artificial intelligence and robots. Provided are a robot operating system, robot cross-platform development architectures, and a robot cross-platform development method. By means of module conversion, a task module provided in a first robot operating system is encapsulated and adapted to a general task interface of a second robot operating system, so as to implement seamless integration and running across platforms; thus, consistent running of the same set of algorithm codes on different robot operating system platforms is realized, thereby avoiding repeated development for different operating systems, and reducing development time and resources; in addition, the universality and portability of modules are enhanced, the compatibility and scalability between different operating system platforms are improved, and flexibility and high efficiency are provided for the development of robot technology.

Description

Robot operating system and cross-platform development architecture, development method TECHNICAL FIELD

[0001] The present application relates to the technical field of robot operating systems, in particular to a robot operating system and a cross-platform development architecture and development method. BACKGROUND

[0002] With the continuous progress of science and technology, mobile robots have been increasingly widely used in many important fields such as civil and industrial applications.

[0003] A mobile robot is a complex integrated system of mechanical, electrical, control, and sensing technologies. The core controller of the mobile robot is usually based on an industrial control computer hardware platform, and a robot-specific operating system is installed on the platform. Various software algorithms developed for robot control, sensing, and decision-making run on the operating system, and ultimately complete the control and operation of the robot. As can be seen, the operating system plays a core and fundamental role in the robot control platform.

[0004] In actual applications, even if the same algorithm is executed for the same action, when it needs to run on different operating systems, the developer has to perform targeted repetitive development for different operating system platforms, resulting in waste of development resources and time.

[0005] Therefore, there is a need for a new development architecture that can support the same algorithm running on different robot operating system platforms. SUMMARY

[0006] Therefore, the embodiments of the present application provide a robot operating system and a cross-platform development architecture and development method, which are applied to the technical field of artificial intelligence and robots. By developing a module conversion toolkit, a task module developed on a first robot operating system platform is converted into a new module that can be compatibly run on a second robot operating system platform. This conversion process involves standardized packaging and interface adaptation, ensuring the consistency of algorithm code, so that the same code can run on different robot operating systems. In addition, by using a universal task interface, the task module converted by the conversion module toolkit can run seamlessly on the second robot operating system platform, thereby avoiding repetitive development work for different operating systems, improving the universality and reusability of the module, effectively saving development time and resources, and enhancing the compatibility and expandability between different operating system platforms.

[0007] The embodiments of the present application provide the following technical solutions:

[0008] The embodiment of the present specification provides a robot cross-platform development architecture applied to a first robot operating system side, the robot cross-platform development architecture comprising: a task module arranged in the first robot operating system; wherein the task module comprises a series of standardized API components, the series of standardized API components being used to export user-designed algorithm software as corresponding standardized APIs according to a kernel function of the task module, wherein each of the standardized APIs is used to be correspondingly embedded into a corresponding function layer in a conversion module, so as to be packaged by the conversion module as API data capable of being used by a general task interface in a second robot operating system.

[0009] The embodiment of the present specification also provides a robot cross-platform development architecture, the robot cross-platform development architecture comprising: a conversion module, wherein the conversion module comprises a plurality of first function layers and a first API layer, each of the first function layers being used to embed a corresponding standardized API to package the standardized API, wherein the standardized API is an API exported by a task module of a first robot operating system according to a kernel function of the task module to export user-designed algorithm software; and the first API layer is used to interface each of the packaged standardized APIs with a general task interface, wherein the general task interface is located in a second robot operating system and is provided with a second API layer for interfacing, and the second API layer is correspondingly arranged with the first API layer.

[0010] The embodiment of the present specification also provides a robot cross-platform development architecture applied to a second robot operating system, the robot cross-platform development architecture comprising: a general task interface arranged in the second robot operating system, wherein the general task interface comprises a second API layer and a plurality of second function layers; the second API layer is correspondingly arranged with a first API layer of a conversion module, and is used to obtain corresponding description data content from the corresponding first API layer; and the plurality of second function layers are used to form the description data content into an application interface and a function implementation corresponding to a kernel in the second robot operating system.

[0011] The embodiment of the present specification also provides a robot cross-platform development architecture comprising: a task module, a conversion module and a general task interface.

[0012] The task module is arranged in a first robot operating system and comprises a series of standardized API components, the series of standardized API components being used to export user-designed algorithm software as corresponding standardized APIs according to a kernel function of the task module, wherein each of the standardized APIs is used to be correspondingly embedded into a corresponding function layer in a conversion module;

[0013] The conversion module comprises a plurality of first function layers and a first API layer, wherein the plurality of first function layers are used for embedding corresponding standardized APIs to encapsulate kernel functions of the task module and the standardized APIs, and the first API layer is used for connecting each encapsulated standardized API with a corresponding second API layer in a general task interface;

[0014] The general task interface is arranged in a second robot operating system and comprises a second API layer and a plurality of second function layers, wherein the second API layer is arranged correspondingly to the first API layer to obtain corresponding data content from the encapsulated standardized APIs, and the plurality of second function layers are used for forming a corresponding application interface and function implementation in the second robot operating system.

[0015] The embodiments of the present specification also provide a robot cross-platform development method, comprising:

[0016] obtaining algorithm software designed by a user, wherein the algorithm software is algorithm software for realizing robot motion control based on a first robot operating system;

[0017] exporting the algorithm software to corresponding first data by any one of the robot cross-platform development architectures;

[0018] converting the first data into corresponding second data by any one of the robot cross-platform development architectures;

[0019] importing the second data into a general task interface in any one of the robot cross-platform development architectures, so that the algorithm software runs in a second robot operating system.

[0020] The embodiments of the present specification also provide a robot operating system, comprising: a task module in any one of the robot cross-platform development architectures, or a general task interface in any one of the robot cross-platform development architectures.

[0021] Preferably, the robot operating system further comprises: a conversion module in any one of the robot cross-platform development architectures.

[0022] Compared with the prior art, the above at least one technical solution adopted by the embodiments of the present specification can achieve at least the following beneficial effects:

[0023] The application realizes seamless integration and running across platforms by module conversion, encapsulating and adapting the task module arranged in the first robot operating system into the general task interface of the second robot operating system, thereby realizing consistent running of the same set of algorithm codes on different robot operating system platforms, avoiding repetitive development for different operating systems, saving development time and resources, while enhancing the universality and portability of the module, improving the compatibility and expansibility between different operating system platforms, providing flexibility and efficiency for the development of robot technology.

[0024] In addition, the module development design of the application follows a set of standardized API design rules, providing a standardized interface for the application of the module on other platforms, promoting the development and standardization of the core content of the module, significantly improving the development efficiency and code reusability, ensuring real-time and consistency across different operating system platforms, enhancing the flexibility, expansibility and maintenance simplicity of the system, and effectively reducing maintenance costs. BRIEF DESCRIPTION OF DRAWINGS

[0025] In order to more clearly illustrate the technical solutions of the embodiments of the application, the drawings needed in the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor.

[0026] Fig. 1 is a schematic diagram of the robot cross-platform development architecture in the application;

[0027] Fig. 2 is a series of standardized API component diagrams exported by the task module in the application;

[0028] Fig. 3 is a schematic diagram of the internal logic implementation of the task module in the application;

[0029] Fig. 4 is a schematic diagram of the relationship between the task module and the module converter in the application;

[0030] Fig. 5 is a schematic diagram of the relationship between the new module and the general task interface module in the application;

[0031] Fig. 6 is a corresponding relationship diagram of the first API layer of the conversion module and the second API layer of the general task interface in the application;

[0032] Fig. 7 is a task module architecture diagram in the application. DETAILED DESCRIPTION

[0033] The embodiments of the application will be described in detail below with reference to the drawings.

[0034] Following, the embodiments of the present application are described through specific examples, and other advantages and effects of the present application can be easily understood by those skilled in the art from the disclosure. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. The present application can also be implemented or applied through other different specific embodiments, and various modifications or changes can be made to the details in the specification based on different views and applications without departing from the spirit of the present application. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0035] It should be noted that the various aspects of the embodiments described below are within the scope of the appended claims. It should be apparent that the aspects described herein can be embodied in a wide variety of forms and that any specific structure and / or function described herein is merely illustrative. Based on the teachings herein one skilled in the art should appreciate that an aspect described herein can be implemented independently of any other aspects and that an aspect can be implemented both as any number of software and / or hardware structures and as any number of combinations of software and / or hardware structures. For example, an apparatus can be implemented using any number and combination of the aspects described herein.

[0036] It should also be noted that the figures provided in the following embodiments are only to illustrate the basic concepts of the present application in a schematic manner, and only the components related to the present application are shown in the figures, not the number, shape and size of the components when actually implemented. The actual implementation of each component can be a random change in shape, number and proportion, and the layout of the components can also be more complex.

[0037] In addition, in the following description, specific details are provided in order to facilitate a thorough understanding of examples. However, one skilled in the art will understand that the application can be practiced without these specific details.

[0038] The core controller of the mobile robot is based on industrial control computer hardware, and a robot-specific operating system is installed on the platform. These operating systems support the operation of key algorithms such as control, perception and decision-making, thereby ensuring the accurate operation and function realization of the robot.

[0039] At present, there are various different types of robot operating systems in the industry, such as the Robot Operating System (ROS) developed by Google, etc. However, due to the particularity of the operating system, even if the robot executes the same task algorithm (such as motion action, sensor algorithm, etc.), it cannot be directly run on different robot operating systems. Therefore, when the same task algorithm is applied to different robot operating system platforms, it needs to be opened separately and repeatedly, and cannot be directly applied across platforms, that is, the compatibility and interoperability across platforms between different robot operating systems need to be solved first.

[0040] For example, with the development of robot technology and related fields, different enterprises will choose their own operating system according to the characteristics of their own products, and even within the same enterprise, different operating systems will be used for different product types and series to exert their respective advantages. For example, the ROS system is known for its ecological users and open source properties, and is currently the most widely used robot operating system. However, due to the characteristics of different robot operating systems, developers need to develop robot application tasks for different operating system platforms, which increases the development difficulty for developers, and makes the maintenance and update of the system difficult and costly.

[0041] Therefore, in-depth analysis of robot operating systems and improvement of cross-operating system applications is needed. It is found that robot operating systems usually provide API interfaces to facilitate developers to design their own tasks based on APIs. Therefore, if the API interfaces provided by the robot operating system are utilized and improved, it is possible to run the same task algorithm software developed for the first operating system on two robot operating systems after API conversion, thereby eliminating the need for developers to develop two sets of task algorithms for two operating systems.

[0042] In the implementation of the improvement idea, it is further found that cross-platform between only two robot operating systems still has relatively large limitations. That is, the above improvement scheme needs to be improved again for the API interface function of the operating system if the robot operating system is replaced, which still increases the repetitive development work. Therefore, if a modular translator function is added inside or outside the robot operating system, the same task algorithm can be quickly and flexibly adapted to different robot operating systems through the modular translator.

[0043] Based on this, the embodiment of the present specification proposes a robot cross-platform development architecture, and the overall idea is as follows: as shown in FIG. 1, the algorithm software developed on the first robot operating system platform is still developed in the form of tasks, and only needs to form a series of standardized APIs based on the task module (Task Module), and then the standardized APIs are converted into algorithm modules available on the second robot operating system platform. Among them, the conversion module can be used as a toolkit, that is, the "modular translator" in the figure, to convert the standardized APIs formed by the task module, such as the input and output interfaces, instruction call attributes, parameters, etc. of the code kernel in the task module, into standardized encapsulation and conversion, into the interface and resource call mode available on the second robot operating system platform, realizing seamless integration and running across platforms, so as to realize consistent running of the same set of algorithm code on different robot operating system platforms, avoid repeated development for different operating systems, save development time and resources, and at the same time enhance the universality and portability of the module, providing flexibility and efficiency for the development of robot technology.

[0044] The technical solutions provided by the embodiments of the present application are described below in conjunction with the drawings.

[0045] As shown in FIGS. 1 and 2, the present specification provides a robot cross-platform development architecture applied to the first robot operating system side, which comprises: a task module arranged in the first robot operating system; wherein the task module comprises a series of standardized API components, which are used to export the algorithm software designed by the user into corresponding standardized APIs according to the kernel function of the task module, wherein each standardized API is used to be embedded into the corresponding function layer in the conversion module, so as to be encapsulated by the conversion module into API data that can be used by the general task interface in the second robot operating system.

[0046] Specifically, referring to FIG. 1, taking the first robot operating system platform and the second robot operating system platform (such as SAGE-OS and ROS, two different robot operating systems) as an example:

[0047] The algorithm software developed on the first robot operating system platform is developed in the form of a task module. The module is converted into an algorithm module available on the second robot operating system platform through a module conversion tool kit (hereinafter referred to as module conversion). The module conversion tool kit, i.e. the "modular translator" in the figure, the module conversion converts the task module, i.e. the input and output interfaces, instruction call attributes, parameters, etc. of the code kernel in the task module are standardized and converted into an interface and resource call mode available on other operating system platforms; the generated new module, i.e. "New modular".

[0048] In FIG. 1, the CM API on the second robot operating system platform is a general task interface developed based on the platform to realize the interface with any other third-party operating system platform algorithm module.

[0049] The general task interface is connected with the generated "new module" to complete the data interaction and instruction call, task execution, etc. of the new module on the second robot operating system platform.

[0050] Finally, the task module (a set of source code) developed on the first robot operating system platform can be applied on the second robot operating system platform, avoiding repeated development on two sets of operating system platforms.

[0051] Conversely, the task module developed on the second robot operating system platform can be applied on the first robot operating system platform through the conversion of the corresponding "modular translator".

[0052] As shown in FIG. 2, when developing a task module or an algorithm module on the first robot operating system platform, the task module or the algorithm module exports a Lite-SDK plug-in composed of a series of standardized APIs. Each standardized API in the task modular module is embedded into the corresponding functional layer in the modular translator to realize the adaptive packaging of the task modular kernel function and the API, ensuring that these APIs can be effectively used in the general task interface of the second operating system, thereby realizing the cross-platform compatibility and functionality.

[0053] In an embodiment, the task module further comprises a logic judging unit and a register unit, wherein the logic judging unit is configured to judge the type of the API to be called before the series of standardized API components are exported, and put the API to be called into the register unit, so that the kernel executes the corresponding API content call after internal matching of the API stored in the register.

[0054] Specifically, in the design of the task module, two key components, the logic judging unit and the register unit, are included. The function of the logic judging unit is to identify and judge the type of the API to be called before the series of standardized API components are exported. Once the type of the API is identified, the logic judging unit stores the information of the API into the register unit. Subsequently, the kernel of the task module reads the stored API information from the register unit and performs internal matching to determine and execute the corresponding API content call, thereby ensuring that the kernel of the module can efficiently and accurately respond to external requests and perform corresponding operations.

[0055] In an embodiment, the task module further comprises a numbering unit configured to number each API to be exported to mark the priority level of the API, the priority level being divided into a high priority level and a low priority level, the high priority level being used to mark the API call sensitive to real-time and requiring high real-time, and the low priority level being used to mark the API call not requiring high real-time; the logic judging unit, after judging the type of the API, puts the number corresponding to the API into the register unit, so that the kernel performs internal matching through the number in the register.

[0056] Specifically, as shown in FIG. 3, when the code of the task module or the algorithm module is running, the data and the functional logic framework provided by the API are executed. Each task module or algorithm module (hereinafter referred to as module) has a task kernel inside, and a series of standardized API interfaces are exported by the task kernel. Inside the module, each exported API is numbered and divided into two groups: high priority and low priority; as the name implies, the high priority API has the right to be executed first and is suitable for API calls sensitive to real-time and requiring high real-time. The low priority API is suitable for calls not requiring high real-time. The logic judging unit, after judging the type of the API, puts the number corresponding to the API into the register unit, so that the kernel performs internal matching through the number in the register.

[0057] In one embodiment, the register unit includes a first register group and a second register group, wherein the first register group is used to store the numbers of high-priority APIs, and the second register group is used to store the numbers of low-priority APIs, and the first register group triggers the kernel to perform internal matching processing in an interrupt mode when the numbers of high-priority APIs are stored, and the second register group is queried by the kernel to perform internal matching processing after the numbers of low-priority APIs are stored.

[0058] Specifically, in the design of the task module, the register unit includes a first register group and a second register group, when the task module receives an external call or interacts with the outside, the API number judgment logic unit in the kernel judges the type of the API being called, and outputs the number corresponding to the API, and stores the number in the first register group or the second register group.

[0059] The kernel performs internal matching according to the API numbers stored in the register, thereby executing the corresponding API content call. The API with a high priority will be executed first, similar to the interrupt mechanism. The API with a low priority will be queried, and when the number of the API is matched, the kernel will execute the corresponding call.

[0060] The implementation mechanism of the task module or the algorithm module in the above embodiment has the following advantages:

[0061] 1. The real-time property of the module is embodied

[0062] Because the mobile robot is applied to an industrial site, it is required to be highly consistent with the production tempo of the line, and in general, higher requirements are put forward for the real-time property of the robot. The real-time property of the internal software and algorithm is a basic guarantee for realizing the real-time property of the whole robot. Therefore, from the bottom logic and kernel running mechanism of the task module or the algorithm module, the above mechanism embodies the real-time property of the module, and discards the traditional module development process, which either develops a module as a whole into a real-time module or develops it into a non-real-time module according to requirements. The above mechanism realizes the unification of real-time and non-real-time within the same module.

[0063] 2. The standardized API logic architecture is realized within the module, which is more helpful for the development of the core content of the module and the standardized development of the module

[0064] The kernel mechanism of the above embodiment module solidifies the API logic architecture of the module, is suitable for modular development of any task type or modular development of any algorithm type, and developers only focus on kernel development of the content of the module, and no longer need to pay attention to how to develop the API interface and logic implementation of the module, which is more conducive to standardized development and improves the development efficiency and output of developers.

[0065] 3. The standardized interface is provided for application of the module on other platforms

[0066] The API logic of the above embodiment module provides a unified and standardized external interface and internal implementation mechanism for the module, and based on the API, data interaction with the external platform is more easily achieved according to different requirements of the external platform, which is a standardized API interface.

[0067] In an embodiment, the plurality of standardized APIs includes at least one or more of the following APIs: a data transmission API, a page jump API, an authority control API, and a calling channel API.

[0068] Specifically, as shown in FIG. 2, when a task module or an algorithm module is developed on the first robot operating system platform, the task module or the algorithm module exports a Lite-SDK plug-in, which is composed of a series of standardized APIs, including at least one or more of the following APIs: a data transmission API, a page jump API, an authority control API, and a calling channel API. The series of standardized APIs provide an interface and a bridge with the outside according to the needs of the internal running data, function calling, and control logic of the task module, so that the module can be more easily adapted and run on different operating system platforms after being converted by the module converter.

[0069] In an embodiment, the first robot operating system includes a SAGE-OS robot operating system.

[0070] The embodiment of the present specification also provides a robot cross-platform development architecture, which includes: a conversion module, wherein the conversion module includes a plurality of first function layers and a first API layer, each of the first function layers is used to embed a corresponding standardized API to encapsulate the standardized API, and the standardized API is an API exported by a task module of a first robot operating system according to a kernel function of user-designed algorithm software; and the first API layer is used to connect each encapsulated standardized API with a general task interface, wherein the general task interface is located in a second robot operating system and is provided with a second API layer for connection, and the second API layer is correspondingly provided with the first API layer.

[0071] Specifically, as shown in FIG. 4, the robot cross-platform development architecture includes a conversion module responsible for converting a task module developed on a first robot operating system into a module capable of running on a second robot operating system.

[0072] In implementation, the conversion module is responsible for embedding and encapsulating standardized APIs in the task module from the first robot operating system, which are derived according to the kernel function of the task module and represent the interface of the user-designed algorithm software. The encapsulated standardized APIs are further connected to the general task interface in the second robot operating system through the first API layer.

[0073] The general task interface has a second API layer corresponding to the first API layer, ensuring compatibility and functionality in the second operating system. Through this hierarchical and modular encapsulation and connection mechanism, the conversion module enables the task module originally designed for the first operating system to run seamlessly on the second operating system, achieving cross-platform code reuse and functional adaptation, thereby improving development efficiency, avoiding repetitive development for different operating systems, saving development time and resources, and enhancing the universality and portability of the module.

[0074] Therefore, the module translator is essentially an intermediate tool that can convert a task module developed on one platform into a task module applicable on other platforms. In simple terms, it is an "encapsulation" tool that "suits" the original module with a shell, through which other platforms can interact with the module.

[0075] In one embodiment, the first API layer interacts with the general task interface through a data stack.

[0076] Specifically, the first API layer defines multiple data stacks responsible for processing data from the task module and communicating with the general task interface according to established protocols and formats.

[0077] When the task module needs to exchange data or request services with the second operating system, the relevant data is first sent to the data stack of the first API layer. The data stack processes the data according to the preset rules and protocols, such as data packaging, encryption, protocol conversion, etc., to ensure that the data can be correctly understood by the target operating system. The processed data is then sent to the general task interface through the API layer.

[0078] In the second API layer of the general task interface, the received data is parsed, decrypted, converted, etc. to ensure that the data can be correctly executed in the second operating system. Through the interaction mode of the data stack, not only the security and accuracy of data transmission are ensured, but also the efficiency of data exchange is improved, realizing efficient communication and seamless integration of task modules between different operating system platforms.

[0079] In an embodiment, the first API layer includes one or more data stacks for data interaction: a data channel stack, an interaction protocol stack, a network protocol stack, and a hardware abstraction stack.

[0080] Specifically, as shown in FIG. 6, the first API layer includes one or more data stacks for data interaction: a data channel stack, an interaction protocol stack, a network protocol stack, and a hardware abstraction stack.

[0081] Correspondingly, in the second API layer of the general task interface, one or more data stacks for data interaction are also included, and correspond to those in the first API layer.

[0082] In an embodiment, the several first functional layers include:

[0083] A platform abstraction layer for abstractly describing the hardware platform on which the second robot operating system is located;

[0084] A network layer for describing a network protocol stack for data exchange;

[0085] A protocol layer for describing an interaction network protocol related to the second robot operating system;

[0086] A service layer for serving as a data channel;

[0087] Each first functional layer is embedded in the corresponding standardized API to realize the kernel function of the task module and the adaptive packaging of the API, so that each standardized API is expressed as data based on the corresponding functional layer of data interaction.

[0088] Specifically, as shown in FIG. 4, the relationship between the task module and the modular translator is shown: the series of APIs of the task module are the interface and bridge of the external functional information block.

[0089] In the modular translator, the overall architecture is designed as four first functional layers and one API layer, and the four first functional layers are:

[0090] A platform abstraction layer related to the hardware platform of the operating system of the platform to be converted;

[0091] A network layer for a network protocol stack;

[0092] Protocol layer: an interactive network protocol related to the platform to be converted to;

[0093] Service layer: data channel, instruction call, etc.;

[0094] API layer, which is the API interface with the operating system of the platform to be converted to;

[0095] Each API in the task modular module is embedded into the corresponding functional layer in the modular translator, realizing the adaptive packaging of the task modular kernel function and API. Finally, the Modular translator provides an interface in the form of an API layer for the converted operating system platform, enabling the original task module to interact and communicate with the new operating system platform.

[0096] In essence, the task module conversion (task modular) converts the control API in the task module into a module based on the data interaction network layer architecture, and prepares the corresponding API layer to interface with different operating system platforms, ensuring that the API of the task module can maintain its functionality and performance in the new operating system environment, achieving cross-platform compatibility and portability.

[0097] In one embodiment, the conversion module further includes a clock management unit and a register management unit, the clock management unit being configured to synchronize the clock pace of the interface between the first API layer and the general task interface, and the register unit being configured to complete the bidirectional transmission of the interface between the first API layer and the general task interface under the control of the clock management unit.

[0098] Specifically, the clock management unit synchronizes the clock pace between the first API layer and the general task interface, ensuring consistent time reference during data interaction, thereby avoiding data synchronization problems caused by inconsistent clocks. The register management unit is responsible for executing the data bidirectional transmission task between the first API layer and the general task interface under the unified scheduling of the clock management unit. Through the read and write operations of the register, the data is quickly accessed and transmitted, ensuring the real-time and accuracy of data interaction, thereby ensuring the compatibility between different operating system platforms and the stability of data interaction.

[0099] In the general task interface (CM API), each execution layer of the operating system of the platform performs the work of taking and placing data packets from the CM API stacks according to the specified protocol, and the new module calls the resources of the new platform through the content interaction of the "stack" on both sides.

[0100] The reading and writing of the two "stacks" are completed in a unified clock step to achieve the purpose of data interaction.

[0101] The reading and writing of the two "stacks" under the "step in unison" rule ensures the real-time and accuracy of data interaction, and improves the efficiency of data interaction.

[0102] The embodiment of the present specification also provides a robot cross-platform development architecture applied to a second robot operating system, which comprises: a general task interface arranged in the second robot operating system, wherein the general task interface comprises a second API layer and a plurality of second function layers; the second API layer is arranged corresponding to the first API layer of the conversion module, and is used to obtain corresponding description data content from the corresponding first API layer; the plurality of second function layers are used to form the application interface and the function implementation corresponding to the kernel of the second robot operating system.

[0103] Specifically, as shown in FIG. 5, the general task interface arranged in the second robot operating system comprises a second API layer and a plurality of second function layers;

[0104] The second API layer and the first API layer in the conversion module correspond to each other, receive and obtain corresponding description data content from the first API layer, and the data content contains all information and instructions required by the task module after being encapsulated by the conversion module, thereby realizing cross-platform.

[0105] In an embodiment, the plurality of second function layers comprise:

[0106] An operating system time management layer is used to obtain time data of the current operating system and manage the time data corresponding to the first API layer in the conversion module;

[0107] An operating system application data layer is used to interact with the application data corresponding to the runtime of the first API layer in the conversion module;

[0108] An operating system thread management layer is used to manage the threads corresponding to the execution and invocation of the first API layer in the conversion module;

[0109] An operating system abstraction layer is used to register the functions of the operating system layer into the corresponding first API layer of the conversion module, so that the corresponding first API layer of the conversion module can access the second robot operating system and the kernel resources of the second robot operating system;

[0110] A platform hardware abstraction layer is used to adapt the corresponding first API layer of the conversion module to the hardware platform of the second robot operating system.

[0111] Specifically, as shown in FIG. 5, the new module generated by converting the task module through the module conversion is connected with the CM (Common Mode) API of the new operating system platform through the unified API layer, and is implemented to run on the operating system platform.

[0112] The CM API layer of the operating system includes a plurality of second function layers, such as an operating system time management layer for obtaining the time data of the current system and interfacing with the new module, an operating system application data layer for realizing the application data interaction with the new module during running, an operating system thread management layer for realizing the thread management function during the execution and calling of the new module, an operating system abstraction layer for realizing the registration of the functions of the operating system layer into the new module, so that the new module can access the resources of the operating system and the operating system kernel through the layer, and a platform hardware abstraction layer for realizing the adaptability of the new module to the hardware platform of the new operating system.

[0113] Therefore, the CM API is actually an interface module layer developed according to the new platform, which is specially used for interfacing with the new module to realize the adaptive application interface and function implementation of the new module on the operating system platform.

[0114] In an embodiment, the common task interface (CM API) can interface with any plurality of "new modular"; that is, the modules developed on other platforms and generated into new modules after the modular translator are required to interface with the CM API. It can be said that the CM API is the entrance of the modules converted from other platforms to run on the platform. The modules developed on the platform do not need to pass through the CM API.

[0115] In an embodiment, the common task interface further includes a common clock management unit for clock management control of the module calling tasks in a queuing clock management mode.

[0116] And / or, the common task interface further includes a dedicated clock management unit for clock management control of the module calling tasks in a dedicated clock management mode, and for the module calling tasks in a queuing clock management mode.

[0117] Specifically, as shown in FIG. 7, in the CM API framework, each clock management and register management has a respective independent "stack" (array) to improve the running efficiency of the modules, and in this case, the overall efficiency is the highest (parallel mode), but the platform resources are occupied more.

[0118] Two or more modules can also share a "stack", and clock management of the two or more modules will be configured as a sequential clock mode, or a "queued" clock mode, to sequentially complete data interaction. In this case, platform resources are saved, but overall efficiency is reduced, and this is suitable for module calls that do not have high real-time requirements.

[0119] The module call priority can also be dynamically configured, and modules with high priority requirements, high real-time requirements, or large data flow data interaction amounts can use a separate or exclusive clock management mode. Modules with low priority requirements and low data flow data interaction amounts can use a queued clock management mode. A platform with abundant resources can use a separate or exclusive clock management mode more often.

[0120] A platform with limited resources can use a queued clock management mode.

[0121] It should be noted that the dynamic configuration mechanism provides convenience for system expansion, allows the system to flexibly adjust the clock management mode according to the current running state and task requirements, to adapt to different running conditions and environmental changes, and newly added modules can be flexibly integrated into the existing clock management framework according to their characteristics and requirements.

[0122] In an embodiment, different clock management is used for different task modules, as shown in FIG. 7, which is labeled as "clock management 1". For the CM API, there can be multiple clock management, i.e., clock management 2, clock management 3, etc., each of which corresponds to a module converted from an external platform.

[0123] Similarly, the same applies to register management.

[0124] In an embodiment, the second robot operating system includes a ROS robot operating system.

[0125] Embodiments of the present specification also provide a robot cross-platform development architecture, including a task module, a conversion module, and a general task interface.

[0126] The task module is arranged in a first robot operating system and includes a series of standardized API components, which are used to export user-designed algorithm software as corresponding standardized APIs according to the kernel functions of the task module, wherein each standardized API is used to be correspondingly embedded into a corresponding function layer in the conversion module.

[0127] The conversion module comprises a plurality of first function layers and a first API layer, wherein the plurality of first function layers are used for embedding corresponding standardized APIs to encapsulate kernel functions of the task module and the standardized APIs, and the first API layer is used for connecting each encapsulated standardized API with a corresponding second API layer in a general task interface;

[0128] The general task interface is arranged in a second robot operating system and comprises a second API layer and a plurality of second function layers, wherein the second API layer is arranged correspondingly to the first API layer to obtain corresponding data content from the encapsulated standardized APIs, and the plurality of second function layers are used for forming a corresponding application interface and function implementation in the second robot operating system.

[0129] Specifically, the robot cross-platform development architecture comprises a task module, a conversion module and a general task interface.

[0130] The task module is developed in a first robot operating system and comprises a series of standardized API components, which are used to export user-designed algorithm software as standardized APIs according to kernel functions of the task module, and each standardized API is embedded into a corresponding function layer in the conversion module to realize encapsulation of the kernel functions and the APIs.

[0131] The conversion module comprises a plurality of first function layers and a first API layer, wherein the plurality of first function layers are used for embedding corresponding standardized APIs to encapsulate kernel functions of the task module and the standardized APIs, and the first API layer is used for connecting each encapsulated standardized API with a corresponding second API layer in a general task interface;

[0132] The general task interface is arranged in a second robot operating system and comprises a second API layer and a plurality of second function layers, wherein the second API layer is arranged correspondingly to the first API layer to obtain corresponding data content from the encapsulated standardized APIs, and the plurality of second function layers are used for forming a corresponding application interface and function implementation in the second robot operating system.

[0133] Through the above architecture, the developed task module can be encapsulated and adapted by the conversion module to realize seamless integration and operation on the second robot operating system, which not only improves the universality and portability of the module, but also avoids repeated development of the same function on different operating systems, saves development time and resources, and enhances the compatibility and expansibility between different operating system platforms.

[0134] Based on the same inventive concept, the application also provides a robot cross-platform development method corresponding to the foregoing software architecture example, comprising:

[0135] obtaining user-designed algorithm software, wherein the algorithm software is algorithm software for realizing robot motion control based on a first robot operating system;

[0136] exporting the algorithm software to corresponding first data by applying the robot cross-platform development architecture to any one of the first robot operating system side;

[0137] converting the first data to corresponding second data by using a conversion module in the robot cross-platform development architecture;

[0138] importing the second data into a general task interface in any one of the robot cross-platform development architecture, so that the algorithm software runs in the second robot operating system.

[0139] It should be noted that the functions of each module in the robot cross-platform development method can be divided and implemented according to the robot cross-platform development architecture implementation example described above, which will not be described here.

[0140] Based on the same inventive concept, the application also provides a robot operating system, comprising: a task module in the robot cross-platform development architecture, or a general task interface in the robot cross-platform development architecture.

[0141] Preferably, the robot operating system further comprises: a conversion module in the robot cross-platform development architecture.

[0142] The application provides a cross-platform development architecture; including a modular development method, including a series of API implementation logic inside the module, including a conversion tool that can be used on other platforms after module conversion, including a general interface definition framework of the new module generated after conversion on other platforms.

[0143] In the specification, the same and similar parts among various embodiments can be referred to each other, and each embodiment focuses on the difference from other embodiments. In particular, for the embodiments described later, the description is relatively simple, and the relevant parts can be referred to the part of the foregoing embodiments.

[0144] The above is merely a specific implementation of the application, but the protection scope of the application is not limited thereto, and any person skilled in the art can easily think of changes or replacements within the technical range disclosed in the application, which should be covered within the protection scope of the application. Therefore, the protection scope of the application should be subject to the protection scope of the claims.

Claims

1. A robotic cross-platform development architecture, comprising: The robot cross-platform development architecture applied to a first robot operating system side comprises: a task module arranged in the first robot operating system; wherein the task module comprises a series of standardized API components, which are used to export user-designed algorithm software as corresponding standardized APIs according to the kernel function of the task module, and each of the standardized APIs is used to be embedded into a corresponding function layer in a conversion module, so as to be encapsulated by the conversion module as API data that can be used by a general task interface in a second robot operating system.

2. The robotic cross-platform development architecture of claim 1, wherein, The task module further comprises a logic judgment unit and a register unit, wherein the logic judgment unit is used to judge the type of the API called currently before the series of standardized API components export the standardized APIs, and put the called API into the register unit, so that the kernel performs internal matching and executes the corresponding API content calling after the API stored in the register.

3. The robotic cross-platform development architecture of claim 2, wherein, The task module further comprises a numbering unit, which is used to number each API to be exported, so as to mark the priority level of the API by the number, the priority level is divided into high priority level and low priority level, the high priority level is used to mark the API calling sensitive to real-time and high in real-time requirement, and the low priority level is used to mark the API calling not high in real-time requirement; the logic judgment unit puts the number corresponding to the API into the register unit after judging the type of the API, so that the kernel performs internal matching by the number in the register.

4. The robotic cross-platform development architecture of claim 3, wherein, The register unit comprises a first register group and a second register group, wherein the first register group is used to store the number of the high priority level API, the second register group is used to store the number of the low priority level API, and the first register group triggers the kernel to perform internal matching processing in a priority mode by interrupt when storing the number of the high priority level API, and the second register group performs internal matching processing by the kernel in a query mode after storing the number of the low priority level API.

5. The robotic cross-platform development architecture of claim 1, wherein, The series of standardized APIs comprise at least one or more of the following APIs: data transmission API, page jump API, permission control API, and calling channel API.

6. The robotic cross-platform development architecture of any of claims 1-5, wherein, The first robot operating system comprises a SAGE-OS robot operating system.

7. A robotic cross-platform development architecture, comprising: The robot cross-platform development architecture comprises: a conversion module, wherein the conversion module comprises a series of first function layers and a first API layer, each of the first function layers is used to embed a corresponding standardized API to encapsulate the standardized API, the standardized API is an API exported by the task module of the first robot operating system according to the kernel function of the user-designed algorithm software, and the first API layer is used to connect each of the encapsulated standardized APIs with a general task interface, wherein the general task interface is located in a second robot operating system and is provided with a second API layer for connection, and the second API layer is arranged correspondingly with the first API layer.

8. The robotic cross-platform development architecture of claim 7, wherein, The first API layer interacts with the general task interface in a data stack mode.

9. The robotic cross-platform development architecture of claim 8, wherein, The first API layer includes one or more data stacks for data interaction: a data channel stack, an interaction protocol stack, a network protocol stack, and a hardware abstraction stack.

10. The robotic cross-platform development architecture of claim 7, wherein, The first API layer includes one or more data stacks for data interaction: a data channel stack, an interaction protocol stack, a network protocol stack, and a hardware abstraction stack. The platform abstraction layer is used to abstract the hardware platform on which the second robot operating system is located. The network layer is used to describe the network protocol stack for data exchange. The protocol layer is used to describe the interaction network protocol related to the second robot operating system. The service layer is used as a data channel. Each first function layer is used to correspondingly embed the corresponding standardized API, implement the kernel function of the task module, and adaptively package the API, so that each standardized API is expressed as data based on the corresponding function layer of data interaction.

11. The robotic cross-platform development architecture of any of claims 7-10, wherein, The conversion module further includes a clock management unit and a register management unit. The clock management unit is used to unify the clock pace of the interface between the first API layer and the general task interface. The register unit is used to complete the bidirectional transmission of the interface between the first API layer and the general task interface under the control of the clock management unit.

12. A robotic cross-platform development architecture, comprising: The robot cross-platform development architecture applied to the second robot operating system includes a general task interface provided in the second robot operating system, wherein the general task interface includes a second API layer and a plurality of second function layers; the second API layer is correspondingly provided with the first API layer of the conversion module, and is used to obtain corresponding description data content from the corresponding first API layer; and the plurality of second function layers are used to form a corresponding application interface and function implementation of the kernel of the second robot operating system.

13. The robotic cross-platform development architecture of claim 12, wherein, The second API layer includes one or more data stacks for data interaction: a data channel stack, an interaction protocol stack, a network protocol stack, and a hardware abstraction stack. The operating system time management layer is used to obtain time data of the current operating system and manage the time data corresponding to the first API layer in the conversion module. The operating system application data layer is used to interact with the application data corresponding to the first API layer in the conversion module. The operating system thread management layer is used to manage threads corresponding to the execution and calling of the first API layer in the conversion module. The operating system abstraction layer is used to register functions of the operating system layer to the corresponding first API layer of the conversion module, so that the corresponding first API layer of the conversion module can access the kernel resources of the second robot operating system. The platform hardware abstraction layer is used to adapt the corresponding first API layer of the conversion module to the hardware platform of the second robot operating system.

14. The robotic cross-platform development architecture of claim 12, wherein, The general task interface further includes a general clock management unit, which is used to manage and control the clock of all module calling tasks in a queuing manner. The general task interface further includes a dedicated clock management unit, which is used to manage and control the clock of module calling tasks with high priority, high real-time requirement, or large data flow data interaction in a dedicated manner, and to manage and control the clock of module calling tasks with low priority or low data flow data interaction in a queuing manner.

15. The robotic cross-platform development architecture of any of claims 12-14, wherein, The second robot operating system includes a ROS robot operating system.

16. A robotic cross-platform development architecture, comprising: The robot cross-platform development architecture includes a task module, a conversion module, and a general task interface. ​ The task module is arranged in a first robot operating system, and includes a series of standardized API components for exporting user-designed algorithm software as corresponding standardized APIs according to kernel functions of the task module, wherein each of the standardized APIs is embedded in a corresponding function layer in a conversion module; The conversion module includes a plurality of first function layers and a first API layer, wherein the first function layers are used to embed corresponding standardized APIs to encapsulate kernel functions of the task module and the standardized APIs, and the first API layer is used to connect each of the encapsulated standardized APIs with a second API layer in a general task interface; The general task interface is arranged in a second robot operating system, and includes a second API layer and a plurality of second function layers, wherein the second API layer is arranged correspondingly with the first API layer to obtain corresponding data content from the encapsulated standardized APIs, and the second function layers are used to form the data content into a corresponding application interface and function implementation in the second robot operating system.

17. A method for cross-platform development of a robot, characterized by The method comprises: obtaining user-designed algorithm software, wherein the algorithm software is algorithm software for realizing robot motion control based on a first robot operating system; exporting the algorithm software as corresponding first data by using the robot cross-platform development architecture according to any one of claims 1-6; converting the first data into corresponding second data by using the robot cross-platform development architecture according to any one of claims 7-11; importing the second data into a general task interface in the robot cross-platform development architecture according to any one of claims 12-15, so that the algorithm software runs in a second robot operating system.

18. A robotic operating system, comprising: The method comprises: the task module in the robot cross-platform development architecture according to any one of claims 1-6, or the general task interface in the robot cross-platform development architecture according to any one of claims 12-15.

19. The robotic handling system of claim 18, wherein, The robot operating system further comprises the conversion module in the robot cross-platform development architecture according to any one of claims 7-11.

Images