Posted on

Harrison’s Status Report 4/4/2026

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:

  1. For our verification and testing phase, we want to focus on consistent accuracy over the course of a board game’s piece movements. For testing, we will have multiple users of different backgrounds play the three board games we support, and they will report whether each of the movements made by the gantry is accurate or not accurate in a survey. Along with this, they will also report the accuracy of the CV in detecting their moves correctly in the same way. We want to ensure the enjoyment and playability of FlexyBoard as described in our use-case requirements.

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.

Posted on

Iniyaa’s Status Report 4/4/26

This week I was primarily focused on the Interim Demo. I made a slide deck for the demo and worked on polishing the appearance of our current setup to make sure things go smoothly for the demo. I’ve started planning the player 2 interface that will communicate with the raspberry pi to reflect the moves made on FlexyBoard. I am a bit behind compared to the original schedule we wrote in our design report, but I am on track for the updated schedule we included as part of our interim demo. I am still on schedule for the final deadline. In the next week I hope to make significant progress on the player 2 interface. My goal is for the computer interface to be fully functional with checkers.

For the player 2 interface I will verify that a remote player can correctly view the board state, input moves, and receive updates from the physical board, while measuring move-entry accuracy and ensuring both boards remain fully synchronized over multiple turns. Since the player 2 interface is on my computer, I do not feel the need to do any repetition tests and I plan to primarily verify its functionality by making sure it is 100% accurate during regular game play based on the inputs it receives from the raspberry pi. Currently, I am testing jumping over pieces in checkers using a mock rpi interface using a python tool.

Posted on

Team’s status report for 4/4/26

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.

Posted on

Chris’s Status Report for 4/4/26

This week, a major part of it was making sure parts worked together and getting ready for the Demos. I made some improvements to the CV system which had included splitting detection into multiple parts. There is now detection after the camera captures an image on the Pi. This includes a region identification for the entire Flexyboard which shows up on the image in a green grid, there is also detection for the subpart which shows up in a yellow grid (and also lays out the 64 squares). Upon improving this system this week, I had also worked on the communication between the Pi and the STM32. The Pi can now send commands to the STM32 as well as move coordinates such as 0,0 -> 7,7 (this system would be useful for chess and checkers but we would need a more precise variant for parcheesi). The upcoming week I plan to move the CV instead of using the 64 squares for chess and checker to feed output move data detection by where it is proportional to the overall board, this will make this system work better for parcheesi. I will also plan by next week to implement the software algorithm to detect if pieces need to be moved out of the way before making a piece move and then moved back. I plan to do this by detecting how many squares have pieces in the way and calculating the minimal amount of pieces that need to be displaced for a piece to make its move (it could be blocked).

Here is an image of the current output:

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?

For the verification part of this, I am focusing on the computer vision (CV) and board state detection subsystem, along with the Pi to STM32 move-command interface. The main requirement for my subsystem is that it correctly detects board state changes and produces accurate move outputs reliably enough for the full FlexyBoard system to function. In our design requirements, one of the main targets is at least 95% correct move detection accuracy, so my verification testing is centered around measuring whether that threshold is met.

To verify this, I will run repeated trials in checkers first, since that game is currently the most functional, and then expand to chess and Parcheesi as the detection method becomes more generalized. For checkers, I will play full games while recording, for every turn:

  • the true move made on the board
  • the move output predicted by the CV system
  • whether the detected move was correct
  • whether the board region and square grid were identified correctly
  • any failure type, such as missed detection, incorrect source square, incorrect destination square, or piece visibility issue

From these trials, I will compute the following metrics to help quantify the system’s abilities:

  • move detection accuracy = number of correct detected moves / total moves tested
  • source-square accuracy
  • destination-square accuracy
  • board localization success rate
  • failure frequency by category

I will run enough total moves across multiple games to create a meaningful sample size rather than relying on one short trial. I will compare the final measured accuracy against the 95% design requirement. If the measured value is below that threshold, I will use the logged failure categories to determine the main causes of error, such as poor contrast between black pieces and dark squares, imperfect region detection, or square-mapping issues.

For the Pi to the STM32 communication portion, I will verify that coordinate commands sent by the Pi are received correctly by the STM32 by testing known coordinate pairs and confirming that the expected command is executed. I will record whether each transmitted move matches the commanded move and compute a command transmission success rate. This will verify that the communication subsystem is working reliably enough for integration into the larger project.

These measured results will be analyzed directly against the design requirements which we laid out int he design doc: if move detection accuracy is at least 95%, region detection is stable, and coordinate commands are transmitted correctly and consistently, then my subsystem can be considered verified for its intended role in the project.

 

Posted on

Iniyaa Status Report 3/28

I made a lot of progress this week. We have our gantry system and board setup so I spent a lot of time figuring out the mechanics of how we were going to attach the game boards to the flexyboard, where it sits with respect to the gantry system, and how to attach the magnets to the gantry and the game pieces. I hot glued magnets to all the game pieces. I also drew out game boards as the ones we ordered were too large and the magnetized pieces seemed to move better on paper instead of the thicker/clunkier cardboard game boards with creases. Also, none of us had played the game sorry in years so it was different than we anticipated and the game pieces were not compatible with our project design. Because of this, I stopped by Games Unlimited and found parcheesi, a game that works a bit better with FlexyBoard as it does require players to draw cards(like sorry does). All of us helped assemble the stand for the Camera, and I did a bit of cosmetic work with a hacksaw and file to smooth out the screws that were sticking out of the stand and it’s not such a safety hazard anymore. Overall I’d say my progress is on schedule, but we do have lots of things to get done in order to be prepared for the final presentation/showcase. I’ve picked up the additional responsibility of working on the software for the player 2 interface so that is what I will be working on next week.

Posted on

Harrison’s Status Report 3/28/2026

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.

Posted on

Team Status Report for 3/28/26

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.

Posted on

Chris’s status report for 3/28/26

This week there were a lot of things that happened. We finished testing with one motor which was quite operational. There was some choppiness which we were able to sort out. However when I connected all 4 motors one of the motors seemed to stop functioning well. I am not fully sure if something was shorted or if it’s a current/resistance issue. Will look more into this over the next couple days. Additionally, there was progress made with the CV detection. There were issues with properly identifying the corners of the board as we were still adjusting the size of the board and issues with identifying the pieces within the board. There was progress made in this domain but still not perfect. I set up a communication layer and state machine for the interaction between pi and STM32 although it is not perfect yet as I am still trying to work on getting the CV detection proper and functioning well.

 

CV Update:

Posted on

Team Status Report for 3/21/26

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.