WO2021173071A1

WO2021173071A1 - A system and method for assigning a task to a fleet of vehicles

Info

Publication number: WO2021173071A1
Application number: PCT/SG2020/050094
Authority: WO
Inventors: Tat Wai David LEE; An Liang CHEW
Original assignee: Sesto Robotics Pte. Ltd.
Priority date: 2020-02-28
Filing date: 2020-02-28
Publication date: 2021-09-02
Also published as: TW202134989A

Abstract

The present invention provides a system and method that assigns vehicles to tasks with the aim of maximising payloads delivered while minimising an arbitrary cost function under constraints. This is achieved broadly by grouping tasks based on their pickup and delivery locations before assignment. This method enables the fleet of vehicles to achieve a higher throughput.

Description

A SYSTEM AND METHOD FOR ASSIGNING A TASK TO A FLEET

OF VEHICLES

FIELD OF INVENTION

The present invention relates to a system and method for assigning a task, particularly for robots used in a manufacturing and/or logistics facility. BACKGROUND

Autonomous mobile vehicles are increasingly being put into service in the next phase of the industrial evolution, whereby the vehicles are configured to navigate autonomously to their intended destinations to carry out desired tasks. This increased adoption of autonomous mobile vehicles is driven by explosive growth in the global supply chain, and a drive to increase yield/productivity using automation. The autonomous mobile vehicles can be configured to aid in addressing shortage in manual labour and to reduce errors associated with the decisions that human users make as part of the operational process. This is especially critical in a manufacturing/logistics facility as such mistakes could result in substantial monetary losses and/or down time.

When using a fleet of autonomous mobile vehicles, it is typical for the vehicles to be configured in a manner which prevents collision with each other. However, there are challenges in relation to task allocation for the respective vehicles. As the adoption of mobile vehicles increases within such facilities, proper systems to handle fleet management becomes imperative to handle the growing demands of tasks to be delivered with the existing fleet of vehicles. One option for task allocation is simply dispensing tasks to available vehicles physically closest to a location that the task should be carried out. However, such a methodology typically leads to situations whereby the fleet of vehicles is not deployed in an optimal manner. Typically, this problem can be divided into two discrete sub-problems: a) T ask Assignment - Given a set of tasks, how to efficiently assign them to a fleet of vehicles to optimise the throughput of these tasks, with consideration for the current capacity of each vehicle, the tasks assigned previously and other ambient conditions. b) Vehicle Routing - Given that a vehicle needs to visit a sequence of locations and to perform the tasks assigned to it in an appropriate manner, eg. pickup has to precede delivery, minimising distance travelled and other considerations. One of the current ways to resolve such issues comes from the domain of Operations Research (OR) using the construction of mathematical models that address each of these sub problems, either separately or as a single model. Unfortunately, there are limitations. Handling each of these problems separately reduces the potential solution space as the second problem is conditioned on the solution of the first. In addition, a single model may be too complex to yield a solution, or its computations may be too intensive to be carried out in real-time. It is evident that many challenges need to be addressed with regard to managing a plurality of vehicles within the fleet. SUMMARY

In a first aspect, there is provided a system for assigning a task to a fleet of robots, the system being enabled by at least one data processor configured to: generate, at a central server, a first list of robots that are ready for housekeeping; generate, at the central server, a second list of robots that are available for task assignment; generate, at the central server, a third list of robots that are unassigned for any tasks; determine, at the central server, if the third list is populated; determine, at the central server, if a robot from the third list can be transferred to either the first list or the second list; determine, at the central server, if the first list is populated; determine, at the central server, if the second list is populated; and transmit, to respective robots, assigned tasks and routes.

In a second aspect, there is provided a data processor implemented method for assigning a task to a fleet of robots, the method comprising: generating, at a central server, a first list of robots that are ready for housekeeping; generating, at the central server, a second list of robots that are available for task assignment; generating, at the central server, a third list of robots that are unassigned for any tasks; determining, at the central server, if the third list is populated; determining, at the central server, if a robot from the third list can be transferred to either the first list or the second list; determining, at the central server, if the first list is populated; determining, at the central server, if the second list is populated; and transmitting, to respective robots, assigned tasks and routes.

