Robots have been making their way into human life. From household robots to self-driving cars and industrial robots, it is expected that the number of robots will keep increasing in the future. To cope with such growth, robot controlling systems need to be designed with scalability in mind. We took an inspiration from autonomous warehouse systems111https://amazonrobotics.com,222https://locusrobotics.com where the retrieval and storage tasks are done autonomously by mobile robots. When the system receives an order, it assigns a set of robots to retrieve shelves containing the products to a human operator for fulfillment of the order, then store the shelves back in their appropriate place.
In this paper, we only consider the problem of finding a plan for agents to reach their assigned location (i.e., goal) without collision. The problem is called Multi-Agent Path Finding (MAPF) and will be formally introduced in Section 2.1. Most existing MAPF algorithms are centralized (i.e., having a central unit overseeing the entire solving process) such as WHCA* , asprilo , and CBS . While there are attempts to improve the scalability of centralized algorithms using various techniques, such as abstraction (e.g., planning for each agent independently then combine the partial plans to obtain the solution – while resolving any conflict), dealing with MAPF problems with a large number of agents (greater than a thousand) still remains a challenge. We have designed a decentralized and distributed MAPF algorithm, named DMAPF – Distributed Multi-Agent Pathfinder – with scalability in mind. DMAPF is able to take advantage of distributed computing to cope with the possibility of having an ever-increasing problem size. An input problem to DMAPF is encoded in answer set program as generated by the ASPRILO project  and solved using mainly the answer set programming, which will be introduced in Section 2.2. The communication between distributed components in DMAPF is facilitated by the Robot Operating System (ROS), which will be introduced in Section 2.3.
DMAPF is an improvement over our original system, ros-dmapf . We address the issues in ros-dmapf where it (i) only works in maps without obstacles; and (ii) has a low success rate with dense maps. DMAPF shares the same idea with ros-dmapf in that, given a MAPF problem, it divides the problem spatially and assigns each divided subproblem to a distributed solver, which is a ROS node. The difference is that DMAPF also further divides each subproblem into disconnected regions called areas. This, together with a few other changes, allow DMAPF to deal with having obstacles. The details of problem division will be explained in Secion 3.1. After the subproblems have been distributed, each solver individually creates an abstract plan – a sequence of areas that an agent needs to visit to reach the area that contains its goal – for each agent in the given subproblem. The details of abstract plan creation will be explained in Section 3.2.1. After the plans have been made for every agent, the solvers interleave communicating with neighboring solvers to send/receive migrating agents (details in Sections 3.2.2, 3.2.3, and 3.2.5) with movement planning (details in Section 3.2.4) along each round. This differs from ros-dmapf where it does the communication from beginning to end first, then finds a movement plan for each round in a single attempt. If ros-dmapf is unable to make a plan during the movement planning phase, it would be difficult to adjust the border assignment since assignments for the next rounds have already been agreed upon, whereas DMAPF can easily adjust the assignment and retry. This, together with changes in migration protocol, allow DMAPF to achieve a higher success rate and better solution quality than ros-dmapf. DMAPF has been implemented and compared with other state-of-the-art solvers. Section 4 shows results of the comparison. Section 5 concludes with discussion on the results, advantages, limitations, and future work.
2.1 Multi-Agent Path Finding Problem
A Multi-Agent Path Finding (MAPF) problem can be defined as a quadruple , where is a graph such that is a set of vertices corresponding to locations in the graph, and denotes edges between two locations; is a set of agents; and and denote start and goal locations of the agents, respectively.
Agents can move from to where if , under the restrictions: (a) two agents cannot swap locations in a single time step; and (b) each location can be occupied by at most one agent at a time. A path for an agent is a sequence of vertices if (i) agent starts at (i.e., ); and (ii) there is an edge between any two subsequent vertices and (i.e., ), or they are the same vertex (i.e., ). An agent completes its order via a path if . A solution of a MAPF problem is a collection of paths such that all orders in are completed.
In our work, we assume that (i) each agent has a different start location (i.e., ); (ii) each agent either has no goal or has a distinct goal location (i.e., ); (iii) each agent is at its goal at the last time step (i.e., ); and (iv) the graph is grid-based. These assumptions are common among most multi-agent path finding solvers.
2.2 Answer Set Programming
Let us provide some general background on Answer Set Programming (ASP). Consider a logic language , where are sets of constants, predicate symbols, and variables, respectively, and the notions of terms, atoms, and literals are traditional.
An answer set program is a set of rules of the form
Each and is a literal from , and each is called a negation-as-failure literal (or naf-literal). can be a literal or omitted. A program is a positive program if it does not contain naf-literals. A non-ground rule is a rule that contains variables; otherwise, it is called a ground rule. A rule with variables is simply used as a shorthand for the set of its ground instances from the language . If , then the rule is called a fact. If is omitted, then the rule is called an ASP constraint.
A set of ground literals is consistent if there is no atom such that . A literal is true (resp. false) in a set of literals if (resp. ). A set of ground literals satisfies a ground rule of the form (1) if either of the following is true: (i) ; (ii) some is false in ; or (iii) some is true in . A solution of a program, called an answer set , is a consistent set of ground literals satisfying the following conditions:
If is a ground program (i.e., a program whose rules are all ground), then its answer set is defined by the following:
If does not contain any naf-literals, then is an answer set of if it is a consistent and subset-minimal set of ground literals satisfying all rules in .
If contains some naf-literals, then is an answer set of if it is an answer set of the program reduct . is obtained from by deleting (i) each rule that has a naf-literal not in its body with ; and (ii) all naf-literals in the bodies of the remaining rules.
If is a non-ground program (i.e., a program whose rules include non-ground rules), then is an answer set of if it is an answer set of the program consisting of all ground instantiations of the rules in .
The ASP language includes also language-level extensions to facilitate the encoding of aggregates (, , , etc.), range specification of variables, and allowing choice of literals. In ASP, one solves a problem by encoding it as an ASP program whose answer sets correspond one-to-one to the solutions of the problem [9, 10]. Answer sets of ASP programs can be computed using ASP solvers like clasp  and dlv .
Early ASP rests upon a single-shot approach to problem solving – an ASP solver takes a logic program, computes its answer sets, and exits. Unlike this, recently developed multi-shot ASP solvers provide operative solving processes for dealing with continuously changing logic programs. For controlling such solving processes, the declarative approach of ASP is combined with imperative means. Inclingo , this is done by augmenting an ASP encoding with C or Python procedures. The instrumentation includes methods for adding/grounding rules, setting truth values of (external) atoms, computing the answer sets of current program, etc.
2.3 Robot Operating System
The Robot Operating System
(ROS) is an open-source framework designed for building robotics systems which is distributed in nature. We adopt ROS because of its scalability and support for the development of heterogeneous clusters of software. ROS provides client libraries333Visit http://wiki.ros.org/Client%20Libraries for a full list of ROS client libraries for software written in different languages (e.g., C++, Python, Lisp) to communicate.
A ROS system must consist of a roscore at a bare minimum, and may consist of multiple ROS nodes. A roscore is a set of prerequisites to run a ROS-based system, and it consists of a ROS master among a few other things. A ROS node is an individual process that does some computation. ROS nodes working together for a particular task may be organized as a package, and they can be on different networks. For a node to communicate with another node , first needs to locate via the ROS master, then can communicate directly with as a peer-to-peer network. There are mainly two forms of communication between ROS nodes:
Publish-Subscribe – nodes are connected via a topic, which is a named bus. A node sending (resp. listening to) messages on a topic is called a publisher (resp. subscriber). One node can both be a publisher and a subscriber on the same or multiple topics. A topic may have zero or more publishers and/or subscribers.
Request-Response – two nodes follow an RPC interaction through a service. A node that provides (resp. calls) a service is called a service server (resp. service client). There can only be one service server, but possibly multiple service clients for a single service. Calls from the service clients will be put into a queue and processed one-by-one.
Algorithm 1 shows an overview of DMAPF. The algorithm takes a MAPF problem and the dimension of desired subproblems as inputs, and produces the solution if it could find one. Line 1 divides the given problem into smaller subproblems: , and provides the information telling which pairs of areas within the subproblems are connected (i.e., there exists some border between them). This step will be explained in Section 3.1. The problem can also be divided by hand as DMAPF does not put restrictions on how the subproblems have to be divided, i.e., they do not have to be rectangles of dimension . Lines 2-4 create solvers as ROS nodes with the divided subproblem as their input. How the solvers work together, which is the core of the algorithm, will be explained in Section 3.2. Solver has an extra responsibility, besides solving its own subproblem, to aggregate partial plans from all the solvers and create the solution as an output. Therefore, line 5 waits for to finish its own task of solving , combine partial plans from all the solvers, and produce the solution at line 6.
Figure 1 depicts an overview of a DMAPF system. In there, the problem has been divided into subproblems and each of them is an input to solvers , respectively. All solvers have Links information telling which pairs of them are connected. They use this information as an abstract map to find abstract plans (details in Section 3.2.1). All solvers connect to Track topic to synchronize and exchange information to determine whether they have finished their work, or if not, which of them still have work to do. Each of them also provides a Migrate service for connected solvers to call if there is any robot that needs to move between them. Solver provides Aggregate service for the other solvers to submit their plan, which constitutes a part of the solution, then it will combine them to produce the final solution.
3.1 Problem Division
Figure 2 shows a set of programs used in problem division.
The uses of these programs are controlled by a C++ implementation.
First, given a MAPF problem , as generated by the ASPRILO project , and the dimension of desired subproblems, program
base is called to determine the following atoms:
– direction that a robot can move in each time step. is a number representing the direction, which will be later used in movement planning (Section 3.2.4). In our setting, the robots can move one node at a time to either left, right, up, or down, which correspond to , , , or , respectively.
– robot has its goal at node . To restrict each robot to have at most one distinct goal, we assume that there is at most one order per robot, where the order is to pick a distinct product on a distinct shelf , which is at node at coordinate .
Subproblems are determined in an iterative manner.
Suppose , , , and are the left, right, top, and bottom-most points of a given problem , there would be a total of subproblems (if the map is rectangular).
The map of the top-left subproblem would be bounded within the range of and .
The boundaries of the other subproblems can be determined by adjusting , (resp. , ) by (resp. ).
divide is repeatedly called (with external atoms which we omit) to determine the information pertaining to each subproblem as follows:
– node is in subproblem at coordinate .
– robot starts at node which is in subproblem .
– nodes and are next to each other in subproblem .
– node is a border in subproblem .
link is then called after all the subproblems have been created from the calls to program
It determines the following atom:
– node in subproblem is next to node in subproblem . Solvers of and are considered to be neighbors if there is a link between them.
Atoms acquired from the calls to program
divide are used to determined areas within each subproblem.
An area is a region where the nodes inside are all connected.
Atoms are added to denote that node is a part of area which is in subproblem .
result is repeatedly called (with external atoms which we omit) to determine a set of information pertaining to each area as follows:
– node at coordinate is in area .
– node at coordinate is right outside of area (only one direction away).
– node is next to node , and they are in area . can be a node in either or , but can only be a node in .
– node at coordinate in area is next to node at coordinate in another area.
Each subproblem consists of information about its areas, which includes the atoms acquired from the call to program
Besides the atoms, a subproblem also contains auxiliary information such as the number of nodes in different areas (within the subproblem), a list of its neighboring areas (and their solvers), and a list of nodes that are corners (i.e., a node that connects to multiple areas) and the areas which they connect to.
A set of atoms , which denotes that areas and are connected, is the content of (in figure 1) which is an input to every solver.
3.2 Problem Solving
After a MAPF problem has been divided into subproblems as explained in Section 3.1, a solver is created for each subproblem . The solvers execute algorithm 2 in parallel to solve their own subproblem , and at the end will combine their partial plans to produce the solution of the original problem . The algorithm requires a few explanations as follows:
The lines where the first word is underlined denote that they involve communication with other solvers. Lines 9 and 30 publish a message to the Track topic. Lines 15, 17, and 20 send a migration request to the Migrate service of the solver that contains area , for each . Lines 16, 18, and 21 wait to receive a number of service calls according to the number of areas in .
The global variables: , , and (defined at line 1), are determined from the communication between solvers. keeps track of solvers that still have work to do, i.e., there is a movement plan to be made or there exists a robot that needs to migrate; and has the same content across all the solvers. (resp. ) stores areas that needs to send (resp. receive) migration requests to (resp. from). The contents of the variables are determined at lines 9 and 30 by having each solver publishes whether it still has any robot that has not reached its goal (determines ), and if so, which area they would need to leave and enter if the current area does not have their goal (determines and ). Every solver (and area) can be uniquely identified by a number (i.e., an ID). A solver (resp. area) with an ID is denoted as (resp. ). For every pair of solvers and , if , then all areas in also have smaller IDs than those in . When a solver wants to send a service request to another solver , it can only do so if – this does not mean that cannot send information to , as it can do so in the response message – RPC style. This design ensures that there is only one direction of service calls between each pair of neighboring solvers, thus reducing the overhead in communication by half.
Function (defined at line 2) maps a round (denoted as a number starting from ) to a set of area instances. An area instance (or instance, for short) consists of necessary information about everything in the area such as nodes, corners, border assignment constraints, current robots (), outgoing robots (), incoming robots (), and a movement plan. An instance can be constructed either from either (i) an area, as obtained after the problem division (line 4 and 10); or (ii) another instance (lines 22 and 31). When an instance is constructed from another instance , the information about the robots in is determined from as . The other information is straightforward to determine, so we omit the details. Lines 10 deals with the case where an instance for area has not been constructed (because area contains no robot), but there are some robot in another area that wants to migrate to – so needs to be constructed. Line 31 deals with the case where an instance needs to be constructed based on another instance of the same area in the most recent previous round; the problem is, may not have been constructed at all. If such case happens, would be constructed from area .
The algorithm revolves around the notions of (i) abstract planning (line 6); (ii) migration; and (iii) movement planning (line 19). The migration process is divided into three steps: (i) negotiation (lines 15-16); (ii) rejection (lines 17-18); and (iii) confirmation (lines 20-21). The details of each notion will be explained sequentially – as how the algorithm works – in the following subsections.
3.2.1 Abstract Planning
An abstract plan is a sequence of connected areas that takes a robot from its initial area to reach the area that contains its goal.
The program shown in figure 3 is used to make an abstract plan for a robot .
denotes that is in area at round ; and denotes that the goal of is in area .
abstract(i) is solved sequentially from or until an answer set if found.
If no answer set is found after , then we consider there is no way for to reach its goal, and the algorithm terminates.
is set to be the total number of areas across all the subproblems, so an abstract plan has to exist if it is possible for a robot to reach its goal (without considering the other robots).
Negotiation is the first phase of the migration process.
Its purpose is to find a set of distinct border assignments for migrating robots.
The program shown in figure 4 is used to make such assignments.
It is designed to minimize makespan – the time step that all robots reach their goal.
When a solver of an area sends a negotiation request to a neighboring solver of an area , the message contains a set of robots that want to migrate, called , with their current location, grouped and ordered by the number of steps left in their abstract plan to reach the last area (longest first); the result of the grouping will be referred to as tier
After receives the request from , it merges with and orders them by tier from high to low; the result of the merging will be referred to as .
It then computes two variables: the number of incoming (resp. outgoing) borders available, (resp. ).
Let , , and denote the number of pairs of connected borders between and , the number of incoming borders that have been blocked, and the number of outgoing borders that have been blocked, respectively, then , and .
Then, goes through tier-by-tier.
In each tier, if the robots are in , then they are used to create either atoms or ; otherwise, they are used to create either atoms or .
Atoms , , , and in program
migrate denote the current location of a robot.
Whether to encode the robots in (resp. ) or (resp. depends on the current number of robots that have been assigned out (resp. in), which we will refer to as (resp. ).
If the number of robots in the tier is less than or equal to (resp. ), then they are used to create (resp. ); otherwise, they are used to create (resp. .
After the robots in the considering tier have been used to create the atoms, then the value of either or is increased by the number of robots added accordingly, and the tier is removed from .
will stop going though when either (i) ; or (ii) and .
The atom in program
migrate denotes the limit – the number of robots expected to get the border assigned.
could be calculated as .
A collection of atoms , where it denotes that robot can migrate from border in its current area to border in another area and the distance from its current node to is , is obtained from program
Each atom is checked whether is in area or .
if (resp. if ) is checked whether it is a corner node (i.e., a node that connects to more than two areas); if so, a constraint
:- m(_,N1,_,_). (resp.
:- m(_,_,N2,_).) will be added, and the value of (resp. ) is increased by one.
These constraints prevent from making border assignments for the next negotiation requests (within the same round) that would result in conflict at the corners. Finally, remembers the resulting border assignments and also send them to the caller, .
Rejection is the second phase of the migration process. Its purpose is to prevent collision at corners that reside between areas with lower and higher IDs. Suppose there are three solvers: , , and , which contain areas , , and , respectively; two connected pairs of the areas: (1) and , and (2) and ; and a corner in that connects to both and . In the negotiation phase, if there are robots from and that want to migrate to , there would be requests from to , and from to . (resp. ) will take care of border assignment between and (resp. and ). This could result in a collision at because would not know which borders has assigned for the robots in to come into – the corner could be among them. The collision will happen if also assigns a robot in to come into at . In the rejection phase, every active solver checks for this case and report to the neighboring solvers their robots that will cause the collision. The reported solvers will keep the robots in their area for the current round and attempt to migrate them again in the next round, while the reporting solvers will treat them as not coming in (in this round).
3.2.4 Movement Planning
A movement plan is a sequence of movements for robots to reach their goal without collision. The program shown in figure 5 is used by every active solver to make a movement plan for its area that exists some robot that has not reached its goal or assigned border yet. It is similar to the encoding used by the ASPRILO project , except that it has the following constraints:
:- r(R,N,0), o(N,_), not m(R,_,_,1), q(t).– forces incoming robots to move into the area at the first time step ().
:- q(t), g(t), r(R,N,t), c(N), not g(R,N).– prohibits robots to stay at any node that will be migrated into unless it is their goal.
The second constraint helps to increase the success rate of DMAPF, but it could make movement planning unsuccessful unless there is sufficient free spaces in the area to enforce it. Therefore, we only add atoms when , where, for an area ; , , , and denote the number of nodes; the number of robots currently in it; the number of robots assigned to come in; and the minimum number of free nodes required, set by the user (currently ), respectively. Most of the atoms come directly from , except:
– robot is at node at time step . An atom needs to be added for each robot in the area to denote its starting node .
– denotes that there will be a robot migrating into node in the next round. The set of such nodes is determined from the result of the negotiation and the rejection phases.
movement(t) is solved sequentially from or until an answer set is found.
is set to , where is the number of nodes in area , and is a sensitivity constant set by the user (currently ).
The lower the value of is, the less chance that a movement plan will be found, but it could terminate earlier if there is actually no plan, and vice versa.
If no answer set is found after , then we consider it to be impossible to make a movement plan for the given configuration, and DMAPF will try to relax the configuration by removing the goal of a migrating robot one at a time, ordered by the Manhattan distance of the robot to its assigned border (longest first), and restarts the call to the program from .
DMAPF terminates (and returns no solution) if it cannot relax the configuration any further.
Confirmation is the third, and the last phase of the migration process. After every active solver has finished movement planning, it will send the information of all the robots that are actually able to move out to the next area, in the neighboring solver, accordingly. The information of the robots remains mostly the same, except that their abstract plan will be shorten by one step because the current area will be removed as they have already been able to move out, and their current location is updated to the border node that they will be migrating from.
Table 1 provides comparison between three MAPF solvers: (i) DMAPF; (ii) ros-dmapf ; and (iii) ECBS444https://github.com/whoenig/libMultiRobotPlanning  – a relaxed version of CBS  where the solution quality is bounded-suboptimal instead of optimal. We also tried asprilo  – an ASP encoding that solves MAPF problems optimally – but it cannot solve any of the problem instances within the timeout, so it has been excluded from the table. There are 15 problem configurations according to each row. Their map size is denoted in the first column (from the left). Each configuration contains a different number of robots according to the second column (), and each robot is randomly assigned a different goal location. The problem instances do not include obstacles because we would be unable to compare with ros-dmapf since it does not support having obstacles. The last three main columns contain results from the three solvers, which are Time – the solving time in seconds; Span – makespan of the solution; and Moves – the total number of moves from all the robots. The size of subproblems for both DMAPF and ros-dmapf is set to 8x8. The suboptimality bound for ECBS is set to . The tests were performed on Ubuntu 20.04 with Clingo 5.5.0, running on a Dell Precision-3630 Tower with Intel i9-9900K CPU and 64 GB of RAM.
24 x 24
48 x 48
96 x 96
5 Conclusion and Discussion
The experiment in Section 4 shows that, while ECBS performs very fast on the small problem instances, its performance becomes noticeably worse in a 48x48 map with 276 robots, and is unable to find the solution within the timeout in the bigger problems. ros-dmapf is generally slightly faster than DMAPF, but it is due to its simpler solver interaction protocol. It is unable to scale further when the maps get denser – in terms of the ratio between the number of robots to the number of borders within an area. When this ratio increases, there is more chance for border assignments that will result in no movement plan to be selected. Since ros-dmapf randomly assigns borders to migrating robots and cannot change the assignment afterwards, it has difficulties to scale further. The resulting makespan of DMAPF is consistent, and better than ros-dmapf due to the better border assignment mechanism, but it comes with a slight increase in the number of moves. The solution quality of ECBS is still better than the other two solvers due to its centralized nature, but not by much in many cases. We believe DMAPF can scale further given a better hardware and/or the use of clusters. To scale DMAPF even further, the question whether it is feasible to also backtrack when movement planning fails even after all the relaxation should be addressed. Mechanisms that can balance the density of robots across the areas may also be helpful.
-  Benjamin Andres, David Rajaratnam, Orkunt Sabuncu & Torsten Schaub (2015): Integrating ASP into ROS for Reasoning in Robots. In: Proceedings of the 13th International Conference on Logic Programming and Nonmonotonic Reasoning, 9345, Springer, Lexington, Kentucky, pp. 69–82, doi:10.1007/978-3-319-23264-57.
-  Max Barer, Guni Sharon, Roni Stern & Ariel Felner (2014): Suboptimal Variants of the Conflict-Based Search Algorithm for the Multi-Agent Pathfinding Problem. In: Seventh Annual Symposium on Combinatorial Search, doi:10.3233/978-1-61499-419-0-961.
-  Simona Citrigno, Thomas Eiter, Wolfgang Faber, Georg Gottlob, Christoph Koch, Nicola Leone, Cristinel Mateis, Gerald Pfeifer & Francesco Scarcello (1997): The dlv System: Model Generator and Application Frontends. In: Proceedings of the 12th Workshop on Logic Programming, 128137, pp. 128–137. Available at https://www.wfaber.com/research/papers/wlp97.pdf.
-  Martin Gebser, Roland Kaminski, Benjamin Kaufmann & Torsten Schaub (2014): Clingo = ASP + Control: Preliminary Report. In: Technical Communications of the 13th International Conference on Logic Programming, 14(4-5). Available at https://arxiv.org/abs/1405.3694.
-  Martin Gebser, Benjamin Kaufmann, André Neumann & Torsten Schaub (2007): clasp : A Conflict-Driven Answer Set Solver. In: Proceedings of the 9th International Conference on Logic Programming and Nonmonotonic Reasoning, 4483, Springer, Tempe, Arizona, pp. 260–265, doi:10.1007/978-3-540-72200-723.
-  Martin Gebser, Philipp Obermeier, Thomas Otto, Schaub Torsten, Orkunt Sabuncu, Van Nguyen & Tran Cao Son (2018): Experimenting with robotic intra-logistics domains. Theory and Practice of Logic Programming 18(3-4), pp. 502–519, doi:10.1017/S1471068418000200.
-  Michael Gelfond & Vladimir Lifschitz (1990): Logic Programs with Classical Negation. In: Logic Programming, Proceedings of the Seventh International Conference, MIT Press, Jerusalem, Israel, pp. 579–597. Available at https://dl.acm.org/doi/10.5555/87961.88030.
-  Victor W. Marek & Miroslaw Truszczynski (1999): Stable Models and an Alternative Logic Programming Paradigm. In: The Logic Programming Paradigm - A 25-Year Perspective, Springer, pp. 375–398, doi:10.1007/978-3-642-60085-217.
(1999): Logic Programs with Stable
Model Semantics as a Constraint Programming Paradigm.
Annals of Mathematics and Artificial Intelligence25(3-4), pp. 241–273, doi:10.1023/A:1018930122475.
-  Poom Pianpak, Tran Cao Son, Z O Toups & William Yeoh (2019): A Distributed Solver for Multi-Agent Path Finding Problems. In: Proceedings of the First International Conference on Distributed Artificial Intelligence, pp. 1–7, doi:10.1145/3356464.3357702.
-  Morgan Quigley, Ken Conley, Brian Gerkey, Josh Faust, Tully Foote, Jeremy Leibs, Rob Wheeler & Andrew Y. Ng (2009): ROS: an open-source Robot Operating System. In: ICRA workshop on open source software, 3, Kobe, Japan, p. 5. Available at http://www.cim.mcgill.ca/~dudek/417/Papers/quigley-icra2009-ros.pdf.
-  Guni Sharon, Roni Stern, Ariel Felner & Nathan R. Sturtevant (2015): Conflict-based search for optimal multi-agent pathfinding. Artificial Intelligence 219, pp. 40–66, doi:10.1016/j.artint.2014.11.006.
-  David Silver (2005): Cooperative Pathfinding. In: Proceedings of the 1st Artificial Intelligence and Interactive Digital Entertainment Conference, 1, Marina Del Rey, pp. 117–122. Available at https://www.aaai.org/Library/AIIDE/2005/aiide05-020.php.