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.

BusPlan

Aashish Kapur, Connor Lake, Scott Liu

BusPlan

Featured Project

# People

Scott Liu - sliu125

Connor Lake - crlake2

Aashish Kapur - askapur2

# Problem

Buses are scheduled inefficiently. Traditionally buses are scheduled in 10-30 minute intervals with no regard the the actual load of people at any given stop at a given time. This results in some buses being packed, and others empty.

# Solution Overview

Introducing the _BusPlan_: A network of smart detectors that actively survey the amount of people waiting at a bus stop to determine the ideal amount of buses at any given time and location.

To technically achieve this, the device will use a wifi chip to listen for probe requests from nearby wifi-devices (we assume to be closely correlated with the number of people). It will use a radio chip to mesh network with other nearby devices at other bus stops. For power the device will use a solar cell and Li-Ion battery.

With the existing mesh network, we also are considering hosting wifi at each deployed location. This might include media, advertisements, localized wifi (restricted to bus stops), weather forecasts, and much more.

# Solution Components

## Wifi Chip

- esp8266 to wake periodically and listen for wifi probe requests.

## Radio chip

- NRF24L01 chip to connect to nearby devices and send/receive data.

## Microcontroller

- Microcontroller (Atmel atmega328) to control the RF chip and the wifi chip. It also manages the caching and sending of data. After further research we may not need this microcontroller. We will attempt to use just the ens86606 chip and if we cannot successfully use the SPI interface, we will use the atmega as a middleman.

## Power Subsystem

- Solar panel that will convert solar power to electrical power

- Power regulator chip in charge of taking the power from the solar panel and charging a small battery with it

- Small Li-Ion battery to act as a buffer for shady moments and rainy days

## Software and Server

- Backend api to receive and store data in mongodb or mysql database

- Data visualization frontend

- Machine learning predictions (using LSTM model)

# Criteria for Success

- Successfully collect an accurate measurement of number of people at bus stops

- Use data to determine optimized bus deployment schedules.

- Use data to provide useful visualizations.

# Ethics and Safety

It is important to take into consideration the privacy aspect of users when collecting unique device tokens. We will make sure to follow the existing ethics guidelines established by IEEE and ACM.

There are several potential issues that might arise under very specific conditions: High temperature and harsh environment factors may make the Li-Ion batteries explode. Rainy or moist environments may lead to short-circuiting of the device.

We plan to address all these issues upon our project proposal.

# Competitors

https://www.accuware.com/products/locate-wifi-devices/

Accuware currently has a device that helps locate wifi devices. However our devices will be tailored for bus stops and the data will be formatted in a the most productive ways from the perspective of bus companies.