In a third aspect, there is provided a central server configured to carry out a method for assigning a task to a fleet of robots, the central server including at least one data processor configured to: generate, a first list of robots that are ready for housekeeping; generate, a second list of robots that are available for task assignment; generate, a third list of robots that are unassigned for any tasks; determine, if the third list is populated; determine, if a robot from the third list can be transferred to either the first list or the second list; determine, if the first list is populated; determine, if the second list is populated; and transmit, to respective robots, assigned tasks and routes.

It will be appreciated that the broad forms of the invention and their respective features can be used in conjunction, interchangeably and/or independently, and reference to separate broad forms is not intended to be limiting.

DESCRIPTION OF FIGURES

A non-limiting example of the present invention will now be described with reference to the accompanying drawings, in which:

FIG 1 is a first schematic view of a first system for assigning a task for a plurality of vehicles;

FIG 2 is a schematic view of an example server shown in FIG 1 ;

FIG 3 is a schematic view of an example vehicle shown in FIG 1 ;

FIG 4 is a schematic view of a second system for managing a plurality of vehicles;

FIGs 5A to 5D are flow charts of an example for a method for assigning a task for a plurality of vehicles;

FIG 6 is table of tasks to be carried out by a plurality of vehicles;

FIG 7 is a representation of how the tasks in FIG 6 relate to each other positionally;

FIG 8 is a table of tasks showing a sequence of how the tasks of FIG 6 are carried out;

FIG 9 is a table of indicating chain banks from the sequence of FIG 8; FIG 10 is a flow chart of sub-steps within step 593 of FIG 5D.

FIGs 11 A to 11B is a flow chart of sub-steps within step 1020 of FIG 10. FIG 12A to 12C is a flow chart of sub-steps within step 1030 of FIG 10. FIG 13 is a flow chart of sub-steps within step 1040 of FIG 10.

FIG 14 is a flow chart of sub-steps within step 1050 of FIG 10. DETAILED DESCRIPTION

Embodiments of the present invention provide a system and method that assigns vehicles to tasks with the aim of maximising payloads delivered while minimising an arbitrary cost function under constraints. This is achieved broadly by grouping tasks based on their pickup and delivery locations before assignment. This method enables the fleet of vehicles to achieve a higher throughput.

Accordingly, embodiments of the present invention provide users with a system and method for assigning tasks for a plurality of vehicles. When assigning the tasks, the system and method is configured to enable the plurality of vehicles to carry out the tasks in an optimal manner which minimises/avoids delays and minimises a duration to carry out the tasks.

The present invention should operate in real-time, and must consider the capacity of each vehicle and pickup/delivery locations and model them as additional constraints when making assignment decisions. It must also be capable of operating in a highly dynamic environment, where tasks are generated in an ad-hoc manner, where the vehicles are subject to external influences such as traffic congestion and delays accruing from human obstacles and other vehicles and where the availability of vehicles are contingent on the completion of previously assigned tasks.

It should be noted that in the following description, the term "vehicle" is interchangeable with the term "robot", whereby a vehicle is an object that can be controllable and/or programmable to carry out assigned tasks. In addition, the term "agent" is defined to mean a virtual entity representing a vehicle. The term “task” refers to a unit of material to be moved from a pickup location to a delivery location, while “assignment” refers to the selection of a vehicle to perform a specific task. Furthermore, the term “paired task” refers to any two tasks with a pickup and delivery location in close proximity to one another. It should be noted that close proximity can include zero which means that a common pickup and delivery location. Finally, “chained task” refers to a series of paired tasks.

An example of a first system 100 for assigning tasks for a plurality of vehicles will now be described with reference to FIG 1 . In this example, the system 100 includes a plurality of vehicles 120, a communications network 150, and a central server 170. While the central server 170 is shown to be a single processing device, it should be appreciated that the central server 170 can be a plurality of processing devices. The plurality of vehicles 120 can be configured to receive data from the central server 170, whereby the data is processed at the plurality of vehicles 120 in order to enable movement of the respective vehicles 120 such that the assigned tasks can be carried out.

The communications network 150 can be of any appropriate form, such as the Internet and/or a number of local area networks (LANs). It will be appreciated that the configuration shown in FIG 1 is for the purpose of example only, and in practice the vehicles 120, and the central server 170 can communicate via any appropriate mechanism, such as via wired or wireless connections, including, but not limited to mobile networks, private networks, such as an 802.1 1 network, the Internet, LANs, WANs, or the like, as well as via direct or point-to-point connections, such as Bluetooth, or the like.

Further details of the respective components of the system 100 will be provided in the following paragraphs. Central Server 170

