Main | March 2006 »

February 10, 2006

Project Proposal - Main Control

This entry contains the continuation of our project propsal, found here, and continuing from here.

The following is taken from our project proposal:

3.3 Main Control

The main control will be a module in itself within Simulink, but have no physical representation other than the xPC Target and/or Host. Its functionality will be transparent to all other layers, and it will primarily communicate with the dealer-cart because the main control believes this to be the only thing it can control. It will also communicate with a user interface, however that is implemented (either hard coded or through actual buttons). Therefore, it will send whatever signals necessary for not only dealing whatever game it believes it is playing but for dealing cards to play the game.

For example, if playing blackjack, it would first deal the game: one card up and one down to the dealer, and two cards up to the user. Then it starts playing, by waiting for the user to “hit” and then dealing the appropriate cards until they “stay.” If the user “busts” the game is over, if not, it will hit until it either beats the player or busts. The main control would have to send to the dealing-cart only the necessary cards to deal for this interaction, thus keeping the game completely transparent to the dealing-cart.

Project Proposal - Card Reading

This entry contains the continuation of our project propsal, found here, and continuing from here.

The following is taken from our project proposal:

3.2 Card Reading

The card reading layer will be necessary for determining what cards are dealt what players. This has many uses, but is primarily necessary if our dealer will know how to play blackjack. This module will only talk with the single-card-dealer to minimize communication points and so that the single-card-dealer can trigger its flip process. Once the card-reader has determined what the present card is, it will pass a six-bit value to the single-card-dealer. The single-card-dealer can then flip the card and then pass the six-bit value back to the dealing-cart. The dealing cart can then pass this back to the control to signalize that the entire process has finished dealing to the appropriate position. Depending on the game being played or the card being dealt, the control can decide whether to keep or trash the card-value that was read.

The actual card reading computation will depend on if we implement barcode-reading using one sensor per player (2 total), or two sensors per player (4-total). The first option is to use real barcode printers/readers. This might be easiest if the commercial barcode readers can simply read off 1-52 depending on the card and pass that as a binary signal. The next option is to have two photo-reflective sensors that read two tracks of black marks. One track for clock cycle, the other track for actual information. Using one photo-reflective sensor either means placing the sensor inbetween tracks to read variable amounts of light and convert that to information, or to simply feedback card position from the dealing-belt and transform the time information to position information. This might make things more complicated not only in computation, but in removing some of the transparency between the card-reading layer and the card-dealing layer.

Project Proposal - Dealing an Entire Game

This entry contains the continuation of our project propsal, found here, and continuing from here.

The following is taken from our project proposal:

3.1.2 Dealing an entire game

When the dealing-cart receives a signal from the main control to deal to a particular position, it will first move to that position. It will then pass the appropriate signals to the single-card-dealer to deal what the main control told it to. Because the processes for dealing a single card are transparent to it, it will wait for an all-clear signal from the single-card-dealer. Once it receives the all-clear, it will pass this signal back to the main control. It will then await to receive its next instructions, and when it does it will move to the next position and pass the next appropriate signals for dealing the next card and so forth. This step will utilize the motor devoted to moving the cart on wheels. It will use position feedback to control the motor to move itself from one position on the table to the next.

Project Proposal - Dealing One Card

This entry contains the continuation of our project propsal, found here, and continuing from here.

The following is taken from our project proposal:

3.1.1 Dealing One Card

Starting at the deck, the first step will be controlling the motor which drives the belt with the rubber flap. This particular module will simply do position control of the rubber flap around the belt. For the purposes of this explanation, it is assumed the rubber flap begins on the top side of the belt. When a card needs to be dealt one direction, the flap will be positionally controlled to move either clockwise or counterclockwise around the belt until it makes contact with a card on the bottom side of the belt and begins to drag it towards the appropriate person. It will continue on until it returns to some home position on the top side of the belt.

