Dumping Ground

If you have ideas, comments, gripes, questions, or random thoughts feel free to put them here and they will be subsumed into the main roadmap where possible. Please remember to date your post

Welcome to the Dumping Ground

I think more of the chapters should have illustrative images or diagrams. Just my two cents. /samplerant

-jb on 9/23/2010

Constantly using FTDI causes issues when one needs to register a unique Vendor ID/Vendor name for their USB device. I believe you can only use the FTDI vendor info. Also, what does it cost to get a Vendor ID for a device?

DIYDrones mission planning software is quite sophisticated and has been more of the focus than the sensor payload to date.

Ardustat is an open source battery detctor/charger/experimentation platform.

Printing of battery source has been proven by Evan Malone of the Fab@HOME. Multi-layers, e.g., silicone on the outside, zinc anode, boundary, cathode, more silicon.

Fab Academy in RI - is it at the AS220?

Will success ruin open source hardware?

There is talk of a vehicleforge.mil (https://www.fbo.gov/index?s=opportunity&mode=form&id=66a0dce0a76db6edbea3a2d7fd344521&tab=core&_cview=1)

Check out the antipasto hardware blog.

Homecamp is an interesting DIY home project.

Standards, safety, and certification are massive problems.

GoGoBoard

Education is a very slow market. In terms of other market, it is very difficult to get cash/capital from banks or VC for inventory. Therefore, growth must be controlled cycles.

Check out Dangerous Prototypes

-Jim Barkley notes from OSH, 23 Sep

I just added some more notes at the URL below, and they relate to how people doing open manufacturing research might collaborate:
http://pointrel.svn.sourceforge.net/viewvc/pointrel/trunk/Pointrel20090201/redesign.txt?view=log

Just posting a copy here in case anyone is interested. It's inspired by the sort of thinking behind a DVCS like git but applied more to sharing semantic content rather than code. One big difference from regular DVCS is this idea of federating archives together to form larger virtual archives, although that may not be strictly necessary if one used a more purely git-like approach of copying everything you needed when you referred to someone else's content. Also important is the notion of transactions as being in individual files of triples, which makes merging easy at a low level (even if there may be higher level conflicts that would need to be resolved).

[Paul D.], 26 Sep

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 D., Sep. 24


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-NonCommercial 3.0 License