Industrial robot unified control architecture system and universal robot controller

Abstract

The invention discloses an industrial robot unified control architecture system and a universal robot controller, belongs to the technical field of robot control, and relates to a unified control architecture system based on an industrial robot whole machine performance optimization control algorithm. The problems that an existing industrial robot system is high in brand barrier and high in software and hardware coupling performance are solved. The system comprises the following hierarchical structures: a real-time control kernel layer, a system process and thread structure layer, a communication mechanism layer and a basic function module layer. The industrial robot unified control architecture system and the universal robot controller are suitable for integrating six-axis industrial robots of different brands and models into a unified group control system.

Description

Technical Field

[0001] The present invention relates to the field of robot control technology, and in particular to a unified control architecture system based on an industrial robot overall performance optimization control algorithm. Background Art

[0002] Industrial robots, core equipment in intelligent manufacturing, face a significant bottleneck in their control systems, hindering technological advancement. Currently, mainstream industrial robot manufacturers (such as ABB, KUKA, and FANUC) generally use closed controller architectures, which suffer from the following drawbacks: (1) High brand barriers: The systems of controllers from different brands are highly customized and only support robots and dedicated tool chains of their own brands. Controllers from different brands are incompatible with each other. Due to the brand protection mechanism, the hardware and software systems of controllers from different brands are deeply coupled, and the external interfaces are not open, making it impossible for developers to access the underlying drivers and key data channels.

[0003] This brand closedness leads to obstacles in joint development. Algorithm modules are difficult to transplant and interfaces need to be repeatedly developed for different brands. This makes it difficult to achieve cross-brand compatibility and collaborative control, greatly limiting the multi-party cross-platform collaborative innovation and rapid iteration of industrial robot technology.

[0004] A typical case: During the upgrade of an automotive spray painting production line, the team planned to deploy a vision-guided trajectory adaptation system. This required the intelligent algorithm development team to collaborate on a third-party AI path optimization algorithm, which would then be integrated with the existing branded robot system to control the robot's optimized trajectory in real time. However, because the branded controllers used a closed system and lacked a unified interface standard, the third-party algorithm could not be directly connected to the branded robot's control loop. Consequently, the project team had to rewrite the algorithm call interface for each branded robot separately, without even being able to access motion control details. This greatly limited the application effectiveness and deployment efficiency of the third-party algorithm.

[0005] (2) Lack of modular decoupling: Controllers from various brands use isolated interfaces that are not friendly to third-party developers and limit the development of the technology community. Robot control requires the cooperation of various basic functional modules, such as motion control, path planning, and trajectory tracking. Currently, controllers from various brands integrate functional modules such as motion control, path planning, and trajectory tracking into a closed-loop system with closed interfaces and fixed data links. Any third-party attempt to replace or optimize a module requires the reconstruction of the entire system, making "plug-and-play" module algorithms impossible and hindering the modular decoupling of functional modules.

[0006] A typical case: On an electronics manufacturing production line used for inspection and high-speed assembly, the research team attempted to replace the original brand robot's built-in trapezoidal velocity planning algorithm with their own "zero-speed start optimized trajectory generator" to improve end-point precision control. However, because the brand's robot controller did not support the injection of user-defined trajectory modules, it could only issue pre-calculated trajectory points through external means disguised as manual control, resulting in a significant decrease in the control system's synchronization performance.

[0007] In summary, the existing technology lacks a universal control architecture that covers six-axis industrial machines of multiple brands and multiple loads (15-200kg). Summary of the Invention

[0008] The present invention proposes a unified control architecture system for industrial robots and a universal robot controller, which solves the problems of high brand barriers and strong coupling between software and hardware in existing industrial robot systems.

