Category: Team Status Reports

This week we focused on finishing our remaining tasks and our final testing/integration testing. We added a physical button instead of the purely software key. We finished adding a UI for parcheesi and the appropriate on board implementation. We improving our move planning algo and detection for the board. Cleaned up board swapping between chess/checkers and parcheesi for our demo.

Until the demo we still need to fine tune a few things mainly visual in terms of the board.

Tests:

Motors:

Move Completion time: 4.42

Placement accuracy across all 3 games: (100%)

Note/Change: This number was initially more inaccurate but after tuning down the speed and slowing down the magnet pick up and let go we were able to increase our accuracy.

Magnet Pickup: 100% succesful

 

CV System (Pi + Camera):

Diff Accuracy alone: 82% (detection of extra or too few squares means a wrong detection)

Full CV Accuracy with game rules and board state: 100%

ML Accuracy: 62% (initially)

Promotion Accuracy and Detection: 100%

Change: Our low ML Accuracy caused us to switch from a trained model to a system that stored pieces on the side of the chessboard and remembered them. This meant that for promotions it could take from the used pieces. Could also detect when player 1 promotes to one of these pieces and takes it.

Auto detection of Outer board: 75%

Auto detection of Inner Board if Outer board correct: 70%

Change: Made the user manually pick the corner points in software. Coupled with changing the outer board corners to a unique color for auto detection and then using fixed geometry for inner board and then manual user confirmation.

 

Player 2 GUI:

Ran tests for invalid move detection on all 3 games: 100%

Ran tests for correctly updating given the move from the Pi:

For Chess: 100%

For Checkers: 100%

For Parcheesi: 100%

Integration Tests:

Ran through 10 full games of Chess, Checkers, and Parcheesi.

Ensured no build up in error, ensured software state matched physical state, ensured accuracy throughout the game: 100%

Session reliability: 5 game of each type was played back to back to back to ensure we didn’t need to recalibrate (for at least an hour). Total duration took 4 hours.

User Enjoyment: Ran study to ensure > 80% like it more than strictly virtual We received 100% enjoyment. (Tested on 10 people)

 

This week there was a lot of integration that went on between the systems. Here is our combined repo code:

https://github.com/ChrisBernitsas/FlexyBoard

In terms of progress we:

integrated the CV, GUI, Pi bridge, and STM32 into one end-to-end system.

Added off board capture spaces and legal move validation for chess/checkers

Added A* based movement around pieces

Kept improving Software GUI

Kept fine tuning motor accuracy and tuning how it took inputs from the Pi (works on percentage system, square system, or coordinate system now) This makes it robust for more games.

Moved to contour-based CV detection. When testing the outer board and chessboard detection part seemed to be not up to our accuracy standards so currently it’s a manual selection at the start of the game and will be reverted back to automatic this week when we can get a unique color to outline them.

Did unit/integration testing between and for subsystems based on our design report and have numbers for some systems.

Our next tasks are as follows:

1. Fix magnets on Chess pieces/Finish Checkers pieces (I think 3 missing magnets and some are flipped polarity from the gantry magnets)

2. Improve detection of outer board and inner chess/checkers/parcheesi board unless we stick with manual.

3. Improve our system so we can slide boards in and out for fast change. (Velcro system).

4. Incorporate button for ending turn instead of enter key

5. Allow software to, at any time, update the game board with any new position/promotion

6. Promotion testing from captured area/ML

6. Confirm and fully test Algo for moving through obstacles and off board

7. Finish updating parcheesi UI in software (and all features/rules) and label squares virtually so that they can be used when sending commands.

8. Test accuracy of motor control coupled with CV system and algo for full games of parcheesi/chess/checkers especially

9. Potentially automate camera detection of if its chess/checkers/parcheesi board so don’t have to manually input (will automatically know which rules and potentially GUI to use) instead of manual selection/input

As a team we focused on preparing and having everything ready for the Interim  demos this week. We each prepared one piece of the overall system and got to show some parts of it off at demo specifically for checkers. In the upcoming weeks we plan on implementing player 2 software, the algorithm for moving pieces out of the way and captures, and the communication between Physical board -> Pi -> player 2  and player 2-> Pi -> STM32. (the pi -> STM32 part is already done). We realized that for some boards the CV may struggle with the black checkers and chess pieces on the board if the squares are also black so we may order boards with different colors.

Extra Question:

In particular, how will you analyze the anticipated measured results to verify your contribution to the project meets the engineering design requirements or the use case requirements?

Validation:

For the validation part of this, once we have player 2 and the connections between the microcontrollers to player 2, we will validate that the entire system works by first testing the system on one move. We will make the first move physically on the board and see if the CV system output is correctly passed to player 2 in software. If this is updated properly we will make the player 2 move in software and see if this output is correctly passed to the Pi and then to the STM and then made correctly on the physical board. If this full cycle works for one move, we will play a full game (chess, checkers, then parcheesi) to see if it works on all games and the consistency and note any flaws and correct them.  A successful validation trial means that this full cycle completes without manual intervention and that the final physical board state matches the software state. If this holds throughout each move and throughout the game we can say our design is validated. During this process we won’t just look at if it works but also all failure types. This includes the above aforementioned:

• physical board state matches software
• no manual intervention
• works across supported games
• acceptable accuracy in terms of where the pieces are and reliability throughout the whole session
• incorrect CV detection, incorrect software update, incorrect communication between components, incorrect physical piece execution
• loss of consistency over multiple repeated turns (if pieces get slightly farther from their correct location and error builds)

To analyze the measured results, we will record for each turn (1) whether the move was completed successfully, (2) whether the physical board state matched the software state, (3) whether any manual intervention was needed, (4) and what type of failure occurred if the turn failed.

From this, we can calculate a

• turn success rate,
• game completion rate,
• and consistency rate over repeated turns.

We will compare these results against our use case requirements by checking whether the system can reliably complete moves and full games across supported games without manual correction and without accumulated positional error. If repeated trials show that the board state remains synchronized with the software state and the system can complete games consistently, then the overall design will be considered validated.

As a team, we finished developing the arm for the camera for the raspberry pi and properly got measurements for it which we then made an arm made out of wood and attached the Camera too. All the hardware aspects should be done now and we are making progress on the CV and control components with the motors. We plan on demoing our project with checkers and plan to have the CV and motor part and communication between the pi and STM. The player 2 software and ML piece classifier for chess will probably not be fully done and will have to be completed after the demo.

During this week as a team we worked on the ethics assignment and had out ethics lecture on Wednesday. We got to thinking about our product in the real world and how it affects stakeholders. We will keep thinking about this as time goes on.

As a team we have an order in place for remaining parts which include the game boards and 200+ magnets which we will need and can hopefully use soon.

We are slightly behind in some tasks but ahead in others. Overall we are on pace and plan to spend next week getting the full movement system working between the motors, raspberry pi, and STM32.

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

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.

 

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.

As a team we discussed feedback from last week and made specific decisions regarding our MVP and then discussed design options for the hardware and connection to software. We also requested items from inventory and found specific hardware pieces to order and discussed how we would make our gantry. We worked on our slides and prepared for Monday’s presentation.

Worked on the presentation this week, along with discussing our first steps toward what should be completed now and in what order. Also discussed what sort of games we want to support.