[MAS.865](../../index.html) > [people](../../people) > Andrew Spielberg
##About me
![Andy](AndyCropped.png)
I'm a PhD student at MIT's Computer Science and Artificial Intelligence Laboratory co-advised by Wojciech Matusik and Daniela Rus, working on the Printable Programmable Machines project. Prior to joining MIT, I earned my M.Eng in Computer Science and my B.S. in Computer Science and Engineering Physics at Cornell University, where I briefly worked with Hod Lipson's group, and then spent two years working as a research engineer in the Asymmetric Operations Department at the Johns Hopkins University Applied Physics Lab (JHU/APL).
I work in the intersection of fabrication and robotics. Previously, that meant designing algorithms for robotic assembly, but these days I am creating tools to enable users to quickly design, program, and easily fabricate their own personal robots using data-driven tools. I am strongly interested in democratizing fabrication, both in form and function, and computational creativity. My work falls in the intersection of computer graphics, machine learning, and robotics.
In summer 2015 I had an awesome internship at Disney Research: Pittsburgh, working on projects in fabrication and interaction, and I had another awesome internship in 2016 at Disney Research: Zürich.
##My System Project
I will be working on a silicone 3D Printer for applications in robotics.
Everything below is subject to change.
###Task 1: Chassis Design and Fabrication
Target date: March 8
Update: March 14
Well, it's a little behind schedule, but here we are. My chassis is completed, shown below. I had never made a 3D printer before, and frankly, I didn't know where to start. I started researching a whole bunch of different possible architectures (I found this breakdown to be very helpful). At the end of the day, I wanted something intuitive to reason about (so, printhead on both the X and Y axis, and the Z axis controlled directly). Delta had a lot of complicated calculations I'd have to work with (I'd written control software back in HtMAA and there are a lot of ways to mess up). The moving bed on Prusas seemed a little needlessly complicated and would require weird sign changes. So, unless I wanted to reinvent the wheel, that meant it was down to either the Darwin or the CoreXY. Well, I heard so many good things about the CoreXY from Neil, so I figured it was worth giving it a shot. I looked around for a good tutorial, and found the Voron. As I go, I'll make changes to the official Voron design for my purposes. This week, I've already started by changing the build volume of my printer.
So far my chassis is 2'x2'x1'. It's built using 20x20 t-slot connectors, which I tapped and connected with cube connectors. Next up: adding the axes!
![chassis1](chassis1.jpg)
![chassis2](chassis2.jpg)
###Task 2: Motor Mount and open-loop control
Target date: March 22
Update: March 21 - We're not quite there yet - still a little behind. I've made a lot of the pieces for my axes, but they're not yet mounted, and electronics aren't there. This will probably get done within the next two weeks. Some in progress images are below.
Update: April 5 - Okay, we're almost done now with the structure, and the control boards are coming soon. So far I've mounted my gantry, and I'm just waiting for new pulleys to come in to mount my belt.
![gantry1](gantry1.jpg)
![gantry2](gantry2.jpg)
I had to recut my shafts to fit the design and epoxy some parts that were supposed to be plastic threaded in, but otherwise, we're in good shape. Once the motors get electronics, it's time for some code.
###Task 3: Closed loop control toolchain perfected
Target Date: April 12
Update: April 23 - A little behind here, as well :). I decided to break the software stack into multiple parts. The top level will take in a multimaterial bitmap, and from that, attempt to create a path over which a toolhead will move. The second level will take that path and convert it to motor steps for a certain kinematic configuration of a printer (Cartesian, CoreXY, etc.). The third level will take those motor steps and convert it to an acceleration profile, and the fourth step will take the acceleration profile and use it to directly control the stepper motors. In other words:
1. Path planning
2. Machine coordinates
3. Acceleration profile
4. Directly control motors.
Steps 3 and 4 are mostly coming from Jake Read's stepper boards, and I might help write the acceleration controller. In the meanwhile, I'm working on path planning. I've coded up a simple path planning algorithm that works like this:
-For each material that needs to be deposited, in order:
1. Represent it as a bitmap (either the material exists in a pixel, or it doesn't.
2. Break the bitmap down into connected regions.
3. For each region:
a) Generate the distance field
b) Break the distance field into level sets
c) Try to follow a "path" as well as possible for each level set in order
The first step orders materials, in case certain materials need to be placed down before others.
The second step emphasizes locality in printing sections
The third step attempts to completely fill a region in a smooth spiraling motion.
The distance field and path following could be replaced by some other algorithm if desired. Either way, filling an entire region reduces to a Hamiltonian path problem, which even for planar graphs (as we have here) is NP-Hard. Currently, I'm simply trying to cover all the nodes with a depth-first search, but this will soon be replaced by an A* search which prioritizes visiting nodes close to the starting point first, as a heuristic.
Between regions, the printer greedily moves to the closest region.
Current example of path planning can be seen below . Darker nodes are visited first. The image input doesn't have perfect boundaries, so the regions aren't detected perfect here. I'm working on better visualization, A* search, handling of multiple materials, and interfacing with Jake's motors in the next week. After that, I plan to close the loop on hardware and software (without the pump).
Original:
![skull_default](DesignToPrintPattern/DesignToPrintPattern/skull.jpg)
Node ordering:
![skull_order](skull_print_order.png)
Update: April 28 - I've added new visualization so that people can see how the path planning behaves in better detail, implemented the Dijkstra's algorithm instead for path planning (makes as much sense as A* here, since we can enumerate the entire graph initially and the weights are obvious), interfaced with the Javascript, and added the multimaterial handling. All of this can be seen below in the gifs. If I wanted to make this path planning better, I might split each region further up into its own convex regions. This is functionality that I may add at a later date if I have time.
![testgif1](DesignToPrintPattern/DesignToPrintPattern/test.png.gif)
![testgif2](DesignToPrintPattern/DesignToPrintPattern/test2.png.gif)
![testgif3](DesignToPrintPattern/DesignToPrintPattern/skull.jpg.gif)
![testgif3](DesignToPrintPattern/DesignToPrintPattern/colors.png.gif)
![testgif3](DesignToPrintPattern/DesignToPrintPattern/yoshi_cleaned.png.gif)
Update: May 2 - Something I forgot to talk about a while ago was that I ordered material to play with (for a different research project on injection molding), and recently decided to try it out on this printer. It's not the material I'd like to use, but I cured a few samples. This only works if all the things I want to print are to have the consistency of boogers...it's too tacky and way too damped compared to what I wanted.
Update: May 9 - Based off Jake's mods code for stepper motor, I now have a complete pipeline from image --> motor commands. I also bought a UV Lamp and am working on mounting it.
Next up: Building an outer box, mounting the pump, mounting the UV Light, testing the stepper motors, and attaching the belt.
Update: May 16 - The last week has been filled with the following tasks:
1. Building mounts for holding the UV lamp in place. In theory, my system will be able to hold 4 UV lamps. This is good because the ones I'm using off the shelf right now are very weak and slow, taking 20-30 minutes to cure. This is obviously less than optimal, but better UV lamps are more expensive and I'm not ready to make that purchase until the rest of the machine works. For now, this can at least suffice for the WIP.
The brackets can be seen below. The widest section slides into the UV lamp itself, and then can be screwed into the gantry. The UV lamp slides in, meaning it's not constrained along that axis, so two holers are similarly screwed in on either side of the lamp to stop it from sliding back and forth. The resulting mount configuraiton is thus fully kinematically constrained.
Bracket:
![bracketimg](bracketimg.png)
Holder:
![holderimg](holderimg.png)
2. Creating a holder for the syringe. This was 3D printed and added to the current end-effector holder. It is a three-part snap fit (seen below), with snaps on the top and bottom, designed such that the "petals" of the syringe are forced into an orientation as a constraint, a screw hole for extra security, and with room for the syringe material/air tube to extend outward to an electronic pump. Tape was to be added to the syringe to prevent UV exposure and to keep it more snug in the holster, but I removed it in this case to make assembly and disassembly easier. I'll try to add a picture with the tape if I get a chance.
As I was assembling this, one of the snap connectors on the assembly broke (you can see it on the side in one of the pics). Further, the screw hole, as per usual, doesn't have threads, so it's being secured with a peg and glue. A v2 of this would be ideal fixing these minor issues, but otherwise this came out pretty nice.
Top:
![topimg](topimg.png)
Bottom:
![bottomimg](bottomimg.png)
![gang](gang.jpg)
![gang2](gang2.jpg)
![tragedy](tragedy.jpg)
(tragedy)
![assembled1](assembled1.jpg)
![assembled2](assembled2.jpg)
3. Tested the stepper motors. Alexandre and I worked tonight on trying to get Jake's stepper motor boards working. We were able to power them, maintain a hold torque, and make the motors take one step. However, we are currently unable to get consistent motion. This is the current focus. Two videos below, which was the best we got. The first just shows motion, which happens when the reset button is held down - but not actual control. The second video is just me making a joke - we didn't actually send a packet here, we're still holding the reset button :P
Next up: Creating the box, debugging the stepper motors, hooking everything up.
Update: May 18, 2018
Crunch time :). I've made the .svg for laser cutting a box. This is a pressfit construction kit, just like the type we'd build in HTMAA (ah, memories). It's parametric in height and width, and provides a number of slots in case I want to attach pieces at intermediate heights. I generated it with a python file here, included in the repo. The resulting design, which I'll laser cut tomorrow, is below:
I will fabricate each side, glue it together, and then line the interior with foil to reflect as much UV light inside as possible.
Update: May 21, 2018
Oh wow, we're getting down to the wire now! But a lot has happened.
The box has been fabricated. In the end, the pressfit didn't exactly pan out as a) I didn't have time to get the tolerances just right, b) my laser bed wasn't big enough to put the tab slots in the interior(just barely), and c) I screwed up by using acrylic that just wans't as thick as it should have been. All in all, this box is pretty shoddy, but it does the job in enclosing the UV light. The interior was lined with foil to try to reflect the light on the sample and reduce absorption by the box, though I don't know how well this will work (this is also why white acrylic was chosen, and I have to be honest, that might be more reflective than the foil I got).
![box1](box1.jpg)
![box2](box2.jpg)
![box3](box3.jpg)
![box4](box4.jpg)
![box5](box5.jpg)
As for the UV lamp itself, the clamps had to be resized to fit the screws (which were larger than I thought). But, as I was working on this the night before the project was due, I accidentally broke my mount as I was widening a hole...I'll see if I have time to print another one, but otherwise...zip ties it is...
![ohno](ohno.jpg)
This weekend I was traveling, but I was able to write a quick script to convert my output motion planning files to gcode, as can be seen here here. I wired up the tinyg board today, and tested my gcode, which worked on the first try. This was my first time working with the tinyg (or directly with gcode), and I got this all up and working in ~5 hours, which felt pretty empowering. A video of my motors following the commands here is below (a better file is available upon request), and the file it's running is here. After I tested this, I changed the python file to convert the output to CoreXY, kinematics, which really just leads to the axes being A = x + y, B = x - y, modulo some (uniform) scaling (there's supposed to be a /2 but that can get absorbed into the pixel to step size conversion).
Finally, I tested the extrusion out of the syringe pump a few days ago (which will be covered in black electric tape to prevent the silicone from being cured inside the syringe). This works using an electric pump and control box that can be triggered with a 5V TTL signal. I;ve found through experimentation that 0.5 psi gives a nice and consistent, but low volume extrusion of material. A video of this test can be seen below. I probably won't be able to bring this to the final presentation though, because the setup is too big :(
Electronic pump is the one seen here (with tube and syringe and material inside):
![electronicpump](electronicpump.jpg)
With electronics, box, and mounting out of the way, all that's left is to reassemble my printer and do a final test...with 12 hours to go ;).
Update: May 22, 2018
Some results for y'all :). The final printer, in its case, with the UV lights shining bright:
![finalinbox](finalinbox.jpg)
And some videos. First, showing the motion of the gantry without motors:
Second, showing simple tests of the axes in corexy coordinates.
Third, showing the printing part of of colors.png (that colored square example) using the whole pipeline.
My only complaint at this time is that the belt seems to slip quite a bit, but we're out of time. That's future work :)
###Task 4: Four nozzles designed, mounted, demonstrated
Target Date: April 26
Officially cancelled as too ambitious :)
###Task 5: Computational Design of structures
Target Date: May 17
Officially cancelled as too ambitious :)
###Task 6:
Final Presentation
##Individual projects
### Mods Axes
March 9: I am working with some others to add a Mods module for automating the specification and fabrication of axes for 3D printing. Currently I've written a three.js viewer here, though it's not up and running on the webpage since I'm not yet sure how we're hosting three.js as a library. Currently, it just takes in a few options (height, weidth, depth, axis type) and renders a corresponding cuboid. This will become more sophisticated as we integrate it with other pieces and Mods itself.
April 5: Update - that project seems to be going well without me for now :). I'll re-evaluate how I can help more later.
### Motion Planning on Mods
Cancelled as I'm having enough trouble getting the board working :)
### AR Mods
Postponed as a summer plan.
### Temperature Controller
I helped Filippos get started by providing an example of how to use OpenCV inside a Nelder-Mead algorithm here, with an explanation of where motor parameters would be changed. I provided a dummy example program, and a more sophisticated graphcut algorithm (that only works on small images). I also provided an example here of how to use javascript with python through websockets. Although I think these implementations were scrapped in favor of a pure-javascript implementation, I'm hoping at least the way of structuring the code for Nelder-Mead + I/O was helpful.