Re: [hackerspaces] Possible HackerSpace Hardware Inv. Software
Bryan Bishop
> Hi everyone,
> I saw this the other day when just randomly poking around. It looks pretty
> nice and can be self hosted.
> Is anyone here already running it? If so how do you like it??
>
> http://www.opensourcerails.com/projects/51989-Hardware-Inventory
Looks neat. Nick's suggestion to use thingiverse is spot-on. But if
you want an open source version of thingiverse that you can host
locally, maybe this can help:
http://github.com/kanzure/skdb/
In particular see the web/web.py file. There's no inventory system
built in yet, but it's certainly planned.
Sam Putman
Do you think you could link to a functioning web install of SKDB,
something that demonstrates any degree of utility however minimal?
A thingiverse killer should at least have a demo site, right?
-Sam.
Bryan Bishop
Ha, very well. Let me turn on a few servers.. try this?
Of course, the main function is *not* a website (it's actually
supposed to be like "apt-get").
Sam Putman
Root.default(virtual_path=('share',), keywords={})
cmd is:
virtual path is: ['share']
b/c I still have that MakerBeam YAML file somewhere, and there's more
documentation coming.
If I can't figure out how to use SKDB, or at least be convinced that
it's on its way to useful, I can't very well use SKDB to package the
MakerBeam project.
Perhaps some things have changed behind the scenes, and there may be
something I'm not seeing here. But it looks like the same old SKDB
that you had in august, which is to say, it doesn't do anything and
has no database to speak of.
What needs to happen to change that? I have a test project: several
objects, including a screw fer crikey's sake, which have various
materials, file formats for description, and dependencies. It needs to
be packaged up somehow; if I can't do SKDB I'm just going to accept an
inferior but gorrramit functional alternative like Thingiverse or an
awkward tarball.
I also volunteered to work on packaging the periodic table of
elements, and was told that this would be a waste of time. A
perspective I don't share, given that absolutely everything material
is built from said elements, but there you have it.
I'm willing to be the 'package maintainer' for MakerBeam and do the
work of getting the files straight, but I'm somewhat discouraged in
that: there appears to be no instructions at all as to how to do this,
it appears that no one including the two project heads has added new
packages in a long time, and the code base has evolved only minimally
and displays no function at present.
I'm worried that this project won't ever get past the puff-pieces and
presentations on YouTube stage, basically. SKDB or something like it
is an absolutely necessary part of the ecosystem, but the question
remains: when are we going to see SKDB 1.0? Or even a stable release
that does something?
-Sam.
Bryan Bishop
> So when I click on "share", something should happen? other than this:
No. Right now the only thing that should work is "packages". In
particular the best example is the "lego" package:
http://heybryan.org:8081/package/
http://heybryan.org:8081/package/lego/
> b/c I still have that MakerBeam YAML file somewhere, and there's more
> documentation coming.
I don't know if I remember that or if I'm getting it confused with
something else. It's not just YAML files that makes everything work..
look around in the lego example and see how there's a catalog of parts
(data.yaml), but also tools to help figure it all out (lego.py) and do
"sense checking". To package something up you're going to have to
start with a skeleton- like the lego example- and work from there.
> If I can't figure out how to use SKDB, or at least be convinced that
> it's on its way to useful, I can't very well use SKDB to package the
> MakerBeam project.
To be honest, you don't have a reason to use skdb because you're
buying all of your parts. It's easier for you to just go manually
order parts from your suppliers. For projects with parts from multiple
suppliers and potential replacement parts that may or may not be
compatible, that's where skdb starts to get useful.
> Perhaps some things have changed behind the scenes, and there may be
> something I'm not seeing here. But it looks like the same old SKDB
> that you had in august, which is to say, it doesn't do anything and
> has no database to speak of.
Yes, I am terrible at naming things. It's not a database. It's apt-get
for hardware. It does part mating, compatibility and some crude
dependency resolution. You use it by typing "skdb-get.py lego" or
whatever it is that you're trying to physically get.
> What needs to happen to change that? I have a test project: several
> objects, including a screw fer crikey's sake, which have various
> materials, file formats for description, and dependencies. It needs to
> be packaged up somehow; if I can't do SKDB I'm just going to accept an
> inferior but gorrramit functional alternative like Thingiverse or an
> awkward tarball.
So what's stopping you from typing in MakerBeam dependencies into an
SKDB package? If you have already done this, then I have completely
forgot and need to be linked again to these files. :-)
> I also volunteered to work on packaging the periodic table of
> elements, and was told that this would be a waste of time. A
> perspective I don't share, given that absolutely everything material
> is built from said elements, but there you have it.
Who told you it was a waste of time?
> I'm willing to be the 'package maintainer' for MakerBeam and do the
> work of getting the files straight, but I'm somewhat discouraged in
> that: there appears to be no instructions at all as to how to do this,
There are no instructions, but there are some examples. Maybe you
would like to help write the instructions since you know what it is
that you don't know and would find helpful?
> it appears that no one including the two project heads has added new
> packages in a long time, and the code base has evolved only minimally
There's a microfluidics, openeeg, and cubespawn package that are
relatively recent in comparison to the "originals". They aren't as
developed though :-).
> and displays no function at present.
Are you on Windows or something? That would explain a lot.
> I'm worried that this project won't ever get past the puff-pieces and
> presentations on YouTube stage, basically. SKDB or something like it
> is an absolutely necessary part of the ecosystem, but the question
> remains: when are we going to see SKDB 1.0? Or even a stable release
> that does something?
Dunno, but I can't do everything on my own. It's really just been me
for the past 6 months.
John Griessen
> Ha, very well. Let me turn on a few servers.. try this?
>
> http://heybryan.org:8081/
>
> Of course, the main function is *not* a website (it's actually
> supposed to be like "apt-get").
>
Would a wep app interface for admin and entering data fit with your SKDB plans?
John
Sam Putman
> On Wed, Jan 20, 2010 at 12:32 PM, Sam Putman wrote:
>> So when I click on "share", something should happen? other than this:
>
> No. Right now the only thing that should work is "packages". In
> particular the best example is the "lego" package:
>
> http://heybryan.org:8081/package/
> http://heybryan.org:8081/package/lego/
>
Okay, well you have one user clamoring for the "share" functionality
as of now. Please don't ask me to write it myself :-)
>> b/c I still have that MakerBeam YAML file somewhere, and there's more
>> documentation coming.
>
> I don't know if I remember that or if I'm getting it confused with
> something else. It's not just YAML files that makes everything work..
> look around in the lego example and see how there's a catalog of parts
> (data.yaml), but also tools to help figure it all out (lego.py) and do
> "sense checking". To package something up you're going to have to
> start with a skeleton- like the lego example- and work from there.
>
So I'm going to need to write some python to make this work?
I am not thrilled at that prospect, offhand. Why can't I describe the
relevant data using YAML?
>> If I can't figure out how to use SKDB, or at least be convinced that
>> it's on its way to useful, I can't very well use SKDB to package the
>> MakerBeam project.
>
> To be honest, you don't have a reason to use skdb because you're
> buying all of your parts. It's easier for you to just go manually
> order parts from your suppliers. For projects with parts from multiple
> suppliers and potential replacement parts that may or may not be
> compatible, that's where skdb starts to get useful.
>
This is a serious misunderstanding of the project.
Aluminum extruders are not generally in the screw manufacture
business, nor do either of these types of suppliers generally do
stamping, plastic extrusion, injection molding or any of the other
specialized types of manufacture used in bulk manufacture of MakerBeam
components.
Also, wherever possible we are offering parts files for construction
using our available rapid-fab technologies. An example would be the
beam itself: if you need a small section of MakerBeam, with light-duty
tolerances for strain and proportions, you can take the STL file for
the beam itself and print one.
Or take the brackets. Currently our Alpha brackets are being cut on a
ShopBot with a vacuum hold-down system. We're in the process of
getting some of the brackets stamped, and working on laser-cutting the
rest. That's three ways to make a given bracket, depending on how much
you want to invest up-front, the choice of material, and available
machinery.
We need the "buy" and "make" buttons. That's why SKDB is interesting to us.
>> What needs to happen to change that? I have a test project: several
>> objects, including a screw fer crikey's sake, which have various
>> materials, file formats for description, and dependencies. It needs to
>> be packaged up somehow; if I can't do SKDB I'm just going to accept an
>> inferior but gorrramit functional alternative like Thingiverse or an
>> awkward tarball.
>
> So what's stopping you from typing in MakerBeam dependencies into an
> SKDB package? If you have already done this, then I have completely
> forgot and need to be linked again to these files. :-)
>
Because you have provided no documentation other than idiosyncratic
example files, basically. I made a YAML file, as I've indicated, and
saw no work done in return. I have no idea how to write up
dependencies in a useful way, and I'm not a python programmer.
>> I also volunteered to work on packaging the periodic table of
>> elements, and was told that this would be a waste of time. A
>> perspective I don't share, given that absolutely everything material
>> is built from said elements, but there you have it.
>
> Who told you it was a waste of time?
>
So there's no confusion, this was the exact quote:
"anyway none of this gets us any closer to having the entire ASTM catalog
of alloys and polymers available. might as well just start writing up
random facts about your favorite alloy. "
If this is how Ben feels about the project of documenting the periodic
table, I can't expect a lot of support in doing so.
>> and displays no function at present.
>
> Are you on Windows or something? That would explain a lot.
>
I run a modified BSD distribution with a proprietary user interface
called Cocoa.
I can produce a terminal on command. However, it's been two full
decades since the 1980s and a program without a usable graphic
interface is strictly weak sauce. I'd prefer that it be web based,
since a) it's better and b) you consistently tout this as a
Thingiverse killer, but a reasonably well-done Jython skin would do.
Furthermore, Windows still commands the largest installed user base.
If Windows users can't use it, you have a pretty big case of fail.
> Dunno, but I can't do everything on my own. It's really just been me
> for the past 6 months.
>
> - Bryan
>
Well I can't write your program for you, for a variety of reasons.
What happened to Ben, wasn't he a big part of the SKDB team?
I can work on packages, but I'm hesitant to put the work in without
some sense that it's all turning in to something usable.
Is there a roadmap? Because if it's just you, then documenting what
the project is supposed to become, in detail, would seem to be a
crucial element in getting SKDB off the ground.
I see no alternative to SKDB at present. I remain concerned that it
will never condense out of the vapors.
-Sam.
Bryan Bishop
Oh, certainly. It's just that I didn't want people to get the wrong
idea. The website already has some tools implemented to let people
enter data:
http://heybryan.org:8081/package/lego:master/metadata.yaml
Sam Putman
Okay, so editing existing files is implemented. Great!
Can you add functionality for uploading and editing new files and
projects? Or is it on there somewhere already?
-Sam.
Vitaly Mankevich
> particular the best example is the "lego" package:
>
> http://heybryan.org:8081/package/
> http://heybryan.org:8081/package/lego/
This thread has some demonstrations and explanations of the lego package:
http://groups.google.com/group/openmanufacturing/browse_thread/thread/9542e9680bb0bc71
I don't know if things have advanced since then, but if my
understanding is correct, this basically works like so:
metadata.yaml has generic lego definitions, including "peg" and "hole"
interfaces
lego.py implements Lego class inherited from SKDB Part class (returns
list of "peg" or "hole" interfaces)
grammar.yaml has specific definitions of lego features and their
complements (e.g. stud/anti-stud)
interfaces.py implements Feature class inherited from SKDB Interface
class (in particular compatibility check)
data.yaml has definitions of fundamental lego bricks which includes
list of features and their relative coordinates
xxxxx.stp files define geometry of fundamental bricks (STEP format)
dimensions.yaml describes dimensions of lego system and common
formulas (.stp files would have to match?)
Python scripts then create virtual lego bricks and manipulate them in
3D space, such as generate all possible combinations of how they can
fit together; this is all displayed using pythonOCC.
I'm not sure if this description is accurate but I also feel that more
details would be beneficial for anyone who would potentially want to
SKDB-package their project. Digging through the code and figuring out
the SKDB classes and principles of how packages should be structured
can help but I don't feel these examples are self explanatory.
> There are no instructions, but there are some examples. Maybe you
> would like to help write the instructions since you know what it is
> that you don't know and would find helpful?
Is there a description of what SKDB classes are, what the hierarchy
is, what methods are available etc?
Bryan Bishop
>> No. Right now the only thing that should work is "packages". In
>> particular the best example is the "lego" package:
>>
>> http://heybryan.org:8081/package/
>> http://heybryan.org:8081/package/lego/
>
> This thread has some demonstrations and explanations of the lego package:
> http://groups.google.com/group/openmanufacturing/browse_thread/thread/9542e9680bb0bc71
>
> I don't know if things have advanced since then, but if my
> understanding is correct, this basically works like so:
Your overview is spot-on. There are a few details that I'll emphasize.
But in general this is great, thanks so much. Now I know what people
are capable of discerning by digging around a little, and I'll provide
the other 50% and write up some documentation soon to supplement.
Let's see here:
> metadata.yaml has generic lego definitions, including "peg" and "hole"
> interfaces
Yes, but even more importantly, it includes the dependency information
(see near the bottom of the file). You can make legos by solid
freeform fabrication, 3D plastic squirting, plastic injection molding-
so it's represented in the metadata.yaml file.
> lego.py implements Lego class inherited from SKDB Part class (returns
> list of "peg" or "hole" interfaces)
That's right- in the case of the "screw" package, the Screw class
provides some standard methods like check_compatibility, max_force,
breaking_force- though these methods aren't appropriate for the Lego
class, so they weren't written. (Maybe check_compatibility should be
added, but that's what the "interface.py" file in the lego package
helps with).
> grammar.yaml has specific definitions of lego features and their
> complements (e.g. stud/anti-stud)
That's lego-specific, it was fenn flexing his creative muscles a bit.
The screw package doesn't have a "grammar" defined in YAML- instead
the Screw class takes on some responsibilities:
http://designfiles.org/packages/screw/screw.py
In contrast, lego/grammar.yaml is taken advantage by lego/interfaces.py:
http://designfiles.org/packages/lego/interfaces.py
> interfaces.py implements Feature class inherited from SKDB Interface
> class (in particular compatibility check)
The compatibility check is very important, but yes.
> data.yaml has definitions of fundamental lego bricks which includes
> list of features and their relative coordinates
a "catalog"
> xxxxx.stp files define geometry of fundamental bricks (STEP format)
Btw, in the future those could be dynamically generatede since skdb
and pythonOCC are playing together.
> dimensions.yaml describes dimensions of lego system and common
> formulas (.stp files would have to match?)
Eh, those are my leftover notes in that file :-(. Maybe it can be
incorporated into the Lego class some day for making "does this make
sense" checks? (check_compatibility maybe?)
> Python scripts then create virtual lego bricks and manipulate them in
> 3D space, such as generate all possible combinations of how they can
> fit together; this is all displayed using pythonOCC.
Yes.
> I'm not sure if this description is accurate but I also feel that more
> details would be beneficial for anyone who would potentially want to
> SKDB-package their project. Digging through the code and figuring out
> the SKDB classes and principles of how packages should be structured
> can help but I don't feel these examples are self explanatory.
Well, you've definitely given me a lot to work off of. I think that
based off of what you've told me, I should work on an example where
there is a dependency tree, so that the "you need x before y" can be
emphasized, and then the meaning of everything else in the packages
should fall out of the tree from there.
>> There are no instructions, but there are some examples. Maybe you
>> would like to help write the instructions since you know what it is
>> that you don't know and would find helpful?
>
> Is there a description of what SKDB classes are, what the hierarchy
> is, what methods are available etc?
There's a small architecture file:
http://designfiles.org/skdb/doc/architecture
But this isn't what you want. To be honest I've been stuck trying to
come up with a clean way to generate formatted tutorials (not
doxygen/epydoc/sphinx stuff).
I like to use bpython to figure out what methods are available.. it's
slightly faster than always using help() and dir() and such.
http://bpython-interpreter.org/
But it's no excuse for not having documentation.
Thanks a million Vitaly! We need more people like you keeping me in
line and on track.
Christian Siefkes
Sam Putman wrote:
> Perhaps some things have changed behind the scenes, and there may be
> something I'm not seeing here. But it looks like the same old SKDB
> that you had in august, which is to say, it doesn't do anything and
> has no database to speak of.
>
> What needs to happen to change that? I have a test project: several
> objects, including a screw fer crikey's sake, which have various
> materials, file formats for description, and dependencies. It needs to
> be packaged up somehow; if I can't do SKDB I'm just going to accept an
> inferior but gorrramit functional alternative like Thingiverse or an
> awkward tarball.
There also is the Tangible Bit project <http://tangiblebit.com/> Smári
McCarthy and me (among others) are working on. It's in a very early
stage--almost no code yet, only design, but if you want to take a look, you
can check it out at http://www.tangiblebit.com/tangiblebit.git .
> I'm willing to be the 'package maintainer' for MakerBeam and do the
> work of getting the files straight, but I'm somewhat discouraged in
> that: there appears to be no instructions at all as to how to do this,
> it appears that no one including the two project heads has added new
> packages in a long time, and the code base has evolved only minimally
> and displays no function at present.
For Tangible Bit, the object system is described in the file
doc/objects.rst|html (in the gitball). It's still somewhat in flux (and
hence cluttered with TODO notes), but the basics are clear and should be
relatively stable. There also is a sample package (sample/ directory) --
packaging Lady Ada's Drawdio <http://www.ladyada.net/make/drawdio/> tool,
including instructions for making and using it.
Comments from your site--if this is helpful, what you would make different
etc.--are welcome. That goes for everyone else working on free hardware too.
> So I'm going to need to write some python to make this work?
>
> I am not thrilled at that prospect, offhand. Why can't I describe the
> relevant data using YAML?
That--and also that Bryan seems to be difficult to work with--are probably
the main reasons that skdb and Tangible Bit are different projects, with
similar aims but different approaches. In Tangible Bit, we try to do
everything declaratively--no coding required.
Best regards
Christian
--
|------- Dr. Christian Siefkes ------- chri...@siefkes.net -------
| Homepage: http://www.siefkes.net/ | Blog: http://www.keimform.de/
| Peer Production Everywhere: http://peerconomy.org/wiki/
|---------------------------------- OpenPGP Key ID: 0x346452D8 --
The difference between theory and practice tends to be very small in
theory, but in practice it is very large indeed.
Bryan Bishop
> On Wed, Jan 20, 2010 at 11:18 AM, Bryan Bishop wrote:
>> On Wed, Jan 20, 2010 at 1:15 PM, John Griessen wrote:
>>>> Ha, very well. Let me turn on a few servers.. try this?
>>>>
>>>> http://heybryan.org:8081/
>>>>
>>>> Of course, the main function is *not* a website (it's actually
>>>> supposed to be like "apt-get").
>>>
>>> Would a wep app interface for admin and entering data fit with your SKDB
>>> plans?
>>
>> Oh, certainly. It's just that I didn't want people to get the wrong
>> idea. The website already has some tools implemented to let people
>> enter data:
>>
>> http://heybryan.org:8081/package/lego:master/metadata.yaml
>
>
> Can you add functionality for uploading and editing new files and
> projects? Or is it on there somewhere already?
At the moment, there's a hidden upload file feature, it wouldn't be
hard to expose it to the web. On the other hand, the quickest way for
anyone else to upload a file at the moment would be to just commit it
to the git repository and push the repo to whatever is hosting the web
environment.
Bryan Bishop
> similar aims but different approaches. In Tangible Bit, we try to do
> everything declaratively--no coding required.
I'd like to go on the record supporting those ideas, and wish you'd
talk about them more frequently.