A robot application framework system and a working method thereof

Abstract

The application belongs to the technical field of robots, and proposes a robot application framework system and a working method thereof.In the application, the robot application framework system is set as a first communication architecture for data stream communication of data transmission in a running stage, and a second communication architecture for control stream communication of component structure control; wherein the first communication architecture comprises multiple components, and the multiple components are connected into a pipeline framework structure through joints; the second communication framework comprises multiple components and multiple containers, and the multiple components and the multiple containers are connected into a tree-shaped framework structure; the application realizes a reasonable, efficient, flexible and stable system software architecture by using a modularization architecture design idea, can effectively reduce functional data coupling, improve software stability, reduce software development difficulty, and facilitate debugging and error processing.

Description

Technical Field

[0001] This invention belongs to the field of robotics technology, and in particular relates to a robot application framework system and its working method. Background Technology

[0002] The application scenarios of robot systems are becoming increasingly complex, and the functional requirements are becoming more and more diverse. Their implementation is usually a comprehensive and complex systems engineering project. In particular, robot systems are required to meet the characteristics of multi-tasking, strong real-time performance, secure communication and flexible structure, which puts forward high requirements for system planning and design.

[0003] The inventors discovered that in recent years, data communication in robot systems has primarily relied on the Robot Operating System (ROS) and ROS2. ROS is a secondary operating system for robots, but it lacks real-time capabilities. ROS2, a second-generation robot operating system designed and developed based on ROS, simplifies robot development tasks and accelerates the deployment of software libraries and toolsets. However, ROS and ROS2 operating systems have the following limitations: ROS heavily relies on the ROS Master; if the Master fails, the entire system crashes. Inter-process communication within ROS still requires network access, significantly impacting bandwidth consumption and transmission speed. When transmitting large amounts of data, the ROS1 sending and receiving latency increases exponentially. While ROS2 removes the centralized architecture and replaces the data transmission framework with a Data Distribution Service (DDS), solving data transmission security issues, it is more difficult to understand and less conducive to development. Furthermore, ROS2's transmission efficiency is not significantly different from or even slightly lower than ROS. Summary of the Invention

[0004] To address the aforementioned problems, this invention proposes a robot application framework system and its working method to meet the increasingly important requirements of robot software systems for flexibility, efficiency, low resource consumption, real-time performance, and strong scalability.

[0005] To achieve the above objectives, in a first aspect, the present invention provides a robot application framework system, which adopts the following technical solution:

[0006] A robot application framework system includes a first communication architecture and a second communication architecture;

[0007] The first communication architecture is used for data stream communication during the runtime phase of data transmission;

[0008] The second communication architecture is used for control flow communication for component structure control;

[0009] The first communication architecture includes multiple components, which are connected to each other through connectors to form a pipe frame structure; the second communication framework includes multiple components and multiple containers, which are connected to form a tree frame structure.

[0010] Furthermore, in the first communication architecture, each component contains subordinate functional components, and each component is equipped with multiple connectors for communication.

[0011] Furthermore, the connector includes an output connector and an input connector; each output connector supports connection to multiple input connectors, and an input connector is connected to only one output connector.

[0012] Furthermore, each layer in the first communication architecture includes upper-level components and lower-level components; lower-level components are created by upper-level components, and lower-level components are only responsible for their upper-level components. Upper-level components contain multiple lower-level components, and lower-level components have only one specific upper-level component.

[0013] Furthermore, the parent component is responsible for managing its subordinate components and provides a unified interface to the parent component; components do not support cross-level control.

[0014] Furthermore, the second communication architecture includes two parts: functional synchronization and message bus. The functional synchronization is performed between GhostNode components or Node components. Corresponding signals are sent to the message bus, and the signals are passed along the inheritance chain. When a signal is consumed, it is deleted. If it is not processed, it is passed up to the root component. If the root component also does not process the signal, it discards the signal.

[0015] Furthermore, the synchronization functionality is limited to basic framework functions, including creating, destroying, and changing connectors and component settings.

[0016] Furthermore, corresponding signals are sent to the message bus, including adding a connector, deleting a connector, communication error, connector parameter change, adding a component, deleting a component, connecting a connector, and disconnecting a connector.

[0017] Furthermore, the control flow starts from the bottom root component and creates child processes for new components.

[0018] To achieve the above objectives, in a second aspect, the present invention also provides a method for operating a robot application framework system, employing the following technical solution:

[0019] A method for operating a robot application framework system, employing the robot application framework system as described in the first aspect, includes:

[0020] The first communication architecture is used for data stream communication during the runtime phase.

[0021] The second communication architecture is used to perform control flow communication for component structure control.

[0022] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0023] In this invention, the robot application framework system is configured as a first communication architecture for data flow communication during the operation phase and a second communication architecture for control flow communication for component structure control. The first communication architecture includes multiple components connected by connectors to form a pipeline framework structure. The second communication framework includes multiple components and multiple containers connected to form a tree-like framework structure. This invention, with its modular architecture design, achieves a reasonable, efficient, flexible, and stable system software architecture, effectively reducing functional data coupling, improving software stability, lowering software development difficulty, and facilitating debugging and error handling. Attached Figure Description

[0024] The accompanying drawings, which form part of this embodiment, are used to provide a further understanding of this embodiment. The illustrative embodiments and their descriptions are used to explain this embodiment and do not constitute an improper limitation of this embodiment.

[0025] Figure 1 This is the basic data flow architecture of Embodiment 1 of the present invention;

[0026] Figure 2 This is the internal structure of the Node component in Embodiment 1 of the present invention;

[0027] Figure 3 This is the basic control flow architecture of Embodiment 1 of the present invention;

[0028] Figure 4 The process of building a communication pipeline for the control flow of Embodiment 1 of the present invention. Detailed Implementation

[0029] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0030] It should be noted that the following detailed descriptions are exemplary and intended to provide further explanation of this application. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

[0031] Example 1:

[0032] This embodiment provides a robot application framework system, including a first communication architecture and a second communication architecture;

[0033] The first communication architecture is used for data stream communication during the runtime phase of data transmission;

[0034] The second communication architecture is used for control flow communication for component structure control;

[0035] The first communication architecture includes multiple components, which are connected to each other through connectors to form a pipe frame structure; the second communication framework includes multiple components and multiple containers, which are connected to form a tree frame structure.

[0036] Specifically, the robot application framework system is designed with two communication architectures: a first communication architecture and a second communication architecture. The first is a data flow communication for data transmission during normal operation, and the second is a control flow communication for component structure control. The data during normal operation can be understood as the data generated by each component after the system starts up, completes the communication pipeline construction, and enters stable operation. The data flow communication is arranged in a pipeline layout according to the connection of the connectors in the components, and the control flow communication is arranged in a tree-like layout according to the component organization method.

[0037] like Figure 1 As shown, in the first communication architecture, each component contains lower-level functional components, and each component is equipped with multiple connectors for communication. Specifically, the data flow uses Node components as the basic unit, each Node component can contain other lower-level Node functional components, and each Node component can be equipped with several Pad connectors for communication.

[0038] The connectors include output connectors and input connectors; each output connector supports connection to multiple input connectors, and an input connector is connected to only one output connector. Specifically, Pad connectors are divided into output connectors OutPad and input connectors InPad according to their functions; each OutPad supports connection to multiple InPads, but an InPad can only be connected to one OutPad.

[0039] In the first communication architecture, each layer contains upper-level components and lower-level components. Lower-level components are created by upper-level components and are only responsible for their upper-level components. Upper-level components may contain multiple lower-level components, while lower-level components may have only one specific upper-level component. Specifically, each layer in the structure contains two sets of components: upper-level components and lower-level components. The framework has no limit on the number of layers. Lower-level components are created by upper-level components and are only responsible for their upper-level components. Upper-level components may contain multiple lower-level components, while lower-level components may have only one specific upper-level component. By default, each Node component exists in an independent process. Components can choose to run in an independent host, an independent process, an independent thread, or a parent thread environment. Upper-level components can control the connection status of their subordinate components.

[0040] like Figure 2As shown, a higher-level component is responsible for managing its subordinate components and provides a unified interface to the higher-level component. Components do not support cross-level control. A component containing child components can be regarded as a component group, which exposes specific connectors to complete the connection with other components.

