An open-pit mine unmanned vehicle end system architecture, control method and device

Abstract

The application discloses an open-pit mine unmanned vehicle end system architecture, a control method and equipment. The system architecture comprises an application system layer, a first module layer and a second module layer; the first module layer is located below the application system layer and comprises a plurality of independent function nodes, the independent function nodes comprising a positioning module, a perception module, a planning module, a control module, a state detection module, a remote driving active safety module and a chassis arbitration module; the second module layer is located inside the first module layer, and the second module layer comprises a plurality of second function modules, and each second function module corresponds to an independent function node; the independent function nodes are connected through a topic mechanism and a service mechanism of ROS2 for data interaction, the topic mechanism is used for publishing and subscribing real-time data flow, and the service mechanism is used for synchronous request and response of data. The system architecture can promote efficient cooperation between the function modules, strengthen the safety guarantee of the whole vehicle operation, and significantly improve the adaptability of the system to complex mine environments.

Description

Technical Field

[0001] This invention relates to the field of autonomous driving technology, and in particular to an unmanned vehicle terminal system architecture, control method and equipment for open-pit mines. Background Technology

[0002] As the mining industry moves towards intelligent upgrading, unmanned mining trucks have become key equipment for reducing operational safety risks and improving transportation efficiency. The complex operating environment of open-pit mines, such as rugged roads, dusty conditions, significant slope variations, and susceptibility to GPS signal interference, places extremely high demands on the real-time performance, reliability, and safety of unmanned driving systems. However, existing unmanned vehicle systems for open-pit mines still have the following technical shortcomings:

[0003] (1) Unclear architecture and poor module collaboration: The existing system has a high degree of coupling between modules, making it difficult to expand and maintain functions. At the same time, the existing system has a large delay in real-time data publishing and subscription and a slow response to synchronization requests, which makes it difficult to meet the real-time requirements under the complex road conditions in the mine;

[0004] (2) Insufficient safety monitoring and arbitration mechanisms: The current system lacks real-time and accurate assessment of the vehicle's safety fault levels, making comprehensive fault detection impossible. Furthermore, there is a risk of conflict between remote control and local control, making it difficult to guarantee the safe and stable operation of the vehicle under extreme conditions.

[0005] (3) Poor environmental adaptability and lack of information interaction standards: In the harsh environment of the mine, the perception module has a low accuracy rate in identifying obstacles and lacks a unified data interaction standard, resulting in low efficiency of information transmission between the vehicle and the platform and between the vehicle and the platform. Business information and operating status cannot be effectively connected, making it difficult to support the needs of multi-vehicle collaborative operation and remote scheduling.

[0006] Therefore, there is an urgent need for a layered, decoupled, highly efficient communication system architecture for unmanned vehicles in open-pit mines with a sound security arbitration mechanism to improve the system's adaptability, safety, and collaborative operation efficiency. Summary of the Invention

[0007] The technical problem to be solved by this invention is to address the aforementioned shortcomings of existing technologies by proposing a system architecture, control method, and equipment for unmanned open-pit mine vehicles. This system architecture can promote efficient collaboration among various functional modules, enhance the safety of vehicle operation, and significantly improve the system's adaptability to complex mining environments.

[0008] In a first aspect, the present invention provides an unmanned vehicle terminal system architecture for open-pit mines, the system architecture comprising: an application system layer, a first-level module layer, and a second-level module layer;

[0009] The first-level module layer is located below the application system layer. The first-level module layer includes multiple independent functional nodes, including the positioning module, perception module, planning module, control module, status detection module, remote driving active safety module, and chassis arbitration module.

[0010] The second-level module layer is located inside the first-level module layer. The second-level module layer includes multiple second-level functional modules. Each second-level functional module corresponds to an independent functional node. Each second-level functional module includes components that perform algorithm calculations or interface tasks.

[0011] Among them, independent functional nodes interact with each other through ROS2's topic mechanism and service mechanism. The topic mechanism is used for publishing and subscribing to real-time data streams, and the service mechanism is used for data synchronization requests and responses.

[0012] The positioning module is used to obtain the vehicle's location and attitude information;

[0013] The perception module is used to acquire environmental information around the vehicle and identify obstacles in order to generate and publish obstacle information;

[0014] The planning module is used to generate a global path and a local trajectory based on the location and attitude information obtained from the positioning module and in conjunction with the loading task;

[0015] The control module is used to calculate control variables and issue local control commands based on the global path and local trajectory obtained from the planning module.

[0016] The status detection module is used to subscribe to the self-check messages published by the positioning module, perception module, planning module and control module, integrate them to generate the vehicle safety fault level and the overall vehicle status and publish them.

[0017] The remote driving active safety module is used to perform logical verification on the remote control commands received by the autonomous vehicle based on the subscribed comprehensive vehicle status and obstacle information, and output a safety intervention signal when it determines that the command poses a risk.

[0018] The chassis arbitration module is used to receive local control commands, remote control commands, and safety intervention signals output by the remote driving active safety module, and to perform priority arbitration according to the vehicle safety fault level: in the fault state, the safety intervention signal or remote emergency stop command is executed first, and in the normal state, the local control command is executed first.

[0019] Furthermore, the secondary functional modules corresponding to the control module include motion control components, electrical control components, and control self-test components;

[0020] The motion control component is used to generate throttle control commands, brake control commands, and steering control commands based on the local trajectory and the overall vehicle status through lateral and longitudinal control algorithms.

[0021] The electrical control components are used to generate lifting bucket electrical control commands, lowering bucket electrical control commands, and lighting auxiliary electrical control commands based on the vehicle's operational status.

[0022] The control self-test component is used to monitor the execution delay of the horizontal and vertical control algorithms and the rationality of local control commands in real time, and to issue control fault messages.

[0023] Furthermore, the system architecture also includes:

[0024] Vehicle-to-Cloud (V2V) module, V2V module, and map management module;

[0025] The vehicle cloud module is connected to the positioning module, status detection module, planning module, and chassis arbitration module respectively, and is used to establish communication connection and data interaction between the cloud management platform and the vehicle system. Among them, the vehicle cloud module subscribes to the vehicle location information published by the positioning module and the comprehensive vehicle status published by the status detection module and uploads them to the cloud. At the same time, it receives task instructions from the cloud and forwards them to the planning module, and receives remote control instructions from the cloud and forwards them to the chassis arbitration module.

[0026] The V2V module connects to the positioning module, status detection module, perception module, and planning module to enable collaborative communication between vehicles. The V2V module subscribes to the positioning and status information of its own vehicle and broadcasts it outwards. At the same time, it receives interactive information broadcast by surrounding vehicles and publishes it for the perception module to perform multi-source fusion or for the planning module to perform collaborative obstacle avoidance planning.

[0027] The map management module is connected to the positioning module and the planning module respectively, and is used to store and manage the electronic map data of the open-pit mine. The map management module responds to the map data request of the positioning module through the ROS2 service mechanism to assist vehicle positioning, and responds to the map data request of the planning module to provide road topology and work area information to assist in path generation.

[0028] Furthermore, the secondary functional modules corresponding to the perception module include a lidar detection component, a camera detection component, a millimeter-wave detection component, a post-fusion component, and a local update detection component;

[0029] The lidar detection component, camera detection component, and millimeter-wave detection component are used to process the sensor data received by the lidar, camera, and millimeter-wave radar respectively, and then release the initial obstacle information.

[0030] The post-fusion component is used to perform confidence-weighted fusion of the initial obstacle information and output the fused obstacle category and coordinate information;

[0031] The local update detection component is used to extract road boundary information based on point cloud data acquired by LiDAR and publish it to the map management module to trigger local map updates;

[0032] Among them, the fused obstacle category and coordinate information is used to characterize dynamic and static obstacle targets in the vehicle driving environment, and the road boundary information is used to characterize the geometric constraints of the passable area in the vehicle driving environment. The obstacle category and coordinate information and the road boundary information together constitute the multi-dimensional environmental perception results output by the perception module.

[0033] Furthermore, the secondary functional modules corresponding to the status detection module include a vehicle status calculation component, a right-of-way component, and a self-test safety component;

[0034] The vehicle state calculation component is used to subscribe to multi-source data from the positioning module, planning module, and chassis feedback, in order to construct a vehicle state matrix through a timestamp alignment algorithm, and generate a comprehensive vehicle state based on the vehicle state matrix.

[0035] The right-of-way component is used to receive the status of surrounding vehicles and right-of-way suggestions from the cloud via the V2V module, and to calculate the right-of-way priority of the vehicle.

[0036] The self-test safety component is used to subscribe to the self-test messages of each independent functional node, integrate them according to the preset fault classification strategy to generate the vehicle safety fault level, and monitor collision risk.

[0037] Furthermore, the secondary functional modules corresponding to the map management module include the map parsing component, the map service component, and the map writing and updating component;

[0038] The map parsing component is used to parse, segment, and store high-precision semantic maps of the mining area;

[0039] The map service component is used to respond to map data requests from external modules through the ROS2 service interface;

[0040] The map writing and updating component is used to subscribe to road boundary information published by the perception module. When a road change is detected, the local map tiles after high-precision semantic map parsing of the mining area are dynamically updated.

