Posted on

Team’s Status Report for 15th February 2025

As a team, we made final decisions for the camera and Jetson products, then placed orders for them. We are ready to start creating a program for card detection, as well as working on the math required for card counting. We are trying to find an easy way to develop without moving the hardware around too much. For example, it would be nice if we could develop significant parts of a computer vision program without needing to actually connect the camera. We’ll work on how to make this process easy. We do not have any significant schedule changes or block diagram changes. The most significant risks would be a hardware device breaking, which could delay progress as we may need to order a replacement. We still have a contingency plan to develop a CUDA kernel for additional performance if accuracy and performance suffer with computer vision or a python ML model.

 

Nicholas wrote part A, Lohith wrote part B, and Joe wrote part C.

(A) The product does not strictly meet a specified need to public health, safety, or welfare, but rather is designed to ensure these factors are not infringed upon. This product is meant to teach people how to count cards when playing Blackjack at a Casino, as well as providing a fun user experience with friends to all learn as a group. However, we could see that if a product like this gained wide spread adoption, without proper boundaries, arguably public welfare and health might decline. We note that gambling addictions are real problems that need to be properly addressed and mitigated when making a product such as our own, so we have designed it to have constant reminders of safety and proper risk management when playing Blackjack. Luckily, since we are teaching players how to optimally play Blackjack, we are giving them a lower chance of losing money and causing themselves financial harm, but we still need to be aware of the real risk and issues associated with a gambling addiction. Through occasional warnings during gameplay and a warning when starting the system, we hope to mitigate possible issues related to public health, safety and welfare.

(B) This product meets needs with consideration to social factors. Blackjack can be and is often a social activity. Many people going to the casino will go with friends or family, and playing blackjack is often a bonding experience, since a game involving both luck and skill will usually prompt discussion between members of the table, with feelings of jubilation (winning a hand), disappointment (a correct play leading to a loss), or surprise (a misplay or a lucky card). Our product, which aims to help a beginner player make the right decisions when playing, will also help the player take part in these discussions and therefore increase their social interaction with friends and family. Even a person who goes alone can start interacting with other players (including the dealer as is often the case), and maybe make some friends along the way. 

People also play blackjack with their friends at home, and it is possible that a beginner who isn’t confident enough in their skills to bet money will feel alienated. This product can help the beginner start making the right moves in blackjack and increase their confidence, enabling them to start betting and also having fun with their friends.

(C) This product does not really have that many economic considerations since it is an educational application that helps with making accurate probabilistic decisions. From an indirect perspective, the application does also help teach individuals how to manage their finances and make prudent financial decisions. However, from a strictly macro-economic perspective there are not that many relevant considerations for this application and thus the design of the product can more or less ignore this area.

Posted on

Team’s Status Report for 8th February 2025

It is possible that with the base Jetson Nano setup, we may not be able to meet the latency requirements. For this, our contingency plan is to use the CUDA kernels given to us and write optimized code to meet requirements. Also, we plan to use an FPGA to accelerate some of the ML operations in the Jetson, but if the I/O speeds prove to be too slow, and we meet specs without the FPGA, then we will simply not use it. We did not make any major modifications to our initial ideas this week; however we did brainstorm for additional functionalities that we might want to add if time and resources permit. The schedule has not been updated.

Posted on

Lohith’s Status Report for February 8, 2025

Over the past week, I have been exploring options for camera models. The camera is an integral piece to our project, and since we have a goal of 90% accuracy for card identification, the choice of camera is very important. Out of the many options, one option I found was the Intel RealSense camera series. These cameras have sub-millimeter accuracy, which is sufficient for us, since this camera will be on a short tripod close to the hands of cards. Out of the many options, I settled upon the D435 model, a camera that records at 90 frames per second, with RGB capabilities, and a USB-C connector. Also, I have been researching videos on how to interface the Jetson Nano with the camera. This is a common practice that people do, so there is support for if we run into issues. I am currently on schedule. Early next week, we will place the order for the camera (unless the ECE department has one, in which case we will borrow one), and then we can start testing data transfer with the Jetson Nano with a small sample program. Then, we can start developing the ML model for identifying cards.

Posted on

Nicholas’ Status Report for 8th February 2025

I have been researching which ML Model we should use for our project, as well as confirming my belief that there are no alternate Computer Vision techniques we can use. In my research, I reviewed edge detection techniques and color analysis systems for detecting cards. However, as I initially believed, these systems are not robust to different conditions, which is a user requirement for us. Furthermore, these systems do not do further feature processing and refinement like the ML Model’s we will be using can do. This lack of further processing means that a pure Computer Vision approach would not meet the user requirements. Once I had fully confirmed my suspicions, I began to further research Resnet-50 and the YOLO family of models. We have currently decided to use a YOLO model, since after further research, we realized Resnet is a common backbone for most object detection pipelines, but would require further scaffolding on our part. YOLO would streamline this process, so for next week, we are deciding which YOLO model to use, and we will begin preparing the model and dataset for training.

Posted on

Joe’s Status Report for 8th February 2025

This week, I have been primarily working on developing the processing algorithm. Mainly, I have been reading literature on how cards are used to update the count, existing mathematical models on Blackjack so that I can decide how to provide suggestions for users to play. Additionally, I’ve spent some time setting up the scaffolding for the web application, outlining what are the functionalities that the web application should provide. As of now, some of these functionalities include: ability to toggle suggestions on and off, interface to start and set the game and players. Progress is going smoothly and according to plan. I intend to set up a basic version of the web application by next week, figure out whether the functionalities are sufficient, and spend the next few weeks improving the UI design and integrating it with the processing algorithm.