[Hplusroadmap] Openfarmtech and an open source engineering-format in general

[Bryan Bishop]

----------  Forwarded Message  ----------

Subject: Re: openfarmtech/turbine + technology dependency trees
Date: Thursday 20 March 2008
From: ben lipkowitz <fenn at sdf.lonestar.org>
To: Marcin Jakubowski <joseph.dolittle at gmail.com>

On Tue, 18 Mar 2008, Marcin Jakubowski wrote:

> Here is another question. How far did you ever get on the Tesla 
turbine?

Not very far. I played around with several different rotors made from 
sheet metal and plastic. I got stuck on welding the diffusor scroll, 
(using a hacked microwave oven transformer!) and then I realized I 
didn't 
know much about welding or fabrication in general. This was about ten 
years ago, when I was in high school.

> Please view our work on the Solar Turbine. Dan Granett Engineering 
designed
> it. We have the complete design on the web:
>
> http://openfarmtech.org/weblog/?p=55
> http://openfarmtech.org/index.php?title=Boundary_Layer_Turbine
> http://openfarmtech.org/index.php?title=Solar_Concentrators

Looks like Granett is very far along. What do you need me for? Also, 
what 
do you need 4kW for? Starting out that big is a bad idea; you need large 
test stands and instruments, lots of power to test with, safety issues.

> Here's what I'd like to ask you. Could you help us get the Boundary 
Layer
> Turbine built? What would it cost you? We are trying to get bids on it 
right
> now. We are interested in having someone build it, we just don't have 
time
> right now as we are preparing the CEB press for production.

I'm quite an amateur machinist. I've never bid on anything before so I 
dont really know how to go about it. I'd estimate it would take about 
two 
days to build, assuming everything goes right. So, using Hofstadter's 
law 
we multiply by 2 and raise to the next unit of measurement to find the 
real amount of time needed - about 4 weeks?

Also, my lathe is 10 inch swing, so something like 9" diameter discs is 
the max I could do on it, but 6" diameter is much more reasonable.

> Please let us know if there's any way you can help on the turbine. 
Could you
> recommend someone who could do it? If you can just help us outsource 
the
> building of a prototype turbine, that would work for us as well.

I've just discovered mfg.com which is interesting in its own right. 
Also, 
I'll ask some of the guys from #emc if they can help, provided there are 
more detailed plans I can point to.

You've left a lot of engineering work up to the fabricator. For example, 
what kind of steel to use for the runners, casing, ring seal? The nozzle 
is almost completely unspecified. Why does it say 1/16 disc spacing in 
one 
place and 0.4mm in another? How much clearance is allowed between the 
disc 
seal and case?

Aside from all this, do you really want a 12" diameter turbine?

> We are also looking for a Babington burner-fired, steam generator that 
> could be used as an initial test bed of the turbine with steam 
> operation. Let me know what you think. That could be a great product, 
a 
> transformative one at that.

This part should be fairly easy. I saw something on YouTube where the 
babington burner was running directly on steam instead of compressed 
air - 
were you planning on taking this route eventually?

*clunk* (gear shifting noise)

It looks like what you're trying to do with openfarmtech is to create an 
open source hardware 'distribution' akin to debian or redhat. The reason 
these distro's work is that they have created a package format that 
specifies what each package requires and what it provides, so the 
package 
manager can automatically download and/or compile all the required 
packages for a given functionality. If you were able to 'package' or 
assimilate other open source hardware developments into a common format 
with well defined requirements and capabilities (one each for building 
and 
for running) then someone would be able to see at a glance the entire 
technology tree that they will need to build or run any given system. By 
separating build-time and run-time dependencies you allow the use of 
found 
or bought hardware and materials in the bootstrapping or experimental 
stage.

The ideal process-state of creating all necessary intermediate- and 
end-products from local raw material streams becomes simply a matter of 
examining the run-time and build-time dependency trees, and then 
eliminating bottlenecks that depend on bought materials and components. 
If 
this state were achieved it would enable completely cost-free village 
replication and exponential growth. (Assuming there are people willing 
to 
help the machines along.) Examining the tree by hand (by mind?) is quite 
possible for small levels of complexity, but for larger projects, 
without 
a mathematical representation for the 'common sense' involved, it 
quickly 
turns into running around like a chicken with your head cut off, unable 
to decide which project is currently the most important to work on. 
Traditional attempts at a solution for this problem are 1) extensive 
bureaucracy 2) politics 3) market forces. Surely we can come up with 
something better, something more intelligent.

