Control system and method of mining equipment, related equipment and mining equipment

Abstract

The invention provides a control system and method of mining equipment, related equipment of the control system and the mining equipment. The control system comprises a lower computer, an upper computer and a heterogeneous communication link. Wherein the lower computer is connected with the execution mechanism and the sensor group, and the lower computer is used for receiving sensor data of the sensor group and a control instruction of the upper computer, sending the control instruction of the execution mechanism to the execution mechanism and sending the sensor data to the upper computer; the upper computer is connected with the lower computer through a heterogeneous communication link, and the upper computer is used for receiving sensor data sent by the lower computer, determining a control instruction based on the sensor data and sending the control instruction to the lower computer; and the upper computer and the lower computer adopt different communication protocols. Complex data processing and global decision tasks are concentrated on an upper computer, and high-real-time signal acquisition and mechanism driving tasks are distributed to a lower computer, so that the technical contradiction that a single controller is difficult to consider both calculation performance and real-time response at the same time is solved.

Description

Technical Field

[0001] This application relates to the field of mining equipment technology, and more specifically, to a control system, method and related equipment for mining equipment, and mining equipment. Background Technology

[0002] With the deepening of intelligent coal mine construction, fully mechanized mining faces are gradually evolving from traditional mechanized mining to an intelligent collaborative mode of "less manned and unmanned" operation. As the main support structure of fully mechanized mining faces, hydraulic supports' electro-hydraulic control systems not only undertake core tasks such as supporting the roof and moving scraper conveyors, but also need to perform complex collaborative operations with equipment such as coal mining machines, scraper conveyors, and inspection robots. Current fully mechanized mining automation technology is no longer limited to the execution of single machine actions, but places extremely high demands on the adaptive control of support groups, the accuracy of attitude perception, and the real-time data interaction between heterogeneous devices. This signifies that hydraulic supports are transforming into "robotic equipment with perception and decision-making capabilities."

[0003] However, most existing electro-hydraulic control systems for hydraulic supports adopt traditional closed embedded architectures. A typical implementation uses an STM32 (ST Microelectronics 32-bit ARM Cortex-M MCU), a DSP (Digital Signal Processor), or a dedicated industrial MCU (Microcontroller Unit) as the core controller, running bare-metal programs or lightweight real-time operating systems (such as uCOS or FreeRTOS). Communication between support controllers primarily occurs via CAN bus (Controller Area Network), RS485 (Recommended Standard 485), or proprietary industrial Ethernet protocols. At the software development level, a tightly coupled programming model based on a specific hardware platform is typically employed, with control logic, drivers, and communication protocols highly bound together. Each manufacturer generally defines its own proprietary application layer protocols to achieve inter-support control and status updates.

[0004] Therefore, a control system, method, and related equipment and mining equipment for mining equipment that can break through technical barriers, achieve seamless integration of heterogeneous equipment, and have high software reusability has become a key technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] This application aims to address at least one of the technical problems existing in the prior art or related technologies.

[0006] Therefore, the first aspect of this application provides a control system for mining equipment.

[0007] The second aspect of this application provides a method for controlling mining equipment.

[0008] A third aspect of this application provides an electronic device.

[0009] A fourth aspect of this application provides a readable storage medium.

[0010] The fifth aspect of this application provides a mining apparatus.

[0011] In view of this, the first aspect of this application proposes a control system for mining equipment. The mining equipment includes a control system, an actuator, and a sensor group. The control system includes a lower-level machine, a higher-level machine, and a heterogeneous communication link. The lower-level machine is connected to the actuator and the sensor group. The lower-level machine is used to receive sensor data from the sensor group and control commands from the higher-level machine, send control commands to the actuator, and send sensor data to the higher-level machine. The higher-level machine is connected to the lower-level machine via the heterogeneous communication link. The higher-level machine is used to receive sensor data sent by the lower-level machine, determine control commands based on the sensor data, and send the control commands to the lower-level machine. The higher-level machine and the lower-level machine are configured with different communication protocols. The heterogeneous communication link is used to bidirectionally convert data between the higher-level machine and the lower-level machine using different communication protocols.

[0012] The control system for mining equipment proposed in this application is applied to mining equipment that includes actuators (such as solenoid valve groups of hydraulic supports) and sensor groups (such as pressure, stroke, and tilt sensors). The core of the system includes a lower-level machine, a higher-level machine, and a heterogeneous communication link. The lower-level machine is directly connected to the actuators and sensor groups, responsible for receiving raw data collected by the sensor groups and receiving final control commands from the higher-level machine, thereby driving the actuators to move; simultaneously, the lower-level machine uploads the collected sensor data. The higher-level machine is connected to the lower-level machine via the heterogeneous communication link, responsible for receiving and processing all sensor data uploaded by the lower-level machine, executing decision-making algorithms such as group control collaboration based on this data, generating control commands, and sending the commands to the corresponding lower-level machines. The control system for mining equipment, by establishing a higher-level machine and a lower-level machine, which use different communication protocols and are connected via a heterogeneous communication link, constructs a control system architecture that separates decision-making from execution. This architecture centralizes complex data processing and global decision-making tasks on the host computer, while allocating high-real-time signal acquisition and mechanism driving tasks to the slave computer. This effectively solves the technical contradiction that a single controller cannot simultaneously balance computing performance and real-time response, laying a structural foundation for the system to achieve intelligent collaborative control.

[0013] In any of the above technical solutions, optionally, the host computer runs the ROS2 operating system (Robot Operating System 2) and deploys the MicroROS agent service, while the slave computer runs a real-time operating system and integrates the MicroROS client library; the heterogeneous communication link is established based on the XRCE-DDS protocol (DDS for eXtremelyResource Constrained Environments), so that the slave computer is mapped as a standard node in the ROS2 operating system network.

