Re: [Discuss] discuss Digest, Vol 10, Issue 106

[Bryan Bishop]

On Tue, Mar 26, 2013 at 11:56 PM, Matt Maier <blueb...@gmail.com> wrote:
> Releasing the source is only half the battle.

But... you just said you don't even have that (source files). "It
wasn't even completely planned out." Do the CAD files even correspond
to the actual machine? Maybe it would be better to use the prusa
reprap models as an example instead, or the parameterized reprap
source files. You guys have a lot of technical debt. To be fair, so
does RepRap-- Sebastien has been using a very similar "put everything
on the wiki" strategy, although RepRap has a huge community of other
contributors, including those parameterized source files to define the
3d printable parts.

- Bryan
http://heybryan.org/
1 512 203 0507

[Matt Maier]

Maybe I should make it explicitly clear that I'm much more of a HARDware guy than an electronics or software guy, so I tend to think of things in terms of metal and motors. I can see how maybe guys who primarily think in terms of wires or boolean could misinterpret my poorly-formed illustrations.

The confounding thing about physical projects is that they cannot be simulated in any relevant sense of the word. Sure, if you're an expert, and you have a lot of capital invested in tools, you can generate accurate simulations for most features of a hardware project before you build it. I actually talked to the technical lead in charge of DARPA's VehicleForge project, which is specifically directly millions of dollars into the pie-in-the-sky dream of a software tool that can simulate a cyber-electro-mechanical system so accurately that it doesn't need to be prototyped...and he isn't confident that it's even possible. 

So, that being my background thought process, no the LifeTrac CAD isn't available or up to date, but no that doesn't matter. When something gets so far out of the computer that it requires welding you are beyond the ability of "source files" to be anything other than helpful. The records of a machine always have to be updated with all of the little things that you ACTUALLY did when you built it. If you were to give someone the original files, the ones that haven't been updated based on reality, they would not be getting a description of what the thing actually is.

That's a huge part of why HARDware projects are lagging behind. It's not enough just to design the thing. After all of the work is done you have to go back and edit your design records to reflect what you actually ended up building. That can easily turn into an extremely unfriendly cost/benefit ratio when you need to record one change but it affects a dozen different records.

Anywho, the LifeTrac was an example of a barely-open project. So, if you have problems with it, that's probably because I picked an example with a lot of illustrative problems on purpose.

Should hardware documentation be parameterized whenever possible? Absolutely. Was OSE (at the time) rushing to try to publish a batch of instructions by Christmas? Absolutely. Was the LifeTrac documentation out of date even before it was published? Again, absolutely. Do we need some better options that most of the community can standardize on? I think the answer is absolutely. 

[Bryan Bishop]

On Wed, Mar 27, 2013 at 12:23 AM, Matt Maier <blueb...@gmail.com> wrote:
> Maybe I should make it explicitly clear that I'm much more of a HARDware guy
> than an electronics or software guy, so I tend to think of things in terms

Have you considered learning both? It's a pretty useful area to look into.

> The confounding thing about physical projects is that they cannot be
> simulated in any relevant sense of the word. Sure, if you're an expert, and
> you have a lot of capital invested in tools, you can generate accurate
> simulations for most features of a hardware project before you build it. I

"capital invested in tools".. yes, that's what we're building here.
But we were not specifically talking about simulations. I think
simulations are useful and important, although they seem to be
something that can't be planned from day one without undue burden
(unfortunately).

> actually talked to the technical lead in charge of DARPA's VehicleForge
> project, which is specifically directly millions of dollars into the
> pie-in-the-sky dream of a software tool that can simulate a

I, too, just like almost everyone else here, wrote a proposal for
VehicleForge... we all saw each other in that chatroom that they ran
for DARPA-BAA-10-86, I think that was on 2010-08-31. I think Makerbot
even had some people writing a proposal on that one.

> cyber-electro-mechanical system so accurately that it doesn't need to be
> prototyped...and he isn't confident that it's even possible.