[0009] The industrial robot unified control architecture system of the present invention comprises the following hierarchical structure: a real-time control kernel layer, a system process and thread structure layer, a communication mechanism layer, and a basic function module layer; wherein: The real-time control kernel layer includes: Hard real-time scheduling subsystem: built on Xenomai's Cobalt dual-core architecture; Kernel communication and interrupt isolation module: Isolation between the real-time domain and the non-real-time domain is achieved through I-Pipe and RTDM driver models; RTnet real-time network communication stack: establishes hard real-time communication links; Multi-core CPU logical core isolation module: assigns real-time tasks and non-real-time tasks to independent CPU cores; The system process and thread structure layer includes: Machine planning process: runs in the non-real-time domain and is used to handle non-hard real-time tasks at the global level of the system; Joint drive control process: runs in the real-time domain and is used for the underlying control of each robot's execution joints; Debug simulation process: runs in the non-real-time domain and is used for visual debugging and remote simulation support; The communication mechanism layer includes: EtherCAT bus communication channel: real-time communication between the system main controller and each joint driver; Real-time thread communication: periodically parses the TxPDO datagram of the slave driver and constructs the corresponding RxPDO control word to form a closed-loop feedback control chain; Remote communication interface Socket API: realizes the communication interface between the system and the host computer or simulation terminal; The basic function module layer: uses modular encapsulation to build basic function modules, deploys them in the form of dynamic link libraries, and opens them to the upper system through a unified interface standard.

[0010] Furthermore, a preferred embodiment is provided, wherein the basic functional modules include: a data transmission module, a system monitoring module, a servo management module, a drive control module, an IO control module, a trajectory planning module, a kinematics module (D7) and a motion control module; Data transmission module: realizes cross-domain data synchronization and message forwarding; System monitoring module: collects bus and motor operating status for health diagnosis; Servo management module: supports identification, configuration and control mode switching of multi-brand drives; Drive control module: realize joint-level closed-loop control based on PDO / SDO; IO control module: supports unified acquisition and control of analog and digital quantities; Trajectory planning module: generates smooth and controllable B-spline paths; Kinematics module: provides forward and inverse solutions and singularity obstacle avoidance functions; Motion control module: Integrates dynamic compensation and vibration suppression mechanisms to achieve high-speed and high-precision trajectory tracking.

[0011] Furthermore, a preferred embodiment is provided, in the hard real-time scheduling subsystem (A1): In the Cobalt dual-kernel architecture, the system runs in two isolated kernel spaces: The Cobalt kernel is responsible for real-time task scheduling and interrupt handling; The Linux kernel handles non-real-time tasks.

[0012] Furthermore, a preferred embodiment is provided, wherein the RTnet real-time network communication stack bypasses the non-real-time path of the traditional TCP / IP network protocol and directly establishes a data link in the Cobalt real-time domain, thereby improving communication delay and jitter control capabilities.

[0013] Furthermore, a preferred embodiment is provided, wherein the whole machine planning process includes a trajectory planning module and a kinematics module; Trajectory planning module: supports multiple trajectory generation methods, and the generated trajectory is directly transferred to the real-time control domain for subsequent interpolation execution; Kinematics module: responsible for low-level geometric operations.

[0014] Furthermore, a preferred embodiment is provided, wherein the joint drive control process includes a real-time communication thread, a status monitoring thread, an initialization thread, and an interaction thread; Real-time communication thread: runs at the highest scheduling priority and is used for direct data communication with the servo drives of each joint; Status monitoring thread: used to continuously evaluate the bus communication status; Initialization thread: During system startup or device reconnection, it is used to automatically load servo drive parameters and complete one-click adaptation based on different manufacturers and hardware configurations; Interactive thread: used to receive keyboard commands from the user and implement basic human-computer interaction operations.

[0015] Furthermore, a preferred embodiment is provided, in which the debugging simulation process integrates a three-dimensional graphics engine and a simulation model to construct a real-time visualization of the robot's motion status; remote access is supported, and intuitive observation and debugging operations of the robot's posture, trajectory path, and execution status information can be achieved remotely.