[0014] In these technical solutions, the host computer serves as the core of the ROS2 network, and its ROS2 operating system provides a distributed communication framework. The MicroROS agent service deployed on the host computer acts as a protocol conversion gateway. The real-time operating system running on the slave computer ensures the hard real-time performance of control tasks, while its integrated MicroROS client library encapsulates local functions into ROS2 interfaces. The heterogeneous communication link connecting the host and slave computers uses the XRCE-DDS protocol for data serialization and transmission, optimized for resource-constrained environments. Through this architecture, the slave computer can publish sensor data topics and subscribe to control command topics as a standard ROS2 node. The host computer runs the ROS2 operating system and deploys the MicroROS agent service, while the slave computer runs a real-time operating system and integrates the MicroROS client library; the heterogeneous communication link is established based on the XRCE-DDS protocol. This solution logically maps each physical slave controller to a standard node in the ROS2 network, achieving seamless integration of embedded devices and the robot operating system. It solves the problems of proprietary protocols and difficulty in interoperability with advanced robot ecosystems in traditional industrial control systems, significantly improving the system's openness and scalability.

[0015] In any of the above technical solutions, optionally, the lower-level machine uses an STM32 series microcontroller as an embedded controller; the upper-level machine uses an RK3568 industrial control board, a PC (Personal Computer) server, or a server with a Windows WSL / Ubuntu virtual machine deployed as a computing platform.

[0016] In these technical solutions, the lower-level machine uses an STM32 series microcontroller as an embedded controller. This controller is responsible for directly connecting to the sensor array and actuators, running a real-time operating system to ensure millisecond-level response of control commands. The upper-level machine, as the decision-making center, can be deployed at the edge using an RK3568 industrial control board based on the ARM architecture (Advanced RISC Machine), or at the central control center using a PC server based on the x86 architecture. It can even deploy ROS2 on a Windows system via the WSL subsystem or a virtual machine running an Ubuntu environment. This flexibility adapts to the computing power and deployment requirements of different application scenarios. The lower-level machine is specified to use an STM32 series microcontroller, while the upper-level machine can use an RK3568 industrial control board, a PC server, or a server with a Windows WSL / Ubuntu virtual machine deployed. This solution combines the maturity, low power consumption, and cost advantages of STM32 in real-time control with the high performance of the RK3568 or x86 platform in complex computing tasks, forming a cost-effective heterogeneous computing power combination that enables the system to possess both powerful edge computing capabilities and reliable low-level control capabilities.

[0017] In any of the above technical solutions, optionally, the physical transmission medium supported by the heterogeneous communication link includes UART (Universal Asynchronous Receiver / Transmitter) serial port, CAN-FD bus (CAN Flexible Data-rate) or industrial Ethernet.

[0018] In these technical solutions, the physical layer implementation of heterogeneous communication links is diverse. For point-to-point or short-distance communication, a general-purpose UART asynchronous serial port can be used. For scenarios requiring the connection of multiple lower-level machines to form a bus-type network, a CAN-FD bus with error detection and priority arbitration mechanisms can be used. For applications with high bandwidth and stringent real-time requirements, industrial Ethernet can be selected as the physical medium to ensure large-scale data transmission and low-latency control. The physical transmission media that can be used for heterogeneous communication links include UART serial ports, CAN-FD buses, or industrial Ethernet. This solution provides flexibility to adapt to different field environments and performance requirements: UART serial ports are simple to implement, CAN-FD buses have high reliability and multi-node networking capabilities, and industrial Ethernet provides high bandwidth and low latency, ensuring that the XRCE-DDS protocol has a stable and reliable physical carrier under various operating conditions, enhancing the system's engineering applicability.

[0019] The second aspect of this application provides a control method for mining equipment, comprising: a system initialization and communication establishment step: establishing a communication connection between a host computer and a slave computer; a data acquisition and distribution step: the slave computer acquires sensor data from a sensor group and sends the sensor data to the host computer; a decision-making and instruction issuance step: the host computer generates control instructions based on the received sensor data and sends the control instructions to the slave computer; and an execution step: the slave computer receives and parses the control instructions and drives the actuator to move.

[0020] In these technical solutions, a communication connection is established between the host computer and the slave computer. Next, the data acquisition and distribution step begins, where the slave computer periodically collects sensor data (such as pressure values) from the connected temperature sensor group and sends this data to the host computer. In the decision-making and command issuance step, the host computer aggregates all slave computer data, runs the control algorithm, generates control commands (such as column raising and lowering commands), and sends the commands to the target slave computer. Finally, in the execution step, the slave computer receives and parses the commands, drives the connected actuators (such as solenoid valves) to complete the control closed loop. This covers the entire process from communication establishment, data acquisition, decision-making to execution. This method achieves the collaborative operation of distributed control through process-oriented steps, enabling the host computer to make optimized decisions based on global information, while the slave computer focuses on precise local execution. The method logic is clear, ensuring the orderliness and reliability of the mining equipment control process. A control system architecture separating decision-making and execution is constructed using heterogeneous communication links. This architecture centralizes complex data processing and global decision-making tasks on the host computer, while allocating high-real-time signal acquisition and mechanism driving tasks to the slave computer. This effectively solves the technical contradiction that a single controller cannot simultaneously balance computing performance and real-time response, laying a structural foundation for the system to achieve intelligent collaborative control.

[0021] In any of the above technical solutions, optionally, in the system initialization and communication establishment steps, the host computer starts the agent service, and the slave computer powers on and sends a connection request to establish a session; in the data acquisition and publishing steps, the slave computer encapsulates the acquired sensor data into a standard message format and sends it through its integrated client library; in the decision-making and command issuance steps, the host computer converts the generated control commands into a format recognizable by the slave computer through the agent service and then issues them; wherein, the communication between the host computer and the slave computer is based on a preset communication protocol.

