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.