System and method for scheduling tasks to a mobile robot

Abstract

A server for scheduling mobile robots to perform tasks includes a memory and a processor configured to: obtain a planning period divided into a plurality of time slots; obtain input constraints including (i) a number of mobile robots in a robot swarm, (ii) a number of docks, and (iii) a target number of active robots; obtain parameters; generate an agent for each mobile robot based on the parameters; define a work weight and a charging weight for each time slot; determine, by each respective agent, a schedule portion based on the work weight, charging weight, and parameters; the schedule portion selects, for each time slot, whether the mobile robot performs work or charging; and transmit the schedule portion to each mobile robot in response to determining that the firm conditions and the input constraints are satisfied by the schedule portion.

Description

[Background technology]

[0001] Facilities such as warehouses, manufacturing facilities, medical facilities, etc. may be deployed with autonomous or semi-autonomous mobile robots, for example, to transport items within the associated facility. Work tasks, such as instructions to travel to designated locations within the facility and retrieve particular items, may be assigned to the mobile robots by a server. While performing such work tasks, the battery levels of the mobile robots may be depleted and the mobile robots may need to be periodically recharged. Manually scheduling a fleet of robots to perform work tasks or to recharge is time-consuming and error-prone, and may result in too few robots working or the robots running out of battery. Summary of the Invention

[0002] The accompanying drawings, in which like reference numbers refer to identical or functionally similar elements throughout the separate drawings, are incorporated into and form a part of this specification and, together with the following detailed description, serve to further illustrate embodiments of the concepts that comprise the claimed invention(s) and to explain various principles and advantages of those embodiments. [Brief explanation of the drawings]

[0003] [Figure 1] FIG. 1 is a schematic diagram of a system for scheduling tasks to a mobile robot. [Figure 2] FIG. 2 is a block diagram of certain components of the mobile robot of FIG. 1. [Figure 3] FIG. 2 is a block diagram of an application 144 of FIG. [Figure 4] 1 is a flowchart of a method for scheduling tasks to a mobile robot. [Figure 5] 5 is a diagram of an exemplary work weight curve used in block 415 of the method of FIG. 4. [Figure 6]5 is a diagram of an exemplary dock weight curve used in block 415 of the method of FIG. 4. DETAILED DESCRIPTION OF THE INVENTION

[0004] Those skilled in the art will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.

[0005] Where appropriate, device and method components are represented in the drawings with conventional symbols, and only specific details relevant to understanding the embodiments of the invention are shown so as not to obscure the present disclosure with details that will be readily apparent to those skilled in the art having the benefit of the description herein.

[0006] An example disclosed herein is directed to a server comprising a memory and a processor interconnected with the memory, the processor configured to: obtain a planning horizon divided into a plurality of time slots; obtain input constraints including (i) a number of mobile robots in a robot swarm, (ii) a number of docks for charging the mobile robots, and (iii) a target number of active robots available for work in a given time slot; obtain robot parameters and generate a robot agent for each of the mobile robots based on the robot parameters; define a work weight and a charging weight for each time slot in the planning horizon; determine, by a respective robot agent, for each mobile robot, a schedule portion based on the work weight, the charging weight, and the robot parameters, wherein the schedule portion selects, for each time slot in the planning horizon, for the mobile robot to perform work or charge; and, in response to determining that the firm conditions and the input constraints are satisfied by the schedule portion, send the schedule portion to each respective mobile robot to be fulfilled during the planning horizon.

[0007] An additional example disclosed herein is directed to a method including obtaining a planning horizon divided into a plurality of time slots; obtaining input constraints including (i) a number of mobile robots in a robot fleet, (ii) a number of docks for charging the mobile robots, and (iii) a target number of active robots available for work in a given time slot; obtaining robot parameters and generating a robot agent for each of the mobile robots based on the robot parameters; defining a work weight and a charging weight for each time slot in the planning horizon; determining, by the respective robot agent, a schedule portion for each mobile robot based on the work weight, the charging weight, and the robot parameters, wherein the schedule portion selects, for each time slot in the planning horizon, for the mobile robot to perform work or charge; and, in response to determining that the firm conditions and the input constraints are satisfied by the schedule portion, transmitting the schedule portion to each respective mobile robot to perform during the planning horizon.

[0008] FIG. 1 illustrates the interior of a facility 100, such as a warehouse, manufacturing facility, medical facility, or the like. Facility 100 includes a plurality of support structures 104 that hold items 108. In the illustrated example, support structures 104 include shelving modules arranged in sets to form, for example, aisles 112-1 and 112-2 (collectively referred to as aisles 112 and collectively as aisles 112; similar nomenclature is used herein for other components). As shown in FIG. 1, support structures 104 in the form of shelving modules include support surfaces 116 that support items 108. In other examples, support structures 104 may include pegboards, containers, or the like.

