Posted on

Team Status Report 04/27/2024

There are no more major risks as all that is left is to add small changes to the website and internal software system. We did add new batteries just in case during the demo we needed to swap them out for more battery life. The batteries cost about $80 and we had the budget to spare. We shouldn’t incur any more costs. Schedule has not changed.

ADDITIONAL PROMPT:

Starting with the hardware unit testing, we tested out the body rotation and card dispensing first separately. We had the internal gear system as well as the axle ready, with a platform on top. The rest of the system was initially replaced with a comparable amount of weight on top of the platform to check if the stepper motor we chose was able to rotate a system up to 8 pounds. Once this was confirmed, we tested out the card dispenser. This took a lot of iterations to come to the final design. Throughout multiple iterations, the design of the slit that lets the card out has changed in shape as well as size that minimizes cards being stuck as well as 2 cards being dispensed at the same time. Toward the end of testing, we changed it so that the front of the dispenser is separable, making it easy to iterate multiple times. One major change was also changing the material around the rollers from o-rings to rubber bands. Rubber bands have a lot larger surface area touching the cards so they grab the cards more easily. On top of these, while we were able to get a good card dispensing accuracy, we noticed it might be better to add an IR sensor to detect whether a card is dispensed or not automatically. Adding self correction with the IR sensor basically made the failure rate very low.

We worked on some integration while unit testing the separate hardware as well. We connected the UNO and RPI using serial and made sure we could send a command from the RPI to the UNO and move the motors for rotation and dispensing, and everything worked out pretty well.

On the software side, we didn’t really have a lot of unit tests. Our testing methodology mainly worked around logging events in the system and then analyzing the logs when things went wrong. When moving to the asynchronous execution model, there were alot of bugs surrounding synchronization and deadlocking. We had to be very precise to avoid recreating the issue of blocking on io in the main thread. For our design requirements, we measured latency using the log files to find the time deltas between initiating and completing actions such as website updates and classification. Logging truly was a very versatile and useful tool for us as it allowed us to introspect how all of the asynchronous events were interacting with each other.

 

For the image classification portion of the project, we mainly operated on the accuracy results from our test and validation datasets. One key design change was to artificially generate new images (by rotating, scaling, changing saturation) AFTER splitting up the dataset. Otherwise, the images would be too similar across the datasets, and there would be very little difference between testing and training datasets. We also found that fine-tuning ResNet-18 worked significantly better than designing our own architecture.

Posted on

David’s Status Report 04/27/2024

This week I wrote and presented the final presentation. I also worked with Jason to debug the software. We also added more functionality to the website. The bugs surrounding displaying the score are now gone and we can now conditionally display cards based on the client’s role. For example, player 1 can only  view player 1’s cards and everyone else’s cards are rendered as an image of the back of an uno card. We moved everything to socket events to make everything more uniform and to avoid refreshing the page ever. This is to preserve the state.

I am on schedule. Next week we will work to add state correction as well as add support for variable numbers of players on the hardware (rotate variable amount).

Posted on

David’s Status Report 04/20/2024

These past two weeks saw a massive overhaul of the code base and lots of breakthroughs on the software side. Jason and I worked together on all of these changes. We finally finished moving over to a fully asynchronous execution model. This allows us to do full asynchronous IO and receive and send input to the website at any time. We also made large progress on the website. We decided to have the server talk to both the uno machine and the users over websockets. This allowed us to both host the server on a laptop instead of the raspberry pi as well as write simple code to handle updates to the game state at any time. We also added features for dealing with illegal user input and dealing with calling uno.We also removed the auto correction feature on a failed card deal as it was causing the arduino uno to brownout due to the current spikes. This is fine as it will just fall back to having a human intervene and fix the dealing failure.

We are on schedule. The plan next week is to continue refining the website interface and also allow for a variable number of players on the hardware side.

Additional Prompt:

There were many things that I encountered during the semester that I had never interacted with before. I had to read the documentation for both the Adafruit Motor Shield as well as the Raspberry Pi camera library. I also watched many videos with Thomas to assist in figuring out the mechanical design. I also looked at a lot of motor specifications and forum posts to find motors that met all of our power and strength requirements. I also learned a lot about web development as I have never designed a website before. I read official documentation, forum posts, and watched tutorials to navigate the muddy waters of javascript and html.

Posted on

Team Status Report 04/06/2024

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.

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

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

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

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

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.

Posted on

David’s Status Report for 3/16/2024

This week I generated the data set for the card classifier. This involved taking around 500 images and then hand labeling all of them.I also worked with thomas to continue fiddling with the card dealer. We finally found a setup that gives us pretty consistent results.

I am on schedule. Next week I will integrate my code to control the machine into Jason’s UNO controller interface that he has created to make it simple to have the UNO controller code also interact with hardware. I also need to write drivers for the number pad that we are using for user input.