When dealing with classic challenges of robotics, such as exploration, evaluation and manipulation of objects, traditional robot models are based on relatively powerful capabilities, such as the ability (1) to collect and store significant amounts of data, (2) perform intricate computations, and (3) execute complex physical operations. With the ongoing progress in miniaturization of devices, new possibilities emerge for exploration, evaluation and manipulation. However, dealing with micro- and even nano-scale dimensions (as present in the context of programmable matter) introduces a vast spectrum of new difficulties and constraints. These include significant limitations to all three of the mentioned capabilities; challenges get even more pronounced in the context of complex nanoscale systems, where there is a significant threshold between ‘‘internal’’ objects and sensors and ‘‘external’’ control entities that can evaluate gathered data, extract important information and provide guidance.
In this paper, we present algorithmic methods for evaluating and manipulating a collective of particles by agents of the most basic possible type: finite automata that can neither store significant amounts of data, nor perform complex computations, and are limited to a handful of possible physical operations. The objective is to provide a toolbox for carrying out fundamental tasks on a given arrangement of particles, such as bounding, counting, copying, reflecting, rotating or scaling a large given shape. The key idea is to use the arrangement itself as a storage device, similar to a higher-dimensional Turing machine with geometric properties.
1.1 Our Results
We consider an arrangement of pixel-shaped particles, on which a single finite-state robot can perform a limited set of operations; see Section 2 for a precise model description. Our goal is to develop strategies for evaluating and modifying the arrangement by defining sequences of transformations and providing metrics for such sequences. In particular, we present the following; a full technical overview is given in Table 1.
We give a time- and space-efficient method for determining the bounding box of .
We show that we can simulate a Turing machine with our model.
We provide a counter for evaluating the number of tiles forming , as well as the number of corner pixels of .
We develop time- and space-efficient algorithms for higher-level operations, such as copying, reflecting, rotating or scaling .
|Problem||Tile Complexity||Time Complexity||Space Complexity|
1.2 Related Work
There is a wide range of related work; due to space limitations, we can only present a small selection.
A very successful model considers self-assembling DNA tiles (e.g., [15, 5]) that form complex shapes based on the interaction of different glues along their edges; however, no active agents are involved, and composition is the result of chemical and physical diffusion.
The setting of a finite-automaton robot operating on a set of tiles in a grid was introduced in , where the objective is to arrange a given set of tiles into an equilateral triangle. An extension studies the problem of recognizing certain shapes . We use a simplified variant of the model underlying this line of research that exhibits three main differences: First, for ease of presentation we consider a square grid instead of a triangular grid. Second, our model is less restrictive in that the robot can create and destroy tiles at will instead of only being able to transport tiles from one position to another. Finally, we allow the robot to move freely throughout the grid instead of restricting it to move along the tile structure.
Other previous related work includes shape formation in a number of different models: in the context of agents walking DNA-based shapes [17, 21, 23]; in the Amoebot model ; in modular robotics ; in a variant of population protocols ; in the nubot model . Models based on automate and movable objects have also been studied in the context of one-dimensional arrays, e.g., pebble automata . Work focusing on a setting of robots on graphs includes network exploration , maze exploration , rendezvous search , intruder caption and graph searching [2, 7], and black hole search . For a connection to other approaches to agents moving tiles, e.g., see [4, 20].
Although the complexity of our model is very restricted, actually realizing such a system, for example using complex DNA nanomachines, is currently still a challenging task. However, on the practical side, recent years have seen significant progress towards realizing systems with the capabilities of our model. For example, it has been shown that nanomachines have the ability to act like the head of a finite automaton on an input tape , to walk on a one- or two-dimensional surface [11, 14, 23], and to transport cargo [19, 21, 22].
We consider a single robot that acts as a deterministic finite automaton. The robot moves on the (infinite) grid with edges between all pairs of nodes that are within unit distance. The nodes of are called pixels. Each pixel is in one of two states: It is either empty or occupied by a particle called tile. A diagonal pair is a pair of two pixels with (see Fig. 1, left and middle). A polyomino is a connected set of tiles such that for all diagonal pairs there is another tile that is adjacent to and adjacent to (see Fig. 1 middle and right). We say that is simple if it has no holes, i.e., if there is no empty pixel that lies inside a cycle formed by occupied tiles. Otherwise, is non-simple.
The -row of is the set of all pixels . We say that is -monotone if the -row of is connected in for each (see Fig. 1 right). Analogously, the -column of is the set of all pixels and is called -monotone if the -column of is connected in for each . The boundary of is the set of all tiles of that are adjacent to an empty pixel or build a diagonal pair with an empty pixel (see Fig. 1 right).
A configuration consists of the states of all pixels and the robot’s location and state. The robot can transform a configuration into another configuration using a sequence of look-compute-move steps as follows. In each step, the robot acts according to a transition function . This transition function maps a pair containing the state of the robot and the state of the current pixel to a triple , where is the new state of the robot, is the new state of the current pixel, and is the direction the robot moves in. In other words, in each step, the robot checks its state and the state of the current pixel , computes , changes into state , changes the state of the current pixel to if , and moves one step into direction .
Our goal is to develop robots transforming an unknown initial configuration into a target configuration . We assess the efficiency of a robot by several metrics: (1) Time complexity, i.e., the total number of steps performed by the robot until termination, (2) space complexity, i.e., the total number of visited pixels outside the bounding box of the input polyomino , and (3) tile complexity, i.e., the maximum number of tiles on the grid minus the number of tiles in the input polyomino .
3 Basic Tools
A robot can check the states of all pixels within a constant distance by performing a tour of constant length. Thus, from now on we assume that a robot can check within a single step all eight pixels that are adjacent to the current position or build a diagonal pair with .
3.1 Bounding Box Construction
We describe how to construct a bounding box of a given polyomino in the form of a zig-zag as shown in Fig. 2. We can split the bounding box into an outer lane and an inner lane (see Fig. 2). This allows distinguishing tiles of and tiles of the bounding box.
Our construction proceeds in three phases. (i) We search for an appropriate starting position. (ii) We wrap a zig-zag path around . (iii) We finalize this path to obtain the bounding box.
For phase (i), we simply search for a local minimum in the -direction. We break ties by taking the tile with minimal -coordinate, i.e., the leftmost tile. From the local minimum, we go two steps further to the left. If we land on a tile, this tile belongs to and we restart phase (i) from this tile. Otherwise we have found a possible start position.
In phase (ii), we start constructing a path that will wrap around . We start placing tiles in a zig-zag manner in the upwards direction. While constructing the path, three cases may occur.
At some point we lose contact with , i.e., there is no tile at distance two from the inner lane. In this case, we do a right turn and continue our construction in the new direction.
Placing a new tile produces a conflict, i.e., the tile shares a corner or a side with a tile of . In this case, we shift the currently constructed side of the bounding box outwards until no more conflict occurs. This shifting process may lead to further conflicts, i.e., we may not be able to further shift the current side outwards. If this happens, we deconstruct the path until we can shift it outwards again (see Fig. 3). In this process, we may be forced to deconstruct the entire bounding box we have built so far, i.e., we remove all tiles of the bounding box including the tile in the starting position. In this case we know that there must be a tile of to the left of the start position; we move to the left until we reach such a tile and restart phase (i).
Placing a new tile closes the path, i.e., we reach a tile of the bounding box we have created so far. We proceed with phase (iii).
Phase (iii): Let be the tile that we reached at the end of phase (ii). We can distinguish two cases: (i) At , the bounding box splits into three different directions (shown as the tile with black-and-white diagonal stripes in Fig. 4), and (ii) the bounding box splits into two different directions. In the latter case we are done, because we can only reach the bottom or left side of the bounding box. In the first case we have reached a right or top side of the bounding box. From we can move to the tile where we started the bounding box construction, and remove the bounding box parts until we reach . Now the bounding box splits in two directions at . Because we have reached a left or top side of the bounding box, we may not have built a convex shape around (see Fig. 4 left). This can be dealt with by straightening the bounding box in an analogous fashion, e.g., by pushing the line to the right of down.
The described strategy builds a bounding box that encloses the given polyomino of width and height . Moreover, the strategy terminates after steps, using at most auxiliary tiles and only of additional space. The running time in the best case is .
Correctness: We show that (a) the bounding box will enclose ; and (b) whenever we make a turn or shift a side of the bounding box, we find a tile with distance two from the bounding box, i.e., we will not build an infinite line.
First note that we only make a turn after encountering a tile with distance two to the inner lane. This means that we will “gift wrap” the polyomino until we reach the start. When there is a conflict (i.e., we would hit a tile of with the current line), we shift the current line. Thus, we again find a tile with distance two to the inner lane. This also happens when we remove the current line and extend the previous one. After a short extension we make a turn and find a tile with distance two to the inner lane, meaning that we make another turn at some point. Therefore, we do not construct an infinite line, and the construction remains finite.
Time: To establish a runtime of , we show that each pixel lying in the final bounding box is visited only a constant number of times. Consider a tile that is visited for the first time. We know that gets revisited again if the line through gets shifted or removed. When is no longer on the bounding box, we can visit again while searching for the start tile. Thus, is visited at most four times by the robot, implying a running time of unit steps. However, it may happen that we have to remove the bounding box completely and have to restart the local minimum search. In this case, there may be tiles that can be visited up to times (see Fig. 5). Therefore, the running time is in the worst-case.
Auxiliary Tiles: We now show that we need at most many auxiliary tiles at any time. Consider a tile of from which we can shoot a ray to a tile of the bounding box (or the intermediate construction), such that no other tile of is hit. For each tile of , there are at most four tiles of the bounding box. We can charge the cost of to , which is constant. Thus, each tile in has been charged by . However, there are still tiles on the bounding box that have not been charged to a tile of , i.e., tiles that lie in a curve of the bounding box.
Consider a locally convex tile , i.e., a tile at which we can place a square solely containing . Each turn of the bounding box can be charged to a locally convex tile. Note that there are at most four turns that can be charged to a locally convex tile. For each turn, there are at most four tiles that are charged to a locally convex tile. Thus, each tile of has constant cost, i.e., we need at most auxiliary tiles.
It is straightforward to see that we need additional space. ∎
3.2 Binary Counter
For counting problems, a binary counter is indispensable, because we are not able to store non-constant numbers. The binary counter for storing an -bit number consists of a base-line of tiles. Above each tile of the base-line there is either a tile denoting a 1, or an empty pixel denoting 0. Given an -bit counter we can increase and decrease the counter by 1 (or by any constant ), and extend the counter by one bit. The latter operation will only be used in an increase operation. In order to perform an increase or decrease operation, we move to the least significant bit and start flipping the bit (i.e., remove or place tiles).
4 Counting Problems
The constant memory of our robot poses several challenges when we want to count certain elements of our polyomino, such as tiles or corners. Because these counts can be arbitrarily large, we cannot store them in the state space of our robot. Instead, we have to make use of a binary counter. This requires us to move back and forth between the polyomino and the counter. Therefore, we must be able to find and identify the counter coming from the polyomino and to find the way back to the position where we stopped counting.
This motivates the following strategy for counting problems. We start by constructing a slightly extended bounding box. We perform the actual counting by shifting the polyomino two units downwards or to the left, one tile at a time. After moving each tile, we return to the counter and increase it if necessary. We describe further details in the next two sections, where we present algorithms for counting the number of tiles or corners in a polyomino.
4.1 Counting Tiles
The total number of tiles in our polyomino can be counted using the strategy outlined above, increasing the counter by one after each moved tile.
Let be a polyomino of width and height with tiles for which the bounding box has already been created. Counting the number of tiles in can be done in steps using of additional space and auxiliary tiles.
In a first step, we determine whether the polyomino’s width is greater than its height or vice versa. We can do this by moving to the lower left corner of the bounding box and then alternatingly moving up and right one step until we meet the bounding box again. We can recognize the bounding box by a local lookup based on its zig-zag shape that contains tiles only connected by a corner, which cannot occur in a polyomino. The height is at least as high as the width if we end up on the right side of the bounding box. In the following, we describe our counting procedure for the case that the polyomino is higher than wide; the other case is analogous.
We start by extending the bounding box by shifting its bottom line down by two units. Afterwards we create a vertical binary counter to the left of the bounding box. We begin counting tiles in the bottom row of the polyomino. We keep our counter in a column to the left of the bounding box such that the least significant bit at the bottom of the counter is in the row, in which we are currently counting. We move to the right into the current row until we find the first tile. If this tile is part of the bounding box, the current row is done. In this case, we move back to the counter, shift it upwards and continue with the next row until all rows are done. Otherwise, we simply move the current tile down two units, return to the counter and increment it. For an example of this procedure, refer to Fig. 7.
For each tile in the polyomino, we use steps to move to the tile, shift it and return to the counter; incrementing the counter itself only takes amortized time per tile. For each empty pixel we have cost . In addition, we have to shift the counter times. Thus, we need unit steps. We only use auxiliary tiles in the counter, in addition to the bounding box.
In order to achieve additional space, we modify the procedure as follows. Whenever we move our counter, we check whether it extends into the space above the bounding box. If it does, we reflect the counter vertically, such that the least significant bit is at the top in the row, in which we are currently counting. This requires extra steps and avoids using additional space above the polyomino. ∎
4.2 Counting Corners
In this section, we present an algorithm to count reflex or convex corners of a given polyomino.
Let be a polyomino of width and height with convex (reflex) corners for which the bounding box has already been created. Counting the number of convex (reflex) corners in can be done in steps, using of additional space and auxiliary tiles.
We use the same strategy as for counting tiles in Theorem 2 and retain the same asymptotic bounds on running time, auxiliary tiles and additional space. It remains to describe how we recognize convex and reflex corners.
Whenever we reach a tile that we have not yet considered so far, we examine its neighbors , as shown in Fig. 8. The tile has one convex corner for each pair , , , that does not contain a tile, and no convex corner is contained in more than one tile of the polyomino. As there are at most four convex corners per tile, we can simply store this number in the state space of our robot, return to the counter, and increment it accordingly.
A reflex corner is shared by exactly three tiles of the polyomino, so we have to ensure that each corner is counted exactly once. We achieve this by only counting a reflex corner if it is on top of our current tile and was not already counted with the previous tile . In other words, we count the upper right corner of as a reflex corner if exactly two of are occupied; we count the upper left corner of as reflex corner if and are present and is not. In this way, all reflex corners are counted exactly once. ∎
5 Transformations with Turing machines
In this section we develop a robot that transforms a polyomino into a required target polyomino . In particular, we encode and by strings and whose characters are from (see Fig. 9 left and Definition 4). If there is a Turing machine transforming into , we can give a strategy that transforms into (see Theorem 5).
We start with the definition of the encodings and .
Let be the polyomino forming the smallest rectangle containing a given polyomino (see Fig. 9 right). We represent by the concatenation of three bit strings , , and separated by blanks . In particular, and are the height and width of . Furthermore, we label each tile of by its rank in the lexicographic decreasing order w.r.t. - and -coordinates with higher priority to -coordinates (see Fig. 9 right). Finally, is an -bit string with if and only if the th tile in also belongs to .
Let and be two polyominos with . There is a strategy transforming into if there is a Turing machine transforming into . The robot needs auxiliary tiles, steps, and of additional space, where and are the number of steps and additional space needed by the Turing machine.
Our strategy works in five phases: Phase (1) constructs a slightly modified bounding box of (see Fig. 9(a)). Phase (2) constructs a shape representing . In particular, the robot writes onto a auxiliary line in a bit-by-bit fashion (see Fig 9(b)). In order to remember the position, to which the previous bit was written, we use a position tile placed on another auxiliary line . Phase (3) simulates the Turing machine that transforms into . Phase (4) is the reversed version of Phase (2), and Phase (5) is the reversed version of Phase (1). As Phase (4) and Phase (5) are the reversed version of Phase (1) and Phase (2), we still have to discuss how to realize Phases (1), (2), and (3).
Phase (1): We apply a slightly modified version of the approach of Theorem 1. In particular, in addition to the bounding box, we fill all pixels that lie not inside and adjacent to the boundary of by auxiliary tiles. This results in a third additional layer of the bounding box, see Fig. 9(a). Note that the robot recognizes that the tiles of the third layer do not belong to the input polyomino , because these tiles of the third layer lie adjacent to the original bounding box.
Phase (2): Initially, we construct a vertical auxiliary line of constant length seeding two horizontal auxiliary lines and that are simultaneously constructed by the robot during Phase (2). The robot constructs the representation of on and stores on a “position tile” indicating the next tile on , where the robot has to write the next bit of the representation of .
Finally, the robot places one after another and in decreasing order w.r.t. -coordinates all lines of onto . In particular, the tiles of the current line of are processed from right to left as follows. For each each tile , the robot alternates between and the auxiliary lines and in order to check whether belongs to or not.
In order to reach the first tile of the topmost line, the robot moves in a vertical direction on the lane induced by the vertical line to the topmost line of and then to the rightmost tile of the topmost line, see the yellow arrows in Fig. 9(b). In order to ensure that in the next iteration of Phase (2), the next tile of is reached, the robot deletes from and shrinks the modified bounding box correspondingly, see Fig. 9(b). This involves only a constant-sized neighbourhood of and thus can be realized by robot with constant memory. Next, the robot moves to the first free position of auxiliary line by searching for the position tile on auxiliary line . As the vertical distances of and to the lowest line of the bounding box is a constant, the robot can change vertically between and by simply remembering the robot’s vertical distance to the lowest line of the bounding box. The robot concludes the current iteration of Phase (2) by moving the position tile one step to the right.
The approach of Phase (2) is repeated until all tiles of are removed from .
Phase (3): We simply apply the algorithm of the Turing machine by moving the robot correspondingly to the movement of the head of the Turing machine.
Finally, we analyze the entire approach of simulating a Turing machine as described above. From the discussion of Phase (2) we conclude that the construction of the auxiliary lines , , and are not necessary, because the vertical length of the entire construction below the bounding is a constant. Furthermore, the current writing position on is indicated by a single position tile on . Thus, sizes of the bounding boxes needed in Phase (2) and Phase (4) dominate the number of used auxiliary tiles, which is in . Furthermore, each iteration of Phase (2) needs steps, where is the number of steps needed by the Turing machine. The same argument applies to the number of steps used in Phase (4). Finally, the additional space is in . This concludes the proof of Theorem 5. ∎
6 CAD Functions
As already seen, we can transform a given polyomino by any computable function by simulating a Turing machine. However, this requires a considerable amount of space. In this section, we present realizations of common functions in a more space-efficient manner.
6.1 Copying a Polyomino
Copying a polyomino has many application. For example, we can apply algorithms that may destroy after copying into free space. In the following, we describe the copy function that copies each column below the bounding box, as seen in Fig. 11 (a row-wise copy can be described analogously).
Our strategy to copy a polyomino is as follows: After constructing the bounding box, we copy each column of the bounding box area into free space. This, however, comes with a problem. As the intersection of the polyomino with a column may consists of more than one component, which may be several units apart, we have to be sure that the right amount of empty pixels are copied. This problem can be solved by using bridges, i.e., auxiliary tiles denoting empty pixels. To distinguish between tiles of and bridges, we use two lanes (i) a left lane containing tiles of and (ii) a right line containing bridge tiles (see Fig. 11).
To copy an empty pixel, we place a tile two unit steps to the left. This marks a part of a bridge. Then we move down and search for the first position, at which there is no copied tile of to the left, nor a bridge tile. When this position is found, we place a tile, denoting an empty position.
To copy a tile of , we move this tile three unit steps to the left. Afterwards, we move downwards following the tiles and bridges until we reach a free position and place a tile, denoting a copy of . when we reach the bottom of a column, we remove any tile representing a bridge tile and proceed with the next column (see Fig. 11 right).
Copying a polyomino column-wise can be done within unit steps using of auxiliary tiles and additional space.
Consider the strategy described above. It is straightforward to see that by maintaining the bridges, we can ensure that each tile of is copied to the correct position. As there are many pixels that we have to copy with cost of per pixel, the strategy needs unit steps to terminate.
Now consider the number of auxiliary tiles. We need tiles for the copy and tiles for bridges, which are reused for each column. Thus, we need auxiliary tiles in total. Because we place the copied version of beneath , we need additional space in the vertical direction. ∎
6.2 Reflecting a Polyomino
In this section we show how to perform a vertical reflection on a polyomino (a horizontal reflection is done analogously). Assume that we already built the bounding box. Then we shift the bottom side of the bounding box one unit down, such that we have two units of space between the bounding box and . We start with the bottom-most row and copy in reversed order beneath the bounding box using bridges, as seen in the previous section. After the copy process, we delete from and shift the bottom side of the bounding box one unit up. Note that we still have two units of space between the bounding box and . We can therefore repeat the process until no tile is left.
Reflecting a polyomino vertically can be done in unit steps, using of additional space and auxiliary tiles.
For each pixel within the bounding box we have to copy this pixel to the desired position. This costs steps, i.e., we have to move to the right side of the boundary, move a constant number of steps down and move to the desired position. These are steps per pixel, unit steps in total.
It can be seen in the described strategy that we only need a constant amount of additional space in one dimension because we are overwriting the space that was occupied by . This implies a space complexity of . Following the same argumentation of Theorem 6, we can see that we need auxiliary tiles. ∎
Reflecting a polyomino vertically and horizontally can be done in unit steps, using additional space and auxiliary tiles.
6.3 Rotating a Polyomino
Rotating a polyomino presents some additional difficulties, because the dimension of the resulting polyomino has dimensions instead of . Thus, we may need non-constant additional space in one dimension, e.g., if one dimension is large compared to the other dimension. A simple approach is to copy the rows of bottom-up to the right of . This allows us to rotate with additional space. For now, we assume that .
We now propose a strategy that is more compact. The strategy consists of two phases: First build a reflected version of our desired polyomino, then reflect it to obtain the correct polyomino.
After constructing the bounding box, we place a tile in the bottom-left corner of the bounding box, which marks the bottom-left corner of (see Fig. 12). We also extend the bounding box at the left side and the bottom side by six units. This gives us a width of seven units between the polyomino and the bounding box at the left and bottom side. Now we can move the first column rotated in clockwise direction five units below (which is two units above the bounding box), as follows.
We use two more tiles denoting the column, at which we have to enter the bounding box, and marking the pixel that has to be copied next (see Fig. 12). We can maintain these tiles as in a copy process to always copy the next pixel: If reached , i.e., we would place on , then we know that we have finished the column and proceed with the row by moving to the right of . We can copy this pixel to the desired position again by following the bridges and tiles that now make a turn at some point (see Fig. 12 for an example). Note that we cannot place the row directly on top of the column or else we may get conflicts with bridges. We therefore build the row one unit to the left and above the column. Also note that during construction of the first column or during the shifting we may hit the bounding box. In this case we extend the bounding box by one unit.
After constructing a column and a row, we move the constructed row one unit to the left and two units down, and we move the column one unit down and two units left. This gives us enough space to construct the next column and row in the same way.
When all columns and rows are constructed, we obtain a polyomino that is a reflected version of our desired polyomino. It is left to reflect horizontally to obtain a polyomino rotated in counter-clockwise direction, or vertically to obtain a polyomino that is rotated in clockwise direction. This can be done with the strategy described above.
There is a strategy to rotate a polyomino by within unit steps, using of additional space and auxiliary tiles.
Like in other algorithms, the number of steps to copy the state of a pixel to the desired position is bounded by . Shifting the constructed row and column also takes the same number of steps. Therefore, constructing the reflected version of our desired polyomino needs unit steps. Additionally we may have to extend one side of the bounding box. This can happen at most times, with each event needing unit steps. Because can be bounded by , this does not change the total time complexity.
Because the width of the working space increases by and the height only increases by , we need of additional space. It is straightforward to see that we need a total of auxiliary tiles. ∎
6.4 Scaling a Polyomino
Scaling a polyomino by a factor replaces each tile by a square. This can easily be handled by our robot.
Given a constant , the robot can scale the polyomino by within unit steps using additional tiles and additional space.
After constructing the bounding box, we place a tile denoting the current column. Suppose we are in the -th column . Then we shift all columns that lie to the right of by units to the right with cost of , where is the number of tiles in the th column. Because is a constant, we can always find the next column that is to be shifted. Afterwards, we copy exactly times to the right of , which costs unit steps. Thus, extending a single row costs and hence extending all rows costs unit steps in total.
Extending each row is done analogously. However, because each tile has already been copied times, we obtain a running time of . This implies a total running time of . The proof for the tile and space complexity is straightforward. ∎
We have given a number of tools and functions for manipulating an arrangement of tiles by a single robotic automaton. There are various further questions, including more complex operations, as well as sharing the work between multiple robots. These are left for future work.
-  M. Blum and D. Kozen. On the power of the compass (or, why mazes are easier to search than graphs). In Proc. 19th Annual Symposium on Foundations of Computer Science, pages 132--142, 1978.
-  A. Bonato and R. J. Nowakowski. The Game of Cops and Robbers on Graphs. AMS, 2011.
-  S. Das. Mobile agents in distributed computing: Network exploration. Bulletin of the European Association for Theoretical Computer Science, 109:54--69, 2013.
-  E. Demaine, M. Demaine, M. Hoffmann, and J. O’Rourke. Pushing blocks is hard. Computational Geometry, 26(1):21--36, 2003.
-  E. D. Demaine, S. P. Fekete, C. Scheffer, and A. Schmidt. New geometric algorithms for fully connected staged self-assembly. Theoretical Computer Science, 671:4--18, 2017.
-  Z. Derakhshandeh, R. Gmyr, A. W. Richa, C. Scheideler, and T. Strothmann. Universal shape formation for programmable matter. In Proc. 28th ACM Symposium on Parallelism in Algorithms and Architectures, pages 289--299, 2016.
-  F. V. Fomin and D. M. Thilikos. An annotated bibliography on guaranteed graph searching. Theoretical Computer Science, 399(3):236--245, jun 2008.
-  R. Gmyr, K. Hinnenthal, I. Kostitsyna, F. Kuhn, D. Rudolph, and C. Scheideler. Shape recognition by a finite automaton robot. In 43nd International Symposium on Mathematical Foundations of Computer Science, 2018. To appear.
-  R. Gmyr, K. Hinnenthal, I. Kostitsyna, F. Kuhn, D. Rudolph, C. Scheideler, and T. Strothmann. Forming tile shapes with simple robots. In 23rd International Conference on DNA Computing and Molecular Programming, 2018. To appear.
-  F. Hurtado, E. Molina, S. Ramaswami, and V. Sacristán. Distributed reconfiguraiton of 2D lattice-based modular robotic systems. Autonomous Robots, 38(4):383--413, 2015.
-  K. Lund, A. Manzo, N. Dabby, N. Michelotti, A. Johnson-Buck, J. Nangreave, S. Taylor, R. Pei, M. Stojanovic, N. Walter, and E. Winfree. Molecular robots guided by prescriptive landscapes. Nature, 465(7295):206--210, 2010.
-  E. Markou. Identifying hostile nodes in networks using mobile agents. Bulletin of the European Association for Theoretical Computer Science, 108:93--129, 2012.
-  O. Michail and P. G. Spirakis. Simple and efficient local codes for distributed stable network construction. Distributed Computing, 29(3):207--237, 2016.
-  T. Omabegho, R. Sha, and N. Seeman. A bipedal DNA Brownian motor with coordinated legs. Science, 324(5923):67--71, 2009.
-  M. J. Patitz. An introduction to tile-based self-assembly and a survey of recent results. Natural Computing, 13(2):195--224, 2014.
-  A. Pelc. Deterministic rendezvous in networks: A comprehensive survey. Networks, 59(3):331--347, 2012.
-  J. H. Reif and S. Sahu. Autonomous programmable DNA nanorobotic devices using dnazymes. Theoretical Computer Science, 410:1428--1439, 2009.
-  A. N. Shah. Pebble automata on arrays. Computer Graphics and Image Processing, 3(3):236--246, 1974.
-  J. Shin and N. Pierce. A synthetic DNA walker for molecular transport. Journal of the American Chemical Society, 126:4903--4911, 2004.
-  Y. Terada and S. Murata. Automatic modular assembly system and its distributed control. International Journal of Robotics Research, 27(3--4):445--462, 2008.
-  A. Thubagere, W. Li, R. Johnson, Z. Chen, S. Doroudi, Y. Lee, G. Izatt, S. Wittman, N. Srinivas, D. Woods, E. Winfree, and L. Qian. A cargo-sorting DNA robot. Science, 357(6356), 2017.
-  Z. Wang, J. Elbaz, and I. Willner. A dynamically programmed DNA transporter. Angewandte Chemie International Edition, 51(48):4322--4326, 2012.
-  S. Wickham, J. Bath, Y. Katsuda, M. Endo, K. Hidaka, H. Sugiyama, and A. Turberfield. A DNA-based molecular motor that can navigate a network of tracks. Nature Nanotechnology, 7(3):169--173, 2012.
-  D. Woods, H. Chen, S. Goodfriend, N. Dabby, E. Winfree, and P. Yin. Active self-assembly of algorithmic shapes and patterns in polylogarithmic time. In Proc. 4th Conference of Innovations in Theoretical Computer Science, pages 353--354, 2013.