Author: tsmehta

Since we finished our MVP on schedule and even a little ahead of time, we were able to take a short break during Thanksgiving week to enjoy time with family and friends. We still wrapped up a few last-minute bug fixes and aesthetic adjustments.

That week, I finished cutting, gluing, and pasting the extra Catan resource tiles. On Sunday, Rhea, May, and I worked on fixing the remaining software bugs, such as the player-turn light synchronization, and we also recorded the videos for our demo. This included the dice roll, save state, multiplayer features, and a full walkthrough. We also divided the design slide responsibilities to ensure we created a strong presentation that properly showcased our project.

The following week, we added the ports (boats), flags, and magnets to secure the board to its casing. I also wrote the introduction script for our video demo since we wanted a fun way to introduce our use case. Now, with only the video demo and design report left, we’re ready for demo day on Monday!

This week I helped work on nearly  every major task we completed from Monday through Friday, but my primary focus was getting the dice-detection system fully working. I spent many hours refining the dice plate algorithm and finally got it to detect pip patterns accurately and consistently on the Raspberry Pi. This required switching to DBSCAN and combining it with the stopping/rolling detection logic I wrote earlier. I had to tune pip size thresholds, adjust clustering parameters, and deal with lighting variability on the Pi camera. After multiple iterations of both software and physical dice-plate designs, the system now detects dice with roughly ≥90% accuracy, which is a big improvement from where we started. I also worked on transferring the entire dice-detection pipeline from the Mac to the Pi, fixing camera issues, debugging FFmpeg and v4l2 errors, and testing everything in real gameplay scenarios.

In addition to the software, I helped with all of the major hardware tasks this week. I helped fix LED soldering problems and worked with May to resolder unstable connections so the rings would behave reliably in-game. I also glued the resource tiles, cut more tiles, and redesigned and reassembled the dice plates. A large part of my time went into building the full base-board structure: using CorelDRAW to design the base support, laser-cutting all required pieces, adding spacers, and assembling the complete board so it was sturdy enough for gameplay. Overall, I spent the week on a combination of coding, debugging, soldering, laser-cutting, and assembly to push the project forward.

My progress is on schedule, and we are not behind. Next week, I plan to focus on polishing the dice-detection code even more, reinforcing the board structure with magnets, and helping prepare the final presentation. I also hope to finish any remaining debugging and clean up the code so everything is ready for final testing.

Below is a video of me testing and refining the dice roll algorithm with a GUI display I coded:
https://drive.google.com/file/d/1DVNEzwVgGazKlUYmCNaQBRux-3qgsN41/view?usp=sharing

This week, I focused on completing the assembly of our second Catan board so that we can transition into synchronization and software integration over the next few weeks. I spent most of my time in TechSpark working on the hardware components. I finished wiring and soldering the entire switch matrix, and May and I worked together to solder and restructure all of the LEDs. I also laser-cut the remaining token and button pieces we needed for the board. Rhea and I assembled the LED board and cut the dowels used for the button-press mechanisms. As a team, we merged the two boards and finalized the LED-to-button mapping. By the end of the day on Friday, we were able to get the second board fully working, which positions us well for the upcoming software work.

I also spent time redesigning the dice-plate algorithm. I reframed the problem so that the algorithm detects the result of each die roll and lights up the corresponding tile, running directly on the Raspberry Pi. A key requirement is identifying when the roll begins and ends so that the board updates only once per roll rather than continuously. To reduce noise, the algorithm focuses only on the visible dice-plate region and filters for black pips on a white face. I experimented with bounding boxes to restrict the detection area and thought about ways to improve reliability, including using a custom die with colored faces so the system requires both the pip pattern and face color to match. I also considered replacing the physical dice entirely with a spinner wheel if it yields cleaner signal detection. I plan to test these ideas next week and begin integrating the algorithm with our tile-lighting logic. Below, I also listed my subsystem verifications:

Verification:

• Switch matrix (multimeter + press tests):
  Check continuity across all rows/columns with a multimeter and verify each button press registers correctly with no ghosting.
• LED–button mapping:
  Press each button and confirm the correct LED lights up.
• Dice detection accuracy:
  Run repeated rolls to confirm correct pip detection under different lighting conditions.
• Roll start/end detection:
  Verify the algorithm triggers tile lighting only once per roll.
• ROI filtering:
  Confirm bounding boxes correctly isolate the dice plate and ignore external pips.

We are currently on schedule. With the second board fully assembled, the major hardware tasks are complete, and the dice-detection work is progressing. Next week, I hope to prototype the revised dice-detection strategies, begin setting up the peer-to-peer communication system with Rhea and May, and connect the dice output to the board-lighting logic. I will also document the algorithm’s structure and gather photos and videos demonstrating my progress to support the next status update.

This week was midterm-heavy, so most of my project work took place later in the week. After exams, May and I focused on completing all soldering for the LED connections and repairing previously broken ones. While we secured the joints with electrical tape, several connections still came loose during testing, so we plan to explore more stable soldering or wire management methods next week.

In parallel, I continued developing the dice detection algorithm. I continue experimenting with multiple approaches, such as background subtraction, bounding box isolation, and DBSCAN clustering, to improve pip recognition accuracy. I successfully integrated the algorithm with the external Etron camera, enabling proper real-time testing. However, differentiating the dice from the surrounding background remains a challenge. Background removal often makes the dice less visible against the plate, reducing detection accuracy below our stated use-case requirement. A sample image of my current progress is below. I also placed orders for extra parts for our new design and second board.

After researching more effective techniques, I realized that pretrained models may not generalize well for our setup. Instead, I plan to train a custom YOLO model using images captured from our specific camera and lighting conditions. I will begin collecting training data once one board is fully assembled, which should be within the next two weeks. With midterms over, I also expect to help complete the second board next week and further refine the dice detection accuracy.

This week, Rhea and I focused on setting up SSH access for the Raspberry Pi. We initially encountered some connection issues because we needed to complete a head setup before enabling headless access. This was necessary to retrieve the Pi’s MAC address and register the device properly. After troubleshooting, we successfully configured SSH on both Raspberry Pis.

Rhea and I concentrated on building the switch matrix. This required soldering each button in sequence for input connections, followed by soldering diodes and completing all wiring. Although we checked connectivity throughout the process, we found several broken connections at the end. Because each button’s circuit is dependent on the others, fixing the broken ones would have required significant rework. Additionally, the current buttons are difficult to press, and the solder joints aren’t very secure.

To address these issues, we ordered new buttons and asked May to design a new board that will allow for a cleaner and more stable wiring setup. While we’ll need to rebuild the switch matrix, this iteration provided valuable insight into the design and wiring process and helped us identify key improvements for the next version.

In parallel, I worked on assembling the dice plate using the pieces May designed and laser-cut. While May primarily handled the CAD and laser-cutting process, I helped troubleshoot issues with engraving and cutting.  After assembling the dice plate (temporarily held together with hot glue for testing), we found that the angled wall version obstructed the view of the roads and houses on the board. We’ll move forward with a straight-walled design instead.

Because much of my time this week was spent soldering and waiting for laser-cutting jobs to finish, I wasn’t able to thoroughly test the dice algorithm with the new camera.

Once the new buttons arrive, I plan to finish assembling the revised switch matrix and fully test the dice algorithm with the camera in preparation for the interim demo.

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

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.