Category: Team Status Report

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.

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.

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.

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.

On the software side, the ML model is still the biggest risk. We have collected a lot of data from both the top and the bottom. So far, we have gotten 99.9% training accuracy for top images, but have not run it for the bottom images yet. We will try to generate more bottom data and see what happens next. 

On the hardware side, we have found the reason why the card dispenser has been pretty inconsistent, and we are pretty close to getting the claimed 95% success rate. We will keep prototyping and testing for the next couple of weeks. We did notice that the motors have to run a little longer than our 1 second latency requirement for the cards to get extruded enough and consistently, which isn’t the most significant downgrade to our project. 

There were no significant design changes or schedule changes made in the last week in both software and hardware. We are all on schedule, and a good amount of integration has been happening already. 

The risk of being able to move the chassis as well as dispensing one card consistently has become less of a concern. We haven’t yet given the full weight on top of the rotation platform, as well as we still have the jamming issue on the dispenser that happens here and there, but with the amount of time we have, we will be able to figure a solution out. For the dispenser at least, it seems to work well when we apply some amount of pressure on the cards, which will be replaced by some type of weight on top of the cards later down the road. 

We are still unsure about the classification latency/accuracy which we will start testing next week. One of the potential risks is lighting inside the chassis, but we have purchased some diffused LEDs we could use to brighten the inside or make a mesh-like cutout on the chassis so there’s enough lighting coming into the chassis for better visibility. 

No changes to the system and schedule have been made. We do aim to focus on getting the design report done next week though. 

Here are some videos of getting the chassis and dispenser working:

https://drive.google.com/file/d/1KGgJ0_tdnAvi6B1oQFJU8SHMi2bihiQO/view?usp=sharing

https://drive.google.com/file/d/1dAv9jNmSohXnl55oyNhz-Z-KTMuDrxDC/view?usp=sharing

https://drive.google.com/file/d/1LHxRdXYtc_W_PJOMiwY9bpuBw-nyfv2b/view?usp=sharing

https://drive.google.com/file/d/1nWOSIvm0QjXJGd85pnTdlnt-_bM_Pzob/view?usp=sharing

We have noticed that it will be very difficult to make the card dispenser dispense one card at a time, both due to inaccuracies of the 3D printer and having to calibrate the rollers and the pressure on the cards very accurately. We will try to identify issues of each trial and make improvements to each prototype to carefully calibrate for the next couple weeks. We are not pressed for time on this at the moment as the software needed for the dispenser’s full functionality is still being implemented. 

Furthermore, similar to last week, since we just got our relevant parts so we weren’t able to fully test rotating the platform. These are scheduled to be handled next week, and we plan to make changes to the motors and the motor shield if needed as soon as possible.

There were no significant changes in the system design. We had some schedule changes that occurred due to delay in getting the parts, but it’s mostly changing the orders of 2 tasks, so everyone is on schedule.

Part A written by Jason Stentz, Part B written by Thomas Kang, Part C written by David Peng.

Part A: Although our project is not directly geared towards drastically improving public health, safety, and welfare, there are a few key benefits. Since we are removing the burden of managing game flow, players will be more social during the game instead of worrying about managing the game. Of course, increased social interaction is almost always a  health benefit. Also, UNO is a cognitively stimulating game. It may not seem like it on the surface, but there is actually quite a bit of strategy involved in picking when to play, draw, or call a bluff. Creating an automated UNO device will attract others to the game, promoting a healthy game to stimulate the mind. Lastly, an automatic UNO device will lower the barrier to entry for new players, since the rules will be enforced for them! This will mean they will have less anxiety when playing for the first time. Overall, an automatic UNO controller will allow for more social interaction during the game, reduce anxiety for new players, and help spread a cognitively stimulating game.

Part B: While UNO is one of the most popular card games around the world, there are a good amount of people who are not as familiar with it, especially in Asian countries. Also, even among people who know how to play the game, depending on where and who they played the game with, they can have their own sets of rules. This potentially leads to people getting into arguments or getting too focused on the game itself all the time that they miss out on the opportunity of using UNO as an opportunity to bond with other people and socialize. Our machine will be able to not only educate and assist people who have never played the game, but also eliminate arguments over rules as well as facilitate people’s social interaction by automating the flow of the game. This way, regardless of people’s background in the game, everyone will be able to enjoy the game to the fullest.

Part C: With UNO being one of the most played card games in the world, there is a large group of people, both casual, and competitive, who can benefit from this product. For example, in the UNO world championships, the need for dealers would be reduced as our product can manage the games being played with high accuracy and efficiency. It can also allow for other tournaments with lower budgets to use this machine to control the games instead of having to hire a large number of dealers. The automatic scoring will also augment the home experience and introduce more people to the game and make it more engaging. 

In the mechanical realm, we have to make sure the stepper/DC/Servo motors don’t draw too much current through the Arduino Motor shield, so we made sure to choose options with the least amount of current draw. We could also swap out the motors with something else down the road if we find it necessary. Also, we do have a concern of RPI 5 not being able to run on full throttle due to requiring 5V 5A, but even on the low power peripheral mode, we expect the 2 cameras and the serial interface to stay within the max current output. Finally, the stepper motor options we could use were heavily restricted by the 1.2A current draw, making us choose a relatively weaker one. It is possible that it will struggle to move the entire chassis, but we do plan to use possibly lighter material for the casing, make the batteries smaller in case we need to reduce weight, and change the gearing design to require less torque on the motor. 

In terms of software, the biggest risk is a failed classification model. In our proposal, we promised at least a 95% accuracy in card classification, but we want to achieve something higher than this. Initially, we will be attempting a standard CNN architecture without much preprocessing. If this does not achieve a high enough accuracy, we will preprocess the image (extracting the symbol) to classify the symbol and color separately. This will decrease the dimensionality of both the input and the output, hopefully simplifying the problem for the model. If all of this fails, our backup solution is to tag the cards (say with a QR code) to reliably identify them.

On a systems level, nothing changed. We are calibrating sizing of the case and gear ratios, and minor physical features, but our overarching design is still the same.

We chose a smaller battery pack for the motors as we realized that we could save power by cutting power to the motors when not in use. This allows us to save weight and space in the enclosure. This also saves us money.

We might have to swap what we are doing next week based on the parts delivery. If we do not get the parts, we will just start developing the card dispenser CAD model and 3d print as well as begin work on the classification model itself.