Carnegie Mellon ECE Capstone, Spring 2026 | Harrison Hayward, Iniyaa Mohanraj, Christopher Bernitsas
Continued work on individual game finalization and system integration.
Game board swapping and final code implementation for subunits finalized. Ensured accurate movements tested with our final magnet-modified pieces.
Finishing up the final algorithms and connecting the P2 online interface to the Raspberry Pi and STM32 motor control systems.
Worked on the Final Presentation presented by Chris.
Started work on the finalization of ML and algorithm (special chess movements) integration. This includes the movement of pieces out of the way when moving pieces like the knight and tracking of taken pieces to be used for promotions.
Very simple design to make the outside of the machine look nice (black cloth) around the edges, while elevating the machine.
Extra Questions:
1. I have had experience coding motor control code in the past, but I have never used an STM32. Chris was a big help as a knowledge base for using the STM32 since he took Embedded. Along with this, setting up the software connections and getting to the point where I could run code off of the STM32 after installing drivers, YouTube tutorials and AI were helpful in my learning of setting up the IDE and updating the system.
2.
Completed our Intrim Demos this week, spending a lot of time to get the system working and presentable. Fixed some parts of the gantry which were coming loose after modification. Focusing on ML model and CV refinements to distinguish between pieces for games like chess. Also focusing on integrating the gantry with a table and tabletop to have a more standard board game playing experience.
Extra Questions:
The subsystem I worked on was the microcontroller code for the stepper motors. We have found that slower gantry movement leads to more accurate movements, and we adjusted the speed to have an arbitrary balance of accuracy and speed. Based on the tests, I will be able to either increase the speed for faster movements if it is already accurate or decrease the speed to increase movement accuracy if it is too inaccurate.
Worked heavily on the gantry. Wired up all motors and drivers to STM32 and tested all of their movements. Calculated maximum number of steps to take advantage of the full gantry space and calculated the ratios between the checkers board squares and converted them to steps to accurately move pieces to different locations on the board.
Working on sending Raspberry Pi data to STM32 to control movements now.
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.
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.
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.
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.
This week I worked on getting the final list of parts we will need to make the x-y gantry before we integrate it into the table while ensuring compatibility. We plan to order these parts as soon as we can at this point. The following is our current list of items to complete the first iteration of the gantry.
https://www.amazon.com/hz/wishlist/ls/1KEQ64R8VOND3?ref_=wl_share
While working to finish our design implementation presentation, I have created a concrete list of parts we will need to build the gantry. Along with this, I have found a physical design that I hope to use to control the gantry. We also have the opportunity to buy a gantry that was used by some of our friends who needed it for one of their previous projects. We will look into this but we are going full speed ahead with designing/planning to make the gantry on our own:
