Posted on

David’s Status Report 04/06/2024

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.

Posted on

Thomas’s Status Report for 4/6/2024

Most of this week was used to test out and do some minor tweaking to the system to get ready for the interim demo. With new cards, I was able to reproduce the low error rate dispensing, proving that the dispensing accuracy is highly dependent on the card condition. Also, David and I worked on integrating the IR sensor into the system, which was successful. This lets the user press one less button during the game, making it more automated. With the new filament we just got, I have also started printing different versions of the dispenser’s front end to test it out for the next couple of weeks. My goal is to minimize the times we have to manually pull out the cards from the bottom, and make it fix itself when it detects the card has not been dispensed this time. 

 

I am currently on schedule, and next week I would like to get the official chassis rotation testing data, test out different dispensers that are printing currently, and get IR sensor accuracy data for the dispenser. 

 

In terms of verification, a lot has been done so far on the hardware portion. Most of these were performed with David together as it requires some kind of driver/software to enable the motors. 

  • The dispenser has been tested by continuously dispensing 10 decks of cards(1090 cards in total), and I was able to get a sub 2% error rate, lower than our required 5% error rate. Also, the latency of the dispensing itself is measured both by using the delays in the Arduino code as well as physically timing it. It is a bit slower than our design requirements, but we figured it is necessary to give enough delay in order to get a higher dispensing accuracy. This only hurts during the initial dealing phase since the latency of card dealing in the middle of the game is easily masked by the human latency of thinking and putting down the card they want, making it a minimal change to the players. 
  • After the addition of the IR sensor, we checked that the sensor is able to accurately pick up (no errors so far) whenever a card is dispensed. I will get official numbers on the accuracy by dispensing a bunch of cards and see how many times it mistakes a dispense. We want to make sure that this is accurate, probably close to 95~97% so that we deal the right number of cards to each player. This was not part of our initial design, so we don’t have any numbers promised. However, it should be considered as part of the dispenser accuracy, so combined 95% accuracy, or 6 mistakes/deck. This will let the users not get too distracted to fix the errors in the game state. 
  • Chassis rotation has been unofficially tested by using visual inspection, and we are confident that it will stay within +-10 degrees throughout the game, which is our design requirement. I will be setting up the actual testing environment next week by marking the middle of each side of the chassis and the base. Then throughout a game, I will check if the angle between the chassis mark and the base mark stay within our requirement using a protractor. This ensures the card dealt is relatively within the reach of each respective player, and +-10 degrees seems appropriate.