This package was developed over six year period where it began as a thought experiment which then turned into a real experiment which then became a set of research and development operations which then became a set of programmable utilities for 3D printing purposes and then that was re-envisioned an API / CLI python package built for open source.
In the beginning before I began development of mupy I had experienced a plethora of inefficiencies, difficulties and realities regarding research, development and manufacturing inefficiencies which were so difficult to overcome that I considered quitting engineering altogether. I have very big goals but not the kind you kind. My problem was my that I essentially needed to scale my developments on such a level and needed to build bigger systems (which could tap into efficiency of scale functions) but I lacked the time and resources to do so and when I finally did accomplish something interesting I seemed to lack the passion to guide the projects thenceforwards. I needed something new and something I could build momentum on for the rest of my life, in-fact it would be built into the project. A game changer really. I decided that I would only focus on a big goal and the requirements and through constraints to see that goal through.
Mandating an extreme set of requirements and constraints will force a good idea if it exists. If the system is required to do impossible things then it will do impossible things if built. The primary constraint and goal
- Mandate Primary Constraint : Build from nothing except what you have.
- Mandate Primary Goal : Build a city in space and everything we need to take us there.
- Mandate Primary Requirement : Build a utility which will assist in that goal.
I know this sounds crazy but it is possible and I built mupy to prove it. It is my offering. We just need to tap into efficiencies which are there and waiting to be exacted.
Project ρ (Recursive Hardware Operations) was dedicated to making better use of smaller 3D printers by researching and developing hardware with advanced modularity features.
ask if there was some set of optimal shapes / limited parts which could make it easier to print and assemble anything. The idea was borrowed from legos except that the parts would need to be designed with specific requirements in mind that would improve the quality of any assembly especially when it comes to binding and unbinding.
Imagine basic legos are provided to you along with Knex, Erector Sets and Some RoBlocks to spice the deal and imagine you were supplied enough hardware such that you could build almost anything you want say a space ship or something but you realize that the hardware is not optimized for the assembly of certain things or it could be better or something Well this was the biasses for this new approach to researching and developing modular hardware ; It was about having options to build things and a space ship was a hard test that would supply the requirements needed to make the [arts really optimal.
- Maximize Material Independence / Material Configuration
- Maximize Constructibility / Destructibility Freedom
- Minimize Manufacturing Time / Cost / Resources
- Maximize Bind-ability / Connectivity / Adaptability
- Minimize Required Tools / Assembly Time
- Maxmize Connective Hardware Count
The flagship family which represented project ρ was the CUBX0012 family. This cubic family propelled project ρ since CUBX0012 was so general purpose. It can be thought of as a family making up hardware elements which the simplest form attempted to build boxes from side panels ; a box with a cavity if cut up into six equal shapes would represent the general archetype geometry constituting CUBX0012 hardware elements. From more simple parts can more complex geometry be derived making up new types which belong to CUBX0012. CUBX0012 is currently retired but will be replaced soon.
-
Once we built the parts and tested them, we manufactured many more except and realized that we didn't actually know what to assemble and this represented a fundamental problem since it forced the decision that parts should indeed derive from design plans themselves and not the other way around ; for the sake of optimization. This violated many of the originals clauses but it also introduced a new opportunity.
-
There was no set of optimal parts that could be designed unless it had infinite permutations. The CUBX0012 family was very fun but it had its problems and in some cases was an engineering
Project ρ++ was an extension of project ρ. Just some context ; in these days the hardware 'elements' that were in the process of being developed and tested were treated as agents which expressed the ρ hardware assembly language. Some more context ; A hardware assembly language should be compared to a software programming language since that if we program software and we assemble hardware then it may be necessary to build a hardware assembly language which we would classify Legos as being.
The more complex the machinery, the smaller and more precision certain parts need to be. This seems to be a fundamental principle.
- Hardware must be schema-less ; each type should dictate it's own rules.
- Needed a command-line interface instead of programming in scad. Too many parametrizations to handle manually.
- Too many parts were required to optimize. Universal modularity clause of project rho needed to be abandoned in favor of non-universal guaranteed modularity clause since configuration freedom is too invaluable and required for optimization. We do not need to lose modularity necessarily but only require that some parts work with others generally.
Project ψ (Parametric System Instruction) was a project which explored hardware configuration, definition and assembly to it's manufacturing limit. This was the next stage in the evolution of this project.
During this time I was trying to run a business by perhaps selling these parts. At the time there was no software package. PSI was the first project which trried to bring software functions into the fold which managed the creation of renderings and organization of parts.
Project rho proved that there was no way in principle to establish a modular family which satisfied all requirements. From this the idea of the psi terminal was developed which said that some terminal should exist which takes in 'system-codes' which serve to identify a system in terms of it's properties.
- Handle parametrization better and cleaner.
- Abandon local modularity clause in favor of Why did with the creation of family codes did things need to be modular generally. Hell, even 3D printed guitar picks should be given their own systems codes since the system was built to handle it.
Project μ aimed to take a step back and generalize these technologies into a more general purpose form. There needed to exist distribution and packaging mechanisms so that people could have acces, also there needed to exist assembly information. THERE NEEDED TO EXIST
