Figure 1. Qubrick's final prototype.

For my final project I made Qubricks, a making kit that brings together two different design processes, that of hands-on experimentation and that of experimentation through the use of 3D modeling software. As physical objects, they are bricks that attach with each other through magnets that are placed in the internal surfaces of their four sides. Each brick contains a central programmable microcontroller that allows the identification of its position and state, in terms of connectivity and spatial configurability, within the physical model. The pins of the microcontroller are connected to conductive pads on the external surfaces of the bricks; these pads power a microcontroller inside every brick by transfering electricity from a central power source through adjacent bricks; they also serve as datalines for the communication of neighboring microcontrollers. Each brick can identify its position by querying its neighbor ids and inform a central computer about it by passing messages in the network through serial communication. The central computer collects data from multiple bricks tracking the construction process piece by piece. It can also send custom commands to each brick to control its color which changes using an internal RGB LED. The LEDs can serve as indicators that guide a user during the reconstruction process of a particular design but they can also be integral parts of the design itself. The inputs and outputs created within the model are visualized via an node.js application that gets their spatial configurations in a 2-dimensional environment and creates an .svg drawing in the screen of the computer.

Video 1. Two Qubrick prototypes interacting.

The idea of programmable bricks has been developed by many researchers and designers inside and outside MIT. Relevant to Qubricks work that has been done beforehand includes:
- Mitchel Resnick's programmable brick,
- Kyle Gilpin's and Daniela Rus's Self-Disassembling Robot Pebbles,
- Dimitris Papanikolaou BlockNet.

For my final project I had the opportunity to use a lot of the topics that we covered throughout the semester: computer-aided design and 3d printing (for the bricks); computer controlled cutting (for the kit base and the semi-translucent parts of the bricks); embedded programming and output devices (for the RGB LED and the PCB programming); networking (for the communication and the connections among the bricks); interfaces and applications (for the visualization of the configurations of the bricks).

The design of my bricks ended up being much simpler than the one that I had proposed in week 1, however I had to consider a lot of parameters this time (Fig. 3):
- the size of the copper conductive strips (6 mm) each,
- the diameter of the magnet (1.27 mm), which I did not want to involve in my electronics part (I will definitely do it in a future project), so I had to keep it untouched by the copper pads
- the size of my pcb (31.5 x 37.5 mm), which I wanted to press-fit in a socket in the 3d-printed brick bottom.

Figure 4. Designing my model in Rhinoceros; apart from the brick shells, I designed the 3d printed pads that were later covered with the adhesive copper tape so that they would be conductive.

Figure 6. Vinyl-cutting the pads and the strips.

After modeling my brick, its bottom and its pads, I used the MakerBot software to prepare it. I used the "High" presets, which meant a fair amount of printing time - but exceptionally good quality and precision, as I realized after, for such a cheap machine. Using raft when printing "empty" objects proved extremely important, as without it the freshly extruded material can not get stabilized in the position that it should be extruded . I did not use any support materials as the software indicated that they were not needed - the extrusion speed was slow enough to allow that!

Figure 7. Preparing my model in the MakerBot software.

Figure 8. Watching my model being printed in the Architecture studio's MakerBot. Using raft really helped to get these hollow rectangles in the right shape!

For the electronics part I used the board that I designed and made during week 10. I solved the rainbow cable issue that I had (the two holders did notfit on my milled board next to each other) by using female-to-female jumper cables. One advantage of jumper cables compared to the nake-edged wires of the rainbow cable was that i could make more stable connections with the conductive copper pads by soldering pins to the latter. Despite that I needed only 4 + 4 pins out of the 6 + 6 that I used for the final design of my board, I wanted to have more "free" pins to test my project out of the bricks - that meant more cables (+, -, data, "sides") = more pins!

Figure 9. Collecting my board parts from fab-lbr in EAGLE and making my connections in the schematic mode.

Figure 10. Routing was "tight" in some parts of the board, especially the one around the bottom ISP.

Figure 11. The final design of my board.

Figure 12. Milling the board in the Roland Modela.

Programming the boards to power an output device while interacting with each other meant that I had to combine embedded programming, output devices and networking and communications programming in the code that my boards would run. I programmed my board in C, reading a lot, getting a lot of coding advice, and learning a lot! That was one of the most challenging parts of my project development that I was working for from networking and communications week and I'm glad that it worked now. Here the biggest question that I had from the start of the semester was answered: how can my bricks can identify their positions by querying its neighbors ids, and inform the central computer about it? The code I wrote is the same for all the processors, master and slaves. The ID = 0 condition applies only to the master so every other ID belongs to a slave processor.

This was another part of the project that became possible thanks to a weekly assignment, that done in interface and application programming week. Here is the code that I wrote (again, reading, failing, asking, learning) to make the serial communication between the different processors possible. After initiating the serial communication, the node.js code (attached on the interface and application programming) generates an. svg image of the configurations between the different pins of the processor -and therefore, sides of the bricks-. The user can switch the LEDs through the application. The application operates through an .html page that calls the main.js script and generates the switchable .svg image. (the code for these parts is long and can be found in my networking and communications page)

Video 2. Making and visualizing connections between the boards.

After designing and fabricating the parts of my bricks, making the pcbs and programming them, the "bringing things together" part of the process came about. Everything that I worked for during the previous part would just not work if things were not put together in the right way. This process involved a lot of hands-on training and experimentation - training on handling wires gently and experimentation on finding the right angles for soldering pins to pads, braiding jumpers, sanding 3d printed parts. Some important parts of this process were enjoyable and, at some moments, were painful (the neodmium magnets kept jumping off their sockets and pinching me). The multimeter, throughout this long process, was my only and best friend.