Hi everyone.
My name is Jasper and I am from the University of Washington in Seattle in the United States.
I’m presenting this work on a framework for representing digital fabrication machines
in computer language.
I'm presenting on behalf of my co-authors Khang Lee and Nadya Peek.
This late-breaking work is a part of bigger project that is a work in progress.
So digital fabrication machines have become popular research subjects lately in HCI.
Digital fabrication is an umbrella term for any machine that’s controlled by a computer,
also known as CNC.
One example people might be familiar with is a 3D printer.
A 3D printer takes a digital 3D model, translates the model into machine movements known as
the tool path and then extrudes plastic while following the tool path to get the final plastic
object.
And so digital fabrication technology has been around a since the 1950s in factory settings,
but it has only come to consumer settings in the last two decades.
On the right is an example of face shield holders for healthcare workers that a makerspace
3D printed at the start of the COVID-19 pandemic.
These machines span an incredible breadth of scales and applications that I can’t
complete cover here, but I’ll give two examples.
On the left is an image posted on Twitter of someone using their desktop plotter (which
is a drawing machine) to draw a city street map.
On the right is a 20-foot tall robotic arm with a specialized extruder that is casting
and shaping a concrete pillar.
Given this breadth of machines, it would be great to have one representation that can
be used across different platforms, rather than having each platform design its own representation.
This leads us to our research question: how can we describe a breadth of existing digital
fabrication machines in a programmatic form?
Note that we want to describe, rather than prescribe machine components.
In designing our machine grammar, there’s a trade-off we need to make in terms of the
level of representation.
Ultimately we went with a coarse grain approach because this will help us design a grammar
that’s more portable and extensible later on.
To this end, we came up with an abstraction called a block.
A block represents one functional unit of a machine.
A block has dimensions width, length, and height of a bounding box.
It has a position, which is either explicitly set with x, y, and z coordinates, or is implicitly
set via a connection which I'll talk about later.
And, it also contains attributes which are physical details that matter for machine kinematics,
or calculating how the machine actually moves to do what it needs to do.
To get a sense of how blocks work, here is a side by side of the physical Prusa i3 3D
printer and its representation in blocks represented in a scene.
So, we’ll put an orange box on the left around one important part which is the motor,
and on the right, or—yeah on the right we see the motor represented as a block in yellow.
And, we can do the same for on the left with the blue, this is—showing the crossbar mechanism
which moves the extruder.
This is represented by a block on the right, and of course the extruder itself which deposits
the plastic is represented by a block on the right.
So why bother making everything into neat little cubes?
One reason we—is that we can establish a relatively simple model of how these blocks
move, that actually works for a wide range of machines.
So here we see a block in blue that's powered by the motor in gold.
And what this means is that the blue block can actuate.
So the blue block is a parent that has a connection with the child block in gray.
Whenever the blue block actuates, that means the gray block will start to move.
And we can kind of compound this into what's called a kinematic tree, and this a model
that works for many machines, even with a simple abstraction.
And for more details on this, please read the late-breaking work.
So our next step—our next steps with this initial grammar are: representing higher-
and lower-level machine details, comparing and contrasting machines based on their grammars,
and enforcing best practices when working with machines.
And so I'd briefly like to acknowledge some people.
First, Chandrakana Nandi for feedback on the language design, Blair Subbaraman and Gabrielle
Benabdallah for evaluation and feedback, and the Alfred P. Sloan foundation for gracious
financial support for me to be able to do this work.
And thank you all for listening.