Posted on

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.

Posted on

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.

Posted on

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.

Posted on

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.

Posted on

Rhea’s Status Report for 9/20/25

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.

Posted on

Tanisha’s Status Report for 9/20/25

This week, I focused on preparing and practicing for the proposal presentation. This pushed me to think further about our use cases and implementation details, such as whether multiple boards would be necessary for the MVP. After receiving questions and suggestions during the proposal presentation, I reevaluated some of these considerations. For example, I looked into hosting the server directly on the Raspberry Pi instead of using WebRTC. However, it became clear this would not be scalable and could potentially overload the Raspberry Pi, especially if we plan to incorporate some of our stretch goals (e.g., saving the game state) in the future. My progress is on schedule, and I plan to complete a basic software diagram showing the communication between the board and the server within the next week.

Posted on

May’s Status Report for 9/20/25

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.

Posted on

Team Status Report for 9/20/25

As a team, we mainly discussed our circuit design. The most significant risk that could jeopardize the success of the project is making sure all the buttons and LEDs on our board are reliable and consistently work. We are managing this risk by carefully and thoroughly planning the design, specifically the wiring. We are not as concerned about the buttons for the settlements, but more about how the roads will light up functionally. The contingency plan for the roads is to either add another button on top of the board that lights up an LED or use a button LED component. The latter would be preferred due to ease of implementation and fewer components to wire. However, we are still looking into what possible LEDs exist that meet this requirement, and we haven’t been able to find any affordable options yet. So far, we have not made any changes to our existing design as we are still working out the granular technical details. We remain on track with our schedule. All team members contributed to the system specification and implementation plan sections of the design presentation content.