[0016] Furthermore, a preferred embodiment is provided, wherein the EtherCAT bus communication channel adopts a standard CoE protocol stack for data exchange; the communication content includes periodic motion control instructions, feedback data and parameter configuration; Supports the following key features: PDO mechanism: used for periodic control data exchange; SDO mechanism: used for aperiodic parameter access; Control mode support: Supports three cycle synchronization control modes in the EtherCAT specification, which can be dynamically switched according to task requirements: CSP: used for high-precision position control tasks; CSV: Suitable for trajectory following or speed driving; CST: Suitable for compliance control, force control or contact tasks.

[0017] The present invention also proposes a universal robot controller, which includes any one of the industrial robot unified control architecture systems described above.

[0018] The present invention also provides an industrial robot group control system, comprising: the universal robot controller described above, a teaching pendant connected to the universal robot controller, and first to nth robots, wherein n is a positive integer greater than or equal to 2; Each robot includes: a robotic arm body and at least one joint drive module; The universal robot controller and each joint drive module are provided with an Ethernet interface supporting the EtherCAT protocol; the controller is connected to the first joint drive module in the first robot via an Ethernet cable; the first joint drive module to the last joint drive module in the first robot to the nth robot are all connected in sequence via Ethernet cables; the last joint drive module in the preceding robot is connected to the first joint drive module in the succeeding robot among adjacent robots; The universal robot controller serves as an EtherCAT master station; the first joint drive module to the last joint drive module in the first robot to the nth robot serve as EtherCAT slave stations, and the first robot to the nth robot are group-controlled through the controller.

[0019] The present invention has the following beneficial effects: 1. The unified control architecture system for industrial robots described in this invention provides a standardized platform for industrial robots, enabling modular integration and replacement of various algorithms. It integrates six-axis industrial robots of different brands and models into a unified control system, breaking down brand barriers.

[0020] 2. The unified industrial robot control architecture system described in this invention innovatively proposes the concept of a unified industrial robot architecture (UIRA), aiming to promote the modularization, decoupling, and standardization of industrial robot control systems. By integrating the strengths of academia, industry, and individual developers, it significantly accelerates the iteration and improvement of industrial robot capabilities and the development and deployment of related functional algorithms.

[0021] The industrial robot unified control architecture system and the universal robot controller described in the present invention are suitable for integrating six-axis industrial robots of different brands and models into a unified group control system. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0023] Figure 1 This is a schematic diagram of the structure of a unified control architecture system for industrial robots in one embodiment of the present invention. DETAILED DESCRIPTION

[0024] In order to make the technical solutions and advantages of the present invention more clearly described, the specific embodiments of the present invention will be further described in detail and completely in conjunction with the accompanying drawings. The various embodiments described below are only part of the preferred embodiments of the present invention, rather than all implementation plans; the various embodiments described below are intended to explain the present invention and cannot be understood as limiting the present invention; the reasonable combination of the technical features defined in the various embodiments of the present invention, as well as all other implementation plans obtained by ordinary technicians in this field based on the embodiments of the present invention without making creative work, all fall within the scope of protection of the present invention.

[0025] Implementation 1: A unified control architecture system for industrial robots, comprising the following hierarchical structures: a real-time control kernel layer, a system process and thread structure layer, a communication mechanism layer, and a basic function module layer; wherein: The real-time control kernel layer includes: Hard real-time scheduling subsystem: built on Xenomai's Cobalt dual-core architecture; Kernel communication and interrupt isolation module: Isolation between the real-time domain and the non-real-time domain is achieved through I-Pipe and RTDM driver models; RTnet real-time network communication stack: establishes hard real-time communication links; Multi-core CPU logical core isolation module: assigns real-time tasks and non-real-time tasks to independent CPU cores; The system process and thread structure layer includes: Machine planning process: runs in the non-real-time domain and is used to handle non-hard real-time tasks at the global level of the system; Joint drive control process: runs in the real-time domain and is used for the underlying control of each robot's execution joints; Debug simulation process: runs in the non-real-time domain and is used for visual debugging and remote simulation support; The communication mechanism layer includes: EtherCAT bus communication channel: real-time communication between the system main controller and each joint driver; Real-time thread communication: periodically parses the TxPDO datagram of the slave driver and constructs the corresponding RxPDO control word to form a closed-loop feedback control chain; Remote communication interface Socket API: realizes the communication interface between the system and the host computer or simulation terminal; The basic function module layer: uses modular encapsulation to build basic function modules, deploys them in the form of dynamic link libraries, and opens them to the upper system through a unified interface standard.

