As avid poker players, we all agreed that designing a dealer would be an enjoyable undertaking for the class. There are very few automatic card dealers

out there; none of which provided the attributes that we would want in a
product. These included full automation that would deal cards for the correct phase of the game and to the right places, card recognition for onlookers
to follow along with, and an online interface that could eventually be developed to track betting, statistics, and other aspects of the game. It’s safe to
say that we had high hopes for our design that, as we would soon learn, was
more complicated than expected. Overall, we wanted to design our dealer to
be accessible to newer players and a convenience to regulars. 

Our team’s original outcome objectives at the start of the quarter were as
follows:
• Our device would be able to successfully deal out individual cards (face
down), rotating with appropriately spaced intervals, for a manually entered number of players on the website.
• Our device would correctly identify the cards’ values as they are dealt
to each player. Our website would include a live display of each player’s
hands.
• Our device would successfully deal three cards for the flop, and flip
them face-up after being prompted by the players (using a button). The
website would update the display accordingly. Then it would repeat .

We knew that this product was ambitious due to the significant mechanical components. Throughout the term, we faced many difficulties realizing
the product we had envisioned at the beginning. Our ending product was
simplified in several ways to allow us to meet our goals.
• We were unable to integrate the automated rotating base. We installed
the servo, and also 3D-printed the rotating base, but did not have
enough time to reach our Milestone 5 goals and include the code we
had written to rotate the base in between cards being dispensed.
• Also, instead of automating the cards being dispensed, our final prototype relies on a physical button push to trigger the card being dispensed, the image being taken, and the card recognition to work.

• We do not have any code that keeps track of the previous cards, it just
recognizes the card that was just dealt.
• Our server web page does not update with the card dispensed, and
instead that information is displayed on the python terminal that the
server is hosted on. As multiple cards are dealt, the terminal displays
a list of the cards and continues to fill it out. 

The performance of Mrs. Deal, was not as perfect as our team had envisioned
from the beginning of the project. Upon a button press, it is able to rotate
the dc motors to stick a card out, take an image with the ESP-32 CAM, and
send that image to the server for card recognition to take place. We faced
a very difficult time throughout this term with the mechanical issues behind
dispensing a single card without moving the rest of the stack and also behind
stopping the card mid-way through being dispensed. We tried switching a 

couple different types of motors, and also printed several different wheels
with varying surface patterns. Also, we switched from having a single motor
dispensing cards to having a secondary motor that engages with the rest of
the stack to pull it back into place. In spite of all of these efforts, the card
dispensing was quite unreliable. Often, multiple cards would slide out of the
holder, or the card would be dispensed not enough or too far out of the field
of view of the camera. One thing that did work extremely well was the timing
between the card movement, our LED’s illuminating the card from below,
and the camera taking an image to send to the server. The difficult part was
having the card be in the correct position when the image was taken.
The performance of the card recognition was actually surprisingly good
considering the limited resolution offered by the ESP 32 camera. It was
accomplished by iterating through a list of template images (which we had
previously captured) and lowering...