[0009] In other examples, facility 100 may include fewer or more aisles 112 than those shown in FIG. 1 . In the illustrated example, the aisles 112 are formed by sets of eight support structures 104 (four on each side). However, the facility may have a variety of other aisle layouts. As will be apparent, each aisle 112 is an open-ended space bounded on both sides by support structures 104. The aisles 112 may be for movement of people, vehicles, etc. In still further examples, facility 100 may not include aisles 112, but may instead include an assembly line, etc.

[0010] The items 108 may be processed according to a variety of processes, depending on the nature of the facility 100. In some examples, the facility 100 is a shipping facility, a distribution facility, etc., and the items 108 may be placed on a support structure 104 for storage and later retrieved for shipment from the facility. The placement of the items 108 on and / or retrieval of the items 108 from the support structure may be performed or assisted by a mobile robot 120. A fleet of mobile robots 120 may be deployed at the facility 100, with the number of mobile robots 120 based on, for example, the size and / or layout of the facility 100. Components of the robot 120 are discussed in more detail below. Generally, each robot 120 in the facility 100 is configured to transport the items 108 within the facility 100.

[0011] Each robot 120 may be configured to track its pose (e.g., position and orientation) within facility 100, for example, in a coordinate system 124 pre-established for facility 100. The robot 120 may autonomously navigate within facility 100, for example, moving to locations assigned to the robot 120 to receive and / or deposit items 108. The items 108 may be deposited in or on the robot 120 and removed from the robot 120 by human workers and / or mechanical devices, such as robotic arms, deployed in facility 100. The locations to which each robot 120 navigates may be assigned to the robot 120 by a central server 128. That is, the server 128 is configured to assign tasks to each robot 120. Each task may include one or more locations to travel to and / or one or more actions to perform at those locations. For example, the server 128 may assign a task to the robot 120 to move to a defined location in the coordinate system 124 and wait at that location to receive one or more items 108 .

[0012] Because the robot 120 is mobile, the robot 120 may be battery operated and may be rechargeable at a charging dock 148. The facility 100 may have multiple docks 148 located at various locations throughout the facility 100. While performing work tasks throughout the facility 100, the batteries of the robot 120 may become depleted, and therefore, in some examples, tasks assigned to the robot 120 may include a charging task to charge at the dock 148.

[0013] Tasks may be assigned to robots 120 by exchanging messages between server 128 and robots 120 via link 130 defined by, for example, a suitable combination of a local area network and a wide area network. Server 128 may be deployed at facility 100 and may communicate with robots 120 via one or more local networks deployed within facility 100, such as a wireless local area network (WLAN). In other examples, server 128 may be located remotely from facility 100 and may communicate with robots 120 via a combination of a local area network and a wide area network. In some examples, server 128 is configured to assign tasks to robots 120 in multiple facilities.

[0014] The server 128 includes a processor 132, such as one or more central processing units (CPUs), graphics processing units (GPUs), or dedicated hardware controllers such as application specific integrated circuits (ASICs). The processor 132 is communicatively coupled to a non-transitory computer-readable medium, such as a memory 136, e.g., a suitable combination of volatile and non-volatile memory elements. The processor 132 is also coupled to a communication interface 140, such as a wireless transceiver, that allows the robot 120 to communicate with other computing devices, such as the mobile robot 120. The memory 136 may store a plurality of computer-readable instructions executable by the processor 132, such as a scheduling application 144 that, when executed by the processor 132, configures the processor 132 to schedule work tasks and charging operations for each of the mobile robots 120 in the fleet.

[0015] In particular, there may be various work scheduling and charging constraints that must be met to ensure that the fleet of robots 120 is appropriately deployed to meet the needs of the facility 100. Furthermore, in some examples, the group of robots 120 available for scheduling, such as for maintenance and / or repair operations, may be smaller than the fleet of robots in the facility 100. For example, to reduce the cost of acquiring and maintaining charging docks 148, the charging docks 148 may be fewer than the number of robots 120 in the fleet or the group of available robots 120. Furthermore, the docks 148 may not be in use at all times, as operators of the facility 100 may desire a target number of robots 120 to be active and available for work at a given time. The target number of active robots may be set based on the tasks to be performed at a given time. However, the limited number of charging docks 148, the target number of active robots, and the charging constraints and requirements of the robots 120 may complicate charging management.

[0016] Thus, the scheduling operation performed by the server 128 may schedule work tasks and charging operations for each of the robots 120 to optimize usage of the charging dock 148 (i.e., the charging dock 148 is in use as often as possible), to ensure that the robots 120 do not run out of charge while performing work tasks, and to ensure that a target number of robots 120 are available to perform work tasks at any given time. The scheduling operation may schedule work tasks and charging operations taking into account various robot charging constraints, such as ensuring that the robots 120 can obtain deep charges at their target frequency (e.g., once a week). In other examples, other facility, dock, and robot constraints are also contemplated for the scheduling operation to consider.

