Posted on

May’s Status Report for 10/25/25

This week the team and I worked on the Raspberry Pi and the LED strip. I ran small test scripts on my laptop and on the Pi to learn the LED API and how to address colors. I brought up basic patterns and started checking timing and per-tile addressing. Early signs look fine, and I have more checks to finish.

I also worked on how to connect to the Pi. I tried SSH and a direct wired setup and wrote down the steps for each. I fixed a few small network and permission issues while testing.

Our last part arrived on Thursday, so full assembly can start next week. I plan to help assemble the switch matrix and bring up a small section first. I’ll write a simple scan test and check that the switch events map to the right LEDs. After that, we’ll scale to more tiles.

Posted on

Rhea’s Status Report for 10/25/25

This week I focused on the switch inputs (and finished the ethics assignment). I tested the buttons we ordered with copper wire to check feel and basic continuity to the Pi. The buttons are tiny (as we had  intended), but after testing them, we realized some usability trade-offs. First, direct finger presses are finicky, it is easier to press using something harder (such as a fingernail). Second, pressing through a thin sheet can potentially nudge nearby buttons and cause accidental triggers.

Given that, we are considering changing the design to place each button directly under a settlement/city game piece so the piece helps localizes force. While this is different from our original design where we wanted all the electrical components of the game board hidden under a layer, it still keeps the top surface clean (as the buttons are hidden under the game pieces). Therefore, it still aligns with our “invisible wiring but still tactile” goal of the design.

For the full board, we are planning an 11×11 switch matrix. I haven’t built the 3×3 yet, I only validated parts and wiring, but I outlined the scale-up path. Next week, I’ll wire a 3×3 and test for simultaneous presses without ghosting (with per-switch diodes if needed) and verify the press to LED mapping.

Posted on

Tanisha’s Status Report for 10/25/25

This week, apart from finishing the ethics assignment, I focused on testing and refining the dice roll detection algorithm. While our original plan was to continue testing with the OAK-D short-range camera, feedback from the design review suggested that a simpler IR camera (without depth sensing) might be sufficient. Based on that, I prioritized improving the algorithm using a standard computer webcam before proceeding with new hardware.

The main issue I encountered is that the computer vision model performs well when the camera is stationary and the background is neutral. The stationary setup aligns with our design requirements, but achieving a consistent background is more challenging since the camera views the dice through a transparent base facing upward, meaning the user’s ceiling or any movement above the board can be captured. To address this, I experimented with several techniques, including adaptive thresholding, color-space conversion (HSV and LAB) to isolate the white dice and remove background noise, contour detection and filtering based on area and circularity. These improvements helped stabilize detection in most cases, but performance still degrades under strong glare or high-reflectivity conditions.

Next week, I plan to continue optimizing the algorithm, expand the DBSCAN clustering approach to improve pip differentiation across varying dice orientations, and begin integrating the camera into the physical dice tray. I will also compare the IR and OAK-D cameras to determine which provides more reliable and consistent detection for our setup.

The link below is a rough, quick demo showing the dice roll algorithm working in a stable and neutral background, and having issues once either of the aforementioned criteria are not met.

https://drive.google.com/file/d/1MSPHxBoCMd_Q1P0uBS3rVgX7YBYsmDOO/view?usp=sharing

Posted on

Team Status Report for 10/25/25

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.

Posted on

Tanisha’s Status Report for 10/18/25

This week I was tied up with the design report, but I made progress on our dice-reading algorithm. I re-evaluated the short-range camera setup (focal distance, exposure/gain) and ran end-to-end dice-roll tests. The pipeline worked reliably, with occasional low-confidence reads fixed by an automatic re-capture. I updated our changes to reflect the short-range camera, noting notes lighting/glare mitigation, and documented what we would need for the dice tray and camera enclosure. Next week, I plan to organize test clips and screenshots as well as collect quantitate data on the reading accuracy of 100 dice rolls to demonstrate the results.

Part B: Cultural Factors

Our project recreates the social feel and norms of in-person Catan for players in different locations, so we explicitly design for fairness, privacy, accessibility, and familiar “table rhythm.” 

Two mirrored, physical boards sense roads/settlements/cities directly on the board, keeping talk and negotiation natural without new screens. To support shared rules around fair play, dice are read on-device with a short-range camera; if the read is uncertain, the system quietly tries again so no one acts as the referee. Information is language-independent: LEDs and simple icons carry meaning across groups, and we can choose color blind friendly palettes so mixed-ability players participate without being singled out. 

We target low latency (≈100 ms local, ≤1 s board-to-board) so pacing and attention match normal tabletop play on typical home Wi-Fi. For privacy expectations in homes, lounges, and community rooms, we transmit only compact game events (no video), and keep inference on the board. A hooded tray and stable exposure reduce glare so the setup works across varied lighting and table sizes. 

Taken together, these choices address cultural factors, beliefs about fair competition, norms around shared space and devices, differing languages and abilities, so different communities can keep their usual play style while sharing one consistent, trustworthy game.

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.