Category: May’s Status Reports

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.