[0017] During operation, to schedule work tasks and charging operations for the mobile robots 120, the server 128 may generate a simulation including multiple robot agents, each representing one of the mobile robots 120 in the fleet, at least one work scheduling agent, and a dock scheduling agent. The scheduling operations may be performed over a defined planning period (e.g., one week) and divided into multiple time slots (e.g., one hour). The server 128 may then run a market-based simulation, in which the scheduling agent may generate weights for performing work and charging, while the robot agents select, based on those weights, to perform work and charging in each time slot in a schedule portion (i.e., a portion of the overall schedule specific to a given mobile robot 120 represented by the robot agent; also referred to herein as a robot plan) to optimize their individual and combined selected weights (i.e., a score represented by the combination of the work weight and the charging weight associated with the selected operation in each given time slot), taking into account various robot parameters (e.g., current charge level, battery depletion model, and other battery constraints). The server 128 may iteratively update the weights and the robot plan until the plan converges or another stopping condition is met, as described further below.

[0018] Thus, memory 136 may store various scheduling, facility, dock, and robot parameters for use in scheduling operations performed by server 128 .

[0019] Before discussing scheduling operations in more detail, certain components of the robot 120 will be discussed with reference to Figure 2. As shown in Figure 2, the robot 120 includes a chassis 200 that supports various other components of the robot 120. In particular, the chassis 200 supports a drive assembly 204, such as one or more electric motors that drive a set of wheels, tracks, etc. The drive assembly 204 may include one or more sensors, such as wheel odometers, an inertial measurement unit (IMU), etc.

[0020] The chassis 200 also supports receptacles, shelves, etc. for supporting the items 108 during transport. For example, the robot 120 may include a selectable combination of receptacles 212. In the illustrated example, the chassis 200 supports a rack 208 that includes, for example, rails or other structural features configured to support the receptacles 212 at variable heights above the chassis 200. Thus, the receptacles 212 can be installed and removed from the rack 208, thereby allowing distinct combinations of receptacles 212 to be supported by the robot 120.

[0021] The robot 120 may include an output device such as a display 216. In the illustrated example, the display 216 is mounted above the rack 208, although it will be apparent that in other examples, the display 216 may be located elsewhere on the robot 120. The display 216 may include a built-in touchscreen or other input device. In some examples, the robot 120 may include other output devices in addition to or in place of the display 216. For example, the robot 120 may include one or more speakers, lights such as a strip of light-emitting diodes (LEDs) along the rack 208, etc.

[0022] The chassis 200 of the robot 120 also supports various other components, including a processor 220, such as one or more central processing units (CPUs), graphics processing units (GPUs), or dedicated hardware controllers such as application specific integrated circuits (ASICs). The processor 220 is communicatively coupled to a non-transitory computer-readable medium, such as memory 224, such as a suitable combination of volatile and non-volatile memory elements. The processor 220 is also coupled to a communication interface 228, such as a wireless transceiver, that allows the robot 120 to communicate with other computing devices, such as a server 128 and other robots 120.

[0023] Memory 224 stores various data used for autonomous or semi-autonomous navigation, including applications 232 executable by processor 220 to perform navigation and other task-performing functions. In some examples, the above functions may be performed by multiple separate applications stored in memory 224. Execution of applications 232 may cause processor 220 to generate various operational data, such as those described above, and may store the operational data in memory 224.

[0024] Chassis 200 may support sensors 240, such as one or more cameras and / or depth sensors (e.g., lidar, depth cameras, time-of-flight cameras, etc.), coupled to processor 220. Sensors 240 are configured to capture image and / or depth data indicative of at least a portion of the physical environment of robot 120. Data captured by sensors 240 may be used by processor 220 for navigation purposes, such as path planning, obstacle avoidance, etc.

[0025] The sensors 240 have respective fields of view (FOVs). For example, a first FOV 242a corresponds to a laser scanner, such as a lidar sensor, disposed on the forward-facing surface of the chassis 200. The FOV 242a may be substantially two-dimensional, e.g., extending forward in a substantially horizontal plane. The second FOV 242b corresponds to a camera (e.g., a depth camera, a color camera, etc.) also mounted on the forward-facing surface of the chassis 200. As will be apparent, a variety of other optical sensors having respective FOVs 242 may be disposed on the chassis 200 and / or the rack 208.

[0026] Components of the robot 120 that consume power may be supplied with such power from a battery 244, for example, implemented as one or more rechargeable batteries housed in the chassis 200 and rechargeable via a charging dock 148 or other suitable charging interface.