[0041] Secondly, this invention provides a method for controlling an unmanned vehicle in an open-pit mine. This method is applied to the system architecture of the first aspect and includes:

[0042] The positioning module acquires and publishes the vehicle's location and attitude information;

[0043] The perception module acquires environmental information around the vehicle and identifies obstacles to generate and publish obstacle information;

[0044] The planning module generates a global path and a local trajectory based on the location and attitude information obtained from the positioning module and the loading task.

[0045] The control module calculates control variables and issues local control commands based on the global path and local trajectory obtained from the planning module.

[0046] The status detection module subscribes to the self-check messages published by the positioning module, perception module, planning module and control module, integrates them to generate the vehicle safety fault level and the overall vehicle status and publishes them.

[0047] The remote driving active safety module performs logical verification on the remote control commands received by the autonomous vehicle based on the subscribed comprehensive vehicle status and obstacle information, and outputs a safety intervention signal when it determines that the command poses a risk.

[0048] The chassis arbitration module receives local control commands, remote control commands, and safety intervention signals output by the remote driving active safety module. It performs priority arbitration based on the vehicle's safety fault level: in a fault state, it prioritizes the execution of safety intervention signals or remote emergency stop commands; in a normal state, it prioritizes the execution of local control commands.

[0049] Furthermore, the steps for priority arbitration based on the vehicle's overall safety fault level specifically include:

[0050] The chassis arbitration module monitors the vehicle safety fault levels published by the status detection module in real time.

[0051] When the vehicle safety fault level is severe, the chassis arbitration module blocks local control commands and regular remote control commands, and only responds to remote emergency stop commands or safety intervention signals output by the remote driving active safety module, and performs amplitude limiting protection processing on the final output control commands.

[0052] When the vehicle's safety fault level is normal, the chassis arbitration module prioritizes executing the local control commands issued by the control module; if a remote control command is received at the same time, the local control command and the remote control command are compared for safety, and the control command with higher safety is output.

[0053] Furthermore, the method also includes:

[0054] The perception module extracts the boundary information of the current road based on the lidar point cloud data, calculates the deviation value between the current road boundary and the boundary in the locally stored map data, and determines whether the deviation value exceeds the preset threshold.

[0055] If the deviation value exceeds the preset threshold, a road boundary update message will be published through the ROS2 topic mechanism;

[0056] The map management module subscribes to road boundary update messages, performs update write operations on locally stored local map tiles, records update timestamps, and provides the updated map data to the planning module through the ROS2 service mechanism.

[0057] Thirdly, the present invention provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and when the processor runs the computer program stored in the memory, the processor executes the open-pit mine unmanned vehicle terminal control method according to the second aspect.

[0058] This invention employs a three-tiered architecture design—application system layer, first-level module layer, and second-level module layer—combined with a heterogeneous communication strategy based on ROS2 topic and service mechanisms. This architecture constructs a complete safety assurance system encompassing a state detection module, a remote driving active safety module, and a chassis arbitration module. This promotes efficient collaboration among functional modules, strengthens the safety assurance of the entire vehicle operation, and significantly improves the system's adaptability to complex mining environments. Specific beneficial effects are as follows:

[0059] (1) Improve system compatibility and scalability, and reduce module coupling: This invention divides the system into application system layer, first-level module layer and second-level module layer. The first-level module layer is divided into independent functional nodes, and the second-level module layer is divided into internal execution components of the nodes. This layered decoupling design makes each functional node relatively independent, solves the problem of high module coupling in existing systems, and facilitates independent upgrades, maintenance or hardware replacement for the personalized needs of mines without large-scale system reconstruction.

[0060] (2) Enhance multi-module collaboration to meet real-time response requirements: Independent functional nodes interact with each other through ROS2’s topic mechanism and service mechanism. The topic mechanism ensures the efficient publishing and subscription of real-time data streams such as positioning and perception, while the service mechanism ensures the timeliness of data synchronization requests and responses, effectively solving the problems of high data interaction latency and poor collaboration in the existing system.

[0061] (3) Realize full-process safety monitoring and fault early warning: By setting up a status detection module, subscribing to the self-inspection messages issued by the positioning, perception, planning and control modules, the system integrates and generates the vehicle safety fault level and the overall vehicle status. This mechanism fills the gap in the existing system self-inspection mechanism, realizes full-process fault detection and early warning of core modules, and significantly improves the reliability of the system.

[0062] (4) Constructing a clear arbitration logic and active safety protection: The chassis arbitration module performs priority arbitration based on the vehicle's safety fault level, clarifying the priority of local control commands, remote control commands, and safety intervention signals (safety intervention or emergency stop is executed first in fault state, and local control is executed first in normal state); combined with the remote driving active safety module's logic verification and risk intervention for remote commands, it effectively solves the problem of conflict between remote and local control, eliminates the safety hazards caused by remote misoperation, and greatly improves the operational safety of unmanned mining trucks.

[0063] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0064] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention and do not constitute a limitation thereof. The above and other features and advantages will become more apparent to those skilled in the art from the detailed description of exemplary embodiments with reference to the accompanying drawings, in which:

[0065] Figure 1 This is a schematic diagram of the unmanned vehicle control method for open-pit mines provided in an embodiment of the present invention;

[0066] Figure 2 This is a general block diagram of the ROS2-based unmanned vehicle terminal system architecture for open-pit mines provided in an embodiment of the present invention.

[0067] Figure 3 A functional flowchart of the sensing system provided in an embodiment of the present invention;

[0068] Figure 4 A functional flowchart of the planning system provided in an embodiment of the present invention;

[0069] Figure 5 A flowchart of the vehicle-to-cloud and V2V system provided in an embodiment of the present invention;

[0070] Figure 6 A flowchart of the control system provided in an embodiment of the present invention;

[0071] Figure 7 A flowchart of a state detection system provided in an embodiment of the present invention;

[0072] Figure 8 A flowchart of a map system provided in an embodiment of the present invention;

[0073] Figure 9 A flowchart of a positioning system provided in an embodiment of the present invention;

[0074] Figure 10 A flowchart of the chassis arbitration system provided in an embodiment of the present invention;

[0075] Figure 11 This is a framework diagram of an electronic device provided in an embodiment of the present invention.

[0076] Reference numerals: 100, processor; 200, memory. Detailed Implementation

[0077] It is understood that the specific embodiments and accompanying drawings described herein are merely for explaining the invention and are not intended to limit the invention.

[0078] It is understood that, without conflict, the various embodiments and features in the embodiments of the present invention can be combined with each other.

[0079] It is understood that, for ease of description, only the parts related to the present invention are shown in the accompanying drawings, while the parts unrelated to the present invention are not shown in the drawings.

[0080] It is understood that each unit or module involved in the embodiments of the present invention may correspond to only one entity structure, or may be composed of multiple entity structures, or multiple units or modules may be integrated into one entity structure.

[0081] It is understood that, without conflict, the functions and steps marked in the flowcharts and block diagrams of this invention may occur in a different order than that marked in the accompanying drawings.

[0082] It is understood that the flowcharts and block diagrams of this invention illustrate the possible architecture, functions, and operations of systems, apparatuses, devices, and methods according to various embodiments of this invention. Each block in the flowchart or block diagram may represent a unit, module, program segment, or code, containing executable instructions for implementing the specified function. Furthermore, each block or combination of blocks in the block diagram and flowchart can be implemented using a hardware-based system to achieve the specified function, or using a combination of hardware and computer instructions.

[0083] It is understood that the units and modules involved in the embodiments of the present invention can be implemented by software or by hardware. For example, the units and modules can be located in a processor.

[0084] Example 1:

[0085] like Figure 2As shown in the figure, this embodiment provides an unmanned vehicle terminal system architecture for open-pit mines. This system architecture includes an application system layer, a first-level module layer, and a second-level module layer. The unmanned vehicle terminal system architecture provided in this embodiment is mainly applied to full-process unmanned transportation operations in the complex environment of open-pit mines. It covers autonomous driving scenarios in harsh road conditions such as multi-slope and bumpy terrain and dust obstruction within the mine, as well as efficient operation scenarios involving multi-vehicle collaborative formation and cloud-based cluster scheduling. Addressing the frequent changes in mine roads, it supports dynamic map updates based on real-time perception to adapt to terrain changes. It is also suitable for special working conditions such as remote takeover, emergency avoidance, and vehicle malfunctions. A dual safety arbitration mechanism, both local and remote, ensures vehicle operational safety, fully meeting the stringent requirements of open-pit mines for all-weather, high-safety, and intelligent transportation. The specific architecture of the unmanned vehicle terminal system for open-pit mines is shown in Tables 1-1 and 1-2 below.

[0086] Table 1-1: Tiankuangshan Unmanned Vehicle Terminal System Architecture - Part 1

[0087]

[0088] Table 1-2: Part 2 of the Tiankuangshan Unmanned Vehicle Terminal System Architecture.

[0089]

