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.
Posted on

Team Status Report 03/30/2024

The biggest risks for us are still the card dispenser. We are redesigning the system so that we only have to reprint the front rollers and the card hole to save material and time. We hope that with the new prototypes and the new cards that we get, we are able to achieve a low error rate again, just like it was in the testing Thomas did.

We are adding one thing to the design. We are planning on adding an IR sensor to detect if a card was successfully dealt. This will allow us to better handle errors and it is very cheap, around $8.

We have not made any changes to the schedule, and we are all on schedule as well.

Posted on

Thomas’s Status Report 3/30/2024

This week, I have gotten test data for our dispenser. Using a new deck, I have dispensed 10 decks in a row and written down how many times the dispenser was not able to dispense a card. The data suggested 24 errors / 1090 cards, which is about a 2% error rate. However, while using the dispenser to test out the hardware interface later, I noticed the error rate went back up by a lot. We believe this is due to the cards themselves gaining friction between each other due to hand oil and card wear and tear over time. I have tried making the card hole smaller to fit just one card, but that seemed to not dispense due to the cards not separating, further supporting our theory. We have come out with a new way to more quickly prototype different card holes by separating the front portion of the dispenser from the rest of the body, which will let us try out many different iterations over the next couple of weeks. 

I am still on schedule, since the rest of my schedule is dedicated to testing and helping others to integrate the full system. Next week, I want to keep testing the dispenser with the new prototyping mechanism we have built. Also, we would like to test out adding IR sensors in order to provide automatic feedback on whether the dispenser failed or succeeded in dispensing the card.

Posted on

Jason’s Status Report for 3/30/2024

This week, I accomplished a few more things. Firstly, the card classification models have been tested. We found the most success with two separate models for the top and bottom cameras, but use the same color classification model across both of them. At this point, after at least ~500 times of using the models, we have not seen an incorrect classification. We will continue to monitor and train on new data if something comes up. Although I had implemented most of the UNO code around week 1 or 2, we finally got around to testing it live. We ironed out a few bugs with the implementation, and everything seems to be working now. I have also helped Thomas with making some modular modifications to the dispenser, which are being printed. We will continue to iterate on the dispenser over the next few weeks. I also began designing a new control flow to allow better async communication (such as from the website). I also made a crude GUI for visualizing the state alongside logging for debugging.

At this point, I am on schedule. This week, I will finalize the new software macro design and begin work on the website.

Posted on

David’s Status Report for 03/30/2024

This week, I fully implemented the hardware interface for UNO. We were able to start testing full UNO games using the machine this week. We ran into several weird bugs involving the TkInter based GUI and the hardware IO as the GUI stopped working once we switched to using the hardware controller. Jason and I finally fixed this issue after we forced the Tk display to update in a blocking manner instead of non blocking as usual. Also, our current implementation relies on blocking IO which polls the various buttons and serial interfaces. We started switching this over to an async approach which spins up another thread to do the polling. Also, the issue with the GUI should go away once we switch to a website interface which will have its server running in a different process.

I am on schedule. Next week I plan to finish switching the code over to non blocking IO and to start work on the website with Jason.

Posted on

Thomas’s Status Report 3/23/2024

This week was another week of testing out and modifying the physical parts, mainly testing the dispenser, collecting data for classification, and reorganizing the things inside the chassis. We had some issues with the dispenser’s consistency last week, so we decided to change the material used from the O-rings to some silicon rubber bands. At least from the couple hundred cards we have tested after, we have seen an improvement in the amount of friction on the cards. Thus, we never have a case where no cards are being pushed out. It’s just 2 cards trying to leave the opening at the same time that get stuck. To address this problem, we currently have a new prototype in the way that with a larger opening this time, hoping that the 2 cards will leave instead of getting stuck. Picking up a card that was additionally dispensed seemed easier than having to get the stuck card out of the dispenser. The internals of the chassis are also reorganized to have less wire tangling.

The last couple of weeks starting this week are integration and testing. I have already finished all the physical parts that are needed, and all that is left is to test and make improvements to the system until we meet the requirements. Thus, I am on schedule. 

Next week, I will test out the new dispenser prototype, and help others collect data and test out the software parts too. Once the software interfaces are done, I could also test the accuracy of the chassis rotation next week as well.

Posted on

Team Status Report for 3/23/2024

With the discard pile classification model giving us basically a 100 percent accuracy, our potential risks are just the card dispenser accuracy and the draw pile classification accuracy. As mentioned in the personal reports, we have a new dispenser being printed, and Jason is working on getting the bottom classification accuracy up, which looks promising so far. Also, the current dispenser accuracy with the new rubber band material isn’t too far off our requirement, which is also assuring.

No significant change has been made to our design of the system or the schedule, and all of us are currently on schedule. In the next couple of weeks, we will work on integrating and testing our project while also making some improvements on our own parts as well.

Posted on

Jason’s Status Report for 3/23/2024

This week, I made significant progress on the card classification algorithm. Initially, artificially creating new data before splitting up into test and validation sets was causing misleading results on the testing and validation sets. Also, the model I had designed was having issues with overfitting to the training data. Because of this, I switched to fine-tuning the ResNet18 model on our data instead of training a model completely from scratch. I have trained 3 card classification models, one trained on data from the top camera, one trained on data from the bottom camera, and one trained on both. Across all three of these models, the only image being incorrectly classified is pictured below.

I would argue thinking the card is a 1 instead of a 7 is more our fault than the model’s because of the glare, which we will mitigate by covering more of the backlight. Finally, I have a color classifying model, which is achieving 100% accuracy, as expected. Because of this progress, I believe I am back on track. This week, I plan on fully integrating the software UNO implementation with the hardware and begin work on the website.

Posted on

David’s Status Report 3/23/2024

This week, I collected a lot more data for the model.I took and labeled over 700 images.This was instrumental in increasing the accuracy of our model which now works great. I also assisted Thomas with testing the new card dispenser. After our testing, we realized that it’s basically impossible to avoid cases where 2 cards try to come out at the same time. Thus, we decided to change the card dispenser to just let the 2 cards out instead of having them jam the dispenser. This way, it’s at least very easy to recover from a fault.Lastly, I worked on implementing the uno hardware controller. I implemented the various commands that need to be sent to control the motors as well as doing the stuff to capture images and send them to the uno simulator. All code and labels for the images are in the git repo.

I am on schedule. Next week I will work on finishing up the hardware controller and starting work on the website.