Month: March 2025

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.

Now, we have a complete picture of how the machine will look like. We closely examined the required parts and their specifications more closely to make sure they all meet the design requirements we have set for this project. Admittedly, we did run into some problems due to parts we have bought/borrowed that actually did not entirely meet our requirement. However, we have accommodated those and are ready to build the machine starting this week. That is, unless the extra parts we bought arrive late. However, since there was one week gap for the parts to arrive, it would be unlikely.

As specified in the design report, the final size of the machine body will be a 20 x 20 x 6 cm  wooden box, made by combining mdf plates. The size was chosen after creating virtual images of the assembly as shown above, getting a general sense of the amount of space that would be required for all the parts to fit inside. Although we do not have the dxf file for the wooden plates yet, I am planning on quickly creating those this Monday and hopefully cut them by Tuesday.

Then I will assemble those in to a box and add the caster wheels so that I can adjust the placement of the servo for central rotation. Then, I will add weight in side the box to simulate other parts other than the uno to see if we need to buy a different motor shield to support external power supply or the servo. The one we have currently does not, so it will be drawing power from the Arduino, which is generally not a good idea. However, considering that the load is not too heavy, we thought that the servo may end up not drawing too much current.

In short, it was mostly final polishing of the design plan before moving onto the actual assembly.

We are on track in terms of schedule, and if the servo and the 3D printed dispenser case does not cause any trouble, we will very ahead of schedule by the end of this week (though that would be highly unlikely).