What process was used to generate the diagrams on the openfarmtech.org 
wiki? Were they simply drawn by hand with diagramming software? The 
double-ended arrows don't illustrate the dependencies correctly.

The Debian project Just Works(tm) despite its decentralized nature 
because 
they publish standards for packaging formats, policy and procedure, and 
automatic tools that contributors can use to check their contributions 
for 
conformance. They also aggregate and assimilate independent projects 
that 
would otherwise get lost in the vastness of the net, and cherry-pick the 
most promising for further improvement. (bug triage, championing and 
mentoring) I think open source hardware needs a similar borganism.

Too much time is spent on learning similar but incompatible technologies 
(i.e. pic vs avr) and repeatedly going through the search/build/test 
cycle 
to make the project using materials on hand. A seasoned electronics Pro 
can understand a schematic at a glance and know which 
resistors/capacitors 
are critical and which can vary by 1000 percent, but the newbie has no 
idea and must slavishly follow every detail, ordering obscure parts from 
Digikey that the creator just happened to have had on hand in the first 
place. There is no framework or common language, so even if you want to 
help fix the "howto" plan, you can't. You're limited to saying "this 
worked for me, and yammer yammer yammer" it actually doesn't matter what 
you say because the builder is probably already done with the project 
and 
moved on. This is where the standardized specification format comes in.

Specifications for a machine's requirements might include:
   run-time: power, space, control | human attention, human skill, noise
     level, ventilation, lighting, safety equipment, zoning laws

   assembly: transportation, space, assembly equipment, human 
skill*hours

   build-time:
     materials: strength, flexibility, damping, chemical/wear 
resistance,
       surface finish, toxicity/outgassing,
     process: measurement and calibration tolerances, cutting 
tolerances,
       human skill*hours, safety equipment, (include assembly 
requirements)

   materials:
     purchase cost, transportation, environmental cost?, storage space,
     mass, etc

In contrast, the capabilities of a machine are rather easy to specify - 
for each operational mode: dimensional envelope, performance envelope, 
tolerances, quantities per time unit, quantity*quality per skill unit, 
other efficiencies

An important goal is to make this system usable by mortals, with a low 
learning curve for widespread adoption. We can use simple methods 
like 'on 
a scale of 0 to 9' for subjective parameters like skill or product 
quality. Skill levels could be organized in a tree fashion, perhaps with 
a 
handy interactive survey/calculator to determine you skill level in a 
particular area. However, since most contributors will be technically 
literate, we should require a basic level of objective performance and 
requirements measurements regarding the machine itself.

So, you see, an open source hardware package is more than just 
specifying the dimensions of all the parts and taking pictures of the 
finished product.

Is there a mailing list or something? Can I really just go ahead and 
unscramble the wiki? I do have "my own village" so this is not just an 
intellectual exercise.

   -fenn

-------------------------------------------------------
________________________________________
Bryan Bishop
http://heybryan.org/
----------  Forwarded Message  ----------

Subject: Re: openfarmtech/turbine + technology dependency trees
Date: Thursday 20 March 2008
From: Bryan Bishop <kanzure at gmail.com>
To: ben lipkowitz <fenn at sdf.lonestar.org>

Looks good, but I have to run off to school, will put some thought into 
this today. The immediate problem I note is that wihle we can come up 
with linear programs to represent problems, like moving an arm and so 
on, the fundamental problem is that these programs are necessarily 
linear while the true representation of the 3D existence of the arm is 
much more parallel, that the number of possibilities for satisfying the 
arm is much greater than the amateur is willing to look into. I think 
we should black box it all.

- Bryan
________________________________________
Bryan Bishop
http://heybryan.org/

-------------------------------------------------------
________________________________________
Bryan Bishop
http://heybryan.org/