When you work on a project, you don't have to or shouldn't have to
reinvent the wheel. Someone else has probably spent a lot of time
figuring out some little piece of the puzzle that you need to complete
(or start on) your hardware or lab project. These puzzle pieces are
spread out over the internet so far and wide that it's hard to work
with. But the software folks solved this type of problem by something
called dependency resolution. The way dependency resolution works is
as follows: some software requires (depends on) other software that
must be installed first, and so a program looks at this socially
currated metadata and makes a decision like whether or not something
else has to be installed first.. and it's exactly the same with
manufacturing and building things. In order to build a lathe you need
to cast metal, and in order to cast metal you'll need to make fire,
before you can make fire you will need to find flint or sticks or
maybe matches, and so on.
In the software world, the most phenomenally amazing example of this
is the (free) Debian project [1]. Debian is a distribution or
collection of software involving three main ingredients: (1) GNU tools
[2], (2) the Linux kernel [3] to interface to the hardware, and (3)
debian packages. There is a software system that they give you that
looks at what software you currently have installed, and then
determines which other software has to be installed when you want to
install something completely random out of their collection. I have
trouble conveying how important or how huge debian is to people, but
Wikipedia has helped me a few times: "The cost of developing all the
packages included in Debian 4.0 etch (283 million lines of code),
using the COCOMO model, has been estimated to be close to $13 billion
USD. As of April 2, 2009, Ohloh estimates that the codebase of the
Debian GNU/Linux project (45 million lines of code), using the COCOMO
model, would cost about $819 million USD to develop." [4] There was a
really wonderful overview of this written once too, trying to explain
how much of an impact debian has on the internet:
"Debian is the largest independent of the longest-running of the Free
Software Distributions in existence. There are over 1000 maintainers;
nearly 20,000 packages. There are over 40 "Primary" Mirrors, and
something like one hundred secondary mirrors (listed here - I'm
stunned and shocked at the numbers!). 14 architectures are supported -
13 Linux ports and one GNU/Hurd port but only for i386 (aww bless
iiit). A complete copy of the mirrors and their architectures,
including source code, is over 160 gigabytes."
"At the last major upgrade of Debian/Stable, all the routers at the
major International fibreoptic backbone sites across the world
redlined for a week."
"... To say that Debian is "big" is an understatement of the first order." [5]
.. and it goes on and on. For some reason, though, nobody knows about
it. I suspect that this is because you have to be a super geek to even
know about debian, and a doubly super geek to even use it and know how
it works. It truly simplifies my life on my computer, and I am amazed
when I see how others install software. And when I sit and think about
it, that's exactly how it is with hardware projects!
[1] http://debian.org/
[2] http://gnu.org/
[3] http://kernel.org/
[4] http://en.wikipedia.org/wiki/Debian
[5] http://www.advogato.org/article/972.html
So I've been leveraging my knowledge of software to do this dependency
resolution method with manufacturing and the art of building things.
The goal here is to literally be able to download hardware over the
web. I want to tell my computer that I want an F16, and I want an F16
to be assembled and made to appear before my eyes. This is what the
SKDB project [1] is about. SKDB stands for "Social
Engineering-Knowledge Database". I will immediately admit that I am
absolutely terrible at naming things. My main cohort on this project
has been Ben Lipkowitz [2]. Apparently we met in 2006 and neither of
us realized it (on the internet), and then in early 2008 we met up
again after I read Kevin Kelly's blog [3] and decided to search for a
deceased man named David Gingery because of what KK wrote:
"Recently a guy re-invented the fabric of industrial society in his
garage. The late Dave Gingery was a midnight machinist in Springfield,
Missouri who enjoyed the challenge of making something from nothing,
or perhaps it is more accurate to say, making very much by leveraging
the power of very little. Over years of tinkering, Gingery was able to
bootstrap a full-bore machine shop from alley scraps. He made rough
tools that made better tools, which then made tools good enough to
make real stuff."
Kevin Kelly also wrote some other thoughtful pieces on civilization,
as if it was an organism or creature or monster:
"I've been thinking of civilization (the technium) as a life form, as
a self-replicating structure. I began to wonder what is the smallest
seed into which you could reduce the "genes" of civilization, and have
it unfold again, sufficient that it could also make another seed
again. That is, what is the smallest seed of the technium that is
viable? It must be a seed able to grow to reproduction age and express
itself as a full-fledge civilization and have offspring itself --
another replicating seed."
"This seed would most likely be a library full of knowledge and
perhaps tools. Many libraries now contain a lot of what we know about
our culture and technology, and even a little bit of how to recreate
it, but this library would have to accurately capture all the
essential knowledge of cultural self-reproduction. It is important to
realize that this seed library is not the universal library of
everything we know. Rather, it is a kernel that contains that which
cannot be replicated and that which when expanded can recover what we
know." [4]
It was this concept of a seed library of knowledge that was planted in
me, and on which Ben Lipkowitz and I expanded on in early 2008. Ben
and I are very similar and yet quite different. We both have a strong
history in programming, and so we were both able to share the concept
of debian, and early 2008 is when we started to work on SKDB. I
quickly learned that Ben had some unusual talents and interests. One
of his earlier projects he carried out was making a Gingery lathe,
which is a lathe he built from scratch, pouring the molten metals into
the shape of a metal-cutting lathe. Really impressive (there's some
photos later in this email).
[1] http://designfiles.org/dokuwiki/skdb
[2] http://fennetic.net/
[3] http://www.kk.org/thetechnium/archives/2007/03/bootstrapping_t.php
[4] http://www.kk.org/thetechnium/archives/2006/02/the_forever_boo.php
The idea for SKDB is that volunteer package maintainers encode open
source hardware projects currated from the web into a standard
package. These standard packages are fairly simple, it's just a folder
with some specific files, so almost anyone can make these packages.
Right now SKDB has only a handful of packages: screw, lego, bearings,
washers. When you download a package, the idea is that you're also
downloading the hardware, or the instructions to make the hardware
given what you have in your inventory. Because this project is still
"just" beginning, it's true that it can't be literal at the moment,
that the hardware can't physically be "beamed" over like the Star Trek
replicators and matter transporters, but this is close enough. SKDB
consists of two parts: (1) packages of open source hardware, and (2)
instruction generation. What I mean by instruction generation is that
the idea is that it will eventually spit out better instructions for
how to build a project. I've found that Ikia instructions and lego kit
instructions are some good examples of where I want to go. There's an
entire website [1] called Instructables where users type out
instructions for various projects. Unfortunately the quality is poor,
and that's why I'm interested in a computational method of generating
instructions for assembling projects. If you have a computational
representation of instructions, it's not a big deal to have either (1)
a human do it, or at a later time (2) a computer to follow the
instructions, like CNC machines and automated manufacturing equipment.
However! If you start off only with human readable instructions,
you're in a world of hurt, for you will have to wait for artificial
intelligence to be able to read in the information. But when you start
with package maintainers that are trained to make computational
instructions that can *then* be rendered into a human readable format,
you're much much better off. There's one primary website that
demonstrates the idea of a hardware repository called thingiverse.com
[2]-- but for various technical reasons, it's not adequate for my
purposes. Thingiverse is a website of "meshes", which is 3D surface
information. CAD data- for computer-aided design- is from engineers,
and maintains information about constraints, requirements, and even
solid geometries. Meshes are more often used in animation, film, and
3D gaming where it only matters what the model looks like. The
thingiverse users are using meshes because they are using 3D printers
like the RepRap [3] or MakerBot [4].
[1] http://instructables.com/
[2] http://thingiverse.com/
[3] http://reprap.org/
[4] http://makerbot.com/
So, after working on SKDB for a while, I started to realize that I
need to actually verify the data and information that I was encoding
into the software. It is not useful to be working in a vacuum or a
bubble. I need to know that I am not bullshitting people when I tell
them that the length of a certain rod needs to be 10cm, or 12cm, and I
need to get my error bars correct "or else". Meanwhile, on the
internet, there has been growing this community of supporters in the
Open Manufacturing group [1]. At openmanufacturing.org, the idea is to
bring software development methodologies to the physical world. The
mailing list [2] has been somewhat of an oasis on the web for
like-minded thinkers and doers-- attracting people like Marcin
Jakubowski of Factor E Farm, Michel Bauwens of the P2PFoundation,
Joseph Jackson, Philippe van Nedervelde, Paul D. Fernhout, Todd
Huffman, Eugen Leitl, Smári McCarthy, and various others. All around
this concept of open source hardware and open manufacturing: where
designs and schematics are provided and we're not afraid to build each
other's machines, tools and parts. Where we're allowed to stand on the
shoulders of giants, where we don't have to reinvent the wheel. Many
of the participants either directly manage a fablab, hackerspace, or
some other machine shop, or are somehow involved in those initiatives.
A fablab is a cross between a machine shop and a wetware lab, where
people can come to make (almost) anything. Tools and various
technologies are put into the fablab so that as much as possible can
be accomplished. One of the downsides of the fablab initiative is that
it's an academic project geared towards answering a question, "What
would third world country citizens make?" [3]. As a consequence,
fablabs have all the tools to make (almost) anything.. except for
making another fablab itself! They buy really, really expensive
equipment, and it requires huge academic and federal grants to get a
fablab up and running successfully ($100k+). There's about 20 to 30 of
these fablabs worldwide. A more broad, general case of this is a
hackerspace, which people have been setting up on there own. There's
hundreds of these [4]. They might not be as well funded, but it's a
place where people come to share their tools, projects and work
together to learn new things, hack, etc.
[1] http://openmanufacturing.org/
[2] http://groups.google.com/group/openmanufacturing
[3] http://www.ted.com/talks/neil_gershenfeld_on_fab_labs.html
[4] http://hackerspaces.org/wiki/List_of_Hacker_Spaces
So in early 2009 I realized that I needed to get a hackerspace,
fablab, techshop, *something* together so that I could make sure I
wasn't bullshitting people- that the data was right, that instructions
work as written/generated, and so on. So, I humorously sent out a very
simple email to the internet that plainly stated, "Dear interweb,
please give me a fablab. Thank you, sincerely, Bryan." Surprisingly
enough someone named Les Filip here in Austin, Texas replied. He has
had a 4,000 square foot shop for the past 20 years. At the time I
wrote the email, I was living on campus at the University of Texas at
Austin. But where I'm living now- his shop is 0.5mi away from me. Les
and I met up, and we found out that we're on the same wavelength for
almost all of our projects, and even some of our dreams (a critical
eye will find a copy of "The Singularity is Near" sitting on a dusty
shelf in a corner of his shop!). After touring his shop and making
some plans with Les, I eagerly wrote to Ben Lipkowitz. Within 2 weeks
Ben was moved down here into Austin, and he spent 3 months living with
Les. After that he moved in with me when I moved into an apartment.
Unfortunately it was a one bedroom apartment, so he slept in the
closet. It turns out that he always sleeps on the floor anyway- an
unusual character. So the year of 2009 was a spectacularly intense
year for the both of us- we were programming day and night.
http://austinhackerspace.org/
I suppose I should mention that when I was at UT Austin, I was
employed in a lot of different labs (simultaneously), and in
particular I was working in the Automated Design Lab[1] under Matt
Campbell[2] in the mechanical engineering department. I asked Matt if
he wanted to give Ben a job, but after learning that Ben had a degree
in microbiology, he said no. Ironically, when Ben physically showed up
in late May 2009, Matt gave him a job. So we were both working in the
lab for the summer period, and my employment continued after the
summer while his did not (budgets). Matt had hired us under an NSF
grant for a project called VOICED, Virtual Organization for Innovative
Conceptual Engineering Design. It's a multi-university collaboration,
and it's the original reason I met Matt. I showed up in his office one
day (late 2008) and said, "I am working on this project I call SKDB",
and Matt sat there and said "Cool, do you want a job doing it?".
VOICED is somewhat similar to SKDB, but I have kept the projects
separated because I don't want IP issues or entanglements. I have
heard too many horror stories.
[1] http://www.me.utexas.edu/~adl/
[2] http://www.me.utexas.edu/~campbell/
So, Les showing up was a very good thing. Unfortunately, it turns out
that Les has a weird sleep schedule, and he's awake at peculiar hours.
This wouldn't be much of a problem except that Ben has a weird sleep
schedule too. He's "out of phase" and can't help but stay up one hour
later each day, so he cycles on this 25 hour schedule and every 2
weeks is synched up with the rest of us. Consequently when he was
living with Les, they didn't get anything at all done. And I had
obligations at the university. Now that I no longer have those
obligations, I've been working with Les at the shop much more often. A
week ago I was helping him and a team to build walls for storage rooms
in the shop. Jason Wohlfahrt took some photos:
http://designfiles.org/~bryan/photos/2010-01-02/
This is where I plan to do some building soon. I have some projects
lined up that I want to execute, so that they can be put into SKDB and
everyone else can start testing them out. In particular I've been
thinking about a 4-axis (3 space, 1 time) CNC machine, the CubeSpawn
project, and recently a DNA synthesizer and a new version of OpenEEG.
I'll explain each shortly.
There's an open source 2-space 1-time axis CNC machine out there
called the mechmate [1]. Les has one assembled and ready to go at his
shop, it's 11x6 feet in size with a working area of 10x5. It's
massive. I need to hook up some electronics to it and get it working.
Interestingly enough, Ben used to be a programmer on the EMC project
("Enhanced Machine Controller") [2], free and open source software
that is made just for this problem. What you do is you hook up a
computer's printer port to servo controllers directly and use a
technique known as pulse width modulation to control the servos
directly. This is clever: the normal way involves making custom PCBs,
throwing together all sorts of electronics, or buying expensive
proprietary equipment. The downside of the mechmate is that the
schematics are all in a PDF file format, meaning either I or someone
else will have to do all of the diagrams in order to make it
compatible with SKDB. The schematics are just images, not CAD data.
:-( But the upside is that we have one mostly built already.
[1] http://mechmate.com/
[2] http://linuxcnc.org/
Interestingly enough, many years ago I heard about a project to build
an open source CNC machine sponsored by a website called MFG [1]. MFG
is just this giant portal that hooks up design engineers with
manufacturers who can do a quote on how much it would cost to produce
a design. The owner, Mitch Free, dropped $20k on an open source CNC
machine project (I don't know why so much), and the results were
fantastic, there's a really wonderful video here [2]. The guy who
built and designed the machine was Jorge Barrera, someone out of MIT.
I haven't been able to find Jorge for a very long time. So, this last
week I pulled out the trusty phone and called Mitch Free. I got his
answering machine, left a message, but got a call back a few hours
later. Apparently he has the design files sitting on a computer in his
house, and he's been waiting for someone like me to come along to make
use of them. He's very excited about SKDB and it's exactly what he's
been wanting to do. He's been holding off releasing the design files
until he has a better idea of what he wants to do with this "open
source hardware" he's developed. I'm still waiting for a follow-up
from him and will be giving him a call in the next day or so to see if
I laid it on too heavy with my email to him! I sent him an email
follow-up after we chatted on the phone so that he could see some
links and get a better idea of who I am and what the heck I'm rambling
on about.
[1] http://mfg.com/
[2] http://www.youtube.com/watch?v=OnfW9ggtiEk
Before I get back to the other projects, I mentioned to Mitch, and
some other people lately, one of the recent developments in SKDB. I
made a web server that interfaces SKDB to the outside world so that
people don't have to use Linux or the command line. I tell people to
think of it as a cross between thingiverse.com on steroids and
instructables.com mated with a cluestick. On the site, users can log
in to work on hardware projects (or they can download the hardware and
physically/digitally work on it with whatever tools they are
accustomed to). Next to every project on this website there are two
buttons: "make" and "buy". The make button generates instructions or a
plan that can be executed by the machines that a user has (even if it
the user just has one "machine"- a person!). The "buy" button is a
very special button.
The idea behind the "buy" button is that different people are willing
to go to different lengths or troubles. Ben Lipkowitz was willing to
build his lathe from scratch. However, not everyone wants to forge
their own screws, and not everyone wants to summon their own Big Bang
or to create their own quarks and universes just to make a sandwhich.
For this reason, the "buy" button is kind of a way to opt out of the
tech tree at a certain point. It's the point at which the user decides
it's time to spend some money and purchase something practical. Nobody
can do anything in a vacuum or a void- they have to have *something*
to start with, like their own simple house repair tools, screw
drivers, rubber bands, something! Back in 2009 I released some plans
on the do-it-yourself genetic engineering mailing list on how to make
microfluidic circuits out of pieces of glass, scotch tape and a
sharpie to harness the hydrphobic effects of the ink, water and
laminar flows. So in that situation you would need to at least have
some glass, sharpies and tape, etc. I can't help people make big bangs
(yet).
So when the user presses "buy", SKDB is assembling them a custom Bill
of Materials. This past week an interesting opportunity popped up on
my radar with Octopart [1]. Octopart is an electronics part search
engine. What they do is they feed in vendor datasheets into their
system and give price details and various parametric information about
different electronics parts, as well as mechanical parts and so on.
For SKDB's purposes of letting users opt out of the tech tree, this is
very interesting. I quickly wrote some code after talking with
Octopart's head guy Andres Morey, and the code [2] interfaces SKDB to
octopart to find parts that match a certain specification. The next
step on this front is a program that I should write that automatically
orders the parts from the vendors. Most vendors are *not* going to
respond to my emails and phone calls, but I still have a way to have a
computer automatically place orders across 30+ suppliers for a user,
and consolidate all the ordering/shipping information in one location.
This way the user can just see a BOM, see which parts they're buying,
and everything comes to their door. With instructions :-). Maybe one
day money won't have to be a part of this process?
[1] http://octopart.com/
[2] http://designfiles.org/skdb/octopart.py
The other physical hardware project that I have been looking into with
a critical eye is CubeSpawn [1]. CubeSpawn is the brainchild of James
Jones out of San Antonio, Texas. The concept is simple: standardized
form factors allowed the personal computer industry to flourish, and
perhaps it can do the same for the homebrew fabrication community as
well. So the form factor is basically a cube that can be scaled up and
down in size. Inside this cube you mount an open source hardware
project, like a CNC machine (perhaps Mitch Free's CNC machine?), or
the MakerBot 3D printer. With these cubes laying around all over the
place, you always have spare parts to build things with. I'm willing
to try it out and see how things go.I have been working to incorporate
CubeSpawn's dimensions and CAD models into SKDB. James and I met this
last week for the first time (it was a 2 hour drive both ways for
him). He's a really nice guy.. actually everyone involved in this is,
to be honest. Oddly enough James has been asking for $10k to get the
CubeSpawn project started, but I think he can get things rolling for
significantly less. I have dimensions and some models from him
already, and have played with a few cubes he drove down, so it's not
the end of the world if he doesn't get the funding he thinks he needs.
[1] http://cubespawn.com/
Jason Wohlfahrt is a friend I recently made back in November at an
event called 3 Day Startup. Jason has now been successfully
indoctrinated into the world of futurism, singularities, transhumanism
and technological acceleration :-). He has some money saved up and is
spending some of it on a MakerBot, the 3D printer. He finally put in
the order yesterday (I think). Once it arrives, I'm the guy who will
be assembling it. In particular I'm thinking of mounting it into one
of the CubeSpawn cubes.
Michael Grube is a fellow that I met many many years ago on the
internet, and now we've recently come back into contact. He's trying
to convince me to help him build an OpenEEG [1] setup with
32-channels. I'm not really convinced that EEG makes a good
brain-computer interface. But I'm willing to hear him out some more.
Might turn out to be an interesting project to include in SKDB? I am
not yet convinced actually.. the potential for EEG seems to be very
low, and I can't find any papers in the literature that harp on about
future potential advancements. The best EEG setups have been able to
give locked in paralysis patients up to 15 words per minute of typing
speed by thinking of "left arm" or "right arm" or "toes", and in some
cases the ability to control a prosthetic limb, but that's about it.
So I'm still wondering about this one. Michael might have to settle
for working on another project with me.
[1] http://openeeg.sourceforge.net/
Last but not least, someone from Caltech hit me up earlier today
asking about an open source DNA synthesizer project. I have a lot of
people wanting to build this sort of project. In the past the main
barrier to getting this done has been the cost of chemicals, so I was
drawing out some really elaborate pathways to synthesize
phosphramidites from chemicals and materials found in the average
kitchen. That was taking a very long time. But with some funding to
purchase chemicals to test with, and someone from Caltech (Winfree's
group), maybe a more traditional DNA synthesizer can be designed and
improved upon. Of course, I can also just buy one off of ebay for $300
and experiment with it for a while and see how it works. There's one
current DNA synthesizer project out there called PoSaM, but it's big
and bulky and costs $20k to build. Requires a nitrogen atmosphere. Not
what I want.
Last and certainly not least, I have been meeting so many amazing
people on the internet since I first came on it. I've been creating a
vehicle to channel, focus and leverage this awesome community of
hackers and engineers. In particular, it is called Gnusha [1], a co-op
for open source technologies. SKDB package maintainers are signed into
Gnusha. Projects like an open source SMT pick-and-place project (which
I've forgot to tell you about!) are set up in different locations,
like maybe in the Austin Hacker Space, and one at Marcin Jakubowski's
farm, and one at the Michigan RepRap User Group's (MURG's)
hackerspace. Profits from running the SMT machine (maybe it is hooked
up to a commercial website front-end) go back into the local shop for
overhead, but also back into the co-op so that overall there are
hundreds of these setups around the world contributing money back into
the pool. Then these funds are used to build more machines, and better
machines of all sorts- DNA synthesizers, CNC machines, SMT
pick-and-place machines, maybe one day molecular nanotechnology and
kinematic self-replicating machines or entire toolchains for
fabrication laboratories.
[1] http://gnusha.org/
Eugen Leitl also convinced me within the past few weeks (I'm not sure
when) that I should integrate NanoEngineer1 into SKDB. Nanoengineer1
is the open source nanotech CAD program that Nanorex developed a few
years back. Apparently there is no CAD software out in the world that
integrates macroscopic design engineering with the microscopic world,
like nano tech. Integrating the two softwares is easier than I thought
it would be because Nanoengineer1 is mostly written in python, just
like SKDB, so in some cases I can copy-and-paste code since it's all
open source and liberally licensed. Maybe one day this can help forge
a path to Freitas' and Merkle's diamond mechanosynthesis projects?
There has been so much positive support building around Gnusha. Even
before Gnusha was born there was this concept floating in our heads,
and I tried to aggregate it. Eric Hunting wrote about it and he called
it "ToolBook"- in general if you ever want to be blown away, just read
anything by Eric Hunting:
http://heybryan.org/om.html (in particular the top few links)
I should stop writing, but another recent update is that Nathan
McCorkle seems to have an interest in managing the microfluidics
subsection of SKDB. I need to rest my forearms for a while now and
then get back to work :-). So much to do! Also, like with anything in
life, there's so much that I have had to leave out, but if you ask
about anything in particular I am sure I can expound on it for hours.
Hope this rocks your socks off!
- Bryan
http://heybryan.org/
1 512 203 0507
