---
title: 'Swarm in Blocks: Modular Architecture'
url: https://www.emergentmind.com/topics/swarm-in-blocks
type: topic
---

# Swarm in Blocks: Modular Architecture

Searching arXiv for recent and directly relevant papers on "Swarm in Blocks" and closely related usages.
First, I’ll look for the exact phrase "Swarm-in-Blocks" on arXiv.
Now I’ll search for adjacent technical usages combining swarm methods with blocks, transferable blocks, and swarm behavior.
“Swarm in Blocks” is not a single formalism in the arXiv literature. Instead, the phrase and closely related constructions recur in several technically distinct settings in which swarm-level behavior is mediated by an intermediate unit such as a reusable neural block, a collection-level method, a set-processing layer, a grid of blocked cells, or a visual programming block. In one line of work, particle swarm optimisation is used to evolve a compact DenseNet-like block that is then stacked to form an image classifier [1907.12659]; in another, “Swarm Behavior” denotes a composition operator that binds methods to collections of instances rather than to individual objects [1007.0159]. A separate usage appears in the browser-based drone platform “Swarm-in-Blocks,” which provides a block-based interface atop Clover and ROS for coordinated multi-drone programming [2508.11498]. Taken together, these works treat the “swarm” as a collective object while localizing design, execution, or control into modular units.

## 1. Terminological scope and recurrent abstraction

Across the cited works, the central abstraction is not merely multiplicity, but a controlled interface between collective behavior and a smaller design unit. In neural architecture search, the unit is a CNN block; in programming-language design, it is a group method attached to the element type of a collection; in drone programming, it is a visual code block exposed through a browser interface; in physical swarm control, it may be a grid cell, obstacle block, or modular robot cell [1907.12659] [1007.0159] [2508.11498] [1701.00441] [2405.17868].

| Context | Collective object | Intermediate unit |
|---|---|---|
| NAS with PSO | CNN assembled from repeated motifs | Dense block |
| Java Swarm Behavior | Collection of instances | `@Group` method |
| Set-equivariant learning | Unordered population | SWARM layer |
| Drone programming | Multi-drone swarm | Blockly-style code block |
| Grid or modular swarm control | Particle or module ensemble | Cell, obstacle block, or local module |

This suggests that “Swarm in Blocks” functions less as a domain-specific term than as a recurring architectural pattern: the collective system is made tractable by elevating a mid-level unit that can be searched, composed, invoked, or manipulated.

## 2. Particle swarms evolving transferable neural blocks

In image classification, “swarm in blocks” is expressed most directly by EPSOCNN, a particle-swarm-based NAS method that searches for a single DenseNet-inspired block rather than a full CNN [1907.12659]. The dense block is defined by
\[
x_l = H_l([x_0, x_1, ..., x_{l-1}]),
\]
where \(H_l\) is batch norm + ReLU + \(3\times3\) convolution. EPSOCNN encodes only the number of layers in the block \(nol\) and the growth rate \(gr\), so each particle is a 2D vector. The PSO dynamics use the standard updates
\[
v_{id}(t+1) = w v_{id}(t) + c_1 r_1 (P_{id} - x_{id}(t)) + c_2 r_2 (P_{gd} - x_{id}(t)),
\]
\[
x_{id}(t+1) = x_{id}(t) + v_{id}(t+1).
\]

The efficiency claim rests on three explicit reductions. First, the search space is reduced to one block with \(\alpha_l = [6, 32]\) and \(\alpha_g = [12, 32]\). Second, candidate fitness is evaluated on a small random subset of the training set, split into 80% for training and 20% for validation/test. Third, the learned block is progressively stacked until performance stops improving or memory limits are exceeded. During fitness evaluation, Adam is used; the returned fitness is the best validation accuracy,
\[
\text{fitness} = acc_{best},
\]
and out-of-memory blocks receive fitness \(0\) [1907.12659].

On CIFAR-10, EPSOCNN was evaluated against 13 peer competitors including ResNet-110, DenseNet(k=40), EAS, NASNet, NASH, NAS, AmoebaNet, Hier. repr-n, CGP-CNN, DENSER, GeNet, CoDeapNEAT, and LS-Evolution. The reported best error rate is **3.58%**, the 10-run average is **3.74% ± 0.0154**, the best model has **6.74M** parameters, the average parameter count is **4.79M ± 1.5363M**, and the search cost is **< 4 GPU-days**. For CIFAR-10, the best architecture used the evolved block stacked three times [1907.12659].

