Category: Tanisha’s Status Reports

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

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.

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.

Apart from working on the design presentation and constraints, my main focus this week was fully fleshing out the server communication for our Catan board.  I finalized the architecture for how the Raspberry Pis (host and joiner) will communicate with each other and the cloud, and translated that into a clear data flow design.

On the host side, I detailed the Go native application modules: the game engine and state machine that keeps tracks of players’ turns,, the Pion WebRTC connection layer (handling the DataChannel and ICE), the snapshot manager for serializing the game state, and the event log for recording moves. I also added a local persistence layer using SQLite in WAL mode so the host can write both versioned snapshots and an append-only event log. To bridge this with the cloud, I built out the concept of an uploader that asynchronously pushes periodic snapshots and event batches to the Save Service API. The host also interfaces with an LCD display to show the game code, making setup clear for the user.

On the joiner side, I designed a corresponding Go native application with a lighter module set: the same game engine and WebRTC connection, plus a “catch-up” module that can pull snapshots and missing events from the cloud if the joiner reconnects or rehosts. For user interaction, the joiner will take game code input through a USB numeric keypad that they briefly connect to the Raspberry Pi. While not required, I included an optional SQLite cache so the joiner can locally store recent state for failure recovery.

For the cloud services, I defined the Save Service API endpoints (/games, /save, /events, /snapshot, /resume) that handle game persistence and recovery. I also specified Postgres as the structured store for events and object storage for snapshots, ensuring that the game can always be resumed if a Pi disconnects or fails. Alongside this, I integrated the signaling server (over WebSocket/HTTPS) for SDP/ICE exchange and NAT traversal support via STUN/TURN (coturn), with all traffic secured by TLS. The latter is required by WebRTC applications to run smoothly and for firewall recovery.

Finally, I documented the resilience and recovery flow: the host maintains an authoritative state locally and periodically syncs it to the cloud; if the host drops, another board can fetch the most recent snapshot and events to continue the game without loss of progress. This ties the user-facing hardware, Pi software modules, and cloud services into a complete, robust communication system.

While some of the above requirements are included in the case we are able to achieve our “ideal” product (i.e. they are not required for MVP), I included them in the preliminary block diagram. As for next steps, I plan to refine this setup and also begin implementing the Go app skeleton on the Raspberry Pi, starting with WebRTC setup using Pion.

Below is a detailed diagram of the above information, and below that is a more cleaned up but less dense diagram.

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.