A module is a hardware unit designed to be combined with others. Earlier lessons treated links, joints, actuators, sensors, and wiring as a fixed structure. In a modular robot, these elements are grouped into repeatable building blocks with standardized connectors.

Definition (Modular hardware system). A robot is modular if:

1. It can be decomposed into modules \( M_1,\dots,M_n \).
2. Modules connect through standardized interfaces (mechanical, electrical, and signaling).
3. Robot functionality results from composing modules without redesigning each module.

Reconfigurable robotics studies changing the robot’s physical arrangement (adding/removing/rearranging modules) to suit new tasks, without rebuilding the robot from scratch.

flowchart LR
  M["Module"] --> I1["Mechanical interface"]
  M --> I2["Electrical interface"]
  M --> I3["Signal interface"]
  I1 --> A["Assemble"]
  I2 --> A
  I3 --> A
  A --> R["Robot configuration"]
  R --> T["Task-specific behavior"]
        

Typical module families:

• Structural modules: rigid links, frames, shells.
• Actuation modules: motor + gear + local drive electronics.
• Sensing modules: encoder/IMU/range sensor packages.
• Compute/power modules: embedded controller, battery, power distribution.

Benefits: maintainability (swap a failed module), scalability (add more), rapid prototyping, and hardware reuse across robot families. Costs: interface overhead, lower stiffness, and combinatorial complexity in design/testing.

We model a robot’s hardware as a graph \( G=(V,E) \), where each vertex corresponds to a module and each edge to a physical/electrical interface.

Let \( A \in \mathbb{R}^{n\times n} \) be the adjacency matrix, where \( A_{ij}=1 \) if modules \(i\) and \(j\) are connected, else 0 (undirected for symmetric connectors). The degree of node \(i\) is \( k_i = \sum_{j=1}^n A_{ij} \), and total edge count is \( m=\tfrac{1}{2}\sum_{i}k_i \).

A common quantitative measure is community modularity: partition modules into communities \(c_i\in\{1,\dots,C\}\) representing subsystems intended to be tightly coupled internally (e.g., a leg, a sensor pod, a power block).

\[ Q = \frac{1}{2m}\sum_{i=1}^n\sum_{j=1}^n \left(A_{ij} - \frac{k_i k_j}{2m}\right)\delta(c_i,c_j) \]

Here \( \delta(c_i,c_j)=1 \) if \(i\) and \(j\) are in the same community and 0 otherwise. Intuitively: \( A_{ij} \) counts actual connections, while \( \frac{k_i k_j}{2m} \) is the expected connection count in a randomized graph with the same degrees. Thus \(Q\) is large when modules are more internally connected than chance.

Proposition (Boundedness). For any partition,

\[ -\frac{1}{2} \le Q \le 1. \]

Proof. Since \( \sum_{i,j} A_{ij}\delta(c_i,c_j) \le \sum_{i,j} A_{ij} = 2m \), we have \( \frac{1}{2m}\sum_{i,j}A_{ij}\delta(c_i,c_j)\le 1 \). Also, \( \frac{1}{2m}\sum_{i,j}\frac{k_i k_j}{2m}\delta(c_i,c_j) \ge 0 \), hence \(Q \le 1\). For the lower bound, note that \( \sum_{i,j} \left(A_{ij}-\frac{k_i k_j}{2m}\right)\delta(c_i,c_j) \ge -\sum_{i,j}\frac{k_i k_j}{2m}\delta(c_i,c_j) \ge -2m \), giving \(Q \ge -\tfrac{1}{2}\). ∎

In hardware terms, higher \(Q\) suggests clean subsystem boundaries: changes within a module group minimally disturb other groups.

