Autonomous mining system

Abstract

An autonomous mining system for a mining site includes a plurality of vehicles, where each vehicle has a set of features associated with the vehicle; and a central controller configured to send an indication message to a selected one of the vehicles to perform a task in the mining site, where the message identifies a capability required for the vehicle to complete the task; wherein each vehicle is configured to reject the task if the feature set of the respective vehicle does not match the capability required for the task.

Description

(19) State Intellectual Property Office (12) Invention Patent Application (10) Application Publication Number (43) Application Publication Date (21) Application Number 202480048832.2 (22) Application Date 2024.05.24 (30) Priority Data 2023901654 2023.05.26 AU (85) PCT International Application Entering National Phase Date 2026.01.23 (86) PCT International Application Application Data PCT / AU2024 / 050542 2024.05.24 (87) PCT International Application Publication Data WO2024 / 243618 EN 2024.12.05 (71) Applicant Fortescue Ltd. Address Australia (72) Inventor S. Wesker S. Moran (74) Patent Agency Beijing Linda Liu Intellectual Property Agency (General Partnership) 11277 Patent Attorneys Wang Xiaoxiang and Song Xiaowen (51) Int.Cl. G05B 19 / 418 (2006.01) E21C 35 / 00 (2006.01) E21F 13 / 00 (2006.01) G05D 101 / 10 (2006.01) G06Q 10 / 0631 (2006.01) G06Q 50 / 02 (2006.01) (54) Invention Title: Autonomous Mining System (57) Abstract: An autonomous mining system for a mining site includes: a plurality of vehicles, wherein each vehicle has a feature set associated with it; and a central controller configured to send an instruction message to a selected vehicle among the vehicles to perform a task at the mining site, wherein the message identifies the capability required by the vehicle to perform the task; wherein each vehicle is configured to reject the task if the feature set of the respective vehicle does not match the capability required by the task. Claims (3 pages), Description (10 pages), Drawings (4 pages), CN 121569254 A, 2026.02.24, CN 1 21 56 92 54 A. 1. An autonomous mining system for a mining site, comprising: a plurality of vehicles, wherein each vehicle has a feature set associated with it; and a central controller configured to send an instruction message to a selected vehicle among the vehicles to perform a task at the mining site, wherein the message identifies the capability required by the vehicle to complete the task; wherein each vehicle is configured to reject the task if the feature set of the respective vehicle does not match the capability required for the task.2. An autonomous mining system for a mining site, comprising: a plurality of vehicles, wherein each vehicle has a feature set associated with it; and a central controller configured to send an instruction message to a selected vehicle among the vehicles to perform a task at the mining site, wherein the message identifies the capabilities required by the vehicle to perform the task; wherein each vehicle is configured to accept the task if the feature set of the respective vehicle matches the capabilities required for the task. 3. The autonomous mining system of claim 1 or 2, wherein each vehicle has a local controller configured to receive and query the message sent by the central controller. 4. The autonomous mining system of claim 3, wherein, in use, the local controller of each vehicle compares the capabilities identified in the message with the feature set of the vehicle stored in the local controller. 5. The autonomous mining system of claim 3 or 4, wherein the local controller of each vehicle is configured to send a response to the central controller after the message has been queried. 6. The autonomous mining system of claim 5, wherein the response from the local controller indicates whether the task has been accepted by the corresponding vehicle. 7. The autonomous mining system of any of the preceding claims, wherein the capabilities are listed in discrete verification blocks within the message. 8. The autonomous mining system of any of claims 1 to 6, wherein the capabilities are implicitly defined in the body of the message. 9. The autonomous mining system of any of the preceding claims, wherein the capabilities are selected from a library of capabilities stored within the central controller, the library comprising records of corresponding feature sets of the plurality of vehicles. 10. The autonomous mining system of any of the preceding claims, wherein the plurality of vehicles includes a first vehicle type having a first feature set and a second vehicle type having a second feature set, wherein, in use, a task rejected by a vehicle of the first vehicle type is accepted by a vehicle of the second vehicle type if the feature set of the second vehicle matches the capabilities required by the task. 11. The autonomous mining system of any of the preceding claims, wherein the local controller of each vehicle includes a receiver. 12. The autonomous mining system of claim 11, wherein the receiver receives all task communications from the central controller. 13. The autonomous mining system of claim 11 or 12, wherein the receiver has a memory configured to store new tasks received from the central controller until the new task is ready to be performed.14. The autonomous mining system according to any one of the preceding claims, wherein each vehicle includes at least one execution module communicating with the local controller of the vehicle. 15. The autonomous mining system according to any one of claims 11 to 14, wherein each execution module of the at least one execution module performs a task assigned by the receiver. 16. The autonomous mining system according to any one of claims 11 to 15, wherein each execution module of the at least one execution module performs one task at a time. 17. The autonomous mining system according to any one of claims 14 to 16, wherein the local controller of each vehicle has a memory for storing tasks, wherein the order of tasks and the dependencies of tasks are arranged in a graph, wherein each execution module has a unique path through the graph. 18. An autonomous vehicle for use with the autonomous mining system according to any one of the preceding claims. 19. A method for operating multiple vehicles in a mining site, comprising the steps of: sending a message from a central controller to a selected vehicle among the plurality of vehicles instructing the vehicle to perform a task, the message identifying the capability required by the vehicle to perform the task; querying the message from the central controller by a corresponding vehicle to determine whether a set of features associated with the vehicle matches the capability identified in the message; and rejecting the task by the vehicle if the set of features of the vehicle does not match the capability required by the task. 20. A method for operating multiple vehicles in a mining site, comprising the steps of: sending a message from a central controller to a selected vehicle among the plurality of vehicles instructing the vehicle to perform a task, the message identifying the capability required by the vehicle to perform the task; querying the message from the central controller by a corresponding vehicle to determine whether a set of features associated with the vehicle matches the capability identified in the message; and accepting the task by the vehicle if the set of features of the vehicle matches the capability required by the task. 21. An autonomous mining system for a mining site, comprising: a plurality of machines, wherein each machine has a set of features associated with it; and a central controller configured to send instruction messages to selected machines among the machines to perform a task at the mining site, wherein the messages identify the capabilities required by the machine to perform the task; wherein each machine is configured to reject the task if the characteristic set of the respective machine does not match the capabilities required for the task.22. An autonomous mining system for a mining site, comprising a plurality of machines and a central controller configured to send instruction messages to selected machines among the machines to perform tasks in the mining site, each machine having a local controller for storing tasks in a queue, the tasks in the queue being executed sequentially by the local controller, wherein the order is specified by a plurality of rules. 23. The autonomous mining system of claim 22, wherein each machine includes a plurality of execution modules for executing tasks assigned by the local controller, wherein the plurality of rules includes at least one rule selected from the following group of rules: - each task can only be executed by one execution module; - there are no circular dependencies; - there are no parallel tasks within a particular execution module; - each execution module can only handle one root task; - for each execution module, there is only one path through a given set of tasks; and - there can be no blocking deadlocks. Claims 2 / 3 Page 3 CN 121569254 A 24. The autonomous mining system according to claim 22 or 23, wherein the local controller is programmable to ensure that the plurality of rules must be followed even if additional tasks are added to or withdrawn from the queue. 25. The autonomous mining system according to any one of claims 22 to 24, wherein the order of tasks and the dependencies of tasks are arranged in a graph that captures information about which tasks must be performed sequentially or in parallel or any combination thereof, wherein subsequent tasks are performed intermittently or in a smooth mixed manner. 26. An autonomous mining system comprising a plurality of different machines performing tasks at a mining site and a central controller instructing the machines to perform specific tasks, wherein instruction messages sent by the central controller to the machines use a common format independent of machine and task type. 27. An autonomous mining system comprising a plurality of machines performing tasks at a mining site and a central controller instructing the machines to perform specific tasks, wherein tasks to be performed by the respective machines are scheduled via a graph stored in the memory of the machine. 28. A mining method comprising the steps of: instructing machines in a mining site to perform specific tasks; utilizing the individual machines to perform a series of tasks; and utilizing the individual machines to switch between tasks in a sequence and manner scheduled via a chart stored in the memory of the machine. Claims 3 / 3 Page 4 CN 121569254 A Autonomous Mining System Technical Field

