Mister Dealer
(Card Dealing Robot)

Eric Cherba
Greg Peszek

EECS 373 Final Project
Brehob/Smith W04
4/21/2004

Description:

“A card dealing robot and command interface to play different games, such as blackjack or poker.  The robot accounts for multiple players and arbitrary sitting positions and interfaces with the user through the terminal.”

Media Component interfaces
  1. Rotational motor


    2. The rotational motor is mounted on the base of the robot and controls the angle at which the dealing mechanism is facing. This motor is pulse code modulated and can rotate the robot either left or right. Pulse code modulation is done in FPGA hardware, the controlling of direction is done in physical hardware on the protoboard. The rotational motor status (speed/direction) can be changed by writing to their respective memory addresses and the status can be read from those same addresses.

  2. Card feeding motor


    3. The card feeding motor is positioned directly below the cards and allows for the movement of the bottom most card in the deck. This motor is pulse code modulated and can pull in or push out a card. Pulse code modulation is done in FPGA hardware, the controlling of direction is done in physical hardware on the protoboard. The card feeding motor status (speed/direction) can be changed by writing to their respective memory addresses and the status can be read from those same addresses.

  3. Card dealing motor


    4. The card dealing motor is set at the end of the robot and deals the cards that are fed to it. This motor is pulse code modulated to allow for the robot to deal itself. Pulse code modulation is done in FPGA hardware. The dealing motor status can be changed by writing to its memory address and the status can be read from this same address.

  4. Rotation sensor


    5. Attached to the back of the robot is a wheel with four sections of retorflective tape. This wheel is geared up from the rotation motor so it spins faster than the robot rotates. A reflective sensor is mounted directly behind the wheel and changes status whenever the wheel rotates. This signal is tied in to an interrupt on the MPC823 where the interrupt handler determines which way the robot is rotating (clockwise or counterclockwise) by reading the status of the motor itself, then it increments (or decrements) a global rotation variable which effectivly keeps track of the position of the robot.

  5. Sonar sensor


    6. To determine the positions of the players, a sonar sensor was mounted to the front of the robot. This sensor takes in a 10 microsecond input pulse, then sends out an inaudible sonar pulse and drives its output line high. Once the sonar pulse is recieved back, the sonar sensor returns its output line to low. This output line is tied in to an interrupt on the MPC823 which then checks to see how long the output line was high for, then returns that number. During a player scan, the robot rotates, scans 10 times, and takes the average of the scans. Using that data and threshold detection it is able to determine the approximate positions of the players.

Largest difficulty encounterd

By far the largest difficulty was dealing with the interference from the motor on our sonar and rotation sensors. We discovered that if the dealing motors were left on high, the sonar sensor would interrupt constantly. It took some time to discover and fix this problem, but even after we had sufficient bouce detection in place, we discovered that the input line to the sonar sensor was being affected as well. If the motors were left on, the sonar sensor would start to send out sonar pulses when it was not explicitly told to do so. We solved this by creating logic in the FPGA to determine if the motors are on, and if they are to ignore any sonar interrupts.