Overview

What if there was a robot that could build LEGO for me, while I could sit back and relax? One that could build anything that I wanted, all at the comfort of a button. Look no further! This semester, I'll be documenting the progress I made and the challenges I faced to get this machine running!

Guiding Questions

[1] What does it do?

This is a 3-axis system that can be utilized to stack LEGO three-stud tall bricks togeher in a linear fashion. Using a set of 4 stepper motors - one for x, one for y, and two for z (stability), the motors can be coordinated using a series of custom ATTINY-DVR breakout boards that are directly integrated into the PCB. This machine can be refurbished as a multifunctional printer with various properties in the futuer, and this machine is built upon those principles using several removable joints, parts, and no glue/epoxy.

[2] Who's done what beforehand?

For the first part, the 3 axis machine. several companies already employ this through a variety of machines - this is the stable of the majority of items that make our world run. The most similar example would be 3D printers, and this similarity allows me to understand how these machines work as I build them. The frame, clank, and the belt system have been designed, but I want to challenge myself by making these files. In addition, the basic linkages of the gripper mechanism were predesigned. I found a metal sheet from a previous machining week class to ease my workload. The second part, the easy to exchange end-effector, is something less companies have focused on, so I made a system that was easily adjustable with screws for now so I maintain tightness while I experiment with magnets later on.

[3] What did you design?

I designed the linear actuators, the idler 3D prints, and the most significant contribution will be the PCB boards. These are custom PCB boards using Zach's new "Baa" chips, and over the course of four weeks I have been able to master them to be able to microstep very effectively.

[4] What materials and components were used? [5] Where did they come from? [6] How much did they cost?

Material	Source	Cost
8' by 1" Aluminum T-Slotted Framing Rails	McMaster-Carr	$33.64
8 M3 x 8mm x 30mm Socket Screws	McMaster-Carr	$2.10
30 M4 x 15mm Socket Screws	McMaster-Carr	$5.20
8 x 2 Hole Inside Corner Bracket Gusset	Amazon, Boeray	$3.99
4 x NEMA 17 17HD48002H-22B Stepper Motors	Amazon	$44.00
Servomotor 130 RPM - 6VDC	Digikey	$5.61
Spool of PLA	MakerBot	$17.99
8" Square Metal Sheet	Amazon	$7.21
4 x DVR 8434 Fabricated Breakout Drivers	Zach Fredin	$4
2 x T8 Brass Nut	Amazon, Akkacm	$1.00
2 x 500mm Tr8X2 Lead Screw	Amazon, Akkacm	$24.99
5mm to 8mm Shaft Coupler	McMaster-Carr	$15
Timing Belt, 5M GT2 2mm Pitch 6mm Wide	Amazon, Eewolf	$11.99
30 Aluminum Profile Connection	McMaster-Carr	$7.00
LEGO Bricks	LEGO inc.	$0.50

Summed up, the raw parts would have costed around $137, which includes savings from making our own DVR breakout PCBs. As a benchmark, good quality 3-axis machines cost upwards of $150 to $1000, with the Prusa printers going upwards of $700.

[6] What parts and systems were made?

Pretty much the entirety of the system was assembled by hand from the frame, to the moving belt system. None of these items were purchased as a kit or fully assembled in this configuration when I received these materials. Apart from the gripper system which came from a laser-cut file that I slightly tweaked for sizes, the rest were designed and tested for tolerances throughout the plan.

[7] What processes were used?

Initially, I collected the alumimum together and sawed the pieces to cut them to the rigth lenght, accounting for the removal of material when cutting. Then, I used a series of corner brackets to manually attach them together using screws and profile connections, instead of using typical items such as glue. Afterwards, I relied heavily on 3D printing to produce the custom joint parts and the idlers needed to maintain stability. I found out that the metal hooks for the stepper motors did not have any stability in the interior, so I ended up printing further pieces to a surprising strength. I spent a lot of time acutally adjusting each of the tensions of the belts and the angles of the threaded rods to ensure that they were perfectly aligned. This was tough because the way the aluminum and motor interact means that to make the slightest adjustments, you had to disassemble the motor which would further reajust the weight and stability.

