This week we spent time incorporating the written and verbal feedback we received from the design presentation into our design report. First, we reread the papers we found in order to get a better understanding of past designs. We refined our design further, and our report contains specific details on our system. In particular, we talk about the required math and gave more descriptive justifications for our design choices.
Joshua’s Status Update for Week of 2/23
What I did:
I presented the Design Review. I also re-read Vision based error detection for 3D printing processes by Felix Baumann and Dieter Roller to understand fully the details of their algorithm. By reading Initial Work on the Characterization of Additive Manufacturing (3D Printing) Using Software Image Analysis by Jeremy Straub, I was able to get more of a run-through of other ways to model the printed object.
Team Status Update for Week of 2/16
Towards the end of this week, we had a conversation with Prof. Rowe about our capstone design, and he brought up some good points on how to better reach our objective. We ultimately decided to switch our design so that the hardware’s purpose is to support the detection algorithm; previously, we were needlessly focusing on the exercise of creating a single board computer without considering other design avenues.
Our new design will include modifying OctoPrint and running our algorithm on a RaspberryPi. Our hardware component will be to construct an RPI shield. However, we will be gathering data from 2 cameras and 2 lasers in order to build a better model of the current print and to provide better cross-checking. Our system will also, over its lifetime, build up a model of the distribution of actual print-errors and inherent errors built into the system (i.e. due to laser and camera calibrations) and assign weights, contributing to the total error that is used to determine whether a particular print is erroneous. Then, the user will be notified and asked if the print should be stopped.
Here’s an updated block diagram:
Because of the design change, we also needed to update our Gantt chart:
Joshua’s Status Update for Week of 2/16
What I Did:
Because of our design change late in the week, a lot of the details I did during the week became irrelevant. I was able to implement the optimal camera placement algorithm as mentioned in the previous post, but since we are now using lasers alongside the built-in Ultimaker3 camera, it’s not pertinent anymore. I also began a trade study for an SD card reader that did not lead anywhere because of the design change.
I created a GitHub repo so that code sharing and versioning control could be made easier, but right now it just contains the optimization code.
I made the system block diagram that is seen on our Team Status Update.
I also designed a first-pass power regulation and protection circuit for the RPI Shield (special thanks to 18220, and my eyes for reading the RPI3B+ datasheet and HAT specs). We need protection because new version of the RPI have removed the fuses on the GPIO pins.
Am I Behind?:
I would say that I am behind because the team in general is behind. Because we changed our design late into the Design Phase, we have had to quickly re-refine our requirements, redo our trade studies, and quickly communicate our understand to each other, and I don’t know if we have efficiently done that. However, I believe that once the Design Review is finished, we will be on track to put in our part orders.
Goals for the Upcoming Week:
I get to head up the Design Presentation! Also, I need to order parts required by the RPI Shield. I also need to start laying out the Shield schematic, as well as writing the code that parses the g-code.
Team Status Update for Week of 2/9
We visited TechSpark and talked with Ryan again. He gave us permission to use a Dremel printer for development within TechSpark, but said we would have to use the Ultimaker3 during demo day. He suggested we could create an armature that holds the camera to the calibration screws. He also made note that the Ultimaker3 is a dual extrusion printer, but they only use one extruder; we could put the camera in that second extruder chamber.
We’ve also started to go further into our different trade studies for the different pieces of equipment we will be buying (such as image sensor, camera lens, CPU/MPU/MCU). Also, we refined our testing plan and plan to demo the project. We also narrowed down the actions the user can perform and the types of notifications sent to the user.
Joshua’s Status Update for Week of 2/9
I started the design review slides. In order to determine optimal camera positions, I read Two-Phase Algorithm for Optimal Camera Placement and began implementing its algorithm in Python. There is sort of a steep learning curve, since I haven’t had real experience with optimization techniques. I started off using the cvxpy Python framwork, but got stuck when I realised it could not generate binary integer variables of more than 2 dimensions without clever tricks. I am shifting to using the Python API for IBM’s CPLEX solver (available to me through CMU). By using the process described in the paper and experimenting, we should have a camera arrangement that covers a majority of the print bed. In addition, I started on the block diagram/circuit for the power system and finalized the choice in RF module for the WIFI chip.
Joshua’s Status Update for Week of 2/2
I completed a trade study of various wifi chips. At first I thought we could use the ESP8266EX chip, but after looking further into developing with it, I believe we should move towards using a complete RF module based on the ESP8266EX. I also began a trade study for microprocessors. In addition, I researched and created a list of 24+ types of 3D printing errors, and in preparation for the proposal presentation, narrowed the list down to 4 error classes our device would detect.