[0022] In these technical solutions, during system initialization and communication establishment, the host computer initiates a proxy service. After powering on, the slave device sends a connection request to this proxy service to establish a stable session. During data acquisition and publishing, the slave device does not directly send raw data; instead, it encapsulates the acquired sensor data into a standard message format using its integrated client library before sending it. In the decision-making and command issuance steps, the control commands generated by the host computer also need to be converted into a format directly recognizable by the slave device hardware via the proxy service before being issued. The entire communication process is based on a preset communication protocol for data exchange. This involves establishing a session through the proxy service, encapsulating data using the client library, converting commands through the proxy service, and communicating based on the preset communication protocol. This solution realizes the core links of standardized data interaction between heterogeneous devices, providing a connection for integrating specific technical solutions (such as MicroROS) into the methodology, and ensuring the standardization and feasibility of the communication process.

[0023] In any of the above technical solutions, optionally, the proxy service is the MicroROS proxy service, the client library is the MicroROS client library, and the preset communication protocol is the XRCE-DDS protocol.

[0024] In these technical solutions, the proxy service is the MicroROS proxy service, deployed on the host computer, responsible for bridging the standard ROS2 network and the slave device. The client library is the MicroROS client library, integrated on the slave device, used to adapt the local application interface to the ROS2 interface. The preset communication protocol is the XRCE-DDS protocol, which serves as the rules for data expression and transmission, carrying the messages processed by the MicroROS client library and the proxy service. Specifically, it consists of the MicroROS proxy service, the MicroROS client library, and the XRCE-DDS protocol. This solution clarifies the specific technical toolchain for integrating embedded devices with the ROS2 ecosystem. Through the MicroROS framework and the XRCE-DDS protocol, it effectively solves the problem of resource-constrained slave devices accessing the standard ROS2 distributed communication environment, achieving transparent and reliable transmission of control commands and sensor data between heterogeneous platforms.

[0025] A third aspect of this application provides an electronic device including a memory and a processor, the memory storing a program or instructions executable on the processor, the program or instructions, when executed by the processor, implementing the steps of the control method for the mining equipment provided in the second aspect.

[0026] The fourth aspect of this application provides a readable storage medium having a program and / or instructions stored thereon, which, when executed by a processor, implement the steps of the control method for the mining equipment provided in the second aspect.

[0027] The fifth aspect of this application provides a mining apparatus, including a control system, actuators, and sensor array as provided in the first aspect of the mining apparatus.

[0028] Additional aspects and advantages of this application will become apparent in the following description or may be learned by practice of this application. Attached Figure Description

[0029] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which:

[0030] Figure 1 This is a block diagram of a control system for a mining equipment according to an embodiment of this application;

[0031] Figure 2 This is one of the flowcharts illustrating a control method for a mining equipment according to an embodiment of this application;

[0032] Figure 3 This is a block diagram of an electronic device according to an embodiment of this application;

[0033] Figure 4 This is one of the structural schematic diagrams of a mining equipment according to an embodiment of this application;

[0034] Figure 5 This is a second schematic diagram of the structure of a mining equipment according to an embodiment of this application;

[0035] Figure 6 This is a second schematic flowchart of a control method for a mining equipment according to an embodiment of this application.

[0036] Among them, 1 is mining equipment, 100 is the control system of mining equipment, 101 is the lower-level machine, 102 is the upper-level machine, 103 is the heterogeneous communication link, 10 is the actuator, and 12 is the sensor group. Detailed Implementation

[0037] To better understand the above-mentioned objectives, features, and advantages of this application, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.

[0038] Many specific details are set forth in the following description in order to provide a full understanding of this application. However, this application may also be implemented in other ways different from those described herein. Therefore, the scope of protection of this application is not limited to the specific embodiments disclosed below.

[0039] The following is combined with, for example Figure 1 and Figure 4To further illustrate this embodiment, a control system 100 for mining equipment is provided. The mining equipment 1 includes a control system 100, an actuator 10, and a sensor group 12. The control system includes a lower-level machine 101, a higher-level machine 102, and a heterogeneous communication link 103. The lower-level machine 101 is connected to the actuator 10 and the sensor group 12. The lower-level machine 101 receives sensor data from the sensor group 12 and control commands from the higher-level machine 102, sends control commands to the actuator 10, and sends sensor data to the higher-level machine 102. The higher-level machine 102 is connected to the lower-level machine 101 via the heterogeneous communication link 103. The higher-level machine 102 receives sensor data sent by the lower-level machine 101, determines control commands based on the sensor data, and sends the control commands to the lower-level machine 101. The higher-level machine 102 and the lower-level machine 101 are configured with different communication protocols. The heterogeneous communication link 103 is used to bidirectionally convert data between the higher-level machine 102 and the lower-level machine 101 using different communication protocols.

[0040] The control system 100 for mining equipment according to this application is applied to mining equipment 1 that includes actuators 10 (such as solenoid valve groups of hydraulic supports) and sensor groups 12 (such as pressure, stroke, and tilt sensors). The core of the system includes a lower-level machine 101, a higher-level machine 102, and a heterogeneous communication link 103. The lower-level machine 101 is directly connected to the actuators 10 and the sensor groups 12, and is responsible for receiving the raw data collected by the sensor groups 12 and receiving the final control commands from the higher-level machine 102, thereby driving the actuators 10 to move; at the same time, the lower-level machine 101 uploads the collected sensor data. The higher-level machine 102 is connected to the lower-level machine 101 through the heterogeneous communication link 103, and is responsible for receiving and processing all the sensor data uploaded by the lower-level machine 101, executing decision-making algorithms such as group control collaboration based on this data, generating control commands, and sending the commands to the corresponding lower-level machines 101. The control system 100 of the mining equipment establishes a host computer 102 and a slave computer 101, connected by a heterogeneous communication link 103, thus constructing a control system architecture that separates decision-making and execution. This architecture concentrates complex data processing and global decision-making tasks on the host computer 102, while allocating high-real-time signal acquisition and mechanism driving tasks to the slave computer 101. This effectively solves the technical contradiction that a single controller cannot simultaneously balance computing performance and real-time response, laying a structural foundation for the system to achieve intelligent collaborative control.

