Group 2: Card playing robot – Sprint 2


Sprint 2: 21.08.2020 -28.09.2020

During sprint 2, when the concept was selected, we proceeded to list the system requirements for the card playing in a hierarchical priority order.

High: The requirement is absolutely critical for the system, and without it the system wouldn’t perform fully

  • The system should shuffle cards
  • The system should hand out cards to each player
  • The system should identify cards via image recognition
  • The system should make calculated decisions based on dealt cards

Medium: The quality of the application would be greatly improved by this requirement

  • The system should be controllable by the players wirelessly
  • The system should communicate and interact with the players

Low: This feature would be nice to have; it may consist of cosmetic changes, non-critical inquiries, or other

  • The system should collect cards from players autonomously
  • The system should hand out cards in front of the players
  • The system should know multiple card games
  • The system should be able to smartly bet money

Based on these requirements we found multiple different solutions that could fulfill them. We therefore created a diagram with function requirements and different concepts. Based on this diagram we could choose many different routes that ultimately result in the same product. 

This image has an empty alt attribute; its file name is ERcM_gqptAPzqDOg8JwaeuBOMZPR0zhm_i-C6TodT1VF0JFApCKdhjmv3W6V7W3IEYHSZQj6eVVfYle8XXXGAXtyGUWRK8I3dDYWjal3f9yaUM_ZiuaRM8vRwSgsd2tb0Nnjhfi4
Concept selection

We found that several of these concepts had some equipment in common no matter what solution we chose. We would always need a computing unit and a camera to identify the cards and learn how to play the game. Based on that we created this short first draft of our equipment list:

Raspberry pi: We had the opportunity to choose between Arduino 2560 and Raspberry pi 3/4, both are great tools to create a project. The Arduino can only run a program over and over again, whereas the Raspberry pi can run multiple programs at once. Raspberry Pi also has a much larger and more documented set of libraries. When it comes to image recognition we believe the arduino will not be powerful enough as the robot will need to scan at least 5 frames per second for us to be able  to identify the cards reliably. 

Raspberry pi camera module: We chose the raspberry pi camera module as it was easily obtainable, small enough to put pretty much anywhere and easy to connect to the Raspberry Pi.

Considering there are still parts of our concept that still needs to be decided, we made this overview to prioritize what each discipline must focus on during the next sprint. The plan so far is to split the system in at least two parts. One smart card shuffler, one smart card dealer and one smart robotic arm.

The smart shufflers job is to shuffle the cards, hand them out to each player and read the info of all the cards. Our solution for shuffling a card deck is quite simple. An operator has to split the deck of cards in two equal pieces. The halves are then placed individually in each part of the shuffler. By combining a set number of cards from each of the inserted decks we will end up with a partly shuffled deck at the bottom. For the deck to be properly shuffled we will probably need to insert it multiple times, and perhaps have the shuffler take a random number of cards from each side and not just one and one. Below is a rough first draft of how the shuffler will look.

The smart dealer should take a shuffled deck, give out cards to each player and identify the cards as it does so. The dealer machine will need to know the number of players and how many cards they need. This will probably be controlled by an app connected to the raspberry via bluetooth. The cards will be thrown out from the robot, the camera module placed below the deck will use image recognition to find out what card is handed out. By storing info about all the cards handed out the system can either be set to play as an unbeatable player, or just use the information about the cards it hands out to itself. As it throws out a card, the arm will rotate a set amount of degrees before it throws out the next one. This is how we separate what cards go to what player. A temporary sketch of the card dealing functionality is a 3D animation of a simple conveyor belt transporting the cards. This isn’t necessarily the design we have in mind but serves as a visual representation for now.

Another function of the smart dealer that has been visualized is the smart dealers ability to collect cards after a round of poker has been played. The same conveyor belt used to hand out the cards to the players is used to transport the cards to the card shuffler. Aswell as the function to hand out the cards, this is also a very rough first draft and isn’t representative of the final design.

Many aspects within our concept are still under discussion. We are constantly working to find the best solution for our subsystems, and working with an iterative method we will see changes throughout the development process. One of these functionalities that we are still evaluating is the functionality of shuffling and dealing out cards to the players. The doubt is for example, if we want to read the cards from the bottom of the dealer subsystem, or if we can read the cards while we deal them out. If we want to read them before we deal them out we need to deal out the bottom card, this might be hard to do while the rest of the deck lays on top. But on the other hand if we deal out the top card we have to identify what card it is while it is mid air. We have to do further testing to find out if our recognition software is capable.


Leave a Reply