The central server 170 of any of the examples herein may be formed of any suitable processing device, and one such suitable device is shown in FIG 2. The central server 170 is typically administered by, for example, a vehicle fleet management entity or a facility management entity.

The central server 170 is able to communicate with the plurality of vehicles 120, and/or other processing devices, as required, over the communications network 150 using standard communication protocols.

The components of the central server 170 can be configured in a variety of ways. The components can be implemented entirely by software to be executed on standard computer server hardware, which may comprise one hardware unit or different computer hardware units distributed over various locations, some of which may require the communications network 150 for communication. A number of the components or parts thereof may also be implemented by application specific integrated circuits (ASICs) or field programmable gate arrays.

In the example shown in FIG 2, the central server 170 is a commercially available server computer system based on a 32 bit or a 64 bit Intel architecture, and the processes and/or methods executed or performed by the central server 170 are implemented in the form of programming instructions of one or more software components or modules 222 stored on non-volatile (e.g, hard disk) computer-readable storage 224 associated with the server 170. At least parts of the software modules 222 could alternatively be implemented as one or more dedicated hardware components, such as application-specific integrated circuits (ASICs) and/or field programmable gate arrays (FPGAs).

The server 170 includes at least one or more of the following standard, commercially available, computer components, all interconnected by a bus 235:

1 . random access memory (RAM) 226;

2. at least one computer processor 228, and

