Common format to export to Papecraft cutters, 3D printers, and do-it-yourself plans?

4 views
Skip to first unread message

Paul D. Fernhout

unread,
May 15, 2008, 3:05:21 PM5/15/08
to OpenVirgle
Check out:
http://www.amazon.com/Graphtec-Multi-Media-Cutter-crafts-scrapbooking/dp/B0013YUUTI

There are several other manufacturers as well. That small one has no Linux
drivers (or I would have bought it already for under US$300 :-) but some of
the larger more expensive ones have Linux drivers. I've long wanted to
otherwise get some CAD/CAM system, but they take up a lot of room (which I
don't have much of) and are otherwise dangerous in the home (flying metal
shards, spinning parts, etc.). This cutter is a fun compromise.

The main site:
http://www.graphteccorp.com/craftrobo/

Notice under software vendors they say:
http://www.graphteccorp.com/craftrobo/partners/softvenders.html
"GRAPHTEC is looking for the software development company of Craft-ROBO!
Let's make a Craft ROBO world together!"
Not that I want their money, but maybe they would help with getting Linux
support? Though I see somewhere else someone called tech support about that
and got rebuffed. Their current software is mostly plugins for proprietary
drawing packages.

Interesting for the bigger stuff and Linux:
http://vidar.gimp.org/graphtecprint/
"graphtecprint is a driver / cutting application for the desktop plotter /
cutter Graphtec CC200-20 or any of the OEM models based on it, such as the
QuicKutz Silhouette (and reputedly Xyron Wishblade). It may work on other
Graphtec devices as well, but it’s so far only tested on the CC200-20. It
was developed on Linux, but in theory it should work on other Unix-like
operating systems, too, and perhaps even Windows (not tested!). The rest of
this page will assume that you’re using a Linux distribution."

Though I'd rather support the cheaper one eventually for a wider audience.

With feedback here from Bryan and Mike, I can wonder if there can be some
common representation of a more detailed design that can then be "exported"
to various formats. Still waiting for Doram's opinion but I wonder if he is
camping already?

I think there remains a lot of value in motivating people to share basic
papecraft designs as "placeholders" for things like SpacePods or Mars
crawlers or moonbases or spacecraft and cups and spoons and so on.
Especially from a community building perspective -- people may come for the
toys but a few might stay to build more detailed versions, maybe even real ones.

But, I can see the value of a common approach too that -- or even one which
would somehow be incrementally refined in different directions. So, a common
design ideally might be exported to any of:
* do-it-yourself papercraft cutting instructions and templates,
* path files for cutting and scoring on a GRAPHTEC CC200-20,
* a 3D model for use in a simulation,
* control files for a 3D printer,
* more detailed instructions to do it yourself for real (with a real parts
list and real blueprints), and then someday
* nanotech fabrication patterns.

That's a long term ideal of course, not an essential starting point. As
Bryan pointed out elsewhere, if it takes a lot of people to do a lot of work
by hand, then so be it. It does suggest having our own CAD software down the
road might be a big plus to unify all that somehow.

To an extent, the PlantStudio software does that by having its own
representation for botanical plants but then exporting a specific grown
variation to any of a number of 3D output formats. This web page from 2001
has sadly disappeared and the archive does not have pictures, but it used to
look really nice:
http://web.archive.org/web/20010410052209/http://master.neelum.com/~djduffy/quake/plants/index.html
"Quake goes floral, starting now.... PlantStudio builds realistic looking
plants from a set of parameters. Real or non-real plants can be created and
then exported as pictures or graphics files. This page takes a look at
moving those graphic files to Quake 3 as models. ... So as we see, plants
can be created and converted using tools available for a very modest cost
and effort. As graphics performance has improved, it may now be time to
brighten up those dingy gothic castles with some floral arrangements. And
some of the more innovative maps such as above could greatly benefit from
some plants in the grounds and gardens."

