Industrial robot master control system

Abstract

The invention discloses an industrial robot master control system which comprises a robot hardware abstraction layer, a real-time control algorithm plug-in layer and a non-real-time request corresponding layer, non-blocking asynchronous communication between different modules is achieved through a shared memory, and the robot hardware abstraction layer is used for shielding hardware differences generated due to different robot types. The high reusability of the robot master controller is realized; the real-time control algorithm plug-in layer is used for realizing the separation of the real-time control algorithm layer and the hardware abstraction layer and realizing the overall control of the robot; and the non-real-time request response layer is used for realizing interaction and communication capabilities of the robot and an external function module. The invention also provides a plurality of standardized system development interfaces, so that the system can form a unified development specification, a communication specification and a development mode under software and hardware decoupling. The system architecture provided by the invention is easy to realize in an industrial robot system, the mobility, compatibility and stability of software are improved through modular design, and the system architecture has relatively high applicability.

Description

Technical Field

[0001] The present invention belongs to the technical fields of robotics and master control software, and particularly relates to an industrial robot master control system. Background Art

[0002] With the continuous progress of robotics technology, especially in response to the needs of unstructured workplaces, the complexity of robots has inevitably increased. Modern robots typically consist of a large number of sensors, actuators, and processors, execute numerous control modules, and communicate through multiple controllers. In this context, the design of the master control software architecture becomes crucial.

[0003] To address this challenge, researchers have developed a variety of master control systems aimed at providing a flexible infrastructure for robot systems. The design of these frameworks takes into account the complexity of robot systems and aims to solve the application requirements under diverse tasks and complex constraints in unstructured environments. Currently, the mainstream advanced robot master control systems include OROCOS, Podo, YARP, ROS, etc. OROCOS is a real-time robot master control system designed for developing robot control applications consisting of multiple interacting components. It has the ability to schedule components to run in a single process and relies on the Common Object Request Broker (CORBA) architecture for inter-process communication. Although OROCOS has a certain ability to achieve real-time control, it cannot meet strict real-time requirements and lacks external algorithm plugins, which may limit its application in some high-dynamic and high-demand real-time application scenarios. Podo is a control system developed by the Korea Advanced Institute of Science and Technology for its DRC-Hubo robot. This system has real-time control capabilities and uses inter-process communication facilities based on POSIX IPC. In addition, Podo also utilizes a shared memory system called MPC for data exchange between processes on the same machine. However, Podo adopts a heterogeneous system architecture, which may lead to communication chaos. In a heterogeneous system, different types of components may need to adopt different communication styles, increasing the complexity and management difficulty of the system. YARP and ROS are popular component-based systems for inter-process communication, but they cannot guarantee real-time execution between modules or nodes. Although they perform excellently as external high-level software frameworks, they require a dedicated component for robot real-time control and thus cannot be widely used in real robot scenarios.

[0004] With the gradual diversification of robot application scenarios in unstructured environments, it is difficult for existing robot master control systems to achieve complex functions such as the management and maintenance of various data such as the motion state and operating state of robots, the dynamic response to real-time and non-real-time requests, and the dynamic loading and unloading of various control algorithms. Summary of the Invention

[0005] In view of the challenges such as diverse robot tasks, complex environments, and variable constraints in unstructured environments, as well as the deficiencies of existing technologies, the present invention proposes an industrial robot main control system. Its purpose is to design a main control system architecture for robots facing information perception, status maintenance, and request response, provide a standardized data interface for algorithm libraries such as kinematics, dynamics, intelligent planning and decision-making, and real-time control, and support the development and use of diverse algorithm libraries.

[0006] The purpose of the present invention is mainly achieved through the following technical solutions: an industrial robot main control system, including: a robot hardware abstraction layer, a real-time control algorithm plug-in layer, and a non-real-time request response layer. Asynchronous communication without blocking is achieved between different layers using a modular device-to-device asynchronous communication interface and shared memory;

