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.