[0001] The present invention relates to a method for controlling multiple vehicles and / or associated machinery in a mining site. The present invention also relates to a system for controlling multiple autonomous vehicles and / or associated machinery in a mining site.Background Art

[0002] Unmanned, autonomous, and semi-autonomous vehicles are commonly used to perform various tasks in mining sites. These vehicles are typically controlled by a central server or by an onboard controller. The tasks that a particular vehicle can perform depend on the vehicle's capabilities. In systems with more than one type of vehicle, the capabilities of each vehicle may limit or otherwise hinder the types of tasks it can perform.

[0003] Existing systems for controlling vehicles in mining environments do not provide a general or otherwise easily extensible task interface. This means that task messages are strictly defined and inherently specific to a particular type and / or brand of vehicle. Therefore, it is often difficult to add new vehicles to such systems. Furthermore, adding new capabilities or task types to a system often requires new, customized interfaces for each new task. Understandably, such processing is time-consuming and reduces system efficiency.

[0004] A disadvantage of existing autonomous vehicle control systems is that they cannot be used for tasks to be performed in parallel. That is, each task can only be performed independently, without considering any cross-dependencies with another task. As a result, the efficiency of such vehicles is limited because tasks typically need to be completed sequentially or at least broken down into a series of discrete incremental steps.

[0005] The applicant has determined that it would be advantageous to provide improved systems and methods for controlling multiple autonomous or semi-autonomous vehicles that allow new vehicles with new functionalities to be easily added to the system.

[0006] In a preferred embodiment of the invention, the invention seeks to at least partially alleviate the above-mentioned problems or provide the public with a useful option. Summary of the Invention

[0007] According to one aspect of the invention, an autonomous mining system for a mining site is provided, comprising: a plurality of vehicles, wherein each vehicle has a feature set associated with it; and a central controller configured to send an instruction message to a selected vehicle among the vehicles to perform a task at the mining site, wherein the message identifies the capability required by the vehicle to perform the task; wherein each vehicle is configured to reject the task if the feature set of the respective vehicle does not match the capability required for the task.

[0008] According to another aspect of the invention, an autonomous mining system for a mining site is provided, comprising: a plurality of vehicles, wherein each vehicle has a feature set associated with it; and a central controller configured to send an instruction message to a selected vehicle among the vehicles to perform a task at the mining site, wherein the message identifies the capability required by the vehicle to perform the task; wherein each vehicle is configured to accept the task if the feature set of the respective vehicle matches the capability required by the task.