[0090] The first-level module layer is located below the application system layer. It includes multiple independent functional nodes, such as a positioning module, a perception module, a planning module, a control module, a state detection module, a remote driving active safety module, and a chassis arbitration module. The second-level module layer is located within the first-level module layer. It includes multiple second-level functional modules, each corresponding to an independent functional node. Each second-level functional module includes components that perform algorithm calculations or interface tasks. Specifically, the first-level module layer includes multiple independent functional nodes defined by the application system layer; the second-level module layer includes multiple second-level functional modules defined by the first-level module layer. These second-level functional modules are execution components within the independent functional nodes. Independent functional nodes interact with each other through ROS2's topic and service mechanisms. The topic mechanism is used for publishing and subscribing to real-time data streams, and the service mechanism is used for data synchronization requests and responses. The independent functional nodes include the positioning module, perception module, planning module, control module, state detection module, remote driving active safety module, and chassis arbitration module. The positioning module acquires the vehicle's position and attitude information. The perception module acquires environmental information around the vehicle and identifies obstacles. The planning module acquires location and attitude information from the positioning module and generates a global path and local trajectory based on the loading task. The control module acquires the global path and local trajectory from the planning module, calculates control variables, and issues local control commands. The status detection module subscribes to self-check messages from the positioning, perception, planning, and control modules, integrates them to generate and publishes the vehicle's overall safety fault level and comprehensive vehicle status. The remote driving active safety module subscribes to comprehensive vehicle status and obstacle information, performs logical verification on remote control commands, and outputs a safety intervention signal when a risk is detected in the command.

[0091] The chassis arbitration module is used to receive local control commands, remote control commands, and safety intervention signals output by the remote driving active safety module, and to perform priority arbitration according to the vehicle safety fault level: in the fault state, the safety intervention signal or remote emergency stop command is executed first, and in the normal state, the local control command is executed first.

[0092] As a specific implementation method, the secondary functional modules corresponding to the control module include a motion control component, an electrical control component, and a control self-test component. The motion control component outputs throttle, brake, and steering control commands based on the local trajectory and the vehicle's overall state using lateral and longitudinal control algorithms. The electrical control component generates lifting, lowering, and lighting assistance electrical control commands based on the vehicle's operational status. The control self-test component monitors the execution delay of the control algorithm and the rationality of the control commands in real time, and issues control fault messages.

[0093] As a specific implementation, the system architecture also includes a vehicle-to-cloud (V2V) module, a V2V module, and a map management module. The V2V module is connected to the positioning module, status detection module, planning module, and chassis arbitration module to establish communication connections and data interaction between the vehicle-side system and the cloud-based control platform. Specifically, the V2V module subscribes to vehicle location information published by the positioning module and comprehensive vehicle status information published by the status detection module and uploads them to the cloud. It also receives task instructions from the cloud and forwards them to the planning module, as well as remote control instructions from the cloud and forwards them to the chassis arbitration module. The V2V module is connected to the positioning module, status detection module, perception module, and planning module to enable collaborative communication between vehicles. Specifically, the V2V module subscribes to its own vehicle's location and status information and broadcasts it externally. It also receives and publishes interactive information broadcast by surrounding vehicles, providing data for multi-source fusion by the perception module or for collaborative obstacle avoidance planning by the planning module. The map management module is connected to the positioning module and the planning module respectively, and is used to store and manage the electronic map data of the open-pit mine. The map management module responds to the map data request of the positioning module through the ROS2 service mechanism to assist vehicle positioning, and responds to the map data request of the planning module to provide road topology and work area information to assist in path generation.

[0094] As a specific implementation method, the secondary functional modules corresponding to the perception module include a LiDAR detection component, a camera detection component, a millimeter-wave detection component, a post-fusion component, and a local update detection component. The LiDAR, camera, and millimeter-wave detection components process the sensor data received by the LiDAR, camera, and millimeter-wave radar respectively, and publish initial obstacle information. The post-fusion component performs confidence-weighted fusion on the initial obstacle information, outputting the fused obstacle category and coordinate information. The local update detection component extracts road boundary information based on the point cloud data acquired by the LiDAR and publishes it to the map management module to trigger a local map update.

[0095] As a specific implementation method, the secondary functional modules corresponding to the state detection module include a vehicle state calculation component, a right-of-way component, and a self-check safety component. The vehicle state calculation component subscribes to multi-source data from positioning, planning, and chassis feedback, and constructs a vehicle state matrix using a timestamp alignment algorithm. The right-of-way component receives surrounding vehicle states and cloud-based right-of-way suggestions from the V2V module, and calculates the vehicle's right-of-way priority. The self-check safety component subscribes to fault messages from each independent functional node, integrates them according to a preset fault classification strategy to generate a vehicle safety fault level, and monitors collision risks.

[0096] As a specific implementation method, the secondary functional modules corresponding to the map management module include a map parsing component, a map service component, and a map write / update component. The map parsing component is used to parse, segment, and store the high-precision semantic map of the mining area. The map service component is used to respond to map data requests from external modules through the ROS2 service interface. The map write / update component is used to subscribe to road boundary information published by the perception module and dynamically update local map tiles when road changes are detected.

[0097] This system architecture uses ROS2's real-time publish-subscribe mechanism for topics and synchronous request-response mechanism for services as the core data interaction carriers. Combined with the functional logic links shown in the flowcharts of each system, it achieves deep collaboration among modules such as positioning, perception, mapping, planning, control, vehicle-to-cloud, V2V, state detection, and chassis arbitration. At the same time, it ensures operational reliability through multi-layered security mechanisms. The specific working principle is as follows:

[0098] 1. Data interaction mechanism:

[0099] Based on the standardized communication framework of ROS2, a dual interaction mode of "real-time data stream + synchronous service stream" is constructed: (1) Real-time data stream: high-frequency dynamic data such as location information, obstacle data, vehicle status, and control commands are published / subscribed at a fixed frequency through ROS2 topics (e.g., 50Hz for location messages and 20Hz for fused obstacle messages) to ensure low latency in data transmission (end-to-end latency ≤ 100ms) and adapt to the real-time response requirements of unmanned driving in mines, such as Figure 1 The horizontal data flow between modules in the overall architecture diagram; (2) Synchronous service flow: Static data that requires bidirectional feedback, such as map calls, task confirmations, and fault responses, are synchronized through ROS2 services to achieve synchronous request-response (e.g., the time taken for the planning module to call the map service is ≤30ms), ensuring the reliability of data interaction, such as Figure 7 The logical link of "external subscription module calling service" in the map system.

[0100] 2. Core Function Collaboration Process:

[0101] By combining the functional logic of each system's flowchart, a closed-loop collaborative link is formed:

[0102] (1) Location-perception-map collaboration (e.g.) Figure 3 , Figure 8 , Figure 9 (as shown)

[0103] The positioning system analyzes real-time location data using a GNSS+IMU combined inertial navigation system, and publishes it to the perception system after coordinate transformation and smoothing. The perception system performs spatial calibration of sensor data based on this location information (such as LiDAR point cloud distortion correction and camera image stitching), detects obstacles through multi-source data fusion of LiDAR, cameras, and millimeter-wave radar, and extracts road boundaries by the local update detection module. The map management system subscribes to road boundary information, updates the local map in real time, and provides accurate map data to the planning module through a service interface, realizing a dynamic closed loop of "positioning calibration - perception detection - map update".

[0104] (2) Sensing-planning-control-chassis coordination (e.g.) Figure 3 , Figure 4 , Figure 6 , Figure 10 (as shown)

[0105] The perception system integrates obstacle information and precise map data provided by the mapping system, along with the vehicle's comprehensive status (position, speed, right-of-way) output by the status detection system, and inputs them into the planning system. The planning system first generates a reference trajectory through the global planning module, and then the behavior decision and local planning modules generate a collision-free local trajectory based on obstacle distribution and right-of-way results. After receiving the local trajectory, the control system outputs motion control commands and electrical control commands through lateral and longitudinal control algorithms. The chassis arbitration system performs priority arbitration and safety verification on local and remote control commands, converts them into CAN bus signals, and sends them to the chassis for execution. At the same time, it feeds back the chassis execution status to the control and status detection system, forming a control closed loop of "environmental perception - trajectory planning - control execution - status feedback".

[0106] (3) Vehicle-Cloud-V2V-Local System Collaboration (e.g.) Figure 5 (as shown)

[0107] The vehicle-to-cloud system uses a 5G communication module to remotely issue task commands and upload vehicle status. Remote control commands are verified and then pushed to the chassis arbitration system. The V2V system broadcasts its own vehicle's operating status and business information through the OBU module, while receiving data from other vehicles and transmitting it to the right-of-way module of the status detection system for multi-vehicle right-of-way allocation. The local system (planning, control, and status detection) integrates remote commands and V2V interaction data, dynamically adjusting decision-making logic (such as trajectory avoidance when meeting oncoming traffic and task priority adjustment) to achieve a collaborative operation mode of "remote scheduling - multi-vehicle interaction - local autonomous decision-making".

[0108] (4) Coordinated monitoring of the entire system status (e.g.) Figure 7 (as shown)

[0109] The self-inspection sub-modules of core modules such as positioning, perception, planning, control, and chassis publish fault information in real time; the status detection system subscribes to the self-inspection data of all modules, vehicle operation data, and obstacle information, and integrates them into a vehicle status matrix through a timestamp alignment algorithm, while simultaneously completing right-of-way priority calculation and safety fault classification; the status comprehensive output module synchronizes the integrated status information to each business module (planning, control) and the vehicle cloud system, providing a basis for decision optimization and remote monitoring, forming a monitoring closed loop of "module self-inspection - system aggregation - status feedback".

