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

Jason’s Status Report for 4/27/2024

I spent most of this week collaborating with David on the website and correctly implementing round resetting / game resetting. We also spent time debugging problems with the displayer while improving the website. We are now able to support role selection, game resetting, and round resetting. For each of the roles, it will either show the player’s cards (if that player is you), or it will show the back of the cards. The state roles include “moderator”, “unassigned”, “player 0”, “player 1”, … I am on schedule to finish before Wednesday of this week. Before Wednesday, David and I will implement state correction on the server side and ensure that any misclassifications will signal for correction instead of crashing the system.

Posted on

Thomas’s Status Report for 4/27/2024

Not much has been done on the hardware this week except for some testing and receiving the new parts: new batteries and stepper motors. I have tried the dispensing and the rotation again using the old motor, but the motor accuracy got better again, and the reverse direction doesn’t seem to be losing as many steps as last week. I believe after not testing it for a couple of days, the temporal wearout from overheating or usage has gotten better. I’m most likely going to save the new motor in this case for next week’s Techspark demo and Friday’s real demo. The card dealing also seems to be sufficiently consistent. Also, I have changed the internal gear used for chassis rotation into a slightly taller one so there is more contact between the internal and the outer gear for better torque delivery. 

I am on schedule, and next week will be dedicated to full system testing and taking part in demo days. I will also try to reassemble the parts before the testing to make the design look neat. We will keep the masking tape outside instead of just gluing them so that we can easily take them apart in case something happens. Also, I believe it will look nicer to just use tape instead.

Posted on

Team Status Report for 4/20/2024

In terms of hardware risks, the stepper motor seems to heat up quite a bit when we hold the motor instead of releasing it after each rotation. However, since we are gaining a significant amount of accuracy, I believe we should keep it for now. Also, previously we had an automatic correction movement on the dispenser when a card was not dispensed. However, the forward-to-backward transition motion might be pulling too much current that it’s disconnecting the Arduino from the Pi. We will try to put capacitors in parallel to load so that we can smooth out the sudden current draw, but for now, we decided to manually fix it, which is fine since the accuracy of the dispenser is still pretty high. 

We also made some changes to the software design. We moved over to an asynchronous io and execution model to allow for updates to happen between various components at any time. We also decided to use websockets on the website as it makes it easier for us to send updates from the server to all of the clients. The monetary cost of both of these changes is zero. For the websockets, that does increase the computational intensity of the web server but we are moving that off of the raspberry pi to be hosted on a laptop. Thus, the load on the raspberry pi has actually gone down.

Here’s a photo of the first draft of the website. There are no changes to the schedule.

Posted on

Jason’s Status Report for 4/20/2024

Over these past two weeks, David and I spent a significant amount of time converting our blocking control flow into a completely different asynchronous model. This model change has allowed us to implement calling “UNO!”/ calling out other players for not saying “UNO!”, async state correction, and more. This change took tens of hours and touched almost every part of the code base. On top of switching to an asynchronous model, we set up a WebsiteDisplayer which handles sending the state to a server to update clients in real time. This allows us to externally host the website and save some power on the Pi.

I am on schedule. We will spend the rest of this week fixing bugs and further refining the website. This next week, I will improve the website and give a better interface for state correction on the website.

Additional Prompt:
Before this project, I had never fine-tuned a model on my own, unique dataset. On top of that, I had never gone through the process of collecting and formatting data. I learned a lot about picking good models and creating scripts to artificially diversify your dataset. I also went through some of the pitfalls of over fitting to data and discovered techniques to help the model generalize better. For this, online ML tutorials proved to be quite useful, as well as a lot of trial and error.

Besides machine learning, I also learned a lot about asynchronous coding in Python. For this async model, I learned how to use Python’s thread-safe queues for message passing. I learned and took inspiration from some designs I made for Distributed Systems.

