Posted on

Tanisha’s Status Report for 11/22/25

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

Posted on

Team Status Report for 11/22/25

This week we made major progress on both the software and hardware for our synchronized Catan boards. As we implemented and debugged the system, we had to learn several new tools along the way. On the software side, we learned how to get the Raspberry Pi camera working reliably with OpenCV, how to tune the dice-detection algorithm using DBSCAN, how to fix issues with FFmpeg and v4l2, and how to manage socket threading so both boards stay synchronized. On the hardware side, we learned how to fix LED soldering issues, wire neopixel rings more reliably, and use the laser cutter to create updated tiles, dice plates, and structural pieces. Most of this came from informal learning—videos, forums, GitHub issues, and trying small examples until we understood the behavior and could incorporate it into our system.

Several risks still remain, but we have plans in place to manage them. Dice detection can still be sensitive to lighting and angles, so we tuned parameters extensively, redesigned the dice plate, and tested many camera settings. Our fallback is a manual-entry button if detection ever becomes unreliable. Another risk is the two boards falling out of sync, so we built a save-state system and a resync request so the boards can recover automatically if something goes wrong during gameplay. Hardware reliability, especially LED joints, was also a concern, but after fixing the soldering issues and reinforcing the wiring, the system is now stable. Structurally, the board needed more support because we shrank our layout, and our original design only had space for six numbered tiles; we had four extra numbers, so we added them as corner stand-up resource tiles, which required extra wiring. We will strengthen the board next week with magnets and better adhesion.

We also completed several stretch-goal features. We implemented a save-state system, added clear-board logic controlled by physical buttons, and even added support for multiple players on the same board. These features added time, and the wiring for the extra corner tiles increased complexity, but each addition improves the usability and robustness of the final product. All three stretch goals are fully implemented and working.

Throughout the week we steadily integrated all of these pieces. On Monday, we finalized the dice-detection algorithm on the Mac and got messages sending correctly from the Pi. On Tuesday, we fixed camera issues on the Pi, moved the full dice pipeline onto it, laser-cut additional dice plates, and achieved working synchronization between both boards. On Wednesday, we soldered the pin headers, laser-cut the tiles and the base board, assembled the entire physical structure, added the clear-board buttons, and finished the sync and save-state code. At the end of the week, we fixed several LED soldering problems, tuned the dice algorithm, laser-cut the remaining numbered fixtures, added lights for the tokens, and glued all the resource tiles and water pieces for the final board design. We also finished the multiplayer stretch-goal code during this time.

Overall, we are in a strong position. The core system is working, the stretch goals are complete, and only minor debugging, minor aesthetic improvements, and physical reinforcement remain before the final presentation.

Below is a photo of how one board looks like:


Below is a video demonstration of a 3-person game (we have a feature where you can enter the number of players 2-4):

https://drive.google.com/file/d/1aihQ5PfYeqy9WeP17BvGSp3CvyLi_z7i/view?usp=drive_link

Posted on

Rhea’s Status Report for 11/22/25

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.

Posted on

May’s Status Report for 11/22/25

This week I helped solder header connections for stable wiring and finished assembling the base board. I wired and soldered the save-state and turn-toggling buttons, plus a new set of LEDs for each board to light up ports and improve dice visibility. I worked on testing with the team, where we found a few small bugs to fix.

We had a setback when one LED strip lost connection and the copper pad ripped off. Because the button board and LED board were already joined, replacing that LED while keeping indexing consistent took time, but we were able to swap it and resolder everything more securely. I also helped assemble the ports and glue the visual pieces (water pattern and resource tiles) onto the board. We are ahead of schedule and have most of our stretch goals implemented. Next week I want to help finalize the presentation, record a better demo video, secure the button rods, and help debug remaining software issues.

I also had to learn more detailed CAD skills to design robust parts that could handle multiple iterations and different cut depths. I reviewed past course material, watched online videos, and asked TechSpark staff and friends for help, especially for modeling layered cuts and understanding the switch matrix. Most of what I needed came from knowledge in our earlier classes and projects, and I filled in the gaps with a few targeted videos, quick references, and small experiments.

Posted on

Rhea’s Status Report for 11/15/25

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.
Posted on

Team Status Report for 11/15/25

This week we finished the first board and got ready for the interim demo. We figured out how to connect the button board to the LED board and assembled the stack. We also finished the software that maps buttons to LEDs. It now enforces that the robber is in only one place. If two presses happen at the same time and they aren’t adjacent, we ignore them without an error.

