Roadmap for Open Hardware (ohroadmap.org)
Bryan Bishop
Jim Barkley from MITRE was speaking at Open Hardware Summit the other
day and threw up a website for roadmapping activity. You can find the
wiki here:
Jim: mind posting an introduction to the open manufacturing group
about yourself & your goals? What is your background in open hardware-
CAD, legal, sales, infrastructure, etc.?
James - Coder by day, fabber by night
How have I missed this Google Group for so long?!
I am a software engineer and researcher working for The MITRE
Corporation (www.mitre.org), a non-profit corporation managing 5
Federally Funded Research & Development Centers (FFRDCs). We work
exclusively for the federal government and our charter is "working in
the public interest". We are often cited for our technical
objectivity.
For the last two years I have been researching Additive Manufacturing
technologies, among other things. I am an active participant in ASTM
F42 and have authored multiple papers and articles on the subject. A
somewhat self-serving example can be found at
http://www.mitre.org/news/digest/advanced_research/08_10/layer.html.
We also attempted last year to create a web-based, one-click printing
architecture from a Ruby on Rails web server to an ethernet-adapted
Cupcake CNC (code available at http://github.com/makeone/makeone) with
limited success.
This research has segued into open source hardware and potentially
emergent agile systems engineering methods (I know, that's a
mouthful).
My goal with the www.ohroadmap.org wiki is to develop a technology
roadmap which identifies current and future technologies in open
hardware/open manufacturing as well as technology gaps, barriers,
industry targets, and research areas. I have decided to do this as a
public wiki because:
A) I wish to share the results of my work in real-time with the OH
community in hopes that it helps establish a stronger sense of
identity (and destiny?)
B) I wish to share my results with others in hopes of educating the
uninitiated and accelerating adoption and development of OH
technologies and practices
C) There are many, many people more knowledgeable on the subject than
me, and I hope by crowd-sourcing it I can get a higher quality end
result while giving people a chance to contribute to a formal
document.
-jb
> 1 512 203 0507
Bryan Bishop
Greetings,
How have I missed this Google Group for so long?!
Hopefully we can provide some value to you :-).
We also attempted last year to create a web-based, one-click printing architecture from a Ruby on Rails web server to an ethernet-adapted Cupcake CNC (code available at http://github.com/makeone/makeone) with limited success.
Huh. A few of us on this list have been working on a project called SKDB akin to "apt-get for hardware"- i.e., apt-get make a thing.. there's a git repository here:
git clone git://diyhpl.us/skdb.git
or http://github.com/kanzure/skdb for a mirror
.. there are also some youtube videos floating around somewhere, like on:
http://gnusha.org/
I've been meaning to do a demo of someone hooking up a RepRap or MakerBot or some other 3D printer to the system, but it's hardly restricted to just 3D printing. The core concept is packaging open source hardware projects into a format- somewhat like the concept of a .deb or .rpm package- and then interface with standard CAD tools for manipulation, collaboration, sharing, etc.
Were you aiming to make makeone more like "firmware" or as a intranet application for queuing up jobs for a printer? I haven't looked through your rails code yet but was it just a place to upload STL files and a web-like version of skeinforge (or something)?
This research has segued into open source hardware and potentially emergent agile systems engineering methods (I know, that's a mouthful).
My goal with the www.ohroadmap.org wiki is to develop a technology roadmap which identifies current and future technologies in open hardware/open manufacturing as well as technology gaps, barriers, industry targets, and research areas. I have decided to do this as a public wiki because:
I am definitely interested in collaborating on a roadmap for open source hardware, if you're interested. However, there were a few issues on the wiki that I took note of, that didn't really seem to be like the roadmap that I have been thinking of, so I hopefully my perspective will be of some value. Standardization in the open source hardware community is pretty important :-) and also outlining where volunteers can help, or where interesting pockets of communities are, is valuable.
John Griessen
> For the last two years I have been researching Additive Manufacturing
> technologies, among other things. I am an active participant in ASTM
> F42 and have authored multiple papers and articles on the subject. A
> somewhat self-serving example can be found at
> http://www.mitre.org/news/digest/advanced_research/08_10/layer.html.
For your 3D file format standardization work, XML is proposed. XML
by itself is useless and can bog things down if not used well -- you
need a very carefully defined DTD to do good. The DTD needs to have a name
to reflect its purpose and there might need to be several DTDs that use
the same super-set XML the army wants for its data, just to simplify
the data down to cases like milling/subtractive or plastic-additive or
metal-additive. So then the army's super data form would be a DTD called
warfighting-component-manufacture and the other subset ones would have names like
STEP-milling-subtractive, STEP-thermoplastic-additive, STL-milling-subtractive,
STL-thermoplastic-additive, for instance.
It is best to not force the use of XML and instead support lossless
translation between whatever XML format you choose for the army and the
defacto standards the rest of the world uses and evolves, because even
with an open wiki and great community comments, the community will keep
on evolving things faster than the army and government procurement could
ever keep up with or align with, since the community has a wider mission
including "for the joy of doing things", than the army. XML is not human
readable. Most of the best defacto standards have some human readability
and can be text edited for some minor changes or tests or double checks.
That readability is a good thing.
> This research has segued into open source hardware and potentially
> emergent agile systems engineering methods (I know, that's a
> mouthful).
Yes, it's not the kind of wording you see describing defacto standards
that are used in fabbing today, suggesting a for-the-army system again.
John Griessen
former Hughes Aircraft product engineer
currently systems engineer, gEDA user, HeeksCAD user, manufacturer
James Barkley
On Fri, Sep 24, 2010 at 11:46 AM, Jim Barkley wrote:Greetings,
How have I missed this Google Group for so long?!
Hopefully we can provide some value to you :-).We also attempted last year to create a web-based, one-click printing architecture from a Ruby on Rails web server to an ethernet-adapted Cupcake CNC (code available at http://github.com/makeone/makeone) with limited success.
Huh. A few of us on this list have been working on a project called SKDB akin to "apt-get for hardware"- i.e., apt-get make a thing.. there's a git repository here:
git clone git://diyhpl.us/skdb.git
or http://github.com/kanzure/skdb for a mirror
.. there are also some youtube videos floating around somewhere, like on:
http://gnusha.org/
I've been meaning to do a demo of someone hooking up a RepRap or MakerBot or some other 3D printer to the system, but it's hardly restricted to just 3D printing. The core concept is packaging open source hardware projects into a format- somewhat like the concept of a .deb or .rpm package- and then interface with standard CAD tools for manipulation, collaboration, sharing, etc.
Were you aiming to make makeone more like "firmware" or as a intranet application for queuing up jobs for a printer? I haven't looked through your rails code yet but was it just a place to upload STL files and a web-like version of skeinforge (or something)?
This research has segued into open source hardware and potentially emergent agile systems engineering methods (I know, that's a mouthful).
My goal with the www.ohroadmap.org wiki is to develop a technology roadmap which identifies current and future technologies in open hardware/open manufacturing as well as technology gaps, barriers, industry targets, and research areas. I have decided to do this as a public wiki because:
I am definitely interested in collaborating on a roadmap for open source hardware, if you're interested. However, there were a few issues on the wiki that I took note of, that didn't really seem to be like the roadmap that I have been thinking of, so I hopefully my perspective will be of some value. Standardization in the open source hardware community is pretty important :-) and also outlining where volunteers can help, or where interesting pockets of communities are, is valuable.
James Barkley
On 09/24/2010 11:51 AM, James - Coder by day, fabber by night wrote:For your 3D file format standardization work, XML is proposed. XML
For the last two years I have been researching Additive Manufacturing
technologies, among other things. I am an active participant in ASTM
F42 and have authored multiple papers and articles on the subject. A
somewhat self-serving example can be found at
http://www.mitre.org/news/digest/advanced_research/08_10/layer.html.
by itself is useless and can bog things down if not used well -- you
need a very carefully defined DTD to do good. The DTD needs to have a name
to reflect its purpose and there might need to be several DTDs that use
the same super-set XML the army wants for its data, just to simplify
the data down to cases like milling/subtractive or plastic-additive or
metal-additive. So then the army's super data form would be a DTD called
warfighting-component-manufacture and the other subset ones would have names like
STEP-milling-subtractive, STEP-thermoplastic-additive, STL-milling-subtractive,
STL-thermoplastic-additive, for instance.
It is best to not force the use of XML and instead support lossless
translation between whatever XML format you choose for the army and the
defacto standards the rest of the world uses and evolves, because even
with an open wiki and great community comments, the community will keep
on evolving things faster than the army and government procurement could
ever keep up with or align with, since the community has a wider mission
including "for the joy of doing things", than the army. XML is not human
readable. Most of the best defacto standards have some human readability
and can be text edited for some minor changes or tests or double checks.
That readability is a good thing.Yes, it's not the kind of wording you see describing defacto standards
This research has segued into open source hardware and potentially
emergent agile systems engineering methods (I know, that's a
mouthful).
that are used in fabbing today, suggesting a for-the-army system again.
John Griessen
former Hughes Aircraft product engineer
currently systems engineer, gEDA user, HeeksCAD user, manufacturer
--
You received this message because you are subscribed to the Google Groups "Open Manufacturing" group.
To post to this group, send email to openmanu...@googlegroups.com.
To unsubscribe from this group, send email to openmanufactur...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/openmanufacturing?hl=en.
Bryan Bishop
> On 09/24/2010 11:51 AM, James wrote:
>> For the last two years I have been researching Additive Manufacturing
>> technologies, among other things. I am an active participant in ASTM
>> F42 and have authored multiple papers and articles on the subject. A
>> somewhat self-serving example can be found at
>> http://www.mitre.org/news/digest/advanced_research/08_10/layer.html.
>
> For your 3D file format standardization work, XML is proposed. XML
> by itself is useless and can bog things down if not used well -- you
To be fair, there are a lot of problems with XML. But it's not
entirely useless. There are worse fates, sir :-).
> It is best to not force the use of XML and instead support lossless
> translation between whatever XML format you choose for the army and the
> defacto standards the rest of the world uses and evolves, because even
Are you talking about the STL2/XML standard? I am sure it's entirely
possible to transform that data into the tessellations for STL.
>> This research has segued into open source hardware and potentially
>> emergent agile systems engineering methods (I know, that's a
>> mouthful).
>
> Yes, it's not the kind of wording you see describing defacto standards
> that are used in fabbing today, suggesting a for-the-army system again.
What? Agile systems engineering and related buzzwords are used
throughout the manufacturing industry. I don't particularly like the
buzzwords, granted..
- Bryan
John Griessen
>> It is best to not force the use of XML and instead support lossless
>> translation between whatever XML format you choose for the army and the
>> defacto standards the rest of the world uses and evolves, because even
>
> Are you talking about the STL2/XML standard? I am sure it's entirely
> possible to transform that data into the tessellations for STL.
Not STL2, just in general, I'd like to see decent defacto standards
supported with some way to translate from and to them losslessly
up to some point. If you have too much data in your XML schema for
manufacturing a part, such as a full bill of materials for the system
it goes in, it would be perceived as bogging down usability by a
fab shop. Then you would do a one way lossless translation to
the form the fab shop wants.
The constructive thing to consider
with standards that are new is to also add the good features to the existing
data formats also so you can translate back and forth. One way to
do that is put the extra features in as comments in one of the formats
you are translating to. and with enough info to extract them from comments
and put back in the original format.
On 09/24/2010 02:18 PM, James Barkley wrote:
> Troll the new guy? If you want to discuss the proposed xml file format, please move that discussion to
> http://groups.google.com/group/stl2 but not before having your voice heard by taking the widely publicized survey about AM file
> formats at http://www.mae.cornell.edu/lipson/stl2.htm
I'm interested in discussing 3D formats in general, not just STL2.
I'll give that a look. I'm ignorant of it, and a newbie as far as STL and STEP.
From what I understand STL is a final output form useful for creating tool-paths from,
but not good for refining a design since it does not save any primitive geometry
and has no chance of parameterized anything like STEP does.
Is STL2 not limited that way?
John
Paul D. Fernhout
> My goal with the www.ohroadmap.org wiki is to develop a technology
> roadmap which identifies current and future technologies in open
> hardware/open manufacturing as well as technology gaps, barriers,
> industry targets, and research areas.
Here is a rambling sketch of some ideas related to reusability of open
hardware designs that seeing your Wiki and your description makes me think
about.
http://www.ohroadmap.org/
This is also inspired in part from watching the Open Hardware Summit
streamcast that Bryan posted about, where one participant (possible Eric von
Hippel?) said there were three big competing issues:
* project
* product
* platform
Each of these three (project, product, platform) may have different
requirements or social approaches from an open manufacturing perspective.
The issue of reusability of designs (especially when all you have is CAD or
CAM files) is something that has been in the back of my mind for a long
time, considering the fact that things created by hand often are adapted to
materials at hand as well as quirky circumstances. Or at least, that's
tended to be my own experience. :-) I often scrounge around for things and
adapt designs to materials, tools, and subcomponents that I have easily
available. I may iterate that process several times, too, as solutions fail
to be good enough. So, even having detailed 3D designs may not be that
useful to me, unless I had everything I needed to put together an entire
complex product. That assuming a design wasn't just all printed as a working
unit from some amazing nanotech printer, which remains a ways off -- and
even then, we would probably need to sometimes think in terms of "repair" or
"improvement" with scrounging whatever was on hand.
Here is an example inspired by your link to this with a picture of a couple
of tanks in a desert:
http://www.mitre.org/news/digest/advanced_research/08_10/layer.html
Consider that image, in the context of product, project, and platform.
I'm personally not very interested in building tanks, as a "product". Tanks
(or, say, even just self-propelled Howitzers) are a product that is probably
illegal for me to own, at least if it had live ammo. And even it was legal,
a tank would be expensive to build and maintain, and having one around might
worry my neighbors a bunch and mess up the driveway. :-) Related by me:
"Intrinsic/mutual security vs. extrinsic/unilateral"
http://slashdot.org/comments.pl?sid=1783364&cid=33537044
Likewise, I'm not interesting in using a tank to do anything in a desert as
a "project". Those are typically projects that, as my sig below suggests, I
consider a likely example of "irony". :-) Also rlated by me:
http://www.pdfernhout.net/recognizing-irony-is-a-key-to-transcending-militarism.html
But tanks have a lot of brackets, and I've very interested in brackets in
general (as a "platform" in at least two senses of the word. :-) That's as a
platform to hold things up, and also a platform in a general sense of
software that might help design brackets to specific needs.
So, I have a common interest with someone who designs tanks. Brackets are
just really, really, important in life. :-) I mean, where would be be
without brackets? Everything would be one big jumble. :-)
When I was a kid, my father (a merchant mariner, a machinist, and then a
manufacturing engineer), made brackets for me for some robots I made. But
now, sadly, he's not around (a casualty to heart disease -- preventable it
turns out, with the Fuhrman nutritional plan and adequate vitamin D, but I
did not know that back then).
So how do I get custom brackets made on demand? Any tank designer must have
the same problem, or at least the design side of that problem even if other
people did the manufacturing.
I could say, look through any non-secret part of a public tank design, and
hope to get lucky with something that meets my needs for, say, putting up a
bookshelf.
"World War II AFV Plans: American Armored Fighting Vehicles"
http://www.amazon.com/World-War-II-AFV-Plans/dp/0811733408
But, in practice, a bracket with specific dimensions made out of a specific
material in a specific shape used in a specific tank to hold a specific item
is probably useless to just about anyone else (except by chance). And even
if it was a very good design for a similar circumstance, how would you find
it out of all the other bracket designs out there? And chances are, the
design for some specific things, like a tank, may just not be shared,
anyway, even if, as above, you might find some old designs around to some
degree of detail.
The logical process that goes into creating an appropriate bracket for
holding an item at a particular position might be generalizable to some kind
of "bracket design" software tool. Give it some constraints, and it might
create you some candidate brackets to consider. Possibly it might do this in
an interactive and evolutionary way -- perhaps of like this software (we
wrote) for breeding 3D models of botanical plants, but for brackets? :-)
http://www.kurtz-fernhout.com/PlantStudio/
My father like probably most people who are handy with tools and have many
decades of experience making stuff, essentially could do that quickly, maybe
with a bit of paper and pencil work. But not everyone is so fortunate as to
have someone like that around for a time.
There probably is proprietary software already out there that does this,
like in AutoLISP for AutoCAD? But I'd guess that most everyone still goes
through these motions every time:
"Tutorials on Basic Mechanical Design Calculations (part-1) "
http://www.brighthub.com/engineering/mechanical/articles/15234.aspx
"Today I will talk about design of a simple �L� shaped bracket, one side of
it is clamped and at the other side it is carrying some amount of load. ..."
But even if there were proprietary software to do this, it doesn't help me
personally much, because I'm not going to pay a bunch of money just to
design one bracket right now. And chances are, the software runs with other
proprietary software I don't have, either.
So, one might see that FOSS bracket software tool as part of an open
"platform" for design. Same for wire routing tools, diagnostic system test
point insert tools, documentation for maintenance generation tools, viewport
design tools, and so on. If someone wants to design a new type of vehicle,
like a SpacePod,
http://code.google.com/p/openvirgle/wiki/SpacePod
well, one might hope it might eventually be a lot easier and go a lot faster
using these tools that together make up some kind of open hardware design
platform. And then many of the same tools could be used for, say, creating
book shelves stuck on a wall that have brackets. And there's no reason to
have just the 3D CAD output in a design file. You could have a reference to
the module you used to design a bracket, and the parameters you used, so
anyone getting that design could still easily tweak it a bit at the
parameter level.
From a mass production standpoint, customization of every vehicle is
insanity. Why would a big organization want, say, 1000 vehicles each with
custom parts designed by end users to scratch some specific itch (customized
seats?) that were not interchangeable? Wasn't it a huge leap forward to have
interchangeable parts? Still, if you were 3D printing the parts at a
practically-zero-inventory repair depot that could essentially fix any
vehicle, then what does it matter if parts are custom? Also, if you had, as
discussed recently on the list, a really good recycling system, someday, if
you are really annoyed at a certain vehicle's customization, you just
recycle the whole thing locally and produce a new one. Or, if you have have
a vehicle, adapted by its users in various ways that you want to keep and
bring back into good repair, and you have the CAD files about it, then you
just print the customized broken part. You might also have automatically
generated instructions created directly from the design for troubleshooting,
disassembly, repair, and re-assembly, which a technician could use, perhaps
guided by graphics displayed on reality by a wearable computer with a heads
up display? :-) The repair could even be logged and then fed back into
design software... Thus you have a very adaptive fleet of vehicles... Ones
that are even flexible reconfigurable. A historic example: :-)
http://en.wikipedia.org/wiki/Improvised_vehicle_armour
One key emotional point is that people customizing their equipment probably
will be motivated to understand it better and probably to take better care
of it, because it will be "theirs" in that sense. For a story about a world
of customized products, see:
http://en.wikipedia.org/wiki/The_Mote_in_God%27s_Eye
Or for more on the emotional aspect of humans as makers, see my comments
building on Mark Frauenfelder's:
http://groups.google.com/group/openmanufacturing/msg/70fec0838320517b
Of course, to create a good platform allowing mass customization may be a
lot more work (or, at least, different work) than doing specific projects or
creating specific products. Related to this is the notion that it is easy in
software to create a class for an "object" in object-oriented programming.
But to create a generally reusable class to create broadly usable objects
(probably with some parameters specified at creation time) generally takes
many times more work than to just create a specific "class". That's why, in
practice, "reuse" of software has not been as great as expected.
My father, Klaas Fernhout, the bracket maker (among other talents), as a
native Dutch speaker, preferred "Klaas" be pronounced different from
"class", more like the a sound in "hah" (so, customized pronunciation
compared to a typical English speaker?) But both Klaas and a class are
related in this context by being able to make things. :-) So, I want a class
that can do what my father, Klaas, could do as far as generate brackets on
demand to handle all the unique constraints of the moment. Or, more likely,
that might take a set of classes that cooperated while maybe generating sets
of designs that competed, all to help someone do what my father, Klaas,
could do in his head and with scribbling a bit of paper. :-) Granted, I can
expect eventually software tools will do bracket design "better" in some
sense than my father (though perhaps never with as much love. :-)
Now, from a narrowly defined business perspective that's where it ends.
There is essentially no point on any specific project for making reusable
classes, and tools go in and out of fashion, so investment in any platform
is problematical by a specific company (unless you are selling that platform
yourself). Who in their right mind would write a piece of software that
helps people design arbitrary brackets? Unless you were going to sell that
stand-alone program as a proprietary product -- in which case most people
probably can't use it. Or unless some big organization who saw the value of
such tools paid you to do that (and then you promptly abandoned it and went
on to other new grant-funded things, keeping it artificially scarce just in
case you might make a bit more money from it someday).
Related:
http://www.pdfernhout.net/on-funding-digital-public-works.html
And, likewise, for programs, we get programming methodologies like extreme
programming that design and implement everything just-in-time. And that can
be a very useful approach for a "project" or even a "product" (especially
since figuring out the true "requirements" is often most of what any project
entails). But such an ad-hoc just-in-time approach is more problematical for
a "platform" that needs to support many projects and products. To make a
good platform, you usually have to consider a lot of different cases, to see
what you can generalize from them.
However, from an open source perspective, the above may just be the
beginning, not the end. If a lot of people are engaged in using an open
platform, than it may make sense for people to keep improving different
things so each is generally reusable, with each person or team working on a
different module, and the modules somehow working together as a common
platform used to make products for projects. Someone who cares a lot about
nice looking functional elegant brackets is going to work really hard on a
parametrized bracket design module. Maybe it can't design every bracket, but
it could do a lot of them. This approach might not work well if everything
was proprietary (and also written to assume different data formats), but
this approach might work very well if everything was free and open source.
It might help if such a platform used a common semantic web infrastructure
too, so communications about design discussions (including determining needs
and priorities) could be integrated in with each design. Related Wikipedia
item (and a comment by me):
http://en.wikipedia.org/wiki/Semantic_Web
"Raising the bar to supporting a Social Semantic Desktop"
http://groups.google.com/group/diaspora-dev/msg/8410682ec9ca87ee
So, the platform then is really supporting an incremental design "process"
as well as an end-product manufacturing "process". So, maybe we need a
fourth "P" word up at the start, for "process"? :-) And a more
process-oriented view of open manufacturing might link up with efforts like
this at NIST:
"Sustainable and Lifecycle Information-based Manufacturing"
http://www.nist.gov/mel/msid/dpg/slim.cfm
Eventually, we might end up with "designs" that were even just a collection
of reusable software tools and related parameters, like an electric motor
design tool linked to a bracket design tool, where you could scale the whole
thing to fit some need -- produced within a total lifecycle analysis process.
Now, this is not to say *everything* in a design should be a reusable
software tool to generate specific things. There may well be some categories
of things like brackets, porthole creation, wiring, and so on that relate
more to ad hoc interfacing, whereas some other items (a gyroscope? a CPU?)
might be more carefully designed items that you are connecting into a system
just as they are mass produced. One of the very first 3D CAD software, Ivan
Sutherland's SketchPad, worked in terms of constraints, which are somewhat
similar to parameterized modules.
http://en.wikipedia.org/wiki/Sketchpad
"The main idea was to have master drawings which one could instantiate into
many duplicates. If the user changed the master drawing, all the instances
would change as well. Another major invention in Sketchpad was that it let
the user easily constrain geometric properties in the drawing�for instance,
the length of a line or the angle between two lines could be fixed."
So, any real system would probably be a mix of these things, the fixed and
the variable. And any very generic design that was scalable might well have
both types of definitions and be scalable within some range. So, for
example, you might be able to scale a space probe up and down within some
range until the point where one gyroscope was not powerful enough to orient
the craft at an acceptable rate. At that point, you'd have to revisit the
design to replace that component in the design or make other changes.
(Integrating simulation would help a lot in analysis.) Over time, as 3D
printing improves, more and more of various open hardware designs might be
made generic in this fashion. For example, shoes.
"I just reprapped a left shoe. It cost me 30 pence..."
http://blog.reprap.org/2008/05/shoe.html
It seems that a big promise of open manufacturing is the flexibility to make
a variety of products to support ad hoc projects or custom fits. But to make
the most of that flexibility may involve creating a different sort of
platform than one supporting a more conventional design process where the
focus is on just one mass-produced product.
And then once you've specified what you want, scaled as you need it and
maybe adjusted for local materials and local processes, then you go ahead
and generate specific CAM files, and have it fabricated (like with SKDB).
Then, when it breaks, you either recycle it or print a custom part again or
even an adapter to hold a different part.
So, the bigger picture on open manufacturing of open hardware is that the
entire design process may eventually change leading to different products
maintained in different ways. And we probably want to be creating
infrastructures for that sort of overall dynamic social design,
manufacturing, performance analysis, and repair process. But, granted, that
big picture may be different than any one specific institution with narrow
objectives may be seeing when it looks at just one part of the open
manufacturing picture.
==
By the way, the license for the ohroadmap Wiki "Creative Commons
Attribution-NonCommercial 3.0 License" is not compatible with Wikipedia.
That may not matter to you, but it is something to consider. Personally, I
find "non-commercial" clauses problematical, because it's never clear what
is commercial and what is not (a teacher getting paid to teach about open
manufacturing seems to me to be commercial, for example). You might ask
yourself if there any particular reason you want that license as opposed to
one that is compatible with Wikipedia?
http://en.wikipedia.org/wiki/Manufacturing
--Paul Fernhout
http://www.pdfernhout.net/
====
The biggest challenge of the 21st century is the irony of technologies of
abundance in the hands of those thinking in terms of scarcity.
James Barkley
On 09/24/2010 02:31 PM, Bryan Bishop wrote:Not STL2, just in general, I'd like to see decent defacto standards
It is best to not force the use of XML and instead support lossless
translation between whatever XML format you choose for the army and the
defacto standards the rest of the world uses and evolves, because even
Are you talking about the STL2/XML standard? I am sure it's entirely
possible to transform that data into the tessellations for STL.
supported with some way to translate from and to them losslessly
up to some point. If you have too much data in your XML schema for
manufacturing a part, such as a full bill of materials for the system
it goes in, it would be perceived as bogging down usability by a
fab shop. Then you would do a one way lossless translation to
the form the fab shop wants.
The constructive thing to consider
with standards that are new is to also add the good features to the existing
data formats also so you can translate back and forth. One way to
do that is put the extra features in as comments in one of the formats
you are translating to. and with enough info to extract them from comments
and put back in the original format.
I'm interested in discussing 3D formats in general, not just STL2.
On 09/24/2010 02:18 PM, James Barkley wrote:
> Troll the new guy? If you want to discuss the proposed xml file format, please move that discussion to
> http://groups.google.com/group/stl2 but not before having your voice heard by taking the widely publicized survey about AM file
> formats at http://www.mae.cornell.edu/lipson/stl2.htm
I'll give that a look. I'm ignorant of it, and a newbie as far as STL and STEP.
From what I understand STL is a final output form useful for creating tool-paths from,
but not good for refining a design since it does not save any primitive geometry
and has no chance of parameterized anything like STEP does.
Is STL2 not limited that way?
John
John Griessen
> Now you're making a lot more sense to me! I agree with most of what you say here, although the XML problems that people have are
> often quite debatable, including your fear of file size bloat due to additional information or additional encodings.
I'm not afraid of the size, but the debuggability of it. XML is OK and probably beneficial for
data translating, I just would not want it as the only way -- abbreviated XML codes like YAML
are getting used by the gEDA project... Some open source code might not survive
switching to it -- there might not be enough volunteer time to adapt it...
> Is STL2 not limited that way?
>
>
> STL2 is much less limited in the way it stores geometry. While NURBs and parametric functions aren't specified in the current
> version, it does not preclude them from becoming part of the standard now. One of the primary goals was to keep it straightforward
> to increase the chance of adoption, so stl-style triangle meshes can be included, but it also has many other geometric features -
> such as curved triangles - that make it achievable to obtain much higher curvature resolution with a much smaller mesh. Anyway,
> read the spec for yourself (it's pretty short, and a good read) at http://ccsl.mae.cornell.edu/sites/default/files/AMF_V0.45.pdf
OK.
John G
James Barkley
"Today I will talk about design of a simple “L” shaped bracket, one side of it is clamped and at the other side it is carrying some amount of load. ..."
"The main idea was to have master drawings which one could instantiate into many duplicates. If the user changed the master drawing, all the instances would change as well. Another major invention in Sketchpad was that it let the user easily constrain geometric properties in the drawing—for instance, the length of a line or the angle between two lines could be fixed."
So, any real system would probably be a mix of these things, the fixed and the variable. And any very generic design that was scalable might well have both types of definitions and be scalable within some range. So, for example, you might be able to scale a space probe up and down within some range until the point where one gyroscope was not powerful enough to orient the craft at an acceptable rate. At that point, you'd have to revisit the design to replace that component in the design or make other changes. (Integrating simulation would help a lot in analysis.) Over time, as 3D printing improves, more and more of various open hardware designs might be made generic in this fashion. For example, shoes.
"I just reprapped a left shoe. It cost me 30 pence..."
http://blog.reprap.org/2008/05/shoe.html
It seems that a big promise of open manufacturing is the flexibility to make a variety of products to support ad hoc projects or custom fits. But to make the most of that flexibility may involve creating a different sort of platform than one supporting a more conventional design process where the focus is on just one mass-produced product.
And then once you've specified what you want, scaled as you need it and maybe adjusted for local materials and local processes, then you go ahead and generate specific CAM files, and have it fabricated (like with SKDB). Then, when it breaks, you either recycle it or print a custom part again or even an adapter to hold a different part.
So, the bigger picture on open manufacturing of open hardware is that the entire design process may eventually change leading to different products maintained in different ways. And we probably want to be creating infrastructures for that sort of overall dynamic social design, manufacturing, performance analysis, and repair process. But, granted, that big picture may be different than any one specific institution with narrow objectives may be seeing when it looks at just one part of the open manufacturing picture.
==
By the way, the license for the ohroadmap Wiki "Creative Commons Attribution-NonCommercial 3.0 License" is not compatible with Wikipedia. That may not matter to you, but it is something to consider. Personally, I find "non-commercial" clauses problematical, because it's never clear what is commercial and what is not (a teacher getting paid to teach about open manufacturing seems to me to be commercial, for example). You might ask yourself if there any particular reason you want that license as opposed to one that is compatible with Wikipedia?
http://en.wikipedia.org/wiki/Manufacturing
--Paul Fernhout
http://www.pdfernhout.net/
====
The biggest challenge of the 21st century is the irony of technologies of abundance in the hands of those thinking in terms of scarcity.
Paul D. Fernhout
> On Fri, Sep 24, 2010 at 6:29 PM, Paul D. Fernhout<
> pdfer...@kurtz-fernhout.com> wrote:
>> Here is a rambling sketch of some ideas related to reusability of open
>> hardware designs that seeing your Wiki and your description makes me think
>> about.
>> http://www.ohroadmap.org/
>
> Just wanted to say thanks for the thoughtful reply - it took me awhile
> to get through it all! Informative and thought-provoking, yet
> entertaining and, at times, outright funny.
You're welcome.
Thanks for the inspiration.
Glad someone gets some of my jokes. :-)
I think I'd already forgotten that I wrote that, I've written so much in
other contexts in the meanwhile. :-)
Reading it over, I see a striking omission. :-) That is, it may be more
important to focus on *standards* for representing and exchanging content
than on creating the content itself. It's kind of implicit in the document,
but I don't think it is stated explicitly. And it is a theme that has come
up here several times. Here it is reprised about Diaspora, an anti-Facebook
effort, where I quote someone else quoting someone else: :-)
http://groups.google.com/group/diaspora-dev/msg/17cf35b6ca8aeb00
"As someone else said yesterday, having an 'HTTP' for social media would be
more important than having an 'Apache' for social media." "
One may ask the same question about open manufacturing? Do we need an HTTP
(and XML etc.) of open manufacturing, an Apache of Open Manufacturing, or a
Wikipedia/Facebook/SKDB/OSCOMAK/whatever of open manufacturing?
===
Also, here:
http://www.ohroadmap.org/table-of-contents
I don't see a line item for a survey of existing efforts...
===
Also, could comment more on why you picked the license you did for the
ohopenroadmap.org discussions, as that might be interesting to discuss as
far as shaping a community? Given CC-BY-NC has a non-commercial clause, it
is incompatibly with Wikipedia, and may pose issues with various companies
using related content if it extends to 3D designs. I'm not saying you should
change your license, I'm just trying to understand your reasoning for the
choice and how you expect it will influence community participation.
I know the NC option is a very popular choice for creative commons,
especially bands that want to put their music out there to the public but
get a cut it if gets resold. I can't find it right now, but a couple of
months ago I saw a graph of the frequency that different options were
chosen, and I was surprised how NC was more common than not.
Related issue though:
"Does the Noncommercial Creative Commons license make sense?"
http://news.cnet.com/8301-13556_3-9823336-61.html
http://wiki.creativecommons.org/DiscussionDraftNonCommercial_Guidelines
For me, being able to take content from Wikipedia or move content to
Wikipedia seems like, in theory, a big issues. Likewise for Appropedia:
http://www.appropedia.org/Welcome_to_Appropedia