[0007] The robot hardware abstraction layer is used to receive robot status data and send command data. Taking a URDF or SRDF file describing the robot model as input, it organically organizes data of different joints according to the configuration of the actual robot and updates the dynamic data of the robot;

[0008] The real-time control algorithm plug-in layer provides various types of real-time control algorithms, and realizes online switching between different control modes by managing and scheduling different control plug-ins to dynamically load or unload different controllers;

[0009] The non-real-time request response layer is used to receive non-real-time requests from third parties and realize the interaction and communication between the robot and external functional modules.

[0010] Furthermore, the system also includes a robot data and model module, which is an organized robot status container, including its on-board controller; the robot data and model module provides a unified interface for the status of the actual robot, provides a unified interface for the corresponding model counterparts, retrieves the results of common kinematic and dynamic calculations, and simplifies the data exchange between the robot and the corresponding model.

[0011] Furthermore, the robot hardware abstraction layer provides a middleware with independent thread capabilities independent of the underlying hardware or software, providing multiple interfaces; among them, the core component is the hardware abstraction layer (HAL) interface, which is responsible for providing a unified call interface for all different underlying hardware / software layers.

[0012] Furthermore, the HAL interface includes three abstract functions:

[0013] The init() function: is called during the initialization phase to open the connection with the underlying joint drive module and initialize the data structure of the robot;

[0014] The recvFromSlave() function: Reads data from different types of underlying hardware and assigns it to the data structure of the robot's response.

[0015] The sendToSlave() function: Communicates with different types of underlying hardware and sends command data to the corresponding hardware.

[0016] Further, the control plugin includes: joint position / velocity / torque control, Cartesian position / velocity / torque control, impedance control, admittance control, and trajectory tracking control.

[0017] Further, the real-time control algorithm plugin layer's real-time control algorithm uses a dedicated control IController interface, which includes:

[0018] The init_control_plugin() function: Is called when the controller is loaded. This function initializes various parameters and variables in the controller, establishes a mapping relationship between the data required by the controller and the shared memory, so as to facilitate the controller to read the corresponding robot state and various sensor data. At the same time, whether the underlying hardware is working abnormally will also be checked at this stage. If there are abnormal behaviors in the underlying hardware, the controller will not be loaded and error data will be reported.

[0019] The control() function: After the controller is loaded, this function will be called in a loop in each real-time cycle of the main control program. Users can implement their own control strategies in this function.

[0020] The close() function: Is called when the controller is unloaded. Users complete some necessary operations before the controller is unloaded in this function to ensure the safety of the robot after the controller is unloaded.

[0021] Further, receiving non-real-time requests from a third party in the non-real-time request response layer specifically includes: Receiving requests from users, and parsing different requests into different commands according to the protocol, so as to manage and schedule the robot's real-time control algorithm and the robot's sensor data to complete the tasks expected by the users; To achieve this goal, this layer will maintain a state machine to dynamically manage the running state of the robot.

[0022] Further, the non-blocking asynchronous communication implemented between different layers using the modular device-to-device asynchronous communication interface and shared memory specifically includes:

[0023] Connecting different layers or modules based on the EtherCAT communication protocol. Each module is designed to be able to run independently and execute specific tasks, and data exchange is carried out through the shared memory method, thereby realizing non-blocking asynchronous communication.

[0024] Further, the configuration process of the modular device - to - device asynchronous communication interface includes:

[0025] First, configure the master station network in the robot main control system. Connect the network card to the robot controller and use the corresponding toolkit to configure and manage the network. During the configuration process, assign a unique address to each slave station and set the communication parameters.

[0026] Second, define dedicated communication interfaces on each component of the robot. The dedicated communication interfaces are designed according to the communication requirements between components to enable asynchronous communication between each device and the main control system.

[0027] Further, the modular device - to - device asynchronous communication interface includes:

[0028] The initialize_socket() function: used to initialize the communication socket and associate it with the data in the shared memory.

[0029] The send_data() function: used to read command reference data from the shared memory and send it to the device. For pure external sensors, this function cannot perform any operations.

[0030] The receive_data() function: This function is used to receive the current state from the device and update it to the shared memory, and is called at the beginning of each running loop.

[0031] Advantages of the present invention:

[0032] First, the industrial robot software architecture proposed by the present invention realizes effective decoupling of software and hardware through modular design. By adopting a modular device - to - device asynchronous communication interface, a shared memory mechanism, and a general hardware abstraction layer (HAL), the differences in underlying hardware are shielded, enabling the software to be developed and run uniformly on different hardware platforms, significantly improving the system's portability, compatibility, and stability, and having high applicability and scalability.

[0033] Second, the real - time control algorithm plug - in layer proposed by the present invention provides various types of real - time control algorithms. By managing and scheduling different control plug - ins, different controllers can be dynamically loaded or unloaded, which has high flexibility and efficiency. Through the dynamic loading mechanism and open user extension interface of the real - time control algorithm plug - in layer, users can quickly develop and integrate custom function modules, realize the efficient deployment of multiple control strategies, significantly reduce the development complexity, shorten the development cycle, and meet the functional expansion requirements in complex application scenarios.

[0034] Thirdly, the present invention proposes an efficient inter-device communication technology, which improves the real-time performance of the system. Through the modular asynchronous communication interface between devices and shared memory technology, the data transmission process is optimized, solving the problems of high communication latency and poor real-time performance in the existing system, significantly improving the efficiency and real-time performance of data transmission, and meeting the high-performance requirements of industrial robots in complex task scenarios. Brief Description of the Drawings

[0035] Figure 1 is the architecture of the main control system of the industrial robot proposed by the present invention.

[0036] Figure 2 is the design concept diagram of the robot hardware abstraction layer proposed by the present invention.

[0037] Figure 3 is the unified modeling language diagram of the system architecture using the hardware abstraction layer method proposed by the present invention.

[0038] Figure 4 is the schematic diagram of the relationship between controller plugins proposed by the present invention.

[0039] Figure 5 is the schematic diagram of the life cycle of the controller plugin proposed by the present invention.

[0040] Figure 6 is the functional schematic diagram of the non-real-time request response layer proposed by the present invention.

[0041] Figure 7 is the example diagram of the functions provided by the non-real-time request response layer proposed by the present invention. Detailed Description of the Preferred Embodiments

[0042] In order to make the objectives, technical solutions and advantages of the present invention more clear and understandable, the following further describes the specific embodiments of the present invention in detail with reference to the accompanying drawings.

[0043] Figure 1 is the architecture of the main control system of the industrial robot provided in this specification. As Figure 1 shown, the system architecture in the present invention includes components such as a robot hardware abstraction layer, a real-time control algorithm plugin layer, and a non-real-time request response layer. Non-blocking asynchronous communication is achieved between each module through shared memory.

[0044] In the current system architecture layering, the robot hardware abstraction layer is divided according to functional modules. Each module is interconnected and there is no upper or lower layer relationship. In this embodiment, the robot hardware abstraction layer in the present invention maintains the running state of the robot and provides low-level control strategies, including the workspace limitation method of the manipulator, the force / torque limitation of the haptic master device, etc. This robot hardware abstraction layer enables users to effectively transplant and run the same control software module on different robots on simulation and real hardware platforms. Its main idea is to provide an independent layer relative to the robot hardware and high-level software, so as to be able to integrate new actuators, sensors or other hardware components. In terms of thread configuration, the software architecture of the present invention uses a separate thread to execute the low-level robot control loop and allows the implementation of controllers with different frequencies. Synchronization between the plugin handler thread and the robot hardware abstraction layer thread is achieved using conditional variables, which is necessary for safe access to shared data structures.