I hear they awarded the contract to some people who are in way over
their heads; like if you go check out the site, they just have a zip
file that you can download with some poorly drawn doodles or
something. All of those cyber-electro-mechanical-simulation features
aren't even present, nor any of the version control stuff (although, I
might be misremembering and maybe that was something I included in a
proposal, but it wasn't explicitly required). Really disappointing
pick.

I wonder how iFAB is going.

> So, that being my background thought process, no the LifeTrac CAD isn't
> available or up to date, but no that doesn't matter. When something gets so

Heck yeah it matters... that's the whole point of GVCS! The 50
replicable machines? Remember :-(...

> far out of the computer that it requires welding you are beyond the ability
> of "source files" to be anything other than helpful. The records of a
> machine always have to be updated with all of the little things that you
> ACTUALLY did when you built it. If you were to give someone the original

Have you considered that you should spend more time thinking about how
to plan your machines, so that you don't have to modify it every time
you use it ? What is the actual use case that is happening here? Maybe
we can help you make the process less awful.

> That's a huge part of why HARDware projects are lagging behind. It's not
> enough just to design the thing. After all of the work is done you have to
> go back and edit your design records to reflect what you actually ended up

Huh? How is that any different from any other field? I have to update
hardware schematics and files all the time, just like I make
modifications to my source code on software projects. Same with
genetic engineering projects.

> building. That can easily turn into an extremely unfriendly cost/benefit
> ratio when you need to record one change but it affects a dozen different
> records.

Yep. That's completely worth doing. Yes, it takes time.

> Anywho, the LifeTrac was an example of a barely-open project. So, if you
> have problems with it, that's probably because I picked an example with a
> lot of illustrative problems on purpose.

Okay. Understood.

[John Griessen]

On 03/27/2013 12:23 AM, Matt Maier wrote:
> Maybe I should make it explicitly clear that I'm much more of a HARDware guy than an electronics or software guy, so I tend to
> think of things in terms of metal and motors.

When something gets so far out of the computer that it requires welding you are beyond the ability of "source files" to be anything
> other than helpful. The records of a machine always have to be updated with all of the little things that you ACTUALLY did when
> you built it. If you were to give someone the original files, the ones that haven't been updated based on reality, they would not
> be getting a description of what the thing actually is.

This is saying revisions should be easy. The infrastructure for that is a defined place for every
kind of part description, so one can go to it quickly.

> It's not enough just to design the thing. After all of the work is
> done you have to go back and edit your design records to reflect what you actually ended up building. That can easily turn into an
> extremely unfriendly cost/benefit ratio when you need to record one change but it affects a dozen different records.

You want a document to be parametric. Leo outlining editor comes to mind, but that is fairly unknown
and probably hard to promote. Some kind of hyperlink for every dimension or feature of a part design
seems too much. I'd say openly searchable in text, and with a style that helps find parameters
and change at once is all we could spec. Having some decent GPL'd 3D CAD tool will suggest how to
write a style manual for OSHW publications.

> To sum up: hardware projects are more complicated because more variables have to be accounted for if
> the instructions are to be correct. It is currently possible to capture that complexity
> and to store it on Github, but it is not possible to interact with it
> in a way that allows for the project to be "truly" open.

Are you wanting a GUI driven app? Like a Windows app? I'd like one too, but what will it do? If
too much is specified for it to do, it will not get written.

At this early stage, and with an OSHW documentation JAM session in a month, I'd just like to ask
for names that describe categories of essential documents well. To start out, we'll all use the chosen names
in our own ways -- some will buy GUI apps to use them, I'll arrange project dirs with those names
and set up makefiles to help with development repetitive steps.

I came across something new that might help. Datasheets and circuit layouts are graphics which often
include text as a graphic so it is not searchable or automatable. Here is a project to define
circuits in words that could help get past that: http://phdl.sourceforge.net/1.0/index.php

I have not dug into it, but it could have some value as an example of connecting parts together.
Today the standard for small to medium circuits is a visual schematic drawing, and for larger ones
descriptions in Verilog or VHDL.

How do you arrange reams of data needed to make a piece of lab gear, or a car? I'm not sure, but
text files sorted into categories is the obvious starting point. So what are the best category names?

Maybe later a recording can be used with one button press to load a robot assembly line and start
making things from such arranged data.