Re: the mechanics of sharing physical design
Bryan Bishop
> Dear friends:
>
> I have posted this query by Jon Kuniholm at
> http://p2pfoundation.ning.com/forum/topic/show?id=2003008%3ATopic%3A6733 as
> it is perhaps a better way to preserve the discussion for the future.
>
> Jon Kuniholm <openpro...@gmail.com>:
>
>
> I'm interested in joining the P2P Foundation in order to contribute to
> the discussion on Open Design. I found you all because I noticed that
> you had cited our list of the benefits of sharing physical design
> information here: http://www.shareddesign.org/
>
> I'm particularly interested in the mechanics of sharing physical design
> information, and I'd like to get some wiki-based discussion going on the
> specifications for an open source software suite of tools to make this
> easier, including CAD software.
Hey Jon, glad you brought up this topic. I'm presently sitting in the
Automated Design Lab - quite literally on some rather comfortable
chairs - while the computers are humming away generating CFGs,
graphical depictions of designs of various artifacts from a repository
that I've been throwing together with an open source group that tends
to post to that openmanufacturing mailing list that Michel mentions.
As you are aware, the CAD interchange formats suck immensely, and they
do not really capture all aspects of design as they are now.
There's some data sets that you can go look at *right now*:
http://heybryan.org/~bbishop/docs/
In particular, there's the repo/ directory which contains an XML
description of the interconnection of parts of various consumer
products. This is a direct rip from the MST
repository.designengineeringlab.org website. The prettyrepo.zip file
might be more useful since it's significantly smaller. There's also
the biobricks.zip file which is quickly approaching some design
sharing format in general, thanks to some new developments from the
diybio.org mailing list and on the IRC channels.
What we've been figuring is that we're going to be using YAML metadata
to specify the overall information about designs and provide an exact,
computational, specific way of representing and specifying all of the
important details about interconnections and other properties of the
design. Anyway, as you say, you're interested in the mechanics of the
sharing, perhaps not so much the how-the-knowledge-is-represented
issue.
So, you might be interested in the mechanisms that we've been using
with the community at large -- various git repositories. This is one
repository that has been used for the biotech toolkit and bioreactor
project, which I consider a subset or child project of the larger
ideas flying back and forth among us:
http://heybryan.org/gitweb.cgi
http://heybryan.org/biotech.git
There's also a somewhat nonworking ikiwiki + git interface to the
dataset to help facilitate web-users to peak into the data set in some
wiki-ish interface that they apparently love so much.
Anyway, I need to run :-) but I hope you'll ask questions.
- Bryan
Bryan Bishop
> Forgive my ignorance here: how do I look at a repo file? Can I create
> an STL file or a G-code machining path with one?
Things are only steadly moving along. You'll have to forgive _me_ for
this. Here's an example of what the repo files are currently storing:
http://heybryan.org/~bbishop/docs/repo/CFGs/72.png
That file was generated via http://graphviz.org/ - some graphing
utilities. Some of the repository files have CAD files within them that
represent the overall "repo file", the finished product, but don't have
the necessary detail such as the subcomponents, like the PCB boards
involved and such.
I'm working on fixing this.
Yes, STL and gcode are very important to me as well. You cannot generate
STL files from it yet. It's certainly on the todo list .. very high up
there. A few weeks maybe ?? (This is highly dependent on some other
preliminary work that I think must be done: the file format has to be
rewritten.)
> I agree that there's a difference between the mechanics of sharing vs
> representing designs, but think that there may be some opportunity
> here to allow some overlap to be created by thinking about both in
> new ways. Mako Hill pointed out in a discussion we had a while ago
> that an application that made it easier to collaborate on CAD
> stuff--the equivalent of Google Docs for design--would be forgiven
> many foibles because of such features.
Good news! I have a volunteer working on an AJAX
Google-Docs-like-interface for this. It's basically AJAX + ikiwiki +
git, so it's a web front end to the repository that works off of the
combination of parts to make up new systems. Users input things in a
sort of black-box specification format, and the first version will show
possible ways to fill it in with known parts from the repository. This
isn't 3D geometrical modeling (yet) - it can be included Real Soon -
but I'm excited about the way things are moving.
> Of course, anything usable at this point would be great.
No kidding. Btw, after I replied to your email a week ago I was handed
the latest SciAm and found the OPP mention in the back of the book.
Heh.
- Bryan
________________________________________
http://heybryan.org/
Engineers: http://heybryan.org/exp.html
irc.freenode.net #hplusroadmap
Bryan Bishop
> .. lots of stuff ..
It occurs to me that I neglected to link over to some presentations on
automated design. This isn't anything about 3D modeling (which I am
dealing with separately), but instead about the search optimization
processes for finding good designs from the big pot of all possible
designs (up to some point).
http://heybryan.org/~bbishop/docs/repo/presentations/
- Brya
Bryan Bishop
> As far as the CAD stuff goes, you should be aware of Adam Kumpf's
> AvoCADo, which is XML-based. There may be some synergy there, but
> it's early in the project. He's done a lot of thinking about the file
> format, however, so maybe you could use the AcoCADo format as the
> basis, or collaborate on it.
> http://avocado-cad.sourceforge.net/
>
> I don't know if Blender or Ogre would be useful:
> http://www.blendernation.com/2006/04/27/cad-modeling-in-blender/
> http://www2.futureware.at/~philipp/BlendXML/
>
> As far as the collaboration piece, maybe your Ajax module could be
> used with Adam's files and program.
Neat. Yes, that's definitely worth me looking into more. I would much
rather use a standardized format over proprietary formats. Blender does
have a good array of importing tools, however, and I'm very grateful
for this.
By the way, I just got notification in the IRC channel of:
http://synbioss.sf.net/
It's a design tool that I was thinking of writing - guess somebody beat
me to it :-) - and what it does is takes biobricks from
http://partsregistry.org/ and puts them together into a certain circuit
design, performing some sort of function that is overall specified by
what I call "function structures" but aren't quite currently
implemented. Anyway, there's no "CAD" for proteins or for synthetic
biological circuits, yet the design information is just as important.
http://heybryan.org/~bbishop/docs/biobricks/ were my notes towards that
sort of software suite but it's obsolete for now.
Actually, the CAD might be the visualization of the overall finished DNA
molecule. I don't know - that's semantics or splicing words or
something.
Anyway, part of the problem that shows up in design, like it currently
does in the product/mechanical design repository hosted on my server,
is that the dot repo files contain sub files. These subfiles include
JPGs or PNGs, CDD (ConceptDraw), and sometimes .CAD files. The CDDs
show the "function structures" and the CAD files show 3D geometry. But
none of the information in these files are linked back to the
information in the .repo file format .. in other words, it's like the
CAD stuff is just hanging off in la-la-land, and people are expecting
the computer to spontaneously understand how to connect parts or
whatever, or even how different parts of the CAD file correlates to
different subsystems specified in the "function structure"
and "component function graph" diagrams that you were looking at (the
PNG's via graphviz's dotty etc.).
Somewhat the same even with the SynbioSS stuff I just mentioned. Less so
in that case because they have to make sure their molecules are
interacting together correctly, so they do keep track of metadata. (I
actually can't affirm this at the moment; I just learned of SynbioSS as
of 10 minutes ago and am running off to a next class shortly here.)
Anyway, I have a guy or two working on an AJAX interface for SynbioSS,
and then I recently proposed wiring up the output design files to
automated ordering/procurement software* for the vectors and plasmids,
which I hope to do the same for CAD files in some sort of unified
framework. ;-)
* For the die-hard do-it-yourself kid in me, though, this would just
export to whatever software is running the do-it-yourself DNA
synthesizer so that you just make your primers and biobrick plasmid DNA
strands on your own (though the inoculation and so on isn't yet
automated - I'm sure Big Pharma has some automated systems doing this,
but I haven't heard of them).
http://bioinformatics.org/pogo/