[0045] In this embodiment, the real-time control algorithm plugin layer provides various types of real-time control algorithms to achieve the overall control of the robot, such as joint position / velocity / torque control, Cartesian position / velocity / torque control, impedance control, admittance control, trajectory tracking control, etc. The real-time control algorithm plugin layer can dynamically load / unload different controllers by managing and scheduling different plugins to achieve online switching between different control modes.

[0046] In this embodiment, the non-real-time request response layer receives and responds to non-real-time requests from, for example, the secondary development program of the user, the intelligent planning and decision-making commands of the upper layer, the teach pendant and other third parties, and at the same time provides functions such as the status data of the robot, parsing the commands of third-party users, and managing the running state of the robot.

[0047] In this embodiment, the robot data and model module is essentially an organized container of the robot state, including its on-board controller. Therefore, it includes quantities that describe the measurements from the robot sensors [such as joint position and torque, motor current, inertial measurement unit (IMU) status, force / torque sensing, etc.] and control references (joint position, torque and impedance, etc.). Its main ideas are: to provide a unified interface for the state of the actual robot and also for the corresponding model counterparts; to standardize the API for retrieving the results of the most common kinematic and dynamic calculations; and to simplify the data exchange between the robot and the corresponding model.

[0048] In this embodiment, the software architecture uses a shared memory mechanism to implement communication between modules. This communication method is non-blocking asynchronous communication, allowing each module to read and write shared data in parallel without waiting for a response or execution from other modules. Through shared memory, data can be directly transferred between modules without expensive data copying or indirect transfer through message queues, etc., thereby improving the efficiency and speed of communication. In this architecture, communication between modules is based on read and write operations on a shared memory area, and these operations are atomic, ensuring data consistency and reliability. Due to the characteristics of shared memory, modules can quickly exchange data while avoiding blocking phenomena during communication, enabling the system to respond more efficiently to external events and instructions.

[0049] Figure 2 It is a design concept diagram of the robot hardware abstraction layer provided in this invention book. As Figure 2 shown, in order to shield the hardware differences brought by different robot types and achieve high reusability of the robot main controller, this embodiment designs a robot hardware abstraction layer module. The introduction of the robot hardware abstraction layer is the core of the robot main control software architecture design. Below the robot hardware abstraction layer, the robot main controller does not need to know the specific type of the robot it drives, but only responsible for receiving status data and sending command data. And the robot hardware abstraction layer will take URDF (Universal Robotics Description Format) or SRDF (Semantic Robotic Description Format) files that describe the robot model as input, organize the data of different joint modules according to the configuration of the actual robot, and update dynamic data such as the Jacobian matrix and inertia matrix of the robot in real time.

[0050] Figure 3 It is a unified modeling language diagram of the system architecture using the hardware abstraction layer method provided in this invention book. As Figure 3 shown, the hardware abstraction layer method in this embodiment includes core components such as the HAL interface, data and sensor interface, thread interface, controller interface, and model plugin interface.

[0051] In this embodiment, the core component HAL interface of the hardware abstraction layer is responsible for providing a unified call interface for all different underlying hardware / software layers, so that new robots of any configuration can be flexibly adapted.

[0052] Specifically, to achieve the goal of the core component HAL interface of the hardware abstraction layer, the HAL interface designs three abstract functions that need to be implemented by the corresponding robot:

[0053] The init() function: It is called during the initialization phase and is mainly used to establish a connection with the underlying joint drive module, initialize the robot's data structure, etc.;

[0054] The recvFromSlave() function: The main function of this function is to read data from different types of underlying hardware (such as joints, inertial measurement unit (IMU) sensors, force / torque (F / T) sensors, etc.) and assign it to the robot's response data structure;

[0055] The sendToSlave() function: Communicates with different types of underlying hardware and sends command data to the corresponding hardware (such as joints).