[8] What questions were answered?

Using the avaiable tools at hand, would it be possible to accurately pick up LEGO at a certain spot with a machine made from scratch, and improve the precision of it up to a similar standard to other machines in the market?

[9] What worked? What didn't?

By the end of the semester, I was able to get the machine working with all three axis, as well as the servo motor. Using pre-generated commands, I instructed the machine to pick up and drop LEGOS, but did it in slow steps since I feared that the stepper motor drivers would fry (and they did eventually). A couple days before the final push, the whole electronics suddenly stopped working overnight, with no reason why. The drivers needed a reverse diode to protect the circuits, and due to the space of the circuits I was unable to fit them in time before I could mill again, so I had to take the risk of burnout. In the future, I'll be creating a version three of these chips to protect them. I also had major problems with keeping the ESP32 connected to the ATTINYs through I2c. I spent the night before working with Rob and Nathan trying to debug it for five hours, when it appeared that loose connections would supposedly interfere. However, this was even more confusing when the I2C scanner that I used showed all 4 devices (instead of 128 streams of random addresses that occured with a loose connection), but could not connect. I would need to use the oscilloscope in the future to debug it more thoroughly, and I was running low on time so I forgoed the fully virtual connection and instead opted for a remote operation, ditching the phone app even though I had all the code (which was a real bummer since I got the MIT app to work well!).

[10] How was it evaluated?

The sucess of it was evaluated on the following. 1.) Can each motor be operated independently and be able to move freely. 2.) Can a network of systems talk back to each other and move the machine in a coordinated manner. 3.) Can the machine sucessfully grasph a LEGO piece, place it on another structure and drop it down. These three were the overrarching questions and were of great interest to me, and I was eventually able to get to all three, even amidst the driver boards shorting several times due to voltage spikes.

[11] What are the implications?

For a 3D printer, the toolchange mechanism has yet to be fully realized. With Prusa as the only major player to do so, there is a lot of room for players to create more efficient systems at a cheaper cost. What is more important however, is the lower amount of waste that is generated with separate 3 axis machines given a specific size. With interchangable end-effectors, it makes it more straightforward to buy addons instead of an entirely new machine, saving time, money, and contributes to environmental causes.

[12] General Requirements for the Project

This project contains both 2D and 3D design. The subtractive fabrication processes mainly involve the laser-cutter for making the box and wooden to house the electronics. There is a lot of additive fabrication, as the 3D printer was used heavily for the custom joints, idlers, and rod mounts. It was also ussed as a temporary coupler for the rails until Nathan got extras for me.

The electronics design was significantly involved as well; without it, the entire project would not have fuctioned. this focuses on the ATTINY board, the DVR 8434 from Zach, and the ESP32 WROOM E. The ESP32 and the ATTINY were connected through I2C for the majority of the time until I started having packet issues with the different devices spontaneously.

The interface and programming is also significant for this machine. With it, you can upload custom software to move the motors in a specific manner, but also create a mini script to make 'fake' G-CODE to run to specific points using custom libraries.

Packing is an area which I focused heavily on after the presentation and clarification from Neil. Initially, I had the majority of the wires out around the machine, which was a tripping hazard but also problematic when transporting it. Utilizing some tape and 3D prints, I was able to cut the majority of the wires into the alumimum frame and keep a minimalistic product that could be seen on the markets today. These machines are different for packaging in which their primary design is to be a machine first, then have a proper form. (see the update for today for a comparison).

Lastly, all of these parts were made from mostly raw materials, such as the aluminum frames, the actual motors, and no pre-bought stepper motor drivers. I wanted to make sure that what I did was based on my own fabrication skills and aligned with the course values, which would make the end product of the machine more satisfying.

