A Budget Pachinko Machine

High Level Design    top

Overview

Our project utilizes two microcontrollers. These two microcontrollers do not interface with each other except for a single reset bit. The first microcontroller is an ATMega32 and is used to controll all aspects of dropping a skittle. The second microcontroller is an ATMega644 and is used for all aspects of scoring. The division of control between two microcontrollers allowed for both partners to write code concurrently and without worry of affecting the other's.

Standards

The only noteable standard that was adhered to in this project was the control protocol for servo motors.

Intellectual Property

Pachinko as a game is wildly popular in certain regions, most notably in Japan. As a result of its popularity, every conceivable iteration of the inner workings of pachinko machines has already been patented. Due to its early origins however, there is no trademark on the name “pachinko” itself. "Skittle" however, remains the trademark of Mars, Inc. The artwork done on our machine’s backboard was done by an external artist and is her intellectual property. Nintendo holds the copyright for Mario, but the use of his image in our backboard’s artwork should be covered under the fair use clause.

Background Math

A machine involving a dead drop of a perfectly spherical ball with symmetric and completely filled rows of pegs follows a binomial distribution in terms of where the ball will land. A skittle is not nearly a sphere and our design has a spinning motor, highly asymmetric layout of pegs, and was not fully filled with pegs; because of this, the binomial distribution no longer applies.

Hardware and Software Tradeoffs

A large portion of our project was hardware based. Originally we had a very grand plan for the machine, and as construction got going, it became clear that it was going to take a substantial amount of time. Most of the tradeoffs happened in hardware, as that is not our area of expertise, and most of these tradeoffs involved simplifying or speeding up construction so that we would actually have something to control with our code. Simplification of the hardware usually led to some simplification of coding, so there weren’t many tradeoffs between hardware and software, but more between hardware and how much time we had left to practically finish the project.

We originally planned to have a moving dispenser on rails along the top of the case to allow for additional control. This concept failed because we were unable to fit the rails salvaged from a printer into the main pachinko case.

We also originally planned on including sounds and music. Initial testing showed the speaker salvaged from a printer was too quiet. We could have found another speaker or make other modifications to make the sounds work, but we were low on time and it was not essential to the system, so the idea was scrapped.

Another concept not implemented in the final version of our design was a tilt sensor which would work to prevent cheating. Testing showed that the sensor was too sensitive, and constantly triggered. We could have found a work-around or used another sensor, but we were low on time and the sensor was not essential to the system so the idea was scrapped.

In the spirit of reuse and recycling, we planned on using the seemingly unlimited supply of screws from the scanner and printers as the pegs in pachinko machine. This idea was scrapped because it was more important to us that the user be able to eat their winning skittles. The screws were deemed too contaminated to be allowed to come in contact with food, and so fresh push pins were used in their place.

High Level Block Diagram

Hardware    top

It is entirely possible that someone else could build this from what we have written. In fact, someone with access to better machining equipment could build one of much higher quality and durability than ours. One of our major challenges was just building the system physically. All of our electronics are easily replicable and someone with a moderate level of experience in wiring and microcontrollers should find success in building this or using our system to build something similar.

Hardware Design

The electrical schematic for our design is split between the ATMega32 and ATMega644. Both parts can be seen below.

Hardware Components

Schmitt Triggers

Schmitt Triggers are what notify the system that a skittle has scored in a basket. The actual sensors are analog, but the schmitt triggers cause their output to be converted into a binary digital signal. These are quite important for the system to keep track of the current score, and sometimes are finicky to tune. At first we tried a packaged Schmitt trigger, but due to lack of tunability, we decided to make our own out of op-amps and a potentiometer.

H-Bridge/DC Motor

The use of an H bridge to control a DC motor is fairly standard practice, especially in small electronics projects. The H bridge can allow current to flow either direction through a DC motor based on the logic inputs, which allows control of a motor in either direction. We used this in our project to add an element of both randomness and control for the user. We wound up using a Toshiba TA7291P package that is rated for 1 amp. Since our motor did not need extremely high amounts of current draw, this suited our needs nicely and was easy on the budget.

IR Emitters/Detectors

We used a set of 5 IR emitters/detectors in order to sense our skittle scores. The output of these were hooked into the Schmitt triggers which then fed into the microcontroller. The Schmitt triggers had to be extremely finely tuned because skittles are largely transparent to IR light, and therefore cause only a minimal signal at the sensor. Another of the challenges we faced with these was physically mounting them. In order for them to function, they needed to be moderately close and we had to make sure that the skittle would block off the IR emitter without getting stuck in our passageway. The imperfect spheroid shape of the skittles made this surprisingly hard. Eventually we figured out a system that relied on guiding the skittle through moderately close quarters.

