« February 2006 | Main

March 17, 2006




The Double Down card dealer is a fully programmable automated card dealer. It has the ability to deal a card in two directions (left or right, dealer or player, etc) while at the same time moving linearly perpendicular to those directions (card stack 1, 2, 3, etc).



Decent Back and Forth
Class Demo Day
Tech Demo Day 1
Tech Demo Day 2



The majority of the electrical work for this project was comprised of linear amplifier circuits to drive the DC motors. Each of the two motors had the following circuits created:


The V_in signal came from the PC/104 stack analog outputs driven from the computational model. The motors were each driven usen +/- 15V, but the stack could only output +/- 9V. Therefore, to push 9V up to the 15V source, the multiplier 5/3 (1.667) was chosen to push the limits. This would give us ultimate torque and speed.

The solenoids were also driven with a similar amplifier, though they only needed 12V.


Flipper & Scanner


Each playing card had a barcode printed onto each side, so that as it exits the stack the cuecat will scan it and know the card being dealt. This allows the robot to play any number of games rather than just deal them. The cuecat was disassembled into two parts. The black housing with the red light is the photodiode, LED and lens system for reading, and on the other side of the solenoid is the electronics that convert the signal into a keyboard signal. The cuecat was glued in place, and had to be positioned so that it was right against the surface of the barcode being scanned.

The Solenoid was included, but never fully functional in our project. For many games, some cards need to be dealt face up. The solenoids were added so that as the card is leaving the dealer the solenoid would kick up the back end of the card, flipping it over mid-air before landing on the table. The physical flipping worked quite well, but the actual timing of when to fire the solenoid was never implemented in out code, and is very difficult to do by hand.



The bulk of the body was constructed out of polycarbonate for its ease of machining and for viewing the internal mechanisms. Each piece was designed by hand, in SolidWorks, and then machined by hand in a mill. The pieces were glued together with a plastiweld glue and screwed together as well. The opaque pieces in the diagram represent pieces of UHMW for the bed and the axel bearings. UHMW was again chosen for its low friction, cost, and ease of use.


Another Maxon motor from the lab was used to control the movement of the cart. A 72:84 teeth ratio was used to gear down the motor for greater precision of movement. The gearing and the motor control gave very accurate and still rather fast movement. The gear ratio was chosen as it was the greatest ratio available given the physical constraints of the wheel size and distance between the motor and the axel.

March 16, 2006


bulk materials:

  • clear polycarbonate
  • blue UHMW (mcmaster)
  • aluminum stock

mechanical components:

  • springs (ace hardware)
  • shoulder bolts (ace hardware)
  • screws and set screws
  • Maxon motors (from the labs)
  • solenoids (jameco)
  • gears and hubs (robotzone)


  • cuecats (purchased from ebay)
  • PC/104 stack
  • resistors and transistors

if unlabled, the material was aquired from the shop


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.

Cuecat History

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.


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.



As seen in the picture, the main body of the dealer consists of a bed on which the cards rest, 2 bumpers that limit clearance to allow dealing of one card at a time, 4 springs that constantly raise the deck such that the top card is at the appropriate dealing level, a wheel that spins in either direction to deal cards, a flap attached to the wheel that sweeps the top card off the deck, and a motor that controls the motion of the wheel.


The bed was machined of Ultra-High Molecular Weight (UHMW) Polyethylene, selected primarly because of its low friction and low cost. We wanted to minimize any friction that could inhibit the cards in exiting the dealer. It was designed to ride on 4 shoulder bolts to prevent twisting and binding inside the dealer and to ensure the cards remained level.


The bumpers were machined of polycarbonate and were a 3rd generation design. The first two essentially worked, although with less consistency, as cards seemed to have more difficulty exiting the dealer. Polycarbonate was selected because of its availability in the machine shop. The original design specified UHMW Polyethylene for low friction; however, we were unable to obtain this for the 2nd and 3rd generation designs.

The springs were purchased based on their length, diameter, and wire gauge. We needed a spring that was longer than the deck was tall to ensure the deck was constantly being raised, with an appropriate diameter to fit the shoulder bolts, and of very thin gauge to create enough force to lift the deck but not pinch it. The springs we found were selected on a trial and error basis, and did not have accompanying specifications.


The wheel was machined out of stock aluminum from the machine shop. It attached to a shaft, also machined from aluminum, which joined the wheel and motor. Aluminum was used because of its availability and low density. To further reduce weight, we cut holes in the wheel using a CNC mill and trimmed down the thickness using a lathe. The wheel had a diameter of approximately 3.5", which is equivalent to the length of a card. The diameter was specified to maximize the contact between the flap and card, while fitting in the space constraints.