[0027] 3, there is shown a block diagram of application 144. In particular, as noted above, to perform scheduling operations (i.e., by executing application 144), server 128 may simulate various system components of facility 100 as multiple agents.

[0028] Thus, the application 144 may include a scheduling module 300, also referred to herein as a planning module 300, which also includes a plurality of robotic agents 304-1,..., 304-n. Each robotic agent 304 represents one of the mobile robots 120 in the facility 100. The planning module 300 further includes a plurality of work scheduling agents 308-1,..., 308-m. Each work scheduling agent corresponds to a work schedule for the facility 100. For example, the facility 100 may have work schedules for various sets of tasks grouped, for example, by facility area, by task type, by project, or other suitable classification. Each work schedule may be represented by a respective work scheduling agent 308 in the simulation for scheduling operations. The planning module 300 further includes a dock scheduling agent 312 for managing the availability of docks 148 for the facility 100.

[0029] During a scheduling operation, the application 144 may invoke the planning module 300 to generate a schedule for a given planning period. The planning module 300 may then generate a schedule that assigns the robot 120 to work or charge at each time slot in the planning period. In particular, the planning module 300 may initiate the robot agent 304, the work scheduling agent 308, and the dock scheduling agent 312 to generate the schedule.

[0030] In some examples, the application 144 may additionally include a work management module 316 and a dock management module 320. After generating a schedule that assigns robots 120 to work or charge in each time slot, the work management module 316 may assign specific work tasks to specific robots 120 among the set of robots 120 assigned to work in a given time slot. For example, a specific work task may include a location to move to and one or more actions to perform at the location. Similarly, the dock management module 320 may assign specific charging tasks to specific robots 120 among the set of robots 120 assigned to charge in a given time slot. For example, a specific charging task may be the designation of a specific charging dock 148 where the robot 120 should charge, or a staging location to wait for the charging dock 148.

[0031] 4 , a method 400 for scheduling a plurality of mobile robots to perform tasks is illustrated. Method 400 is discussed below in conjunction with an example of its implementation in facility 100. In particular, method 400 is performed by server 128 through execution of application 144 by processor 132, and more specifically, through execution of planning module 300 and agents 304, 308, and 312. As described herein, performance of various functionality by agents 304, 308, and 312 may be achieved through execution by processor 132 of computer-readable instructions stored therein.

[0032] In block 405, the scheduling operation is initiated, for example, in response to a request by an operator to generate a schedule, or periodically at predetermined intervals (e.g., based on facility parameters). The planning module 300 may obtain a planning period for which a schedule is to be generated and may divide the planning period into time slots. The planning period may be a future period, or the planning period may be ongoing, for example, if the method 400 is performed to update the schedule or plan based on real-time unforeseen constraints. In such an example, the planning module 300 may obtain the planning period of the currently active schedule or plan. In another example, the request may specify the planning period and a specified length of time slots into which the planning period should be divided. In another example, a default length of time slots may be retrieved from memory 136.

[0033] The planning module 300 may additionally receive input constraints including the number of mobile robots available for the scheduling operation (i.e., the number of robots in the fleet for the scheduling operation), the number of docks available for charging the mobile robots, and a target number of active robots. For example, the request may specify a fleet of mobile robots to schedule and available docks for charging. The fleet and docks may be indicated, for example, by an operator annotating a map of the facility.

[0034] In block 410, the planning module 300 may initiate a market-based simulation. In particular, the planning module 300 may obtain robot parameters for each mobile robot 120. The robot parameters may include the current battery level of the robot 120, the last deep charge time, the target deep charge frequency, and a battery level model. In some examples, the robot parameters may additionally include work tasks and charging operations assigned to the robot 120 up to the start of the planning period to enable the planning module 300 to estimate the battery level of the robot 120 at the start of the planning period.

[0035] After obtaining the robot parameters from each mobile robot 120, the planning module 300 initializes or generates a robot agent 304 for each mobile robot 120 based on the respective robot parameters for each of the mobile robots 120 in the robot swarm.

[0036] In addition to initializing the robotic agents 304 for the simulation, the planning module 300 may additionally initialize a work scheduling agent 308 for each work schedule and a dock scheduling agent 312 for managing the docks.

[0037] Thus, in block 415, the work scheduling agent 308 and the dock scheduling agent 312 may define a work weight and a charging weight, respectively, for each time slot in the planning horizon. In particular, the work weight represents a simulated monetary or other quantitative weight for motivating the robotic agent 304 to select to perform work during the corresponding time slot. Similarly, the charging weight represents a weight for motivating the robotic agent 304 to select to perform charging during the corresponding time slot.