Display Board

The display board shown below is a collection of components mounted at the top of the machine whose purpose is to provide the user with visual feedback about the system. An LCD is used to display the all-time highscore as well as useful messages. A three digit, seven-segment display is used to show the user's current score. Another, one digit, seven-segment display is used to indicate the state of the DC motor. A 5x7 LED matrix is used to show how many skittles remain in the user's current game session.

Physical Assembly

Dispenser

The dispenser is our proprietary Skittle distribution mechanism inspired by this. It consists of a wine cork that is hot glued to a servo motor at the bottom of a giant cardboard funnel. There is a channel created in the cork where the skittle sits when the servo turns, then the skittle drops out when the motor turns the other way. This method allowed us to reliably dispense exactly one skittle at a time. Every now and then none would come out or two would, but the vast majority of the time it would just dispense one, as planned.

Score Baskets

The score baskets are channels made of cardboard that catch the skittle and direct it in front of the IR emitter/receiver combinations. The skittles are then directed into the return chute for consumption by the player.

Skittle Return Chute

The skittle return chute is a series of cardboard channels that direct scored skittles through a hole in the bottom of the pachinko case. There were no substantial problems directing the winning skittles, but due to unexpected design constraints, we were unable to devise a losing skittle return chute. Given more time and a better layout of our parts, we could have made one, but as it is, this system is just for fun and a proof of concept, so this isn’t a major issue.

Software    top

The Files

schmitt.c

This is the sole contents of the ATMega644's programming. This is the main score detection and handling program. The default state of this program is to continuously and quickly cycle through the digits of the three digit, seven-segment display to display the current score. A score event will cause an interrupt and update the current score. The LCD is then updated to reflect both the all-time highscore as stored in the ATMega644's EEPROM and the "skill gap" between the highscore and teh current score. If the current score is ever higher than the all-time highscore, the new highscore is writen to the EEPROM and the LCD will display the message "Champion".

Also during the score interrupt, the individual baskets are polled to see which of them was scored upon. Once all baskets have been scored on at least once, the program initiates the jackpot subfunction which gives the user an additional ten points and displays "Jackpot" on the LCD

In addition to the above, the main function of schmitt.c constantly polls for the reset pin attached to the ATMega32. If the pin is high, the current score is set to zero and the LCD is refreshed.

Motor.c

motor.c is the code that runs on the ATMega32-based microcontroller. This is the board that is responsible for the control of all the motor functions as well as displaying relevant information about the number of skittles left and current motor speed. Pins B4:7 and C0:7 all control the LED matrix that displays the number of skittles remaining. Pin D5 is the PWM output that controls the dispenser servo motor. A0:7 control the seven segment display. It has all the inputs from the buttons on pins D0:3 and D6 and acts accordingly. It tells the other microcontroller when to reset to a new game by sending a high signal from pin B2. A quick breakdown of the functions are as follows:

matrixFull(char num) - Give it a number from 0 to 35, it displays that many dots on the seven segment display.

matrixRow(char num) - Fills up num columns in the current row.

debounce() - Checks debounce states for the buttons.

motorSpeed() - Updates the speed of the DC motor.

speedDisplay() - Displays the current speed of the DC motor on the seven segment display.

dispenseServoPosition() - Toggles the position of the dispenser servo if enough time has passed since the last dispense.

startNewGame() - Starts a new game if all the skittles have been dispensed.

Programming Issues

Servo

The very first problem that popped up immediately was the control of servo motors. Servos have a built in motor controller and potentiometer so that they can self-identify their location. You give them a signal telling them what angle to hold and they will try to hold that position as long as they have power. The signal required is a pulse-width modulated 50 Hz square wave. Varying the width of the pulse from 1 ms to 2 ms will send the servo through its entire range of motion. PWM is somewhat limited in the ATMega32 environment. It has three timers, but only one of them allows for fine tuning of the frequency. This timer fortunately has two PWM outputs, but this limits the number of servos that can be connected to 2 before software PWM would be required. We had three servos to control, but luckily two of them could be set to the same value. Unfortunately there was some back talk and noise in the system that caused malfunction when two of the servos were attached. With more time we would have resolved this issue by isolating the servos. In order to set the ATMega32 to the proper timing values, we turned on Fast PWM Mode with a prescalar of 256. With this prescalar, we found that the range of the servo’s motion exists by setting OCR1A/B to 33 for a most negative position, a 93 for a neutral position, and 153 for the most positive position.