By the way, Bryan, you can make paper systems with moving parts (maybe even
a paper/cardboard bicycle), they are just not very robust:
"Paper Automata: Four Working Models to Cut Out & Glue Together"
http://www.amazon.com/Paper-Automata-Working-Models-Together/dp/189961821X
(that page links to similar books too.)
Still, good designs often minimize moving parts which can wear -- ICs
instead of relays, electric thrusters instead of liquid fuel rocket engines,
and in turn simpler rocket engines instead of complex gasoline motors. A
good question is what percent of mass in a space habitat is in some sense a
"moving part"? Ignoring the motion of the whole thing, of course. :-)

To me, the big idea is getting stuff happening both in 3D and the real world
-- even if we are only printing in 2D now and folding and taping. You can
also do expanded (or shrunken) versions of scientific ideas -- someone made
a design for a paper human skeleton, one can imagine an expanded version of
part of a solar collector that somehow showed how photons are absorbed and
electrons are set in collective motion. Anyway, even for solar panels, there
are no moving parts. When we got our child a doll house of wood, the first
thing done was to put scotch tape on the roof as solar panels. Imagine if we
could have later printed out more realistic ones with wiring harnesses,
battery banks, and an inverter
http://www.builditsolar.com/Projects/PV/pv.htm#Small%20Systems

Still, projective imagination with plain things may be better a lot of the
time, so there are limits to the value of realism for young children. See:
http://www.dandelionsummers.com/html/imaginative_play.html
"""
Toys that encourage imaginative play:
* open-ended, can be played with in a variety of different ways.
* are simple, yet attractive in their details, allowing the child’s
imagination to complete the details to suit their mood or play.
* let the child determine the play (they are not modeled after the
latest cartoon or movie).
* are made of natural materials.
"""
See also:
http://www.wisegeek.com/what-are-some-good-toys-for-imaginative-play.htm
"Different types of toys can support imaginative play in different ways.
Toys that are in some way undefined, such as a block of wood or a block of
modeling clay, invite the child to engage with them and make whatever she or
he wants out of them. Many art supplies, and building blocks of various
types fit this category of imaginative play toys. Other examples are Erector
Sets and K’NEX®, which can be used as desired by the child."

I think paper toys that can be printed and assembled (at first just by the
parent) on demand of the child's interests (they care about Badger in Wind
in the Willows, you print a badger, maybe a 3D white one to be colored in)
might be a totally new category in a sense. Still there is a tiny pause as I
write that, especially for young kids.

In the future we older kids :-) could all print OpenVirgle models in 3D when
the prices fall on stuff like this from the current about $45K (and it gets
easier to use and handles more materials):
http://www.zcorp.com/Products/3D-Printers/ZPrinter-450/spage.aspx
"Now you can print 3D color models so quickly and affordably, you'll do it
every day. Introducing the ZPrinter®450. The ZPrinter 450 makes color 3D
printing accessible to everyone. The lowest priced color 3D printer
available, it outputs brilliant color models with time-saving automation and
an easy printing process."

Also on those:
http://www.prototypemagazine.com/index.php?option=com_content&task=view&id=90
"So, where does Z Corp fit into this? The answer is at its very core. Z
Corporation’s machines are one of the best examples to date of true rapid
prototyping – with an emphasis on the rapid. They allow the user to generate
a 3D model, print it and have it in their hands within hours. But they
aren’t alone. What differentiates Z Corp from its competition is simply
colour. But until recently the colour capability has been the cost premium.
With the entry level 310 offering only monochrome build capabilities, only
the Spectrum 510, launched in 2005, truly offers flexible colour building
potential."

Z Corp also has a neat handheld 3D scanner btw:
http://www.prototypemagazine.com/index.php?option=com_content&task=view&id=151&Itemid=2
"Once ready, you press the trigger and begin to pass the projected
crosshairs over the surface of your object. The major differentiator and
unique aspect of this device is the self-positioning nature – in that you
move the unit around the object, rather than moving the object whilst the
scanner remains stationary, without the use of an arm. It does this by
registering the position of the target, as the system detects the first four
points it triangulates and retains the position of the device. As you pass
the scanner over, the laser captures the geometry and the scanner’s position
is known by tracking these targets. If you lose position, you simply press
the trigger and pass the laser over an already captured area to re-acquire
its position."

