Posted on

Tanisha’s Status Report for 9/27/25

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.

Posted on

Rhea’s Status Report for 9/27/25

I spent a lot of time working and designing how the switch matrix would work and function, finding optimal placements to maximize the space we had, and minimize required components, keeping in mind ease of implementation. I laid out the 20″ × 20″ hexagonal game board with 11 copper rows and 11 copper columns, creating a grid that allows each intersection to be a unique addressable switch. The pink points in the diagram below represent the actual switch positions, while the diagonal copper wires are 18-gauge conductors that form the backbone of the matrix. By pressing two adjacent switches, players can place a road in the game, while a single press can represent a settlement (with an additional press later upgrading it to a city). This switch matrix design balances compactness, wiring simplicity, and intuitive user interaction.

In addition, I worked out how the computer vision dice detection system will function. We are planning to use the Oak-D Pro depth camera, connected to the Raspberry Pi 5 via USB to capture the dice rolls inside a transparent dice tray. The video frames will be processed by OpenCV, where we apply preprocessing steps like grayscale conversion, Gaussian blur, and adaptive thresholding to reduce noise and highlight the dice. From there, a blob detection algorithm is used to identify the dark circular regions (pips) on the dice faces. To ensure accuracy, the algorithm will use density-based clustering (such as DBSCAN) to group nearby pixels and eliminate spurious detections caused by reflections or shadows.

This approach has several advantages over mechanical or magnetic sensors:

  1. It allows the use of regular dice without modifications.
  2. The system can generalize across lighting conditions by adjusting preprocessing thresholds dynamically.
  3. By knowing the tray’s approximate size and camera angle, we can filter out non-dice blobs and count only the valid pips.
  4. Because the Oak-D Pro provides depth information, we could later extend the pipeline to verify that exactly two dice are present and lying flat before confirming a roll.

The final result of the pipeline will be a pair of integers corresponding to the dice values. These values are then sent to the Raspberry Pi’s game logic, which passes them over the WebRTC DataChannel to keep all boards synchronized. This means that once a roll is detected, the same value propagates across every connected board in under 500 ms.

Together, these two pieces, the switch matrix for structured player input on the board and the CV pipeline for automated dice roll detection, complete the sensing and input layer of the system. They integrate well with the Raspberry Pi’s GPIO and USB interfaces, and fit directly into the broader WebRTC-based communication system Tanisha finalized this week.

My plan for next week is to prototype OpenCV pipeline with the Oak-D Pro to validate dice detection accuracy and robustness under different lighting conditions.

Posted on

Team Status Report for 9/27/25

This week our team really had to work together to figure out all the details and kinks of our design. We had multiple work sessions where we fleshed out our circuit design and server design. 

One of our biggest worries was the amount of components we had to wire. Firstly, we didn’t want to use an excessive amount of GPIO pins as they would be hard to wire. Secondly, with too many wires, our circuit is more prone to errors, can get messy without excellent wire management, and would overall be very difficult to work with. Our goal was to minimize the number of wires we would need in order to still have all the components in our circuit working. The issue with our preliminary design is that we wanted to have LED’s for each settlement and settlement type (e.g. one for the settlement and one for city), one for each road, and one for each tile number. Then, we wanted a button for each settlement and settlement type, a button for each robber location, and a button for each road. This would put our total LED count to 183 (54 settlement & city locations, 57 road locations, 18 number tiles), and our total button count to 183 as well. 

We spent some time brainstorming after discussing some possible options with the professor and our TA at our weekly meeting. To solve this problem, we decided to use one long programmable LED strip. This would allow us to only require one connection to the Raspberry Pi, and we can index into the LED and program it accordingly. We can use this LED strip for all our LED purposes, making it a really efficient and cost effective solution. As for our button problem, we decided to fix this by using a 11×11 switch matrix. This 11×11 switch matrix would have 121 possible button locations, and perfectly aligns with the Catan tile array setup. This was still not enough for our 165 total button account, so we decided to use the buttons in a unique way. We would place one at each possible settlement/city location, and they would function as follows:

  • Pressing a button once lights up a settlement.
  • Pressing it again upgrades it to a city.
  • Pressing it a third time turns the light off.
  • Pressing two adjacent buttons at once lights up the road between them.
  • Pressing those two again turns the road off.

This makes it easy to undo any mistakes, and reduces our required button count to just 72. 

We also began curating a parts list, and placed a preliminary order from the inventory. This included the Raspberry Pi 5 which has 40 GPIO pins, and the Oak-d Pro camera to identify our rolled die number. 

After this, we began working on our design presentation, and dividing up the labour according to our individual responsibilities. More details can be found in our individual status reports. In general, we are still on track with our current schedule, and the major changes we made were in the design of our circuit as mentioned above.