[0041] The second communication architecture includes two parts: functional synchronization and a message bus. Functional synchronization occurs between GhostNode components or Node components. Corresponding signals are sent to the message bus, and these signals are passed along the inheritance chain. Once a signal is consumed, it is deleted; if not processed, it continues to propagate upwards until the root component. If the root component also does not process the signal, it discards it. Specifically:

[0042] Control flow communication occurs between hierarchical components within the Node component tree structure. Control communication is organized according to the component tree structure.

[0043] The control system comprises a message bus and functional synchronization. Functional synchronization occurs between GhostNode components or Node components (which may run in different containers), and is limited to basic framework functions, including creating, destroying, and modifying connectors and component settings. The message bus sends corresponding signals, which are passed along the inheritance chain. Once a signal is consumed (processed), it is deleted. If unprocessed, it continues to propagate upwards to the root component. If the root component also fails to process the signal, it discards it. Signal types include: adding a connector, deleting a connector, communication errors (for receiving components), connector parameter changes, adding a component, deleting a component, connector connection, and disconnection.

[0044] Control flow originates from the root component (i.e., the main process), creating child processes / threads for new components or component groups as needed. When parent and child components run in the same thread, management through the GhostNode component is unnecessary. Additionally, the parent process / thread synchronously creates GhostNode components to control the child components located in the child processes / threads from the parent component in the main process / thread. After creating the Pad connectors in each Node component, the parent node establishes the communication pipeline in the main process using the link function. The specific process is as follows: Figure 4 As shown.

[0045] Once the system is fully built, each sensor updates its data periodically. This data flows along the communication pipeline, is processed in the Node components, and is finally output. The data flow within the communication pipeline is decentralized. During normal operation, to ensure system stability, control communication exists outside the communication pipeline. This control communication uses IPC / RPC to implement functions such as Node component changes and the addition, deletion, and modification of Pad connectors during normal operation.

[0046] During normal operation, control communication still follows a tree structure. Each layer of control signal is only responsible for the sub-component directly connected to it, and each sub-component continues to manage downwards. Cross-layer management can only be completed by sequentially passing signals. For example, when the communication connection is interrupted, the data receiving component sends an exception message to the upper level. The upper-level component can process the message or forward the signal to a higher-level component for processing.

[0047] The Pad connector follows a trigger-based call approach for data processing. The data processing function is invoked only when data is passed from the upper layer; otherwise, it remains suspended. Its data processing method can also be modified in real-time by the upper-layer Node components during normal operation, ensuring the system can adapt its running state to complex environments.

[0048] In some embodiments, the modules of the robot application framework system are created according to the following steps:

[0049] S1. Initialization and creation:

[0050] An instance of the APP class is created in the parent process / thread to manage all child processes / threads created in that parent process / thread, i.e., the lower-level Node components connected to this Node component.

[0051] The component is created using the `create_node(sub-node component name)` method in the example.

[0052] The component creation process involves creating a NodeGhost component in the parent process / thread and creating a Node component in the child process / thread. Specifically, the `create_node` method instantiates and records a NodeGhost component using `NodeGhost(name, cfg, loop)`. Internally, `NodeGhost(name, cfg, loop)` starts a child process / thread and instantiates its child Node component using `Node(name, cfg, loop, address)`. Both NodeGhost and Node instantiation use the same parameters: `name`, `cfg`, and `loop`. `name` represents the component name; `cfg` represents the component's internal Pad header configuration information, including the Pad name, input / output mode, data format, current component description, additional functions, and additional signal configurations; `loop` represents the event loop in which the main program runs; and `address` in `Node` represents the "storage address" corresponding to the Node component created through `GhostNode`.

[0053] The GhostNode component and the Node component create GhostPad and Pad headers respectively based on the same cfg configuration file to complete system initialization.

[0054] S2, Communication Connection:

[0055] After the pipeline is created, the Pad connectors need to be connected according to the requirements of each Node component to form the internal communication module of the system. The specific process is as follows:

[0056] The parent process calls the `link(src, sink)` method to update the output connector receiving list. Here, `src` represents the output connector of the upstream component, and `sink` represents the input connector of the downstream component. The GhostNode component in the parent process / thread contains the "address" information of the child process / thread's Node component, relying on this "address" to update the upstream component's connection list to the downstream component.

