Tanisha’s Status Report for 10/18/25

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.

Rhea’s Status Report for 10/18/25

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.

May’s Status Report for 10/18/25

Most of my time this week was spent working on the design report and reviewing sections for submission. In addition to that, I focused on the mechanical and structural design of the board. I completed the CAD models for laser cutting the game tiles and began testing different materials, including wood and acrylic, to determine which would be the most durable and visually consistent for fabrication. I also reviewed how the board layout aligns with the switch matrix and LED wiring to ensure proper fit during assembly.

Part A: Global Factors
Our project responds to how people around the world spend time together. Many games today use screens, which can make people feel distant. By bringing back real, physical play, our system helps people connect in a more natural way. It can also reduce screen fatigue and make shared time feel more personal. The design reuses hardware like Raspberry Pis and cameras that are easy to find and use anywhere. This makes the system simple to build and supports global goals for sustainability and better use of technology.

Our system also focuses on people outside local or academic circles. Many players live far apart or do not have access to in-person game groups. Some may not be comfortable with complex digital tools. Because the boards connect over normal Wi-Fi and use real pieces, anyone can set them up without special skills. This makes it easy for families and friends in different places to play together through a simple, hands-on experience.

Team Status Report for 10/18/25

During this week, the team mainly focused on completing and submitting the design report. We incorporated feedback from the design presentation and made sure all comments were addressed in the final version. Since the presentation did not cover all required material, we finalized the overall system architecture and design requirements in the report. We also completed trade studies for key components, confirming the use of the Raspberry Pi 5, OAK-D Short Range camera, diode-isolated switch matrix, and WebRTC for communication. In addition, the team created sketches for the board layout and wiring design, organized the bill of materials, and finalized the Gantt chart showing each member’s timeline and tasks. We also ordered the parts needed to build and test a smaller prototype section of the board before full-scale fabrication.

Part A was written by May, B was written by Tanisha and C was written by Rhea.

May’s Status Report for 9/27/25

I spent most of Sunday preparing for the design presentation and presented it on Monday. I also made the switch from the OAK-D Pro Robotics to the OAK-D Short Range camera after learning that our first choice was unavailable and updated the design report accordingly. The OAK-D Short Range camera still has the main features such as the IR LED for low light vision and on board processing power. 

This week, I also finalized the list of materials for the board base and began creating the CAD drawings for laser cutting. I’m on track to complete these drawings by next week when I plan to schedule shop time to laser cut the pieces and perform a quick test fit to verify that everything aligns as intended, as well as work with Rhea to test individual components.

Tanisha’s Status Report for 10/4/25

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.

Rhea’s Status Report for 10/4/25

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.

Team Status Report for 10/4/25

This week, we finalized the parts list for our build. This includes materials for the board base, switch circuit components, and an individually addressable LED strip. For now, we’ve ordered enough to assemble one board. We plan to build a smaller version of each component so we can evaluate the materials and make adjustments before scaling up and building the full board.

Since our preferred camera (OAK-D Pro Robotics) was reserved by another group, we switched to the OAK-D Short Range camera. It still supports the close-up dice detection we need and should meet all of our technical requirements.

Following our design presentation, we met to revise and expand upon the written design report. Each team member will work on specific sections of the report, after which we’ll reconvene to integrate everything and finalize the draft.

One risk right now is shipping delays and minor adjustments from the camera change. To stay on track, we’ll continue testing with recorded video in place of a live feed and recalibrate once the new camera arrives. If time becomes tight, we’ll prioritize completing the report first then camera testing. If we are able to get shop time, we also want to laser-cut our first set of pieces for a quick test fit.

Another potential risk is the brightness of the LEDs. We need to ensure that roads and settlements are clearly illuminated, so if the current strip isn’t bright or dense enough, we may need to either switch to a higher-density LED strip or cut and re-solder individual LEDs to achieve the desired visibility.

Finally, we rebalanced team roles in the Gantt chart to parallelize the workload. The updated assignments are shown below.

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.

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.