The next step is flipping or not flipping the card. If we are using a foot at the bottom of the ramp to stop the card or not, then when the single-card-dealer is given the flag to either flip the card or not, then by the time the card is down the ramp the foot will already have moved into or out of the way. From there, as the card is being dealt, it passes whatever photosensor is used for card reading. It is possible to use this sensor from the card reader not only to determine what card is being dealt, but also to determine once the card has reached a certain position down the ramp. The card reader module implementation and control is completely transparent to the single-card-dealer. Either by waiting for the card reader to send a signal that it is finished, or through just a simple time-delay signal, the solenoid to flip the card is activated. Once the flipper returns to home position, a signal will be passed back to the dealing cart to indicate it is finished.

Project Proposal - Computation

This entry contains the continuation of our project propsal, found here, and continuing from here.

The following is taken from our project proposal:

3 Computation

The computing necessary for the automatic card dealer and card game player needs to be very carefully planned and implemented to reach the appropriate result. It will need to be largely modular in Simulink much like object-oriented programs are modular in a real programming language. With clever and extensive planning before beginning the programming stages, there will be better versatility in what the machine can do. While the main focus will be implementing a blackjack dealer and player due to time constraints, if the possibility of dealing and playing any game is kept in mind, it will not be hard to add the implementation for additional games later.

3.1 Card Dealing

Card dealing will have two layers of computational modularity in simulink, implementing the functionality for dealing one card, and utilizing this functionality for dealing an entire game.

The single-card-dealing functionality is simply focused on all operations necessary for taking one card from the deck and getting it to the table. Its abstraction can be visualized as the internals of the dealing cart. This stage assumes the dealing-cart is already in the necessary position on the table for dispensing a card either dealer-side or player-side. Additionally, this stage will be modular enough that its processes will be transparent to the parent process calling it, in this case the cart on wheels. This way, the dealer cart can move to whatever position necessary and then pass a signal to deal one card either player-side or dealer-side and either face-up or face-down.

The functionality for dealing an entire game is primarily focused on getting the dealing-cart from one dealing position to another. Its secondary purpose is an intermediary between the single-card-dealer and the main control. Its abstraction can be visualized as the dealing-cart on wheels as a whole, ignoring the internals. Its functionality will be transparent to the main control, and the functionality for dealing one card will be transparent to it. When given a signal from the main control to deal to a particular card dealing position, it will move to that position and then pass on whatever signals necessary to the single-card-dealer.

Project Proposal - Card Flipping

This entry contains the continuation of our project propsal, found here, and continuing from here.

The following is taken from our project proposal:

1.2 Card Flipping

When dealing a game of blackjack, some cards need to be face-up and some face-down. When a card is dispensed from the deck housing is lying facedown and can be allowed to slide down a ramp and onto the table. So far we have thought of two different systems for flipping the card face-up before placing it on the table.

Figure 6: Flipping Method #1
proposal_flipping_method_1.jpg

The first method uses a foot that is lifted up by a small solenoid at the end to the ramp to prevent the card from falling onto the table. Then, a second solenoid pushes the top of the ramp while it pivots at the base. The foot will be an acute angle to hold the card in the ramp until it has been completely overturned.

Figure 7: Flipping Method #2
proposal_flipping_method_2.jpg
The second method uses a light sensor near the bottom of the ramp to trigger a solenoid at the top of the ramp, so that when the bottom of the card covers the sensor, the solenoid quickly pushed the top of the card out, flipping it in the air. A bar attached to the solenoid would ensure it flips the way we want. A light sensor makes most sense as a touch sensor might not be sensitive enough to feel something as light as a card.

Project Proposal - The Player/Card Recognition

This entry contains the continuation of our project propsal, found here, and continuing from here.

The following is taken from our project proposal:

2 The player
Figure 3: Card’s Barcode
proposal_card_barcode.jpg

For our device to play any number of card games, it will need to know what cards it deals itself and sometimes which cards are dealt to the player(s). After considering several methods we agreed upon a barcode and phototransistor system, as it would be the simplest to implement in our design and doesn’t require metal contacts or stickers on the cards so that they remain slick for easier dealing.

