Double Down

The barcode scanning of the playing cards was carried out through the use of a readily available device known as a "cuecat." These devices, created by Digital Convergence and manufactured by Radio Shack, could scan UPC-A and Barcode39 numerical values and (originally) output an encrypted source to proprietary software. Nowadays, however, it is more common to find cuecats already "hacked" than not in order to disable the encryption and simply output ASCII keyboard codes. Therefore, scanning a UPC or Barcode39 font "types" its real value to the computer it is plugged in to.

Due to the limitations of xPC Target, we were forced to use the PS/2 keyboard input on a seperate computer than our PC/104 stack. By opening notepad and begining our card dealing procedures, we could view the output of the barcode reading.

Posted by John Hanauer at 09:18 AM | Permalink

The :CueCat was a barcode scanner manufactured by vendors of RadioShack Corporation in the early 2000's. The product and associated intellectual property would instantly and directly link product UPC, EAN, ISBN as well as the unique :CRQ Cue codes to their appropriate web sites. Usually these were to links buried deeply within a site which could be further targeted demographically or geographically. The unique Cue code The unique Cue codes were placed within traditional media content and some advertisements in publications like Wired Magazine, Forbes and its specialty magazines, Parade Magazine and several daily newspapers. Product Cues were also placed in many catalogs to facilitate instant e-commerce shopping and the automation of wish lists. As you can imagine, this technology could eliminate search with "laser beam" accuracy.

The "tethered" Cue:Cat was just the beginning of the story. Portable scanners like the one manufactured by Cross as a pen, and a keychain scanner were ultimately cost-reduced and readied for deployment. This "store and forward" or "bookmark life" concept was just beginning as the dot-com crash and advertising money around it started to crumble. Today, everyone with a mobile camera phone has the potential to read barcodes, thus negating the need for a separate scanning device that DigitalConvergnce had produced to achieve the ultimate goal of linking the physical world to virtual space.

UPC Code Since January of 2002, the database servers which provided this machine-readable code to Internet URL linking are no longer in operation. The desktop client, which requires a registration code, is no longer supported, nor can these codes be generated for the Windows PC or Apple OS-X software.

The weak encryption from the Cue Cat, put in place to protect the company under DCMA laws, can be circumvented via instructions that can be found on the Internet. Many third party book, CD, DVD, video game and other media home inventory and web applications can even accept the obfuscated output and convert it to the original code format. If you are looking for the rare USB or popular PS/2 keyboard wedge CueCat, they can be found inexpensively through many websites online.

Posted by John Hanauer at 08:19 AM | Permalink

Computation was taken care of by our PC/104 stack. This device was a computer on its own and ran all out simulink processes on it. The simulink file is here. There are no embedded matlab functions present anywhere within our simulink file.

The model begins by storing a state variable to keep track of the present dealing positions. Feeding this into the state machine, it can grab out what dealing positions it wants and create motor control signals from that. The subsystems within the top level include the state machine, the motor control, and the motor steady test.

Posted by John Hanauer at 07:27 AM | Permalink

The state machine was implimented using what simulink calls a "multiport switch" as a ROM table. By inputing the present value of the state variable, the program indexed and addressed the current variables it needed to deal the card ot the right position. The variables it used included Left(0) or Right(1), Card Position (positive or negative integer based on starrtup position being 0), Whether to wait for the PushButton or the Motors to settle, and what the next state would be.

Posted by John Hanauer at 08:35 AM | Permalink

Posted by John Hanauer at 08:34 AM | Permalink

Using simulink, the motors were controlled via PID compensators. The Kp gain was 100, the Kd gain was 5, and the Ki gain was set to zero.

Posted by John Hanauer at 08:38 AM | Permalink

The motor steady check would output a true signal if the motor was within a certain error tolerance (set by a constant) for the last half second (also changeable by a constant). It would use an incremental counter multiplied by appropriate gains to convert to seconds, but essentially would carry out the following equation:

Counts = (Within_Tolerance*(Not Stable) + Counts)*Within_Tolerance

This way, counts would increment by Within_Tolerance each dt, and since Within_Tolerance only holds zero or one, it would either increment, or become zero, thus multiplying the whole sum by zero and starting over. Also, but multiplying Within_Tolerance by the opposite of Stable, once the motors did become stable the counter could stop thus preventing overflow.

Posted by John Hanauer at 08:43 AM | Permalink

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.

Posted by John Hanauer at 01:19 AM | Permalink

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.

Posted by John Hanauer at 01:17 AM | Permalink | TrackBacks (1)

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.

Posted by John Hanauer at 01:09 AM | Permalink | TrackBacks (1)

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.

Posted by John Hanauer at 01:04 AM | Permalink | TrackBacks (1)

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.

Posted by John Hanauer at 12:58 AM | Permalink | TrackBacks (1)

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

Posted by John Hanauer at 09:15 PM | Permalink