Finally, I learned a lot about web interfaces and real-time updates to websites. Honestly, Stack Overflow and ChatGPT were very helpful for showing small examples to apply to our bigger task.

Posted on

Thomas’s Status Report 4/20/2024

For the last couple of weeks, I have focused on getting new prototypes for the dispenser and getting the whole subsystem satisfactory. I did a lot of testing on different prototypes, and we settled on one that worked decently within our requirements. With the software infrastructure already set up, I was able to test out the rotation of the chassis too. By not releasing the stepper motor in between motions, it generates quite a bit of heat but gains significant accuracy. While it was working fine, after going to a lot of rotations back and forth throughout the last couple of weeks, I have noticed that the stepper motors are giving out gradually as it has been losing steps in the reverse directions. We might have to purchase another one that we might use mostly for demo day. The same goes for the batteries. With the software portion mostly finished in terms of the website, we played a full game of 4 – people uno yesterday, without an error. 

I am on schedule, and next week after the presentation will be dedicated to finalizing the hardware, further testing with the software, and overall getting ready for the demo. Also, I do need to add an LED that lights up when an illegal move is played. 

Additional Prompt:

Everything I have done for this project is something I have never done before. I had to learn how to use CAD software for modeling, the laser cutter in Techspark, and 3d printing gears. I watched a lot of videos on YouTube to learn Onshape, which is the CAD software I have decided to use. My friend also initially taught me some tricks to make work easier. In terms of the laser cutter, Professor Nace and the staff at TechSpark were kind enough to walk through all the steps. For gears, I tried to make the dimensions of the machinery easy to create and replicate similar gears which also learned how to make on Youtube. 

When I was learning all the new things on YouTube, I tried only learn couple of things that were directly related to my project, and I spent most of my time just trying them out. I printed a lot of boxes in Techspark using scrap, and I was able to get used to it pretty quickly. The same goes with the CAD where I tried to make many different iterations of the chassis before finalizing it. I believe trying these things out myself instead of watching more videos saved me time or tutorials since I got better at them a lot quicker. 

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

Jason’s Status Report for 4/6/2024

This week, I spent a lot of time on the design and implementation of the async version of the game. The current problem is that the current control flow of the system blocks too much on user input. This makes it basically impossible to do anything asynchronous in the state, such as reset the game or correct a card. So, the change to an asynchronous model is necessary but adds other challenges. The new model consists of the same 4 nodes (UNO, Controller, Displayer, & Manager), except now the manager is at the top level, and it facilitates the asynchronous communication between the other three nodes using thread-safe queues in Python. The code looks very similar to what I have written in Golang for Distributed Systems.

 

Because of this refactor, I am slightly behind schedule. I will work diligently on finalizing the new control flow for the first part of this week. Then, I will switch to helping David with the website portion. I hope, in collaboration with David’s work, to have a fully tested new control flow and a basic working website. Then I can transition into making the website functionality more complex.

 

There are two main areas in which I have done verification and validation: card classification, and control flow.

  • Card classification: I have spent a lot of time validating the model in different conditions. In fact, this validation is exactly how I landed on a specific model + hyperparameters combo. Offline, I have seen 100% accuracy on the validation and test datasets. When actually using the device, we have seen very few mistakes. We have played at least 20 games of UNO and only witnessed 1 error in the color classification. This was a color classification from the bottom camera, and it thought a blue card was green. This mistake was more likely a lighting problem, however.
  • As for control flow, we have tested all scenarios that can appear in the game, except calling UNO and calling an UNO failure. We must wait for the new async model to test this. Since I implemented logging inside of the game manager, we are able to confirm the game’s state after each scenario. Some examples of tested scenarios are: playing +4, calling bluff, failed bluff call, playing +2, playing skip, playing reverse, drawing a card, playing a wildcard, and more.

 

Once the new asynchronous model is implemented, I will do similar testing on each of the scenarios outlined above. Also, once the website is up and running, we will use more logging to verify its robustness.

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.