3. external computer interfaces 230: a. universal serial bus (USB) interfaces 230a (at least one of which is connected to one or more user-interface devices, such as a keyboard, a pointing device (e.g, a mouse or touchpad) 232, b. a network interface connector (NIC) 230b which connects the server 170 to a data communications network 150; and c. a display adapter 230c, which is connected to a display device 234 such as a liquid-crystal display (LCD) panel device.

The server 170 includes a plurality of standard software modules, including:

1 . an operating system (OS) 236 (e.g, Linux or Microsoft Windows);

2. web server software 240 (e.g, Apache, available at http://www.apache.org);

3. scripting language modules 244 (e.g, personal home page or PHP, available at http://www.php.net, or Microsoft ASP).

Together, the web server 240, and scripting language 244, provide the server 170 with the general ability to allow devices connected to the network 150 to access the server 170 and in particular to provide data to and receive data from the database 216.

The boundaries between the modules and components in the software modules 222 are exemplary, and alternative embodiments may merge modules or impose an alternative decomposition of functionality of modules. For example, the modules discussed herein may be decomposed into submodules to be executed as multiple computer processes, and, optionally, on multiple computers. Moreover, alternative embodiments may combine multiple instances of a particular module or submodule. Furthermore, the operations may be combined or the functionality of the operations may be distributed in additional operations in accordance with the invention. Alternatively, such actions may be embodied in the structure of circuitry that implements such functionality, such as the micro-code of a complex instruction set computer (CISC), firmware programmed into programmable or erasable/programmable devices, the configuration of a field- programmable gate array (FPGA), the design of a gate array or full- custom application-specific integrated circuit (ASIC), or the like.

Each of the steps of the processes performed by the server 170 may be executed by a module (of software modules 222) or a portion of a module. The processes may be embodied in a non-transient machine- readable and/or computer-readable medium for configuring a computer system to execute the processes. The software modules may be stored within and/or transmitted to a computer system memory to configure the computer system to perform the functions of the module.

The server 170 normally processes information according to a program (a list of internally stored instructions such as a particular application program and/or an operating system) and produces resultant output information via input/output (I/O) devices 232. A computer process typically includes an executing (running) program or portion of a program, current program values and state information, and the resources used by the operating system to manage the execution of the process. A parent process may spawn other, child processes to help perform the overall functionality of the parent process. Because the parent process specifically spawns the child processes to perform a portion of the overall functionality of the parent process, the functions performed by child processes (and grandchild processes, etc.) may sometimes be described as being performed by the parent process. Vehicle 120

An exemplary embodiment of the vehicle 120 is shown in FIG 3. As shown, the vehicle 120 includes the following components in electronic communication via a bus 306:

- a location sensor 310;

- RAM 304;

- non-volatile memory 303; - an image capture component 308;

- vehicle controller 307;

- a display 302;

- a transceiver component 305 that includes N transceivers; and

- N processing components 301.

Although the components depicted in FIG 3 represent physical components, FIG 3 is not intended to be a hardware diagram; thus many of the components depicted in FIG 3 may be realized by common constructs or distributed among additional physical components. Moreover, it is certainly contemplated that other existing and yet-to-be developed physical components and architectures may be utilized to implement the functional components described with reference to FIG 3. The vehicle 120 is preferably encased in a robust chassis, and the respective components of the vehicle 120 also are preferably robust so as to be able to withstand regular impacts without being damaged. In some embodiments, the vehicle 120 is configured to carry loads, and can also be configured to dispense the loads carried by the vehicle 120 as per tasks assigned to the vehicle 120.

The location sensor 310 can be configured to receive signals from communication nodes to generate location coordinates using, for example, triangulation processes. Alternatively, in outdoor applications, the location sensor 310 can be configured to receive signals from satellites of a Global Positioning System (GPS) and/or Global Navigation Satellite System (GLONASS) network. This allows the vehicle 120 to provide its location in a form of location coordinates whenever necessary.

In general, the non-volatile memory 303 functions to store (e.g. persistently store) data (including images captured by the image capture component 308) and executable code received by and/or required by the vehicle 120 to carry out desired tasks. In some embodiments, for example, the non-volatile memory 303 includes bootloader code, modem software, operating system code, file system code, and code to facilitate the implementation of one or more portions of the method as well as other components well known to those of ordinary skill in the art that are not depicted for simplicity.

In many implementations, the RAM 304 is realized by flash memory (e.g., NAND or NOR memory), but it is certainly contemplated that other memory types may be utilized as well. Executable code in the non volatile memory 303 is typically executed by one or more of the N processing components 301 to effectuate the functional components. The image capture component 308 generally operates like a camera to capture images, such as, for example, of objects located around the vehicle 120, whereby the images can be used to determine/confirm a position of the vehicle 120.

In addition, the vehicle controller 307 provides instructions to the vehicle 120 to traverse to a desired location(s) and carry out desired tasks, for example, moving, stopping parking, loading, unloading and so forth. It should be appreciated that the instructions provided by the vehicle controller 307 can be due either to signals received from the central server 170. The vehicle controller 307 can also include a set of physical controllers on the vehicle 120.

The display 302 can be, for example, a LCD or LED panel, which can be used to display a graphical user interface for inputting instructions to the vehicle controller 307, or to display information pertaining to the vehicle 120, for example, faulty codes and status indicators.

The transceiver component 305 includes N transceiver chains, which may be used for communicating with external devices via wireless networks. Each of the N transceiver chains may represent a transceiver associated with a particular communication scheme. For example, each transceiver may correspond to protocols that are specific to local area networks, cellular networks (e.g., a CDMA network, a GPRS network, a UMTS networks), and other types of communication networks.

Referring to FIG 4, there is shown a second system 400 for generating navigation routes for a plurality of vehicles. In this example, the system 400 includes a vehicular component 402 continually interacting with an environment 416. The vehicular component 402 comprises both a virtual form 404 and a physical form 410 of vehicles or robots. By interacting with the environment 416, the vehicular component 402 is able to make appropriate decisions for each individual vehicle or robot.

The virtual form 404 is a multi-agent system, and the physical form 410 is a robotic fleet. In some instances, individual vehicles of the robotic fleet 410 are each represented virtually in the multi-agent system 404. The multi-agent system 404 is typically able to simulate movements of the robotic fleet 410 to ensure that tasks assigned to the robotic fleet 410 can be carried out.

The environment 416 typically encompasses aspects such as, for example, layout of a facility, configuration of production line, human movements at the facility, machinery placements at the facility, computing resource placements at the facility, sensor placements at the facility, and so forth.

The environment 416 typically provides inputs/percepts 412 (obtained using sensors) to the multi-agent system 404, whereby the inputs/percepts 412 includes, for example, pending tasks, path obstructions, route modifications and the like. In addition, the robotic fleet 410 also provides inputs/percepts 406 (obtained using sensors) to the multi-agent system 404, whereby the inputs/percepts 406 includes, for example, respective positions, respective states, respective actions, and so forth.

After processing the inputs/percepts 406, 412, the multi-agent system 404 transmits decisions 408 to the robotic fleet 410, the robotic fleet 410 being instructed to act on the decisions 408, which includes assigned tasks for the respective fleet units.

Consequently, when the robotic fleet 410 carries out the decisions 408, the robotic fleet 410 then provides outputs/actions 414 to the environment 416, the outputs/actions 414 including information on respective payloads, resolutions of path conflicts, obstacle avoidance routes and so forth. Subsequently, both the environment 416 and the robotic fleet 410 continually feed back the inputs/percepts 412, 406 to the multi-agent system 404, enabling appropriate decisions to be made and carried out by the vehicular component 402 in real-time.

In this regard, the system 400 is able to provide a robotic fleet which is able to allow respective fleet units to carry out assigned tasks within a facility without undesired incidents.

Referring to FIGs 5A to 5D, there is shown a preferred embodiment of a method 500 for assigning a task for at least one robot. The method 500 can be carried out in the system 100, the system 400 or any similar system. For example, the method 500 can be carried out by the central server 170. For the context of this description, it should be noted that “housekeeping activities” relates to, for example, parking of an idle robot to an available parking points which does not obstruct traffic, charging a robot to prevents scenarios of robots dying due to depleted batteries, and the like.

Firstly, a list of all robots is generated for housekeeping and task assignment to available robots (505). A first list, H is generated for robots for housekeeping purposes (510). A second list, A is generated for task assignment for the robots (515). A third list, U is generated for unassigned robots (520).

A determination is then made whether the third list, U is populated (525). If no, the method 500 proceeds to step 565. If yes, a determination is made for the robot with the highest priority, r_u (530). The priority is determined, for example, using a function containing arbitrary weights of certain factors including, for example, system states (task priority, robot battery level, robot payload capacity), environmental factors (position from robot to task), and the like. It is then determined if r_u requires charging (535) and parking (540). If it is determined that r_u requires either charging or parking, r_u is then added to the first list, H (555) and removed from the third list, U (560). If it is determined that r_u does not require either charging or parking, it is then determined if r_u has capacity to carry out a task(s) (545). If yes, r_u is added to the second list, A (550) and removed from the third list, U (560). If no, r_u is removed from the third list, U (560).

At step 565, a determination is made whether the first list H is populated. If no, the method 500 proceeds to step 585. If yes, housekeeping activities are allocated for robot at top of the first list H, (570). Subsequently, a destination is allocated to GH (575) and consequently, GH is removed from the top of first list H (580). Subsequently, the method 500 proceeds to step 565. At step 585, a determination is made whether the second list A is populated. If no, defined routes are allocated for robots that have already been deployed (590). If yes, a task assignment is allocated to a robot at top of second list A, GA (593). Subsequently, a destination is allocated to GA (596) and consequently, GA is removed from the top of second list A (599). Subsequently, the method 500 proceeds to step 585.

It should be appreciated that the method 500 is firstly used for agents, and when the agents are able to perform in the optimal manner, the relevant instructions are then transmitted to actual physical robots that are represented by the respective agents.

An illustration of the implementation of method 500 is shown in FIGs 6 to 9. FIG 6 shows a table of tasks which are to be carried out by a plurality of robots. FIG 7 is a representation of how the tasks in FIG 6 relate to each other positionally. With the application of the method 500, the tasks of FIG 6 are ordered in a manner as shown in FIG 8. FIG 9 shows the further application of the method 500 to provide chain banks for the carrying out of tasks.

Referring to FIG 10, there is shown a process flow of sub-steps of step 593 of FIG 5D, part of the method 500. At step 1010, “chain swap” is initiated to assign tasks to robot GA (1010). Generally, “chain swap” includes the process of generating a collection of chains in a chain bank, and the subsequent removal of sub-optimal chains from the chain bank. Subsequently, task mappings are obtained (1020), which is shown in FIG 8. Then, a chain bank is generated (1030), as shown in FIG 9. In addition, undesirable chains are then removed from the chain bank (1040). Undesirable chains are removed when there are non-optimal issues within the chain. Finally, a most desirable chain is selected from the chain bank (1050).

Referring to FIGs 11A to 11 B, there is shown a process flow of sub steps of step 1020 of FIG 10. At step 1110, a successor map S with i keys, where each i key corresponds to each task for assignment. At step 1120, the values of all S are initialised to be an empty list. It is then determined if all tasks in S are processed (1130). If yes, the process continues (1140). If no, a subsequent source task in S is set as t, (1150). Subsequently, all successor tasks of task t, are added to map S (1160) and ti is marked as processed (1170). It is then determined if all tasks in S are processed (1130).

Referring to FIG 11 B, there is shown a process flow of sub-steps of step 1160 of FIG 11 A. Firstly, a list of tasks, T available for assignment is generated (1190). It is then determined if all tasks for assignment in T has been evaluated (1191). If yes, the process continues (1192). If no, a subsequent task is obtained from T and set as t_j (1194). It is then determined if t_j = t, (1195). If yes, t_j is marked as evaluated (1193). If no, it is determined if pickup of tj = delivery of t, < D (1196), where D is the maximum allowable separation parameter of the pickup location from the delivery location. If yes, t_j is added to S (1197) and t_j is marked as evaluated (1193). If no, t_j is marked as evaluated (1193).

Referring to FIGs 12A to 12C, there is shown a process flow of sub steps of step 1030 of FIG 10. In FIG 12A, a chain bank B is initialised as an empty list (1205). It is then determined whether all tasks in S are evaluated for chaining (1210). If true, the process continues (1215). If false, a subsequent task is obtained and labelled t, (1220). Subsequently, a chain C is created with t, as first task in C (1225). Chain C is then populated and added to chain bank B (1230), and t, is marked as evaluated (1235). The process then proceeds to step 1210.

FIG 12B shows a process flow of sub-steps of step 1230 of FIG 12A. A last task in C is marked as t, (1250). Successive tasks of t, are obtained from S and set as s (1252). All tasks in s are then marked as un processed (1254). It is then determined if all tasks in s are processed (1256). If true, the process terminates (1258). If false, a subsequent task in s is obtained and set as tj (1266). It is then determined if tj is able to chain with C (1268). If true, tj is added to C (1270) and step 1230 is re started. If false, the process then terminates (1258). A copy of current chain C is made, and added to chain bank B (1264). t_j is then removed from C (1262) and tj is then marked as processed (1260). Step 1256 is then carried out.

Step 1268 in FIG 12B is further broken down in FIG 12C. It is determined if a length of chain C is less than an allowable chain length (1280). If false, a true output is provided (1284). If true, it is determined if t_j is already present in C (1282). If false, a true output is provided (1284). If true, a false output is provided (1286). Referring to FIG 13, there is shown a process flow of sub-steps of step 1040 of FIG 10. It is firstly determined if all chains in C are processed (1310). If true, the process continues (1320). If false, a subsequent chain in C is obtained and set as Ct (1330). It is then determined if there are expired tasks (ie. tasks that were not completed within a pre-defined time) in C_t (1340). If false, C_t is marked as processed (1360). If true, it is determined if the expired tasks are expired during to sequencing (1350). If false, C_t is marked as processed (1360). If true, C_t is removed from C (1370). Referring to FIG 14, there is shown a process flow of sub-steps of step 1050 of FIG 10. Firstly, the length of a longest chain in C is determined as n (1410). Subsequently, all chains from C shorter than length n are removed (1420). It is then determined whether there is a single chain remaining in C (1430). If false, a chain with a first task physically closest to a robot’s present position is selected and set as W. Chains are then broken with tasks created at an earlier juncture (1440). If true, the remaining chain is set as W (1450). Both steps 1440 and 1450 proceed to assigning W (1460). It should be appreciated that the method 500 ensures that robots are able to perform desired tasks in an efficient manner which requires minimal manual intervention. There are numerous checks and counter- checks implemented into method 500, and these safeguard against oversights from managing a fleet of robots. In addition, the implementation of the method 500 to agents for simulation prior to transmission to the robots ensure that instances of incidents involving the robots are minimised, consequently reducing repair/replacement costs for the owner of the robots.

The present invention can advantageously be capable of finding all possible chains up to a user configured maximum chain length, which can be extremely helpful for fleet planning and coordination.

From a broad perspective, the present invention involves: (i) generating groupings of tasks, known as chains for assignment; and subsequently; (ii) applying a set of evaluation criteria to identify optimal chains to be assigned to vehicles. The groupings are generated based on several criteria like, for example, tasks have pickup/delivery locations in close proximity to reduce the time when a vehicle is travelling without any payload, and other ad-hoc criteria (in addition to the preceding one). In addition, the chains are evaluated based on for example, time priority of tasks (chains containing tasks that have or are going to exceed their minimal time delivery window will be prioritised), cost of chains (chains that minimise costs will be preferred) and other ad-hoc criteria. In some embodiments of the present invention, a vehicle performing a chain will be able to handle a swap, whereby a vehicle performs a pickup at a location (to be delivered to another delivery location), then drops off another payload that it is already carrying at the same location. In order to cater for the swap, it is ensured that any vehicle assigned for a swap has an excess payload capacity, eg to perform an exchange of two payloads, a minimum of three payload slots is required. Therefore, it can perform an exchange using its spare capacity without requiring additional space at a location with space constraints.

Throughout this specification and claims which follow, unless the context requires otherwise, the word “comprise”, and variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated integer or group of integers or steps but not the exclusion of any other integer or group of integers.

Persons skilled in the art will appreciate that numerous variations and modifications will become apparent. All such variations and modifications which become apparent to persons skilled in the art, should be considered to fall within the spirit and scope that the invention broadly appearing before described.

Claims

1 . A system for assigning a task to a fleet of robots, the system being enabled by at least one data processor configured to: generate, at a central server, a first list of robots that are ready for housekeeping; generate, at the central server, a second list of robots that are available for task assignment; generate, at the central server, a third list of robots that are unassigned for any tasks; determine, at the central server, if the third list is populated; determine, at the central server, if a robot from the third list can be transferred to either the first list or the second list; determine, at the central server, if the first list is populated; determine, at the central server, if the second list is populated; and transmit, to respective robots, assigned tasks and routes.

2. The system of claim 1 , wherein determination of the robot transferred from the third list includes determining a priority of the robot in the third list.

3. The system of claim 2, wherein the priority of the robot is dependent on at least one of: requirement for charging, requirement for parking, and payload capacity.

4. The system of any of claims 1 to 3, wherein the tasks and routes are assigned when the first list and the second list are populated.

5. The system of claim 4, wherein the task assignment for the second list is determined by carrying out a chain swap, the chain swap comprising: obtaining task mappings for each robot; generating chain bank for each robot; removing undesirable chains from the chain bank; and selecting desirable chain from the chain bank.

6. The system of claim 5, wherein the task mappings are obtained by creating a successor map with multiple keys corresponding to each assigned task.

7. The system of claim 5, wherein the chain bank is generated by evaluating all tasks for chaining in the chain bank, and by processing tasks to determine possibility of chaining.

8. The system of claim 5, wherein the removal of undesirable chains includes processing of chains to remove expired tasks and expired assignments.

9. The system of claim 5, wherein the selection of the desirable chain is the chain with a location requirement closest to the robot.

10. A data processor implemented method for assigning a task to a fleet of robots, the method comprising: generating, at a central server, a first list of robots that are ready for housekeeping; generating, at the central server, a second list of robots that are available for task assignment; generating, at the central server, a third list of robots that are unassigned for any tasks; determining, at the central server, if the third list is populated; determining, at the central server, if a robot from the third list can be transferred to either the first list or the second list; determining, at the central server, if the first list is populated; determining, at the central server, if the second list is populated; and transmitting, to respective robots, assigned tasks and routes.

11. The method of claim 10, wherein determination of the robot transferred from the third list includes determining a priority of the robot in the third list.

12. The method of claim 11 , wherein the priority of the robot is dependent on at least one of: requirement for charging, requirement for parking, and payload capacity.

13. The method of any of claims 10 to 12, wherein the tasks and routes are assigned when the first list and the second list are populated.

14. The method of claim 13, wherein the task assignment for the second list is determined by carrying out a chain swap, the chain swap comprising: obtaining task mappings for each robot; generating chain bank for each robot; removing undesirable chains from the chain bank; and selecting desirable chain from the chain bank.

15. The method of claim 14, wherein the task mappings are obtained by creating a successor map with multiple keys corresponding to each assigned task.

16. The method of claim 14, wherein the chain bank is generated by evaluating all tasks for chaining in the chain bank, and by processing tasks to determine possibility of chaining.

17. The method of claim 14, wherein the removal of undesirable chains includes processing of chains to remove expired tasks and expired assignments.

18. The method of claim 14, wherein the selection of the desirable chain is the chain with a location requirement closest to the robot.

19. A central server configured to carry out a method for assigning a task to a fleet of robots, the central server including at least one data processor configured to: generate, a first list of robots that are ready for housekeeping; generate, a second list of robots that are available for task assignment; generate, a third list of robots that are unassigned for any tasks; determine, if the third list is populated; determine, if a robot from the third list can be transferred to either the first list or the second list; determine, if the first list is populated; determine, if the second list is populated; and transmit, to respective robots, assigned tasks and routes.