So, one can imagine thousands of people using similar devices in the future
to put in 3D models derived from real objects, and we might then have
software indirectly related to that script Bryan mentioned to take the 3D
models and figure out how to make instructions for people or machines as to
how to build something similarly shaped. Although I think it likely evolving
new shapes through intelligent design like with PlantStudio-like software
might also prove popular down the road.

Anyway, I need to think more on this issue of common representation, or if
it is too hard at the start. It might take some serious software to do a
good job automatically from 3D to paper, but maybe an intermediate helper
program might be good enough. I was originally thinking the 3D models would
just be virtually folded and taped virtual cut paper. And maybe that is good
enough for a start. We will see.

--Paul Fernhout

Bryan Bishop

unread,
May 15, 2008, 7:54:04 PM5/15/08
to openv...@googlegroups.com
On Thursday 15 May 2008, Paul D. Fernhout wrote:
> Check out:
> http://www.amazon.com/Graphtec-Multi-Media-Cutter-crafts-scrapbooking
>/dp/B0013YUUTI

Paul, all of these notes would be stuff to throw into skdb files, I
should point out. So a few seconds of thought about the overall
meta-structure of what these notes are based off of would *probably*
show a somewhat time-stamped list of ideas that are referenced to some
websites, plus comments/annotations, streamed together. So if we had a
quick interface for dumping these into a database, the better. I'm
thinking that the basic semantic structure is simply link + annotation
+ timestamp, maybe some verbal taggage. Some python:

class fernhoutunit:
__init__(this, name, tags, annotation)
this.name = name
this.tags = tags
this.annotation = annotation
__repr__(this, name, tags, annotation)
# Uhh. Py-YAML tells you how to do this.

