Weekly Status Reports

This week, I had to make a major revision on my codebase, since in the previous implementation, I completely forgot that we had to deploy the model to read in data in real-time and rather had the model read in images for data. This meant that I had to change the model to extract features and read data in real-time video processing instead of on static image data.

I’m a week behind in terms of what I had to achieve– I had to deploy the model on raspberry pi. However, the issue stems from delivery issues, so this was quite inevitable. As such, to mitigate this, I will have to devote some good amount of time once we get the SD card and make 2 weeks amount of effort.

Now, the model is designed to work on real-time streamed video. However, since we haven’t been able to gather training data for the cards, I was not able to test the model. The next step I’m thinking is maybe I could train and evaluate the model on dummy data so that we can see if the basic object detection is working. Subsequently, once I’m able to gather the training data, my plan is to train and evaluate the model to detect and classify the cards that can be deployed in the dealer system.

 

During this week, I focused on three main areas: User Interface and Game State Manager. My time allocation demonstrates a substantial commitment to the project, meeting the expected minimum of 12 hours:

• 4 hours of in-class team collaboration
• 1 hour participating in 3D Printing Dispenser Body
• 7+ hours of game state management
• 1+ hours on starting on user interface

Key Accomplishments

1. Completed 3D-print request to CMU techspark. The dispenser body is taking a little longer than expected to get printed. Relatively small pieces like cylinders and gears are printed.
2.  Completed structuring the Poker game management. Haven’t made much progress with  user interface.

The project is getting a little behind of the original plan: 3D printing is taking more time than expected, and Implementing the game state management and user interface is also taking more time, but it is not a huge concern, given that our original schedule had a massive slack time. In addition, I can put more time next week to finish everything before the presentation week.

Next Week’s Deliverables

1. Finishing implementing I/O inputs and game state management.
2. Start testing on dispenser body.

This week, I cut out the main machine body of ACE, made of mdf. After consulting with a person working in Techspark, I realized that the thickness of does not need to be overly thick. So, I decided to use a 3mm mdf, which significantly reduced the overall weight of the machine. So, I think we can continue using the motor shield we have for now.

I have confirmed that the machine does spin properly, within the latency bound we have set as the design requirement. Right now, I have temporarily put the pieces together in tape, but they will soon be glued together. Once the dispenser gets printed, we can try placing it on the designated space and see if everything works out.

 

Roughly on schedule, with some parts ahead and some parts behind. It was unexpected that our order for the SD card got canceled.

 

• What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

No special risk at this moment. However, since our project requires a combination of many components. All parts must be prepared on time to have enough slack time. 

• Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

None

• Provide an updated schedule if changes have occurred.
  

Slightly behind in combining parts to the machine body. It must be done by next week.

• This is also the place to put some photos of your progress or to brag about a component you got working.

DXF file ready to be cut in techspark fablab.

This week, I worked on learning how to make dxf files for laser cutter and making it. It honestly took me a lot longer time to do this, as I had to get the dimensions right.

It also took some time because I wanted to make it in a way that lets me change the hinge size according to the thickness of the mdf I am going to use. This was to add flexibility in our machine body’s design in case we need the material to be less thick to reduce weight or thicker to made it stronger.

Although I did very selectively place the holes considering the size of inner components and their placement, how it actually looks when assembled in real life may be different. So the top part may need to change slightly, but the rest should be fine with what we have right now.

I am behind schedule right now, as I should have already cut this board out this week. So, I will need to do that right away on Monday and assemble them. Good news is that all parts (except for RPI sd card) has arrived, which means I should be able to construct the full machine body now.

I do see it taking some trials and errors, but I hope it won’t take too long. That is why we took some time to plan ahead after all: to reduce number of trial and error.

This week, I mostly focused on setting up the codebase for our card detection model. I started writing some of the key functions we’ll need and did some research into good backbone models—I’m leaning towards ResNet because it seems reliable and effective. Progress was a bit slow due to the ongoing hardware issues, but at least we’ve got a solid foundation now, so we’ll be able to move quickly once we get the Raspberry Pi 5. I’ll share the code once it reaches a more usable stage.

Next week, I plan to finish up the model and run some early tests to make sure everything is working well with our dataset. That way, as soon as the Raspberry Pi 5 is here, we can dive right into training and deployment.

During this week, I focused on three main areas: Dispenser 3-D Printing, Ethics Assignment, and User Interface. My time allocation demonstrates a substantial commitment to the project, meeting the expected minimum of 12 hours:

• 4 hours of in-class team collaboration
• 1 hour participating in 3D Printing Dispenser Body
• 5+ hours of completing Ethics Assignment
• 3+ hours on starting on user interface

Key Accomplishments

1. Completed 3D-print request to CMU techspark. The product expected to be completely printed by next Tuesday
2. Completed Ethics Assignment.
3. Started working on user interface: weight sensor and game state management. Currently working on structuring the Poker game and writing it as a working code.

Schedule Status The project is progressing according to schedule, with all planned deliverables for this week completed on time.

Next Week’s Deliverables

1. Continue implementing I/O inputs and game state management.
2. Start testing on dispenser body.

During this week, I focused on two main areas: Dispenser design CAD and Design Report. My time allocation demonstrates a substantial commitment to the project, meeting the expected minimum of 12 hours:

• 4 hours of in-class team collaboration
• 8 hours participating in Dispenser design & Machine Body design CAD
• 6+ hours of writing the design report

Key Accomplishments