[0026] In this embodiment, the real-time control kernel layer provides underlying hard real-time scheduling and interrupt management functions based on a real-time operating system (RTOS).

[0027] The real-time control kernel layer is the foundation of the unified control architecture system for industrial robots. Its core mission is to provide high-precision, low-latency, and deterministic task scheduling and interrupt management capabilities to meet the hard real-time performance requirements of industrial control scenarios. This layer is built on a real-time operating system (RTOS) and utilizes the Cobalt dual-core architecture provided by the Xenomai framework.

[0028] Under the Cobalt architecture, the system runs in two isolated kernel spaces: The Cobalt kernel is responsible for real-time task scheduling and interrupt handling; the Cobalt kernel intercepts system interrupts and prioritizes real-time processes, ensuring that the execution time of critical control tasks can be controlled in milliseconds or even microseconds, effectively avoiding system instability caused by unpredictable kernel scheduling.

[0029] The Linux kernel handles non-real-time tasks, such as UI display, data logging, etc.

[0030] In this implementation, the RTnet real-time network communication stack: To achieve high-speed and stable communication with external devices, the system introduces the RTnet (Real-Time Networking) protocol stack. This protocol stack bypasses the non-real-time path of the traditional TCP / IP network protocol and directly establishes data links in the Cobalt real-time domain, significantly improving communication delay and jitter control capabilities.

[0031] In this implementation, the system further builds on RTnet by directly accessing network hardware resources through the Real-Time Driver Model (RTDM), establishing an end-to-end real-time communication link. RTDM allows real-time threads to access underlying I / O resources such as network devices and serial ports through a unified interface, reducing context switching and improving data channel stability.

[0032] In this implementation, hard real-time refers to the system's extremely strict timing requirements. Each operation must be completed within a specified timeframe, otherwise system failure will occur. In this system, joint control cycles must be 1ms or even shorter, requiring hard real-time performance to ensure stable robot operation.

[0033] In this implementation, the system process and thread structure layer: In order to achieve stability, maintainability and high response speed of the industrial robot control system, the system establishes a multi-process architecture with clear partitions based on the real-time operating system.

[0034] In this implementation, the overall structure of the system process and thread structure layer is divided into three main processes according to real-time requirements: the whole machine planning process (non-real-time), the joint drive control process (real-time), and the debugging simulation process (non-real-time). Each process works together through a communication mechanism to ensure clear task hierarchy and stable operation: (1) Machine Planning Process (Non-real-time): This runs in the Linux non-real-time domain and is responsible for non-hard real-time tasks at the global level of the system, such as motion planning, path generation, and coordinate transformation. It is the basis for realizing high-level intelligent behavior of the robot. It integrates a trajectory planning module, a kinematics module, and a multi-robot coordination module.

[0035] Trajectory Planning Module: This module supports multiple trajectory generation methods, including a B-spline-based smooth path generation algorithm and a time-optimal jerk S-curve planning method. The generated trajectory can be directly transferred to the real-time control domain for subsequent interpolation execution.

[0036] Kinematics Module: This module performs low-level geometric operations such as forward / inverse solution calculations, Jacobian matrix calculations, and singularity avoidance, providing accurate position, velocity, acceleration, and other parameter support for the planning and control modules. This module is compatible with various industrial robot structures and is compatible with DH-based or URDF-based structural modeling methods.

[0037] Since these non-hard real-time tasks do not require sub-millisecond execution accuracy, they are deployed in the non-real-time domain to reduce the use of real-time resources. This process transmits trajectory target values, control instructions, parameter configurations, and other data to the real-time control process through a cross-domain communication interface.