[0009] In some embodiments, each vehicle may have a local controller configured to receive and query the message sent by the central controller. In use, the local controller of each vehicle may compare the capabilities identified in the message with the feature set of that vehicle stored in the local controller. The local controller of each vehicle may be configured to send a response to the central controller after the message has been queried. The response from the local controller indicates whether the task has been accepted by the corresponding vehicle.

[0010] In some embodiments, the capabilities are listed in discrete verification blocks within the message. In other embodiments, the capabilities are implicitly defined in the body of the message. The capabilities may be selected from a library of capabilities stored in the central controller, the library including records of the corresponding feature sets of the plurality of vehicles.

[0011] In some embodiments, the plurality of vehicles includes a first vehicle type having a first set of features and a second vehicle type having a second set of features, wherein, in use, a task rejected by a vehicle of the first vehicle type is accepted by a vehicle of the second vehicle type if the feature set of the second vehicle matches the capabilities required for the task.

[0012] In some embodiments, the local controller of each vehicle may include a receiver. The receiver may receive all task communications from the central controller. The receiver may have a memory configured to store new tasks received from the central controller until the new task is ready to be performed.

[0013] In some embodiments, each vehicle includes at least one execution module communicating with the local controller of the vehicle. Each of the at least one execution module may execute a task assigned by the receiver. Each of the at least one execution module may execute one task at a time.

[0014] In some embodiments, the local controller of each vehicle has a memory for storing tasks, wherein the order of tasks and the dependencies of tasks are arranged in a graph, wherein each execution module has a unique path through the graph.

[0015] According to another aspect of the invention, an autonomous vehicle is provided for use with the mining system described above.

[0016] According to another aspect of the invention, a method for operating multiple vehicles in a mining site is provided, comprising the steps of: a central controller sending a message instructing a selected vehicle among the plurality of vehicles to perform a task, the message identifying the capability required by the vehicle to complete the task; a corresponding vehicle querying the message from the central controller to determine whether a feature set associated with the vehicle matches the capability identified in the message; and, if the feature set of the corresponding vehicle does not match the capability required for the task, the vehicle rejecting the task.

[0017] According to another aspect of the invention, if the feature set of the corresponding vehicle matches the capability required for the task, the step of rejecting the task can be replaced by the vehicle accepting the task.

[0018] According to another aspect of the invention, an autonomous mining system for a mining site is provided, comprising: a plurality of machines, wherein each machine has a feature set associated with it; and a central controller configured to send an instruction message to a selected machine among the machines to perform a task in the mining site, wherein the message identifies the capability required by the machine to complete the task; wherein each machine is configured to reject the task if the feature set of the respective machine does not match the capability required by the task.

[0019] According to another aspect of the invention, an autonomous mining system for a mining site is provided, comprising a plurality of machines and a central controller configured to send an instruction message to a selected machine among the machines to perform a task in the mining site, each machine having a local controller for storing tasks in a queue, the tasks in the queue being executed sequentially by the local controller, wherein the order is specified by a plurality of rules. Specification 2 / 10 Page 6 CN 121569254 A

[0020] Each machine may include multiple execution modules for executing tasks assigned by the local controller, wherein the multiple rules include at least one rule selected from the following group of rules: - Each task can only be executed by one execution module; - There are no circular dependencies; - There are no parallel tasks within a particular execution module; - Each execution module can only handle one root task; - For each execution module, there is only one path through a given set of tasks; and - There can be no blocking deadlocks.

[0021] In some embodiments, the local controller is programmable to ensure that the multiple rules must be followed even if additional tasks are added to or withdrawn from the queue. The order of tasks and the dependencies of tasks can be arranged in a graph that captures information about which tasks must be executed sequentially or in parallel (where subsequent tasks are executed intermittently or smoothly mixed) or any combination thereof.

[0022] According to another aspect of the invention, an autonomous mining system is provided, comprising a plurality of different machines performing tasks at a mining site and a central controller instructing the machines to perform specific tasks, wherein instruction messages sent by the central controller to the machines use a common format independent of machine and task type.

[0023] According to another aspect of the invention, an autonomous mining system is provided, comprising a plurality of machines performing corresponding tasks at a mining site and a central controller sending instructions to the machines to perform specific tasks, wherein tasks to be performed by the corresponding machines are scheduled via charts stored in the memory of the machines.

[0024] According to another aspect of the invention, a mining method is provided, comprising the steps of: instructing machines at a mining site to perform specific tasks; utilizing the respective machines to perform a series of tasks; and utilizing the respective machines to switch between tasks in an order and manner scheduled via charts stored in the memory of the machines. Brief Description of the Drawings

[0025] Specific embodiments of the invention will now be described only by non-limiting example and with reference to the accompanying drawings, in which: FIG1 illustrates an autonomous system for controlling vehicles at a mining site. FIG2 is a logic diagram illustrating the functional components of the system of FIG1. Figure 3 shows the local controller of the vehicle of the system of Figure 1. Figure 4 shows a first embodiment of the message forming part of the logic diagram shown in Figure 2. Figure 5 shows a second embodiment of the message forming part of the logic diagram shown in Figure 2. Figure 6 shows a task dependency diagram forming part of the logic diagram shown in Figure 2. Figure 7 is a schematic diagram of the steps of an embodiment of a method for operating multiple vehicles in a mining site. Detailed Description