2.1 Card Recognition

Using a template, a binary barcode will drawn on each card in opposite corners. The barcode will be composed of two parallel 6-bit binary numbers. The first set of lines will be all black and will act as the clock cycle for triggering the reading of the other set of lines next to it. The second set is then the one holding a binary number 1-52 for each card in a deck.

Figure 4: Methods for Sensing Barcode
proposal_barcode_methods.jpg
An LED will light up the underside of the card and either one or two phototransistors will detect if the card reflects or absorbs the light. Two phototransistors can be used as digital inputs for reading the two lines, or one phototransistor can be used as an analog output to differentiate between no lines, one line, or two.
Figure 5: Sensor Position
proposal_sensor_position.jpg

The phototransistors and LED will be positioned at both outputs of the deck housing and will read the barcode as the card is dispensed. They can either be under a clear ramp that the cards slide down or in a recess of an opaque ramp.

February 09, 2006

Project Proposal - The Dealer

This entry contains the continuation of our project propsal, found here.

The following is taken from our project proposal:


1 The Dealer

Cart.jpg

The cart has 4 wheels, powered by a DC motor, and rolls along a straight path of approximately 1-2 feet. As it rolls, the machine deals out the necessary cards for blackjack: the dealer’s 2 cards, the user’s 2 cards, and any additional “hits”. The DC motor is equipped with an encoder to determine where to deal the cards such that they are evenly spaced and do not overlap.

To prevent the cart from rolling off a table, it is equipped with an infrared range sensor on each end that will detect the difference between the tabletop and the floor. In the event the IR ranger detects the edge of the table, the machine will stop moving and produce an error signal or message.

The main component of the cart body is the storage bin for the cards. We intend to play with 2 to 4 decks, which will rest on a spring-loaded bed. This spring lifts the deck as cards are dealt, keeping the top card at a constant height for dealing. By dealing from the top of the deck, there is less weight on the card being dealt, thus reducing friction and enabling a more reliable deal. To deal from the bottom of the deck places the entire weight of the deck on the dealt card, increasing friction. Additionally, dealing from the top follows standard casino rules.

To lift the deck, the spring must simply be able to exert a force slightly larger than the weight of the deck. As cards are removed from the deck, the weight will lessen and the deck will become thinner. Accordingly, the spring will lengthen, given the extra space, and will exert less force (by Hooke’s Law) as the spring nears its natural length. Thus, by carefully selecting a spring with the appropriate length and spring constant, we can expect the top card to always be in the correct position for dealing, with the correct amount of force acting on it.

The cards are dealt using a rubber flap attached to a belt driven by a DC motor. The motor drives the belt clockwise or counterclockwise, depending on whether the card is being dealt to the user or computer. The rubber flap, selected to have a very high coefficient of friction, moves around the belt until it contacts the top card. As it continues along the belt, the flap drags the top card off the deck, since the flap/card friction will be considerably higher than the card/deck friction. Also, by using a single flap to contact the card, none of the other cards below will be touched or moved, which could potentially jam up the dealer. To reduce friction further, we are investigating the use of a small CPU fan to create a thin air pocket between the top card and deck.

Project Proposal - Introduction

The following is taken from our project proposal:

Our goal is to design and build an automatic card game capable of dealing cards for a game of Blackjack and then playing the game with a user. This machine has virtually endless possibilities in the number of games it could play and the number of users with whom it could play. We would like to program the computer for multi-user games like Texas Hold-‘em Poker, but given the time constraints of the quarter, we intend to focus primarily on Blackjack.
proposal_overall_sketch.jpg

The machine can be divided into two primary roles: a dealer and a player. The main component of the dealer is a small cart that rolls back and forth on the playing surface (tabletop or floor), as seen in figure 2.

Cart.jpg

Paul Eats Babies

I believe I speak for everybody when I say that Paul eats babies.