1. Completed SolidWorks models for the dispenser design and finished first draft of machine body design
2. Completed writing the design proposal.

Schedule Status The project is progressing according to schedule, with all planned deliverables for this week completed on time.

Next Week’s Deliverables

1. Start 3D Printing Solidworks dispenser design.
2. Start implementing I/O inputs.

 

A was written by Martin Lee, B was written by Andrew Kim and C was written by Justin Kim.

Part A: … with consideration of global factors. Global factors are world-wide contexts and factors, rather than only local ones. They do not necessarily represent geographic concerns. Global factors do not need to concern every single person in the entire world. Rather, these factors affect people outside of Pittsburgh, or those who are not in an academic environment, or those who are not technologically savvy, etc.

The Automated CardEaler (ACE) is designed with global considerations to meet the diverse needs of casual poker players around the world. By automating the dealer functionality, ACE addresses the common inconvenience faced by casual card game players worldwide– namely, the social exclusion of the person acting as the dealer. 

To ensure ACE effectively serves global Texas Hold’em players, the design enforces to follow the typical Texas Hold’em rule. Furthermore, in the future, we’re intending to incorporate flexible and adaptable elements like multilingual audio output and customizable game rules. Supporting multiple languages in ACE ensures accessibility across various linguistic contexts, directly acknowledging global diversity. In total, our product solution not only meets the specific need for unbiased, automated dealing but also reinforces global inclusivity and broadens the product’s appeal in a diverse, interconnected world.

Part B: … with consideration of cultural factors. Cultural factors are encompass the set of beliefs, moral values, traditions, language, and laws (or rules of behavior) held in common by a nation, a community, or other defined group of people.

Automated CardEaler is specifically designed to enhance the inclusivity and engagement of casual card games across diverse cultural settings. Having one player act as the dealer can exclude them from fully participating in the game, potentially conflicting with cultural values that emphasize fairness and equal participation. By automating the dealing process, this machine ensures that no player is disadvantaged by the responsibility of dealing cards, aligning with cultural norms that value equity and full involvement in communal activities. This feature not only democratizes gameplay but also respects the social dynamics of gaming traditions in various cultures, making the game more accessible and enjoyable for everyone involved.

 

We can also add modifications to the system to enhance the social and cultural aspects of gaming by accommodating diverse player needs and respecting cultural norms around gaming. For example, the system’s language settings can be customized to support multiple languages, making the game accessible to players from different linguistic backgrounds. Furthermore, the machine’s user interface and game rules can be adjusted to align with local traditions and legal standards, ensuring that it respects the cultural values and legal requirements of various regions. This flexibility not only broadens the appeal of the game but also reinforces the cultural respect and inclusivity essential in today’s globalized society.

 

Part C: … with consideration of environmental factors. Environmental factors are concerned with the environment as it relates to living organisms and natural resources.

Our project doesn’t have a direct correlation with the environmental factors since poker happens indoor and our machine doesn’t require substantial amount of energy or resources to build one. However, if we were to scale this project into actually selling our product and mass production of it might, of course, cost huge amounts of money and energy. Not to address the problem with the environmental factors, but we designed our project in a way that the machine costs as few as possible. This means, the machine is not expected to harm any living organisms or harvest natural resources to a concerning level. 

 

• What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

There are currently three possible risks in our project.

Number one: The card recognition system may not work with 100% accuracy. There isn’t much risk mitigation we can add to mitigate the effect of this, so it would be our job to polish it as much as we can.

Number two: We may need to buy another motor shield/motor driver because the current one does not support external power supply for the servos. We really want to work with the motor shield we have right now, but in the case that the central servo does not work properly with the machine body placed, we will need to buy a new one that supports external power supply for the servo. Thus, we will need to hurry building the machine body so that we can test if the servo works properly.

Number three: The 3D printed dispenser may not work properly. Thus, we cannot test at all until we print it. We put a lot of time and effort into making sure it will work in the first try, but in the case it doesn’t, we will need to hurry and make modifications.

• Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

Where we place the parts in the machine body (arduino, raspberry pi, battery, breadboard) may need to change slightly for better proximity between parts that are being connected. However, it is not very different from the 3D model we have in the design report.

Provide an updated schedule if changes have occurred.

 

This week, I faced an unforeseen hardware constraint involving the Raspberry Pi. Initially, the plan was to deploy our trained card detection model directly onto a Raspberry Pi 4. However, I discovered that the Raspberry Pi 4 does not natively support multiple camera modules. Attempting to integrate two camera modules with the Raspberry Pi 4 would require using a camera multiplexer, consuming approximately 21 GPIO pins. This presented a significant obstacle since our existing design heavily depends on these GPIO pins for other critical functions, and sacrificing them was not feasible without compromising our entire design. Consequently, we could not adhere to our original plan of deploying the card detection model onto the Raspberry Pi 4.

To resolve this issue, we decided to upgrade our hardware by purchasing a Raspberry Pi 5, which inherently supports dual-camera inputs without the need for a multiplexer, thus preserving our GPIO pins. However, this upgrade led to delays, as the model deployment activities were contingent upon using our finalized hardware setup. As a result, my focus shifted from generating deployment-ready models to preparing for rapid integration once the Raspberry Pi 5 arrives.

Meanwhile, my immediate tasks include generating a custom dataset tailored specifically to our hardware environment and training the refined model promptly. Once the Raspberry Pi 5 is available, I will deploy the model to ensure our project remains aligned with our timeline.