[0026] In general, the present invention relates to a mining system 10 for a mining site. The system includes: a plurality of vehicles 102, wherein each vehicle 102 has a feature set 118 associated therewith; and a central controller 210 configured to send a message 212 instructing a selected vehicle among the vehicles to perform one or more tasks 216 in the mining site. The message identifies the capability required for the vehicle to satisfactorily complete the task 216. In use, if the feature set 118 of the corresponding vehicle 102 does not match the capabilities required for task 216, task 216 is rejected by that vehicle, whereas if the feature set 118 of the vehicle 102 matches the capabilities of task 216, task 216 is accepted.

[0027] In most of the following description, the mining system 10 will be described as an autonomous mining system, wherein the vehicle 102 is an autonomous vehicle. However, it should be understood that the invention is not limited to such preferred embodiments and can also be applied to semi-autonomous vehicles, or in fact, to vehicles that are substantially controlled by an onboard operator.Furthermore, it should be understood that the mining system 10 is suitable for use with other associated machinery operating in the mining site. Such machinery may include, for example, reclaimers, stackers, conveyors, robots, multi-axis arms, and custom end effectors and / or tools.

[0028] The mining system 10 will now be described in detail with reference to Figures 1 through 6.

[0029] Figure 1 illustrates a preferred embodiment of the invention, wherein a central controller 210 is arranged to wirelessly transmit messages 212 to selected mining vehicles among a plurality of mining vehicles 102 operating in the mining site. As shown, the vehicles 102 include a first mining vehicle 102a in the form of an excavator and a second mining vehicle 102b in the form of a tractor or dump truck. The central controller 210 communicates bidirectionally with the vehicles 102. This means that the mining system 10 includes a feedback system such that the controller 210 knows the status of each vehicle 102 via a response telegram 112. This feedback aids the operation of System 10 because Controller 210 uses the state of the corresponding vehicle 102 when selecting which vehicle 102 should address message 212 to. In this way, operations at the mining site can be optimized to minimize the idle and / or transit times (together representing 'non-working' time) of the corresponding vehicle 102. Note that the structure of messages 216, 216' is independent of the type of vehicle 102 operating at the mining site (in other words, message 216 has a 'generic type' format), resulting in a 'modular' or otherwise scalable System 10. This scalability of System 10 simplifies the way new vehicles and vehicle types 102 are added to System 10—essentially eliminating the need to develop custom interfaces for individual vehicles. The generic message format provides a single interface to represent all types of vehicles 102 and tasks 216 and is easily scalable. In other words, the system uses a single message structure independent of the vehicle and task type, thus reducing the effort required to introduce new instruction types based on the new vehicle and / or new task type for the reasons described above.

[0030] The operational logic of the system in Figure 1 is schematically represented in Figure 2.

[0031] As shown in Figure 3, task 216 represents a discrete instruction block to be completed by vehicle 102. Task 216 is sent from central controller 210 to the onboard control system 110 of vehicle 102. The onboard control system or local controller 110 includes two main components: receiver 124 and execution module 122, each carried by vehicle 102.

[0032] Receiver 124 receives task communications from central controller 210. A new task 216 from central controller 210 is received by receiver 124, which then assigns the corresponding task 216 to execution module 122.Receiver 124 includes a memory or buffer 120 such that incoming tasks 216 from central controller 210 are stored in receiver 124 before being assigned to the appropriate execution module 122. Referring particularly to the example shown in FIG3, four tasks 216a, 216b, 216c, and 216d are stored in the memory 120 of receiver 124.

[0033] Execution module 122 is configured to perform tasks 216 assigned to module 122 by receiver 124. Each vehicle 102 may include one or more execution modules 122. Each execution module 122 performs one task 216 at a time. Referring to the embodiment shown in FIG2, vehicle 102 includes two execution modules 122a and 122b, wherein each module 122 has two execution or job slots 116—"active job slot" 116 and "next job slot" 116'.

[0034] Referring now to FIG4, message 212 has a structure conforming to communication protocols and application programming interface standards. Message 212 is used for communication between nodes of local controller 110 and between local controller 110 and central controller 210. It is envisioned that message 212 is defined in an Interface Definition Language (IDL), which defines the data structures and interfaces used for the communication protocol. The IDL of message 212 is independent of the operating system and programming language.

[0035] The structure of message 212 is configured to capture all input parameters required to perform the desired task 216. Each message 212 (Specification 4 / 10, page 8, CN 121569254 A) identifies at least one vehicle capability 218 required for task 216. Capabilities 218 may be listed in discrete data or in a "verification" block at the header of message 212. However, preferably, the capabilities 218 required by vehicle 102 are specified within fields of the body 214 of message 212 itself. Examples of capabilities 218 required by vehicle 102 within a mining application may include "movement," "dumping," and "mode change." Capability 218 may also specify the desired speed at which the vehicle needs to move, and / or the type of terrain that the vehicle must be able to traverse. Capabilities 218 are communicated by the central controller 210 using data objects. For example, data objects may take the form of sequences and / or strings within message body 214. In the figures, three capabilities are schematically illustrated and labeled 218a, 218b, and 218c, respectively.