And then those objects can be serialized and unserialized. The big
problem is overhead. As you said [that as I said], if it's going to
take some overhead and clickage, so be it. But let's also minimize it
too. Back in 2004, when I did my first slackware linux setup, I had a
shell script that I could blog into, perhaps predating twitter [and
certainly my knowledge of twitter]. As it is now, to update my website,
I open up kwrite and thankfully the KDE open-file process is
standardized and so I can type the ftp path out to my server, but
that's a lot of key strokes to get to the specific directory, and
frankly that's just useless overhead that should be automated. Same
thing with the amount of effort we all have to go to do references,
even in papers. As you read you should be able to "digest" the paper,
the file, the web page; SuperMemo called this reading thousands of
books at once. In SuperMemo, you would open up all of the web pages
that you wanted to read, highlighting sentences and statements as you
go, and then doing color markup and other annotations, and then
inserting them into the memory system for further processing. Heh, back
in late 2006 I was even getting carried away with my digestion of Mark
Twain [since I was disliking it so much]:
http://heybryan.org/school/English%20III/Huck.html
So, yeah. I know I'm complaining a lot here, but it's a lot of effort to
look up and down from pages of a book, or even to tab from one window
to the next (clicking even worse - avoid at all costs); so the whole
process of annotation and digestion sucks. I knew this then, and I
still try to work on the problem. Most recently via AutoScholar:
http://heybryan.org/projects/autoscholar/
The idea with AutoScholar is to automate the downloading of scientific
papers from either open access databases or really anything that it can
get to. I don't care how. I was using the perl WWW::Mechanize library
to fool Google Scholar into thinking it was just me clicking around on
their links. It needs some improvement, actually. It's supposed to be
able to find a paper no matter what, including going down some other
routes that I mapped out on the page, but I haven't quite gotten around
to it. My idea is to eventually do full crawls of important regions of
science via analysis of BibTeX. Not all papers provide BibTeX, so I was
investigating the prospects of automated OCR of the references section.
Things did not turn out well. Furthermore, it doesn't yet really solve
the problem of annotations. I spend a lot of time with pen and paper. A
lot of time. I produce about 100 lines of written text on blank paper a
day, mostly because it's too much overhead to reach for the laptop and
I need to scribble out insights *now*. I know paper very, very well.
The blankness, the void. It's almost intimidating when you don't have
something that you are actually processing. Lion Kimbro out there on
the internet talks about keeping every single thought he ever has in a
collection of such papers -- and let me tell you, he's right when he
says it will paralyze you. I see the problems. The issue is ultimately
this: semantic annotation and full tagging distracts from actually
thinking and considering everything, while printing out the text and
marking it up with pens, colors, highlight, etc., -- you lose too much
information and it's unrecoverable, so the best you can do is retain
little insights left over from it. And having somebody type up the
handwritten notes is ultimately futile, since only you can really
remember your intentions in certain marks and the lines of reasoning
that you were trying to compress [because of the nature of handwritten
notes, you can't get everything out fast enough, so you do massive
compression and generalization -- with a keyboard this isn't the same].
But I am optimistic and I suspect there in fact does exist a
computational solution to the Paper Digestion Problem. For a while now
I have been figuring that the solution is to expose the processes going
on inside the brain itself. Think about debugging your own programs.
There are not too many variables to focus on, and if there are you can
probably think of ways to refactor, or ways to debug by placing
specific markers within the program. The brain doesn't do this
naturally. There's lots of information that is sorted and selected,
a 'neural darwinism' according to Edelman [who didn't win a Nobel Prize
for nothing]. There are tons of gradients of information within the
head. As Salthe says: nature abhors a gradient. Somehow, if we can get
in there and capture some of that information [NOT just action
potentials (APs) but also the dendritic connections and the rules for
making brains, as Markram has been elucidating], then that can be
processed, sorted and organized by helpers, I call them 'mindbots'.
This ultimately solves the documentation problem, the blogging problem,
the overhead problem and while it's no substitute for true experience,
it's a way that we can more fully detail the experiences that we are
having. No solution will ever be enough [short of making an entirely
new brain, a better brain], but again it's a way of coping. So that's
why many of my projects are focused so much on neurosci and engineering
and so on. I want to take care of my neocortical columns, I want to
debug them and capture all of this extra data that I am letting vanish
into entropy. [[Would this be enough to solve part of the problem?
Xanadu, remember, was to solve some of these. It would 'remember' the
context in which you were writing everything, timestamps as well as the
recursive pathways of clickage and commands that you are running in the
unix-shell pipelines on top of the microprocessor threaded pipelines,
and so on. So in the mean time we need a way to cope until we can get
to that stage. I don't know what to suggest, but bruteforcing the path
seems like a good option to me so far.]] Back to the topic at hand.

> There are several other manufacturers as well. That small one has no
> Linux drivers (or I would have bought it already for under US$300 :-)
> but some of the larger more expensive ones have Linux drivers. I've
> long wanted to otherwise get some CAD/CAM system, but they take up a
> lot of room (which I don't have much of) and are otherwise dangerous
> in the home (flying metal shards, spinning parts, etc.). This cutter

> is a fun compromise. http://www.graphteccorp.com/craftrobo/

Re: CAD software. Yes, but apparently there isn't anything for linux
that actually does the job well, so this is something that is going to
have to change if we expect serious design to be taking place.

> With feedback here from Bryan and Mike, I can wonder if there can be
> some common representation of a more detailed design that can then be
> "exported" to various formats. Still waiting for Doram's opinion but
> I wonder if he is camping already?

That 'common representation' is the whole point of the metadata files.
Though I think you are suggesting a specific case of these:
paper-folding. A few days ago we were mentioning Rube Goldberg
machines, which would be another type; so it looks like you're on to
something pretty specific. But looking at the subject line, I have to
point out that diy plans aren't necessarily going to fit within the
same cases as paper-folding-diy projects. After all, diy projects range
from genetic engineering equipment to anything else in civilization.

> I think there remains a lot of value in motivating people to share
> basic papecraft designs as "placeholders" for things like SpacePods
> or Mars crawlers or moonbases or spacecraft and cups and spoons and
> so on. Especially from a community building perspective -- people may
> come for the toys but a few might stay to build more detailed
> versions, maybe even real ones.

Isn't it all toys anyway? re: OSCOMAK playful community.

> But, I can see the value of a common approach too that -- or even one
> which would somehow be incrementally refined in different directions.
> So, a common design ideally might be exported to any of:
> * do-it-yourself papercraft cutting instructions and templates,
> * path files for cutting and scoring on a GRAPHTEC CC200-20,

Of course, the way to BUILD the GRAPHTEC also belongs within SKDB. It's
more about processes than dry flatfiles, really, so these flatfiles
that are 3D models and so on aren't things that I actually care about
that much, as long as we can facilitate the general case and the
process behind it. Which was the entire point of a demonstration. Guess
it's working.

> * a 3D model for use in a simulation,
> * control files for a 3D printer,
> * more detailed instructions to do it yourself for real (with a real
> parts list and real blueprints), and then someday
> * nanotech fabrication patterns.

Nanotech? =( Clanking replicators, clanking.

> That's a long term ideal of course, not an essential starting point.

The important point is mapping out the strategy and then implementing
the methods to make the strategy a success; I don't think any of us
particularly care about the end results, as long as they work and are
good, technically feasible projects, follow the general specifications,
etc.

> As Bryan pointed out elsewhere, if it takes a lot of people to do a
> lot of work by hand, then so be it. It does suggest having our own
> CAD software down the road might be a big plus to unify all that
> somehow.

Yes, that's the idea of the 'matter compiler' and GAs and so on, much
like your plantbuilder/gardenbuilder/PlantStudio as you suggested.
http://heybryan.org/mediawiki/index.php/Matter_compiler

> To an extent, the PlantStudio software does that by having its own

> representation for botanical plants [...]

Scientific models/representations, naturally belong in SKDB too.

> By the way, Bryan, you can make paper systems with moving parts
> (maybe even a paper/cardboard bicycle), they are just not very
> robust:
> "Paper Automata: Four Working Models to Cut Out & Glue Together"
> http://www.amazon.com/Paper-Automata-Working-Models-Together/dp/18996

>1821X (that page links to similar books too.)

Huh. Interesting.

> Still, good designs often minimize moving parts which can wear -- ICs
> instead of relays, electric thrusters instead of liquid fuel rocket
> engines, and in turn simpler rocket engines instead of complex
> gasoline motors. A good question is what percent of mass in a space
> habitat is in some sense a "moving part"? Ignoring the motion of the
> whole thing, of course. :-)

Yeah, solid state is the way to go. If anything is going to be moving,
let it be the subatomic particles, or the smallest possible unit, not
the big giant stuff [uh, like cars - bad idea].

> To me, the big idea is getting stuff happening both in 3D and the
> real world -- even if we are only printing in 2D now and folding and
> taping. You can also do expanded (or shrunken) versions of scientific
> ideas -- someone made a design for a paper human skeleton, one can
> imagine an expanded version of part of a solar collector that somehow
> showed how photons are absorbed and electrons are set in collective
> motion. Anyway, even for solar panels, there are no moving parts.

Maybe something with graphene?
http://heybryan.org/graphene.html There was recently something in the
news about very easy ways of making sheets of graphene via tape and
folding [re: origami/papercraft], and you can sketch nanocircuits into
these things with the AFM nanolithography setups:
http://heybryan.org/mediawiki/index.php/AFM_nanolithography
But a general STM/AFM setup first would be pretty good too:
http://heybryan.org/instrumentation/instru.html
^ I still need to add bio instrumentation equipment on to that page. Hm.

> When we got our child a doll house of wood, the first thing done was
> to put scotch tape on the roof as solar panels. Imagine if we could

Doll houses? Lego houses.

> have later printed out more realistic ones with wiring harnesses,
> battery banks, and an inverter
> http://www.builditsolar.com/Projects/PV/pv.htm#Small%20Systems

You can print out electronic circuits (PCBs) via inkjet printers.
http://fab.cba.mit.edu/central/?q=forums/in_the_news_fab_lab_like_projects/191
http://www.dcordes.freeuk.com/o2board.htm
http://forums.bit-tech.net/showthread.php?t=31766
http://www.turbokeu.com/myprojects/pcb.htm
http://www.qsl.net/vk5cu/
http://recording.org/users/kev/HowtoPCB.htm
http://www.semis.demon.co.uk/PCB/PCB.html
http://www.nrgrecording.de/html/pcb.html
http://web.media.mit.edu/~ladyada/resources/inhouseetch.html
http://web.archive.org/web/20030608202504/http://www.gyraf.dk/gyraf2/gy_pd/pcbs.htm
http://www.electricstuff.co.uk/pcbs.html
http://www.rdrop.com/~cary/mirror/tools_htmlized.html
http://opencircuits.com/PCB_Footprints
http://www.fiu.edu/~seagrass/class/pcb3043/lab10.html
http://www.forestry-suppliers.com/product_pages/View_Catalog_Page.asp?mi=3342
http://www.fullnet.com/u/tomg/gooteepc.htm
http://max8888.orcon.net.nz/pcbs.htm
http://www.nbb.cornell.edu/neurobio/land/PROJECTS/PCBadaptors/index.html
http://hem.passagen.se/communication/pcb.html
http://www.freelabs.com/~whitis/opensymbol/
That last one: "... the Open Symbol Project aims to create an open
collection of schematic symbols and PCB footprints released under a
license that does not interfere with use in either commercial or free
projects."

> I think paper toys that can be printed and assembled (at first just
> by the parent) on demand of the child's interests (they care about
> Badger in Wind in the Willows, you print a badger, maybe a 3D white
> one to be colored in) might be a totally new category in a sense.
> Still there is a tiny pause as I write that, especially for young
> kids.

Re: kids and weird commercial stuff for their entertainment. I take the
Waldorf isolationist approach on that front.

> Z Corp also has a neat handheld 3D scanner btw:
> http://www.prototypemagazine.com/index.php?option=com_content&task=vi

>ew&id=151&Itemid=2 "Once ready, you press the trigger and begin to


> pass the projected crosshairs over the surface of your object. The
> major differentiator and unique aspect of this device is the

> self-positioning nature - in that you move the unit around the


> object, rather than moving the object whilst the scanner remains
> stationary, without the use of an arm. It does this by registering
> the position of the target, as the system detects the first four
> points it triangulates and retains the position of the device. As you
> pass the scanner over, the laser captures the geometry and the
> scanner's position is known by tracking these targets. If you lose
> position, you simply press the trigger and pass the laser over an
> already captured area to re-acquire its position."

I can imagine a system similar in nature to the wii and the wii remote,
plus a few lasers involved. If you set up the motion capture devices in
a nearby circle of the object, and then pass the laser around and
record the information, then you get lots of triangulation information
and so on too. So it's kind of a cheap way of doing it, but hey. I
think these lasers are pretty cheap. Actually, you don't really need to
do the laser method, normal photography works pretty well, especially
for faces. Take a look at this:
http://heybryan.org/mediawiki/index.php/Societal_engineering_knowledge_database#2008-05-14:_pepakura
http://www.bertsimons.nl/zenphoto/paperworks/
which is just digital photography, even from the disposables.

> So, one can imagine thousands of people using similar devices in the
> future to put in 3D models derived from real objects, and we might
> then have software indirectly related to that script Bryan mentioned

3D models aren't the entire point. It's the processes that provide the
functionality we need -- ultimately the idea is to *make* things, the
emphasis is on the making, the processes, the tools and machines to
facilitate this, not necessarily the things themselves, although those
are of course useful.

> to take the 3D models and figure out how to make instructions for
> people or machines as to how to build something similarly shaped.
> Although I think it likely evolving new shapes through intelligent
> design like with PlantStudio-like software might also prove popular
> down the road.

Yep. But evolving them, I've figured this is pretty hard. Earlier today
I came across the idea that -- maybe -- the parallelism/nonlinear stuff
is related to GNU Hurd, the microkernel, it's a way to stuff the
evolutionary potential into the operating system, as opposed to on to
the user (the research scientist trying to integrate divergent
components together) and instead of the programmer. In my case I keep
thinking it's going to be an 'amorphous compiler'. But again, this
isn't necessary as long as the 'fabhat' setup is completely
standardized.

> Anyway, I need to think more on this issue of common representation,
> or if it is too hard at the start. It might take some serious
> software to do a good job automatically from 3D to paper, but maybe
> an intermediate helper program might be good enough. I was originally
> thinking the 3D models would just be virtually folded and taped
> virtual cut paper. And maybe that is good enough for a start. We will
> see.

Intermediate helper programs are encouraged.

- Bryan
________________________________________
http://heybryan.org/

Reply all
Reply to author
Forward
0 new messages