[0110] 3. Security Mechanism:

[0111] A "two-level safety protection" system is built based on multi-module collaboration to ensure operational safety in complex mining environments:

[0112] Level 1 Protection (Module Self-Check): Each core module is equipped with a self-check sub-module (such as positioning self-check, perception self-check, chassis self-check) to monitor hardware status (such as sensor power supply, communication link) and software operation (such as algorithm latency, data validity) in real time. Upon detecting an anomaly, a fault message is immediately issued. (See Figure 3.) Figure 6 , Figure 9 The "fault release" logic in the flowchart;

[0113] Level 2 Protection (System-level Early Warning and Arbitration): The condition monitoring system integrates fault information from all modules, classifies it by severity (no fault / minor / moderate / severe), and issues early warnings; the chassis arbitration system clearly defines the priority between local and remote control, takes a safe value for conflicting commands, and automatically overwrites commands exceeding the threshold. Figure 10 The "arbitration rules" and "protection overwrite" logic of the chassis arbitration system.

[0114] The following five-step implementation path (hardware deployment, software development, system integration, testing and verification, and scenario implementation) is used to meet the requirements of the entire open-pit mine operation process:

[0115] (a) Hardware deployment:

[0116] Deployed in layers: sensor layer, computing and control layer, communication layer, and power supply link.

[0117] 1. Sensor system deployment

[0118] 1.1 LiDAR: One solid-state LiDAR is installed at an unobstructed position on the front of the vehicle roof, with a detection range of ≥200m and a point cloud density of ≥1 million points / second. Three mechanical LiDARs are installed at unobstructed positions on the front left, front right, and rear of the vehicle, with a detection range of ≥50m and a point cloud density of ≥200,000 points / second. They are connected to the computing platform via Ethernet interface for 3D obstacle detection and road boundary recognition.

[0119] 1.2 High-definition cameras: A total of 4 perception cameras are deployed on the front and rear sides of the vehicle and the left and right sides of the front of the vehicle. The resolution is ≥8 million pixels, the frame rate is ≥30fps, and HDR function is supported. Image data is transmitted through the Ethernet interface to assist in obstacle classification.

[0120] 1.3 mm wave radar: 1 unit on the front bumper and 1 unit at the rear of the vehicle, with a detection range of ≥150m and an angle range of ±45°. It outputs data via CAN bus to supplement obstacle detection in extreme weather conditions.

[0121] 1.4 Inertial Navigation Positioning Module: A high-precision GNSS+IMU combined inertial navigation system is installed in the vehicle's electrical cabinet. The antenna is placed on the roof in an unobstructed position. In RTK mode, the positioning accuracy is ≤2cm and the update frequency is ≥100Hz. It is connected to the computing platform through an RS232 interface and outputs data such as latitude and longitude and heading angle.

[0122] 1.5V2V communication module: One DSRC and 5G dual-mode OBU is deployed at the front of the vehicle roof, with a communication distance of ≥500m and a transmission delay of ≤50ms. It is connected to the system through an Ethernet interface to realize multi-vehicle information interaction.

[0123] 2. Deployment of the computing control unit

[0124] 2.1 Edge computing platform (industrial control computer): One industrial-grade computing box is fixed in the electrical cabinet behind the cab, with a CPU of ≥8 cores (Intel Core i7 or equivalent performance), a GPU of ≥150 TOPS computing power (NVIDIA Jetson AGX Orin), and a pre-installed ROS2 Humble system to run all algorithm modules;

[0125] 2.2 Chassis Control Unit (VCU): A mining truck-adaptive VCU is installed in the chassis electrical compartment. It supports CAN2.0 and CANFD buses, with a response delay of ≤10ms. It receives and arbitrates control commands to drive the chassis actuators.

[0126] 2.3 Power Management Unit: The electrical cabinet is equipped with one wide-input industrial power module with an input voltage of 24V~60V and an output power of ≥500W. It has overvoltage, overcurrent and overtemperature protection and provides power to the computing platform (24V), sensors (12V / 24V) and communication module (12V).

[0127] 3. Communication and Connectivity Deployment

[0128] 3.1 5G Communication Module: An industrial-grade 5G module (supporting SA / NSA dual-mode) is installed on the roof antenna mount, with a downlink speed of ≥1Gbps and an uplink speed of ≥100Mbps. It is paired with a 5G omnidirectional antenna with a gain of ≥8dBi to achieve low-latency vehicle-to-cloud communication.

[0129] 3.2 CAN bus gateway: One industrial-grade CAN-Ethernet gateway with a latency of ≤5ms is deployed in the electrical cabinet to realize protocol conversion between the computing platform and the chassis VCU and vehicle status sensors;

[0130] 3.3 Interface Protection: All hardware interfaces use M12 waterproof aviation connectors, the Ethernet link between the sensor and the computing platform uses shielded network cables, and the power supply line is equipped with surge protectors.

[0131] (II) Software Development:

[0132] Based on the ROS2 Humble Hawksbill version, each module has a clearly defined development process:

[0133] 1. Standardized setup of the development environment

[0134] 1.1 Operating System: Ubuntu 22.04LTS (64-bit), pre-installed with the complete ROS2 Humble Hawksbill suite;

[0135] 1.2 Development toolchain: Visual Studio Code (with ROS2, C++, and Python plugins installed), Git (version control);

[0136] 1.3 Dependency library configuration: PCL 1.12 (point cloud processing), OpenCV 4.5 (image processing), TensorRT 8.5 (deep learning acceleration), Eigen 3.4 (matrix operations), CANopen (CAN bus communication), etc., are uniformly installed and configured using the apt-get command;

[0137] 1.4 Compilation tool: Colcon. Write the colcon.pkg file to define the dependencies between each package and support multi-module joint compilation and incremental compilation.

[0138] 2. Detailed Implementation of Core Module Software

[0139] 2.1 Positioning Module:

[0140] The positioning and publishing module reads inertial navigation NMEA protocol data (latitude, longitude, altitude, heading angle, etc.), performs the conversion from the WGS84 coordinate system to the local plane coordinate system of the mining area through the Eigen library, smooths the data using the Kalman filter algorithm (outlier judgment standard: deviation of 10 consecutive frames of data > 0.5m), and publishes positioning messages at a frequency of 50Hz in the format mine_location / msg / LocationInfo (including x, y, z coordinates, heading angle θ, positioning confidence 0~100, etc.).

[0141] Positioning self-check module: Real-time monitoring of the number of inertial navigation module satellites (≥8 satellites are normal), RTK connection status (fixed solution is normal), and positioning data continuity (disconnection exceeding 500ms is a fault). It is classified into mild (6~7 satellites), moderate (3~5 satellites), and severe (≤2 satellites or disconnection exceeding 500ms), and publishes the fault level and cause in the format mine_selfcheck / msg / LocationFault at a frequency of 10Hz.

[0142] Network detection module: By pinging the cloud platform IP address every 100ms and counting the 5G module signal strength (RSRP≥-100dBm is normal), the network status is determined (latency ≤100ms and normal signal is "good", latency 100~500ms or signal -100~-120dBm is "poor", latency ≥500ms or signal ≤-120dBm is "disconnected"). The results are published in the format mine_network / msg / NetworkState at a frequency of 10Hz.

[0143] 2.2 Sensing System:

[0144] The LiDAR detection module receives LiDAR point cloud data, performs distortion correction (based on vehicle motion state compensation) and ground point filtering (RANSAC algorithm) using the PCL library, and uses the YOLOv8-3D deep learning model for inference to detect obstacles such as people, vehicles, rocks, and retaining walls. It outputs the category, 3D bounding box coordinates, and confidence score, and publishes them at 20Hz in the mine_perception / msg / LidarObstacle format.

[0145] Camera detection module: Receives image data from 4 cameras, performs distortion correction and image stitching to generate panoramic images using OpenCV, uses YOLOv8-2D model inference to detect various obstacles and aligns them with the LiDAR detection categories, and publishes the data at 30Hz in the mine_perception / msg / CameraObstacle format.

[0146] Millimeter-wave detection module: Reads the millimeter-wave radar CAN bus signal, analyzes the obstacle distance, speed, and azimuth angle, removes abnormal data with a distance ≥150m or a speed deviation exceeding 5m / s, and publishes valid obstacle information at 50Hz in the format mine_perception / msg / MmwaveObstacle.

[0147] Local update detection module: Based on LiDAR point cloud ground point data, the α-shape algorithm is used to extract the road boundary contour and fit it into a polygon. The boundary is recalculated every frame. If the deviation from the previous frame exceeds 0.3m, the road is judged to have changed. The road boundary coordinates are published at 10Hz in the format mine_perception / msg / RoadBoundary.

[0148] Post-fusion module: Employs a confidence-weighted fusion algorithm to integrate the same obstacle detected by LiDAR, camera, and millimeter-wave radar (judged with IOU ≥ 0.5), selects the category with the highest confidence, projects the LiDAR 3D coordinates as 2D global envelope coordinates, and publishes the fusion results at 20Hz in the format mine_perception / msg / FusedObstacle.

