Module Shape

The shape of modules in the RoFI platform is based on a 10cm cube grid. There is an inscribed sphere in each cell of the grid. By saying a module occupies a grid cell we mean that it occupies the sphere inscribed to the cell. Two grid cells are adjacent if they share a common face. Therefore, each cell has 6 adjacent cells.

Each module in its default state (with all joints in neutral position) should occupy one or more adjacent cells of the grid. If the module occupies more than a single cell, it is also allowed to occupy the space of corresponding module hull. Consider two adjacent cells occupied by the module body. Then there is a convex hull of their inscribed spheres (see double cell module in figure below). We then define the module hull as the union of all such existing convex hulls for the module. See figure below for an example. When we reference a module shape, we use following terminology:

  • a shoe is a part of the module occupying a cell sphere and
  • a body is a part of the module occupying mainly the rest of the space from the module hull.

See the usage of the terminology on the universal module.

Example of a module hull construction. Each convex hull of adjacent cells is denoted by a coloured area. The module hull is the union of coloured areas. Note that the coloured areas slightly overlap the grid. This is only for the purpose of visualization. In reality they fit exactly in the grid.

The modules are allowed to change their shape by offering several degrees of freedom in the form of joints. Joint is a single rotational or linear degree of freedom. Intuitively, we can imagine a module as beads, which can rotate against each other along the axes of joints. For a simple example of a double cell module movement see figure below.

Why To Restrict The Shape?

The motivation for such a restriction of the shape is a property we call grid-awareness. Consider a simple task for a double cell module: having a grounded left part of the module, move its right part above the left one. Figure bellow illustrates the task. If we consider a module which fits exactly inside a cube-shaped cell, e.g. an M-TRAN module, the module occupies extra cells during the movement (marked by red circles in the figure). Such a shape restricts the module movement in a densely occupied grid. However, if we consider a grid-aware module (e.g., double cell module), it only occupies the minimal number of cells necessary for the movement and as a result. it should allow for more efficient reconfiguration algorithms. The key to grid-awareness is a sphere inscribed in a cell. Therefore, Roombots are not grid-aware even though their shape is a sphere. Their bodies cannot be inscribed in spheres inside grid cells. Grid-awareness, however, comes at a cost. It requires a retractable connector mechanism as two neighbouring modules can feature only point contact. See RoFICoM for our solution of the problem.

Visualization of grid-awareness. Consider two module shapes — [M-TRAN](https://www.wevolver.com/wevolver.staff/m-tran/) like (in the top row) and a RoFI like (in the bottom row). Given the task to move right body over the left one, M-TRAN like module occupies extra cells due to small parts of its body overlapping out of the gird. That is not true for the RoFI like module as it occupies the least number of cells required to make the movement.

We want to point out that even though we showed grid-fitting positions of the robots (where all movement is performed by steps of 90 °) in all examples, we do not give any restriction on the granularity of the movement. We assume the modules are physically able to move practically continuously (considering limits of a mechanical construction). However, the reconfiguration algorithms built on top of the system can take only discrete steps in the movement into account if they need to.

Module Types

The shape specification allows us to define modules with various shapes and functionality. However, we do not expect the platform to feature many different types of modules and especially oddly shaped ones. We firmly believe that the double cell universal module should be the primary building block of RoFI systems. However, in future, we consider having, e.g., a passive module (built only from a mechanical construction), an accumulator module or single-cell modules featuring specialized sensors (e.g., camera) or actuators (e.g., a robotic hand or a wheel).

Connectors in The Grid System

So far, we omitted the placement of the connectors. Consider a shoe, the basic abstract building block of modules. We define the origin of the shoe in the middle of the sphere. There are up to 6 adjacent shoes in the grid (in both directions of all axes X, Y, and Z.) The directions define six possible connector positions which we name after an axis direction. We name it \(\mathcal{P} = \left\{+X, -X, +Y, -Y, +Z, -Z\right\}\). We also specify an orientation of the connector.

Therefore, each RoFI module can specify a subset of docks it features for each cell it occupies. Once we introduce module descriptors, we will be able to name each dock unambiguously.

There are 6 positions for the docks on a shoe -- in the centers of faces of the corresponding cell cube. The docks are named using the axes names. Small arrows denote the orientation vector of each dock.

Connector Orientation

The docks can connect in four different mutual orientations. To uniquely name them, we use the orientation vector of each connector. When two connectors connect, there can be an angle of 0 °, 90 °, 180 °, 270 ° between their orientation vectors (measured counterclockwise from a perspective one of the modules; looking from the shoe center to the dock center). Notice that the angle is the same no matter which module we choose. Therefore, we introduce a following convention: If we aim one of the orientation vectors up (to the north), the other vector aims either: north, east, south or westas shown in figure below. Therefore, we define the mutual orientation \(o\) to be an element of \(\mathcal{O} = \{N, E, S, W\}\).

Possible orientation of two docks. The orientation vector of the current perspective is shown red, the orientation vector of the mating dock is shown blue. Note that it does not matter which dock's perspective we choose.