Team E1: 3D Printing Error Detection System
Created by Joshua Bas, Hannah Preston, and Lucas Moiseyev for Carnegie Mellon ECE Capstone, Spring 2020
This week the team created the slides and the final Gantt chart of team accomplishments.
We’ve had some major setbacks (see Lucas’ post) and are working to find solutions to these challenges.
Well, I had been continuing development for the Octoprint plugin. This plugin captures a picture on each Z-axis increment, and is supposed to process the images and the pre-computed model that Hannah’s code generated. However, apparently Lucas’ computer and 3D printer are broken, and since he never sent real images using our camera (and corresponding intrinsic/extrinsic matrices), I couldn’t do full tests of the system with known camera parameters. So this past week I’ve been trying to figure out how to, with only 1 image and 1 point cloud, estimate 3D-2D point correspondences without knowing the world-to-camera matrix — since we didn’t have access to a 3D printer, I thought the easiest way to test the whole system was to stream in a timelapse of a 3D print (many can be found on YouTube, and usually include a link to the STL file or gcode being used). It’s easier said than done, because as the number of point cloud points increase, many of the algorithms I looked at performed in the order of magnitude of an hour (which is not useful for our project nor is it feasible debugging-wise).
This week I optimized the edge error code. Originally, I was using Edward Cui’s code for the modified Hausdorff, but after slow computation times, I reimplemented the algorithm myself, which was a lot simpler than I had previously thought. Cui’s implementation imported numpy.core.umath_tests, which apparently is deprecated and runs rather slowly. Instead I call the scipy.spatial_distance.directed_hausdorff function, and use the max of the forward and reverse directed hausdorff distances as my distance metric. This is described in Comparing Images Using the Hausdorff Distance by Huttenlocher.
I didn’t really do much for Capstone this week due to other exams and labs, but I am planning on continuing refining the edge/blob code I wrote last week, as well as furthering the Octoprint plugin code I had previously started on.
This week, we mostly didn’t work together apart from our Monday meetings in preparation of the demo. We worked on our subsystems and will be presenting what we have.
This week I was able to accomplish my tasks of creating an edge/blob function . I also completed a function that determined whether an error has occurred, based on the edge/blob results and a reference image. I will be demonstrating these functions using several images of small 3D printed parts.
This week, I had more discussions with Hannah and Lucas. I think we’re getting back on track. We had to reassign some tasks because each of us now have restrictions on the resources we have access to. So since Hannah has done all the research on the gcode, and since I offered to do the blob code. I started working on the blob comparison code as well as blob detection code. Nothing is really working, so I’m glad the demo got pushed back a week. This week I will finish the blob stuff and integrate that with the core plugin.
We re-did our Gantt Chart, trimming out the unnecessary tasks due to our rescoping of the project and reassigning some tasks to better accommodate those who currently do not have access to on-campus resources. This week we will be focusing on the gcode visualizer and finishing the blob detection.
The biggest risk factor is our hardware limiting the soft- ware implementation we have chosen. We are manipulating very large data sets and performing multiple searches during each error check. Since our design can be checked just by streaming in a prerecorded video of a print job, we don’t necessarily need an RPi to prove our system works. So in the worst case, we can just run our plugin on a laptop.
Another risk factor is the system having a higher false positive rate than expected. Although a high false positive rate is preferable to a high false negative rate, we want to also have a low false positive rate. If we come across this issue, we can tune the various similarity metrics we used in order to mitigate this risk. This is unchanged from the design report.
A minor risk is that the fixture we construct to hold our sensors and devices is too heavy to meet specifications. Lucas has designed the armature already and is able to print it at home, so he’ll be in direct control of the weight of the fixture.
We only have access to a single functioning printer…that has already broken down once. If the printer were put out of commision again, we would lose not only our only test platform as well as our only avenue of printing mounts and other mechanical hardware.
Because of the COVID-19 predicament, as a team we didn’t do much in terms of work, but we did meet with each other and the course faculty and TAs over Zoom to discuss our project. The results of the discussion are outlines in our Statement of Work.
This upcoming week we will work on the error detection functions, the core system, and fixing up the broken Printrbot and the associated software components.
Considering the circumstances with COVID-19, I didn’t do as much this week as in previous weeks. However, during Spring Break, I did begin implementation of the main system plugin. This included a half-runnable/half-pseudcode Python implementation of the RPi camera IO access, creating the prototype for a basic Octoprint plugin with the appropriate handers to access the gcode, and messing around with the possibility of multithreaded. I also attempted to begin the point cloud code. This can all be found in the team’s Github repo. I also wrote the statement of work.
This upcoming week I need to refocus on the main system code and provide solid system error messages and give better access to the necessary IO and handlers.