Devlog #2 - Component Assembly and Design Tuning

This week, I was tuning my Stardeck designs to reach feasibility before submitting my design to Stardance for review. I started to test my initial design decisions using Onshape to model the spacing that each part would need, and I used that to finish up a component assembly that reflected how my parts would fit together in the real world.

CAD Assembly

Space was a critical factor in my cyberdeck because it was what everything inside of my enclosure lived on. Furthermore, my enclosure design evolved often to account for unanticipated constraints. A few of my enclosure features for Stardeck surprised me as I never even knew that I needed them at first.

• Clamshell Design: Remember how in the first devlog, I was considering using a rectangular prism with a carved-out back to house all the internal components? I found out very quickly that this would still make for a hard assembly once more than two parts came in. A clamshell design - top half, bottom half - would allow me to make the most of the space given because it would allow me to actually reach many parts of the internals.

• Alignment Lips: This took me a long time to conceptualize after hearing about these for the first time, but it became easy once I thought of a shoebox. The top of any shoebox fits on the bottom half and rests there - not because it’s screwed in place, but because the top half sort of wraps around the bottom half. These made the clamshell more robust as the “shoebox method” promised a safer screwdriver assembly as well.

• Mounting Rails: Placing the Raspberry Pi, which would be the basis of Stardeck’s computing subsystem, in the exact middle of the enclosure meant that other components - battery, screen, flash drive, etc - could reach it easily. However, it can’t just levitate, so it uses mounting rails to keep it up. The rails also come with holes for the Pi to be mounted onto for added security.

• Port Cutout: I felt so relieved after realizing that I needed this before shipping off all my CAD files to display on GitHub. The reason why was because it’s the hole in the enclosure that allows external cables to access the Pi’s USB ports. This makes essential functions such as swapping flash drives and connecting keyboards much easier. Overall, it’s a small design feature that makes assembly and maintenance much easier.

System Architecture

From the last devlog, we already knew how each component would connect to one another in practice. However, I found that for this iteration, the system could be modeled effectively at the subsystem level without a full PCB design or detailed electrical schematic. To follow, I created a System Architecture diagram to demonstrate how the parts of Stardeck interact with each other. After solving the electrical problem, I managed - with several days of me modeling components to depict and assemble - to solve the mechanical problem instead. Both were closely related to each other, which made for a lot of work when planning port maps, looking at diagrams of the port locations on a Raspberry Pi, finding components for the BOM that I want for my build, and so on.

Summary

I learned a lot about hardware selection, using Onshape to work around physical constraints, and building prototypes with future me in mind. I’m confident this design is ready to be submitted at its current state to Stardance. It’s simple and has just enough functionality without going overboard for a minimal viable product. With funding help from them, I’ll have the parts necessary to go from designing a prototype to fabricating a prototype.

Exploded View Part Numbers

1. Top Enclosure
2. Bottom Enclosure
3. Raspberry Pi
4. Battery Pack
5. Screen
6. Flash Drive
7. Alignment Lip
8. Battery Tray
9. Mounting Rails

Next up:

• Print enclosure
• Assemble real-world components
• Iterate on the design (if met with an obstacle during fabrication)