Chris’s Status Report for 3/14/2026

This week I worked on the CV implementation. I had taken two pictures of a chess board in different positions with my phone camera and processed those and it appears to detect correct between moves. However, because we don’t have the camera and board fully set up on our flexy board I have not been able to test. Next week, I plan to help setting up the camera and making sure the CV algorithm works fully with our project. This is slightly behind schedule, but I think if I can get this part fully working by the end of next week I can move on to our ML implementation for chess after and it will be smoother as the grounds for testing will already be in place. If we haven’t fully set up the camera system to take pictures, I’ll switch my tasks to work on the software GUIs first. I will also work on any code for the interaction between the camera and the raspberry pi next week to try to get that fully set up.

Harrison’s Status Report 3/14/2026

This week we figured out what we are going to start doing and where we will be working. We will be using a space in the ECE wing of hamershlag which has ample room to store our project. The gantry is already very large, and we wanted storage space to accommodate it when our project gets even bigger.

Also ordering extra magnets for pieces.

Chris’s Status Report for 3/7/2026

This week a large majority of my work was on the design document. I worked on Sections III and the corresponding block diagram, Sections VI, VII, VIII (including updating and making our gnatt chart more descriptive and BOM), as well as IX, references, and making smaller edits to other sections where required.

 

While this week the majority was dedicated to the design doc and the finalizing our design choices and components, I also begun working on local testing of our CV algorithm that will be used across all 3 board games. I plan to finalize this next week and then begin the ML portion for the piece classification of chess pieces.

Team Status Report 3/7/2026

The majority of this week was spent analyzing our project and considering all interactions within our system. We laid this out in our design document. We also further finalized our gnatt chart and included it in the design doc as well as our architecture and block diagram etc. We also included our BOM which we will be obtaining. Next week we will begin on the bulk of our actual work with assembling our gantry, CV, and making sure we have everything we need.

 

Part A (Harrison):

With consideration to global factors, our product is not going to be cheap (relative to what someone buys every day).  With that being said, when it comes to those without technical knowledge, our product targets those who want to play board games online but with physical pieces. We are trying to make the system as simple as possible such that anyone who can play board games will have the ability to set it up and play with those online or with another one of our systems. We also want the system to allow users to fix misplayed moves and system mistakes very easily so the gameplay experience is not impacted.

Part B (Christopher):

With consideration to cultural factors, FlexyBoard is designed understanding that board games are an important social activity for many different groups of people of many different ages. For a lot of families and communities, board games are a way to spend time together, communicate, and continue shared traditions. I know personally a lot of my most favorite childhood memories are playing board games late at night with my family. Because of this, we want to keep the experience of using a real board and actual, physical pieces instead of making the system fully digital. This helps preserve the familiar and social parts of gameplay that many people value.

Our design also considers that different groups may prefer different games as well as different styles of play. Some people may care more about competition, while others may care more about casual interaction and spending time together. By making FlexyBoard flexible to fit a variety of board games and easy to use, we hope it can fit the preferences of many users and allow people to connect through not just a purely digital approach.

 

Part C(Iniyaa):

Environmental factors were considered in the design of FlexyBoard by focusing on low power usage, material efficiency, and a modular system that avoids unnecessary hardware duplication. The system runs on relatively low-power components such as a Raspberry Pi, STM32 microcontroller, and stepper motors that are only active when a move is being executed. During most of gameplay the system is idle, which keeps overall energy consumption low. The physical board and enclosure can be fabricated from plywood using laser cutting, which allows efficient material use and minimizes waste during manufacturing.

Another environmental consideration in the design is the modular hardware architecture. FlexyBoard is intended to support multiple board games, such as chess and checkers, on the same physical platform without requiring separate devices. This reduces the need for multiple specialized electronic systems and lowers the total material and resource usage. Additionally, most of the components used in the system, including motors, microcontrollers, and structural parts, are standard off-the-shelf components that can be replaced or reused if something fails. Designing the system this way helps reduce electronic waste while still meeting the performance requirements of the product.

 

Harrison’s Status Report 3/7/2026

Worked on Introduction, Architecture, and Design Requirements as part of the design report. We now have a concrete plan for testing and have put into words the design and implementation of the parts we glossed over during our presentations.

We will be moving forward with our plan to set up the gantry movement to software connection alongside the first runs of the CV for piece tracking.