We explain some heuristics used by the Shadoks team to solve the CG:SHOP 2021 challenge that considers a coordinated motion planning problem in the two-dimensional grid . The goal is to move a set of labeled unit squares called robots between given start and target grid cells without collisions.
More formally, the input consists of a set of obstacles and a set of robots . Each obstacle is a lattice point and each robot is a pair of lattice points respectively called start and target. A path of length is a sequence of lattice points for a time . A solution of makespan is an assignment of paths of length to each robot satisfying the following constraints.
and for ,
for and ,
for and ,
(collision constraint) for and , and
(overlap constraint) if then .
The objective of the problem is to minimize the makespan222The challenge also considered the objective of minimizing the sum of the distances, but we did not optimize our solutions for this version of the problem. . A trivial lower bound is obtained by ignoring constraints (iv) and (v) and finding shortest paths. Since the problem is symmetric with respect to the time, we may always exchange start-target positions and reverse the paths, keeping the best solution found. For more details about the problem, see the overview  and the related paper .
The challenge CG:SHOP 2021 provided instances containing between and robots, out of which of our solutions were the best ones among all the teams who participated. To our surprise, we succeed in finding solutions that match the trivial lower bound.
The multi-agent path finding problem (MAPF) has been well studied over the last 20 years. This problem occurs in many industrial applications that involve agents that have to reach destinations without colliding with each other . For instance, in automated warehouses , autonomous vehicles, and robotics . Well-studied approaches include search-based solvers (for instance: HCA* ) that make plans agent by agent according to a predefined agent order. When an agent is scheduled, it “reserves” times and locations and the algorithm schedules the next agent. They can also plan all robots at the same time, thus having for each time-step up to possibilities (for instance: Enhanced Partial Expansion A* ). We may also cite rule-based solvers that identify scenarios and apply rules to move agents, for instance the push-and-rotate algorithm 
. Some algorithms model the MAPF problem using network flows, integer linear programs, or SAT instances [22, 21].
One of the most popular methods is CBS (conflict-based search) . This method starts by solving a relaxation of the original problem in which agent collisions are ignored. This relaxation is relatively easy to solve as it consists of running a shortest-path algorithm for each agent. If the resulting plan contains a time and coordinate where two agents collide, then the algorithm forbids either or from being at the coordinate at time . This results in a search tree that is explored until it is depleted (thus finding the optimal solution for the problem). This method has been reported to achieve excellent results and multiple improvements have been made. We may cite for instance, addition of heuristics , merge-and-restart and conflict prioritization , some sub-optimal variants , and some techniques such as a branch-and-cut-and-price algorithm . For more information about the multi-agent path finding problem, we refer the reader to surveys about the MAPF variants and instances  and about the MAPF solvers .
At the beginning of the challenge, we tried some of the aforementioned approaches (notably CBS) to solve the challenge instances. To our surprise, CBS did not perform well. Indeed, the challenge instances are much denser than the ones in the literature. These instances are usually sparse in the number of agents (there are from 2 to 120 agents placed in grids with over 100,000 cells in these instances, where instances of the challenge contain hundreds or thousands of agents placed in grids never larger than ). This structural difference has a dramatic effect on the performance of CBS and in our experiments, CBS fails to find solutions for most of the challenge instances (with the exception of some very small ones).
The remainder of the paper is organized as follows. In Section 2 we consider the problem of obtaining feasible solutions of moderate makespan. These solutions are optimized later on, with the techniques described in Section 3. Details on implementing the algorithms are described in Section 4. Section 5 describes the results we obtained for some challenge instances and presents a comparison with the strategies used by other teams. Concluding remarks are presented in Section 6.
2 Initial Solutions
Feasibility is guaranteed for the challenge instances since the number of obstacles is finite and every start and target are located in the unbounded region of space. In this section, we show how to obtain feasible solutions with a moderate makespan. We divide the heuristics in two categories. In Section 2.1, we compute the solution one step at a time, considering multiple robots simultaneously. In Section 2.2, we compute the solutions one robot at a time.
The heuristics of the first category are not guaranteed to find a solution, but when they do they often find solutions of lower makespan than those of the second category. The algorithms of the second category are guaranteed to find a solution, but the resulting makespan may potentially be high.
2.1 Step by Step Computation
The problem of finding a solution for coordinated motion planning in a given number of steps can be modeled as an Integer Linear Problem (ILP) or equivalently as a SAT problem (see [22, 21] and references therein). While applying such an approach is intractable even for small instances, it can be adapted to find an initial solution. The general idea of the Greedy solver is to plan only a small number of steps for the robots such that the overall distance to the targets decreases as much as possible and repeat until reaching the targets.
Our ILP model considers a Boolean variable for each robot and for each possible path of length starting at the position of the robot. Constraints of having one and only one path per robot and avoiding obstacles and collisions between robots are easily expressed as linear inequalities. The objective function we maximize is the sum of all the variables with weight
where and are the first and the last positions of path and is the obstacle-avoiding distance from a point to the target of robot . The first factor encourages the solution to push the robots towards their targets, since it is better to get closer to target. The second factor prioritizes moving robots that are farther from their targets and we add one so that robots that are already at their target position are encouraged to remain there.
In practice, we set and we only perform the first step of the planned moves so that the robots can anticipate the moves of the other robots. Using the CPLEX  library to solve these problems, we can handle instances with up to roughly 200 robots. Note that this Greedy algorithm is not guaranteed to find a solution. For example, it fails to solve instances with corridors. The reason is that two robots may enter an infinite loop pushing each other back and forth inside the corridor, as the weight function gives higher priority to the robot that is currently farther away from its target, which may alternate between the two robots.
2.2 Robot by Robot Computation
The algorithms in this section compute the solution one robot at a time using an A* search. The search happens in 3-dimensional space where each robot state has integer coordinates of the form for position coordinates and time . There are possible movements, all of which increase by one unit. One movement keeps the position unchanged, while the other movements increment or decrement one of the two coordinates. A movement is feasible if it does not violate any of the problem constraints, considering the current path of the other robots.
We refer to the bounding box as an integer axis-aligned rectangular region containing all the start, target positions and obstacles inside its strict interior (not on the boundary). Given a set of obstacles and a bounding box, the depth of a position is the minimum obstacle-avoiding distance from to a position outside the bounding box. One may note that, being in its strict interior, the start and target positions have depth at least one. Indeed the subsequent algorithms require a way for a robot to go around these positions. A bounding box guarantees that there exists at least one such way: its border, i.e., the positions of depth . The minimum depth of start and target positions of a bounding box might become an issue for performance; to , depending on the algorithm, seem to be good compromises in our experience.
All algorithms in this section are based on a storage network . A storage network is a set of positions outside a predetermined bounding box such that for every position in , there exists a path that avoids all other positions of and goes from to some point in the bounding box. Each robot is assigned to a distinct element of , called the storage of .
Initially, we set the path of each robot to be stationary at the start position. We sort the robots by increasing start depth and for each robot in order, we use A* search to find the shortest path from start to storage, replacing the previous stationary path. The order by which the robots are sorted guarantees that such a path exists.
After finding paths from start to storage for every robot, we proceed to the next phase of the algorithm. We now sort the robots by decreasing target depth. Again, the order of the robots guarantees that a path from storage to target exists. However, we do not compute such a path. Instead, we compute a path from start to target directly, whose existence is guaranteed by the existence of a path from start to storage and another one from storage to target. The following paragraphs describe the design of four different storage networks.
In the Cross strategy, we define the storage network as the set of columns of even coordinate lying directly above or below the bounding box and the set of rows of even coordinate lying directly to the left or right of the bounding box, hence the name Cross. Then, we compute a maximal cardinality matching between the robots and . We tried both minimum-weight matching and greedy matchings, minimizing a weight function that considers the distance from start to storage as well as the distance from storage to target. In the greedy matching version, robots are assigned a storage ordered by decreasing start-to-target distance. The result is represented in Figure 1.
The previous strategy works very well for small or sparse instances. However, the different directions of the flow of robots from start to storage make the solutions inefficient for large dense instances. The Cootie Catcher strategy computes the storage using only the start location, in order to better exploit parallel movement of the robots. The storage network shape consisting of four diamonds is presented in Figure 2. For instances without obstacles, the strategy is guaranteed to find a path from start to storage using at most steps, where is the largest bounding box side. Surprisingly, this strategy also works well for many instances with obstacles.
The weakness of the previous method is that robots may be assigned storage in a location that is opposite to the direction from start to target. Furthermore, the parallel movement of the robots make it unlikely that a robot will be able to take any significant shortcuts before it reaches the storage. In order to exploit parallel movements while taking the target location into consideration, we developed the Dichotomy strategy. The strategy only works for instances without obstacles.
We translate the coordinate system so that the origin is the center of the bounding box. The robots are partitioned into two sets called left side and right side according to the sign of the -coordinate of the target location. Left-side robots are assigned storage with positive -coordinate while right-side robots are assigned storage with negative -coordinate, as represented in Figure 3.
The algorithm performs the following steps, described only for the robots with non-negative -coordinate for simplicity, as the other half is analogous.
Each robot goes up from start position to position .
If the robot target is on the right side, the robot moves up one more row. At this point, the even
rows contain left-side robots and the oddrows contain the right-side robots.
If a right-side (resp. left-side) robot is still inside the bounding box, then it moves to the right (left) as far as needed to leave enough space for the other robots to its left on the same row to move out of the bounding box. Otherwise, a right-side (left-side) robot moves right (left) in order to leave enough space for the robots on the same row to move to a position of positive (negative) -coordinate.
Going from start to storage takes at most movements for a bounding box. Instead of sorting the robots by decreasing target depth as usual, we sort the robots by absolute value of the target -coordinate and then determine the paths from start to target using A* as usual.
This strategy focuses on instances with obstacles, especially on dense instances where the obstacles create bottlenecks. The goal of the Escape strategy is to clear the bounding box as quickly as possible. To do so, we move the robots by blocks as large as possible making efficient use of parallel movements.
The Escape strategy defines layers inside the bounding box. Robots located in the first layer will move in a straight line to reach the outside of the bounding box. No intersection is allowed between the path taken by robots located in the first layer. Then, the second layer is defined. It consists in blocks adjacent to the first layer, ideally as large as possible, that will move in a straight line into the first layer. All robots located in the same block will move towards the first block in parallel motion. Either all robots from a same block are set in motion at once, or none are. Then, in the same way, a third layer is defined, consisting of blocks that will move into the first or second layer. Layers are added until covering the location of every robot as represented in Figure 4. We used a naive algorithm to define the layers, and partially redefined them by hand for the most complicated instances and the unsatisfying results. Outside the bounding box, robots emerging from three columns are stored on only two of these as can be seen in Figure 5.
3 Improving Solutions
In this section we discuss the two heuristics that we used to reduce the makespan of a given feasible solution. The first heuristic makes local changes to the solution, which remains feasible throughout the process, and possibly reduces the makespan. The second heuristic destroys the feasibility of the solution and either finds another solution of reduced makespan, or no feasible solution at all. Throughout, let be the makespan of the input solution.
The idea of the Feasible Optimizer is the following. We iteratively remove the path of a robot from the solution, and then use the A* algorithm to find a new (hopefully different) path for . The A* algorithm may be tuned in several ways to produce different paths, and we do so in such a way that the makespan of the solution never increases and also that a robot is only allowed to move at time if it already did so in the original path. This way, not only the makespan but also the number of robots moving at time never increase. Next, we list some examples on how to modify the A* search.
Find the path from start to target that reaches the target as quickly as possible but break ties using the sum of random weights given to each grid cell the robot passes through.
Reversing the direction of time and then finding a path from target to start that reaches the start as quickly as possible. In the original time direction, that means that the robot will remain at the start for as long as possible.
In the reversed case, force the robot to stay at target for a certain number of steps.
The previous optimization strategy may take very long to reduce the makespan because it relies on chance to move a robot away from the path another robot would rather take. Next, we describe a more aggressive approach that leaves the feasible solution space and works far better than we expected. The algorithm uses a modified A* search that allows for a robot to go over another robot’s path, which we call a conflict. We start by creating a queue with all the robots that move at makespan time . While the queue is not empty, we repeat the following procedure for a robot popped from the front of the queue.
Erase ’s path.
Find a path for from start to target that arrives no later than time and minimizes the weighted sum of conflicting robots.
Add all conflicting robots to the queue.
Let be the number of times has been popped out of the queue. We define the weight of a robot as . This weight function gives some incentive to converge to a feasible solution, preventing robots from repeatedly finding paths that conflict with each other. Notice that ’s path is only cleared once it is popped out of the queue. This way, a robot tries to prevent parts of its previous path from being used by other robots, despite the fact that will need to find a new path.
For sparse or small instances, the Conflict Optimizer can even be used to compute solutions from scratch by choosing an initial makespan and putting all the robots in the queue. This approach fails to find solutions for most instances, though. Hence, we used the Conflict Optimizer only to optimize solutions obtained using the algorithms described in Section 2.
4 Algorithm Engineering
In this section, we describe different techniques used to efficiently implement and apply the previously described heuristics. All heuristics have been executed multiple times extensively using randomization whenever possible. Furthermore, different rotations have been applied, as well as reversing the start and the target of the instances.
Multiple executions were used to produce over ten thousand solution files total. All solution files were saved with a timestamp on the file name. That allowed us to find initial solutions that would optimize better. Even though we only optimized for makespan, this large volume of solutions allowed us to obtain solutions with a sufficiently low sum of the distances to obtain the third place in that category. Developing tools to efficiently organize and view all these solutions were an important part of the team strategy.
The heuristics have been coded in C++, most of which are available publicly on github. The tools have been coded in python. We executed the code on several Linux machines, both personal computers and high performance computing clusters at the LIS and LIMOS laboratories.
The A* search is in the heart of most of our heuristics. Hence, a lot of work has been done to improve its performance. Sometimes we used deterministic A*, breaking ties by the coordinates of the position, but more often we used a randomized A* algorithm where ties are broken by the sum of the weight of the positions in the path, which are assigned randomly. The A* algorithm needs a distance function as a lower bound and a collision detection, which are described next.
The A* algorithm is guided by a lower bound to the distance to target. In the case without obstacles the lower bound we used is simply the distance, which can be calculated in time. While this lower bound is still valid for instances with a set of obstacles, it is inefficient because it does not take the obstacles into account. Instead, we used the obstacle-avoiding distance.
Calculating the obstacle-avoiding distance from scratch is a slow process. Since this computation happens many times during the execution of our heuristics, it is essential to be able to compute it quickly. To this purpose, we need to use a data structure to compute the distance from a query point to a target (in our case, given at preprocessing time). Existing data structures for the problem [5, 4] seem hard to implement. Instead, we designed a simple data structure that takes query time for obstacles inside a square of side . The storage requirement may potentially be close to , but in our case it is significantly less, generally close to .
Given two consecutive points on the same line we have . Furthermore, if is to the left (resp., right) of the bounding box, then (resp. ). Hence, for each line in the bounding box we only store the points such that , as shown in Figure 6. All the remaining queries for line
can be calculated by interpolating or extrapolating these stored values, which can be located in
time using binary search on a sorted vector.
Queries for a point above or below the bounding box are answered by using the closest line of the bounding box and the fact that .
Fast collision detection is a key point to the performance of the A* algorithm. We used an internal storage Hopscotch hash table implemented by Thibaut Goetghebuer-Planchon and distributed under the MIT license . Given a position and time, we stored the robot in that position (or the list of robots in that position for the Conflict Optimizer). Hence, collision detection reduces to a small number of hash table lookups.
Avoiding Conflict Optimizer stalls
The Conflict Optimizer is arguably the most significant contribution of this work. However, it may stall at sub-optimal solutions. To reduce this problem, we may use the following approaches. (i) Reverse start and target as well as the paths in the solution. (ii) Use the Feasible Optimizer to shuffle the solution. (iii) Use randomized paths in the A* search. (iv) Insert the robots that are inserted simultaneously in the queue using a random order.
Tables 1 and 2 show the makespan obtained using different heuristics on some selected challenge instances and the makespan lower bound. The Feasible Optimizer column corresponds to the best optimization it obtained starting from different solutions. The Conflict Optimizer column corresponds to the optimization of the solution obtained by the Feasible Optimizer.
Figure 7 shows the improvement obtained by the Conflict Optimizer over one hour of execution as well as over several weeks. In the case of one hour of execution, we did not attempt to avoid the conflict optimizer stalls. However, the data for several weeks has been produced during the challenge, and is subject to both automatic and manual attempts to avoid stalls. We note that near the end of the challenge, some solutions kept improving very slowly with the Conflict Optimizer: some instances with a few thousand robots such as sun_007, clouds_008, and large_free_007 were consistently giving unit of makespan improvement for every 10 to 20 hours of computation throughout weeks.
Comparison with other teams
In general, the initial solution is computed through a storage network of the robots outside the bounding box of obstacles, start, and target positions. The existence of a solution is guaranteed by using the depth of the start and target positions. We noticed that gitastrophe used the same trick we did: first compute a partial solution going from start to storage and then compute new paths going from start to target since the existence of such paths is guaranteed. gitastrophe also used a minimum weight matching to assign each robot to a storage position. The main difference between the teams during this phase is in the choice of the storage network (points within pairwise distance at least for gitastrophe and points having even coordinates for UNIST). Among the different storage networks that we used (Cross, Cootie Catcher, Dichotomy, Escape), we noticed that none of the four is always the best one.
For the optimization of an initial solution, there are again some similarities, but differences are more significant. The standard strategy is to randomly remove the paths of a sample of robots before recomputing them with the hope of an improvement. gitastrophe experimented different ways to choose the samples: according to their makespan, relative distance, or conflicts with a given robot. UNIST used a sample of only one robot as we did in our Feasible Optimizer but UNIST adds also an original simulated annealing optimization step. Neither UNIST nor gitastrophe have used an optimization algorithm where the sample of robots to recompute evolves dynamically as in our Conflict Optimizer
. The reason could be that this strategy destroys the solution feasibility without any guarantee of recovery. However, the Conflict Optimizer is probably the main ingredient that gave us a dramatic advantage over the other teams.
6 Conclusion and Perspectives
We developed several algorithms to solve the coordinated motion planning instances of the challenge CG:SHOP2021, obtaining low-makespan solutions. We were surprised that our algorithms found optimal solutions (according to the trivial lower bound) for 105 out of 203 challenge instances, much more than we expected considering how dense the instances are. Furthermore, our team obtained the best solution found for 202 out of 203 challenge.
We attribute this success to the large variety of algorithms that we used. The 3-step Greedy algorithm cannot solve most instances, but when it does, it provides solutions that are better than the robot by robot solutions. In the robot by robot solutions, we used several different kinds of storage network, adapting to the peculiarities of each instance. Besides the four storage networks described herein, a few others have been tested, including the possibility of storage inside the bounding box, as well as restricting the movement direction in chosen cells in order to create one-way lanes. These other networks did not yield any noticeable benefit, though. Optimizing the solutions is a key ingredient. The Feasible Optimizer helps, but about half of the optimal solutions that we found were produced by the Conflict Optimizer. We were surprised how well this algorithm works, while not surprised that the higher the robots density is, the lower is its efficiency.
We should keep in mind that the algorithms have been designed for the challenge instances. A natural question is to determine if the strategy that we used remains suitable for other types of instances as the ones arising from the three following scenarios:
The start and target positions are located in different areas. This scenario corresponds to the practical problem of moving a warehouse to another location.
A set of obstacles form a bounding box around the start and target positions. This scenario corresponds to the problem of organizing a warehouse.
A set of obstacles form a bounding box with a small number of doors connecting the interior and the exterior of an area. Start and target positions may be both inside and outside this area. This scenario corresponds to loading and unloading a warehouse.
A key tool that we used for computing the initial solution is a storage network. Storage networks could potentially be possibly used in scenarios 1 and 3, but may be very inefficient for scenario 3 due to a bottleneck at the doors. In scenario 2, it may be possible to adapt the storage network idea, as long as the density is low enough. Tackling these concrete problems are a possible direction for future works.
We would like to thank Hélène Toussaint, Raphaël Amato, Boris Lonjon, and William Guyot-Lénat from LIMOS, as well as the Qarma and TALEP teams and Manuel Bertrand from LIS, who continue to make the computational resources of the LIMOS and LIS clusters available to our research. We would also like to thank the challenge organizers and other competitors for their time, feedback, and making this whole event possible.
The work of Loïc Crombez has been sponsored by the French government research program “Investissements d’Avenir” through the IDEX-ISITE initiative 16-IDEX-0001 (CAP 20-25). The work of Guilherme D. da Fonseca is supported by the French ANR PRC grant ADDS (ANR-19-CE48-0005). The work of Yan Gerard is supported by the French ANR PRC grants ADDS (ANR-19-CE48-0005), ACTIVmap (ANR-19-CE19-0005) and by the French government IDEX-ISITE initiative 16-IDEX-0001 (CAP 20-25). The work of Pascal Lafourcade is supported by the French ANR PRC grant MobiS5 (ANR-18-CE39-0019), DECRYPT (ANR-18-CE39-0007), SEVERITAS (ANR-20-CE39-0005) and by the French government IDEX-ISITE initiative 16-IDEX-0001 (CAP 20-25). The work of Luc Libralesso is supported by the French ANR PRC grant DECRYPT (ANR-18-CE39-0007).
-  (2014) Suboptimal variants of the conflict-based search algorithm for the multi-agent pathfinding problem. In Seventh Annual Symposium on Combinatorial Search, SOCS 2014, External Links: Cited by: §1.
-  (2019) Multi-agent path finding on real robots. AI Commun. 32 (3), pp. 175–189. External Links: Cited by: §1.
-  (2015) ICBS: the improved conflict-based search algorithm for multi-agent pathfinding. In Eighth Annual Symposium on Combinatorial Search, SOCS 2015, pp. 223–225. External Links: Cited by: §1.
-  (2013) Shortest path queries among polygonal obstacles in the plane. In 30th International Symposium on Theoretical Aspects of Computer Science, STACS 2013, External Links: Cited by: §4.
-  (2016) Two-point shortest path queries in the plane. J. Comput. Geom. 7 (1), pp. 473–519. External Links: Cited by: §4.
-  (2009) V12. 1: user’s manual for CPLEX. International Business Machines Corporation 46 (53), pp. 157. Cited by: §2.1.
Push and rotate: a complete multi-agent pathfinding algorithm.
Journal of Artificial Intelligence Research51, pp. 443–492. External Links: Cited by: §1.
-  (2019) Coordinated motion planning: reconfiguring a swarm of labeled robots with bounded stretch. SIAM Journal on Computing 48 (6), pp. 1727–1762. External Links: Cited by: §1.
-  (2021) Computing coordinated motion plans for robot swarms: the CG:SHOP challenge 2021. External Links: Cited by: §1.
-  (2018) Adding heuristics to conflict-based search for multi-agent path finding. In 28th International Conference on Automated Planning and Scheduling, ICAPS 2018, pp. 83–87. External Links: Cited by: §1.
-  (2017) Search-based optimal solvers for the multi-agent pathfinding problem: summary and challenges. In Tenth International Symposium on Combinatorial Search, SOCS 2017, pp. 29–37. External Links: Cited by: §1.
-  (2020) A C++ implementation of a fast hash map and hash set using hopscotch hashing. Note: https://github.com/Tessil/hopscotch-map Cited by: §4.
-  (2014) Enhanced partial expansion A*. Journal of Artificial Intelligence Research 50, pp. 141–187. External Links: Cited by: §1.
-  (2019) Branch-and-cut-and-price for multi-agent pathfinding. In International Joint Conferences on Artificial Intelligence, pp. 1289–1296. External Links: Cited by: §1.
-  (2020) Lifelong multi-agent path finding in large-scale warehouses. External Links: Cited by: §1.
-  (2017) Overview: generalizations of multi-agent path finding to real-world scenarios. External Links: Cited by: §1.
-  (2015) Conflict-based search for optimal multi-agent pathfinding. Artificial Intelligence 219, pp. 40–66. External Links: Cited by: §1.
-  (2005) Cooperative pathfinding. In First Artificial Intelligence and Interactive Digital Entertainment Conference, pp. 117–122. Cited by: §1.
-  (2021) Coordinated motion through randomized k-opt. In 37th International Symposium on Computational Geometry, SoCG 2021, LIPIcs, Vol. 189, pp. 64:1–64:8. External Links: Cited by: §5.
-  (2019) Multi-agent pathfinding: definitions, variants, and benchmarks. External Links: Cited by: §1.
-  (2016) Efficient SAT approach to multi-agent path finding under the sum of costs objective. In 22nd European Conference on Artificial Intelligence, ECAI 2016, Frontiers in Artificial Intelligence and Applications, Vol. 285, pp. 810–818. External Links: Cited by: §1, §2.1.
-  (2019) Unifying search-based and compilation-based approaches to multi-agent path finding through satisfiability modulo theories. In 28th International Joint Conference on Artificial Intelligence, IJCAI 2019, pp. 1177–1183. External Links: Cited by: §1, §2.1.
-  (2021) A simulated annealing approach to coordinated motion planning. In 37th International Symposium on Computational Geometry, SoCG 2021, LIPIcs, Vol. 189, pp. 65:1–65:8. External Links: Cited by: §5.
-  (2013) Planning optimal paths for multiple robots on graphs. In 2013 IEEE International Conference on Robotics and Automation, pp. 3612–3617. External Links: Cited by: §1.