[0038] (2) Joint drive control process (real-time): To ensure the high reliability and real-time response capability of the industrial robot control system, the entire system has a clear multi-process structure built on the operating system layer. The core control logic is deployed in the Cobalt real-time domain, which is responsible for the underlying control of each robot's execution joints. It integrates real-time communication threads, status monitoring threads, initialization threads, and interaction threads.

[0039] Real-time communication thread: This thread runs at the highest scheduling priority and is directly responsible for data communication with the servo drives of each joint. Using the EtherCAT master protocol, this thread sends the desired position, velocity, and torque targets to the drives at regular intervals (typically 1ms, but can be shortened to 500μs or less). It also reads feedback to ensure accurate execution of control commands.

[0040] Status Monitoring Thread: This thread continuously evaluates bus communication status, including monitoring key parameters such as node online status and server response latency. If network jitter or a server node anomaly occurs, the thread triggers an upper-layer warning or initiates an abnormality recovery mechanism.

[0041] Initialization Thread: During system startup or device reconnection, this thread automatically loads servo drive parameters and provides one-click adaptation to different manufacturers and hardware configurations (such as encoder resolution, drive mode, and message structure). This ensures the system's versatility and scalability, making it compatible with industrial robots from multiple brands and configurations.

[0042] Interactive thread: This thread receives keyboard commands from the user and implements basic human-computer interaction operations, such as start, pause, reset, and other control command input. This thread operates at a lower priority and does not affect the real-time performance of the core control tasks.

[0043] (3) Debugging simulation process (non-real-time): In addition to the real-time control process described above, the system also has an auxiliary process called debugging simulation process for visual debugging and remote simulation support. This process does not belong to the real-time domain and runs in the Linux non-real-time kernel. Its core module is the 3D simulation module, which integrates a 3D graphics engine and simulation model to construct a real-time visualization of the robot's motion state. This module supports remote access, allowing intuitive observation and debugging of information such as the robot's posture, trajectory path, and execution status from a remote location.

[0044] In this implementation, the communication mechanism layer: To ensure high-speed and stable data interaction of industrial robot systems, the control architecture is designed with a hard real-time external communication path based on the EtherCAT bus, as well as three types of internal communication mechanisms covering the real-time domain, non-real-time domain, and remote terminals, building a unified and scalable communication system.

[0045] (1) EtherCAT bus communication channel (main channel for joint control): Real-time communication between the system's main controller and each joint driver is based on the EtherCAT Industrial Ethernet protocol, using the standard CoE (CANopen over EtherCAT) protocol stack for data exchange. Communication includes periodic motion control instructions, feedback data, and parameter configuration.

[0046] The key features supported are as follows: PDO (Process Data Object) mechanism: used for periodic control data exchange, such as joint target position, current speed, current, status word, etc. The data is transmitted at high speed in a compact frame format, with a typical cycle of less than 1ms.

[0047] SDO (Service Data Object) mechanism: used for non-periodic parameter access, such as drive configuration, encoder resolution reading, initialization parameter setting, etc.

[0048] Control mode support: The system supports three cycle synchronization control modes in the EtherCAT specification, which can be dynamically switched according to task requirements: CSP (Cyclic Synchronous Position): used for high-precision position control tasks; CSV (Cyclic Synchronous Velocity): Suitable for trajectory following or velocity driving; CST (Cyclic Synchronous Torque): Suitable for smooth control, force control or contact tasks.

[0049] (2) Real-time thread communication: The slave driver's TxPDO datagram (such as status word, motor position) will be parsed periodically, and the corresponding RxPDO control word (such as target position, speed, torque) will be constructed to form a closed-loop feedback control chain.

[0050] Real-time Intra-Domain Communication Protocol IDDP: The system uses the Intra-Domain Datagram Protocol (IDDP) to enable communication between modules in the real-time domain (such as the planning and interpolation module, joint control module, and feedback acquisition module). This channel runs in the Cobalt real-time kernel domain.