[0056] In this embodiment, the implementation of a standard interface of an R-HAL, such as handling joints, inertial measurement unit (IMU) sensors, force / torque (F / T) sensors, etc., must provide all the functions defined by the above three functions. According to different situations, users can also add more function capabilities to the R-HAL, such as adding variables in the R-HAL to characterize whether the hardware is a real robot device or a virtual simulation platform, so that the R-HAL can distinguish online whether the system is a real running robot device or a virtual simulation platform, and further allow the system to seamlessly switch between controlling real robots and virtual platforms.

[0057] Specifically, the three methods designed in the R-HAL: init(), recvFromSlave(), and sendToSlave(), etc. do not take any parameters. Because the types of internal shared data structures required by different device types may be completely different. Therefore, when a user needs to create a new R-HAL implementation, the user needs to create an appropriate data structure accordingly.

[0058] In this embodiment, interfaces such as ARTsbotEcatARTs are implemented through the core component HAL interface to define different devices.

[0059] In this embodiment, the data and sensor interface provides data interfaces such as joints, force / torque sensors (FT), and inertial measurement units (IMU). The ARTsJoint interface contains all abstract methods for obtaining and setting information related to joints; the ARTsFT interface contains all abstract methods for obtaining and setting information related to force / torque; the ARTsIMU interface contains all abstract methods for obtaining and setting information related to the inertial system.

[0060] In this embodiment, through the thread HALthread, the R-HAL creates a separate thread for each different underlying device to handle communication with it. Therefore, synchronization is required between the threads of the R-HAL and the core thread of the main control program to safely access shared data.

[0061] Specifically, this embodiment incorporates the function of processing R-HAL concurrent threads. By shielding all details related to thread synchronization, it only provides two synchronization methods for users to obtain or set the status of the robot (such as position, speed, torque, stiffness, damping, etc.). When users implement methods such as init(), recvFromSlave(), and sendToSlave() defined by R-HAL, their calls and synchronization are hidden in the scheduling and thread synchronization of R-HAL. Adopting the dynamic API model, the design of this embodiment allows the system to automatically trim the data structure of the robot by reading the URDF file of the robot.

[0062] All R-HAL implementations are compiled into shared link libraries that can be dynamically loaded. According to the settings of the configuration file, users can decide which link libraries to load. The present invention adopts the factory design pattern to implement the dynamic loading / unloading of multiple shared link libraries. The robot core main program will load different R-HAL implementations according to the compliance information parsed from HALInterfaceFactory.

[0063] In this embodiment, the ThreadHook class implemented through the interface provides thread functions so that a control loop can be implemented. The ARTsbotCore class acts as a specific controller implementation, which interacts with the HAL by calling appropriate methods. The controller can access data such as joints, force-torque sensors (FT), and inertial measurement units (IMU) by simply calling the appropriate methods provided by the interface.

[0064] Figure 4 It is a schematic diagram showing the relationship between the controller plugins provided in the present invention book. As Figure 4 shown, the relationship between the general controller class GeneralController, the interface IController, and the controller plugins implemented by the user in this embodiment. Different controller plugins achieve dynamic loading and unloading through the setControllerCallback() method in the GeneralController class. And users can easily implement their own control strategies by inheriting and implementing the control() method defined in IController.

[0065] In this embodiment, for the dedicated control IController interface of the real-time control algorithm, three functions are designed to be implemented:

[0066] init_control_plugin() function: called when the controller is loaded. This function will initialize various parameters and variables in the controller, and establish a mapping relationship between the data required by the controller and the shared memory, so that the controller can read the corresponding robot status and various sensor data. At the same time, whether the underlying hardware is working abnormally will also be checked at this stage. If the underlying hardware has abnormal behavior, the controller will no longer load and report erroneous data;

[0067] control() function: After the controller is loaded, this function will be called cyclically in each real-time cycle of the main control program. Users can implement their own control strategies in this function;

