[Jesse Burstyn] and some colleagues at Queen’s University and Carleton University (both in Canada) are delivering a paper at the INTERACT 2015 about PrintPut, their system for printing sensors directly into 3D printed objects. Using a printer with dual extrusion and conductive ABS filament, they have successfully formed capacitive touch sensors, digital resistive sensors, and analog resistive sensors.
In practice, this means they can print buttons, sliders, and even touch pads directly into objects. They also have a design for several pressure sensors and a flex sensor. The system includes scripts for the Rhinoceros 3D CAD package. Designers can create a model in any CAD package they want (including Rhinoceros) and then use these scripts to define the interactive areas.
Sure, you could stuff traditional sensors into the object, but it is difficult to, for example, match contours in the object. It also means increased manual finishing time after the object prints. We’ve covered a similar process using carbomorph. Of course, you could always just print with copper wire, instead. You can see some actual prints made with the PrintPut process in the video below.
Very nice! Can see many uses for these, especially for controlling music related kit. That robot in the video is a little creepy though.
I see really awesome articles and papers coming out of universities regularly. Some of their ideas would be easily implementable, had they also provide their workflow and/or sourcecode on how they got to where they are. As of now, I’ll see some uni project, and know it’s cool, but disregard it unless I want to start from the ground-up and do what they did.
I somewhat disagree. One of the requirements to get a paper published is that your method be well described. I’ve sat through heated arguments at conferences where a presenter was grilled about details of their work that they didn’t want to reveal due to intellectual property-right concerns. Most scientists want the details and get unruly when those details aren’t revealed.
With this particular article, I’m not seeing the problem you describe. Having clicked on to the paper the article is about, the authors’ method is fairly well described. The only part that isn’t described in detail is the software (Rhino 3D scripts) that they used as a convenience to users. It would be nice if that software was open source and sitting somewhere accessible (ie. Github).
But the paper is really about how one can use a dual-extruder 3D printer and commercially available conductive filaments to make seven types of sensors, most of which haven’t been described in the literature as of yet. The details are well enough described that anyone could reproduce their work.
I am one of the authors of this paper, and I completely agree with you.
There is a big communication problem between academe and makers & tinkerers. Yes, as Rural says below, papers should describe the method etc, but in practice there usually are so many implicit assumptions and tacit know-how involved that reproduction is a problem.
Part of the problem is that when publishing an academic paper we are constraint to a format which is geared towards situating your work (explaining how it relates to other work, explaining what its implications are) rather than teaching others how to do it.
I am aware of this issue and hope to address it at some point (maybe in the form of publishing instructables in parallel?). If you take the time to check out more HCI papers however, you will find that some people do actually put a lot of effort into making their work reproducible, which includes sharing of raw data and source code.
*
If you’re interested you can watch a video of me presenting this work: https://www.youtube.com/watch?v=0h75_dw87ek
And if I find the time I’ll see if I can set up an instructables for it.
Please don’t let my grousing about the academic paper publishing diminish your work here! I’ve already been trying to chew on exactly how to generate the GCode paths required to make your sensors, as a drag-n-drop sensor library would be awesome!
Although, I am curious as why you chose to use Rhino. The open source toolchains I thought were good if not better for testing like this… but I could be wrong?
There was no specific reason for choosing Rhino – we were curious to play with the Grasshopper plugin. However, we only used it to design the 3D objects (including sensors and pathing). The GCode was generated separately afterwards, possibly using the default software provided by MakerBot.
If you’re serious about re-implementing this, lets continue the discussion via e-mail: paul dot strohmeier at gmail …
Start testing the conductive spots for human caused degradation on the conductive properties of said spots. Then test for environmental effects, sun etc. This seems to be worse than any of that conductive stuff in all of those keyboards and control pads that fail and require harder and harder presses. Those are (sealed) and out of touch and sun.