[0149] Perception self-check module: Monitors sensor power supply voltage (12V±0.5V for LiDAR is normal), data transmission rate (≥100Mbps for LiDAR point cloud transmission rate is normal), detection algorithm inference latency (≤80ms is normal), obstacle detection coverage, and publishes fault modules and causes in the format mine_selfcheck / msg / PerceptionFault, at a frequency of 10Hz.

[0150] 2.3 Map Management System:

[0151] Map parsing module: Reads the high-precision semantic map of the mining area in .pcd+yaml format, extracts the map boundaries and semantic labels (roads, mining areas, avoidance zones, etc.), divides the .pcd point cloud map into 50m×50m local map blocks (single block ≤ 5MB), and stores them in a "region-category" directory structure (e.g., "mining area A-road-001.pcd").

[0152] Map service module: Provides ROS2 services mine_map / srv / GetMap, which can be called by each module according to "region + requirements" to send out corresponding local map tiles, semantic labels, road speed limits and other information, with a response latency of ≤50ms.

[0153] Map update module: Subscribes to road boundary information published by the local update detection module. When the boundary deviation exceeds 0.3m for 5 consecutive frames, a map update is triggered. The new boundary information is written to the corresponding local map tile, the update timestamp is recorded, and up to 10 historical versions are retained for rollback. After the update, the data integrity is ensured through verification. If the verification fails, the update is discarded and an alarm is triggered.

[0154] 2.4 Planning System:

[0155] Business layer module: Receives transportation task instructions issued by the cloud platform, parses task priority (levels 1-5) and time window, switches vehicle business status according to task execution progress (pending loading → loading in progress → transporting in progress → unloading in progress → completed), and publishes the current business status and task progress at 5Hz in the format mine_planning / msg / BusinessState.

[0156] Global planning module: Based on Dijkstra's algorithm, it takes the global map provided by the map service module, the start and end points of the business task as input, considers road speed limits and avoidance zone constraints, generates a global reference trajectory with an interval of 1m, smooths it with B-spline curve (curvature change rate ≤ 0.1rad / m²), and publishes it at 10Hz in the format mine_planning / msg / GlobalPath (including path point coordinates, speed limits, heading angles, etc.).

[0157] Behavioral decision-making and local planning module: Based on finite state machine (FSM), it takes as input obstacle information, vehicle status, and right-of-way results, and makes rules to decide on behavior (constant speed when the distance to the obstacle is ≥50m, deceleration when the distance is 30~50m, and stopping when the distance is ≤30m and avoidance is not possible); it adopts the EMPlanner algorithm, takes as input global reference trajectory, local map vehicle status, and obstacle information, and generates local trajectory (path point interval 1m) for the next 50 seconds, and publishes it at 10Hz in the format mine_planning / msg / LocalPath (including expected vehicle speed, expected heading angle, expected gear, etc.).

[0158] The planning self-check module detects the global trajectory generation time (≤100ms is normal), local trajectory feasibility, and the rationality of business status switching, and publishes the fault type (such as "global trajectory generation timeout") in the format mine_selfcheck / msg / PlanningFault at a frequency of 10Hz.

[0159] 2.5 Control System:

[0160] Motion control module: Subscribes to the local trajectory (mine_planning / msg / LocalPath) and comprehensive vehicle state (mine_state / msg / ComprehensiveState) of the planning module. It adopts the FUZZY PID control algorithm in the longitudinal direction and outputs throttle and brake control quantities. In the lateral direction, it adopts the MPC algorithm (considering tire lateral stiffness and vehicle inertia), constrains the steering angle change rate to ≤5° / s, and issues commands at 50Hz in the format of mine_control / msg / MotionControlCmd (throttle opening 0~100, brake pedal opening 0~100, steering angle -35°~35°, gear N, R, D). Electrical control module: Subscribes to vehicle overall status, bucket lifting and lowering commands, and motion control commands. When the business status is "unloading" and there is no safety fault, it generates a bucket lifting control signal (completion is determined when the lifting angle is ≥45°). After unloading is completed, it generates a bucket lowering control signal (completion is determined when the lifting angle is ≤1°). Simultaneously, it generates auxiliary electrical signals such as turn signals and brake lights. It publishes electrical control commands at 5Hz in the format of mine_control / msg / ElecControlCmd, and at the same time publishes mine_control / msg / ElecControlState feedback status.

[0161] Control self-test module: Monitors the control module power supply voltage (24V±1V is normal), ROS2 message publishing status (no publishing for 3 consecutive frames is a fault), detects the control algorithm execution delay (≤20ms is normal), the rationality of control commands, and the control effect (vehicle speed deviation ≤1km / h, steering angle deviation ≤5°, lateral deviation <=1m is normal), and publishes the fault type and level in the format mine_selfcheck / msg / ControlFault at a frequency of 10Hz.

[0162] 2.6 Vehicle-to-Cloud and V2V Systems:

[0163] Vehicle-to-Cloud Communication Module: Employs the MQTT-over-5G protocol (QoS level 2) to subscribe to vehicle comprehensive status (mine_state / msg / ComprehensiveState) and fault information (various mine_selfcheck / msg).

[0164] / *Fault, work progress (mine_planning / msg / BusinessState), etc., are uploaded to the cloud in JSON format (including vehicle ID, timestamp, message type, and data content) at 10Hz in normal state and 50Hz in fault state; receive cloud instructions and verify their integrity, forward them to the corresponding modules in ROS2 message format, and publish communication status (good, poor, disconnected) in the format of mine_cloud / msg / CloudCommState at a frequency of 10Hz. * /

[0165] Remote control publishing module: Subscribes to cloud-based remote control commands (mine_cloud / msg / RemoteControlCmd) forwarded by the vehicle-cloud communication module, verifies the publisher's permissions, parameter range, and field integrity. If the verification is successful, it forwards the commands to the chassis arbitration module in the format of mine_cloud / msg / ValidRemoteControlCmd. If it fails, it logs the commands and uploads them to the cloud. The publishing frequency is consistent with the command issuance frequency (maximum 50Hz).

[0166] Vehicle operation status receiving and publishing module: Collects vehicle location information, speed, heading angle, braking status, fault level, etc. at 50Hz through OBU device, encapsulates it in mine_v2v / msg / VehicleRunState format (including vehicle ID, timestamp, parameter set, data credibility), and broadcasts it to other mining trucks within 1km at 20Hz; subscribes to other vehicles' operation status messages, verifies the integrity of fields and the validity of timestamps, and caches them for 5 seconds after successful verification for use by the status detection system and right-of-way module.

[0167] Vehicle Business Receiving and Publishing Module: Collects vehicle business status (current status, task priority, target start and end points, etc.) at 10Hz, encapsulates it in the format mine_v2v / msg / VehicleBusinessState, and broadcasts it to other mining trucks within a 1km radius at 10Hz; subscribes to other vehicle business status messages, verifies the format and legality (such as task priority levels 1 to 5), and pushes them to the business layer module and right-of-way module after successful verification; if no message is received from a vehicle for 30 consecutive frames (2s), it is marked as "disconnected" and the right-of-way module is notified to adjust the calculation logic.

[0168] 2.7 Condition Detection System:

[0169] Vehicle State Calculation Module: Subscribes to 12 types of core data, including positioning, planning, and chassis VCU, through ROS2 topic subscription (subscription frequency 10Hz~100Hz), and synchronizes data using a "timestamp alignment" algorithm (deviation ≤10ms). It constructs a multi-dimensional vehicle state matrix (including position, attitude, motion parameters, and power parameters) through the Eigen library, removes outliers by sliding window filtering (window size 5 frames), and publishes mine_state / msg / VehicleStateMatrix at 50Hz.

[0170] Right-of-way module: Subscribes to the status of other vehicles in the V2V system and right-of-way suggestions in the cloud. It uses a weighted scoring method to calculate priority (task priority weight 0.4, vehicle speed weight 0.3, distance from the intersection weight 0.3). The vehicle with the higher score gets the right-of-way. If the score difference is ≤0.1, it is determined according to "first come, first served". It publishes mine_state / msg / RoadRightResult (including right-of-way level and avoidance suggestions) at 10Hz.

[0171] Self-inspection and safety module: Subscribe to 8 types of module fault messages (all vehicle-side modules), integrate the vehicle self-inspection level (no fault, mild, moderate, severe) according to the principle of "taking the highest level", monitor three types of scenarios in real time: collision risk, control abnormality, and key module failure, and publish mine_state / msg / SafetyLevel at 10Hz.

[0172] The status comprehensive output module integrates vehicle status matrix, right-of-way results, and self-inspection safety results, and processes them according to "timestamp alignment → data association → format standardization". It publishes mine_state / msg / ComprehensiveState at 10Hz under normal conditions and at 50Hz under moderate to severe faults, and uploads them to the cloud synchronously.

[0173] 2.8 Chassis Arbitration System:

[0174] Arbitration module: Subscribes to local motion, electrical control commands, and cloud remote control commands. In case of safety failure, the remote emergency stop command has the highest priority. In case of no failure, the local command has a higher priority than the ordinary remote command. In case of conflict, the safer command is taken. Commands exceeding the threshold are automatically overwritten (steering angle ≤35°, pedal opening degree 0-100) and conflict information is fed back.

