# RoFI Module Descriptors

Grid system gives an idea about all possible shapes of the RoFI modules and also provides examples of use cases for shape other than the universal module. To allow interaction of different modules and also to build a formal description of RoFI systems, there is a need to establish a way to describe various modules and their capabilities. There are two aspects to consider:

- modules have various shapes and can perform various movements and
- modules feature various sensors and special functions.

*RoFI descriptors* cover both of these aspects. Descriptors can be exchanged by
the modules when they connect to build a notion of the system which is essential
for any reconfiguration. We distinguish two types of descriptors:

*shape descriptor*() and- a
*capability descriptor*().

We define the shape descriptor as a tuple where:

- is a finite set of shoes,
- is a finite set of bodies,
- is a finite set of edges, formally such that there are no symmetric edges and self-loops,
- is a function returning a transformation function joint transformation matrix for a given edge, formally: ,
- is a function giving a set of dock present on each shoe. Formally, .

Intuitively, is an oriented graph, with two types of nodes – shoes and bodies, where edges are labeled by functions returning 3D transformation matrices. Note that the graph can be cyclic; however, for each pair of vertices, there is at most one edge. When drawing descriptors, we denote shoes as circles, bodies as squares and we write the functions on edges. See an example of such a descriptor for a universal module:

Each edge with a non-constant function represents a joint. Further in the text we will abuse the notation a little and name the edges, arguments of the corresponding transformation functions and corresponding joints by the same name – usually by a small Greek letter. The type of the object represented by the name should be obvious from the context. For example, we name the edge as , the same as the corresponding joint and the argument of rotation. Also, for practical reasons we consider all descriptors to have unique naming of shoes and bodies (easily achieved by prefixing the name by module name); however, in the examples, we omit the prefix to make them simple.

Given the joint positions, the shape descriptors allow for easy computation of shoe positions in the space. The path in a descriptor between two shoes defines a transformation matrix representing the relative the position of the two shoes. However, finding such a path might not always be possible due to the orientation of the edges. By defining a function flip for labeling reversed edges such that:

an orientation of an edge can be reversed. Once reversed, the edge is labeled by a function returning an inverse transformation compared to the original label. Therefore, there is a path between every two shoes in the module (the module must be weakly connected by definition).

It is possible to extend the idea of module descriptors further to find positions of the connectors. A descriptor of a single shoe can be constructed in the same manner as a descriptor for any other module (figure below). The transformations for connectors are constant functions. The coordinate system is transformed such that the Z-axis is perpendicular to the connectors, and the X-axis is coincident with the orientation vector. We do not consider the connectors to be a part of the shape descriptor as they are the same for each shoe and therefore for the sake of simplicity, they can be omitted. However, we find them useful to consider the following construction.

So far, we considered descriptors only in the context of a single module. We can
further extend the method to multiple modules. Two descriptors can be joined by
adding edges between connected connectors. The relative position of any two
shoes in the system can be computed using this graph. The construction of the
connection is illustrated in figure below. We will refer to this operation as a
*shape descriptor union*.

To allow algorithms to take various sensors present on modules into account, a simple sensor enumeration is not enough as the position of the sensor matters. Therefore, the RoFI platform allows sensors to be placed on faces of the shoe. The faces are named as the corresponding connectors (see grid system for more details). The capability descriptor is a function , where is a set of all possible sensors. Intuitively, is a labeling of individual connectors on the module assigning sensors to them. The set of all sensors contains sensor-dependent descriptions.

# RoFI Configurations

So far, we gave means to describe a single module. To ease and unify the development of a firmware and reconfiguration algorithms, we also give means to describe a system consisting of the RoFI modules.

First, there is a globally unique ID (*GUID*) assigned to each instance of
a module. GUID is a 128-bit number to prevent GUID exhaustion. Second, when
talking about RoFI systems, we distinguish two terms:

- a
*topology*() and - a
*configuration*():

## Topology

Intuitively, topology describes the connection between the modules in a system and does not take in account the physical layout of the modules. Formally, we define a topology as a tuple :

- is a finite set of modules represented by GUID, formally , where is a set of all GUIDs.
- is a finite set of undirected edges (connections) between the modules. Note that the undirected edge forces that both modules have to actively participate in a connection.
- is a labeling function for edges. The function assigns a set of labels to an edge. The labels are tuples in the form , where is a mutual orientation of connected connectors, and from modules in the edge. The order of connectors in the tuple is given lexicographically (first by module GUID, second by the dock name). Therefore the labels are canonical.

## Configuration

Intuitively, a configuration is a topology with the module joints positions. Formally, a configuration is a pair :

- is a topology and
- , where is a union of axes from all module types, is a function assigning values to all joints in the system.

## Valid Configurations

We define a *model of a topology* as a descriptor
obtained by the following procedure:

- rename uniquely descriptors of each module instance in the system, then
- select an arbitrary one and
- unite the selected descriptor consequently with the other modules using a module union.

We define a *model* of a configuration
as a model of , where labels were evaluated according to , i.e.,
labels are constant values. Configuration is *realizable* iff:

- for all pairs of shoes, all paths between them in the model of yield the same relative position and
- no two shoes in the model of intersect.

There are no constraints on the topology; therefore, we consider every topology valid. However, for some topologies there exists no realizable configuration. Given the terminology, there are few aspects to note:

- To move the robot means to change a configuration.
- A change in a configuration can also mean a change in a topology.
- A change in a topology always means a change of a configuration.