Project

# Title Team Members TA Documents Sponsor
24 ECE 445 SP23 RFA: AUTONOMOUS CARD DEALER
Adam Naboulsi
Ralph Balita
Rohit Chalamala
Nikhil Arora design_document2.pdf
final_paper1.pdf
photo1.png
photo2.png
photo3.png
photo4.png
photo5.png
presentation1.pdf
proposal2.pdf
video
## **ECE 445 SP23 RFA: Autonomous Card Dealer**
Early Request for Approval
Jan 25, 2023

**_Team Members:_**
- Adam Naboulsi (adamjn2)
- Ralph Balita (rbalita2)
- Rohit Chalamala (rohitc2)

**#_Problem_**

Describe the problem you want to solve and motivate the need.

We all love card games, whether we are just playing casually with our friends or going to the casino.
To name a few: Poker, Literature, Blackjack, Kings Corner, etc. We all want a fair card distribution
system in which the gameplay is smooth/effortless and where the dealer is not cheating.

**#_Solution_**

Describe your design at a high-level, how it solves the problem, and introduce the subsystems of your project.

At a high level, we want to make the card game playing process more effortless and fair by replacing the dealer with a device. There are a few different subsystems of this project including the card shuffler, card dealer/distributor, and the user interface. The card shuffler allows the games to be more fair because it gets rid of human error that is often present with shuffling. We could make it even more fair by making a truly random shuffle by riffle shuffling the deck 5 or more times. The card distributor would basically replace the dealer by being able to rotate and shoot out cards to certain locations on the board. The user interface for this would be some kind of buttons that allows the user to control turning the device on and off, the number of players, the game mode, and starting/pausing the game, etc. This will solve the problems of current human dealers by making the whole process a lot more fair.

#**_Solution Components_**

Explain what the subsystem does. Explicitly list what sensors/components you will use in this subsystem. Include part numbers.

Below are a set of subsystems required to complete the project

**Shuffler**

_Purpose / Usage_

The purpose of this subsystem is to mechanically mimic the act of shuffling cards. Ideally, a card shuffler should have the ability to shuffle a deck multiple times. The mechanism our group has developed has the capability to shuffle a deck only once. More on design will be discussed in the future.

An automatic card shuffler shall shuffle a cut deck of cards, two sub-decks. The card shuffler shall stop shuffling cards once both sub-decks are depleted. The card shuffler shall use a contact sensor to indicate whether the sub-decks are depleted

Components

Here is a list of possible components that are necessary for this subsystem.

- 2x servo motors - responsible for

- 2x contact sensors

- card holder

- microcontroller

**Dealer / Distributor**

_Purpose / Usage_

The purpose of this subsystem is to mechanically mimic the act of distributing cards based on the game that is being played. More on ‘game-choice’ is described in the User Interface section.

An automatic card dealer shall deal a deck of 52 cards evenly amongst 2 and 4 players. The card dealer shall rotate in a counter clockwise fashion. The card dealer shall have pre-defined trajectories based on the total number of players and the game being played. The card dealer shall distribute the first card to the left of the dealer. The card dealer shall distribute the last card to the ‘dealer’ The card dealer shall stop dealing the cards once all cards are depleted. The card dealer shall use a contact sensor to indicate whether the deck is depleted, which can be used to verify that the correct number of cards were dealt

For a card game that requires 2 players, the servo motor shall have preset trajectories at 0 and 180 degrees. The same applies for 4 players, but instead, at 0, 90, 180, 270 degrees. As the deck gets rotated to each of the angular positions, the card dealer shall stop and deal a card. For bonus points, our group plans on having a card counting system to verify that the number of cards being dealt is correct.


_Components_

Here is a list of possible components that are necessary for this subsystem

- 1x stepper motor - rotate the deck and stop at preset angular positions

- 1x servo motor - ‘throw’ a single card towards a player

- 2x contact sensors

- card holder

- microcontroller

**User Interface**

Purpose / Usage

