Hello! We are remote students from 5 fab labs distributed between Cuenca, Leon and Madrid, supervised by our instructors Adrián Torres, Nuria Robles and Pablo Nuñez from Fab Lab León.

As we are from different places of the Spanish geography, for this group work we had the intention to meeting together at the Fab Lab León to build the machine. Our situation is not so common so I’ll take a minute to explain it. We are 5 students in León’s node this year. Sergio does the FabAcademy locally in León, but he’s the only one of us physically there. Mickael co-runs FabLab Cuenca, so he is in Cuenca. Lorena, Mauro and Alberto are in Madrid. Lorena works in FabLab IED. Alberto is the coordinator of FabLab UE (Universidad Europea of Madrid). Mauro is currently employed at URJC, where he teaches several design related subjects.

But the COVID-19 situation hit us hard, as one of our crewmates, Mauro Herrero, was seriously ill, staying at the hospital for 12 nights with bilateral pneumonia, needing high rates of oxygen supply for more than a week. He tested coronavirus positive during the CNC machining week and we have not been able to meet physically. Even if, he’s evolving nicely and he’s at home now, his participation in the assignment could not be as active as he would have liked to.

As we have not been able to meet physically, we have devised, designed, programmed and built this machine by remote control between Cuenca, Madrid and León. At the end of the week, the plan was that each lab was going to have its own working machine. Will we be able to pull it off? Welcome on board as we will tell you the story from the beginning...

As is tradition in our Fab Academy lab, we assign a Week song for each assignment. So, for this weeks of hard work, the week´s song begins with Welcome to the Family by Avenged Sevenfold.

A few weeks before this assignment started, all five students held an online meeting to brainstorm about candidate projects for the machine building week. We came up with the following:

Candidate 1: PMMA bending machine

The machine would have aa hot wire along an axis, and a folding mechanism. This could either be linear or semicircular rack & pinion. The controls of the machine would include both the heating time and the folding angle. As pros for this candidate, we found that: it was a simple mechanism, the outcome of the assignment was an useful machine, we could fab most parts, the project has possible future spirals, such as feeding axis, and we think it matches our skills to make it in a week.

Candidate 2: Unfolding structure macnine

The second candidate was a machine or mecanismen that unfolds a morphing structure. This was a very interesting topic, with a great wow factor. We could also fab most of it, and inspiration could be Theo Jansen beach walking creatures. On the other hand, mechanisms are usually complex, we found limited usefulness and we were not sure if we were going to be able to develop it in a week.

Candidate 3: Desktop PCB milling machine

Based on Jens Dyvik Fabricatable Machines, the third candidate was a milling machine for PCBs. We found it very useful in homelabs, there are loads of examples to learn from, and we would build it with as few vitamins as possible. But we found no fun factor in this candidate, and we expected a highly time consuming setup.

Finally, after many meetings, many more ideas, some yelling, and a few wise words from our local instructors, we decided to create an interactive machine, like a game, collaborativei rather than competitive, easy to replicate and easy to set up. We came up with the FabLabyrinth. It is a machine to solve mazes.

Mickael from Fablab Cuenca had already designed and built an analog version of a collaborative maze solving machine, , but could a machine like that be automated to work on its own?

It will have a surface on top, so the labyrinth can be changed, making it modular. It will have servos in the first spiral, and probably step motors in the next, that will move the platform in two axis: roll and pitch. And it will have two controllers and some buttons to perform the different actions the game requires.

We want the machine to have different play modes. In the “auto-solving”, the user will not have control over the machine: instead it will sove the maze itself, following a code and moving the platform until finished. The “collaborative” mode will let you control the machine with the two controllers. Each player will control each of the servos, so with the movements of both of them combined the machine will move in the correct direction for the ball to move through the maze.

We also want the machine to be so easy to replicate that we could have one on each of our FabLabs.

Sergio and Mickael worked on the code. Sergio is the programmer and Mickael, as he had access to his FabLab during Easter week, built the first machine and debug both design and code. Alberto, as the engineer he is, designed the mechanisms, the position of the servos and the interaction of the parts. Lorena worked on the visual part, creating the slide and documentation; she was also responsible for the design of the maze itself. Mauro was focusing on recovering from the bilateral pneumonia that Covid-19 brought him, and, besides connecting to the meetings, was responsible for cleaning up and completing the documentation.

Alberto and Mickael wanted to control the machine with four motors and four cables. That means more fun, since it would be for four players. But then, the machine would have more degrees of freedom than axes, and could potentially unbalance itself. So we had many doubts, and went to check other machines and found this double-framed machines with servos or steppers .