[0041] In any of the above technical solutions, optionally, the host computer 102 runs the ROS2 operating system and deploys the MicroROS agent service, and the slave computer 101 runs a real-time operating system and integrates the MicroROS client library; the heterogeneous communication link 103 is established based on the XRCE-DDS protocol, so that the slave computer 101 is mapped as a standard node in the ROS2 operating system network.

[0042] In these technical solutions, the host computer 102 serves as the core of the ROS2 network, and its ROS2 operating system provides a distributed communication framework. The MicroROS agent service deployed on the host computer 102 acts as a protocol conversion gateway. The real-time operating system running on the slave computer 101 ensures the hard real-time performance of control tasks, and its integrated MicroROS client library is responsible for encapsulating local functions into ROS2 interfaces. The heterogeneous communication link 103 connecting the host computer 102 and the slave computer 101 uses the XRCE-DDS protocol for data serialization and transmission, which is optimized for resource-constrained environments. Through this architecture, the slave computer 101 can publish sensor data topics and subscribe to control command topics in the form of a standard ROS2 node. The host computer 102 runs the ROS2 operating system and deploys the MicroROS agent service, while the slave computer 101 runs the real-time operating system and integrates the MicroROS client library. The heterogeneous communication link 103 is established based on the XRCE-DDS protocol. This solution logically maps each physical lower-level 101 controller to a standard node in the ROS2 network, achieving seamless integration between embedded devices and the robot operating system. It solves the problems of proprietary protocols in traditional industrial control systems and difficulty in interconnecting with advanced robot ecosystems, significantly improving the openness and scalability of the system.

[0043] In any of the above technical solutions, optionally, the lower-level machine 101 uses an STM32 series microcontroller as an embedded controller; the upper-level machine 102 uses an RK3568 industrial control board, a PC server, or a server with Windows WSL / Ubuntu virtual machines deployed as a computing platform.

[0044] In these technical solutions, the lower-level computer 101 uses an STM32 series microcontroller as an embedded controller. This controller is responsible for directly connecting to the sensor group 12 and the actuator 10, and running a real-time operating system to ensure millisecond-level response of control commands. The upper-level computer 102, as the decision-making center, can be deployed at the edge using an RK3568 industrial control board based on the ARM architecture, or at the central control center using a PC server based on the x86 architecture. It can even deploy ROS2 on a Windows system via the WSL subsystem or a virtual machine running an Ubuntu environment. This flexibility adapts to the computing power and deployment requirements of different application scenarios. The lower-level computer 101 is specified to use an STM32 series microcontroller, while the upper-level computer 102 can use an RK3568 industrial control board, a PC server, or a server with a Windows WSL / Ubuntu virtual machine deployed. This solution combines the maturity, low power consumption, and cost advantages of STM32 in the field of real-time control with the high performance of RK3568 or X86 platforms in complex computing tasks, forming a cost-effective heterogeneous computing power combination that enables the system to have both powerful edge computing capabilities and reliable low-level control capabilities.

[0045] In any of the above technical solutions, the physical transmission medium supported by the heterogeneous communication link 103 may optionally include UART serial port, CAN-FD bus or industrial Ethernet.

[0046] In these technical solutions, the physical layer implementation of the heterogeneous communication link 103 is diverse. For point-to-point or short-distance communication, a general-purpose UART asynchronous serial port can be used. For scenarios requiring the connection of multiple lower-level machines 101 to form a bus-type network, a CAN-FD bus with error detection and priority arbitration mechanisms can be used. For applications with high bandwidth and stringent real-time requirements, industrial Ethernet can be selected as the physical medium to ensure large-scale data transmission and low-latency control. The physical transmission media that the heterogeneous communication link 103 can use include UART serial port, CAN-FD bus, or industrial Ethernet. This solution provides flexibility to adapt to different field environments and performance requirements: the UART serial port is simple to implement, the CAN-FD bus has high reliability and multi-node networking capabilities, and the industrial Ethernet provides high bandwidth and low latency, ensuring that the XRCE-DDS protocol has a stable and reliable physical carrier under various operating conditions, enhancing the system's engineering applicability.

[0047] The second aspect of this application provides a method for controlling mining equipment, such as... Figure 2 As shown, it includes:

[0048] S201: System initialization and communication establishment steps: Establish a communication connection between the host computer and the slave computer;

[0049] S202: Data Acquisition and Publishing Steps: The lower-level computer acquires sensor data from the sensor group and sends the sensor data to the upper-level computer;

[0050] S203: Decision-making and command issuance steps: The host computer generates control commands based on the received sensor data and sends the control commands to the slave computer;

[0051] S204: Execution steps: The lower-level machine receives and parses the control command and drives the actuator to move.

[0052] In these technical solutions, a communication connection is established between the host computer 102 and the slave computer 101. Next, in the data acquisition and distribution step, the slave computer 101 periodically acquires sensor data (such as pressure values) from the connected temperature sensor group 12 and sends this data to the host computer 102. In the decision-making and command issuance step, the host computer 102 aggregates all data from the slave computers 101, runs the control algorithm, generates control commands (such as column raising and lowering commands), and sends the commands to the target slave computer 101. Finally, in the execution step, the slave computer 101 receives and parses the commands, drives the connected actuator 10 (such as a solenoid valve) to actuate, and completes the control closed loop. This covers the complete process from communication establishment, data acquisition, decision-making to execution. This method achieves the collaborative operation of distributed control through streamlined steps, enabling the host computer 102 to make optimized decisions based on global information, while the slave computer 101 focuses on precise local execution. The method logic is clear, ensuring the orderliness and reliability of the control process of the mining equipment 1. By utilizing heterogeneous communication links 103, a control system architecture that separates decision-making and execution was constructed. This architecture centralizes complex data processing and global decision-making tasks on the host computer 102, while allocating high-real-time signal acquisition and mechanism driving tasks to the slave computer 101. This effectively solves the technical contradiction that a single controller cannot simultaneously balance computational performance and real-time response, laying a structural foundation for the system to achieve intelligent collaborative control.