[0068] close() function: called when the controller is uninstalled. The user can complete some necessary operations before the controller is uninstalled in this function, such as ending the robot's motion state, stopping sending control commands to the robot, etc., to ensure the safety of the robot after the controller is uninstalled.

[0069] Figure 5 Schematic diagram of the life cycle of the controller plug-in in the real-time control algorithm plug-in layer provided in this invention. Figure 5 As shown, in this embodiment, the real-time scheduling of the controller is completed by the scheduling mechanism embedded in the main control software. In this embodiment, the operation process of the control plug-in includes the following steps:

[0070] Loading phase: After ARTsbotCore is started, the init_control_plugin() method is called to complete the initialization operation of the control plug-in. At this time, the control plug-in enters the loading state and prepares for subsequent operations.

[0071] Start phase: After the user sends a start request, the on_start() method is called to control the plug-in to enter the start state, complete the startup operation and enter the run-ready state.

[0072] Run phase: In the run phase, the control_loop() method is called to control the plug-in to enter the loop running state. This phase is the core running phase of the control plug-in, which is used to implement the predetermined control logic. When the user issues a stop request or closes ARTsbotCore, the control flow changes.

[0073] Stop phase: When the user issues a stop request, the on_stop() method is called to control the plug-in to exit from the running state and enter the stopped state, indicating the suspension of the control operation.

[0074] Closing phase: When ARTsbotCore is closed, the close() method is called to control the plug-in from the current state to the closed state and complete the resource release operation.

[0075] Unloading stage: After the control plugin completes all operations and exits, the system unloads it and enters the unloading state, and the process ends.

[0076] Through the above state flow chart, this embodiment clarifies the operation logic of the control plugin in each state and the conversion conditions between states, thus ensuring the stability and reliability of the system operation.

[0077] In addition, in this embodiment, the scheduling mechanism is completely transparent to users and does not expose the underlying complex logic, which enables users to not worry about the real-time issue of the controller but only focus on the design of the required control strategy. This mechanism greatly reduces the difficulty of users' secondary development and significantly shortens the development cycle.

[0078] Figure 6 Shows the functional schematic diagram of the non-real-time request response layer proposed by the present invention. As shown in the figure, the non-real-time request response layer of this embodiment is mainly responsible for receiving the operation requests sent by users through the human-machine interface (HMI) and parsing these requests into corresponding instruction sets according to the preset protocol. Subsequently, this layer classifies and schedules the instructions according to the parsing results to implement the real-time control algorithm of the robot and the efficient management of sensor data, so as to meet the functional requirements of users for the robot.

[0079] To ensure the accuracy and timely response of tasks, a dynamically running state machine is built into the non-real-time request response layer. The state machine can dynamically evaluate and process user requests according to the current running state of the robot to ensure the stability and reliability of the system. At the same time, this layer is seamlessly connected with the motion kernel and the control management module (CtrlManager) through a shared cache mechanism, so as to realize the coordinated operation of various functional modules of the robot. These modules include but are not limited to robot data management, motion function scheduling, message mechanism control, I / O processing, log recording, and multi-robot cooperation. Through reasonable function division and modular design, the non-real-time request response layer can effectively improve the intelligence and user experience of the robot system.

[0080] In this embodiment, during the process of responding to user requests, this layer also has certain scalability and fault tolerance capabilities and can be further customized according to specific application requirements to adapt to more complex industrial scenarios. This design not only improves the flexibility of the system but also provides guarantee for subsequent function upgrade and expansion.

[0081] Figure 7 Is an example diagram of the functions provided by the non-real-time request response layer provided in the present invention book. Some of the contents that need to be implemented by the non-real-time request response layer of this embodiment are listed as Figure 7As shown, it includes providing the status data of the robot, parsing the commands of third-party users, managing the running status of the robot, etc.

[0082] Specifically, the functions provided by the non-real-time request-response layer are as follows:

[0083] Robot data function: Process parameters such as D / H, motors, coordinate systems, etc., and implement functions such as parameter loading, setting, and storage;

