Springer Nature is making SARS-CoV-2 and COVID-19 research free. View research | View latest news | Sign up for updates

Dynamic teams of robots as ad hoc distributed computers: reducing the complexity of multi-robot motion planning via subspace selection


We solve the multi-robot path planning problem using three complimentary techniques: (1) robots that must coordinate to avoid collisions form temporary dynamic teams. (2) Robots in each dynamic team become a distributed computer by pooling their computational resources over ad hoc wireless Ethernet. (3) The computational complexity of each team’s problem is reduced by carefully constraining the environmental subspace in which the problem is considered. An important contribution of this work is a method for quickly choosing the subspace, used for (3), to which each team’s problem is constrained. The heuristic is based on a tile-like pebble motion game, and returns true only if a subset of the environment will permit a solution to be found (otherwise it returns false). We perform experiments with teams of four and six CU Prairiedog robots (built on the iRobot Create platform) deployed in a large residence hall, as well as ten robots in random simulated environments.

This is a preview of subscription content, log in to check access.

Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8
Fig. 9
Fig. 10
Fig. 11
Fig. 12
Fig. 13


  1. 1.

    This is unrelated to agile software development practices.

  2. 2.

    Given that synchronization may be necessary to ensure that all robots move through the conflict zone safely; we assume that robots are able to hold position within their start-tile projection until all team members are ready. For complex hold patterns, this requires that the clearance term be chosen such that it is possible to align the hold patterns of different robots.

  3. 3.

    A probabilistically complete algorithm is an algorithm that will find and return a solution with probability one if a solution exists, but may run forever if a solution does not exist (in practice a timeout is usually used to indicate that a solution could not be found within an allotted planning time).

  4. 4.

    A sound algorithm is an algorithm that will always return a correct solution when it returns a solution.

  5. 5.

    Asymptotic optimality means that, in the limit as the number of samples approaches infinity, then the algorithm will find an optimal solution with probability one.

  6. 6.

    Although, to be fair, we cannot rule out the possible existence of pathological cases for which quality might become arbitrarily worse than a feasible algorithm; however, we expect such cases to be unlikely to occur in practice (if they occur at all). And, on the other hand, it is easy to design cases where feasible algorithms are expected to yield solutions with path lengths that are arbitrarily worse than our method: for example, simply place an arbitrarily large border of free space around a continuous space position swapping problem.


  1. Al-Wahedi, K. (2000). A hybrid local-global motion planner for multi-agent coordination. Masters thesis, Case Western Reserve University.

  2. Allred, J., Hasan, A. B., Panichsakul, S., Pisano, W., Gray, P., Huang, J., et al. (2007). Sensorflock: An airborne wireless sensor network of micro-air vehicles. In Proceedings of the 5th international conference on embedded networked sensor systems (pp. 117–129).

  3. Amstutz, P., Correll, N., & Martinoli, A. (2009). Distributed boundary coverage with a team of networked miniature robots using a robust market-based algorithm. Annals of Mathematics and Artifcial Intelligence Special Issue on Coverage, Exploration, and Search, 52(2–4), 307–333.

  4. Arrichiello, F., Das, J., Heidarsson, H., Pereira, A., Chiaverini, S., & Sukhatme, G. S. (2009). Multi-robot collaboration with range-limited communication: Experiments with two underactuated ASVs. In International conference on field and service robots.

  5. Auletta, V., Monti, A., Parente, M., & Persiano, P. (1999). A linear-time algorithm for the feasibility of pebble motion on trees. Algorithmica, 23(3), 223–245.

  6. Best, G., Cliff, O., Patten, T., Mettu, R., & Fitch, R. (2016). Decentralised monte carlo tree search for active perception. In: International workshop on the algorithmic foundations of robotics (WAFR), San Francisco, USA.

  7. Clark, C. M., Rock, S. M., & Latombe, J. C. (2003). Motion planning for multiple mobile robots using dynamic networks. In IEEE international conference on robotics and automation, 2003. Proceedings. ICRA’03 (Vol. 3, pp. 4222–4227). IEEE.

  8. de Wilde, B., Ter Mors, A. W., & Witteveen, C. (2014). Push and rotate: A complete multi-agent pathfinding algorithm. Journal of Artificial Intelligence Research, 51, 443–492.

  9. Desaraju, V. R., & How, J. P. (2012). Decentralized path planning for multi-agent teams with complex constraints. Autonomous Robots, 32(4), 385–403.

  10. Dixon, C., & Frew, E. W. (2007). Maintaining optimal communication chains in robotic sensor networks using mobility control. In International conference on robot communication and coordination.

  11. Elston, J., Frew, E., Lawrence, D., Gray, P., & Argrow, B. (2009). Net-centric communication and control for a heterogeneous unmanned aircraft system. Journal of Intelligent and Robotic Systems, 56(1–2), 199–232.

  12. Ferguson, D., & Stentz, A. (2006). Anytime RRTS. In 2006 IEEE/RSJ international conference on intelligent robots and systems (pp. 5369–5375). IEEE.

  13. Ford, K. M., Allen, J., Suri, N., Hayes, P. J., & Morris, R. (2010). PIM: A novel architecture for coordinating behavior of distributed systems. AI Magazine, 31(2), 9.

  14. Gammell, J. D., Srinivasa, S. S., & Barfoot, T. D. (2014). Informed RRT*: Optimal sampling-based path planning focused via direct sampling of an admissible ellipsoidal heuristic. In 2014 IEEE/RSJ international conference on intelligent robots and systems (IROS 2014) (pp. 2997–3004). IEEE.

  15. Goldreich, O. (2011). Finding the shortest move-sequence in the graph-generalized 15-puzzle is NP-hard. In O. Goldreich (Ed.), Studies in complexity and cryptography. Miscellanea on the interplay between randomness and computation. Lecture notes in computer science (Vol. 6650). Berlin, Heidelberg: Springer.

  16. Holland, O., Woods, J., De Nardi, R., & Clarck, A. (2005). Beyond swarm intelligence: The ultraswarm. In IEEE swarm intelligence symposium.

  17. Hollinger, G., Yerramalli, S., Singh, S., Mitra, U., & Sukhatme, G. (2011). Distributed coordination and data fusion for underwater search. In IEEE international conference on robotics and automation (pp. 349–355).

  18. Hsieh, M. A., Chaimowicz, L., Cowley, A., Grocholsky, B., Keller, J., Kumar, V., et al. (2007). Adaptive teams of autonomous aerial and ground robots for situational awareness. Journal of Field Robotics, 24(11), 991–1014.

  19. Hsu, D., Kindel, R., Latombe, J. C., & Rock, S. (2002). Randomized kinodynamic motion planning with moving obstacles. The International Journal of Robotics Research, 21(3), 233–255.

  20. Johnson, M., Intlekofer Jr, K., Jung, H., Bradshaw, J. M., Allen, J., Suri, N., et al. (2008). Coordinated operations in mixed teams of humans and robots. In Proceedings of the first IEEE conference on distributed human-machine systems.

  21. Johnson, W. W., Story, W. E., et al. (1879). Notes on the puzzle. American Journal of Mathematics, 2(4), 397–404.

  22. Khoo, A., & Horswill, I. (2002). An efficient coordination architecture for autonomous robot teams. In IEEE international conference on robotics and automation, 2002. Proceedings. ICRA ’02 (Vol. 1, pp. 287–292).

  23. Kornhauser, D., Miller, G., & Spirakis, P. (1984). Coordinating pebble motion on graphs, the diameter of permutation groups, and applications. In 25th annual symposium on foundations of computer science (pp. 241–250). https://doi.org/10.1109/SFCS.1984.715921.

  24. Krontiris, A., Luna, R., & Bekris, K. E. (2013). From feasibility tests to path planners for multi-agent pathfinding. In Sixth annual symposium on combinatorial search.

  25. Loyd, S. (1959). Mathematical puzzles of Sam Loyd. New York: Dover Publications Inc.

  26. Nardi, R. D., Holland, O., Woods, J., & Clark, A. (2006). Swarmav: A swarm of miniature aerial vehicles. Technical Report.

  27. Otte, M. (2011). Any-Com multi-robot path planning. Ph.D. thesis, University of Colorado at Boulder.

  28. Otte, M. (2016). Collective cognition & sensing in robotic swarms via an emergent group mind. In International symposium on experimental robotics (ISER), Tokyo, Japan.

  29. Otte, M., & Correll, N. (2013a). Any-Com multi-robot path-planning: Maximizing collaboration for variable bandwidth (pp. 161–173). Berlin: Springer. https://doi.org/10.1007/978-3-642-32723-0.

  30. Otte, M., & Correll, N. (2013b). C-FOREST: Parallel shortest-path planning with super linear speedup. IEEE Transactions on Robotics, 29, 798–806.

  31. Otte, M., & Correll, N. (2014). Any-Com multi-robot path-planning with dynamic teams: Multi-robot coordination under communication constraints (pp. 743–757). Berlin: Springer. https://doi.org/10.1007/978-3-642-28572-1_51.

  32. Peasgood, M., McPhee, J., & Clark, C. (2006). Complete and scalable multi-robot planning in tunnel environments. IFAC Proceedings Volumes, 39(20), 26–31.

  33. Ratner, D., & Warmuth, M. (1986). Finding a shortest solution for the n\(\times \)n extension of the 15-puzzle is intractable. In AAAI (pp. 168–172).

  34. Rutishauser, S., Correll, N., & Martinoli, A. (2009). Collaborative coverage using a swarm of networked miniature robots. Robotics and Autonomous Systems, 57(5), 517–525.

  35. Scerri, P., Owens, S., Yu, B., & Sycara, K. (2007). A decentralized approach to space deconfliction. In 2007 10th international conference on information fusion (pp. 1–8). IEEE.

  36. Sharon, G., Stern, R., Felner, A., & Sturtevant, N. R. (2012). Meta-agent conflict-based search for optimal multi-agent path finding. In SOCS.

  37. Sharon, G., Stern, R., Felner, A., & Sturtevant, N. R. (2015). Conflict-based search for optimal multi-agent pathfinding. Artificial Intelligence, 219, 40–66.

  38. Solovey, K., & Halperin, D. (2014). k-color multi-robot motion planning. The International Journal of Robotics Research, 33(1), 82–97.

  39. Standley, T., & Korf, R. (2011). Complete algorithms for cooperative pathfinding problems. In IJCAI (pp. 668–673).

  40. Suri, N., & Cabri, G. (2014). Adaptive, dynamic, and resilient systems. Boca Raton, FL: CRC Press Taylor & Francis Group.

  41. Suri, N., Marcon, M., Quitadamo, R., Rebeschini, M., Arguedas, M., Stabellini, S., et al. (2008). An adaptive and efficient peer-to-peer service-oriented architecture for manet environments with agile computing. In Network operations and management symposium workshops (pp. 364–371). IEEE.

  42. Suri, N., Rebeschini, M., Breedy, M., Carvalho, M., & Arguedas, M. (2006). Resource and service discovery in wireless ad-hoc networks with agile computing. In Military Communications Conference, 2006. MILCOM 2006 (pp. 1–7). IEEE.

  43. Surynek, P. (2009). An application of pebble motion on graphs to abstract multi-robot path planning. In 21st IEEE international conference on tools with artificial intelligence (pp. 151–158). IEEE.

  44. Surynek, P. (2014). Solving abstract cooperative path-finding in densely populated environments. Computational Intelligence, 30(2), 402–450.

  45. Sutton, D. J., Klein, P., Otte, M., & Correll, N. (2010). Object interaction language (oil): An intent-based language for programming self-organized sensor/actuator networks. In IEEE/RSJ international conference on intelligent robots and systems (IROS).

  46. van Den Berg, J., Snoeyink, J., Lin, M. C., & Manocha, D. (2009). Centralized path planning for multiple robots: Optimal decoupling into sequential plans. In RSS.

  47. Voyles, R. M., Bae, J., Larson, A. C., & Ayad, M. A. (2009). Wireless video sensor networks for sparse, resource-constrained, multi-robot teams. Intelligent Service Robotics, 2(4), 235–246.

  48. Voyles, R., Povilus, S., Mangharam, R., & Li, K. (2010). Reconode: A reconfigurable node for heterogeneous multi-robot search and rescue. In IEEE international workshop on safety, security and rescue robotics.

  49. Wagner, G., & Choset, H. (2015). Subdimensional expansion for multirobot path planning. Artificial Intelligence, 219, 1–24.

  50. Wagner, G., Kang, M., & Choset, H. (2012). Probabilistic path planning for multiple robots with subdimensional expansion. In 2012 IEEE international conference on robotics and automation (ICRA) (pp. 2886–2892). IEEE.

  51. Wedge, N. A., & Branicky, M. S. (2008). On heavy-tailed runtimes and restarts in rapidly-exploring random trees. In AAAI Conference on artificial intelligence.

  52. Wilson, R. M. (1974). Graph puzzles, homotopy, and the alternating group. Journal of Combinatorial Theory, Series B, 16(1), 86–96.

  53. Yu, J., & Rus, D. (2015). Pebble motion on graphs with rotations: Efficient feasibility tests and planning algorithms. In H. L Akin, N. M. Amato, V. Isler, & A. F van der Stappen (Eds.), Algorithmic foundations of robotics XI (pp. 729–746). Springer.