The purpose of this subsystem is to allow the players to select what game to play and control when to shuffle and when to deal the cards for the given game.

We can limit the number of players based on the game mode. If the user would like a game mode that has cards distributed evenly, then the User interface shall limit the number of players to 2 and 4 (for a 52 card deck) and 6 (for a 54 card deck). If the game mode is poker, then the UI shall limit the number of players to 2,3,4,5,6,7,8.

The user interface shall have 4 buttons:

- On/Off

- Game Mode - user chooses “even distribution”, “poker”, etc

- Number of Players - the user shall have the capability to toggle the number of players based on the chosen game mode

- Start / Pause

Default settings: num_players = 2 game_mode = even distribution

The base model shall work well enough to run an even distribution for 2 and 4 player games. Some card games that will work for this include BullS**t and Literature. We plan on adding complexity by including the game modes: poker and UNO. These games require dealing an X amount of cards to a Y amount of players, so the contact sensors are unnecessary.

The beauty of the project is that users can download and add game modes with preset settings: the number of players, number of cards distributed to each player, and any final cards dealt (ie. poker’s flop, turn, river), and their distinct trajectories

_Components_

Here is a list of possible components that are necessary for this subsystem

- 4 buttons

- Debouncer


#**Criterion For Success**
Describe high-level goals that your project needs to achieve to be effective. These goals need to be clearly testable and not subjective

**Shuffle a set of cards evenly**
This can be tested by looking at the cards before and after the card shuffler is done in order to determine the effectiveness of the shuffle.

**Distribute the cards to the players**
This can be tested visually by checking that the cards that are on the board have been distributed correctly and in the right order.

**Buttons for user interface**
Test each of the buttons to make sure they are performing as expected.

Master Bus Processor

Clay Kaiser, Philip Macias, Richard Mannion

Master Bus Processor

Featured Project

General Description

We will design a Master Bus Processor (MBP) for music production in home studios. The MBP will use a hybrid analog/digital approach to provide both the desirable non-linearities of analog processing and the flexibility of digital control. Our design will be less costly than other audio bus processors so that it is more accessible to our target market of home studio owners. The MBP will be unique in its low cost as well as in its incorporation of a digital hardware control system. This allows for more flexibility and more intuitive controls when compared to other products on the market.

Design Proposal

Our design would contain a core functionality with scalability in added functionality. It would be designed to fit in a 2U rack mount enclosure with distinct boards for digital and analog circuits to allow for easier unit testings and account for digital/analog interference.

The audio processing signal chain would be composed of analog processing 'blocks’--like steps in the signal chain.

The basic analog blocks we would integrate are:

Compressor/limiter modes

EQ with shelf/bell modes

Saturation with symmetrical/asymmetrical modes

Each block’s multiple modes would be controlled by a digital circuit to allow for intuitive mode selection.

The digital circuit will be responsible for:

Mode selection

Analog block sequence

DSP feedback and monitoring of each analog block (REACH GOAL)

The digital circuit will entail a series of buttons to allow the user to easily select which analog block to control and another button to allow the user to scroll between different modes and presets. Another button will allow the user to control sequence of the analog blocks. An LCD display will be used to give the user feedback of the current state of the system when scrolling and selecting particular modes.

Reach Goals

added DSP functionality such as monitoring of the analog functions

Replace Arduino boards for DSP with custom digital control boards using ATmega328 microcontrollers (same as arduino board)

Rack mounted enclosure/marketable design

System Verification

We will qualify the success of the project by how closely its processing performance matches the design intent. Since audio 'quality’ can be highly subjective, we will rely on objective metrics such as Gain Reduction (GR [dB]), Total Harmonic Distortion (THD [%]), and Noise [V] to qualify the analog processing blocks. The digital controls will be qualified by their ability to actuate the correct analog blocks consistently without causing disruptions to the signal chain or interference. Additionally, the hardware user interface will be qualified by ease of use and intuitiveness.

Project Videos