Documentation [A] [B] [C] [D] [E]

[A] Design Planning , [B] Materials and Preparation , [C] PCB Design and Electronics , [D] Assembly , [E] Final Tests

November 22 [A]

I finalized my design and plan for the final weeks of the class. Instead of building a clank machine for the same purpose, I'll be building a prusa style device, which will use a belt rack on the bottom y and x axis, with a threaded rod for the z for stability. This way, I do not have to worry about calculating for gravity in regards to the z motion and it will stay steady. The final plan has been updated in Week 0 but attached below. Each stage is planned for a week, so that I can figure out all the different aspects of the project and but them together.

December 3 [B] [D]

Classes ended at Harvard today, so I spent the newfound time assembling the frame of the project based on the CAD model. This frame consisted of aluminum frames that were in the Harvard Shop. I had the following alluminum pieces (4ft, 3ft, 2ft ,1ft, 1.5 ft), but unfortunately my original design consisted of larger pieces, so I redesigned the frame, simplifying it to one square at the bottom and an inverse U junction for holding the threaded rods.

A hand saw was the only option for cutting the aluminum in the Harvard shop, so I ended up sawing all 8 pieces by hand after clamping them and smoothening them with the belt sander for two hours.

This design was stable enough to be picked up, but the top supporting structures needed two more aluminum fasteners.

December 4 [C]

After the networking week, I realized that I could take advantage of the interface using I^2C for separate nodes, or modules of ATTINY 1614s, for the different stepper motors. That way, I can offload the processing for each of the motors to the different stepper drivers, which would have a faster speed than the ESP32 calculating each motor. For now, I wanted to practice one motor and then connect them to a main esp32 board, which will be a feather for now since the orignial board broke (will be remade this weekend).

Today, I spent the evening looking into better solutions for incorporating the stepper motor driver with the motor itself. While there are several options, such as Poloto, A4988s, and a SAMD version that's integrated. I went with Zach Fredin's custom breakout boards with the DVR8436, which is a nice package for the most essential functions. Looking at the DVR 8434 data sheet as well as the way Zach explained it, I was able to make my own similar formulation, and eventually added more funcitonality with the SCL, SDA, and several other breakout pins that can be used to interface with the ATTINYs (in version 2).

This is the first version, and I ended up changing this design after I milled out my first board. I did not end up taking advantage of the M0 and M1 pins, which can be adjusted to change the microstepping of the stepper motors, but also made some mistakes by using the I2C pins directly for the DVR driver.

Notes: to add Zach's libraries to the file, I first opened KiCAD and went into the symbol editor, and then inserted the libraries from Zach's page, alongside the lib file that was included in the directory. This way, I was able to get the proper symbols in the KiCAD folder and use them. This tutorial from Youtube was also helpful and easy to follow: Link

Link to Zach's Gitlab with the DVR 8434/36

From Networking Week (the updated file with the correct traces):

Note a couple of items: The traces are mostly 0.4 cm, but are increased to 0.6 in areas where the ground is underneatt the pins necessary. This is to protect it and prevent peeling, which was a major issue. After I exported and aligned the file for the traces, I was able to mill without a hitch! I made four of these boards, as well as 1 of the first version.
Left: Version A, Right: Version B. This is more stable and less prone to voltage spikes.

Uploading a blink program through my UPDI cable, we can tell that it works!

Using those connector pins, we can quickly plug this into a 12V power supply as well as the stepper motor through the 2 x 4 connector pin. Especially with the power supply, I found out that you can chain them together. As long as the voltage is within an acceptable amount (9V to 16V), the motors are happy and will take any supply of amperage that they need.
Now lets try getting the I2C together. As you can see here, the grounds have to be connected together to provide a reference frame, and I did that through a breakout board. Then I uploaded some code to

[4] Coding

ATTINY Stepper Motor Code (.ino).

