Robot Blackjack
Edward Giardina
Project code:
Necessary Equipment:
Handy Cricket, v1.1
Panasonic Barcode Reader, model ZE-84TWM1FD
'LogoChip' microprocessor (PICmicro PIC16F876-20/SP)
Useful websites to build your own:
Fred Martin's Cricket Bus and Logochip reference
How I came to build a Blackjack-playing robot
There are several reasons that I chose this project and several reasons why I implemented the project the way I did. First of all, the robot I built plays a game. Game-playing is an important part of Artificial Intelligence research, and I felt that if I ever wanted to explore game-playing in depth, I could use this project as a jumping-off point. Blackjack, the game itself, is computationally simple. There are only a few variables in the entire game, and for the individual player, the only knowledge necessary would be his own hand and how to play that. For strategy, it helps to know the dealer’s hand and the other player’s hands, but in essence, an entire blackjack shoe can be played successfully without seeing anyone else’s cards but your own.
There is
also a reason I picked this game that intrigued me more than just game-playing.
Blackjack, while computationally simple to implement in software (witness how
easy it is to find free blackjack simulators or to play blackjack online), is
rather difficult to implement in the real world for a robotic system. Cards are
almost a two dimensional object that would be hard to manipulate for a robot.
Cards don’t always end up straight or even, so they might be very difficult to
read optically. This is a case where simple cues and symbols which humans find
incredibly easy to read and decipher become a monumental task when building a
robot. So I wanted to focus not on the rules of blackjack, but rather on making
a system that could sit at a blackjack table and play *with* humans. This
divide of the computational concept of software in a robot and the actual
physical means to gather data for the software was very interesting. It had
been posed to me before in other problems, such as ‘building a robot to do
laundry’. While the sequential instruction and events of laundry are easy, i.e.
separate dark clothes from light clothes, place in washer, etc, the physical
identification of dark clothes, the grasping and moving of the clothes, those
problems are perhaps exponentially harder to implement. I had hoped by
implementing a robot that could work with real, tangible, symbolic cards, I
might reconcile these differences.
Narrative description of construction
At Professor Martin’s suggestion, I investigated serial barcode readers.
Figure 1: a Panasonic Serial barcode reader
Common point-of-sale computer systems used in retail transactions, these barcode readers could be used to identify the cards used in blackjack without heavy modification. The cards, even with a printed barcode on them, are still valid symbols to humans.
Figure 2: Modified playing cards with barcodes
I thought about how to directly interface a barcode reader. I could write a PC program that read the serial input/output. However, that seemed to defeat another point of the project. You see, an entire PC really wouldn’t fit on a blackjack table. (Maybe at a blackjack seat, but that’s another point entirely.) So, I thought of the two robotic brains I had worked with previously: the handy board and the handy cricket. The problem is, I didn’t want to write complex serial interfaces for the handy board or handy cricket. So, since we had worked with both the PICmicro Logochip and the Handy Cricket, I decided to use these platforms. The Logochip has a built in serial interface, so that would make the project easier. The Logochip would act as a bus device, passing along its last read barcode when the cricket asked for it.
Figure 3: Block Diagram of Devices
I felt this design would simplify programming the Handy Cricket. The idea behind building a commercial robot is to make it easy to use. This takes a huge software burden off of the cricket, and places it on the Logochip, which, if ever sold commercially, could be burned with the proper code, allowing the user to focus time and energy on the actual implementation of play.
So, after devising the block diagram and how I would develop the device, a few questions of methods posed themselves. I first had to do a fair amount of research into how the specific scanner that we had in the lab worked, and how the data was parsed and presented over a serial line. I also had to do lots of research into the different types of barcodes in use, and select a barcode that the scanner itself could recognize, and that would present the minimal amount of data. The less data that the LogoChip had to parse, the better.
I had to encode ten different blackjack values: 2-10, Face cards, (also ten) and Ace (eleven). At first, I thought I would use UPC-E. UPC-E sends the standard 12 digit barcode found in the Universal Product Code, the code used on most items sold in retail. I thought this method would be easy, since I could parse out the first eleven digits and examine the twelfth one. However, on further examination of the specs that the scanner had, and on available barcodes, I found that the ‘CODE-128’ specification sent only the characters encoded, so it was possible to send a single byte. This was ideal, since a single byte enumerated all the information we would need. The barcode scanner I have returned ASCII values of the symbology encoded in the barcode. So, I printed barcodes and placed them on playing cards, using CODE-128, and the numeric values. The exception to this was the values that were higher than 9. Ten and eleven were encoded using : and ; . Those are the ASCII symbols directly above nine. That way, if you take an ASCII number and subtract 48, you get its decimal value, even on numbers with two digits, which don’t exist on the ASCII Table .
After developing a scheme, I then had to physically interface the devices with the scanner. This proved to be the toughest part. I tried directly examining the ASCII readout of the scanner using a C program I had written under Linux. The approach was to initially read and command the scanner to do bits and pieces, then assemble those steps into code on the Logochip.
Figure 3.a Logochip Wiring diagram
However, instead of being very straightforward, as I had expected, the scanner kept spitting back garbage. Varying garbage, but garbage nonetheless. I tried numerous configurations for about two weeks, parsing the data, examining it, and throwing it away. I tried using the oscilloscope to examine the data coming back to confirm correct timing, baud rate, parity, stop bits, etc. Still no luck, since by measuring the tics on the oscilloscope we determined the proper baud rate. I recruited Professor Martin to take a look at the puzzle, and he, with a little scope ingenuity (something I think I gained a bit of thanks to this project) determined that, even though it was mentioned nowhere in the documentation of the scanner, that it used inverted TTL serial logic.
After that hurdle, I was able to use the LogoChip to send the full range of commands that the scanner could receive, and I was able to read back and store the data the scanner sent. Reading the data on the LogoChip meant that I had to do research and examine the different built in registers for handling serial communication on the LogoChip. This was a non-trivial task, and for a while I thought I might have to program in PICmicro assembly for the serial communications. But, after some tinkering, I found the proper registers to poll different situations, such as ‘whether a new serial event occurred’ and ‘is the serial line clear for transmitting a new byte?’
The last step was interfacing that LogoChip as a serial bus device. I also ran into a small snag here, as I forgot that the scanner sends a <CR> ASCII character. I had to parse out, or throw away, the <CR> values so that the PIC only read the data. Subsequently, since this snag ruined my ‘last minute timetable’ arrangement, I wasn’t able to demo the project at Botfest.
Finally, the cricket has a rudimentary program which keeps track of card value and game status, so it knows what card it has received, and whether to expect another one. It also uses the LEDs on the cricket motor ports to indicate whether to hit or stay. When properly labeled as HIT and STAY, a working demo emerged. The project was successfully demoed at the University's introduction session to incoming students on 4/6/03
Figure 4: Completed Project
obstacles to further functionality
The primary obstacle to taking the blackjack playing further is having only one barcode reader. Because the cricket can only see its own card, it will never play with Basic Strategy. The face-up card the dealer shows is imperative to playing blackjack well. So, two barcode scanners might be better than one in this case. Since I have two at my disposal, this could be done. Multiple devices can be hooked up to the cricket bus, and each PICmicro could have an ID. A Dealer’s ID would be different than the player’s ID.
Another obstacle is the rigid design set. In other words,
since I made the scanner PIC and the cricket work so closely together, and I
wrote the cricket code rather hastily, the cricket can’t exactly play well at
all. Another issue is that I treat Aces to the cricket as 11 values only. This
handicaps the cricket as a blackjack player, since Aces can be 1’s, and it is
often in the player’s favor to hit on a soft hand.
further planning activities
I think this project was an interesting exploration in barcode reading and how barcode schemes work. However, a real blackjack robot might use conventional, off-the-shelf cameras, like the CMU camera. The handy cricket code might be exactly identical, but a new PICmicro chip and new logo code would be warranted. Also, external communications, perhaps voice recognition, might add to the human interaction of the device. Since I love researching ways to beat the casinos, imagine the cricket interfacing with a very tiny camera kept in a pair of eyeglasses. The cricket could also run a display of some sort back to the user. The cricket could count cards and formulate a good move for the player, taking all the work out of it.
The largest project I could undertake with the robot would
be to have the robot also keep track of betting chips. Betting is an important
part of Blackjack and it would be fun to build a robot to not only push chips
on the table before each game, but also reap in the chips when it won.
what you didn’t do
I didn’t have time to implement good blackjack playing rules. Currently, the bot hits on 16 and stands on 17. I also didn’t have the robot indicate its choice of ‘hit’ or ‘stay’ using hands, instead I used LED indicators on the motor ports of the cricket. The most discouraging part about the robot playing blackjack is that it doesn’t know when it has won, since it can’t examine the dealer’s cards.
Overall, I had a lot of fun with this project, and I wish I
could have demoed it at Botfest.