[0038] Each work scheduling agent 308 may define a work weight for each time slot in the planning horizon based on the tasks and / or activities scheduled in the corresponding work schedule. That is, if a work schedule includes one or more tasks for a given time slot, the corresponding work scheduling agent 308 may define a non-zero work weight for that time slot to motivate the robot 304 to select the robot 304 to perform work during that time slot. In some examples, the work weight may be calculated by the work scheduling agent 308 based on a pre-defined weight curve. For example, referring to FIG. 5, an example work weight curve 500 is shown.

[0039] The work weight curve 500 may be a symmetric function centered about the work quota 504, which represents the target number of robots committed to the work scheduling agent 308. In this example, the work weight curve 500 is a quadratic parabola that has a maximum value (i.e., the highest weight or score along the y-axis) when the number of robots committed to the work (i.e., the x-axis) equals the work quota 504. In other examples, the work weight curve 500 may be defined by other suitable functions.

[0040] To calculate the work weight for a robotic agent 304, the work scheduling agent 308 may evaluate the difference in the value of a work weight curve based on a previous iteration of the robotic plan with and without additional robots committed to the work scheduling agent 308. That is, the work weight curve 500 receives the previous iteration of the robotic plan as input and is evaluated to obtain a first weight 508 when the robotic agent 304 does not commit work for the work scheduling agent 308. That is, the first weight 508 is evaluated based on the number of robotic agents 304 that committed to the work scheduling agent 308 in the previous iteration of the simulation (i.e., based on the robotic plan determined in block 420 of the previous iteration, described further below). The work weight curve 500 is also evaluated to obtain a second weight 512 when the robotic agent 304 commits work for the work scheduling agent 308. That is, the second weight 508 is evaluated based on the number of robotic agents 304 that committed to the work scheduling agent 308 in the previous iteration of the simulation plus the robotic agents 304 requesting work weight. In the first iteration of the simulation, each of the robotic agents 304 may be assumed to have committed to the dock scheduling agent 312 to charge. The difference 516 between the weights 508 and 512 is then defined as the work weight. Other methods of calculating the work weight are also contemplated.

[0041] The dock scheduling agent 312 may define a charging weight for each time slot in the planning horizon based on dock constraints (e.g., the number of available docks 148, etc.) and to motivate as many robots 120 as possible to charge at the docks 148. In some examples, the charging weights may be calculated by the dock scheduling agent 312 based on a pre-defined charging weight curve. For example, referring to FIG. 6 , an example charging weight curve 600 is shown. The charging weight curve 600 may also receive as input a previous iteration of the robot plan to calculate the weights for the current iteration.

[0042] The charging weight curve 600 is not symmetrical in this example. The charging weight curve 600 is maximized (i.e., has the highest weight or score along the y-axis) at the number of available docks 604. That is, the charging weight curve 600 is maximized when the number of robots committed to charging (i.e., the x-axis) matches the number of available docks, and then decreases linearly to a minimum weight. The minimum weight may be selected based on the number of robots and docks to incentivize robots to dock if all docks are not in use and to prevent robots from prioritizing docking over work.

[0043] In other examples, other weighting curves may be used to enable the dock scheduling agent 312 to define suitable charging weights. Additionally, in some examples, the dock scheduling agent 312 may additionally evaluate the environmental conditions of the facility 100 (e.g., weather, which may correspond to expected temperatures) when defining charging weights. For example, because the robot 120 charges more slowly as the temperature increases, the dock scheduling agent 312 may increase the charging weight during colder periods to incentivize charging during those times.

[0044] 4, in block 420, each robotic agent 304 determines a robot plan or schedule portion, which defines the robotic agent's 304 orientation or commitment to work or charge for each time slot in the planning period. That is, for each time slot in the planning period, the robotic agent 304 selects a time slot for the mobile robot 120 to work or charge and generates a schedule portion corresponding to that mobile robot 120.

[0045] In particular, for each time slot in the planning horizon, the robotic agent 304 requests or queries the work weights and charging weights defined in block 415 from each work scheduling agent 308 and dock scheduling agent 312. The robotic agent 304 may then select whether to work or charge for each time slot based on the work weights, charging weights, and robot parameters. In particular, the robotic agent 304 may select to work or charge to optimize the combined selected weights from the work and charging weights while satisfying its battery constraints, such as not allowing the battery level to drop below a threshold (i.e., not letting its battery drain in the middle of a work task), obtaining deep charging at a target deep charging frequency, etc.

[0046] Each robotic agent 304 may determine its robot plan independently of the other robotic agents 304 based on its work weight and charge weight and its own robotic parameters, without considering the commitments of the other robotic agents 304. Thus, the optimization performed by the server 128 for each robotic agent 304 has fewer variables to consider and is therefore computationally simpler and less resource-intensive. Additionally, the robotic agents 304 may determine their respective robotic plans sequentially or in parallel.