[0036] Capabilities 218 identified in message 212 are selected from a library or database containing records of supported feature sets for all vehicles in the mining site stored within the central controller 210. Each desired capability 218 includes a set of one or more actions 114. Actions 114 are at the lowest level of message 212 and represent specific instructions for vehicle 102.In the figure, capability 218a has three associated actions 220a-220c, capability 218b has three associated actions 220d-220f, and capability 218c has two associated actions 220g-220h.

[0037] Now moving to Figure 5. The capabilities 218 supported by vehicle 102, and therefore the tasks 216 that vehicle 102 can perform, are determined by the arrangement and configuration of the vehicle itself. Different types of vehicles 102 (e.g., vehicles of excavator 102a and dump truck 102b) are capable of performing tasks 216 that require different capabilities 218.

[0038] Each execution module 122 has at least one set of features 118 associated with it for performing the corresponding task 116. The features 118 of the vehicle correspond to the actions 114 of each capability 218. Referring particularly to the embodiment shown in the figure, vehicle 102 includes two execution modules 122a and 122b. Execution module 122a has a feature set including three features 118a-118c, while execution module 122b also has a feature set with three features (i.e., 118d-118f). A list of supported feature combinations is provided by the vehicle to the central controller 210 during vehicle initialization and is used to build a database of supported capabilities 218.

[0039] Upon receiving message 212, receiver 124 determines which capabilities 218 are associated with each execution module 122. Receiver 124 matches data between the incoming task message 212 from the central controller 210 and the data type of the execution module 122, and assigns task 216 to the appropriate execution module 122. Task 216 is matched to execution module 122 by feature combination. Each execution module 122 supports a unique set of feature combinations, and no two execution modules 122 on the same vehicle can support the same feature combinations. If message 212 contains an action combination that does not satisfy any combination of characteristics of execution module 122, then message 212 is rejected by receiver 124.

[0040] Turning now to FIG6. Task dependencies are used to control the order in which tasks are executed by execution module 122.

[0041] The order in which tasks 216 are processed by receiver 124 is specified by a number of rules. Rules are set within receiver 124. The rules followed by receiver 124 when ordering tasks 216 may include: - Each task can only be executed by one execution module 122; - There are no circular dependencies; - There are no parallel tasks within a particular execution module 122; - Each execution module 122 can only handle one root task; - For each execution module 122, there is only one path through a given set of tasks; and - There can be no blocking deadlocks.

[0042] The receiver is programmable to ensure that a selected number of these rules must be followed even when additional task 216 is added to or removed from the queue. The dependency chains of the individual tasks need to be kept intact through the task queue. A task can only be removed from the queue if the completion status of the task is no longer needed in the dependency chain.

[0043] The list of queued tasks in the memory 120 of the receiver 124 does not necessarily have to be a list of execution order, but the memory 120 can take the form of a task and dependency graph 120, in which each execution module 122 has a unique path through the graph 120, thereby effectively setting the schedule through which the execution task 216 is traversed. The graph 120 shown in the figure is a "directed graph". Each task has at least one blocking dependency relationship with another task unless it is the only task in the queue associated with a particular execution module 122. Dependencies can be used to prevent the execution of a blocked task until a certain condition is met. The condition can be that the blocked task remains blocked until the blocking task begins execution, or that the blocked task remains blocked until the blocking task has been completed. Execution completion may be due to successful task completion or task cancellation.

[0044] The above framework allows for task management of vehicles in a mining site, including the following examples: simultaneously instructing trucks and excavators using the same interface; seamless execution of sequential tasks (e.g., instructing an excavator to move from one point to another, and then to yet another point); and parallel execution of compatible tasks (e.g., instructing a truck to move while dumping). For example, successful trials performed by the applicant included instructing haul trucks to move around the mining site and instructing train trucks to perform movement and dumping tasks.

[0045] Task graph 120 allows individual vehicles to track or otherwise schedule their tasks and execute them efficiently. Task graph 120 implements and communicates task execution order, task mixing for smooth transitions between tasks, and parallel task execution for complex robot behaviors. The task graph links tasks to other tasks based on the dependencies between individual tasks. When combined with execution module 122, conditional control regarding dependencies is used to mix and parallelize tasks. While some tasks can be performed in parallel (e.g., movement and taking pictures), others cannot (e.g., driving to two locations at once). When task 216 is performed by vehicle 102, execution module 122 will be used, matching the combination of features from message 212. In summary, it should be understood that the advantage of task graph 120 is that it provides a particularly robust way to smoothly transition from one task to another and / or to perform tasks in parallel.

[0046] Each message 212 sent from the central controller 210 to the corresponding local controller 110 may include the following commands within the message body 214. The "Insert" command can be used to insert a task into the task queue. This command uses the dependencies provided in message 212 to determine where the task is located in the task graph 120. The task can be inserted in the middle of graph 120 or appended to the end of the execution module task path. The "Replace" command can be used to replace a task already in the task queue. Flags in the replacement command can be used to determine whether dependencies associated with the replaced task should be transferred to the new task. Even if the old task dependencies are transferred, the dependencies provided in the new task are used. The "Remove" command can be used to remove one or more tasks from the task queue. The "Clear" command can be used to clear the queue of all tasks.

