This week I was able to connect to the raspberry pi and get some preliminary code down for motor control, the camera has still not been set up and so the task of making the CV work on the actual physical system is still in play. Also the ML algorithm is pushed back a little now. I do not think this is a major issue as I started working on other parts in later weeks now due to the unset up hardware. I also started planning and working on the 3 boards for the software player who will interact with the hardware. Next week I want to have the CV fully down and working and have most of the ML algorithm done so that it will be functional in checkers and Sorry but not necessarily Chess yet. The week after will be finishing motor control and getting the communication between STM and raspberry pi set up.
Harrison’s Status Report 3/21/2026
I started working on connecting our motors up to the gantry with Chris. Our goal is to get all the movements working during our first meeting on Monday, work on setting up the camera system on Tuesday, combining these two aspects on Wednesday, and meeting for extra time if we are not finished during the rest of the week.
Iniyaa Status Report 3/14/26
This week I worked on the project mainly through design/planning work, and project coursework that supports the overall development of FlexyBoard. I spent time along with my teammates looking at the specific magnets we need for the gantry, and I also worked on the ethics assignment tied to the project, which took a meaningful amount of time and will continue to feed into our design decisions. In addition, I contributed to progress on materials/planning for the build, including work related to the magnets and game boards. I’ve done work looking at the gantry and figuring out how the dimensions of the gantry will work with our game boards. We’ve noticed that the x-y plane the gantry covers is not centered on the plexiglass encasement so we are trying to figure out how to place the game board. I made a few small modifications to the gantry removing previous parts that were there since we are using a second hand gantry. I would say my progress is generally on schedule, although next week needs to be more focused on direct implementation work so we can keep pace with the build and testing timeline. To stay on track, I plan to spend more time on the actual gantry work next week while also continuing discussion with my team on the ethics portion. My main deliverables for next week are writing some preliminary code to get the gantry moving to specific x-y positions.
Team Status Report for 3/14/2026
This week as a team we found a space in 1200 section of Hamerschlag where we can store our gantry as the current frame is too big for the red boxes. We talked about some of the specific design choices in our project and finalized details on subsections. Furthermore we ordered about 200 magnets as well as boards for all 3 games, chess, checkers, and sorry. Next week we will begin to add the camera and start incorporating our software to test the first subsystem and test whether move detection is handled properly, and plan to have by the week after the motors working and coordinating with the raspberry pi/CV to be able to actually move pieces
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.
Team Status Report for 2/21/2026
As a team we worked on our design and how everything would work together, we talked after our presentation and realized a couple adjustments we needed to make as to consider certain possibilities like in chess if we had two pieces that could be taken by a knight and the user took one, we would have no way of knowing which unless we also had a piece classifier in our CV. We also constructed a list of items we want to order and overall worked on solidifying our design and components.