2008-04-18

From Biohack

Jump to: navigation, search

Basically: the fabrication lab needs to be interfaced to a linux server; the materials need to be specifically characterized, there needs to be a driver interface to all of the available manipulators -> also, it should be known that in general you can either have (1) humans to manipulate the materials or (2) the machines to manipulate the materials (however, you do not necessarily have the machines already, so you might have to bootstrap some of the components).


The packages in sdkb would have to use some API to either add calls to the manufacturing environment or be code that is executed on demand (call package->makeCode.py->someFunction, a standardized name that must be used, kind of like the __main__ symbol). These calls would be to a generalized interface so that the users do not have to explicitly care whether or not their exact hardware is the same hardware implementation as the programmers of the original package. This would mean that (1) drivers for all of the implemented, local hardware in somebody's fabrication laboratory / shop would have to be able to take requests from the common API layer for manufacturing, and (2) the packages in skdb would have to either (1) specify code exactly to send requests to that manufacturing API layer, or (2) be written in a programming language of sorts that can be ran to control the instruments. It's likely that this language can be python too. The code would simply control the movements of the machine (or call upon other preprogrammed movements from other locations in the database).


Autospec evaluation of the metadata would just be for units and making sure that the final product is technically feasible. Everything else involves the grounding problem (which is much greater than a simple ai symbol-meaning grounding problem) --- and this requires package management in the locality/context of the user and his machinery. Given no machinery, then human-readable instructions have to be provided so that the person can follow a walkthrough step-by-step to make the requisite machinery (of course, this might be particularly difficult if the final project is defined as using silicon and other finely processed wafer technologies, he'd have to follow through many technologies etc., but there are many projects that users could follow directly .... such as instructions for folding a paper airplane).


Are there any open source prosthetic/mechanical arm/manipulator projects out there? That would be useful. But the API layer that we need just needs to be able to specify what machinse should be able to do and what the programmers are allowed to request. This gets rather complicated when the tool providers also need to implement interfaces to the "API layer" so that they can physically interact with a user's linux system for the fab-lab. Hm. Grounding issue. :)


Re: this requires package management in the locality/context of the user and his machinery ---> This means actually physically managing the materials that are available, either automatically or by specifying instructions for users to do to move the materials to the right locations. Go look at the print-services on linux networks -- it's an active daemon in the background that manages machinery on the network, this is pretty close to that. This will introduce a very large variability into the user's environment-space ... on a debian installation for example, there's only a finite number of ways that things can be arranged and organized, but in this environment this is not necessarily true, so something has to give.


  • NMDA-receptor-dependent synaptic plasticity: multiple forms and mechanisms --- Robert C. Malenka
Retrieved from "http://heybryan.org/mediawiki/index.php/2008-04-18"
Personal tools