[0051] Cross-domain communication protocol XDDP: To synchronize information between the real-time and non-real-time domains, the system introduces the Cross-Domain Datagram Protocol (XDDP) to complete tasks such as log collection and forwarding (for example, cycle execution time, control status) and uploading status monitoring data (temperature, current, voltage).

[0052] IDDP (Intra-Domain Datagram Protocol): Used for point-to-point data communication between modules within the same real-time processing domain, it ensures non-blocking data transmission within milliseconds, meeting the strict latency and packet loss requirements of real-time tasks such as joint control.

[0053] XDDP (Cross-Domain Datagram Protocol): Used for data transmission between real-time and non-real-time domains. It mainly carries non-strict real-time data such as logs and status information, ensuring data synchronization and coordination between different operating environments.

[0054] (3) Remote communication interface: Socket API: The system's communication interface to the host computer or simulation terminal is implemented based on the Socket API standard protocol stack, and completes command input functions such as parameter downloading, task configuration, remote debugging, and 3D simulation system status access through TCP / UDP channels.

[0055] In this implementation, the basic functional module layer: To support stable operation and efficient development of industrial robot systems across multiple application scenarios and cross-brand equipment, the system employs a modular functional encapsulation mechanism, dividing key control logic and device adaptation functions into eight basic functional modules. These modules are deployed as dynamic link libraries (.so) and are accessible to upper-level systems through unified interface standards (including C++ interface export functions and version consistency verification). Each module has clear responsibilities, high cohesion, and low coupling, allowing for independent deployment, replacement, and expansion, facilitating system portability and maintenance in real-world projects.

[0056] In this embodiment, the system adopts modular packaging to construct basic functional modules with independent functions and unified interfaces, supporting the collaborative development of upper-level tasks and rapid adaptation of multi-brand servo systems.

[0057] The basic functional modules include: data transmission module, system monitoring module, servo management module, drive control module, IO control module, trajectory planning module, kinematics module and motion control module.

[0058] in: Data transmission module: realizes cross-domain data synchronization and message forwarding; System monitoring module: collects bus and motor operating status for health diagnosis; Servo management module: supports identification, configuration and control mode switching of multi-brand drives; Drive control module: realize joint-level closed-loop control based on PDO / SDO; IO control module: supports unified acquisition and control of analog and digital quantities; Trajectory planning module: generates smooth and controllable B-spline paths; Kinematics module: provides forward and inverse solutions and singularity obstacle avoidance functions; Motion control module: Integrates dynamic compensation and vibration suppression mechanisms to achieve high-speed and high-precision trajectory tracking.

[0059] It should be noted that existing industrial robot systems generally adopt a closed technical architecture, and each brand relies on private controllers and customized hardware interfaces, resulting in the need to develop an additional adaptation layer for cross-platform collaboration, which is time-consuming and has poor compatibility.

[0060] Currently, there are no mature, publicly available technical documents or industrial products that enable seamless integration and control of six-axis industrial robots from more than five different brands. While some research platforms have explored preliminary frameworks for multi-robot control, a universal test matrix covering diverse loads, structures, and brands remains lacking, significantly limiting verification methods.

[0061] The proposed Unified Industrial Robot Control Architecture (UIRA) system utilizes the EtherCAT unified communication protocol and standardized interfaces to interconnect six six-axis robots from six different brands. It can handle payloads ranging from 15 to 200 kg and increase algorithm reuse to 80%. Based on the Xenomai dual-core and RTnet real-time network, control cycle jitter is reduced to less than 20 microseconds. Support for algorithm module encapsulation shortens secondary development cycles by 70%.

[0062] In this embodiment, the industrial robot unified control architecture system is a unified architecture and implementation method for multi-brand six-axis industrial robot control systems, aiming to achieve software and hardware decoupling, modular integration and rapid algorithm deployment across multiple industrial robot brand controllers, and accelerate technological collaboration and capacity improvement in the industrial robot industry.