A configuration is a connected graph built from a set of modules: \( c \equiv G_c=(V,E_c) \), where \(E_c\subseteq E_{\text{possible}}\) respects interface compatibility. A reconfiguration step adds/removes a single edge: \( c \to c' \).

flowchart TD
  C0["Current configuration G_c"] --> A1["Action: add/remove one interface"]
  A1 --> CK["Check constraints"]
  CK -->|ok| C1["New configuration G_c'"]
  CK -->|fail| C0
  C1 --> G["Repeat until task satisfied"]
        

Even with simple modules, the number of configurations grows quickly. If modules form a tree (no loops) and any module may connect to any other, the number of labeled trees on \(n\) modules is given by Cayley’s theorem.

Theorem (Cayley). The number of labeled trees on \(n\) vertices is

\[ N_{\text{tree}}(n) = n^{n-2}. \]

Proof (Prüfer sequence sketch). A labeled tree on vertices \(1,\dots,n\) can be encoded uniquely by a Prüfer sequence of length \(n-2\): iteratively remove the smallest leaf and record its neighbor. This map is bijective. There are \( n^{n-2} \) sequences, hence the same number of trees. ∎

Real modular robots have additional constraints (limited connector count, orientation rules, power buses), so the feasible set is a subset of these \(n^{n-2}\) possibilities, but the scaling insight remains: reconfiguration brings a combinatorial explosion that motivates structured modules and standardized topologies.

A candidate configuration must satisfy compatibility and resource constraints. Let each possible connection \((i,j)\) have a binary variable \( x_{ij}\in\{0,1\} \).

Mechanical compatibility. Use a compatibility matrix \( C^{(m)} \) with entries \( C^{(m)}_{ij}\in\{0,1\} \). Then feasible edges satisfy

\[ x_{ij} \le C^{(m)}_{ij}. \]

Electrical/power compatibility. Let module \(i\) draw power \(p_i\) and supply \(s_i\) (if any). For a connected robot,

\[ \sum_{i=1}^n p_i \le \sum_{i=1}^n s_i. \]

Stiffness degradation by modular joints. Interfaces often behave like compliant springs. For a chain of modules with interface stiffnesses \( k_1,\dots,k_\ell \) (series), the equivalent stiffness is

\[ k_{\text{eq}} = \left(\sum_{r=1}^{\ell}\frac{1}{k_r}\right)^{-1}. \]

Proposition. Adding a compliant interface decreases overall stiffness.

\[ k_{\text{eq}}(\ell+1) \le k_{\text{eq}}(\ell). \]

Proof. Let \(S_\ell = \sum_{r=1}^{\ell}\frac{1}{k_r}\). Then \(k_{\text{eq}}(\ell)=S_\ell^{-1}\). Adding an interface gives \(S_{\ell+1}=S_\ell+\frac{1}{k_{\ell+1}} \ge S_\ell\), so \(S_{\ell+1}^{-1} \le S_\ell^{-1}\). ∎

This is why modular robots may trade stiffness for flexibility and ease of assembly, a key architectural decision.

Repeated modules enable redundancy. Let module \(i\) have reliability (probability of functioning over a mission) \( R_i\in[0,1] \).

Series composition. If failure of any module fails the robot:

\[ R_{\text{series}} = \prod_{i=1}^n R_i. \]

Parallel redundancy. If any of \(q\) identical modules can perform a role:

\[ R_{\text{parallel}} = 1 - \prod_{j=1}^{q}(1-R_j). \]

Proposition (Redundancy improves reliability).

\[ R_{\text{parallel}} \ge \max_j R_j. \]

Proof. Since each term satisfies \(0 \le 1-R_j \le 1\), their product obeys \( \prod_{j}(1-R_j) \le 1-R_k \) for any \(k\). Hence \( R_{\text{parallel}} = 1-\prod_j(1-R_j) \ge 1-(1-R_k)=R_k \). Taking max over \(k\) gives the result. ∎

Modularity thus enables “hot-swappable” fault tolerance: redundant limbs, sensors, or batteries can keep a robot operating.

Hardware architects often pick modules and connections by solving a constrained multiobjective problem. A simple scalarization is:

\[ \min_{\{x_{ij}\}} J = w_1 M(\{x_{ij}\}) + w_2 P(\{x_{ij}\}) + w_3 \bigl(1-R_{\text{sys}}(\{x_{ij}\})\bigr) \]

where \(M\) is total mass, \(P\) total power draw, and \(R_{\text{sys}}\) computed from series/parallel compositions along functional chains. Constraints include compatibility and power inequalities from Section 4, plus graph connectivity (robot must be one connected component).

Though full solution methods come later in the course, this formulation explains why modular architectures need careful structure: the decision variables grow as \( O(n^2) \) through all potential connections.

We compute graph modularity \(Q\) for a toy modular robot and compare it to a less modular wiring pattern. We use networkx.

import networkx as nx

# Toy modular robot: two 3-module subsystems with one bridge
G = nx.Graph()
G.add_edges_from([
    (1,2),(2,3),(1,3),   # subsystem A
    (4,5),(5,6),(4,6),   # subsystem B
    (3,4)                # bridge
])

# Partition into two communities
communities = [{1,2,3}, {4,5,6}]
Q_modular = nx.algorithms.community.quality.modularity(G, communities)

# Less modular: connect everything densely
H = nx.complete_graph([1,2,3,4,5,6])
Q_dense = nx.algorithms.community.quality.modularity(H, communities)

print("Q modular robot =", Q_modular)
print("Q dense robot   =", Q_dense)

# Cayley theorem check for small n (trees only)
def cayley_count(n):
    return n**(n-2) if n >= 2 else 1

for n in range(2,7):
    print(n, "modules: tree configs =", cayley_count(n))
      

With a clear subsystem split, \(Q\) is higher, reflecting stronger modular boundaries.

#include <iostream>
#include <vector>
#include <string>

struct Module {
    std::string name;
    double stiffness;   // interface stiffness to next module (N/m)
    double powerDraw;   // W
    int mechType;       // simple mechanical connector type id
};

bool compatible(const Module& a, const Module& b) {
    return a.mechType == b.mechType; // toy rule: same connector type
}

double seriesStiffness(const std::vector<Module>& chain) {
    double invSum = 0.0;
    for (size_t i = 0; i < chain.size(); ++i)
        invSum += 1.0 / chain[i].stiffness;
    return 1.0 / invSum;
}

int main() {
    Module m1{"LinkA", 3000, 10, 1};
    Module m2{"JointA", 2000, 25, 1};
    Module m3{"LinkB", 1500, 10, 1};

    if (!compatible(m1, m2) || !compatible(m2, m3)) {
        std::cout << "Incompatible modules!\\n";
        return 0;
    }

    std::vector<Module> chain{m1, m2, m3};
    std::cout << "Equivalent stiffness: " <<
        seriesStiffness(chain) << " N/m\\n";
    return 0;
}
      

This snippet mirrors Section 4: compatibility gates feasible edges, and interface stiffness composes in series.

import java.util.*;

class Module {
    public String name;
    public double reliability; // R_i
    public Module(String name, double r) {
        this.name = name; this.reliability = r;
    }
}

public class ReliabilityDemo {

    // Series reliability: product of R_i
    static double series(List<Module> mods) {
        double R = 1.0;
        for (Module m : mods) R *= m.reliability;
        return R;
    }

    // Parallel reliability: 1 - product(1 - R_j)
    static double parallel(List<Module> mods) {
        double failProd = 1.0;
        for (Module m : mods) failProd *= (1.0 - m.reliability);
        return 1.0 - failProd;
    }

    public static void main(String[] args) {
        List<Module> sensorTriplet = Arrays.asList(
            new Module("IMU1", 0.96),
            new Module("IMU2", 0.96),
            new Module("IMU3", 0.96)
        );

        System.out.println("Series R (all needed): " + series(sensorTriplet));
        System.out.println("Parallel R (any works): " + parallel(sensorTriplet));
    }
}
      

Parallel redundancy increases reliability, consistent with Section 5.

% Modular chain stiffness (series) and redundancy reliability
k = [3000, 2000, 1500];          % interface stiffnesses N/m
R = [0.98, 0.95, 0.97];          % module reliabilities

k_eq = 1 / sum(1 ./ k);
R_series = prod(R);

% Add parallel redundancy for module 2 (two identical backups)
R2_parallel = 1 - (1 - R(2))^2;
R_sys_redundant = R(1) * R2_parallel * R(3);

fprintf('Equivalent stiffness: %.2f N/m\\n', k_eq);
fprintf('Series reliability: %.5f\\n', R_series);
fprintf('Redundant reliability: %.5f\\n', R_sys_redundant);

% Simulink note:
% In Simscape Multibody, represent each module as a masked subsystem
% with standardized frame ports; reconfiguration becomes swapping subsystems.
      

A common pattern is to build each module as a reusable Simulink subsystem with fixed mechanical/electrical port definitions.

Problem 1 (Compute modularity \(Q\)). Consider a robot graph with two communities: \(C_1=\{1,2,3\}\) and \(C_2=\{4,5\}\). Edges are \((1,2),(2,3),(1,3)\) within \(C_1\), \((4,5)\) within \(C_2\), and one bridge \((3,4)\). Compute \(Q\).

Solution. Degrees: \(k_1=2,k_2=2,k_3=3,k_4=2,k_5=1\), so \(2m=\sum k_i=10\) and \(m=5\). Sum over pairs within communities:

• Within \(C_1\): actual edges = 3.
• Expected edges within \(C_1\): \(\frac{1}{2m}\sum_{i,j\in C_1}\frac{k_i k_j}{2m} = \frac{(k_1+k_2+k_3)^2}{(2m)^2} = \frac{(2+2+3)^2}{10^2}=\frac{49}{100}\).
• Within \(C_2\): actual edges = 1.
• Expected edges within \(C_2\): \(\frac{(k_4+k_5)^2}{(2m)^2} = \frac{(2+1)^2}{10^2}=\frac{9}{100}\).

Therefore

\[ Q = \frac{1}{2m}\Bigl[(3+1) - (10)\cdot\left(\frac{49}{100}+\frac{9}{100}\right)\Bigr] = \frac{1}{10}(4 - 5.8)= -0.18. \]

The negative value indicates weak modular separation for this tiny example, mainly because degrees are skewed by the bridge.

Problem 2 (Configuration growth). Assume \(n\) labeled modules can connect into any tree configuration. How many configurations exist for \(n=6\)?

Solution. By Cayley, \( N_{\text{tree}}(6)=6^{6-2}=6^4=1296 \).

Problem 3 (Stiffness penalty). A modular arm has interfaces with stiffnesses \(k_1=4000\) N/m and \(k_2=2000\) N/m. Compute the equivalent stiffness. If a third interface \(k_3=1000\) N/m is added, compute the new stiffness and verify it decreases.

Solution. For two interfaces:

\[ k_{\text{eq}}(2)=\left(\frac{1}{4000}+\frac{1}{2000}\right)^{-1} =\left(0.00025+0.0005\right)^{-1}=1333.33\text{ N/m}. \]

With three interfaces:

\[ k_{\text{eq}}(3)=\left(0.00025+0.0005+0.001\right)^{-1} =571.43\text{ N/m}. \]

Indeed \(571.43 \le 1333.33\), matching the proposition.

Problem 4 (Redundancy gain). A sensing role can be performed by any one of three identical modules each with reliability \(R=0.9\). Compute series and parallel reliabilities and compare.

Solution. Series (all must work): \( R_{\text{series}}=0.9^3=0.729 \). Parallel (any works):

\[ R_{\text{parallel}}=1-(1-0.9)^3 = 1-0.1^3 = 0.999. \]

Parallel redundancy yields a large reliability gain.

We framed modular robot hardware as a graph of interoperable modules, quantified modularity using \(Q\), and modeled reconfiguration as a discrete state space whose size grows combinatorially. We derived key interface constraints, showed how modular joints reduce stiffness, and proved that parallel redundancy increases system reliability. These ideas support architectural decisions about how “chunky” a robot should be and how much reconfiguration capability is worth the overhead.