Debounce

Another tricky part was the debouncing of the buttons. Our method should have worked fine, but when tested, the buttons seemed mostly unresponsive. After much testing and scoping of signals, it was found that the noise from the power supply was triggering button instances and forcing the debounce function to run. This tied up the microcontroller so that valid button presses were missed. After adding a noise eliminating capacitor across the power supply, the buttons seemed to work, but not every time. The operation code itself is somewhat slow and doesn’t always take the same amount of time to run, so when the buttons were pressed and the accompanying control code ran, the microcontroller was unable to register any other button presses until the control code finished. We implemented a work-around which lights the decimal point in our seven segment display when the code is ready to read a button and turns off when the microcontroller is otherwise occupied. This allowed for every button pressed to be registered and as such increased control of the system while cutting down on user frustration.

Basket Tracking

A successful score on the baskets is transferred to the microcontroller as an external interrupt. This method of control works reliably. The issue arose when we wanted to have five score baskets and have system recognize which basket was scored upon. There are only three external interrupt pins on the ATMega644, but it can also register large groups of pins (>5) as software interrupts. Initial planning had all of the pins of the microcontroller occupied and so the software, group interrupt approach was not something we could do (other pins would have caused an interrupt to trigger without a scoring event). We got around this by having all of the baskets wired externally to a logical NOR gate which we used to drive a single external interrupt pin, while keeping each individual basket connected to simple input pins. When the interrupt is triggered, we poll through the baskets’ input pins to find which one caused the trigger.

Results    top

Speed of Execution

One issue as mentioned above, which still plagues the final version of our project is slow button response. Code executes at the time of a button press, to preserve its integrity the system needs to wait until that code is finished executing before another button press can be recognized. While the potential user frustration associated with this delay is minimized by signaling when a button press will be accepted, the delay is still sometimes very noticeable to the user.

Another slight issue that we discovered was that of displaying information. Because of how the 7 segment displays work, we need to sweep through each segment we wish to light up, meaning we need to continuously update the display. The LCD code takes some extra time to execute, and while it is doing this, nothing else can run, which causes a slight flicker in the 7 segment display whenever we update the LCD screen. This could have been fixed by placing the seven segment code in an interrupt to always be updating the display, but this slight flicker is not an inconvenience to use and is more of a small annoyance to some.

Accuracy

Our dispenser works moderately well, considering the difficulties in construction and automation. Skittles are not quite perfect spheres, which doesn’t seem like a huge problem at first, but gave us some serious issues with things like only dispensing one skittle at a time and also registering a score in the score basket. Overall, the dispenser succeeds at dispensing exactly 1 skittle approximately 70% of the time, dispenses 2 about 15% of the time, and dispenses none the remaining 15% of the time.

Our scoring system based in IR transmitters and receivers is very consistent. We had problems due to the non-spherical shape of the candy where sometimes it would enter the score basket sideways and not register a score. Eventually we created an enclosed square tunnel such that the skittle would always activate the basket. As long as all our electronics stay cool, everything works very well. As our voltage regulator heats up, however, the bottom basket starts to fail due to performance degradation of the voltage regulator. This might be due to a variety of factors, but we could have fixed this by running more pieces of the project requiring 5V power off of the 5 V rail on the power supply instead of from the voltage regulator.

Safety

Luckily, this system is not incredibly inherently dangerous. The skittles can get moving to pretty high speeds, but not death-inducing ones. Skittles are light and break upon impact, which further decreases their danger level. Had we been working with the full speeds and metal balls of a regular pachinko machine, we would have had to be far more cautious about our work.

The design of the system requires everything to be behind glass. This adds a layer of safety to the project, as the skittles and all moving parts are sealed off from the user, preventing them from getting injured on these parts.

Interference with other's Designs

Our project is self-contained and should not have created interference with other designs as nothing was high power and we were not using any sort of wireless transmission. It is possible that if a group was using IR for their project and they stuck it right next to the glass near our score baskets, that there could be cross-interference, but our emitters and sensors have very narrow cones of sensing and emission so even this is quite unlikely.

Useability

Anyone that can operate buttons can operate this machine. It is all controlled by our button panel. Perhaps we could have made it more accommodating to those with special needs, but for the vast majority of the target audience, they will be able to control the system without any trouble.