[0047] The task graph 120 shown in Figure 6 provides an example of the task graph's ability to provide the central controller 210 with detailed information about the behavior and / or status of the vehicle. In other words, Figure 120 captures information about which tasks must be executed sequentially or in parallel (where subsequent tasks are executed intermittently or smoothly mixed sequentially) or any combination thereof. Referring specifically to the illustrated embodiment, the vehicle will operate in the following manner: Task 216b will begin immediately after task 216a and execute in parallel because the two tasks 216a and 216b are linked with a "start-time" dependency and are served by different execution modules 122a and 122b. Task 216a will smoothly transition to another task 216d, where tasks 216a and 216d are also linked with a "start-time" dependency and are served by the same execution module 122a. Task 216c will only begin when task 216b completes because tasks 216b and 216c are linked with a "completion-time" dependency. Furthermore, once task 216c has completed, task 216d will smoothly transition to task 216e. If task 216d is completed before task 216c, then task 216e will be held until task 216c is completed and no smooth transition will occur. Specification 6 / 10 pages 10 CN 121569254 A

[0048] If task graph 120 is modified by new message 212, task dependencies can be updated. For example, if a corresponding task is canceled, its dependencies are inherited by downstream tasks. This means that if a task has a dependency on a canceled task, it will inherit the dependency of the canceled task. After task graph 120 has been modified, it will be checked for redundant dependencies. Any redundant dependencies will be removed from task graph 120. After task graph 120 has been checked for redundancy, task graph 120 will be checked for errors that would render task graph 120 invalid.Examples of errors that could lead to an invalid task graph 120 include cyclic task dependencies, parallel tasks on an execution module 122, and more than one execution path through the graph for a particular execution module 122.

[0049] Communication from receiver 124 to the corresponding execution module 122 of vehicle 102 may include the following commands. A “Load” command may be used to load a new task. This may also be used to overwrite any tasks queued for execution next. A “Cancel” command may be used to cancel one or more tasks based on the unique identifier of each task. This command may be used to cancel an in-use task, a task to be executed next, or both.