The flap was cut from a sheet of Neoprene-like material obtained in the machine shop. This material proved suitable given its flexibility and high friction characteristics. This component went through countless evolutions, mostly based on a trial-and-error process. We wanted the flap to contact the card and sweep it off the top of the deck by overcoming the friction forces holding it in place. We had many good ideas on how to achieve this, many of which were eliminated once tested. The final design is a strip, held to the wheel by a metal bracket and bound with a piece of electrical tape.

The motor was obtained from the mechatronics lab and is the same motor used in the in-class labs. We used this motor simply because of its availability, familiarity, and zero cost. This was likely not the optimal motor for the application; we would have preferred a motor with higher torque and lower velocity to deal the cards. As it was, we had to power the motor with a +/- 15 V swing, which simply spun the wheel more quickly, in order to deal a card. By spinning the motor quickly, we were able to overcome the forces holding the card in place, although this velocity then carried through to the end of the dealing process, when the card was then flung distances up to 3 ft. A higher torque motor would have produced more pull on the card at a lower velocity, which would have provided a more controlled method of removing a card.

Once all these components were assembled, there was a great deal of fine-tuning that had to be done to allow the dealing of one card at a time. All the mounting holes for each component were slotted to better faciliate adjustments. This was an extremely invaluable foresight that led to the successful deal. Without these slots, adjustments would have been very difficult or virtually impossible. In particular, the bumpers were slotted to adjust the clearance between the walls of the dealer and the bottom of the bumpers. This distance was set to allow one card to easily pass through, but prevent multiple cards. The precision of adjustments for this aspect was astounding. Setting the clearance to one card proved too tight, while two cards proved too loose. The optimal clearance was determined to be the thickness of one card, plus the thickness of 3 sheets of standard office paper. The second area of adjustment was between the motor shaft and top of the deck. The motor had considerable flexibility in positioning to optimize the use of the flap. This adjustment required less precision, although it was equally frustrating to align.

March 15, 2006

Results and Reflections

Although it came down to the wire, we were able to align all the components just right, achieving our first objective of successfully dealing cards. Out of an inserted deck of 52 cards, we were able to deal all but 10 cards, a fairly low failure rate, given the complexity and time constraints of the project.

We were also able to achieve our second objective of reading the cards, although with limited success. We were only able to accurately read approximately 1 out of every 7 or 8 cards. This seemed to be a result of the dealer spitting out the cards too quickly for the scanner to read the barcode. Additionally, given the limitations of our PC-104 stack inputs and the ps/2 scanners we purchased, we were not able to interface the two, but had to output the card value to another computer and monitor.

Finally, we were able to achieve our third objective of moving the cart into different dealing positions with consistent success. After dealing a card in each direction, the cart moved to the next space without a single failure.

Our fourth objective, of lowest priority, was to flip cards as they were dealt. We were unable to address this task in our programming, although we were able to flip cards by activating the solenoids manually. We did not have time to fine-tune the timing between the card sliding off the deck, being scanned, and then being flipped before it left the dealer.

Although we were able to confidently declare our project a success, given that we achieved our three primary objectives, there are a number of improvements and changes that we would make in either continuing or redoing the project.

The biggest challenge we faced throughout the project was balancing the complexity of our mechanisms with the time constraints of the quarter. There were a number of changes we would have liked to make, had the project run a few weeks longer.

For example, we recognized early on that the springs used to lift the deck would have wide variance in applied force, depending on how many cards were in the bin. An entire deck compressed the springs by nearly 50%, causing the cards to bind and sometimes prevent their exit from the dealer. We would have liked to incorporate constant-force springs into the dealer, which would have applied the same force, regardless of how many cards were in the bin. We decided to stick with the standard compression springs only because the design was already developed and time was quickly growing short.

Another example is in the dealing wheel. We initially planned on using a belt with 2 sprockets that ran the length of the cards, and would pull each card entirely off the deck. However, once we began fabrication, we decided to experiment with a wheel instead, which was much easier and quicker to fabricate in the machine shop. By the time we realized that this was a more difficult solution to implement, we did not have enough time to order the necessary components and re-machine parts. We were able to make our single wheel work relatively consistently, but we believe a belt and sprocket system would have been even more consistent. Additionally, the belt would have allowed us to pull the card out more slowly, allowing the scanner more time to accurately read each card. As it was, we had to spin the wheel fast enough to simply accelerate each card enough for it to overcome the friction forces. This meant the cards flew out of the dealer, often distances up to 3 feet, and often moved too quickly for the scanner to read.

Although we were not able to accomplish everything we had originally outlined in the initial project conception, our ambitious objectives motivated us to develop the very best dealer we could in the short time we had. From here, our initial vision of an automated blackjack dealer and player is very attainable, and would only require the implementation of the card-flipping solenoids, a more consistent dealing mechanism using a belt and sprockets, and some additional programming.

We very much enjoyed working on this project and in this class, despite the difficulties and long hours, and we only wish we had more time to accomplish everything we wanted.

State Machine


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.

State Machine


March 14, 2006

Motor Control


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.

March 13, 2006

Motor Steady Check


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.