[0063] Specifically, by establishing a unified control architecture, a standardized platform can be provided for industrial robots, enabling modular integration and replacement of various functional algorithms. Under this unified control architecture, industrial robots of different brands can abstract the underlying hardware through a unified communication protocol and hardware interface. UIRA has designed a universal controller and combined it with a socket interface based on the Xenomai real-time kernel to build a cross-brand and cross-system communication API, achieving modular decoupling of core functions such as motion control and path planning. This design separates hardware drivers from functional logic, freeing algorithm developers from having to focus on the underlying driver details of robots from different brands. Instead, they can focus on developing and optimizing the algorithm itself, significantly shortening the secondary development cycle and improving the system's development efficiency and maintainability.

[0064] By applying UIRA to the field of industrial robots and integrating the experimental platforms of multiple industrial robot companies, a six-axis robot test matrix covering loads of 15-200kg has been formed; statistics show that UIRA can significantly shorten the average R&D cycle.

[0065] Implementation 2: A universal robot controller, wherein the controller includes the industrial robot unified control architecture system described above.

[0066] Embodiment 3: An industrial robot group control system, comprising: the universal robot controller described above, a teaching pendant connected to the universal robot controller, and robots 1 to 2, where n is a positive integer greater than or equal to 2; Each robot includes: a robotic arm body and at least one joint drive module; The universal robot controller and each joint drive module are provided with an Ethernet interface supporting the EtherCAT protocol; the controller is connected to the first joint drive module in the first robot via an Ethernet cable; the first joint drive module to the last joint drive module in the first robot to the nth robot are all connected in sequence via Ethernet cables; the last joint drive module in the preceding robot is connected to the first joint drive module in the succeeding robot among adjacent robots; The universal robot controller serves as an EtherCAT master station; the first joint drive module to the last joint drive module in the first robot to the nth robot serve as EtherCAT slave stations, and the first robot to the nth robot are group-controlled through the controller.

[0067] The above further describes the technical solution provided by the present invention in detail through several specific embodiments in order to highlight the advantages and benefits of the technical solution provided by the present invention. However, the several specific embodiments described above are not intended to limit the present invention. Any reasonable changes and improvements to the present invention, reasonable combinations of implementation methods and equivalent replacements based on the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. The unified control architecture system for industrial robots is characterized by: The system includes the following hierarchical structures: real-time control kernel layer, system process and thread structure layer, communication mechanism layer and basic function module layer; wherein: The real-time control kernel layer includes: Hard real-time scheduling subsystem: built on Xenomai's Cobalt dual-core architecture; Kernel communication and interrupt isolation module: Isolation between the real-time domain and the non-real-time domain is achieved through I-Pipe and RTDM driver models; RTnet real-time network communication stack: establishes hard real-time communication links; Multi-core CPU logical core isolation module: assigns real-time tasks and non-real-time tasks to independent CPU cores; The system process and thread structure layer includes: Machine planning process: runs in the non-real-time domain and is used to handle non-hard real-time tasks at the global level of the system; Joint drive control process: runs in the real-time domain and is used for the underlying control of each robot's execution joints; Debug simulation process: runs in the non-real-time domain and is used for visual debugging and remote simulation support; The communication mechanism layer includes: EtherCAT bus communication channel: real-time communication between the system main controller and each joint driver; Real-time thread communication: periodically parses the TxPDO datagram of the slave driver and constructs the corresponding RxPDO control word to form a closed-loop feedback control chain; Remote communication interface Socket API: realizes the communication interface between the system and the host computer or simulation terminal; The basic function module layer: uses modular encapsulation to build basic function modules, deploys them in the form of dynamic link libraries, and opens them to the upper system through a unified interface standard.