[0053] In any of the above technical solutions, optionally, in the system initialization and communication establishment steps, the host computer starts the agent service, and the slave computer powers on and sends a connection request to establish a session; in the data acquisition and publishing steps, the slave computer encapsulates the acquired sensor data into a standard message format and sends it through its integrated client library; in the decision-making and command issuance steps, the host computer converts the generated control commands into a format recognizable by the slave computer through the agent service and then issues them; wherein, the communication between the host computer and the slave computer is based on a preset communication protocol.

[0054] In these technical solutions, during system initialization and communication establishment, the host computer 102 initiates a proxy service, and the slave computer 101, after powering on, sends a connection request to this proxy service to establish a stable session. During data acquisition and publishing, the slave computer 101 does not directly send raw data, but instead encapsulates the acquired sensor data into a standard message format using its integrated client library before sending it. During decision-making and command issuance, the control commands generated by the host computer 102 also need to be converted into a format directly recognizable by the slave computer 101 hardware through the proxy service before being issued. The entire communication process is based on a preset communication protocol for data exchange. This involves establishing a session through the proxy service, encapsulating data using the client library, converting commands through the proxy service, and communicating based on the preset communication protocol. This solution abstracts the core elements for achieving standardized data interaction between heterogeneous devices, providing a connection for integrating specific technical solutions (such as MicroROS) into the methodology, and ensuring the standardization and feasibility of the communication process.

[0055] In any of the above technical solutions, optionally, the proxy service is the MicroROS proxy service, the client library is the MicroROS client library, and the preset communication protocol is the XRCE-DDS protocol.

[0056] In these technical solutions, the proxy service is the MicroROS proxy service, deployed on the host computer 102, responsible for bridging the standard ROS2 network and the slave computer 101. The client library is the MicroROS client library, integrated into the slave computer 101, used to adapt the local application interface to the ROS2 interface. The preset communication protocol is the XRCE-DDS protocol, which serves as the rules for data expression and transmission, carrying the messages processed by the MicroROS client library and the proxy service. Specifically, it consists of the MicroROS proxy service, the MicroROS client library, and the XRCE-DDS protocol. This solution clarifies the specific technical toolchain for integrating embedded devices with the ROS2 ecosystem. Through the MicroROS framework and the XRCE-DDS protocol, it effectively solves the problem of resource-constrained slave computer 101 accessing the standard ROS2 distributed communication environment, achieving transparent and reliable transmission of control commands and sensor data between heterogeneous platforms.

[0057] like Figure 3 As shown, a third aspect of this application provides an electronic device 300, including a memory 302 and a processor 304. The memory 302 stores programs or instructions that can run on the processor 304. When the programs or instructions are executed by the processor 304, they implement the steps of the control method for the mining equipment provided in the second aspect.

[0058] The fourth aspect of this application provides a readable storage medium having a program and / or instructions stored thereon, which, when executed by a processor, implement the steps of the control method for the mining equipment provided in the second aspect.

[0059] like Figure 4 As shown, the fifth aspect of this application provides a mining equipment 1, including a control system 100, an actuator 10, and a sensor group 12 as provided in the first aspect of the mining equipment.

[0060] This invention provides a distributed control system for a fully mechanized mining support robot based on the MicroROS-ROS2 heterogeneous architecture. It breaks through the limitations of the traditional closed embedded architecture, adopts a layered heterogeneous design, decouples the high computing power decision layer from the high real-time control layer, and achieves seamless integration between the underlying embedded device and the upper robot operating system through the MicroROS middleware.

[0061] Specifically, such as Figure 5 and Figure 6 As shown, the technical solution adopted by the present invention includes the following aspects:

[0062] First, a heterogeneous hardware architecture with separation of "decision-execution" was constructed.

[0063] The system is divided into a higher-level decision-making layer and a lower-level execution layer.

[0064] The upper-level decision-making layer (Host) employs a high-performance computing platform (such as an RK3568 industrial control board, a PC, or a server with Windows WSL / Ubuntu virtual machines deployed), running a full version of the ROS2 (Robot Operating System 2) operating system. This layer acts as the "brain" of the system, deploying MicroROSAgent agent nodes and swarm control and coordination algorithms, and is responsible for handling complex logical operations, data visualization, and global scheduling tasks.

[0065] The lower-level execution layer (Client) employs a low-power embedded controller (such as an STM32 series MCU), runs a real-time operating system (such as FreeRTOS) and the MicroROSClient static library. This layer acts as the "joint" of the system, responsible for driving the solenoid valves of the hydraulic support, acquiring sensor data, and providing millisecond-level real-time control.

[0066] Second, implement node mapping for embedded devices based on MicroROS.

[0067] This invention introduces a MicroROS client library into the lower-level controller 101, encapsulating the sensor data (pressure, stroke, tilt angle) of the hydraulic support as standard ROS2 topics for publication, and encapsulating hydraulic control actions (lifting, lowering, pushing) as ROS2 services or actions for subscription. In this way, each physical hydraulic support controller is logically abstracted as a standard robot node in a ROS network, possessing plug-and-play characteristics.

[0068] Third, establish a heterogeneous communication link 103 based on the XRCE-DDS protocol.

[0069] The system utilizes the XRCE-DDS protocol to break down the communication barriers between the host computer 102 and the slave computer 101. The slave computer 101 connects to the host computer 102 via a serial port (UART), CAN-FD, or industrial Ethernet. MicroROSAgent is responsible for converting the lightweight XRCE-DDS messages from the slave computer 101 into standard DDS messages and injecting them into the ROS2 global data bus, thereby enabling transparent transmission between heterogeneous systems.