[0047] In block 425, the robot agent 304 returns the robot plan to the planning module 300 to enable the planning module 300 to determine whether a plan confirmation condition has been detected and whether the input constraints obtained in block 405 have been satisfied.

[0048] In particular, because the robotic agents 304 determine their respective robot plans independently of each other, the determined robot plan or schedule portion may not satisfy input constraints, such as a target number of active robots. If the input constraints are satisfied, the planning module 300 may additionally consider confirmation conditions to determine whether to continue optimizing the schedule or to confirm the schedule.

[0049] The confirmation condition for allowing the planning module 300 to confirm the determined robot plan may be that the current iteration of the robot plan matches the previous iteration of the robot plan. Thus, the server 128 may perform at least two iterations of blocks 415 and 420 before confirming the robot plan. In some examples, in addition to checking that the current and previous iterations of the robot plan match, the planning module 300 may additionally check that the current and previous iterations of the task weights and charge weights (i.e., the task weights and charge weights that result in a match of the robot plan) also match. Thus, the planning module 300 may determine that a plan confirmation condition has been detected if the robot plan, task weights, and charge weights converge.

[0050] In other examples, the plan confirmation condition may be that minimum work schedule and dock constraints have been met, or other suitable conditions.

[0051] If, at block 425, the planning module 300 determines that the plan confirmation condition is not met, the method 400 returns to block 415 to update the working weights and charging weights based on the current robot plan. In particular, the planning module 300 may send the robot plan to the work scheduling agent 308 and the dock scheduling agent 312 to input the respective weight curves to update the working weights and charging weights. The server 128 may then continue to iterate determining a new robot plan and updating the working weights and charging weights until the plan confirmation condition is met.

[0052] For example, Table 1 shows an example schedule portion determined by the robot agent 304 for three robots A, B, and C to work or charge in time slots T1-T5, along with the number of active robots (i.e., the number of robots working in a given time slot).

[0053] [Table 1]

[0054] In this example, the target number of active robots may be two, and therefore time slots T2 and T4 fall short of the target number of active robots. Thus, the planning module 300 determines that the input constraints, particularly the target number of active robots, are not satisfied by this iteration of the determined schedule portion. Thus, the planning module 300 may return to block 415 and update the working weights and charging weights.

[0055] Table 2 shows an example schedule portion determined in the second iteration after the work and charge weights are updated.

[0056] [Table 2]

[0057] In the second iteration shown in Table 2, the robot agent 304 corresponding to robot A may select robot A to work rather than charge at T4 based on robot A's robot parameters and updated work weights and charging weights. Additionally, the robot agent 304 corresponding to robot C may select robot C to work rather than charge at both T2 and T4 based on robot C's robot parameters and updated work weights and charging weights. Thus, at this time, both T2 and T4 may satisfy the target number of active robots. The planning module 300 may determine that the input constraints, particularly the target number of active robots, have been satisfied by this iteration of the determined schedule portion. Therefore, the planning module 300 may check whether the determination condition has also been satisfied and may return to block 415 or proceed to block 430 accordingly.

[0058] If, at block 425, the planning module 300 determines that the plan confirmation condition is met, the method 400 proceeds to block 430. At block 430, the planning module 300 confirms a robot plan and transmits the confirmed robot plan to each respective robot 120 for execution during the planning period.

[0059] In particular, to determine a robot plan for a given robot, the planning module 300 assigns the robot 120 to work or charge during a given time slot based on the work or charge selection made by the corresponding robot agent 304 in the proposed robot plan. Additionally, the planning module 300 may assign a particular work task or charge task to the given robot 120 for each time slot in the planning period.

[0060] In some examples, after assigning each of the robots 120 to work or charge during each time slot in the planning period, the planning module 300 may additionally provide the work management module 316 with the schedules of the robots 120 assigned to the work and the time slots in the planning period in which each robot is assigned to work. The work management module 316 may then assign specific work tasks to each robot 120. For example, the work management module 316 may additionally obtain a map of the facility (e.g., from memory 136) and assign locations to navigate to and / or actions to take at the target location.

[0061] The planning module 300 may additionally provide the dock management module 320 with a schedule of the robots 120 assigned to charge and the time slots during the planned period in which each robot 120 is assigned to charge. The dock management module 320 may then assign a specific charging task to each robot 120. For example, the dock management module 320 may additionally obtain a map of the facility and assign a dock 148 in which a given robot 120 should charge and / or a staging location in which a given robot 120 should wait to charge. A staging location may be designated, for example, when a robot is not assigned to a particular dock 148 in which to charge and is not assigned to a task. In some examples, the robot 120 may be assigned to enter a low-power state (e.g., in which some of its computational processes are disabled) until its next assigned task.

[0062] The determined robot plan may then be transmitted to each robot 120. When the planning period begins, the robots 120 may fulfill their respective schedule portions by performing the tasks assigned to each time slot in the planning period.

