Chess Pog is the prototyped solution designed by Praxis team 62, (Ryan Qian, Yingxuan Qi, Aman Saggi and Eric Wei), to address the opportunity of assisting Hart House Chess Club players in recording the moves in a chess game. The timeline of this project and tools used can be described as: root cause analysis to redefine the proble, biomimicry to diverge solutions, various different prototyping to represent the proposed solutions, and verification testing to conclude a final proposed solution. Following root cause analysis which redefined the opportunity to creating an automated move recording system, biomimicry was used to diverge a magnetic button solution, a button solution, and a computer vision solution. Then prototyping was used to represent the proposed prototypes, to later undergo verification testing to converge to a final solution. Our finalized solution was a computer vision program that does an analysis on the board state whenever players use the clock, to then find out the move between each board state. Moving forward we will discuss the effects and future viability of biomimicry, our prototyping methods, and verification testing.

Biomimicry - Diverging

As we redefined our opportunity to creating an automated move recording system, biomimicry was extremely useful in diverging ideas as we were able to take inspiration from the different methods of detection animals use. We were to diverge many different ideas from this method, such as using magnets, sonar, computer vision, and even changing colours (Figure 2). In parallel to my value of resourcefulness , biomimicry is similar to "building on the shoulders of giants", as we are able to "build" on the shoulders of nature. This tool was extremely powerful in my team's project as we had to find ways for a program to detect changes, however we must acknowledge that the nature of our project was biased towards biomimicry's usefulness and that biomimicry may not always be the best tool when it does not align to your approach and problem.

Functional Prototyping - Represent

Following a short stage of converging ideas, my team created three prototypes for Beta Release, which were a magnetic button solution, a button solution, and a computer vision solution. The three solutions are shown in Figure 3. Two of the solutions were functional prototypes, while the button solution was described using diagrams. We approached prototyping with ideas of adaptability evident by the small prototype in the second red box (Figure 4). To remain within the constraints of prototyping and using MyFab's sensors, we only created a small section to represent the board, while still portraying the ideas of the design. Furthermore, while creating the computer vision program, we transfer trained our model based on researched open source models online [2], showing elements of resourcefulness . Functional prototyping was a strong tool, as it not only allowed us to represent our ideas to our TAs, but it also allowed us to access the feasability and functionality of our ideas. For example, when demoing the magnetic button solution, we were able to see that it would not work well if players slid their pieces around the board rather than directly picking up and placing down. Realizing this was important in addressing the feasability of each system, and ultimately led to eliminationg the magnetic button solution. In the future, functional prototyping is a tool that I will continue to use, however it is limited by the feasability of constructing the prototype. However, if functional prototyping is difficult with a certain design, it can be an indicator that the design is infeasible. Thus, I believe functional prototyping to be a powerful tool to consider, but not necessarily always follow through with.

Verification Testing - Converging

Following the prototyping of the solutions it was time to test the designs. Our team's two most important objectives were: 1. the system must not require permanent change to the board and pieces, and 2. the accuracy of the system. The button solution was eliminated without testing needed, as it would have required permanent changes to the board to install a sensor. The magnetic button solution however could have been created by placing a board ontop of magnets and making a magnetic bottom to connect to pieces, so the prototype was tested against the computer vision design. Testing was done by simulating a game of chess and comparing the accuracy of the two designs. Figure 4 is a graphic displaying how the computer vision design was tested. While testing with the magnetic button solution we did not drag the pieces, to simulate ideal conditions of the design, which we initially predicted to be highly accurate. However, the magnetic button solution was vastly inaccuarate, as a single mistake in the game would cause the entire game to be inaccurate (this is because the magnetic button solution does not update its knowledge of what pieces are on the board, only the movement, so its predictions are based on the initial board state). In comparison, the computer vision design was able to accurately detect moves, to higher degree than expected. This is a great example of how verification testing is a powerful tool to converge designs, as it allowed us to see the strengths and weaknesses of each design. Which may have been missed had we compared the designs from secondary research and theoretical analysis. Relying too much on thereotical analysis can be dangerous, and lead to impractical and or infeasible designs. Verification testing is a powerful tool I will continue to use given the opportunity.