Sunday, May 5, 2019

Pachinko and Arduino

This blog has been dead for a few years, but I might as well throw out a little report on a recent project.    I'll be bringing this to the 2019 Bay Area Maker Faire - say "hello" if you're there!

I picked up an early 70s Japanese pachinko machine, and had a lot of fun getting it back into good working order.   It's a Nishijin Super DX, the mechanism is called a Model A

First, I was lucky enough to find one used that was fully intact, aside from missing the front glass, which is pretty common.    A local glass shop cut the right size for me (1/8" thick, just measure the other dimensions carefully and allow for it to fit into the frame slots).  Then I spent a few evenings cleaning everything I could reach, with a few spots where I partially disassembled the back mechanism to reach tough areas.

With cleaning and lubrication it was back in working order, and I had fun playing with it and finding out it was a very generous machine that gave out more balls than one ever would in a real-world pachinko parlor. 

The original machine has a very simple set of circuits where a couple of switches would illuminate a light at the upper left and another behind the center jackpot target.   I decided to add a bunch of LEDs driven by an Arduino Pro Mini microcontroller.

I mapped out all the mechanisms and places I could add lights, then started a chain of wires and WS2812B lights cut from a strip.  Most spots use one LED, larger ones two and the center big prize mechanism has five.    Everything in held in place on back with heavy-duty plastic tape. 

The Arduino is fed with an external phone charger battery, the kind used to give your cell phone a power boost when you can't plug it in.

The first version of the program running the lights is very simple, and just runs a changing pattern of colors.   In the future, I'll hook up the two internal switches that indicate an empty ball supply or jackpot payouts, and make them blink accordingly.   In any case, I'm pretty happy with the results:

Monday, February 15, 2016

Saturday meeting

We got together on the 13th for a bit of chat and fiddling with our projects.

The yet-unnamed Water Tank Bot  (WTB?) took a big step forward with test mounting the body.   It has 3D printed custom brackets mounting the tank bottom to the supporting seat frame atop the wheelchair chassis.

The tank doors came out really nice using a very simple but smart build sequence.  First, the hinge line was cut in the tank.   Next, the piano hinges were mounted via pop rivets, and then the final cuts in the tank were made on the top, bottom and split center of the doors.   The doors swing easily and have perfect alignment.

Behind WTB? is the CopperBot, which recently had some detail work for better antenna mounts, less camera vibration, and securely mounting the RCA 833A tube.

The First Person View base station was rigged up on the bench for a demo and to measure power requirements.   With the receiver and 7" display, it's pulling 0.416 amps off a 12v SLA.   It will need a bit more power with a small audio amp and speaker.

Tuesday, February 2, 2016

Copperbot Moving Test

Here is a short video of the CopperBot driving around:

The speaker and FPV video camera servos are being exercised by the Raspberry Pi through their range of movement while it's driving under remote control.    While this may not appear exciting, two problems had to be solved to get here:

First, the Raspberry Pi would reset whenever the R/C started driving the bot around.   This was solved by adding some electrolytic capacitors on the power supply at the Arduino and servo boards.

Next, driving the bot was difficult to control, which turned out to be bad configuration of the Sabretooth controller.   Switching the mode to "independent" matched the R/C transmitter programming, and now it's much intuitive to control.

The Raspberry Pi also recorded compass, accelerator and gyro data while moving.   Later processing it in a spreadsheet, I was able to derive code that will give it good compass heading data.   The sensor suffered from a lot of vibration, however, so the frame needs reinforcing and the data will need smoothing to hopefully mitigate the shaky information.