Now with the addition of the IR sensor and knowledge that the card condition is critical to the dispenser accuracy, we are less concerned with the dispenser accuracy. We also did not see a failure during the interim demo this week, which is a positive as well.
In terms of software risks, the main thing is our change to an asynchronous architecture between the various software subsystems. If the parallelism stops us from achieving correctness, then we will switch to an interval polling based system that does all of the polling the system needs to do at the end of a fixed time period or after a turn. This will hurt our responsiveness and make the code more fragile but it is easier to reason about and closer to what we have now which is mainly blocking.
There is no significant change to our system design nor schedule.
For validation, it will be simply playing multiple games of uno as a normal player. We want to make sure that we minimize the number of times we have to manually modify the state of the game using the website, either due to the dispenser or the classification making a mistake. We want to make sure it interacts with the players correctly and promptly using the buttons, and the state of the game gets updated on the website.