wakoma/nimble

The nimble. An open source, rapidly deployable, wireless mesh network.

nimble's Issues

Add annotation and png Export functionality to CadQuery

This issue related to an external project (CAD query) but is necessary for the Nimble Smart Docs

Create scripts for CAD assembly and assembly steps

Add GH Action to build CAD into STLs

GH Action to build temp. static site

Nimble needs a logo

At the OTFN hackathon we are thinking about logos. We need one better than my awful misspelled attempt:

Leg rotation not constrained

In the current design of the legs, they are free to take any rotation.

I think adding extra screws would be bad but it might be worth adding a raised rim on two sides of the leg on the bottom to constrain the legs rotation

Is it a tray or a shelf!?

          ... 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:

• Do some naming standardisation in the existing repo
• Make a little diagram to explain the naming
• Enforce naming when doing code review

M6 Screw Prototype Shelf & Legs

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.

Add needed assembly and render infromation to database

For example which type of shelf should be used.

Implement final UI

Create scripts to render outline of hardware for assembly images

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.

Create basic back-end server that can run CadQuery and GitBuilding when passed data from UI

Add GitBuilding Syntax for for top-down modular hardware

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

cadquery scripts should be executed using cq-cli or cqgi

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

	import cadquery as cq
	from mechanical.components.cadquery.rack_leg import make_rack_leg
	# Generate the rack leg
	leg = make_rack_leg(length, hole_spacing, long_axis_hole_dia, mounting_holes_dia).cq()
	# Figure out what the file name and temporary path should be
	export_file_name = "leg_length-" + str(length) + "_hole_spacing-" + str(hole_spacing) + "_long_axis_hole_dia-" + str(long_axis_hole_dia) + "_mounting_holes_dia-" + str(mounting_holes_dia) + "." + model_format
	export_path = os.path.join(tempfile.gettempdir(), export_file_name)
	# If the leg does not already exist, export it to a temporary file
	if not os.path.exists(export_path):
	cq.exporters.export(leg, export_path)

but we probably will introduce more code like this in the future.

When this is done, we can get rid of the if statement for imports in cadquery scripts like this one:

nimble/doc_generator/mechanical/components/cadquery/rack_leg.py

Lines 4 to 7 in 791da1e

	if __name__ == "__cqgi__":
	import nimble_builder
	else:
	from . import nimble_builder

Plan data structure and information flow

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:

1. Receive list of networking hardware and rack parameters
2. Pass parameters into full assembly object
   1. Orchestration adds networking component to object
   2. Assembly object then creates shelf object based on this (needs access to database to know what shelf type and other information.)
3. Get ExSource from assembly object to get full list of parts and renders that need to be generated (object will need to query the other objects it contains)
4. Run ExSource
5. Get textual instructions from assembly object (object will need to query the other objects it contains)
6. Run GitBuilding

Shelf classes

• We will need a base high level shelf class that contains all the basic structure.
• We will then need a generic shelf class that creates the shelf (and stores other info) for any networking hardware that doesn't have specific shelves
• We will need child classes for the very specific shelves for certain components.

Avoid tapping plastic with machine screws where possible

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:

• Use Nut traps where possible.
• For small circuits boards like the raspberry Pi, use 2.2mm self tapping screws
• Use triangular holes for tapping into as they are more forgiving if the hole it printed too small.

Add GitHub Action to create CAD, renders, and documentation for one specific config using JSON data

This JSON data should be data that is contained in the database, and could have been extracted from the database

STLs in main Repository

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?

Containerise and host server

Fastener Models in Assemblies

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.

Custom shelves from the web interface

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.

Add new CadQuery annotations into assembly scripts

Information for shelf types in `tray_6in.py` needs to be available to other functions

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.

Hardware list

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

Add GH Action to create renders from assembly scripts

Decide on configuration (and hash) structure

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?

Hashing strategy

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.

Implementation

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.

Possible Move and Refactor of generate.py

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__) + "/..")

Create and populate initial networking hardware database

What are our naming convetions for nimble?

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:

• Is it "nimble" or "Nimble"?
• Should we ever say "the nimble"
• Should we ever say "nimble rack"
• Also when we say "nimble is a ..." what is it? "A mesh network"? "A mesh networking node" "a box of networking gubbins"

@jmwright may have some more questions.

Create public facing view of networking hardware database

Things to do:

• Updated instance of NocoDB to version 0.207 or later.
• Add approved (checkbox) column to table to show which items are approved by core team
• Add public viewable form for adding new hardware without (approved column)
• Add private view showing items to be approved
• Create public view of main data table, filtered to only show approved items

Consider standardising doc-strings to ReadTheDocs

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.

Develop bare bones, limited UI, for selecting hardware from database

PNG, SVG or Both in Documentation?

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:

1. Do we want to incorporate PNG export in the auto-documentation?
2. If so, how do we want to incorporate it?

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.

License followup

I realize that the LICENSES directory had several licenses in it. However, I and others use a LICENSES 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.

Example LICENSES directory

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)

Create Skeletal GitBuilding project, with templates for drawer assembly and final assembly

Hackthon Event happened, could be removed from Readme among others

• remove event info from Readme
• update Readme with recent community channels (Matrix Space is actually jus a Chat Room)
• link generated html pages in Readme

Add scripts to create drawer assembly pages, and final assembly pages in GitBuilding, from JSON data

Ziptie Shelf Prototype

New design for attaching any* hardware to a shelf.

STL Link: https://github.com/Wakoma/nimble/blob/master/gen/2024%20designs/parametric%20(primary)/shelf_6in_2u_anker-atom3slim.stl

Create initial set of scripted CAD shelves and frame

Further standardise nimble parameters

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

• Check through the code and find multiply defined parameters
• Change the rack legs so that they are specified by height in units not in length
• Make sure that screws go through clearance holes and then into tapped holes
• Check that all screw holes sizes are defined from parameters and clearly specified as tapped or clearance, (or other such as counter sunk)
• Decide on some standard rack parameters and think of how to pass specify them via cq-cli parameters
• Be clear about which parameters are fixed and which can/should be changed. Improve the object and it's doc string to make this clear.
• Stop using groups of strings for parameters and string comparisons, and start using enums

Open Source Hardware - some Info is missing

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.

Adjust example GitBuilding Documentation to use new top-down styntax

Get database, back-end server, and front-end UI all communicating (with server run locally)

Update the json updater script to talk to NocoDB

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

Create mock-up of final UI

Decide on Shelf/Component Filename Format

Ideas:

hardware item_rack size (6 or 10)_number of units/holes_version

thoughts @julianstirling?

zip ties VS Velcro on the new shelf creation

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.

Create placeholder CAD models

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.

Make sure that every item in the UI configuration can build a shelf

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:

• Hide the item if there is no dimension information provided
• If the height in units is not set for the shelf, then we calculate it from the item height. (We may want to always calculate it rather than have the info in the database?)
• We also want to consider what to do for items that don't have a normal shelf such as
  • The access points that clip into the lid of a case
  • The items that as standard are made into a special top for the rack. (How do we handle if two of these are chosen?, do we make that impossible, do they also have a shelf style?)

Create a full example documentation for a single configuration in GitBuilding