Posted on

May’s Status Report for 9/27/25

This week, I worked on preparing for the upcoming design review presentation and focused on producing a clear block diagram that represents the overarching system interface. The main goal was to show how the Raspberry Pi acts as the central controller and how all other components integrate with it.

I refined the design of the switch board, mapping out how its internal switches are connected to the Raspberry Pi through 11 copper rows and 11 copper columns. This setup allows the Pi to detect activations across a grid layout while keeping the wiring manageable. I also included how the LCD display is wired directly to the Pi’s GPIO pins, providing visual feedback such as game codes or system status during operation.

On the input side, I added the USB-connected keypad as a straightforward way for users to enter the game code. This clarified both the hardware connection path and the expected software input handling. Similarly, I included the Oak-D Pro camera, connected through USB, and showed how its video feed is processed using OpenCV. This addition demonstrates how dice rolls or other visual inputs will be captured and analyzed in real time.

Finally, I emphasized the communication link between the Raspberry Pi and the WebRTC server, which is critical for synchronizing game state between boards. By showing this explicitly in the diagram, I tied together the local hardware sensing/actuation with the remote peer-to-peer communication layer.

Overall, the diagram now illustrates the entire hardware–software pipeline: from physical sensing on the switch board, to input/output devices (LCD, keypad, camera), to central processing on the Pi, and outwards to the WebRTC server for multi-board synchronization.

I also practiced presenting the design presentation as I will be presenting on either Monday or Wednesday next week. My next step is to finalize the design presentation and begin testing individual interfaces (starting with the keypad input and LCD display on the Pi) to validate that each component communicates correctly before integrating them into the full system.

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.

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.

Posted on

Team Status Report for 9/20/25

As a team, we mainly discussed our circuit design. The most significant risk that could jeopardize the success of the project is making sure all the buttons and LEDs on our board are reliable and consistently work. We are managing this risk by carefully and thoroughly planning the design, specifically the wiring. We are not as concerned about the buttons for the settlements, but more about how the roads will light up functionally. The contingency plan for the roads is to either add another button on top of the board that lights up an LED or use a button LED component. The latter would be preferred due to ease of implementation and fewer components to wire. However, we are still looking into what possible LEDs exist that meet this requirement, and we haven’t been able to find any affordable options yet. So far, we have not made any changes to our existing design as we are still working out the granular technical details. We remain on track with our schedule. All team members contributed to the system specification and implementation plan sections of the design presentation content.