[0175] Chassis Abstraction Module: Converts the arbitration command into a CAN bus signal (such as steering angle to 0~5V analog quantity), and sends it to the chassis actuator through the CAN gateway; reads the CAN signal of the chassis VCU (actual vehicle speed, steering angle, etc.), converts it into mine_chassis / msg / ChassisState, and publishes it to each module for verification at 50Hz.

[0176] Chassis self-check module: Monitors CAN signal transmission (disconnection exceeding 200ms is a fault), actuator response delay (no feedback within 200ms is a fault), brake pressure (≥0.8MPa is normal), and other self-check categories, and publishes mine_selfcheck / msg / ChassisFault at 10Hz.

[0177] 2.9 Remote Driving Active Safety System:

[0178] Remote control signal verification module: Receives remote control commands forwarded by the vehicle cloud module, verifies the publisher's permissions, parameter range (such as steering angle ≤ ±35°), and field integrity. If the verification is successful, it forwards the command to the chassis arbitration module; if it fails, it logs the command and uploads it to the cloud.

[0179] Active safety judgment module: Subscribes to comprehensive vehicle status and obstacle detection information, judges the safety of remote control commands (such as rejecting acceleration commands when the distance to an obstacle is ≤30m), outputs suggestions for normal driving, deceleration or stopping and overwrites control signals to ensure remote driving safety.

[0180] 2.10 Energy Management System:

[0181] Energy consumption optimization module: Subscribes to vehicle state matrix, planned trajectory, and road condition information (such as slope and obstacle distribution), establishes energy consumption model, optimizes the desired route (avoiding steep slopes and congested road sections), throttle and brake opening changes (avoiding rapid acceleration and deceleration) with the goal of minimum energy consumption, and outputs energy consumption optimization suggestions to the planning module.

[0182] Energy consumption monitoring module: collects power system data in real time (battery SOC, engine speed, fuel consumption, and power consumption rate), calculates energy consumption for a single task, generates energy consumption analysis reports, and uploads them to the cloud for scheduling and optimization.

[0183] 2.11 Traffic Control System:

[0184] Path conflict detection module: Subscribes to the operating status, business status and planned trajectory of multiple vehicles, and analyzes the timestamp and coordinates to detect the risk of path intersection at the same time point and issue a conflict warning 500ms in advance.

[0185] Grouping and scheduling module: Receives grouping instructions from the cloud, combines the priority of multiple vehicle tasks and right-of-way results, plans the grouping route (maintaining a safe distance of ≥30m), coordinates the start-stop and speed change rhythm of vehicles, avoids conflicts within the group, and supports large-scale collaborative operations.

[0186] 3. Interface Standardization Definition

[0187] 3.1 Message Format: Based on ROS2 IDL language, 12 core message types are defined (such as mine_location / msg / LocationInfo, mine_perception / msg / FusedObstacle), and the field types (such as coordinates as float64 and confidence level as uint8) and value ranges are specified.

[0188] 3.2 Service Interfaces: Define 8 types of services (such as mine_map / srv / GetMap, mine_task / srv / ConfirmTask), adopting a "request-response" model, with a response latency of ≤50ms;

[0189] (III) System Integration

[0190] 1. Module integration and startup configuration

[0191] 1.1 Function Package Archiving: Store ROS2 function packages for modules such as location, perception, and planning according to the "application system layer" (e.g., location_packageperception_package), with a unified directory structure (include / src / launch / config / ).

[0192] 1.2 Startup file writing: Write mine_autodrive_launch.py ​​to define the module startup order (hardware driver → localization → perception → map → planning → control → vehicle cloud / V2V), and configure parameters such as sensor IP address and algorithm threshold (e.g., LiDAR IP: 192.168.1.100, obstacle detection confidence threshold: 0.6).

[0193] 1.3 Node Management: The ROS2NodeManager tool is used to monitor the CPU usage (≤70%), memory usage (≤80%), and message publish / subscribe frequency of each node in real time. It supports node restart and dynamic parameter adjustment (such as modifying PID parameters via command line).

[0194] 2. Hierarchical joint debugging and testing

[0195] 2.1 Single-point module testing: Start the target module separately and verify the data output using the ros2topic echo command. For example, after starting the location module, confirm that the / mine / location / info topic is posted at a frequency of 50Hz and that the coordinate data does not jump.

[0196] 2.2 Cross-module collaborative test: Start the positioning-perception-map collaborative link, verify the closed-loop logic of positioning data calibrating perception sensors and perceiving road boundaries to update the map, and ensure that the map update delay is ≤500ms;

[0197] 2.3 Hardware-in-the-loop (HIL) testing: A test bench was set up, and real sensors, computing platforms, and chassis VCU simulators were connected. Sensor disconnection was simulated (such as power failure of LiDAR). The self-test module of perception was verified to issue a fault message within 100ms, and the planning module automatically performed the desired route planning such as deceleration and stopping according to the fault level.

[0198] (iv) Testing and verification:

[0199] Verification was achieved through three levels of testing: simulation testing, real vehicle testing, and fault testing.

[0200] 1. Indoor simulation test (Gazebo scene)

[0201] 1.1 Scene Setup: Recreate the open-pit mine (slope ≤ 8%), main road (including curve radius ≥ 20m, slope ≤ 3%), spoil heap (open area), and add obstacle models such as rocks (0.5m~2m in diameter), personnel, and other mine trucks;

[0202] 1.2 Test content: Simulate the "loading → transportation → unloading" process and test the positioning accuracy (≤5cm), obstacle recognition accuracy (≥95%), trajectory tracking deviation (≤0.3m), and end-to-end delay (≤200ms).

[0203] 1.3 Performance monitoring: ros2topichz is used to count message frequency, and htop is used to monitor CPU and memory usage to ensure that the edge computing platform is not overloaded.

[0204] 2. Real vehicle testing (open-pit coal mine site)

[0205] 2.1 Static Testing: After the system is powered on and started, the startup time (≤60s), module initialization success rate (100%), and map loading success rate (100%) are recorded.

[0206] 2.2 Dynamic Test: Constant speed driving on main roads (35km / h), turning on curves (radius 20m), and driving on slopes (8° gradient) to verify speed control deviation (≤1km / h), steering angle deviation (≤1°), and lateral trajectory tracking deviation (≤1.0m).

[0207] 2.3 Obstacle avoidance test: Place stones with a diameter of 1.5m on the main road and simulate workers (at a distance of 50m) to test the avoidance response time (≤500ms) and avoidance distance (≥5m);

[0208] 2.4 Multi-vehicle collaborative test: Two mining trucks operate simultaneously, simulating meeting (lateral distance ≥3m) and following (safe distance ≥30m) to verify the V2V information transmission success rate (≥99%) and the absence of conflict in right-of-way allocation;

[0209] 2.5 Long-term test: Continuously execute transportation tasks for 8 hours in a loop, and record system stability (no crashes, no data loss), task completion rate (≥98%), and energy consumption (comparable to manual driving).

[0210] 3. Fault simulation test

[0211] 3.1 Network disconnection test: The 5G signal is cut off while driving (delay ≥ 500ms). The system switches to local autonomous control within 100ms. The perception detection frequency is increased from 20Hz to 30Hz. The planning module continues to execute the task based on the existing trajectory. If the network disconnection time exceeds 2 minutes, the vehicle decelerates and stops and uploads a parking alarm.

[0212] 3.2 Sensor Fault Test: After disconnecting the LiDAR power supply, the system automatically enhances the fusion weights of the camera and millimeter-wave radar, and the obstacle recognition accuracy remains ≥85%.

[0213] 3.3 Emergency Stop Test: An emergency stop command is issued from the cloud, and the chassis arbitration module is verified to take priority in execution, and the vehicle stops within 3 seconds (braking distance ≤ 15m at a speed of 35km / h).

[0214] (V) Scenario Implementation

[0215] Taking a single transportation task of "loading material at mining site A → transporting on the main road → unloading material at spoil heap B" as an example, the steps are explained as follows:

[0216] 1. Task initiation phase (T0~T30s)

[0217] 1.1 T0s: The cloud sends a task via the MQTT protocol (priority level 3, starting point A loading area x=1234.5m, y=678.9m, ending point B spoil heap, speed limit 35km / h). The vehicle-cloud communication module verifies the integrity of the instruction and then forwards it to the business layer module.

[0218] 1.2 T5s: The system starts all modules through mine_autodrive_launch.py, and the positioning module parses the inertial navigation data and publishes the initial positioning information;

[0219] 1.3 T10s: Each self-inspection module completes initialization, the status detection system integration result is "no fault", and the vehicle's overall status is released;

[0220] 1.4 T30s: The loading machine sends a "loading complete" signal through v2v devices or 5G network (dual link), the business layer module switches the status to "transporting", and the global planning module generates a 3.5km global trajectory (including 2 curves and 1 ramp).

[0221] 2. Trunk line transportation phase (T30s~T15min)

[0222] 2.1 Positioning-Perception Coordination: The positioning module publishes real-time location at 50Hz, and the perception system's LiDAR, camera, and millimeter-wave radar synchronously collect data. The subsequent fusion module publishes obstacle information at 20Hz.