To connect both the ESP32 and ATTINY together, I utilized the Wire Library to sync them up on I2C. I gave the receiver an address, and then made it wait for commands (in this case an integer) to trigger the action of future movement.

With a test circuit, we can sucessfully see the motor working as intended. One of the issues I faced initially was motor stalling, which could be either too high or too little resistance. In addition, one time I accidentally made stepper motor music because the pitch of the motors was too higher.

Here's the full connection working! Now that the intial concept has been verified, we can finish the rest of the breakout PCBs and fabricate them. This is major progress for my final project, and I now see the end of the tunnel!

December 5

Today, I finished printing the gripper design, which I modified from here . This worked very well to 3D print, and I completed it and tested the gripping functionality. I added some soft felt pads on the sides to increase the contact area and friction with the bricks.

December 6

Made more 3D prints today, which are the final designs that I'm using. These are fixes to the size differences between the idlers, since I didn't have the correct belt driver that I was looking for. I also spoke with Rob today about what I can do to finish the machine, and the essential parts that I need to do so, and so far I seem to be on track! The machine is study, with all the adjustable screws fine tuned.

It has enough friction to pick up a piece!!!

December 7

I found that each of the motors I've been using are different types, which means that I need to adjust the current differently. Some of them have been bad quality motors, which could be contributing to the struggles wth the power supply.

December 8

Presented the initial design to the HTMAA class. This has all of the parts ready and built for the mechanical portion. The rest is software and coding aspects (which I thought would be easier...)

December 10

Today, I figured out how the Vref worked on the stepper motor drivers, and subsequently adjusted them with a new potentiometer and fixed the orientation. I ended up blowing out a driver giving it too much voltage, but I was able to use the calculated values to get it functional. This was an intense day, especially since I had to check the 17HD48002H-22B Rated current = 1.7A 0.850

December 11/12

These were intense days; my entire systems integration (from the ESP32 to the ATTINY) suddenly stopped working. This was a day of initial worry, but after seven hours of debugging my entire circuit, it mostly came down to two issues: the SCL and SDA pins both have to be pulled to high. The internal resistance inside of the ATTINYs and the ESP32 were different, so it wouldn't read the same value after changing the ground setting. Adjusting this finally gave the solution to the problem, albeit with shaky connections.

The second issue was the fact that the device was reading the addresses but not sending it. This was an issue with the library I was using, as something had changed within my computer when I modified some of the library settings. I redownloaded the Wire library (the TinyWire solution that I tried was not working either), and got it to finally connect. Phew! With the time I lost for this, I ended up deciding not to further push forward with my phone app, even though I had a semi working state for the MIT app inventor using a tutorial, and stick with the web app that I made with interfaces week.

To finish the human element of the design, I added in extra buttons to a separate PCB board. I borrowed Chris Zhu's design for the buttons, and connected all the ground pins together underneath using a mini breadboard to organize the internals. The picture below was before I organized my stepper motor cables on the outside. I used hot glue to secure the wiring and prevent short circuits, which made the design safe overall and friendly. I even drew in more arrows for each of the machines later on as a part of the interface to let people know what to press. The top four buttons control x and y, while the bottom left and right control the z, and the lowest buttom represnts the servo motor on and off state as a boolean.

December 14

For my final updates, I cleaned up the wiring and remade the circuit boards by replacing the DVR 8434 chips. This is to ensure that it has an excellent ssytems integration and is easy to use by the operator. The wiring has been organzied neatly into the aluminum sidings and taped together to ensure that it can be changed in the future while also keeping the full length of the wire inside, so that you can debug later on.

With that, I completed the final project for this class! I'm really excited about how this turned out after spending over a 100 hours throughout the last few weeks. The initial push during machine week was extremely helpful in getting the project going, and I couldn't be more thankful to Joon who helped me design it, and Nathan and Rob for all the debugging! Thank you again!