http://www.youtube.com/watch?v=lQOkMz3kiS0
http://www.brepettis.com/blog/2009/2/27/sudo-make-me-a-sandwich-robot.html
Adam's blog: http://www.shadowflux.com/blog/
pictures & code:
http://www.shadowflux.com/blog/2009/02/27/sudo-make-me-a-sandwich-robot-brooklyn-part-2/
Adam apparently used QCAD to model up the cheese/bread distribution
mechanisms. The design files are available via thingiverse, the
NYCresistor design sharing site. What the robot does in the video is
use a simple mechanism found in vending machines to push off slices of
bread and cheese on to a plate that is pushed into a toaster oven. The
door doesn't completely close, but many toasters are open-air toasters
anyway, so it's not a terrible tragedy except for energy efficiency
(heat gradient).
QCAD: http://www.qcad.org/
Design files: http://www.thingiverse.com/thing:332
It was inspired by Randall Munroe's comic, XKCD:
http://xkcd.com/149/
http://imgs.xkcd.com/comics/sandwich.png
For those who are unaware of "make" and related utilities, see:
http://en.wikipedia.org/wiki/Makefile
"In software development, make is a utility for automatically building
executable programs and libraries from source code. Files called
makefiles specify how to derive the target program from each of its
dependencies. Make typically decides where to start through
topological sorting. Though Integrated Development Environments and
language-specific compiler features can also be used to manage the
build process in modern systems, make remains widely used, especially
in Unix-based platforms."
"There are now a number of dependency-tracking build utilities, but
make is one of the most wide-spread, primarily due to its inclusion in
Unix, starting with the PWB/UNIX 1.0, which featured a variety of
tools targeting software development tasks. It was originally created
by Stuart Feldman in 1977 at Bell Labs. In 2003 Dr. Feldman received
the ACM Software System Award for the invention of this important
tool.[1] Before make's introduction, the Unix build system would most
likely consist of "make" and "install" shell scripts accompanying a
program's source. Being able to combine the commands for the different
targets into a single file, and being able to abstract out dependency
tracking and archive handling, was an important step in the direction
of modern build environments. In its basic form, Make requires the
programmer to manually track all dependencies between files in the
project. This process is error prone, since a forgotten or an extra
dependency might not be immediately obvious, but instead surfaces as
subtle bugs in the software. It is possible to create make files that
generate some of these dependencies, but a more common solution is to
use one of the available generators to make, e.g. the Automake
toolchain provided by the GNU Project."
The fablab shelltrance was a file I put up on a server a few weeks ago
going over other "unix-like ways to run a fabratory"-
http://heybryan.org/~bbishop/docs/shelltrance.txt
One of the subsections was related to diybio and XML-like protocols
for lab procedures-
"""
## diybio protocols
mkdir ~/diybio/projects/
cd ~/diybio/projects/
wget http://heybryan.org/~bbishop/docs/protocols/pcr.xml
consumables pcr.xml > CONSUMABLES
reqtools pcr.xml > TOOLS
if [test -n `difftool --base=/etc/fablab/inventory TOOLS`] then
cat CONSUMABLES > /dev/checkout ;
else
difftool --base=/etc/fablab/inventory TOOLS > ORDER-REQUEST
cat ORDER-REQUEST | mail -s "Tool discrepancy alert" root@fablab
echo "Your tools will arrive shortly. Perhaps you would like to build
them yourself?"
# TODO: print out instructions for building the tools.
fi
"""
Recently, Zach Smith, one of the other guys behind thingiverse with
Bre Pettis, wrote up a similar blog post that plays on these themes
pretty well-
Pull yourself together, bot!
http://blog.reprap.org/2009/02/pull-yourself-together-bot.html
"Okay, so how exactly do I propose we have the machine self-assemble?
Easy! We use a stepper motor, some threaded rod, a python script, and
a few other parts to turn the RepRap technology into a precision
kebab-building machine! Here's how it works: I created a reference
design in QCad. (which I totally forgot to check into subversion,
sorry!) From this design, I created a python script that creates GCode
instructions for building the various kebabs. The GCode consists
mainly of two parts: instructions that prompt the user to do things:
thread a nut on the rod, slide on kebab parts (diagonal ties, washers,
etc) and actual instructions that cause the rod to rotate a nut to
exactly the right position. The end result is pretty slick: it
generates a wizard that serves as both a guide and a self assembly
program. You the user just sit back and do what your robot overlord
prompts you to do. A screenshot is shown on the right here."
Zach later continues:
"""
1. the design is parameterized! the python script takes all sorts of
parameters that control the gcode that is output. things like X, Y,
and Z dimensions so you could build a big RepRap machine, or a small
reprap machine! it also takes things like rod size, washer size, and
nut size so you can easily convert the script to imperial, or use M5
hardware. it also has some cool options for the build such as leaving
out washers, or using thread locking compound for those adventurous
souls who never wish to take their machine apart.
2. the instructions are the design! the first 20 lines of the gcode
are instructions such as the number of nuts you'll need, the number
and lengths of the various rods you'll need, as well as various bits
of information such as volume diagonal lengths, etc. not only that,
but as its an interactive process, it makes assembly a snap: you
simply follow the step-by-step instructions and the various parts go
together in front of your eyes. no more digging through complicated
build instructions. just connect the dots!
3. we can do lots of other cool things: dynamically generate a DXF
template for the bed? sure! dynamically generate STL files for the
diagonal ties? sounds awesome! one day you may be able to use the same
script to generate a miniature reprap for building ant-sized things or
to generate a reprap for building buildings! these things still need
to be implemented, but the framework is there.
"""
So, I think that overall people are starting to get the picture about
open manufacturing and open hardware. Instructions, assemblies,
design, intercompatibility and repeatibility are all important issues
that hardened software approaches can make significantly more smooth
and, well, doable. Especially with the idea of wizards to help through
the assembly process, by going over instructions, or using
instructions (like alternatives to gcode) to find compatible
replacement parts that can do the same job based off of what you have
laying around at home in your inventory, or at the local fablab.
I also think the recent work on sharpie microfluidics has a role to
play in these topics. The ability to do in situ fabrication of
complex, micron-scale sized structures, or perhaps even nano-scale
structures (not yet tested!), might make for some interesting headway
on the diybio side of things, or maybe not- at least it was a fun
weekend project? There are even photos now :-).
http://heybryan.org/books/papers/microfluidics/jeswin_john_IMG_0521.JPG
http://heybryan.org/books/papers/microfluidics/jeswin_john_IMG_0524.JPG
http://heybryan.org/books/papers/microfluidics/macgyver_multitool.jpg
It is also interesting to consider the possibilities opened up by
pythonOCC, the python API bindings to OpenCASCADE, the free/open
source CAD package. I can easily imagine something like HeeksCAD (Dan
Heeks) and the InteractiveViewer.py script being united into a python
scripting environment for CAD, but plus also heavy parametrization of
designs, and a focus on instructions, assembly information, part
mating, compatibility and catalogs, which becomes much easier with
(dare I mention) pickle or YAML for object serialization. Maybe even
to the point of allowing for some long-promised packaged hardware
files with the sacred metadata- either for gel boxes,
transilluminators, thermocyclers, microfluidic designs, sandwich
making machines, repraps, or perhaps something else?
No, sorry, but I will try to explain about Zach's post.
> programmer and a bit confused by this. Its some sort of mass production but
> I don't understand the programming part about 20 lines.
In his blog post, Zach was talking about gcode, and how it can be used
to show instructions for assembly. Normally, gcode is machine
generated instructions from CAD models of complex shapes that are sent
to computer numerically controlled (CNC) machines that will remove
metal from a brick, ultimately into a desired shape. It's a way of
making an assembly line without people, think of it like that.
Here's the source code that Zach was ranting about-
https://reprap.svn.sourceforge.net/svnroot/reprap/trunk/users/hoeken/pythagoras/make_bot.py
more available here:
https://reprap.svn.sourceforge.net/svnroot/reprap/trunk/users/hoeken/pythagoras/
In particular, what his script does is specifically tailored to the
"frame" parts that he was playing with. The user passes a few
parameters to the script, and the script then consequently generates a
list of steps that the user can take to assemble a frame with the
parameters that he originally specified. So, the script not only
generates human readable instructions, but also gcode, meaning that a
human doesn't necessarily have to be the one assembling things: it's
of course important that we're able to read the instructions and
assemble our tools, but on the other hand, there are times when we'd
rather not- like in the case of mass production, or reconfigurable
manufacturing where we have all of the tools already laying around,
and we want them to just work. (or something)
I'm going to employ a strawman argument here. There seems to be many
people who think that it's either "one or the other"- either human
readable instructions, or machine readable instructions, but not both-
but there are many demonstrations, and even all this now, which is
demonstrating otherwise, and the benefits derived from this
understanding and the benefits derived from implementations.
I really appreciated the Public Service Announcement at the end. I've
been aware of what they pointed out in an abstract way for a long
time, of course, but the demonstration at the end really brought it
home to me.
I think I'm going to go give it a shot myself.