[0070] Fourth, introduce QoS policies and lifecycle management mechanisms.

[0071] To address the complex electromagnetic environment and communication instability in downhole environments, this invention utilizes ROS2's QoS (Quality of Service) strategy, configuring critical control commands in "Reliable" mode and high-frequency sensor data in "BestEffort" mode to balance real-time performance and reliability. Simultaneously, a LifecycleNode mechanism is introduced to standardize the management of the hydraulic support controller's configuration, activation, error handling, and shutdown status, enhancing the system's self-healing capabilities.

[0072] The present invention has the following significant beneficial effects:

[0073] Breaking down technological barriers to achieve cross-platform interoperability:

[0074] By introducing the ROS2 standard architecture, this invention completely solves the problems of proprietary protocols and closed interfaces in traditional coal mining equipment. The hydraulic support control system can directly interact with equipment such as inspection robots and unmanned mining vehicles developed based on ROS, without the need to develop complex protocol conversion gateways, greatly reducing the integration difficulty of multi-machine collaboration in fully mechanized mining faces.

[0075] Leveraging heterogeneous computing power to balance real-time performance and intelligence:

[0076] This invention cleverly combines the hard real-time control capabilities of STM32 with the high-performance computing capabilities of RK3568 / PC. The MicroROS solution enables low-cost MCUs to access the powerful ROS2 ecosystem, allowing complex AI prediction algorithms, digital twin mapping, and other high-computing tasks to run on the host computer 102 while maintaining millisecond-level response at the underlying level, achieving an optimal balance between cost and performance.

[0077] Improve development efficiency and accelerate the "robotization" process:

[0078] Based on the architecture of this invention, developers can directly reuse the vast open-source algorithm libraries of the ROS community (such as navigation, path planning, and SLAM) without having to write underlying drivers from scratch. Simultaneously, by utilizing visualization tools such as Rviz2 and Gazebo, 3D visualization monitoring and simulation debugging of hydraulic support groups can be achieved, significantly shortening the R&D cycle and laying the core technological foundation for the evolution of hydraulic supports into true "intelligent robots."

[0079] Flexible deployment options and high adaptability:

[0080] This solution supports multiple deployment models, including edge computing deployment on the embedded ARM platform (RK3568) and centralized control center deployment based on Windows WSL. Seamless communication between the two platforms is possible without reconstructing the underlying architecture, which greatly improves the system's adaptability and maintainability in different coal mine sites.

[0081] This embodiment of MicroROS provides a robotic control system for fully mechanized hydraulic supports. The system adopts a heterogeneous hierarchical architecture of "upper computer 102 decision-making - lower computer 101 execution".

[0082] The control system in this embodiment includes the following basic components / modules:

[0083] A. Hydraulic support body and actuator 10: including mechanical structures such as columns, jacks, and side guards, as well as solenoid valve groups for controlling the on / off of hydraulic circuits.

[0084] B. Sensor group 12: Sensing elements installed at various parts of the support, including pressure sensors for monitoring column pressure, stroke sensors for monitoring pushing distance, and tilt sensors for monitoring the posture of the support.

[0085] C. Basic power module: Provides intrinsically safe power supply for downhole equipment.

[0086] This embodiment also includes the following core innovative modules:

[0087] D. Lower-level machine 101 embedded control node (MicroROSClient): Uses an STM32 series microcontroller (such as STM32F4 / H7) as the core processing unit. This node embeds a real-time operating system (FreeRTOS) and ported the MicroROSClient static library. It no longer runs proprietary PLC logic but exists as a standard "node" in the ROS2 network.

[0088] E. Host Computer 102 Group Control Decision Center (ROS2Host): Employs a high-performance computing platform (such as an RK3568 industrial control board or a PC server deploying Windows WSL / Ubuntu). This platform runs the ROS2Humble operating system and deploys MicroROSAgent (agent service) and group control collaboration algorithm nodes.

[0089] F. Heterogeneous Communication Link 103 (XRCE-DDSLink, XRCE-DDS Connection Link): The physical transmission channel connecting the host computer 102 and the slave computer 101, supporting UART serial port, CAN-FD bus or industrial Ethernet, carrying serialized data streams based on the XRCE-DDS protocol.

[0090] The physical connections and logical interactions between the various parts are as follows:

[0091] 1. Physical connection level:

[0092] The analog signal of sensor group 12 (B) is connected to the ADC interface of the lower computer 101 control node (D); the control terminal of solenoid valve group (A) is connected to the GPIO output terminal of the lower computer 101 control node (D).

[0093] The lower-level control node (D) 101 is physically connected to the upper-level group control decision center (E) 102 via a physical communication link (F) (e.g., serial port or network cable).

[0094] 2. Logical Interaction Level (Core Innovation):

[0095] Node mapping: After the lower-level machine 101(D) is initialized through the MicroROS library, it is logically mapped to a namespace node (e.g., / support_01) in the ROS2 network.

[0096] Data uplink: After the lower-level machine 101(D) collects sensor data, it does not perform complex business logic processing, but encapsulates it into a standard ROS2 message (such as std_msgs / Float32) and sends it to the MicroROSAgent in the upper-level machine 102(E) via the XRCE-DDS protocol. The Agent "unpacks" it and publishes it as a standard ROS topic to the global data bus.

[0097] Downlink command: The group control algorithm in the host computer 102 (E) makes a decision based on global data and issues a control command. MicroROSAgent receives the command and converts it into an XRCE-DDS message, which is then sent to the slave computer 101 (D). The slave computer 101 (D) receives the command through a SubscriberCallback function and directly drives the solenoid valve group (A) to operate.

[0098] Through the above structure, the system achieves complete decoupling between the underlying hardware driver and the upper-level control logic, enabling the hydraulic support to possess the communication attributes of a "robot".

[0099] The control method of the present invention includes the following steps:

[0100] Step 1: System Initialization and Communication Link Establishment (HandshakePhase):

