Machine Design
This week was terribly exciting. Machine design feels quite meta for this class since we're learning how to use machines and other fabrication tools to make almost anything. This week we're learning about how the machines we've already been using are actually designed. This is a terribly small version of the other CBA class How to Make Something that Makes (almost) Anything.
Since the machine design projects were completed by entire sections within the class, the full writeup of the EECS section's design, manufacturing, and programming processes exists here.
Creating Paths Out Of SVGs
My main objective for this week was doing work on the programming and controls team. This team was responsible for programming the TinyG board and coming up with a terminal interface that would take SVG inputs and be able to control the motors to move them in the necessary way to draw out that SVG.
More specifically, I was responsible to translate an input SVG into a toolpath in 3D cartesian space. This was all done in Python, and using the library svgpathtools made a lot of this not terribly difficult. Using the library, I was able to grab all the paths within the svg, and for each of those paths, I interpolated between all of the control points to create a fairly small delta vector. These positions were added to a list and were eventally scaled to fit the size of our machining area. To bring in the 3D aspect from the 2D SVG, there were essentially two separate layers: the "plotting" layer and the "traversal" layer. For all the points on an SVG curve, the Z coordinate was at the plotting layer, and when moving between curves and beginning and finishing the job the machine would move at the traversal layer.
Understanding the Software Architecture
So my SVG to toolpath part was one of several important steps in the software flow to control the machine. Overall, we had one main file that took in a variety of paramaters including the port the TinyG was connected to, the SVG that was meant to be plot (or cutted), the feedrate, and the machining area. This control file then used my code to get the path in rectangular coordinates, and then another function converted the rectangular coordinates to delta coordinates. Delta coordinates were basically the amount by which the stepper motors had to be below their highest point (Z=0). Finally, the delta coordinate toolpath was then translated into GCode with fairly simple linear moving GCode commands, and sent via serial to the TinyG.
Testing the software
Even though the whole machine hadn't been built, Ben Yuan had a great idea of testing our code with 3 stepper motors that weren't attached to the machine. This way, we saw that the code to upload Gcode to the TinyG worked properlly, and we could see the motors moving. We could generally test that the motors would move how we expected, but it was hard to test if the delta geometry was correct because intuiting how much the steppers should move was pretty difficult. So we waited to get the steppers attached to the machine before we did that.
Helping Build The Machine
Since the programming didn't take a terrible amount of time and the programming team couldn't really debug much more without the machine working, I decided to help out with the build of the machine as the parts were being fabricated.
The first thing I noticed when talking to some of the designers of the machine was that the machine plate (upon which the arms would be put) was way too small. It was only marginally larger than the size of the end effector plate, and from my research to understand the delta geometry we were doing, it's necessary that the vertical arms were placed much farther away from the end effector, otherwise the space we could cover would be extremely small. So after notifying the design team about this, a new machine plate was desinged.
Other than making some comments on the design, I basically was an extra hand for anyone who needed it, whether it was smoothing out the delrin arms, taking pictures, helping put the machine together, or drilling holes in acrylic, I was basiaclly running around everywhere.
Final Testing
After the machine got completely built (this was late Tuesday night / Early Wednesday morning), Ben and I came in with the TinyG to test out our code. There were a couple issues we faced (both mechanical and software):
- Keeping the motor torque engaged after moving one of the steppers. Since our machine is designed with the steppers moving up and down arms, the stepper motor has to be programmed to stay engaged after moving to resist the force of gravity. This wasn't something we considered during our first round of debugging, but was critical once the machine was built. Otherwise the motors and end effector would crash into the ground. While there was a way to do this when the power was on, there wasn't a way to keep the steppers engaged when the power supply was disconnected, which caused issues when we went to move the machine
- Because of the downward force of gravity on the motors and the imprecision of the rack and pinion mechanism, some stepper motors would skip a tooth and fall more than expected. This was somewhat inevitable
- One of the pinions on one of the arms was slipping relative to the stepper motor's shaft. This was a problem because eventually there was to little friction that the stepper motor couldn't keep itself from moving downward along the arm. One fix to this would have been to shape the inner shaft of the pinon differently. I noticed the pinion's inner shafts were cylindical, where the stepper motor's shaft has a notch in it. If we had made the inside of the pinions to match that notch (which I believe is used to prevent the exact problem we had), then I think we would have had more luck.
Reflection
Overall, it was dissapointing to see the machine not work correctly. However, it was an incredibly exhilerating week because I truly was able to see the process of one of these machines go from sketch to (almost) finish. While I certainly didn't do everything, I think the time I took not programming to help build the final machine gave me an idea of how every part of the machine fit together and was supposed to work in theory. This way, even though I didn't do the CAD design or machining myself, I am still able to walk away with an appretiate for the system integration necessary for a project like this to be successful.
Terminology
Motion system, end effector, motor controller, stepper motor, power supply, rack and pinon
Technologies Used
Shopbot, Laser Cutter, Fusion 360, Onshape, Power Supply, TinyG, Python, and much more
Resources Used