[0223] 2.2 Planning-Control Coordination: The behavior decision module determines "decelerate and avoid", the local planning module generates a deceleration and obstacle avoidance trajectory (vehicle speed decreases from 35km / h to 20km / h), the control system outputs a braking command, and the chassis arbitration module sends the command to the chassis after verifying that there is no conflict.

[0224] 2.3 Multi-vehicle collaboration: The V2V system receives the status of the mining truck 1km ahead (vehicle speed 25km / h, in transit), the right-of-way module calculates the priority score (0.72 for this vehicle, 0.68 for other vehicles), and the planning module adjusts the trajectory to reserve 3m of passing space.

[0225] 3. Unloading and Emergency Phase (T15min~T18min)

[0226] 3.1 T15min: The vehicle arrives at the boundary of the spoil heap B. The map management system issues a local map of the unloading area, and the global planning module generates a precise positioning trajectory.

[0227] 3.2 T16min: When the vehicle arrives at the unloading position, the business layer switches to "unloading in progress", the electrical control module outputs a bucket lifting command (lifting angle ≥ 45°), and the sensing system monitors the unloading area for obstacles;

[0228] 3.3 T17min: Unloading completed, the electrical control module outputs a bucket drop command (lifting angle ≤ 5°);

[0229] The unloading and emergency phase also includes emergency handling: if the network is lost at T8min, the network detection module will issue a "network outage" status, the vehicle cloud system will stop receiving remote commands, the planning module will continue driving based on the existing trajectory, and the status will be synchronized to the cloud after the network is restored (T10min).

[0230] The unmanned vehicle system architecture for open-pit mines provided in this embodiment is an intelligent solution that is highly engineered and possesses a complete technical closed loop, designed for extreme working conditions. Its core advantages are reflected in the deep collaboration and organic unity across five dimensions. First, at the system architecture level, this solution relies on the standardized topic and service communication mechanism of ROS2 to construct a "layered modular" software system. It decouples core functions such as positioning, perception, planning, and control into independent and highly cohesive functional units. Each module achieves low-latency data interaction with end-to-end latency ≤100ms through a unified interface. This completely solves the structural drawbacks of traditional unmanned driving systems, such as independent module development, chaotic interfaces, and disconnected data interaction. This enables the system to respond to dynamic changes such as road collapses, vehicle intersections, and sudden rockfalls in complex mine conditions at the millisecond level, significantly improving the real-time performance of decision-making and execution. Secondly, in terms of environmental adaptability, the system adopts a multi-sensor fusion scheme of lidar, camera and millimeter-wave radar, combined with deep learning inference algorithms optimized for mining scenarios. It achieves a recognition accuracy of ≥95% for mining-specific obstacles such as rocks, retaining walls, slopes and mining equipment. At the same time, it is equipped with a dynamic map update mechanism. The perception system extracts road boundary information in real time and feeds it back to the map layer for centimeter-level dynamic correction. This allows it to flexibly adapt to complex working conditions such as frequent changes in mining roads due to the advancement of mining faces, seasonal high dust obstructing the sensor's field of vision, and the impact of severe weather. It ensures that it can maintain stable and reliable environmental perception and positioning capabilities in areas without GNSS signals or where the signal is obstructed. Third, in terms of safety assurance, the system has constructed a full-process safety mechanism of "module self-inspection → system aggregation → hierarchical early warning". Each core module has a built-in self-inspection sub-module to monitor the sensor status, algorithm output rationality and hardware operation health in real time, achieving a safety fault identification coverage rate of ≥98%. At the same time, the priority rules between local emergency control and remote cloud control platform are clarified through chassis arbitration system. When control command conflict is detected, command adjudication is carried out according to preset safety priority. The active safety verification mechanism is used to intercept and overwrite dangerous operations such as speeding, illegal lane changing and collision risk trajectory in real time, avoiding safety accidents caused by human error or system failure from the source, and comprehensively ensuring the reliability and safety of high-intensity continuous operation of the mine 24 / 7.Fourth, at the collaborative interaction level, the system adopts standardized data formats and interaction protocols to unify the interface specifications of vehicle-to-cloud (V2C) communication and vehicle-to-vehicle (V2V) communication. This enables precise transmission of business information (task instructions, path issuance) and operational status information (location, speed, fault codes) between vehicles and the cloud to support remote monitoring and centralized scheduling in the cloud dispatch center. Furthermore, through V2V direct communication, vehicles can share their location, intention trajectory, and operational status in real time, enabling autonomous platooning of multiple vehicles, collaborative passage at intersections, and dynamic collision avoidance. This perfectly adapts to centralized scheduling scenarios with deep cloud platform intervention and distributed autonomous collaborative scenarios without platform intervention, meeting the differentiated needs of different mines for automation levels and operating models. Finally, regarding scalability and sustainability, based on the ROS2 open-source ecosystem and the loosely coupled nature of its modular architecture, the system can achieve "plug-and-play" functionality without reconstructing the overall architecture when adding functional modules such as energy management and traffic control, or replacing hardware such as higher-beam lidars or iterating on next-generation high-performance computing platforms. Only local development or replacement of the corresponding modules is required, significantly reducing the technical threshold for functional iteration and the cost of hardware upgrades. This allows the system to quickly adapt to the personalized operational needs of different types of mines, such as open-pit coal mines and metal mines, and reserves ample interfaces and expansion space for the future introduction of cutting-edge technologies such as V2X roadside collaboration and digital twin monitoring. In summary, this architecture, based on ROS2, organically integrates layered modular design, multi-source perception fusion, full-process safety mechanisms, standardized communication protocols, and loosely coupled scalability. It not only systematically solves the core pain points of traditional mines—low transportation efficiency, high safety risks, and poor environmental adaptability—but also provides a feasible, scalable, and evolvable technical solution for the intelligent and unmanned transformation of open-pit mines.

[0231] Example 2:

[0232] like Figure 1 As shown, this embodiment provides a method for controlling unmanned mining vehicles in open-pit mines. This method is applicable to the complex operating environment of open-pit mines, addressing adverse conditions such as rugged roads, severe dust obstruction, frequent slope changes, and susceptibility to satellite signal interference. It achieves real-time, safe, and autonomous control of unmanned mining trucks. This method is implemented based on the system architecture described in Embodiment 1, fully utilizing the architecture's layered decoupling characteristics and the efficient ROS2 communication mechanism to ensure the vehicle's operational stability under multi-task concurrency and complex scenarios. Specifically, the control method includes steps S1 to S7.

[0233] Step S1: The positioning module acquires and publishes the vehicle's location and attitude information.

[0234] Step S2: The perception module acquires environmental information around the vehicle, identifies obstacles, and publishes the information.

[0235] Step S3: The planning module obtains the location and attitude information published by the positioning module, and generates a global path and local trajectory in combination with the loading task.

[0236] Step S4: The control module obtains the global path and local trajectory published by the planning module, calculates the control quantity, and publishes local control commands.

[0237] Step S5: The status detection module subscribes to the self-check messages published by the positioning module, perception module, planning module and control module, integrates and generates the vehicle safety fault level and vehicle comprehensive status and publishes them.

[0238] Step S6: The remote driving active safety module subscribes to the vehicle's overall status and obstacle information, performs logical verification on remote control commands, and outputs a safety intervention signal when it determines that the command poses a risk.

[0239] Step S7: The chassis arbitration module receives local control commands, remote control commands, and safety intervention signals output by the remote driving active safety module, and performs priority arbitration according to the vehicle safety fault level: in the fault state, the safety intervention signal or remote emergency stop command is executed first, and in the normal state, the local control command is executed first.

[0240] As a specific implementation method, the process of priority arbitration based on the vehicle safety fault level is as follows: First, the chassis arbitration module continuously and in real time monitors the vehicle safety fault level issued by the status detection module, using this as the basis for arbitration decisions. When the monitoring results show that the vehicle safety fault level is a severe fault, the chassis arbitration module immediately triggers a high-priority safety protection mechanism: on the one hand, it blocks local control commands and regular remote control commands, cutting off regular operation paths to prevent the risk from escalating; on the other hand, it only retains the right to respond to remote emergency stop commands or safety intervention signals output by the remote driving active safety module, and performs strict amplitude limiting protection processing on the final output control commands to ensure that the vehicle can safely decelerate or stop in a fault state. When the monitoring results show that the vehicle safety fault level is a normal state, the chassis arbitration module executes the regular operating logic: it prioritizes the execution of local control commands issued by the control module to ensure operational efficiency; during this process, if a remote control command is received simultaneously, the module will perform a safety comparison analysis between the local control command and the remote control command, and finally output the control command with higher safety, thereby achieving a smooth transition of control rights while ensuring safety.

[0241] As a specific implementation method, this unmanned vehicle control method for open-pit mines also includes a step of dynamic map updating. The perception module uses LiDAR point cloud data to extract the boundary information of the current road, calculates the boundary deviation value between it and the locally stored map data, and determines whether the deviation value exceeds a preset threshold. Once the deviation value is determined to exceed the preset threshold, a road boundary update message is published through the ROS2 topic mechanism. After the map management module subscribes to the message, it performs an update write operation on the locally stored local map tiles and records the update timestamp. Subsequently, the updated map data is provided to the planning module through the ROS2 service mechanism, thereby ensuring the real-time performance and accuracy of the map information.

[0242] Example 3:

[0243] like Figure 11 As shown, this embodiment provides an electronic device, including a memory 200 and a processor 100. The memory 200 stores a computer program. When the processor 100 runs the computer program stored in the memory 200, the processor 100 executes the open-pit mine unmanned vehicle terminal control method according to Embodiment 2.

[0244] It is understood that the above embodiments are merely exemplary implementations used to illustrate the principles of the present invention, and the present invention is not limited thereto. For those skilled in the art, various modifications and improvements can be made without departing from the spirit and essence of the present invention, and these modifications and improvements are also considered to be within the scope of protection of the present invention.

Claims

1. A terminal system architecture for an unmanned vehicle in an open-pit mine, characterized in that, include: Application system layer, first-level module layer, and second-level module layer; The first-level module layer is located below the application system layer. The first-level module layer includes multiple independent functional nodes, including a positioning module, a perception module, a planning module, a control module, a status detection module, a remote driving active safety module, and a chassis arbitration module. The second-level module layer is located inside the first-level module layer. The second-level module layer includes multiple second-level functional modules. Each second-level functional module corresponds to an independent functional node. Each second-level functional module includes a component that performs algorithm calculations or interface tasks. The independent functional nodes interact with each other through ROS2's topic mechanism and service mechanism. The topic mechanism is used for publishing and subscribing to real-time data streams, and the service mechanism is used for data synchronization requests and responses. The positioning module is used to acquire the vehicle's location and attitude information; The perception module is used to acquire environmental information around the vehicle and identify obstacles in order to generate and publish obstacle information. The planning module is used to generate a global path and a local trajectory based on the location and attitude information obtained from the positioning module and in conjunction with the loading task. The control module is used to calculate control quantities and issue local control commands based on the global path and local trajectory obtained from the planning module. The status detection module is used to subscribe to the self-check messages published by the positioning module, the perception module, the planning module and the control module, integrate them to generate the vehicle safety fault level and the overall vehicle status and publish them. The remote driving active safety module is used to perform logical verification on the remote control commands received by the autonomous vehicle based on the subscribed comprehensive vehicle status and obstacle information, and output a safety intervention signal when it is determined that the command poses a risk. The chassis arbitration module is used to receive the local control command, the remote control command, and the safety intervention signal output by the remote driving active safety module, and to perform priority arbitration according to the vehicle safety fault level: in the fault state, the safety intervention signal or the remote emergency stop command is executed first, and in the normal state, the local control command is executed first.

2. The open-pit mine unmanned vehicle terminal system architecture according to claim 1, characterized in that, The secondary functional modules corresponding to the control module include motion control components, electrical control components, and control self-test components; The motion control component is used to generate throttle control commands, brake control commands, and steering control commands based on the local trajectory and the overall vehicle status using lateral and longitudinal control algorithms. The electrical control component is used to generate lifting bucket electrical control commands, lowering bucket electrical control commands, and lighting auxiliary electrical control commands according to the vehicle's operational status. The control self-test component is used to monitor the execution delay of the horizontal and vertical control algorithms and the rationality of local control commands in real time, and to issue control fault messages.

3. The open-pit mine unmanned vehicle terminal system architecture according to claim 1 or 2, characterized in that, The system architecture also includes: Vehicle-to-Cloud (V2V) module, V2V module, and map management module; The vehicle cloud module is connected to the positioning module, the status detection module, the planning module, and the chassis arbitration module, respectively, to establish a communication connection and data interaction between the cloud management platform and the vehicle system. The vehicle cloud module subscribes to the vehicle location information published by the positioning module and the comprehensive vehicle status published by the status detection module and uploads them to the cloud. At the same time, it receives task instructions from the cloud and forwards them to the planning module, and receives remote control instructions from the cloud and forwards them to the chassis arbitration module. The V2V module is connected to the positioning module, the status detection module, the perception module, and the planning module respectively, and is used to realize collaborative communication between vehicles. The V2V module subscribes to the positioning information and status information of its own vehicle and broadcasts them to the outside world. At the same time, it receives interactive information broadcast by surrounding vehicles and publishes it, which is used by the perception module for multi-source fusion or by the planning module for collaborative obstacle avoidance planning. The map management module is connected to the positioning module and the planning module respectively, and is used to store and manage electronic map data of the open-pit mine area; wherein, the map management module responds to the map data request of the positioning module through the ROS2 service mechanism to assist vehicle positioning, and responds to the map data request of the planning module to provide road topology and work area information to assist in path generation.

4. The open-pit mine unmanned vehicle terminal system architecture according to claim 3, characterized in that, The secondary functional modules corresponding to the perception module include a lidar detection component, a camera detection component, a millimeter-wave detection component, a post-fusion component, and a local update detection component; The lidar detection component, camera detection component, and millimeter-wave detection component are respectively used to process the sensor data received by the lidar, camera, and millimeter-wave radar to publish initial obstacle information. The post-fusion component is used to perform confidence-weighted fusion on the initial obstacle information and output the fused obstacle category and coordinate information; The local update detection component is used to extract road boundary information based on point cloud data acquired by LiDAR and publish it to the map management module to trigger local map updates. The fused obstacle category and coordinate information are used to characterize dynamic and static obstacle targets in the vehicle driving environment, and the road boundary information is used to characterize the geometric constraints of passable areas in the vehicle driving environment. The obstacle category and coordinate information and the road boundary information together constitute the multi-dimensional environmental perception result output by the perception module.

5. The open-pit mine unmanned vehicle terminal system architecture according to claim 3, characterized in that, The secondary functional modules corresponding to the state detection module include a vehicle state calculation component, a right-of-way component, and a self-test safety component; The vehicle state calculation component is used to subscribe to multi-source data from the positioning module, the planning module, and the chassis feedback, to construct a vehicle state matrix using a timestamp alignment algorithm, and to generate the comprehensive vehicle state based on the vehicle state matrix. The right-of-way component is used to receive the status of surrounding vehicles and right-of-way suggestions from the cloud published by the V2V module, and to calculate the right-of-way priority of the vehicle. The self-test safety component is used to subscribe to the self-test messages of each independent functional node, integrate and generate the vehicle safety fault level according to the preset fault classification strategy, and monitor collision risk.

6. The open-pit mine unmanned vehicle terminal system architecture according to claim 3, characterized in that, The secondary functional modules corresponding to the map management module include a map parsing component, a map service component, and a map writing and updating component; The map parsing component is used to parse, segment, and store high-precision semantic maps of the mining area; The map service component is used to respond to map data requests from external modules through the ROS2 service interface; The map writing and updating component is used to subscribe to the road boundary information published by the perception module, and dynamically update the local map blocks after high-precision semantic map parsing of the mining area when road changes are detected.

7. A method for controlling an unmanned vehicle in an open-pit mine, characterized in that, The method is applied to the system architecture of claim 1, and the method includes: The positioning module acquires and publishes the vehicle's location and attitude information; The perception module acquires environmental information around the vehicle and identifies obstacles to generate and publish obstacle information; The planning module generates a global path and a local trajectory based on the location and attitude information obtained from the positioning module and in conjunction with the loading task. The control module calculates control variables and issues local control commands based on the global path and local trajectory obtained from the planning module. The status detection module subscribes to the self-check messages published by the positioning module, the perception module, the planning module and the control module, integrates them to generate the vehicle safety fault level and the overall vehicle status and publishes them. The remote driving active safety module performs logical verification on the remote control commands received by the autonomous vehicle based on the subscribed comprehensive vehicle status and obstacle information, and outputs a safety intervention signal when it determines that the command poses a risk. The chassis arbitration module receives the local control command, the remote control command, and the safety intervention signal output by the remote driving active safety module, and performs priority arbitration according to the vehicle safety fault level: in the fault state, the safety intervention signal or the remote emergency stop command is executed first, and in the normal state, the local control command is executed first.

8. The unmanned vehicle terminal control method for open-pit mines according to claim 7, characterized in that, The steps for priority arbitration based on the vehicle safety fault level specifically include: The chassis arbitration module monitors the vehicle safety fault level issued by the status detection module in real time. When the vehicle safety fault level is severe, the chassis arbitration module blocks the local control commands and regular remote control commands, and only responds to the remote emergency stop command or the safety intervention signal output by the remote driving active safety module, and performs amplitude limiting protection processing on the final output control command. When the overall vehicle safety fault level is normal, the chassis arbitration module prioritizes executing the local control commands issued by the control module; if a remote control command is received at the same time, the local control command and the remote control command are compared for safety, and the control command with higher safety is output.

9. The unmanned vehicle terminal control method for open-pit mines according to claim 7, characterized in that, The method is applied to the system architecture described in claim 3, and the method further includes: The perception module extracts the boundary information of the current road based on lidar point cloud data, calculates the deviation value between the current road boundary and the boundary in the locally stored map data, and determines whether the deviation value exceeds a preset threshold. If the deviation value is determined to exceed a preset threshold, a road boundary update message is published through the ROS2 topic mechanism; The map management module subscribes to the road boundary update messages, performs update write operations on the locally stored local map tiles, records the update timestamp, and provides the updated map data to the planning module through the ROS2 service mechanism.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program. When the processor runs the computer program stored in the memory, the processor executes the open-pit mine unmanned vehicle terminal control method according to any one of claims 7 to 9.

Images