We took the idea and developed it a bit more. Alberto’s task was to design the physical parts of the machine. With feedback from Mickael, two versions of the machine were created. The V1 has the servos directly attached to the frames. The supports on the left and on the right hold the machine in place. One of the supports has the first servo in it, the other one has a shaft. In between this supports we place the first frame. In one of the sides of that first frame we have the second servo, and on the opposite side, a shaft. This first frame holds the second frame. Inside the second frame we can place the labrynths. All the electronics are in breadboards, as there are no controllers. There are four buttons, two for each of the servos.

The machine then evolved as Mickael built his unit and the group continued adding ideas. V2 has a 2:1 gear multiplication so the speed of the maze decreased, allowing more control for the players. Instead of an interchangeable maze design we went for a fully modular one. The frame was also modified and made more sturdy, supports to place the Arduino in were added, and, with a lot of feedback from the group, we designed the controllers. Sergio designed specific boards to be milled, so the electronics were soldered and permanent. “Self solving” and a “manual control” buttons were added.

Alberto wanted to make a 3D printed version of the controllers, with the board on a sandwich panel between an acrylic top, and adding living hinges. Mickael wanted to create a wooden one on MDF. So the machine that lives in Madrid has 3D printed controllers and the one in Cuenca has more simple MDF ones. Both of them work perfectly fine.

Assembling and debugging three identical (or very similar) machines got us so much work! Each machine was doing different weird things. We helped each other and in the end, the machines were able to move under their own power.

The Structure.

The frames.

The Modular Maze.

The joysticks.

Once Mickael received the first draft of the body and maze from Alberto and Lorena, he cut all the parts and assembled them. For the legs and frame, he used wood glue, and 20mm bolts and nuts that acted as the axes. The small plastic part attached to the shaft of the motor needs to be screwed on the small gear. In his case, he glued the big gears, one to the frame and the other to the maze´s side. Mickael then tested it with the controls he had assembled using the code we had written so far with Sergio. Mickael also milled and soldered the board Sergio designed and tested it with the new version of the code.

We started by investigating the use of servo motors with an arduino and mounted on a breadboard the first draft of what could be the controls of the game. x4 buttons + resistors connected to their pins along with the 5v and pins for the motors….

We have also started the code that makes the machine solve the maze alone by simply giving it the instructions step by step. This code is to be put together with the first code we have for the game controls.

Then, we created a shared project in tinkercad to make the development accessible to all. We are now tweaking the code for better response and efficiency, limited the rage of angle and therefore limited the movements, slowed down the pace by increasing the delay time, trying to remove the noise/humming from the motors, customizing the angle range to each motors as the low quality make them imprecise (see in the code)…

First hardware iteration. Mickael started by investigating the use of servo motors with an arduino and mounted on a breadboard the first draft of what could be the controls of the game. x4 buttons + resistors connected to their pins along with the 5v and pins for the motors.

First software iteration. Following this tutorial Mickael tried to implement the code explained in the tutorial but even following step by step he couldn’t make it work (this time, the problem was with the tuto). He also made a project in Tinkercad to make the development and testing easier and more accessible to all.

Second software iteration. M&S started working together through Tinkercad to fix the non working code. There were some problems with the variable names (typos) as the code was written directly from the tutorial and the Arduino IDE was complaining a lot when verifying the code, mostly due to bad initialization, position or syntax of some variables (despite it was the same from the tutorial). M&S used operation logic to understand the order in which the code has to operate to function and finally got a simple code that was functional.

Second hardware iteration. After making it work, Mickael assembled the machine and started tweaking the movement through software (explained below). At the same time Sergio started designing the board for the controllers as we decided to make them independent from the main board and included the buttons and leds for the record and resolve future functions and also one led for each controller to know when it’s operating.

Third software iteration. M&S started tweaking the code for better response and efficiency, limited the range of angle and therefore limited the movements, slowed down the pace by increasing the delay time, trying to remove the noise/humming from the motors, customizing the angle range to each motors as the low quality make them imprecise (M was modifying the parameters and seeing how the machine was responding and S was looking for functions to make it more silent and precise). Later Mickael made the code that makes the machine solve the maze alone by simply giving it the instructions step by step. This code is to be put together with the first code we have for the game controls.

Fourth software iteration. As code was getting complex and components didn’t fit clearly in one board, Sergio decided to redo the tinkercad schematic to separate each board and get a clearer view of each component and it’s function in the code. Sergio also implemented new variables for the resolve function and included it as a new function in the main code. Record will be implemented later as it needs to use arrays and it’s far more complex.

The Fab Labyrinth- The collaborative game for remote makers by Fab Lab León Team