After the demo, we built the second board using what we learned from the first. We cut and assembled the switch matrix, reworked the LED layout, and did the soldering. We fixed switch-matrix issues and a Raspberry Pi connection bug. We also glued houses, glued LEDs, cut dowels, and laser-cut extra pieces and tokens. We updated the software for the second board too.

Both boards are now fully assembled with full functionality, so we can shift our focus and prioritize software.

Validation:

    • Board synchronization: We will trigger the same action on both boards and compare LED states and game state after each step. The test passes if there are no mismatches in the test log.
    • End-to-end latency: We will measure time from a button press to LEDs lighting on both boards using timestamps or a simple stopwatch video. We will check the result against our latency target from the design report.
    • Full gameplay run (rule-agnostic): We will run a short game flow: setup, placements, resource rolls, robber moves, and a long turn. The run is valid if interactions work, states stay consistent, and no manual rework is needed to recover from normal play.
    • Usability check: Two people not on the team will set up the board and play a short game without our help. We will record task times and note any confusing steps.
    • User Study: We’ll ask 4–6 participants to rate (1–5 Likert) setup ease, feedback clarity, responsiveness, piece placement, and confidence to use without help, plus note one confusion and one change.
    • Safety and Durability: We will tug-test connectors and inspect for sharp edges or exposed wires on the final build. The build passes if nothing comes loose and there are no hazards.

Shared Verification:

  • Button board + dowels: Measure dowel height and press each site 20 times. Pass if each press triggers once (≤1 miss) and no double-triggers.
  • Switch matrix: Press every button 20 times and try adjacent/non-adjacent simultaneous presses. Pass if ≤5% misses, 0 ghosting, and non-adjacent pairs are ignored.
  • Solder/continuity: Inspect joints and check rows/cols and LED conncections with a multimeter. Pass if there are no opens or shorts.
Posted on

May’s Status Report for 11/15/25

This week I worked with Rhea to finish the first board. We finalized the button-board to LED-board connection and assembled them. Together we ran modular tests—LED and indexing, the button board, and both together—to check mapping and behavior. I also helped prep for the interim demo and updated the Gantt chart with Rhea.

For the second board, I laser-cut the LED board and two iterations of the button board. I worked with Tanisha to restructure the LEDs and run quick checks (LED pattern and switch-matrix tests). I helped assemble the button and LED boards, setting the dowel height so the buttons press reliably. With Tanisha, I updated Rhea’s mapping code for the second board and tested the full system to confirm it works end-to-end.

Verification of Board Design and Peer to Peer Connection Subsystems:

  • LED board tile fit: Place tiles and lightly tilt/tap the board. Pass if tiles don’t slide, are held by the engraved divot, and still lift off easily.
  • LED cutout alignment: Check that each cutout lines up with its LED centerline. Pass if alignment error ≤0.5 mm and no LED is occluded.
  • P2P connection: Peers connect and stay connected without errors.
  • P2P state match: After each action, both peers compute the same state (hash or event log matches).
  • P2P ordering/duplicates: Out-of-order or repeated messages are handled once only.
Posted on

Tanisha’s Status Report for 11/15/25

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.

Posted on

May’s Status Report for 11/08/25

This week, I worked with Rhea on building and testing the switch matrix. We ran into a few minor connection issues, which we resolved through testing and soldering. I also helped soldered the LEDs to fit the Catan board cutout, working modularly and testing as we went. We verified the switch matrix by testing each button individually and checked LED connectivity every few strips.

We encountered more soldering issues than expected when securing the LEDs, so to make debugging easier, we split the LEDs into two separate strips. Our original plan to minimize soldered segments made sense at first, but bending the LED strips to fit the settlement and city layout (three LEDs in a peace-sign shape) caused problems, so I resoldered the broken connections and replacement LEDs. For future builds, we plan to solder those connections separately to avoid bending the strips altogether.

Since both the hardware and software components, switch matrix and LED wiring, now work independently, we’re ready to connect the two boards and start testing how they interact. While assembling the board, we realized we need to add a frosted acrylic layer above the tokens (to mark robbers) and leave more space between the LEDs and buttons. We also decided to fill the engraved numbers with black ink for better visibility.

In addition, I laser-cut the second LED board cutout and the switch matrix. We tested alternate buttons with a higher height, but they proved unstable and sometimes got stuck when pressed. Through this week’s testing and design adjustments, we’re confident we can build the second board more efficiently with these improvements.

Next week, I’ll help finish assembling and testing the second board.

Posted on

Tanisha’s Status Report for 11/08/25

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.