[0057] S3, Data Transmission:

[0058] Data is sent from the output connector of a Node component to all downstream input connectors in the connection list. Input connectors can have their data processing method set using `@node.input_connector_name.set_reader`. Overall reception is triggered. When the component is idle, data arrival automatically triggers a function for processing; when the component is running, it automatically discards the currently sent data or sets up a buffer queue to store a fixed amount of data and continuously updates it, based on user needs. After data processing is complete, the output connector of the current Node component is called for further transmission.

[0059] S4. System Maintenance:

[0060] A parent process / thread only has supervisory capabilities over its child processes / threads and can communicate with its own parent process / thread. If a child process / thread terminates unexpectedly, an exception handling function is triggered. If the current component cannot resolve the exception, it is passed to the parent component for further resolution, ensuring overall system stability.

[0061] S5. System Dynamic Management:

[0062] The system has entered a normalized operation phase, with all components running stably. Users can add, delete, remove, or modify components and connectors during this phase as needed. Simultaneously, the Function and Setting classes can be used to add functions and modify configurations in real time. The system is modular, highly flexible, easier to manage, and less prone to crashes.

[0063] S6. Operating Environment:

[0064] By default, each Node component runs in an independent process, and creating a new Node component will open a new child process by default. You can change the default mode by modifying the cfg configuration file, allowing each component to run independently in its own thread, or placing some Nodes in the same process while placing the rest in separate processes.

[0065] Example 2:

[0066] This embodiment provides a method for operating a robot application framework system, which employs the robot application framework system as described in any one of Embodiment 1, including:

[0067] The first communication architecture is used for data stream communication during the runtime phase.

[0068] The second communication architecture is used to perform control flow communication for component structure control.

[0069] The above description is merely a preferred embodiment of this practice and is not intended to limit the scope of this practice. Various modifications and variations can be made to this practice by those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this practice should be included within the protection scope of this practice.

Claims

1. A robot application framework system, characterized in that, Including the first communication architecture and the second communication architecture; The first communication architecture is used for data stream communication during the runtime phase of data transmission; The second communication architecture is used for control flow communication for component structure control; The first communication architecture includes multiple components, which are connected to each other through connectors to form a pipe frame structure; the second communication frame includes multiple components and multiple containers, which are connected to form a tree frame structure. The connector includes output connectors and input connectors; each output connector supports connection to multiple input connectors, and an input connector is connected to only one output connector; each layer in the first communication architecture contains upper-level components and lower-level components; lower-level components are created by upper-level components, and lower-level components are only responsible for their upper-level components; an upper-level component contains multiple lower-level components, and a lower-level component has only one specific upper-level component; an upper-level component is responsible for managing its subordinate lower-level components and provides a unified interface to the upper-level components; components do not support cross-level control.

2. The robot application framework system as described in claim 1, characterized in that, In the first communication architecture, each component contains subordinate functional components, and each component is equipped with multiple connectors for communication.

3. The robot application framework system as described in claim 1, characterized in that, The second communication architecture includes two parts: function synchronization and message bus. The function synchronization is performed between GhostNode components or Node components. Corresponding signals are sent to the message bus. The signals are passed along the inheritance chain. When a signal is consumed, it is deleted. If it is not processed, it is passed up to the root component. If the root component also does not process the signal, the signal is discarded.

4. The robot application framework system as described in claim 3, characterized in that, The synchronization functionality is limited to basic framework functions, including creating, destroying, and changing connectors and component settings.

5. The robot application framework system as described in claim 3, characterized in that, Send corresponding signals to the message bus, including adding a connector, deleting a connector, communication error, connector parameter change, adding a component, deleting a component, connecting a connector, and disconnecting a connector.

6. The robot application framework system as described in claim 3, characterized in that, Control flow starts from the bottom root component and creates child processes for new components.

7. A working method for a robot application framework system, characterized in that, The robot application framework system described in any one of claims 1-6 includes: The first communication architecture is used for data stream communication during the runtime phase. The second communication architecture is used to perform control flow communication for component structure control.

Images