Download references

Author information

Correspondence to Michael Otte.

Additional information

This is one of several papers published in Autonomous Robots comprising the “Special Issue on Distributed Robotics: From Fundamentals to Applications”.


Appendix A: Description of C-FOREST distributed branch and bound

In this section we describe the C-FOREST algorithm. C-FOREST is a distributed branch and bound technique for parallelizing sampling-based motion planning algorithms across multiple CPUs. C-FOREST is designed for use with asymptotically optimal sampling-based motion planning algorithms like RRT-\(\#\) and RRT*.

C-FOREST works by having each CPU build its own random tree. Whenever a more optimal path is discovered by the tree on any CPU, then that path is broadcast to all CPUs so that it can be incorporated into the trees being built on other CPUs.

C-FOREST works for two reasons. (1) It enables “lucky” random exploration (that discovers better homotopy classes or basins of attraction) to be shared across all trees during the planning process so that all trees benefit from the good fortune of any tree. (2) It allows us to ignore portions of the space that cannot possibly lead to better solutions.

(2) is often accomplished with the help of a heuristic. For example, if the length of the geodesic from start to a new point plus the length of the geodesic from the new point to the goal is longer than the best path — then the new point need not be considered because it cannot be part of a path that is shorter than the best one already found. Given the length of the best known path, it is possible to sample directly from the portion of space that yields points shorter than the best solution. The latter heuristic was first used in Any-Time RRT (Ferguson and Stentz 2006), and was previously used in the C-FOREST distributed branch and bound RRT* in our previous work (Otte and Correll 2013b; Otte 2011); more recently, it was used in conjunction with RRT* for the single-robot case in the Bit* algorithm (Gammell et al. 2014).

It is important to note that C-FOREST only provides benefits after the first solution is found (by any CPU). Thus, while C-FOREST can be used with feasible planning algorithms like RRT, it behaves like OR-parallelization for feasible planning.

For ease of presentation, in this section we assume that the robots in the dynamic team \(R\) are labeled \({r_1, \ldots , r_{|R|}}\) such that \({R= \{r_1, \ldots , r_{|R|}\}}\). Each robot \(r_1\) grows a unique random tree through the team’s combined configuration space \(\mathcal {S}_{R}\) from \(s_{R}^{\mathrm {start}}\) to \(s_{R}^{\mathrm {goal}}\).


The quantity \(G(\mathrm {bestLen})\) represents the subset of space in which \(\mathbf {geodesic}(s_{R}^{\mathrm {start}}, s_{R}) + \mathbf {geodesic}(s_{R}, s_{R}^{\mathrm {start}}) < \mathrm {bestLen}\), where \(\mathbf {geodesic}(A,B)\) returns the length of the geodesic from A to B.

Appendix B: Messages used in low level subroutines

Robots broadcast messages to each other to communicate their intentions, to solve their centralized motion planning problems using C-FOREST distributed computation, and to coordinate their progress along the agreed upon multipaths. Let the overall message be denoted \(M\). In our algorithm presentation we use the C/C++ language convention that sub-fields of the message data structure are denoted using the ‘.’ token. Messages from robot \(r_i\) contain the following sub-fields, (similar quantities are also tracked locally on each robot and for brevity we omit repeating their definitions, but they appear without the ‘\(M.\)’ prefix in the presentation of our algorithms):

  • \(M.\mathrm {epoch}\) is the current planning epoch of \(r_i\).

  • \(M.\mathrm {data}\) contains data about each of the j robots that \(r_i\) knows about (either directly or indirectly via other robots).

  • \(M.\mathrm {path}\) contains \(P_{i}\) the path \(r_i\) is using to navigate (that is, the subset between its current location and \(x_{i}^{\mathrm {goal}}\))—including its time parameterization.

  • \(M.\mathrm {behindSchedule}\) is the amount of time that the sending robot’s team is behind schedule (with respect to the time parameterization of \(P_{i}\)).

  • \(M.\mathrm {data}[k]\) stores data about \(r_j\), the k-th robot \(r_i\) knows about.

  • \(M.\mathrm {data}[k].\mathrm {id}\) stores j

  • \(M.\mathrm {data}[k].\mathrm {start}\) stores \(x_{j}^{\mathrm {start}}\).

  • \(M.\mathrm {data}[k].\mathrm {goal}\) stores \(x_{j}^{\mathrm {goal}}\).

  • \(M.R\) contains a list of all robots in the current team.

  • \(M.\mathrm {teamData}\) contains additional data about each of the robots in \(r_i\)’s current team.

  • \(M.\mathrm {teamData}[k]\) stores data about the k-th robot in \(r_i\)’s current team. Note that each robot places itself into position \(k=0\) when populating message data.

  • \(M.\mathrm {teamData}[k].\mathrm {id}\) the k-th robot’s id j

  • \(M.\mathrm {teamData}[k].\mathrm {start}\) stores \(s_{j}^{\mathrm {start}}\).

  • \(M.\mathrm {teamData}[k].\mathrm {goal}\) stores \(s_{j}^{\mathrm {goal}}\).

  • \(M.\mathrm {teamData}[k].\mathrm {epoch}\) stores the k-th robot’s epoch.

  • \(M.\mathrm {bestSolution}\) is the best solution \(\hat{\mathbf {P}}_{R}\) (found so far) currently known to \(r_i\) for the sub-problem currently being solved.

  • \(M.\mathrm {bestLen}\) is the length of the best solution (found so far), \(\Vert \mathbf {P}^*_{R}\Vert \).

  • \(M.\mathrm {bestID}\) is the ID of the robot that generated the best solution (found so far).

  • \(M.\mathrm {agreeSet}\) is the subset of the current team that believes \(\hat{\mathbf {P}}_{R}\) is the best solution (found so far).

  • \(M.\mathrm {finalSet}\) is the subset of the current team that has submitted a final solution (is done planning for the current sub-problem).

  • \(M.\mathrm {movingSet}\) is the subset of the current team that has started moving.

Appendix C: Description of lower level subroutines


The initialization routine \(\mathbf {Initialize}()\) appears in Algorithm 4. Each robot starts in its own team and initializes its team’s multipath to contain its starting location so that if other robot’s paths conflict with this starting location, they will detect that a team combination should occur.


The reset routine \({\mathbf {Reset}()}\) is described in Algorithm 5 and run before a new motion planning sub-problem is solved; it is responsible for re-initializing all C-FOREST related data (lines 14) as well as all data that is used to coordinate movement with a team (lines 59).


\(\mathbf {waitForDataFromTeammates}()\) appears in algorithm 6 and causes the calling process to sleep until this robot has received data from all members of its current team.

\(\mathbf {BroadcastThread}()\) is responsible for sending messages to other robots. It does not appear in pseudocode but, simply packages all data related to movement and planning into a message, and then broadcasts that message on an open channel (to which all robots listen). The broadcast thread is set to run no faster than \(\omega \) hz for user-defined \(\omega \) so that the communications channel is not saturated. If, in practice, a more sophisticated ad hoc communication protocol is used, then this can be replaced appropriately.


\(\mathbf {ListenThread}()\) is responsible for listening for incoming messages from other robots and appears in Algorithm 7. Each time a new message is received (line 2) the data is combined with the local data on the robot to reflect the most up-to-data epoch and path information for nearby robots in general (line 3). The subroutine \(\mathbf {mergeAllNewConflicts}\) that appears in the if-statement on Line 4 is responsible for detecting when a team merge operation must take place in response to new message data (and is described in Algorithm 8). The Boolean flag \(\mathrm {NewConflictsDetected}\) is set to true if this happens (line 5). If the sending robot is already in the receiving robot’s team (check on line 6), then message passing is used to synchronize the team’s start of movement (lines 7–8 and 13–14), or to compute and improve the C-FOREST solution (lines 9–12). Note that \(\mathrm {agreeSet}\) is maintained as the set of robots that agree on the best solution found so far in the C-FOREST algorithm, and \(\mathrm {finalSet}\) is similarly maintained as the set of robots that agree on the final solution. These sets are used to ensure the team reaches consensus on a solution before moving along any solution.


\(\mathbf {mergeAllNewConflicts}(M, R, \mathrm {teamData})\) appears in Algorithm 8 and is responsible for detecting when a robot’s team must be merged with other robots and teams. The epoch count of a team is always increased to the maximum epoch of any of its robots (line 2–4) to ensure that all robots in a team are computing on the most up-to-date problem faced by that team. Two conditions (both on line 5) can cause a new problem to need to be solved (in which case the epoch number is incremented). The first is if a robot not currently in this robot’s team has a conflicting path; the second is if the sending robot advertises that its own team includes a robot from the receiving robot’s team and it has a higher epoch number (we assume that agents are honest, and so the sending robot must have detected that a robot in the receiving robot’s team is conflicting). In the latter case we must increment the epoch to account for the unlikely event that multiple teams are merging at the same time; doing this ensures that the new problem has an epoch number larger than any problem that may have previously been solved by any of the new team’s members. If the epoch number has been increased, then all relevant new robots are merged into the receiving robot’s team (lines 7–11) and the algorithm returns true. Otherwise the algorithm returns false.


The subroutine \(\mathbf {moveAlong}(P_{r})\) is responsible for controlling robot \(r\)’s movement along \(P_{r}\) such that team movement along their shared multipath is coordinated. It appears in Algorithm 9. We note that various coordination mechanisms could be used, the one presented here is simple to implement but may be too naive for many problems (e.g., such as those involving fixed-wing aircraft). This version works well for ground vehicles moving at low speeds. All robots broadcast how far they are behind schedule, and each member of the team waits, when necessary, to match the progress of the robot that is the most behind schedule.


When a team has finished computing a solution to the multi-robot planning problem then \({\mathbf {RobotsAgree}()}\) shown in Algorithm 10, is used to reach consensus on the particular solution that the team uses (since some robots may not yet have received the best solution found by any member of the team). This routine helps with the synchronization of the beginning of movement, which can be initiated by any robot that discovers all team members agree on the final solution (line 1) or by a robot that discovered what it thinks is the best solution—as long as all robots agreed it was the best solution at some previous point. We assume that all robots are honest and seek to use the group optimal solution. However, in rare situations this alternative mechanism for starting movement may cause the team to use a slightly outdated solution; although, it will not cause conflicts/collisions due to the fact that this robot could not possibly have agreed that some other (better) solution was the final solution if it believes its own (worse) solution is still the best. In practice this decreases consensus time by one team-wise message propagation by allowing this relaxed form of consensus to be computed in parallel to the motion planning solution (this is particularly helpful in low-communication environments). Note that if any robot discovers that one of its teammates has started moving, then it also starts moving according to the same solution (even if it previously did not believe it was the best). It is better to agree on a lower quality solution than for two different subsets of the team to move along conflicting solutions.


\(\mathbf {processMoveMessage}(M)\) in Algorithm 11 is responsible for updating the robot’s data to reflect the movement agreements of its current team. On lines 1–3 the receiving root checks to make sure that the sending robot believes they are in the same team (line 2) and that they agree on the current epoch (line 3).

Rights and permissions

Reprints and Permissions

About this article

Verify currency and authenticity via CrossMark

Cite this article

Otte, M., Correll, N. Dynamic teams of robots as ad hoc distributed computers: reducing the complexity of multi-robot motion planning via subspace selection. Auton Robot 42, 1691–1713 (2018). https://doi.org/10.1007/s10514-018-9714-9

Download citation


  • Motion planning
  • Multi robot team
  • Ad hoc distributed computer
  • Any-Com
  • Dynamic team