Reconfigurable Smart Bricks looks at the emergent geometry and construction strategies produced when using bricks as moving agents in a collaborative system. Specifically, it employs the python based Evo-Master environment to train neural-network controllers via NEAT, using Coppelia as an environment for simulation and testing.

The broad goal of this research examines how skills can be embedded directly in construction materials, which can allow for autonomous reconfiguration of a structure from one site to another, or locally as needs change. We see this smart brick as one possible evolution of the technological future for brickwork, wherein much research has already been done using on-site robot assembly.

This robotic application of this approach was inspired by the robotic movement and interaction of MIT’s M-Blocks project, which uses magnets and internal flywheels to create locomotion via rotating and flipping. Additionally, ITech’s Distributed Robotic Assembly System for In-Situ Timber Construction was an inspiration for applying swarm robotics to the built scale and using real-world construction materials.

Our initial exploration involves simulating a number of brick agents within a roughly two-dimensional problem space wherein the attempt to build the highest stack or pyramid in a limited amount of time.

As the implementation of these agents was being produced by evolution of a neural network, we chose to abstract certain parts of our scenario in order to remove details to focus on behavior. Within the simulation, our brick ‘robots’ contain no articulation, and can move either with a simple frictionless sliding, or a jumping flip implemented as the direct application of a torque force.

These movements were developed using simple hard-coded behavior within the simulator first as pictured above, before being attached to the neural network. Bricks without the knowledge to jump will simply pile up or crumple, and an over-application of the jumping will send the bricks past the assembly entirely.

Inputs to the network included globally relevant information as well as local context information. Firstly, the brick’s current global positions in the Y and Z axes are used, without scaling. Next, each brick counts the number of nearby bricks within a certain distance (0.25m in this case), and obtains totals for how many of these bricks it is higher than vs next to or lower than. Both of these counts are divided by the total bricks in the scene and used as inputs. Finally, each brick has a proximity sensor extending from its front and back side, from which the lower distance value return is added as an input.

Each brick’s actuation loop is split into sections for compiling the input, querying and ensuring the response from the network, and applying this response as output:

Looking at the input function itself, the bot will check distances against the previously found sibling bricks and relevant context bricks, as well as check its proximity sensors:

The network then returns three outputs to the bricks. The first is read as a speed at which to slide. Next, when the second output is above a certain threshold (0.5 usually), the bot will execute a jump (and pause briefly before attempting to slide again). Finally, if the third output is above the 0.5 threshold, the bot will set an internal ‘active’ flag to false, and not move any more for the course of the simulation. This allows the bricks to ‘plant’ themselves in an ideal spot in the pyramid once they’ve reached a certain height.

Looking at the output function, we see the reason for the pause after jumping. As simple movement is handled by directly setting the object position, this will normally reset the physics of the object; negating the applied force that creates the jump.:

Fitness of the simulation is measured based on the centerpoints of the brick objects. The highest z-value among the bricks is combined with the average z-value for all bricks; this encourages both reaching higher as well as tending towards a thinner, less spread out structure.
Each actuation loop, the different height values are calculated, added together, and sent to the python program:



The height calculations themselves are primarily simple greatest-in-list and average-of-list operations, with some considerations. Firstly, only bricks within a certain Y-axis range are considered, to prevent counting of bricks pre-stacked in the hopper. Additionally, bricks that have fallen out of the environment have their z-values counted as zero to avoid throwing off the average:

Finally, our need to respond to environmental objects (the existing pile of bricks) with several copies of the environment per Coppelia scene required some workarounds against the Coppelia automatic suffix system. Useful for transparently referring to internal components when an object has multiple sibling copies, the automatic suffix system will unfortunately try to apply itself to every call that involves object names. In response, we added ways to call functions either with no suffix or with the parent object’s suffix instead:

So for instance, to only find the context bricks attached to a bricks own clone group, we call:

Reconfigurable Smart Bricks is a project of IAAC, Institute for Advanced Architecture of Catalonia
developed at Master of Robotics and Advanced Construction in 2020 by:
Students: Anna Batallé, Irem Yagmur Cebeci, Matthew Gordon, AbelRahman Koura, Roberto Vargas
Faculty: Raimund Krenmueller, Soroush Garivani