EffPNet extends the same block-centric principle with surrogate-assisted PSO and a variable-length dense-block encoding [2007.01556]. Here the vector length is fixed to the maximum number of layers, which is **16**, with growth-rate range **[11, 32]** and special value **11** indicating a disabled layer. The surrogate model is an SVM classifier trained on paired block histories using the first \(c=10\) losses and accuracies; with 16 block parameters, 10 losses, and 10 accuracies from each of two blocks, the paired feature vector has
\[
(16+10+10)\times 2 = 72
\]
features. The surrogate is activated once its accuracy exceeds **90%**, and the paper reports that **80.1% of particles are filtered out**, so only 19.9% require full training [2007.01556].

The reported CIFAR-10 results for EffPNet are a best error of **3.49%**, **2.54M** parameters, and search cost of **less than 3 GPU-days**; over 10 runs it obtains **3.576% ± 0.0078** error with **2.68M ± 0.015M** parameters. Without further search, the evolved block is transferred to CIFAR-100 and SVHN, achieving best errors of **18.49%** and **1.82%**, respectively [2007.01556]. In both EPSOCNN and EffPNet, the swarm is the PSO population, while the block is the transferable design unit.

## 3. Swarm behavior as collection-level method dispatch

In programming-language research, “Swarm Behavior” has a different meaning. The paper “Empowering Collections with Swarm Behavior” introduces a composition operator that associates behavior with a collection of instances, with lookup based on the element type rather than the collection hierarchy [1007.0159]. The key addition is the **group method**, annotated with `@Group`, and defined in the lexical scope of the element class. In the running example, a `Collection<Fish>` can invoke `swarmAttack` because the relevant behavior is defined for `Fish`, not for `ArrayList`, `LinkedList`, or another collection subtype.

The lookup procedure is explicit. `Swarm-Lookup(O,S)` first performs ordinary instance-method lookup. If that fails, it requires that \(O\) is a `Collection`, computes the element-type set
\[
\mathcal{C}_\mathcal{E} \gets \left\{ C : C = class[E] \land E \in elements[O] \right\},
\]
then computes
\[
C_\mathcal{S} \gets Least\text{-}Upper\text{-}Bound(\mathcal{C}_\mathcal{E}),
\]
and searches upward through `group-methods[C_S]`. The least-upper-bound operator returns the most specific superclass shared by all elements in the collection [1007.0159].

This is orthogonal to the collection hierarchy. The paper contrasts it with three inadequate idioms: subclassing a collection, reopening the collection hierarchy, and static helper methods. The JavaGroups prototype implements the idea by source transformation in `javac`, generating wrapper classes such as `Fish$Group`, moving `@Group` methods into the wrapper, and rewriting calls like
```java
swarm.swarmAttack(shark);
```
into
```java
new Fish.Fish$Group(swarm).swarmAttack(shark);
```
[1007.0159].

A frequent misconception would be to read “swarm” here as a robotics term. In this literature, it instead denotes behavior that belongs to a collection as a group. The paper’s central sentence is that swarm behavior is “a new composition operator that associates behavior with a collection of instances,” and the decisive dispatch criterion is the least-upper-bound element type, not the receiver’s container class [1007.0159].

## 4. SWARM mappings and set-equivariant network blocks

A third usage appears in set learning. “Learning Set-equivariant Functions with SWARM Mappings” proposes a neural architecture for unordered populations in which each entity is updated individually while synchronizing with the whole population [1906.09400]. The formal requirement is set equivariance:
\[
\pi(f(\mathbf{x})) = f(\pi(\mathbf{x}))
\]
for any permutation \(\pi\) of the entities. The paper also notes that if each layer \(f_i\) is set-equivariant, then the composition
\[
f = f_1 \circ \cdots \circ f_n
\]
is set-equivariant as well [1906.09400].

The SWARM layer is based on a modified LSTM cell. For entity \(i\), a gate is computed as
\[
g_i = \sigma\left(W_{gx}x_i + W_{gh}h_i + W_{gp}p_i + b_g\right),
\]
where \(x_i\) is the entity input, \(h_i\) is the entity’s hidden state, and \(p_i = p(x_1,\ldots,x_N)\) is a set-invariant pooled population input. Parameters are shared across entities, and the same input set is processed recurrently over multiple iterations, with hidden and cell states initialized to zero [1906.09400].