[0084] Motion function: Provide joint, linear, and circular interpolation, and implement functions such as motion sending, feedback, start / stop, etc.;

[0085] Message mechanism function: Provide status monitoring, set message start / stop, and implement functions such as message reading and setting;

[0086] I / O processing function: Implement functions such as reading and setting for digital and analog quantities;

[0087] Log function: Implement functions such as storage, reading, and reset for historical errors;

[0088] Multi-robot cooperation function, set multiple controllers to implement multi-robot cooperation function.

[0089] This layer is the window for the robot controller to interact with the outside world. However, due to the difficulty in ensuring real-time performance in the interaction with third parties, this layer will be designed as a non-real-time thread. At the same time, in order to prevent this layer from blocking and affecting the real-time performance of the underlying control and communication with hardware, asynchronous communication with hierarchical decoupling will be adopted between different layers of the robot main control software, and data exchange will be realized by accessing and reading the shared memory.

[0090] Furthermore, the modular device-to-device asynchronous communication interface is implemented based on Ethercat. Ethercat (Ethernet for Control Automation Technology) is a real-time communication protocol based on Ethernet, mainly used in the fields of industrial automation and robot control. It provides a high-performance and low-latency communication mechanism, which can meet application scenarios with high real-time requirements.

[0091] The modular device-to-device asynchronous communication interface is implemented through the following steps: First, configure the master station network in the robot main control system, connect the network card to the robot controller, and use the corresponding toolkits to configure and manage the network. During this configuration process, in order to ensure the stability and reliability of the network, a unique address needs to be assigned to each slave station, and parameters such as the communication cycle need to be set.

[0092] Secondly, dedicated communication interfaces are defined on each component of the robot. These interfaces are designed according to the communication requirements between components. Through these interfaces, each device can communicate asynchronously with the main control system. The dedicated communication interfaces are designed based on the actual requirements of each device (such as data transfer rate, response time, etc.). Under this framework, asynchronous communication between devices is specifically implemented to ensure that each module can efficiently and stably exchange data and cooperate. At the same time, the connection and removal of these dedicated communication interfaces will not affect other devices, ensuring the stability and reliability of the system. In addition, the communication of specific devices will not be blocked by other devices, ensuring the independence and isolation of communication. The communication design of the present invention makes the communication system highly scalable and flexible. By defining dedicated communication interfaces, new devices can be easily integrated into the system without affecting the existing devices. At the same time, this design also allows communication with devices of different frequencies simultaneously, thus meeting the asynchronous communication requirements for multiple devices and further improving the flexibility and versatility of the system.

[0093] For the asynchronous communication interface between modular devices, three functions are designed to implement:

[0094] The initialize_socket() function: This function is used to initialize the communication socket and the data association with the shared memory.

[0095] The send_data() function: This function is used to read the command reference data from the shared memory and send it to the device. For pure external sensors, this function cannot perform any operations because the sensors require command references.

[0096] The receive_data() function: This function is used to receive the current status from the device and update it to the shared memory. It is called at the beginning of each running loop.

[0097] The above embodiments are used to explain the present invention, rather than limit the present invention. Any modifications and changes made within the spirit and scope of the claims of the present invention fall within the protection scope of the present invention.

Claims

1. An industrial robot master control system, characterized in that: The system includes: robot hardware abstraction layer, real-time control algorithm plug-in layer and non-real-time request response layer. Different layers use modular device asynchronous communication interface and shared memory to realize non-blocking asynchronous communication. The robot hardware abstraction layer is used to receive robot status data and send command data. It takes the URDF or SRDF file describing the robot model as input, organizes the data of different joints according to the actual robot configuration, and updates the dynamic data of the robot. The real-time control algorithm plug-in layer provides various types of real-time control algorithms, dynamically loads or unloads different controllers by managing and scheduling different control plug-ins, and realizes online switching between different control modes; The non-real-time request corresponding layer is used to receive non-real-time requests from third parties, and realize interaction and communication between the robot and external functional modules.

