wakoma / nimble Goto Github PK
View Code? Open in Web Editor NEWThe nimble. An open source, rapidly deployable, wireless mesh network.
License: CERN Open Hardware Licence Version 2 - Strongly Reciprocal
The nimble. An open source, rapidly deployable, wireless mesh network.
License: CERN Open Hardware Licence Version 2 - Strongly Reciprocal
This issue related to an external project (CAD query) but is necessary for the Nimble Smart Docs
... we need to fix all the errant references to `tray` throughout the codebase. I think the "tray" naming convention came from me during the hackathon, but Wakoma uses the term "shelf", so we should fix the codebase to use that term. An example can be found [here](https://github.com/Wakoma/nimble/blob/master/mechanical/components/cadquery/tray_6in.py).
Originally posted by @jmwright in #58 (comment)
The code base uses both tray and shelf. Tray in the codebase also appears to have two meanings. Some times it means the whole shelf. Sometimes the shelf is divided up into the "front plate" and the "tray". Where the front plate is both the actual front plate and also any of the base that sits between the legs, whereas the tray is everything that sits entirely behind the legs (except in some cases when certain code switches are off.. which adds to confusion).
I think we need to:
New designs for M6 screws by @drayde
Pros: M6 will fit standard (EU) server racks.
Cons: M6 screw holes on 6in shelves looks odd
Idea: build screw hole customizer.
For example which type of shelf should be used.
For core hardware this can be a quick CAD model of the device. For less common hardware we can create an approximate rendering from the dimensions and if available the front and back ports.
This issue describes a task that forms part of the Nimble smart doc project funded by the NLNet foundation. This work will enable work within this project but will happen in the GitBuilding repository
As discussed here #14 (comment)
cadquery scripts should only be executed using cq-cli or cqgi https://cadquery.readthedocs.io/en/latest/cqgi.html
This currently affects only this code
nimble/doc_generator/server/nimble_server.py
Lines 117 to 129 in a1540a2
When this is done, we can get rid of the if statement for imports in cadquery scripts like this one:
We need to make sure that the correct data is available to each step of generating the hardware and instructions. A first approximation is that the following data is needed for the three main steps:
I think the easiest way to do this is some sort of heptarchical object-based structure. Very simplistically this will look somewhat like:
This way the orchestration can:
We found in OpenFlexure that most of out failures in the field that required re-printing were due to tapping plastic holes with machine screws. The following solutions worked well for us:
This JSON data should be data that is contained in the database, and could have been extracted from the database
I have just notices we are committing the STLs to the repo. STL files can get large and as Git clone pulls the entire history this very quickly turns into a project that can only be contributed to by people with good internet connection. Something we cannot ensure Nimbe contributors will have. OpenFlexure had this issue, it made it almost impossible to work on the repository in Africa.
Is the idea to commit all the legacy nimble files as STLs then remove them as we make parametric ones? Or are these the new generated ones? f they are they have no business being in a repo and should be purged from the history with BFG and we should be using CI to generate them
Can we have a meeting to discus the repo?
We have started to discuss adding fasteners to assemblies, specifically metric screws to install components into shelves, and screws to mount the shelves into the rack. It looks like there is only one complete generator library at this time, and that is cq_warehouse. It does other things besides fasteners, but I doubt we need any of the other parts it generates.
The alternative is to generate our own fasteners, but there is a surprising amount of nuance in fasteners that can make them tedious to create.
We already had plans for the community to be able to suggest new devices for the web interface. This works well when there is available hardware that is not currently in our database. However, if we consider the option where someone has a very niche (perhaps DIY, customised, or regionally available) device they want a shelf for. It would be great if they could generate a custom shelf directly in the configurator web interface.
For example the most simple one would be if you select custom you get a form to add the dimensions of the device and it makes a zip tie shelf. We could even add an option where mounting holes for the shelf are specified, but this would be a bit more complex.
Currently the information for how each individual shelf is built is held ad-hoc in a set of functions in tray_6in.py
. Some of this information is needed for other parts of the orchestration.
For example if the shelves are broad they need to be a added into the rack before the top is put on. Therefore the instructions need to be different.
We will need some way of holding the information for the shelves in a way that it can be polled without having to run the script the builds the shelf.
Is it possible to enhance the readme or perhaps add another file with more information on the hardware required for things such as mounting?
For example, what are you using to attach the shelves to the rack, what are you using to mount the intel nuc to the nuc shelf, netgate to the netgate shelf, and so on.
Screws or bolts? Size recommendations?
Any insight would be useful. Love this project and the work you are doing
Jergin
To uniquely identify each Nimble Configuration we need to have some sort of unique "hash" for that configuration.
We first need to understand exactly what the possible configurations are. The way we currently pass the components into the orchestration is a list of the devices in the order they go into the rack.
I think we will also want a way to add rack options. Options like the screw sizes, or the total rack height to match the peli-case/container being used (we can pad out the excess with stuff shelves, or blanking plates).
I think our inputs are then:
{
"devices": [
"device_id1",
"device_id2",
"..."
],
"parameters": {
"parameter1": "value1",
"parameter2": "value2"
}
}
Are there other things we will need?
We can just add these as a string (with parameters sorted as @jmwright has in example code) or we can pass them into a hashing function. My gut feeling is to lass it into a hashing function to keep the names shorter, but it may also obscure them.
I think that the hashing should be a property method of the NimbleConfiguration
class. The way I see it working is that the server or any other generation script can generate a configuration object as:
from nimble_orchestration.configuration import NimbleConfiguration
config = NimbleConfiguration(['NUC10i5FNH', 'Raspberry_Pi_4B'], parameters={"rack_height":21})
hash = config.hash
From here the server/script can check the build directory if a zip is available with a matching hash. If not it can use OrchestrationRunner
to create everything that is needed and zip it up.
See original comment here.
At some point we probably want to move the generate functionality into the nimble_orchestration module so we don't have do do weird path things. generate.py can then basically become a 2-3 line script.
This was in reference to the following line of code in nimble_server.py
.
sys.path.append(os.path.dirname(__file__) + "/..")
There is a lot of inconsistent naming through the repository probably as it has been written by lots of people guessing the answers to some questions below.
@ericnitschke What are your opinions on:
@jmwright may have some more questions.
Things to do:
Our doc-strings in the Python code are currently pretty ad hoc. We can make far better code documentation if we use standardised formatting such as that used by ReadTheDocs.
During the hackathon we were limited to SVG output (outlines and hidden lines only). After seeing the renders on the field dissection microscope (a variant of the OpenFlexure microscope) on Experiment.com, I developed a Gist that provides a method of outputting similar PNG renders from CadQuery.
I have two questions:
We could use a mix of SVG and PNG depending on the situation (SVG for views where hidden lines need to be seen, or with exploded views listing the parts). We could also just decide to use one or the other.
The Gist I provided above is not complete (no camera or image size control), but I can push it forward and work on getting it integrated into CadQuery if there is interest.
I realize that the
LICENSES
directory had several licenses in it. However, I and others use aLICENSES
directory for hardware projects because there is no single license that properly covers documentation, hardware, and software. So you end up with three licenses for the project, with a clarification in the README.Mention of multiple licenses in the readme (scroll down to bottom of the readme for the licenses section)
People also seem to be passionate about licenses, and license changes can be contentious.
Originally posted by @jmwright in #62 (comment)
New design for attaching any* hardware to a shelf.
The parameters in nimble_builder
are either hard coded or repeatedly specified in different files. Now we have a RackParameters class we should be using this to define hole sizes.
We need to
Hi Guys do you need some suggestions regarding the Openess of this project? CERN OHL 2.0 (S or W might fit best) or other License might be best, currently I could not find a License file/note.
Where would I find the Source files (so far the stl is mesh not CAD based format)?
I'm working within the context of Open Source Ecology and the Open Culture agency within South Sudan, Uganda and other regions, might be very interesting to collaborate.
We should be able to update the devices.json file in the repo directly from NocoDB so that it serves as an open data backup as well as being useful to the project.
A CI script can automate checking if it is out of date.
See #77
suggestion for the shelves, could we use Velcro in addition or in place of zip ties? I suggest this as if you use zip ties and want to change the device on the shelf then you would have to cut the zip tie in order to change the device out. however, if Velcro was used then all you would have to do would be to undo the Velcro and then change the device out and then re Velcro the device to the shelf. granted this would all be dependent of local use of the system and how "rough" the environment is.
This relates to #40 and #33. For some Networking hardware we will have STEP files. For others we will need to use a placeholder model that stands in the assembly documentation and final model.
would be good to know the colour, basic shape and size. Extra information like port positions etc would be a bonus, but not something we should aim for at first.
Once #79 is merged the setting of what configuration options are held in the UI will be the job of gen_nimble_conf_options.py
Currently this shows everything, even though some cannot create a shelf. We should probably:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.