The reported benchmark most relevant to the architecture’s efficacy is direct amortized clustering. On a dataset of 10,000 tasks with 100 to 1,000 points in \(\mathbb{R}^2\), 3 to 10 clusters, and a 9,000/1,000 train/validation-test split, the best validation losses were \(0.642 \pm 0.002\) for SetLinear, \(0.793 \pm 0.007\) for SetLinear (max), \(0.617 \pm 0.008\) for LSTM, \(0.582 \pm 0.006\) for LSTM (sorted), \(0.457 \pm 0.015\) for SetTransformer, and **\(0.416 \pm 0.004\)** for SWARM [1906.09400]. The paper also reports that unsorted LSTM predictions vary strongly with input ordering, with standard deviation about **15% of the expected loss on average** and up to **80%** on some tasks, whereas for set-equivariant models such as SWARM this variance is zero by design [1906.09400].

Here the relation to “blocks” is compositional rather than lexical. The paper does not title the SWARM layer a “block,” but it explicitly treats set-equivariant layers as composable units. A plausible implication is that the architecture belongs to the same broader design tendency seen elsewhere in the literature: collective behavior is implemented through reusable intermediate mappings rather than monolithic end-to-end structures.

## 5. Swarm-in-Blocks as a block-based drone programming system

The most literal use of the phrase is the paper “Swarm-in-Blocks: Simplifying Drone Swarm Programming with Block-Based Language” [2508.11498]. There, Swarm-in-Blocks is a high-level interface, originally developed for CopterHack 2022, that simplifies drone swarm programming using a block-based language on top of Clover and ROS. The system is explicitly positioned as a bridge for users who do not already know ROS, Python, or low-level drone control, while still supporting coordinated multi-drone behaviors, monitoring, and safety tooling [2508.11498].

The communication chain is described as
**Swarm-in-Blocks web interface → ROS nodes/services/topics → MAVROS bridge → drone flight controllers / PX4 / Clover hardware**.
ROS is the coordination backbone, MAVROS bridges flight-controller commands and telemetry into ROS messages, and the browser interface communicates with ROS through `roslibjs` [2508.11498].

The architecture includes four main components: **Block-Based Programming Interface**, **Robotic Nodes**, **Control System**, and **User Interface**. The implementation-level decomposition includes `swarm_clover_blocks`, `cloverUI`, sFPV, and `swarm_station`. The `swarm_clover_blocks` node exposes four services—**`run`**, **`stop`**, **`store`**, and **`load`**—and publishes the topics **`running`**, **`block`**, **`error`**, and **`prompt`**. Users can select a launch mode, choose an initial formation, create or load a block program, run the command, inspect telemetry and status, and use FPV or swarm-station tools for control and safety [2508.11498].

The platform includes formation generation for lines, circles, squares, triangles, cubes, pyramids, and spheres; a transformation subsystem with translation, scaling, and rotation implemented via matrix operations; and a collision-avoidance subsystem that considers three scenarios: one stationary and one moving drone, both drones moving on parallel paths, and both drones moving on non-parallel paths [2508.11498]. Additional subsystems include LED effects, web-based FPV, and Swarm Preview. The `swarm_station` package provides an **Information Center**, **Drone’s Process**, **Topic List**, **Web Terminal**, and **Safe Area**, the last of which automatically lands drones outside the geofenced region [2508.11498].

The paper’s simulation analysis compares two systems using Gazebo and reports **Real-Time Factor (RTF)** as the key metric. It states that when the number of drones exceeds 10, the Nvidia-based system’s RTF drops sharply and the system eventually crashes, whereas the AMD-based system maintains better stability and can support larger simulations [2508.11498]. The paper describes Swarm-in-Blocks 2.0 as extending the original prototype with web-based FPV, integrated swarm station support, improved formation, transformation, and collision-avoidance systems, and better browser-based workflows [2508.11498].

## 6. Blocked environments, modular swarms, and local aggregation

