Posted on

Rhea’s Status Report for 10/18/25

Finishing the design report and making sure all the feedback from the presentation was addressed took up most of the time this week. Besides that, I prepared for the hardware setup by finalizing the wiring layout and diode plan for the 11×11 switch matrix. Since most of the parts hadn’t arrived yet, I focused on setting up the Raspberry Pi and organizing the copper wire for the matrix. I also got ready for soldering and breadboard testing, which I’ll start once the remaining materials come in.

Part C: Environmental Factors

Our system considers environmental factors by reducing waste and energy use while keeping people connected. Because players can share a game from home, they do not need to travel to meet in person. This lowers transportation emissions over time, especially for groups that play often.

The design also uses materials and power carefully. The LEDs and camera run at low power, and the system stays quiet and cool during use. Its modular build lets users replace or repair parts instead of throwing away the whole board, which helps reduce electronic waste. The camera’s infrared light stays at safe levels for people and pets. Together, these choices make the system more energy-efficient, safe, and sustainable.

Posted on

May’s Status Report for 10/18/25

Most of my time this week was spent working on the design report and reviewing sections for submission. In addition to that, I focused on the mechanical and structural design of the board. I completed the CAD models for laser cutting the game tiles and began testing different materials, including wood and acrylic, to determine which would be the most durable and visually consistent for fabrication. I also reviewed how the board layout aligns with the switch matrix and LED wiring to ensure proper fit during assembly.

Part A: Global Factors
Our project responds to how people around the world spend time together. Many games today use screens, which can make people feel distant. By bringing back real, physical play, our system helps people connect in a more natural way. It can also reduce screen fatigue and make shared time feel more personal. The design reuses hardware like Raspberry Pis and cameras that are easy to find and use anywhere. This makes the system simple to build and supports global goals for sustainability and better use of technology.

Our system also focuses on people outside local or academic circles. Many players live far apart or do not have access to in-person game groups. Some may not be comfortable with complex digital tools. Because the boards connect over normal Wi-Fi and use real pieces, anyone can set them up without special skills. This makes it easy for families and friends in different places to play together through a simple, hands-on experience.

Posted on

Team Status Report for 10/18/25

During this week, the team mainly focused on completing and submitting the design report. We incorporated feedback from the design presentation and made sure all comments were addressed in the final version. Since the presentation did not cover all required material, we finalized the overall system architecture and design requirements in the report. We also completed trade studies for key components, confirming the use of the Raspberry Pi 5, OAK-D Short Range camera, diode-isolated switch matrix, and WebRTC for communication. In addition, the team created sketches for the board layout and wiring design, organized the bill of materials, and finalized the Gantt chart showing each member’s timeline and tasks. We also ordered the parts needed to build and test a smaller prototype section of the board before full-scale fabrication.

Part A was written by May, B was written by Tanisha and C was written by Rhea.

Posted on

May’s Status Report for 9/27/25

I spent most of Sunday preparing for the design presentation and presented it on Monday. I also made the switch from the OAK-D Pro Robotics to the OAK-D Short Range camera after learning that our first choice was unavailable and updated the design report accordingly. The OAK-D Short Range camera still has the main features such as the IR LED for low light vision and on board processing power. 

This week, I also finalized the list of materials for the board base and began creating the CAD drawings for laser cutting. I’m on track to complete these drawings by next week when I plan to schedule shop time to laser cut the pieces and perform a quick test fit to verify that everything aligns as intended, as well as work with Rhea to test individual components.

Posted on

Tanisha’s Status Report for 10/4/25

I implemented the dice-roll detection code we planned last week. Since our original camera became unavailable, I haven’t been able to test it on the actual hardware yet, but our inventory request was approved, so I should be able to do that soon. Overall, I’m on schedule. The main risk now is how quickly I can get access to the new camera. Next week, I plan to connect the camera, run the system end-to-end, and address any issues that come up during testing.

Posted on

Rhea’s Status Report for 10/4/25

This week, I finalized the switch circuit design and ordered the necessary parts to build an initial working prototype. Our plan is to start with a smaller 3×3 switch matrix to validate the circuit before scaling up to the full 11×11 version. Once the parts arrive, we’ll assemble and test the smaller matrix on a breadboard to confirm functionality. If we identify any adjustments during this phase, I will update the schematic accordingly before constructing the full board.

Posted on

Team Status Report for 10/4/25

This week, we finalized the parts list for our build. This includes materials for the board base, switch circuit components, and an individually addressable LED strip. For now, we’ve ordered enough to assemble one board. We plan to build a smaller version of each component so we can evaluate the materials and make adjustments before scaling up and building the full board.

Since our preferred camera (OAK-D Pro Robotics) was reserved by another group, we switched to the OAK-D Short Range camera. It still supports the close-up dice detection we need and should meet all of our technical requirements.

Following our design presentation, we met to revise and expand upon the written design report. Each team member will work on specific sections of the report, after which we’ll reconvene to integrate everything and finalize the draft.

One risk right now is shipping delays and minor adjustments from the camera change. To stay on track, we’ll continue testing with recorded video in place of a live feed and recalibrate once the new camera arrives. If time becomes tight, we’ll prioritize completing the report first then camera testing. If we are able to get shop time, we also want to laser-cut our first set of pieces for a quick test fit.

Another potential risk is the brightness of the LEDs. We need to ensure that roads and settlements are clearly illuminated, so if the current strip isn’t bright or dense enough, we may need to either switch to a higher-density LED strip or cut and re-solder individual LEDs to achieve the desired visibility.

Finally, we rebalanced team roles in the Gantt chart to parallelize the workload. The updated assignments are shown below.

Posted on

Rhea’s Status Report for 9/20/25

During the proposal presentation, there were some questions regarding which specific Raspberry Pi we would be using and whether there would be enough GPIO pins to wire all our desired connections. I looked into the Raspberry Pi pins to check how many were available and whether we could reasonably support all our hardware. For our project, we need to support the camera along with all the LEDs, buttons, and the connection to our server, while also making sure everything works reliably as one system. My progress is on schedule, and I plan to complete a rudimentary block diagram showing the connections between our hardware in the next week.

Posted on

Tanisha’s Status Report for 9/20/25

This week, I focused on preparing and practicing for the proposal presentation. This pushed me to think further about our use cases and implementation details, such as whether multiple boards would be necessary for the MVP. After receiving questions and suggestions during the proposal presentation, I reevaluated some of these considerations. For example, I looked into hosting the server directly on the Raspberry Pi instead of using WebRTC. However, it became clear this would not be scalable and could potentially overload the Raspberry Pi, especially if we plan to incorporate some of our stretch goals (e.g., saving the game state) in the future. My progress is on schedule, and I plan to complete a basic software diagram showing the communication between the board and the server within the next week.

Posted on

May’s Status Report for 9/20/25

I drew out multiple diagrams to represent how our game board will look at the user level and at the hardware level. This not only helped us think about the small implementation details we overlooked before (e.g. how to differentiate between a city and settlement), but it also provided a lot of visual aid during the proposal presentation to help the audience understand our project better. I also looked into the specific parts of our circuit to determine the best options for the road LEDs and the settlements. I did more research into the two camera options presented, the Raspberry Pi AI camera and the Adafruit Tiny USB webcam, and how they would connect to both the WebRTC server and the Raspberry Pi, considering both cost and usability. In addition, I have begun looking into the software side of detecting the rolled number. My progress is on schedule, and I plan to complete the block diagram for the computer vision portion of our project in the next week.