Category: Rhea’s Status Reports

We finished all the final touches for our boards this week (focusing on the aesthetics). I mostly focused on debugging the code and making it more robust to any errors, as there were a few inconsistencies with the save state and multiplayer features. Additionally, I spent most of my time preparing for my presentation on Wednesday. 

We spent the second half of our week planning our final video. Because we are ahead of schedule, we hope to implement some basic rule checks in our code before our demo. For example, a player shouldn’t be able to place a settlement on a corner adjacent to another settlement. Our main focus for next week will be the final video and report. 

This week, I focused on integrating the two boards. Last week, both boards could independently detect button presses and light up the corresponding LEDs, and we had a simple dice detection algorithm, so this week, I worked on synchronizing the two boards. 

I wrote the code that sends messages between both game boards to ensure they are in sync. Whenever a button press or dice roll is detected, it now sends a message to all connected peers (in this case, only one other board). Each board currently stores its peer information (hostname, IP, etc.) in a configuration file. When the program starts, it reads this config, opens a socket that listens on all ports, and spawns a thread dedicated to receiving and processing incoming messages. Two other threads handle checking for button presses and dice rolls (and sending messages whenever anything is detected). This way, both boards can update each other in real time.

I also implemented a save state system. When a player stops playing, the board records its current state (which LEDs are on, whose turn it is, etc.) and writes it to a file. When the board is powered on again, the script automatically loads this saved state so gameplay can resume exactly where it left off. To complement this, I added a clear board button that resets all LEDs so users can start a new game at any time.

Since we decided to downsize our prototype to six tiles, I also worked on remapping the dice rolls. Normally, Catan uses numbers 2–12, but we only use seven of them (six resource tiles and 7 for the robber). We decided to turn the remaining four numbers into ports. Players can choose what resource will be gained from each port, and when a port’s number is rolled, they can take that resource. This ensures every resource appears at least twice across the six tiles and four ports, keeping the game balanced but flexible.

Finally, we added support for more than two players, even with only two boards. Instead of assigning each board to a fixed player color, I added an “end turn” button. When pressed, it cycles through the colors based on the number of players (2–4) entered at the start of the game. This means four players can now play together using the same board, increasing the overall usability.

Finally, we also finished the visual design: gluing down the printed resource images on each tile and adding the blue water background to make the board match the real Catan aesthetic.

Next week, I plan on thoroughly testing our boards and fixing any minor bugs in the code. I also plan on spending most of my time working on the presentation, as I will be working from home and won’t be on campus to work on the actual game boards. Once I come back, I hope to spend time working on making the RPi start running the script immediately upon it being powered on (so you don’t need to connect a computer to start the script). Any information the user needs to enter can be entered directly through a connected keyboard.

To implement board synchronization, I had to learn more about socket programming and managing multiple threads in Python. I previously took Distributed Systems in Go, so I reused the structure I would normally write in Go, then translated that into Python by reading library docs and small code examples online.

I also had to learn how to debug NeoPixel strip issues that only showed up as segfaults in the terminal. At first it wasn’t obvious that the problem was the LEDs at all, or that it was caused by multiple threads writing to the strips at the same time. I went through a lot of Stack Overflow posts and videos about driving multiple NeoPixel strips from one Raspberry Pi. That’s how I realized the NeoPixel library itself isn’t thread-safe, and that simple locks around the strips weren’t enough. In the end, I fixed it by creating a single dedicated thread whose only job is to update the NeoPixels. All other parts of the code just push “update requests” into a queue, and that one thread processes them in order. This removed the race condition without needing complicated locking and made the LED behavior much more stable.

Over the weekend, I worked with May to complete and finalize the first board. I led the button-to-LED mapping code and helped design the connection between the button board and the LED board. We assembled it and ran LED indexing and mapping tests. I also helped prep for the interim demo and updated the Gantt chart with May.

For the second board, I worked with Tanisha to secure the LEDs and route wires so they lay flat. I connected tokens to the buttons and helped set dowel height for reliable presses. I prepped the board for final assembly and assembled the two boards together with the team and conducted the final end to end tests.

 

Verification:

• LED indexing/mapping: Thoroughly check every LED index against the board. Pass if mapping is 100% correct.
• Robber rule logic: Test single press, adjacent pair, non-adjacent pair, and quick repeats. Pass if only one robber position is active and non-adjacent pairs are ignored without errors.

This week, I focused on completing the switch matrix and writing core software for button detection and LED response.

May and I built the full switch matrix from start. We started by gluing all the tactile buttons to the baseboard, then soldered copper wire across each column. We had to solder a diode to the other leg of each button, and then another copper wire connecting all the rows. We used electrical tape along every connection to strengthen joints and prevent short circuits between adjacent rows and columns. After finishing the matrix, I worked on the Python code for button press detection. I implemented software debouncing to make sure a singular button press didn’t register as multiple presses. This took most of Tuesday, and by the end, we had a working, stable 11×11 switch matrix that could detect multiple presses simultaneously.

May and Tanisha handled most of the LED re-soldering (I mostly just held wires down for them). I took the strips they finished soldering and taped them in the correct positions around the board to form hex shapes. This took most of our Wednesday work session. The duct tape I used initially wasn’t strong enough, as the joints kept flexing. We decided to switch to hot glue for all sections. On Thursday, May and I secured all the LEDs in place and thoroughly tested them to make sure the connections were strong enough to withstand normal gameplay and movement.

I also wrote the main LED control script, which links button presses to specific LED indices. The program continuously scans the switch matrix, and (1) lights up “house” LEDs when a single button is pressed, (2) lights up “road” LEDs when two adjacent buttons are pressed, and (3) moves the “robber” light when a specific tile button is pressed again. Right now, the code framework is complete: we just need the final mapping between buttons and LED indices once the boards are physically aligned. After that, I’ll test and tune the system for full responsiveness.

We are slightly behind schedule on finishing the second board because the LED re-soldering and mounting took longer than expected. Before the interim demo, we hope to have the first board assembled completely and the mapping between buttons to LED indices recorded. For next week, I plan to work on tuning the software components, as I am out of town for half the week. Once I am back, I plan to help finish the second board and start working on synchronizing the two boards together.

I worked with Tanisha to finish setting up the Raspberry Pi with SSH so we could control the board remotely. I also tested the LED strips with the Pi and played with different brightness levels to see what would be most visible on the board and what would work best for roads, cities, and settlements.

I worked with May on the baseboard layout. I took measurements on the actual LED strip and cube pieces to figure out spacing/tolerances, and May translated that into the SolidWorks design so that all the components would line up.

I also set up the switch matrix and did the initial wiring. Tanisha helped with the soldering so everything was secured. While we did connectivity checks at each step, we believe some connections broke as we transported the components or as we continued building upon each piece, as there were still a few flaky connections once we finished. We will be switching to sturdier and bigger buttons and laser cutting a layer for the buttons to prevent all the pieces from moving around next week.

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.

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.

This week, I finalized the switch circuit design and ordered the necessary parts to build an initial working prototype. Our plan is to start with a smaller 3×3 switch matrix to validate the circuit before scaling up to the full 11×11 version. Once the parts arrive, we’ll assemble and test the smaller matrix on a breadboard to confirm functionality. If we identify any adjustments during this phase, I will update the schematic accordingly before constructing the full board.

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.

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.