2. The industrial robot unified control architecture system according to claim 1, characterized in that: The basic functional modules include: data transmission module, system monitoring module, servo management module, drive control module, IO control module, trajectory planning module, kinematics module and motion control module; Data transmission module: realizes cross-domain data synchronization and message forwarding; System monitoring module: collects bus and motor operating status for health diagnosis; Servo management module: supports identification, configuration and control mode switching of multi-brand drives; Drive control module: realize joint-level closed-loop control based on PDO / SDO; IO control module: supports unified acquisition and control of analog and digital quantities; Trajectory planning module: generates smooth and controllable B-spline paths; Kinematics module: provides forward and inverse solutions and singularity obstacle avoidance functions; Motion control module: Integrates dynamic compensation and vibration suppression mechanisms to achieve high-speed and high-precision trajectory tracking.

3. The industrial robot unified control architecture system according to claim 1, characterized in that: In the hard real-time scheduling subsystem: In the Cobalt dual-kernel architecture, the system runs in two isolated kernel spaces: The Cobalt kernel is responsible for real-time task scheduling and interrupt handling; The Linux kernel handles non-real-time tasks.

4. The industrial robot unified control architecture system according to claim 1, characterized in that: The RTnet real-time network communication stack bypasses the non-real-time path of the traditional TCP / IP network protocol and directly establishes a data link in the Cobalt real-time domain, thereby improving communication delay and jitter control capabilities.

5. The industrial robot unified control architecture system according to claim 1, characterized in that: The whole machine planning process includes a trajectory planning module and a kinematics module; Trajectory planning module: supports multiple trajectory generation methods, and the generated trajectory is directly transferred to the real-time control domain for subsequent interpolation execution; Kinematics module: responsible for low-level geometric operations.

6. The industrial robot unified control architecture system according to claim 1, characterized in that: The joint drive control process includes a real-time communication thread, a status monitoring thread, an initialization thread and an interaction thread; Real-time communication thread: runs at the highest scheduling priority and is used for direct data communication with the servo drives of each joint; Status monitoring thread: used to continuously evaluate the bus communication status; Initialization thread: During system startup or device reconnection, it is used to automatically load servo drive parameters and complete one-click adaptation based on different manufacturers and hardware configurations; Interactive thread: used to receive keyboard commands from the user and implement basic human-computer interaction operations.

7. The industrial robot unified control architecture system according to claim 1, characterized in that: The debugging simulation process integrates a three-dimensional graphics engine and a simulation model to construct a real-time visualization of the robot's motion status; it supports remote access, enabling intuitive observation and debugging operations of the robot's posture, trajectory path, and execution status information at a remote location.

8. The industrial robot unified control architecture system according to claim 1, characterized in that: The EtherCAT bus communication channel uses the standard CoE protocol stack for data exchange; the communication content includes periodic motion control instructions, feedback data and parameter configuration; Supports the following key features: PDO mechanism: used for periodic control data exchange; SDO mechanism: used for aperiodic parameter access; Control mode support: Supports three cycle synchronization control modes in the EtherCAT specification, which can be dynamically switched according to task requirements: CSP: used for high-precision position control tasks; CSV: Suitable for trajectory following or speed driving; CST: Suitable for compliance control, force control or contact tasks.

9. Universal robot controller, characterized in that, The controller includes the industrial robot unified control architecture system according to any one of claims 1 to 8. 10.Industrial robot group control system, characterized by: include: The universal robot controller according to claim 9, a teaching pendant connected to the universal robot controller, and first to nth robots, wherein n is a positive integer greater than or equal to 2; Each robot includes: a robotic arm body and at least one joint drive module; The universal robot controller and each joint drive module are provided with an Ethernet interface supporting the EtherCAT protocol; the controller is connected to the first joint drive module in the first robot via an Ethernet cable; the first joint drive module to the last joint drive module in the first robot to the nth robot are all connected in sequence via Ethernet cables; the last joint drive module in the preceding robot is connected to the first joint drive module in the succeeding robot among adjacent robots; The universal robot controller serves as an EtherCAT master station; the first joint drive module to the last joint drive module in the first robot to the nth robot serve as EtherCAT slave stations, and the first robot to the nth robot are group-controlled through the controller.

Images