Category: May’s Status Reports

This week most of the time was spent on the final presentation content. Additionally, I tested all the pegs to ensure they were aligned with the buttons and would press securely. I also worked on glueing the boats, flags, and magnets with the team. We also spent time fixing some small visual aspects like the tiles, water, etc. In terms of schedule, we are ahead of our planned timeline and are exploring further software features, however, the final video and report will be our main focus. 

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.

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.

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.

This week I iterated on several CAD versions and made quick laser-cut prototypes to check size and fit. I created CAD for the base board, hex tiles, dice plate and walls, and tokens, and then used the laser cutter to cut and engrave those parts. For the dice plate, I made versions with different wall heights and different wall designs. With the team, I measured spacing between LEDs and cities/settlements and accounted for kerf and a bit of wiggle room so parts place easily – the board cutouts are slightly larger than the pieces. The prototypes confirmed fit and engraving depth and helped me find the best power, speed, resolution, and number of cycles settings for the Epilog machine. The new board has LED-only holes to hide wiring and a shallow divot so tiles don’t move. The dice plate has a locking rim and a smaller hex cutout so the camera can see through the clear plate from underneath.  I ran into issues separating engraving and vector layers because the part was 3D but the DXF export is 2D. I fixed this by redrawing some shapes in CorelDRAW and adding extra sketch outlines in SolidWorks before exporting. Additionally, each full board run takes about three hours, and TechSpark hours sometimes pushed cuts to the next day.

Next week I plan to finish the CAD and cut the middle board that holds the buttons so soldering is stable and aligned with the LEDs. We’re a bit behind because making the cutouts exact took time and we had a setback with the buttons, but we’ve ordered new parts. Now that we know the build, we can move faster and make a second board in parallel. After the middle board CAD and cutting are done, I’ll help with the switch matrix build.

Number Tokens

SolidWorks Board

CorrelDraw Board

The acrylic in the middle is clear, but above has a blue plastic cover on it.

This week the team and I worked on the Raspberry Pi and the LED strip. I ran small test scripts on my laptop and on the Pi to learn the LED API and how to address colors. I brought up basic patterns and started checking timing and per-tile addressing. Early signs look fine, and I have more checks to finish.

I also worked on how to connect to the Pi. I tried SSH and a direct wired setup and wrote down the steps for each. I fixed a few small network and permission issues while testing.

Our last part arrived on Thursday, so full assembly can start next week. I plan to help assemble the switch matrix and bring up a small section first. I’ll write a simple scan test and check that the switch events map to the right LEDs. After that, we’ll scale to more tiles.

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.

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.

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.

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.