2. An industrial robot main control system according to claim 1, characterized in that: The system also includes a Robot Data and Model Module, which is an organized container for the robot state, including its onboard controller; the Robot Data and Model Module provides a unified interface for the state of the actual robot, provides a unified interface for the corresponding model counterparts, retrieves the results of common kinematic and dynamic calculations, and simplifies data exchange between the robot and the corresponding model.

3. The industrial robot main control system according to claim 1, characterized in that: The robot hardware abstraction layer provides a middleware with autonomous thread capabilities that is independent of the underlying hardware or software and provides multiple interfaces; the core component is the HAL interface, which is responsible for providing a unified calling interface for all different underlying hardware / software layers.

4. An industrial robot main control system according to claim 3, characterized in that: The HAL interface includes three abstract functions: init() function: It is called in the initialization phase to open the connection with the underlying joint drive module and initialize the robot's data structure; recvFromSlave() function: reads data from different types of underlying hardware and assigns it to the robot's response data structure; sendToSlave() function: communicates with different types of underlying hardware and sends command data to the corresponding hardware.

5. The industrial robot main control system according to claim 1, characterized in that: The control plug-in includes: joint position / speed / torque control, Cartesian position / speed / torque control, impedance control, admittance control and trajectory tracking control.

6. The industrial robot main control system according to claim 1, characterized in that: The real-time control algorithm plug-in layer real-time control algorithm uses a dedicated control IController interface, which includes: init_control_plugin() function: This function is called when the controller is loaded. It will initialize various parameters and variables in the controller and establish a mapping relationship between the data required by the controller and the shared memory, so that the controller can read the corresponding robot status and various sensor data. At the same time, whether the underlying hardware is working abnormally will also be checked at this stage. If the underlying hardware has abnormal behavior, the controller will no longer load and report error data; control() function: After the controller is loaded, this function will be called cyclically in each real-time cycle of the main control program. Users can implement their own control strategies in this function; close() function: called when the controller is uninstalled. The user completes some necessary operations before the controller is uninstalled in this function to ensure the safety of the robot after the controller is uninstalled.

7. The industrial robot main control system according to claim 1, characterized in that: Receiving non-real-time requests from third parties in the non-real-time request corresponding layer specifically includes: receiving user requests and parsing different requests into different commands according to the protocol, so as to manage and schedule the real-time control algorithm of the robot and the sensor data of the robot to complete the tasks expected by the user; to achieve this goal, this layer will maintain a state machine to dynamically manage the operating status of the robot.

8. The industrial robot main control system according to claim 1, characterized in that: The non-blocking asynchronous communication between the different layers using the modular inter-device asynchronous communication interface and shared memory specifically includes: Different layers or modules are connected based on the EtherCAT communication protocol. Each module is designed to run independently and perform specific tasks, and exchange data through shared memory to achieve non-blocking asynchronous communication.

9. The industrial robot main control system according to claim 1, characterized in that: The configuration process of the asynchronous communication interface between modular devices includes: First, configure the master station network in the robot master control system, connect the network card to the robot controller, and use the corresponding toolkit to configure and manage the network; during the configuration process, assign a unique address to each slave station and set the communication parameters; Secondly, a dedicated communication interface is defined on each component of the robot. The dedicated communication interface is designed according to the communication requirements between each component to achieve asynchronous communication between each device and the main control system.

10. The industrial robot main control system according to claim 1, characterized in that: The modular inter-device asynchronous communication interface includes: initialize_socket() function: used to initialize the communication socket and data association with shared memory; send_data() function: used to read command reference data from shared memory and send it to the device. For purely external sensors, this function cannot perform any operations; receive_data() function: This function is used to receive the current status from the device and update it to the shared memory. It is called at the beginning of each run loop.

Images