The purpose of this guide is to describe how files are sorted and stored in the grabCAD repository. This is to help maintain data integrity and allow new members to easily find their way around the drive and easily add to the project. If you have any questions feel free to message Ethan Cronier on discord!

Reasons for Detail

Many of our members are unable to work on the rover in person due to co-op. and especially this year due to the rona. In order for our remote members to contribute to something they do not have physical access to, they need an accurate representation of the rover in computer, hence a need for accurate CAD representation is needed.

Having accurate CAD also allows us to account for any potential issues that come from a lack of planning. For example, we CAD in all of our fasteners. Some companies will not do this due to their own large stock of fasteners on hand. We do not have access to that... we order all the fasteners we need when we need them and if we have to order again after the fact, this will increase our spending's which could be better spend elsewhere.

High Level Project Structure

In the root of the project folder, there are subsystem folders along with a few top level assemblies and other misc folders.

Below you can find a brief description of each of the top level folders, the sub-system folders will be described afterwards.

.grabcad

this folder is apart of how grabcad pushes and pulls. this folder is safe to delete if you are tight on space, it does regenerate every-time you push or pull though so there is no point. This folder is generally hidden and there is no need to go into this folder.

Archive

This folder stores all archived sub-system folders or top level assemblies only. If you are archiving a part in the science sub-system do not use the top level archive folder, use the science archive folder. In other words, always use the closest archive folder, if there are no archive folders in the directory, create one.

Documentation

This folder stores all 'meta data' files pertaining only to the top level, again if there is a piece of documentation associated with just science but that in the science documentation folder. There has been a recent effort to move all documentation to Confluence, so please but your info here before placing a file in the drive.

The top level documentation folder also homes the now obsolete smart fastener library and the new SolidWorks toolbox library thanks to Austin Tailon Huang .

Member Training

This is were member training documents are stored. New members must complete their training by pushing their named folder here and getting it reviewed to be 'formally' accepted as a mechanical member.

Below is a screenshot of all the recent people who have completed the training. Each member will store their training files in a folder in 'Member Training' named with their full name and initials in (brackets).

PCBs

This folder is now obselete. All PCBs should be stored within the appropriate subsystem folder from now on. (tbh I don't even know what this folder was used for originally, from a time when the project was far less organized)

Renders

This folder is for all things render related for the entire system. If rendering is for a particular system or part of system, this will be stored in the appropriate system render folder.

Top Level Assembly files

These files bring together all sub-systems into a single top level assembly. Historically this was just 1 file, but during the recent CAD cleanup there where some issues combining into one file, so it has been broken into 3 assemblies which then feed into the MR21-MAIN-ASSEMBLY.SLDASM file, highest level. In future it would be nice to have one assembly again.

Sub-system Folders

An effort has been made to make the organization of these folders as similar to each other as possible so the same concepts can be used between Folders. An effort has also been made to make the structure 'recursive' meaning for more complex sub-systems (such as arm), the sub-system folder can contain child sub-system folders with the exact same folder structure (at least that's the idea), This will be described further later on.

Below is a typical sub-system folder, in this case gimbal. Each sub-system should have these 8 folders

Archive

This is the sub-system archive folder any part, assembly or document which is no longer being used can go this archive folder. archive folders are not organized on the inside, they only serve as a backup if someone wants to go digging afterwards. The components and OTS components folder will also have their own archive folder which you can use as well, it is not that important which you use. (note to self, may want to have one archive folder per sub-system, instead of per folder)

Components

This contains all parts which cannot be bought and used directly on the rover. If an OTS part has to be machined or modified it will go in this folder. Files here shall be named according to the naming scheme.

Documents

This is for any calculations, datasheets, BOMs and anything else not a part or assembly or drawing. This is being phased out, try to move any documents to confluence.

Drawings

This folder is for storing SolidWorks drawings and the pdfs of the drawings and nothing else.

Fabrication

this folder contains a set of folders where each folder is a different fabrication order. The naming of each folder inside should be "<company> <date> -<state>". Where state acts as a flag which indicates if the job has been -pending, -ordered, -fabricated, -delivered. This way other members know immediately the state of the order. No need for a fabrication folder if the part is being made in house. An effort should be made to move this meta data to confluence.

Everything the fabricator needs to make the parts should be stored in this folder. This includes: pdfs of drawings, STEP files, stl files and anything else.

OTS Components

This is where all OTS (Off The Shelf) components are located (except the ones being modified) The naming convention for OTS components and folder organization within the OTS folder has been outlined in another document on confluence. Try to use the toolbox for all fasteners.

PCBs

This where the custom PCBs are stored, the ones designed by the electrical team. If the PCB can be bought OTS then it belongs in the OTS folder. This folder does not need to keep the STEP file, just the optimised PCB sldprt file (Creating Lightweight PCBs)

Renders

This folder stores everything render related with the sub-system

discrepancies

Science

The science mechanism has several sub-categorizations of parts but lack a sub-system assembly. It is best practice that assemblies are always a higher level or same level as part files (in terms of folder directory). Since certain assemblies draw parts from several different component folders the assembly has been moved into the root of the sub-system folder and all the component folders moved to the top level.

In future, all components should be grouped in one components folder, or create a sub-assembly folder with its own isolated assembly.

Chassis & Arm

This sub-system is a perfect example of a (relatively) well organized sub-system with its own recursed sub-system.

Below is a screenshot of the chassis folder and then the Frame folder. Note that a recursed sub-system generally only needs the Archive, Components and OTS Components along with the relevant assemblies. This also generally means that there are no components which don't belong to just the sub-system (not sub-sub-system) so no need for a Components or OTS Components folder in the Chassis folder.

The only difference with Arm is that there are more recursed sub-systems than chassis.

Current limitations of the folder structure

• Little space/freedom for prototyping CAD: setup in a way that all files should be used in the final product. loose/floating parts and assemblies are undesirable and archived. - need a space for prototyping
• naming convention (not described here) is not configuration friendly (each part should have its own file name/number)
• nuances in several locations which bugs me. it is not 100% consistent. - this arises from shitty documentation, everyone doing their own thing and no over-arching guidance/coordination