[0063] In some examples, the server 128 may be configured to re-execute the method 400 in response to a trigger condition. For example, the trigger condition may be the expiration of a predetermined period of time, with the purpose of re-executing the method 400 periodically (e.g., every 15 minutes) to account for changes due to real-time production events. In other examples, the trigger condition may be a specific event, such as the robot 120's battery depleting more rapidly than expected based on a battery level model, various tasks being incomplete due to navigation constraints (e.g., an area being blocked), and the like. In response to detecting such a trigger condition, the server 128 may re-execute the method 400. In particular, the server 128 may obtain updated robot parameters, propose a new robot plan, and update the work weights and charge weights until the plan confirmation conditions are satisfied with the updated robot parameters. In such examples, the method 400 may be applied for the same planning period as the original plan.

[0064] In the foregoing specification, particular embodiments have been described. However, those skilled in the art will recognize that various modifications and changes can be made without departing from the scope of the invention as set forth in the following claims. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present teachings.

[0065] Benefits, advantages, solutions to problems, and any elements that may cause or make more pronounced any benefit, advantage, or solution should not be construed as critical, necessary, or essential features or elements of any or all of the claims. The present invention is defined solely by the appended claims, including any amendments made during the pendency of this application, and all equivalents of those claims at the time of issue.

[0066] Furthermore, in this document, relational terms such as first and second, upper and lower, etc., may be used merely to distinguish one entity or operation from another without necessarily requiring or implying any actual such relationship or order between such entities or operations. Terms such as "comprises," "comprising," "has," "has," "includes," "including," "contains," "containing," or any other variation thereof are intended to cover non-exclusive inclusions, and thus a process, method, article, or apparatus that comprises, has, includes, or contains a set of elements may include not only those elements, but also other elements not expressly listed or inherent to such process, method, article, or apparatus. Elements followed by "comprises," "having," "including," or "containing" do not, without further constraints, preclude the presence of additional identical elements in the process, method, article, or apparatus that comprises, has, includes, or contains the element. The term "a" is defined herein as one or more, unless expressly stated otherwise. Terms such as "substantially," "essentially," "approximately," "about," or any other variation thereof, are defined as close as would be understood by one of ordinary skill in the art, and in one non-limiting embodiment, the term is defined as within 10%, in another embodiment within 5%, in another embodiment within 1%, and in another embodiment within 0.5%. The term "coupled," as used herein, is defined as connected, although not necessarily directly, and not necessarily mechanically. A device or structure "configured" in a particular way is configured in at least that way, but may also be configured in ways not listed.

[0067] It will be understood that some embodiments may comprise one or more special-purpose processors (or "processing devices"), such as microprocessors, digital signal processors, custom processors, and field programmable gate arrays (FPGAs), as well as specific stored program instructions (including both software and firmware) that control the one or more processors to perform some, most, or all of the functions of the methods and / or apparatuses described herein in conjunction with specific non-processor circuitry. Alternatively, some or all of the functions may be performed by state machines without stored program instructions, or in one or more application-specific integrated circuits (ASICs) in which each function, or some combination of specific functions, is implemented as custom logic. Of course, a combination of the two approaches may also be used.

[0068] Furthermore, embodiments may be embodied as a computer-readable storage medium having stored thereon computer-readable code for programming a computer (e.g., comprising a processor) to perform the methods described and claimed herein. Examples of such computer-readable storage media include, but are not limited to, hard disks, CD-ROMs, optical storage devices, magnetic storage devices, ROMs (read-only memories), PROMs (programmable read-only memories), EPROMs (erasable programmable read-only memories), EEPROMs (electrically erasable programmable read-only memories), and flash memories. Furthermore, it is expected that those skilled in the art will be readily able to generate such software instructions and programs and ICs with minimal experimentation when guided by the concepts and principles disclosed herein, albeit with potentially significant effort and numerous design variations motivated, for example, by available time, current technology, and economic considerations.

[0069] The Abstract of the Disclosure is provided to enable the reader to quickly grasp the nature of the technical disclosure. It is presented with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Additionally, in the foregoing Detailed Description, it can be seen that various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in fewer than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as separately claimed subject matter.

Claims

1. 1. A server for scheduling a plurality of mobile robots in a robot swarm to perform tasks, the server comprising: Memory and a processor interconnected with said memory; Equipped with The processor: obtaining a planning period divided into a plurality of time slots; Obtaining input constraints including (i) the number of mobile robots in the robot fleet, (ii) the number of docks for charging the mobile robots, and (iii) a target number of active robots available for work in a given time slot; obtaining robot parameters and generating a robot agent for each of the mobile robots based on the robot parameters; defining a working weight and a charging weight for each time slot in the planning horizon; determining, for each mobile robot, by each robot agent, a schedule portion based on the working weight, the charging weight, and the robot parameters, wherein the schedule portion selects whether the mobile robot will work or charge for each time slot in the planning horizon; and and in response to determining that the determination conditions and the input constraints are satisfied by the schedule portion, transmitting the schedule portion to each respective mobile robot for execution during the planning period. A server configured to:

2. The server of claim 1 , wherein the firm condition comprises a current iteration of the schedule portion matching a previous iteration of the schedule portion.

3. The server of claim 2 , wherein the determination condition further comprises a current iteration of the working weights and the charging weights matching a previous iteration of the working weights and the charging weights.

4. 10. The server of claim 1, wherein the processor is further configured to assign to each mobile robot a work task for each time slot in which the robotic agent selects to perform work and a charging task for each time slot in which the robotic agent selects to perform charging.

5. The server of claim 4 , wherein the charging task includes entering a low power state at a designated staging location.

6. The server of claim 1 , wherein to determine the schedule portion, each robotic agent is configured to optimize a combined weight from the work weight and the charging weight taking into account the robot parameters.

7. The server of claim 1 , wherein the robot parameters include one or more of a current battery level, a last deep charge time, a target deep charge frequency, and a battery level model.

8. The server of claim 1 , wherein the work weights and the charging weights are defined based on a work weight curve and a charging weight curve, respectively.

9. The server of claim 8 , wherein the work weight curve and the charging weight curve receive as input a previous iteration of the schedule portion.

10. The processor: obtaining updated robot parameters in response to a trigger condition; passing the updated robot parameters to each of the robot agents to determine a new schedule portion; and and in response to determining that the determination conditions and the input constraints are satisfied by the new schedule portion, transmitting the new schedule portion to each respective mobile robot for execution during the planning period. The server of claim 1 , further configured to:

11. 2. The server of claim 1, wherein the processor is further configured, in response to determining that the deterministic condition is not satisfied by the schedule portion, to update the working weight and the charging weight based on the schedule portion until the deterministic condition is satisfied and to determine a new schedule portion.

12. The server of claim 1 , wherein the number of docks is less than the number of mobile robots in the robot fleet.

13. 1. A method for scheduling a plurality of mobile robots in a robot swarm to perform a task, the method comprising: obtaining a planning period divided into a plurality of time slots; Obtaining input constraints including (i) the number of mobile robots in the robot fleet, (ii) the number of docks for charging the mobile robots, and (iii) a target number of active robots available for work in a given time slot; obtaining robot parameters and generating a robot agent for each of the mobile robots based on the robot parameters; defining a working weight and a charging weight for each time slot in the planning horizon; determining, for each mobile robot, by each robot agent, a schedule portion based on the working weight, the charging weight, and the robot parameters, wherein the schedule portion selects whether the mobile robot will work or charge for each time slot in the planning horizon; and and in response to determining that the determination conditions and the input constraints are satisfied by the schedule portion, transmitting the schedule portion to each respective mobile robot for execution during the planning period. A method comprising:

14. The method of claim 13 , wherein the firm condition comprises a current iteration of the schedule portion matching a previous iteration of the schedule portion.

15. The method of claim 14 , wherein the determination condition further comprises a current iteration of the working weights and the charging weights matching a previous iteration of the working weights and the charging weights.

16. 14. The method of claim 13, further comprising assigning to each mobile robot a work task for each time slot in which the robotic agent selects to perform work and a charging task for each time slot in which the mobile robot selects to perform charging.

17. The method of claim 16 , wherein the charging task includes entering a low power state at a designated staging location.

18. The method of claim 13 , wherein determining the schedule portion includes optimizing a combined weight from the work weight and the charge weight taking into account the robot parameters.

19. The method of claim 13 , wherein the robot parameters include one or more of a current battery level, a last deep charge time, a target deep charge frequency, and a battery level model.

20. The method of claim 13 , further comprising defining the work weights and the charge weights based on a work weight curve and a charge weight curve, respectively.

21. The method of claim 20 , wherein the work weight curve and the charge weight curve receive as input a previous iteration of the schedule portion.

22. obtaining updated robot parameters in response to a trigger condition; passing the updated robot parameters to each of the robot agents to determine a new schedule portion; and and in response to determining that the determination conditions and the input constraints are satisfied by the new schedule portion, transmitting the new schedule portion to each respective mobile robot for execution during the planning period.

14. The method of claim 13, further comprising:

23. 14. The method of claim 13, further comprising, in response to determining that the settling condition is not satisfied by the schedule portion, updating the working weights and the charging weights based on the schedule portion until the settling condition is satisfied and determining a new schedule portion.

24. The method of claim 13 , wherein the number of docks is less than the number of mobile robots in the fleet.

Images