[0101] 1. Start the ROS2 environment on the host computer 102 and run the MicroROSAgent service, listening on the specified communication port (such as / dev / ttyUSB0 or ​​UDP / 8888).

[0102] 2. The lower-level machine 101 (hydraulic support controller) is powered on and started. After the FreeRTOS kernel is initialized, the rclc_support_init function is called.

[0103] 3. The lower-level device 101 actively sends a connection request (Ping) to the upper-level device 102. After receiving the request, the Agent establishes a session, at which point the lower-level device 101 officially connects to the ROS2 network.

[0104] Step 2: Node Registration and Resource Allocation

[0105] 1. The lower-level machine 101 uses the rclc_node_init_default function to register its own node name (such as support_node_01).

[0106] 2. The lower-level machine 101 declares its capabilities:

[0107] Create a publisher: Declare the topic / support_01 / pressure (pressure data).

[0108] Create a subscriber: Declare the topic / support_01 / command (control instructions).

[0109] 3. MicroROSAgent broadcasts this node information in the ROS2 network, enabling other devices in the network (such as Rviz visualization terminals and neighboring rack controllers) to discover the rack.

[0110] Step 3: Real-time Data Acquisition and Publishing

[0111] 1. The timer interrupt of the lower-level machine 101 is triggered (e.g., once every 100ms).

[0112] 2. The lower-level machine 101 reads the ADC register to obtain the hydraulic column pressure value and performs filtering processing.

[0113] 3. The lower-level machine 101 fills the processed pressure value into the ROS message structure and calls the rcl_publish function.

[0114] 4. Data is transmitted to the Agent via the XRCE-DDS protocol. The Agent converts the data into standard DDS data packets and broadcasts them on the ROS2 bus.

[0115] Step 4: Cloud / Edge Side Decision & Control

[0116] 1. The group control algorithm node of host computer 102 (which subscribed to / support_01 / pressure) received pressure data.

[0117] 2. Algorithm judgment: If the pressure value is lower than the set initial support force threshold (e.g., 24MPa), it is determined that the initial support force of the stent is insufficient.

[0118] 3. The host computer 102 issues control commands: sends command codes (e.g., CMD_RAISE) to the / support_01 / command topic.

[0119] 4. MicroROSAgent captures the instruction, serializes it, and sends it to the lower-level machine 101.

[0120] Step 5: Low-level execution and feedback (Execution):

[0121] 1. When the MicroROS Executor of the lower-level machine 101 polls and finds new data in the subscription buffer, it triggers the callback function.

[0122] 2. The callback function parses the instruction code, controls the MCU's GPIO pin to output a high level, and drives the lifting solenoid valve to open (or it can be a solenoid valve driver peripheral that supports 485 serial port).

[0123] 3. (Optional) The lower-level machine 101 publishes the status feedback "Action in progress" through the / support_01 / status topic to complete the closed-loop control.

[0124] A heterogeneous architecture for separating decision-making and execution based on MicroROS and ROS2.

[0125] Corresponding technical effects (cost reduction and efficiency improvement, and computing power balance):

[0126] Breaking the computing power bottleneck: This ingeniously solves the problem of "insufficient brain" in traditional coal mining equipment. By moving complex algorithms (AI decision-making, global scheduling) to the high-computing-power host computer 102, while keeping real-time control on a low-cost MCU, it achieves "high-end intelligence running on low-end hardware".

[0127] Cost advantage: No need to upgrade expensive industrial control hardware across the board. You can access the powerful ROS2 ecosystem by using existing low-cost embedded chips (such as STM32), which significantly reduces the cost of hardware upgrades.

[0128] "Node-based" mapping and standardized encapsulation of hydraulic support controllers.

[0129] Corresponding technological effects (breaking down barriers and ecological integration):

[0130] Eliminating data silos: Completely abandoning closed proprietary protocols, the hydraulic supports are abstracted into standard "robot nodes." This means that the hydraulic supports can seamlessly communicate and collaborate with third-party equipment such as inspection robots and unmanned mining trucks, just like building blocks, greatly improving the system integration and scalability of the fully mechanized mining face.

[0131] Plug and play: It enables the software definition of hardware devices, eliminating the need to rewrite the underlying driver when adding or replacing devices, which greatly reduces the difficulty of on-site deployment.

[0132] Heterogeneous communication link 103 based on XRCE-DDS protocol and QoS / lifecycle management mechanism.

[0133] Corresponding technical effects (high reliability and fault self-healing):

[0134] Adaptable to harsh environments: In response to the complex electromagnetic interference environment underground, the system flexibly configures "reliable transmission" and "best-effort" modes through QoS strategies, ensuring that critical commands are not lost and high-frequency data is not blocked.

[0135] Improve operational efficiency: The introduction of lifecycle management enables the system to have standardized fault detection and self-healing capabilities, reducing manual intervention caused by program crashes or deadlocks, and improving the continuous operational stability of the system.

[0136] It supports flexible deployment solutions across multiple platforms (ARM edge devices / Windows central control devices).

[0137] Corresponding technical benefits (accelerated R&D and visual management):

[0138] Shorten the R&D cycle: Directly reuse the mature navigation and planning algorithm library of the ROS community to avoid reinventing the wheel, which is expected to significantly shorten the software development cycle.

[0139] Visualized monitoring: Supports 3D digital twin monitoring using tools such as Rviz2, making the originally "black box" downhole control process transparent and visualized, providing intuitive basis for remote decision-making by leadership.

[0140] Through the above steps, this invention transforms the complex industrial bus communication process into a standard ROS2 "publish / subscribe" model, greatly simplifying the development process and improving system interoperability.

[0141] Replacement of middleware and communication protocols (to prevent adversaries from changing their "translator").

[0142] Alternative solution description: The MicroROS and XRCE-DDS protocols are replaced by:

[0143] Option A (compatible with older technologies): Use the rosserial protocol. The lower-level machine 101 runs the rosserial client via serial port, and the upper-level machine 102 runs the rosserial_server node. Although its real-time performance is not as good as DDS, it can still achieve the goal of connecting the MCU to the ROS network in low-speed scenarios.

[0144] Option B (Industry Standard Convergence): Use OPC UA over TSN to ROS2 gateway. Lower-level machine 101 runs a lightweight OPC UA server, and upper-level machine 102 maps OPC UA data to ROS2 topics through a conversion node.

[0145] Option C (IoT Protocol): Use MQTT (Message Queuing Telemetry Transport) or CoAP (Constrained Application Protocol). The lower-level device 101 publishes MQTT messages, and the upper-level device 102 converts them into ROS2 topics through the mqtt_bridge node.

[0146] Feasibility analysis: The above protocols are essentially designed to solve the problem of "non-ROS devices accessing ROS networks". Although the specific data encapsulation formats are different, their core logic (data encapsulation-transmission-unpacking mapping) is consistent with this invention.

[0147] 2. Replacement of physical transmission links (from “wired” to “wireless”).

[0148] Alternative solution description: The heterogeneous communication link 103 uses wired connections such as serial port, CAN-FD, or industrial Ethernet. The alternative is to use industrial wireless communication technologies, such as WiFi 6, 5G modules, ZigBee, or LoRa.

[0149] Feasibility Analysis: MicroROS supports transmission based on UDP (User Datagram Protocol) / IP (Internet Protocol). In some complex mining faces where cabling is difficult, using a highly reliable wireless network to carry XRCE-DDS data streams can also achieve interconnection between the upper and lower level 101 machines, and is more conducive to equipment movement and maintenance.

[0150] 3. Replacement at the control logic level (from "centralized" to "distributed collaboration").

[0151] Alternative Solution Description: All decision-making logic is handled centrally by the host computer 102 (centralized group control). The alternative is: distributed collaboration based on adjacent supports (Peer-to-Peer). Utilizing MicroROS's P2P communication capabilities (if the network topology supports it), adjacent hydraulic support controllers can directly subscribe to each other's topics (e.g., support N subscribes to the movement status of support N-1), achieving simple "neighbor-support linkage" logic without requiring forwarding through the host computer 102.

[0152] Feasibility Analysis: The host computer 102 is only responsible for global monitoring and complex parameter adjustments, while simple high-frequency linkage logic is delegated to direct interaction between controllers. This hybrid mode is also an obvious extension of the architecture of this invention and falls within the protection scope of this invention.

[0153] In this application, the term "multiple" refers to two or more unless otherwise expressly defined. The terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral connection; "linking" can be a direct connection or an indirect connection through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0154] In the description of this specification, the terms "one embodiment," "some embodiments," "specific embodiment," etc., refer to a specific feature, structure, material, or characteristic described in connection with that embodiment or example, which is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0155] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A control system for mining equipment, characterized in that, The mining equipment includes a control system, actuators, and a sensor group. The control system includes a lower-level computer, a higher-level computer, and a heterogeneous communication link. The lower-level machine is connected to the actuator and the sensor group. The lower-level machine is used to receive sensor data from the sensor group and control commands from the upper-level machine, send the control commands from the actuator to the actuator, and send the sensor data to the upper-level machine. The host computer is connected to the slave computer via the heterogeneous communication link. The host computer receives sensor data sent by the slave computer, determines the control command based on the sensor data, and sends the control command to the slave computer. The host computer and the slave computer are configured with different communication protocols. The heterogeneous communication link is used to bidirectionally convert the data of the different communication protocols between the host computer and the slave computer.

2. The control system for the mining equipment according to claim 1, characterized in that, The host computer runs the ROS2 operating system and deploys the MicroROS agent service, while the slave computer runs a real-time operating system and integrates the MicroROS client library. The heterogeneous communication link is established based on the XRCE-DDS protocol, so that the slave computer is mapped as a standard node in the ROS2 operating system network.

3. The control system for the mining equipment according to claim 1 or 2, characterized in that, The lower-level machine uses an STM32 series microcontroller as an embedded controller. The host computer uses an RK3568 industrial control board, a PC server, or a server with a Windows WSL / Ubuntu virtual machine deployed as the computing platform.

4. The control system for the mining equipment according to claim 1 or 2, characterized in that, The heterogeneous communication link supports physical transmission media including UART serial port, CAN-FD bus or industrial Ethernet.

5. A method for controlling mining equipment, characterized in that, include: System initialization and communication establishment steps: Establish a communication connection between the host computer and the slave computer; Data acquisition and publishing steps: The lower-level machine acquires sensor data from the sensor group and sends the sensor data to the upper-level machine; Decision-making and instruction issuance steps: The host computer generates control instructions based on the received sensor data and sends the control instructions to the slave computer; Execution steps: The lower-level machine receives and parses the control command, and drives the actuator to move.

6. The control method for the mining equipment according to claim 5, characterized in that, In the system initialization and communication establishment steps, the host computer starts the agent service, and the slave computer powers on and sends a connection request to establish a session; In the data acquisition and publishing step, the lower-level machine encapsulates the acquired sensor data into a standard message format and sends it through its integrated client library; In the decision-making and instruction issuance step, the host computer converts the generated control instructions into a format that the slave computer can recognize through the agent service before issuing them; The communication between the host computer and the slave computer is based on a preset communication protocol.

7. The control method for mining equipment according to claim 6, characterized in that, The proxy service is the MicroROS proxy service, the client library is the MicroROS client library, and the preset communication protocol is the XRCE-DDS protocol.

8. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the control method for the mining equipment as described in any one of claims 5 to 7.

9. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the control method for the mining equipment as described in any one of claims 5 to 7.

10. A mining device, characterized in that, It includes the control system, actuator, and sensor group of the mining equipment as described in any one of claims 1 to 4.

Images