The interweb has been my friend when it comes to researching 3d image libraries.  It is also my sole source for learning to use python, so what I’m about to share can be found if one has a bit of free time to go poking around and do some searching.  However, I wanted to bring this to everyone’s attention.  There is a 3D graphics library for python called Pyvy.  Pivy is a python binding of the Coin toolkit and makes the development of 3D objects in Python a rapid process.  It can even be used from within the python interpreter immediate mode window so you can get immediate feedback, from what I’ve read.  This seems relevant to our project for obvious reasons, but I wonder if this functionality overlaps with blender, to the point that we may not need such a library?  Any thoughts?  There is a useful article with code examples on how to use some of Pivy’s basic features that can be found here, and The project site can be found here.  I took a quick glance at the license for this library and it appears to be freely available for distribution, if we choose to implement it in our software.  The source code is also available.

Stephanie and I have started examining the beginning steps in building the software for this project. We decided that it would be useful to first noise reduce an image before beginning to transform it. This will hopefully rid the image of randomly placed and unwanted pixels and allow the edges of shapes to become more defined. A noise reduction method that we discovered is median filtering. This involves going through the pixels in an image and, for each one, examining the surrounding pixels, or “neighborhood.” Typically, the neighborhood consists of all the pixels adjacent to the selected pixel. This method then determines the values of these pixels. The value could be the numerical value representing a pixel in grey scale, for instance. We then find the median value of these pixels and use it as the new value for the original pixel.

Once the image has passed noise reduction, we can then begin the process of edge detection. In keeping with an iterative development process, we decided it would be easier to only be concerned with grey scale images first. This way, we can examine each pixel’s grey scale value and turn it either black or white. Then, we can then easily distinguish between black and white and decipher where the edges are. As the images we work with become more complicated, so will our technique. For now, we believe this is a first good step.

In further discussions, we hope to improve our edge detection method, examine how to transform the shapes that we find into 3D, and begin to actually implement some of our ideas.

We have a functioning printer! More details in the next few days…

I’ve been racing to get my printer done before spring break starts (now) and I leave for a conference next week (Tuesday). The X and Y decks are in, the power is in, the boards are mounted, and endstops are mounted, the Z deck is in… but… I managed to destroy two of the three ribbon cables used to connect the motherboard to the stepper boards. Not sure how I’m going to replace them as they are no for sale on Makerbot.com. Looks like it’s time to email Bre.

Additionally, while building the plastruder, the insulation tape ripped and I am very unhappy about how loose it ended up being around the print heater. I am likely to order a supply of new items, like the insulation tape, to eventually replace it (summer)?

I’m angry at the build directions, as I can not find how the endstops should be connected, how the wires should go, and if I need to wait to do this. If one follows the directions to a “T”, you would not connect them. Finally, I completely don’t understand the popsicle stick and endstop directions. Can someone post a good close of series of photos of how yours looks? I’m not clear on where I’m gluing the sticks, size of the sticks, where they are placed, etc. The directions are far, far too vague.

We started some private discussion about what the user interface of the software portion should look like, how it should function, where the software should be stored (on a server or locally) and other logistical things.  One of the objectives is to make the software as portable as possible across as many platforms as possible.  This goal would probably be most easily achieved through a server-side software configuration that can be accessed via a web browser.  This would also make our challenges with accessibility a bit easier as well, since any modern screen reader will be able to handle a web interface right out of the box.  After all, the web is the future, right?  Of course, this does have some security issues we have to keep in mind.  For example, who will have access to this service, especially when it’s in its initial stages, and how can we control user access?  The first idea that comes to my mind is that we could put this service behind a firewall of some kind, and allow only certain people access through the firewall.  On the other hand, let’s say we go with the approach of storing the software locally.  We may have some accessibility issues to address.  Most screen readers communicate directly with operating system controls to provide the feedback that they do.  I reported a while back on this blog about my findings with virtual box, something I didn’t have much success with on a count of it using QT.  QT is useful because it makes it easy to make software more portable, but many screen readers will have trouble with it without some kind of modification, as they do not use standard operating system controls.  These are some of the design issues we are considering, and obviously there are tradeoffs either way.

I don’t recall us having any trouble with the bearings falling out of the pulley wheel. Actually, we had the opposite problem, and had a hard time getting them in because they were so tight. As for a solution, you could glue down the bearing, although, keep in mind that the bearing/pulley assembly will be bolted down.