Swarm in Blocks: Modular Architecture

• Swarm in Blocks is a design pattern that mediates collective behavior through intermediate modular units like neural blocks, group methods, or visual code blocks.
• The approach spans diverse applications, including neural architecture search with PSO, collection-level programming, set-equivariant learning, and block-based drone control.
• Methodologies such as particle swarm optimization, compiler transformation, and block-based user interfaces enable enhanced efficiency, scalability, and domain-specific optimization.

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 (Wang et al., 2019); in another, “Swarm Behavior” denotes a composition operator that binds methods to collections of instances rather than to individual objects (Kuhn et al., 2010). 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 (Almeida et al., 15 Aug 2025). 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 (Wang et al., 2019, Kuhn et al., 2010, Almeida et al., 15 Aug 2025, Mahadev et al., 2017, Ishida, 2024).

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 (Wang et al., 2019). 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 $H_l$0 (Wang et al., 2019).

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 (Wang et al., 2019).

EffPNet extends the same block-centric principle with surrogate-assisted PSO and a variable-length dense-block encoding (Wang et al., 2020). 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 $H_l$1 losses and accuracies; with 16 block parameters, 10 losses, and 10 accuracies from each of two blocks, the paired feature vector has

$H_l$2

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 (Wang et al., 2020).

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 (Wang et al., 2020). 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 (Kuhn et al., 2010). 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 $H_l$3 is a Collection, computes the element-type set

$H_l$4

then computes

$H_l$5

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 (Kuhn et al., 2010).

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</code>, moving <code>@Group</code> methods into the wrapper, and rewriting calls like$$gr$9 into $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)),$0 (Kuhn et al., 2010).

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 (Kuhn et al., 2010).

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 (Vollgraf, 2019). The formal requirement is set equivariance: $H_l$6 for any permutation $H_l$7 of the entities. The paper also notes that if each layer $H_l$8 is set-equivariant, then the composition

$H_l$9

is set-equivariant as well (Vollgraf, 2019).

The SWARM layer is based on a modified LSTM cell. For entity $3\times3$0, a gate is computed as

$3\times3$1

where $3\times3$2 is the entity input, $3\times3$3 is the entity’s hidden state, and $3\times3$4 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 (Vollgraf, 2019).

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 $3\times3$5, 3 to 10 clusters, and a 9,000/1,000 train/validation-test split, the best validation losses were $3\times3$6 for SetLinear, $3\times3$7 for SetLinear (max), $3\times3$8 for LSTM, $3\times3$9 for LSTM (sorted), $nol$0 for SetTransformer, and $nol$1 for SWARM (Vollgraf, 2019). 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 (Vollgraf, 2019).

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” (Almeida et al., 15 Aug 2025). 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 (Almeida et al., 15 Aug 2025).

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 (Almeida et al., 15 Aug 2025).

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 (Almeida et al., 15 Aug 2025).

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 (Almeida et al., 15 Aug 2025). 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 (Almeida et al., 15 Aug 2025).

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 (Almeida et al., 15 Aug 2025). 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 (Almeida et al., 15 Aug 2025).

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 $nol$2 (Mahadev et al., 2017). 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

$nol$3

Its runtime and memory are both $nol$4, where $nol$5 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 (Mahadev et al., 2017).

The same paper also provides the greedy pairwise subroutine CollectAB, and proves that it collects two particles in a polyomino with $nol$6 discrete control commands and computational complexity $nol$7. For an entire small-particle swarm of size $nol$8, the paper gives $nol$9 commands and $gr$0 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 (Mahadev et al., 2017).

A different modular interpretation appears in the Turing-pattern-based control of active swarm robots (Ishida, 2024). 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

$gr$1

and module motion follows

$gr$2

In simulation on a 100 × 100 hexagonal lattice, with standard parameters $gr$3, $gr$4, $gr$5 or $gr$6, initial radius $gr$7, and $gr$8, 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 (Ishida, 2024).

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 (Wang et al., 2019, Wang et al., 2020). In Swarm Behavior, the swarm is a collection of instances and the operative unit is a group method resolved by element type (Kuhn et al., 2010). In SWARM mappings, the swarm is an unordered population of entities processed by recurrent set-equivariant layers (Vollgraf, 2019). In Swarm-in-Blocks, the blocks are visual programming elements for multi-drone control on top of Clover and ROS (Almeida et al., 15 Aug 2025).

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 (Wang et al., 2019). 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 (Wang et al., 2020). Swarm Behavior requires compiler transformation through JavaGroups and wrapper-class generation rather than ordinary runtime dispatch (Kuhn et al., 2010). SWARM mappings are strong on direct amortized clustering, but the paper notes that CIFAR10 image generation is less successful than MNIST and FashionMNIST generation (Vollgraf, 2019). 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 (Almeida et al., 15 Aug 2025).

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.