This week, the team began connecting the Raspberry Pi and testing the functionality of the individually addressable LEDs. We verified that the LED strip can respond to signal inputs from the Pi and started experimenting with color addressing and timing control to ensure that each tile can light up independently. These initial tests will help us confirm power requirements and data line reliability before integrating the LEDs into the full board.
Our plan for this week also included catching up on coursework to allow us to fully dedicate next week to hardware implementation and testing in Tech Spark. By the interim demo day, our goal is to complete one functional board section with at least six outer tiles and the central dice tray tile, demonstrating that the user’s individual board lights up correctly in response to game actions.
Most of our ordered components have now arrived, including the LED strips, buttons, cameras, and wiring materials. Next week, we plan to focus on assembling the switch matrix, laser-cutting the acrylic and wood pieces for the board, and beginning full integration of the electronics. In addition, we met as a group to discuss the Ethics Assignment (Part 3) to ensure we are reading for the ethics class discussion next week.
We also reviewed our feedback from the design presentation and gathered the following key notes for improvement:
- Clarify the number of switches and finalize the size of the switch matrix.
- Quantitatively define the synchronization requirement for WebRTC communication (e.g., how the 1-second latency translates into a measurable performance metric).
- Provide more details on dice roll accuracy and explain how it affects the dice detection algorithm.
- Account for the 3-hour portability requirement by confirming that a 300 mW battery is sufficient.
- Add a clear Principle of Operation diagram that illustrates our system architecture.
- Include a trade-study table comparing Arduino vs. Raspberry Pi, highlighting why the Pi is the better fit.
- Show early block diagrams (Board A, B, C) and how they evolved into the current detailed schematic.
- Explain our design trade-off between visible and invisible switches, noting how user feedback led us to prioritize a cleaner interface while maintaining tactile feedback.
- Re-evaluate whether the OAK-D camera is necessary given that we are not using its neural-net features, and explore simpler alternatives such as LiDAR modules from SICK.
These notes will guide our next phase of development and ensure our interim demo demonstrates clear progress in both technical implementation and design justification.