Several swarm-control papers also realize the “blocks” motif physically rather than representationally. In “Collecting a Swarm in a Grid Environment Using Shared, Global Inputs,” the workspace is a planar grid of unit-square cells, each either free space or obstacle, and the swarm is controlled only by a shared global input \(u,r,d,l\) [1701.00441]. The paper distinguishes discrete moves from maximal moves, small particles from large particles, and states that **“A swarm with discrete moves and small particles can be collected on any bounded grid.”** The optimal collecting algorithm performs BFS over configuration space and halts when
\[
|C_i| = 1.
\]
Its runtime and memory are both \(O(4^s)\), where \(s\) is the length of the shortest solution. For a world with **27 free spaces**, the optimal solution required expanding **423,440 nodes** and had an optimal path of **17 moves**; a workspace with **30 free spaces** required **1.6 million nodes** before finding the optimal solution [1701.00441].

The same paper also provides the greedy pairwise subroutine `CollectAB`, and proves that it collects two particles in a polyomino with \(O(n^3)\) discrete control commands and computational complexity \(O(n^3)\). For an entire small-particle swarm of size \(O(m)\), the paper gives \(O(m*n^3)\) commands and \(O(m*n^3)\) computational complexity. Among the tested greedy strategies, **connect to first** performs best consistently and required **50,607 moves** to converge all particles in the complete leaf-world example [1701.00441].

A different modular interpretation appears in the Turing-pattern-based control of active swarm robots [2405.17868]. The environment is a **2D hexagonal cellular space**, and each module has limited self-drive, no module identifier, only neighbor communication, no coordinate system, and only simple arithmetic and memory. The potential value is defined as
\[
\text{Potential Value} = (\text{Total number of integers from 1 to 16}) - (\text{Total number of integers from 1 to 8}) \times w,
\]
and module motion follows
\[
\text{Total Force} = \text{Attraction Force by Adjacent Modules} + \text{Attraction Force toward Light Source} + \text{Random Attraction Force}.
\]
In simulation on a **100 × 100 hexagonal lattice**, with standard parameters \(p = 8\), \(l = 10\), \(r = 1\) or \(r = 3\), initial radius \(R = 5.0\), and \(w = 0.2\), the system produces static shape formation, growth, motion toward a light source, shape-preserving escape through gaps of **3 cells** or **5 cells**, and self-replication [2405.17868].

These papers do not use “Swarm-in-Blocks” as a title, but they reinforce a consistent structural theme: swarm control is achieved through local interaction with discrete environmental or modular units rather than through centralized continuous-state control.

## 7. Conceptual distinctions, limitations, and common confusions

The literature makes clear that “Swarm in Blocks” is polysemous. In EPSOCNN and EffPNet, the swarm is an optimizer population and the block is a transferable CNN motif [1907.12659] [2007.01556]. In Swarm Behavior, the swarm is a collection of instances and the operative unit is a group method resolved by element type [1007.0159]. In SWARM mappings, the swarm is an unordered population of entities processed by recurrent set-equivariant layers [1906.09400]. In Swarm-in-Blocks, the blocks are visual programming elements for multi-drone control on top of Clover and ROS [2508.11498].

This distinction matters because the limitations are domain-specific. EPSOCNN reduces search cost by using one block and a small training subset, but the final model still depends on stacking to regain capacity [1907.12659]. EffPNet further lowers cost through surrogate filtering, yet its final block depends on hyperparameters such as maximum length, growth-rate bounds, surrogate threshold, feature-cutting epoch, and stacking depth [2007.01556]. Swarm Behavior requires compiler transformation through JavaGroups and wrapper-class generation rather than ordinary runtime dispatch [1007.0159]. SWARM mappings are strong on direct amortized clustering, but the paper notes that CIFAR10 image generation is less successful than MNIST and FashionMNIST generation [1906.09400]. Swarm-in-Blocks provides qualitative evidence and a Gazebo-based simulation study, but the paper does not provide a formal user study, quantitative benchmarking of the block language itself, or a detailed mathematical treatment of the formation and collision algorithms [2508.11498].

A plausible synthesis is that these works share a methodological preference for decomposing collective systems into reusable mesoscopic units. The unit may be a dense block, a wrapper class, a recurrent layer, a visual code block, or a local cell/module. What changes across domains is not the presence of the intermediate unit, but its semantics: search primitive, dispatch boundary, equivariant operator, user-interface construct, or physical substrate.

Source: https://www.emergentmind.com/topics/swarm-in-blocks