This week, I started work on the website interface. I researched creating dynamic websites using Flask and implemented some basic proof of concept work on the website. Jason and I also fleshed out the new architecture that we will be using for the design which will involve using async queues to pass tasks between the UNO game state, the hardware controller, and the website interface. We wanted all of the tasks to be preemptable so that we wouldn’t get stuck blocking on IO or having to poll the website/state for updates. If this new architecture doesn’t work, we can switch to an interval based polling model that does all the polling that needs to be done at the end of a certain time interval. Lastly, I also updated the card dealing routine to automatically retry on failure (this uses the ir sensor we just bought to check for a card leaving the dealer) and eventually wait for human intervention if retries also failed. This allowed us to continue the game smoothly even when a card does not deal successfully.
I am on schedule. Next week I will work on implementing the website and the interface between the website and the UNO game state.
For verification and validation, alot of tests have already been done.
On the hardware subsystem, all of the testing was dependent on having working drivers for the motors so that we could deal 1000’s of cards and also rotate the platform many times. We checked the error rate of dealing as well as how much error we accrue when rotating. These tests correspond to what we have laid out during our design presentation. We also timed the latency of these actions and they are not far off from our limits that we set from the design presentation.
In terms of the hardware controller software on the raspberry pi, this was tested by integrating with the entire UNO game state and playing many hands of UNO. This was similar with creating and running separate subsystem tests for the hardware controller as it was very easy to tell which subsystem was failing when we just played UNO. If a certain move would cause an error, then we knew exactly which function was erroring out. For the keypad, I did test this separately to make sure all of the pins were configured correctly to avoid damaging the raspberry pi. This testing also served as validation for the entire system as pretty much everything except the website had to work for the UNO games to run correctly.
The last thing we need to test is battery life. We have not done formal battery testing but we plan on simply playing uno and timing how long it takes the battery to run out and making sure it is greater than the target of 1 hr. However, in our informal tests of simply having the machine on battery as we develop with it, the battery life seems well within our requirements.