[0050] Receiver 124 may determine when to send a task to be loaded into execution module 122 based on the blocking status of a task. Execution module 122 does not consider task blocking because execution module 122 itself does not need or necessarily know task dependencies. Instead, each execution module 122 may only need information about at most two tasks stored in job slots 116 (“In-use Job” 116 and “Next Job” 116'). The current job slot 116 contains the currently executing task, and the next job slot 116' contains the next task to be executed. If a task is loaded into the next job slot, it is assumed that the task in the current job 116 is allowed to be transferred to the task in the next job slot 116'. Each execution module 122 may execute one task at a time, but the vehicle 102 may include one or more execution modules 122. The execution modules 122 may then work in parallel to achieve synchronous task execution.

[0051] The task 216 from the receiver 124 is only loaded into the next job slot 116' on the execution module 122. Whether a task is successfully loaded into the next job task 116' does not depend on the contents of the next job slot 116' or the current job slot 116. If tasks can be merged and the task in the current job slot 116 is being executed, or if the task in the current job slot 116 is in a completed state, the task in the current job slot 116 is only replaced by the task in the next job slot 116'. If execution module 122 supports merging from the current job slot 116 to the next job slot 116', the tasks therein will be merged as soon as possible. If the current job slot 116 is empty, the tasks in the next job slot 116' can be loaded into the current job slot 116.

[0052] Now returning to FIG3. The status of each task is reported from execution module 122 to receiver 124 via feedback 114, and then from receiver 124 to central controller 210 in response to telegram 112. The structure of response telegram 112 is similar to message 212. The feedback 114 returned in response telegram 112 includes the status value of the current task and may include metadata of the next task.The response telegram 112 transmitted from receiver 124 to central controller 210 contains a sequence of the statuses of all tasks known to receiver 124, and includes a current dependency graph 120.

[0053] System 10 is scalable. This means that the system architecture is designed to make inclusion of vehicles with new functionality simple. This scalability is preferable to existing systems, where OEM vehicles have associated custom communication interfaces for each required task type. If a custom interface is required, the following steps will be required each time a new task is defined. The system will have to be adapted to support the new functionality and updated to support the new custom interface. The link between central controller 210 and local controller 110 will need to be modified to support the new interface. Each new task will need to define the parameters of the task in a custom script. Finally, the vehicle's onboard receiver will need to be updated to be able to read from the new interface, and execution modules will need to be created or adapted to handle the new task. It should be understood that in some cases, successful integration of system 10 may require minor rework of the OEM software.

[0054] In the case of the autonomous system 10 used in a mining site, the following steps are taken each time a new task is defined. System Specification 7 / 10 Page 11 CN 121569254 A 10 is adapted to support the new functionality. Extend message 212 to add additional parameters for the new task. Finally, create or adjust execution module 122 to handle the new task.

[0055] As described above, the autonomous system 10 used in a mining site requires less rewriting of the system infrastructure to accommodate new tasks. Duplication of code elements is avoided because it is not necessary to copy tasks just to add new attributes 218 and / or actions 220. Since receiver 124 discovers the dynamic task definition of execution module 122, receiver 124 does not require any software changes.

[0056] For example, if a new type of vehicle (such as a water truck designed to spray water on soil or gravel roads to suppress dust, etc.) is added to the system, the new capability 218 is added to message 212. In this case, the new capability 218 will include a set of actions 220 associated with the water spraying function. Task 216 for this action will also include a list of path segments defining the locations where the truck must spray. These segments may differ from the path the truck follows, as it may only be necessary to spray a portion of the road. In this embodiment, message 212 will be modified to add water spraying capability to the task—thus ensuring that the task is only accepted for action by vehicles with the necessary feature set 118. The remainder of message 212 will otherwise be substantially the same as messages for other types of vehicles traveling along the same road.

[0057] A method 300 for operating multiple vehicles in a mining site will now be described with reference to FIG7.It should be understood that even though the autonomous system 10 has been specifically designed for use in mining sites, the autonomous system can also be adapted for use in unrelated applications.

[0058] In the initial step 310 of operating multiple vehicles in a mining site, a message 212 is sent from the central controller to the selected vehicle 102. The message 212 includes instructions for the vehicle 102 to perform task 216. Within the body 214 of the message 212, the required capabilities 218 for the vehicle 102 to perform task 216 are identified. During this step 310, it should be understood that the central controller 210 can select the vehicle 102 based on various attributes, including the required capabilities 218 for task 216, the state of the vehicle 102 (i.e., active or stationary), and the location or proximity of the vehicle 102 to the destination or work area of ​​task 216 in the work site. In an alternative embodiment, it should be understood that message 212 may be broadcast to multiple vehicles 102, wherein the corresponding local controller 110 of the vehicle processes message 212 before selecting to accept or reject task 216.

[0059] In a subsequent step 320, the targeted vehicle 102 queries message 212 to determine whether its feature set 118 matches the capability 218 identified in message 212—and more specifically, the action 220 associated with the identified capability 218. For example, if the capability identified in the message includes “spraying” and “refilling”, then message 212 is for a truck capable of spraying water on the road. Alternatively, if the identified capability 218 includes “digging”, “steering”, and “releasing”, then the message is for an excavator.

[0060] A truck suitable for spraying will not include these features for “digging”, “steering”, and “releasing” in its feature set. Similarly, “spraying” and “refilling” will not be included in the feature set of an excavator. If the feature set 118 of the vehicle does not match the capabilities 218 required by task 216 for vehicle 102, the vehicle will reject message 212 in rejection step 340.

[0061] Alternatively, if the feature set of the vehicle does match the capabilities and features required by the task, the vehicle will accept message 212 in acceptance step 330. That is, if the capabilities 218 included in the message match the features 118 of the vehicle, the message will be accepted by vehicle 102.

[0062] In summary, it should be understood that the mining system described herein provides an improved mining method that enables improved, cost-effective, and substantially autonomous mining operations. This is achieved at least in part by providing a central controller configured to send instruction messages to selected vehicles among a plurality of vehicles, each of which has a unique feature set associated with it.Each vehicle has an onboard local controller, as described in this specification (pages 8 / 10, CN 121569254 A). The local controller is configured to reject a message if the vehicle is unable to perform the task indicated by the message. This “two-way” feedback between the central controller and the vehicles means that the structure of the messages is essentially generic, or independent of the vehicle type and capability. In this way, the resources and effort associated with operating an autonomous mining site are reduced—this provides improved scalability of the system, particularly by simplifying the steps required to add additional vehicles and capabilities to the system. Furthermore, while existing systems typically use separate message formats for different task types, the mining system described herein uses a single, uniform message format to represent all tasks and vehicle types, and is therefore easily scalable.

[0063] References to any prior publications (or information derived therefrom) or to any known matters in this specification are not and should not be construed as an endorsement or acknowledgment or any form of advice that such prior publications (or information derived therefrom) or known matters form part of the general knowledge in the field of effort covered by this specification.

[0064] In this specification and the appended claims, unless the context otherwise requires, the word "comprise" and variations such as "comprises" and "comprising" will be understood to imply inclusion of the said whole or step or whole or group of steps, but do not exclude any other whole or step or whole or group of steps. Reference Numerals Specification 9 / 10 Page 13 CN 121569254 A Specification 10 / 10 Page 14 CN 121569254 A Figure 1 Specification Drawing 1 / 4 Page 15 CN 121569254 A Figure 2 Figure 3 Specification Drawing 2 / 4 Page 16 CN 121569254 A Figure 4 Figure 5 Specification Drawing 3 / 4 Page 17 CN 121569254 A Figure 6 Specification Drawing 4 / 4 Page 18 CN 121569254 A.

Claims

1. An autonomous mining system for use in a mining site, comprising: A plurality of vehicles, each having a set of features associated with it; and a central controller configured to send instruction messages to selected vehicles among the vehicles to perform a task at the mining site, wherein the messages identify the capabilities required by the vehicle to perform the task; wherein each vehicle is configured to reject the task if the characteristic set of the respective vehicle does not match the capabilities required for the task.

2. An autonomous mining system for use in a mining site, comprising: A plurality of vehicles, each having a set of features associated with it; and a central controller configured to send instruction messages to selected vehicles among the vehicles to perform a task at the mining site, wherein the messages identify the capabilities required by the vehicle to perform the task; wherein each vehicle is configured to accept the task if the characteristic set of the respective vehicle matches the capabilities required for the task.

3. The autonomous mining system according to claim 1 or 2, wherein, Each vehicle has a local controller configured to receive and query the messages sent by the central controller.

4. The autonomous mining system according to claim 3, wherein, In use, the local controller of each vehicle will compare the capabilities identified in the message with the feature set of that vehicle stored in the local controller.

5. The autonomous mining system according to claim 3 or 4, wherein, The local controller of each vehicle is configured to send a response to the central controller after the message has been queried.

6. The autonomous mining system according to claim 5, wherein, The response from the local controller indicates whether the task has been accepted by the appropriate vehicle.

7. The autonomous mining system according to any one of the preceding claims, wherein, The capabilities are listed in the discrete verification block within the message.

8. The autonomous mining system according to any one of claims 1 to 6, wherein, The capability is implicitly defined in the body of the message.

9. The autonomous mining system according to any one of the preceding claims, wherein, The capability is selected from a library of capabilities stored within the central controller, the library comprising records of corresponding feature sets of the plurality of vehicles.

10. The autonomous mining system according to any one of the preceding claims, wherein, The plurality of vehicles includes a first vehicle type having a first set of features and a second vehicle type having a second set of features, wherein, in use, when the feature set of the second vehicle matches the capabilities required for the task, a task rejected by a vehicle of the first vehicle type is accepted by a vehicle of the second vehicle type.

11. The autonomous mining system according to any one of the preceding claims, wherein, Each vehicle's local controller includes a receiver.

12. The autonomous mining system according to claim 11, wherein, The receiver receives all task communications from the central controller.

13. The autonomous mining system according to claim 11 or 12, wherein, The receiver has a memory configured to store new tasks received from the central controller until the new task is ready to be performed.

14. The autonomous mining system according to any one of the preceding claims, wherein, Each vehicle includes at least one execution module that communicates with the local controller of that vehicle.

15. The autonomous mining system according to any one of claims 11 to 14, wherein, Each execution module in the at least one execution module performs the task assigned by the receiver.

16. The autonomous mining system according to any one of claims 11 to 15, wherein, Each of the at least one execution module executes one task at a time.

17. The autonomous mining system according to any one of claims 14 to 16, wherein, The local controller of each vehicle has a memory for storing tasks, wherein the order of tasks and the dependencies of tasks are arranged in a graph, and each execution module has a unique path through the graph.

18. An autonomous vehicle for use with an autonomous mining system according to any one of the preceding claims.

19. A method for operating multiple vehicles in a mining site, comprising the following steps: The central controller sends a message to a selected vehicle among the plurality of vehicles, instructing the vehicle to perform a task, the message identifying the capability required for the vehicle to complete the task; The corresponding vehicle queries the message from the central controller to determine whether the feature set associated with the vehicle matches the capability identified in the message; as well as If the feature set of the corresponding vehicle does not match the capabilities required for the mission, the vehicle shall reject the mission.

20. A method for operating multiple vehicles in a mining site, comprising the following steps: The central controller sends a message to a selected vehicle among the plurality of vehicles, instructing the vehicle to perform a task, the message identifying the capability required for the vehicle to complete the task; The corresponding vehicle queries the message from the central controller to determine whether the feature set associated with the vehicle matches the capability identified in the message; as well as The mission is accepted by the corresponding vehicle when its feature set matches the capabilities required for the mission.

21. An autonomous mining system for use in a mining site, comprising: A plurality of machines, each having a set of features associated with that machine; and a central controller configured to send instruction messages to selected machines among the machines to perform a task at the mining site, wherein the messages identify the capabilities required for the machine to complete the task; wherein each machine is configured to reject the task if the characteristic set of the respective machine does not match the capabilities required for the task.

22. An autonomous mining system for a mining site, comprising a plurality of machines and a central controller configured to send instruction messages to selected machines among the machines to perform tasks at the mining site, each machine having a local controller for storing tasks in a queue, the tasks in the queue being executed sequentially by the local controller, wherein... The order is specified by multiple rules.

23. The autonomous mining system according to claim 22, wherein, Each machine includes multiple execution modules for performing tasks assigned by the local controller, wherein the multiple rules include at least one rule selected from the following rule group: -Each task can only be executed by one execution module; - There is no circular dependency; - No parallel tasks exist within a specific execution module; -Each execution module can only handle one root task; - For each execution module, there exists only one path through a given set of tasks; and - There cannot be a blocking deadlock.

24. The autonomous mining system according to claim 22 or 23, wherein, The local controller is programmable to ensure that the multiple rules must be followed even if additional tasks are added to or withdrawn from the queue.

25. The autonomous mining system according to any one of claims 22 to 24, wherein, The order and dependencies of tasks are arranged in a diagram that captures information about which tasks must be performed sequentially or in parallel, or any combination thereof, wherein subsequent tasks are performed intermittently or in a smooth, mixed manner.

26. An autonomous mining system comprising multiple different machines performing tasks at a mining site and a central controller instructing said machines to perform specific tasks, wherein, Instruction messages sent from the central controller to the machine use a generic format that is independent of machine and task type.

27. An autonomous mining system comprising multiple machines performing tasks at a mining site and a central controller instructing said machines to perform specific tasks, wherein, Tasks to be performed by the corresponding machine are scheduled via a chart stored in the machine's memory.

28. A mining method comprising the following steps: Instructing machines at the mining site to perform specific tasks; To perform a series of tasks using various machines; as well as The tasks are switched between them using the order and manner in which they are scheduled via charts stored in the memory of each machine.

Images