Yeah, bumper time. To be precise: pop bumper time. Here are the parts we have to assemble.
Worth to mention that the coil in the picture is an AC coil without diode and I soldered the diode myself to make it work in my DC voltage environment. And this is how it should work: a pop bumper kicks the ball when a ball hits the bumper plastic skirt. The plastic skirt triggers the switch which gives the impulse to fire up the coil. The coil pulls down the rod and ring assembly to accelerate the ball. Easy as eating cake. I started with mounting the coil:
I used the bumper base for marking all holes and mounted the coil first with only one screw to make sure that all movable parts have enough space. Mounting pop bumper requires lots of drilling BTW. In the next step we place the skirt and fix the rod and ring assembly.
Screwing the bumper body and fixing all parts comes next. It is a bit tricky to stick the lamp pins through the tiny holes but who cares.
To make it look like a real bumper the last visible step is to add the cap.
The real tricky part is to make the bumper work in the way that the skirt does not get caught but activates the switch. In my case I replaced the original switch bracket with a piece of wood strip. I had to try several wood strips in different thickness to make it work. Try and error is the motto. Because I’m using a Raspberry Pi for the switch input testing was easy. I made sure that the bumper switch worked correctly before I wired the coils and relays. I also developed the logic and dry tested some „hiccups“ to avoid burning the coil in advance by adding some special cool downs. Will play around and maybe adjust some timers though. And finally here is a current picture of the play field:
My pinball source code incl. all bumper specifics is available on Github as always, if you are interested. What I recognized while playing the current state is that I get sometimes a short but noticeable delay which results in weak flipper finger strength. As I’m using a Raspberry Pi 2 with multiple cores I introduces multiprocessor support for the sound module. Did not help as much as I thought so this issue is definitively something I need to address as the fun part depends a lot on precision. One solution to address this delays could be to introduce tmpfs and put all sounds into memory to avoid I/O wait conditions. So there is enough stuff on my to-do list. Get excited and have fun.
Building your own pinball machine is not only huge fun. For me it’s learning and experimenting. One can become extremely creative. A good example was today’s „building a spinner mounting support“. The spinner is an original part of a real pinball machine. I got it second hand from a pinball shop. My mission today was to mount it above the lane, add a micro switch and develop the logic around light, sound and scoring. With just a couple of brackets, a metal rail, screws, nuts, washers and a standard micro switch I’m really proud of the result:
And best of all: it works. Which is quite cool as the whole project becomes really complex as everyone can see by just looking at the current state of my wiring:
It looks really confusing and this is only the tip of the iceberg. But I have a fool-proof system that works for me. First of all I‘ using a text file with all GPIO pin configurations. Next: all GPIO outgoing cables are tied to a well defined luster terminal input which is also documented. The text file also describes details which relay must be used. And most of the time I also label the wires. Most of the time means I tend to not label the wires until I lose the track 🙂
Adding light and sound effects is a huge difference when building a pinball machine. Even if I have currently only 3 triggers and two lights its quite fun to play around with the current state. I added a small effect class to the project to play any sounds one after another and to define simple light effects. This means blinking all around and because of a small random routine there is always some blink-blink action. Yeah, major improvement in terms of atmosphere.
The right flipper finger is not as strong as the left one and I’ve no idea why. Same resistors, resistance and pieces all around but noticeably weaker. Maybe something mechanically, will go ahead and ignore it for now. The next step is to define the places for more elements and the visual interface.
The source code is available if you are interested. I really enjoy Python as it makes stuff so much easier. I should add a video as just text or static images can’t express how cool this is. Stay tuned ‚till the next milestone and have fun.
Beginning of the year we replaced the bed of my daughter. First we wanted to give it away but nobody picked it up. In the same time I wanted to start a Raspberry Pi 2 project. One aim was to use the GPIO capabilities. After having the bed standing around several weeks the idea grow to build my own pinball machine where all logic is done by the Raspberry Pi 2. I don’t think that such a project would be possible several years ago but today you get the parts and pieces together without leaving the house. Great times,right. Here is a picture of the foundation:
With your power of imagination you see a pinball machine within this bed. No? Ok, let’s fast forward some days and have another look.
Yeah, there it is. A rough draft. You can see the already mounted shooter assembly and the shooter alley. The slingshot and the flipper finger placement was defined in this stage mostly intuitive. The board is a „multiplex board“ or in German: „Siebdruckplatte“. The most important attribute of these boards for this project is that they don’t bend. My board is 230mm thick if you are curious. At this time I read a lot about flipper coils, power supplies and pinball machines in general as this field was completely new for me. One of the most confusion topics was the wiring of the flipper coils and more specific: the EOS switch. You can find many information around a normally closed (NC) EOS switch or a normal open (NO) one. As I’m tend to test stuff out I ordered all pieces of a flipper assembly and started to play around with it. Here are the pieces for my testing. Test bed becomes a complete new meaning in this project.
As you see, the EOS switch I got is an normally open (NO) one. After more research the picture was clear. Around the early ’90 was a technology switch from NC to NO EOS switches. The good news for me was that the technology switch was because control boards were introduced. As I want the logic within the Raspberry Pi this was exactly the stuff I needed. This means the EOS switch is connected to a GPIO input pin and the logic triggers a GPIO out pin which switches a relay to control the flipper coils. So we have already three different circuits and voltages. GPIO runs on 3,3 volt, the relay needs 5 volt and the flipper coil need high voltage. High voltage in my case means 36 volts and up to 5 amps. Some words to the flipper coils: A flipper coil has two different turns which have a different purpose. The first coil (HIGH) has just a few turns and almost no resistance. This coil kicks the flipper finger and the ball hard. The other coil (HOLD) has far more turns and a higher resistance. Purpose is to hold the flipper finger up when the flipper button is pressed a longer period of time. The issue with the HIGH coil is that it is nearly a short-circuit and draws a huge amount of current. I burned a relay in the process because my relays can only handle 5 amps and I started with 0.5 seconds HIGH. At the moment the HIGH coil is only energized 0.04 seconds and works just great. This said playing with flipper coils is serious business and we need resistors for protection ;). Here a picture of my first wiring prototype and processing the input with the Raspberry Pi:
Today was a good day as I finished the basic flipper logic, have a quite amount of wiring done and can control two different lights with the Raspberry Pi. Neat!
Now comes the part to place more components like bumpers and targets and to develop the first counter/light logic. Whenever I hit the next milestone I will post again. The code will be published on GitHub within the next days. Have fun!
I have to reset an USB device on my Pi and found this extremely helpful little program. It is a bit ugly to find the relation between the device and the bus/device number. There are some hints on the internet like this one:
udevadm info --name=/dev/ttyUSB0 --attribute-walk
I found an easier solution and as I run a cron job to reset the device I wrote a little script that gets the bus/device number and calls usbreset:
result=`lsusb | grep "Prolific Technology, Inc. PL2303 Serial Port"`
tokens=( $result )
command="sudo /home/pi/usbreset /dev/bus/usb/$busnum/$devnum"
I can’t really say that I’ve finished the project but it’s pretty far. The new UI is responsive, completely developed from a mobile first approach and looks nice on a smartphone, a tablet and with a normal desktop browser.
In addition I spent a lot of time to make everything flexible. This includes not only i18n (most of the UI is available in German, English and Spanish) but also 90% of the information and options are based on config files.
The system is actually a visualization/control system for a home automation bus system. Spent quite some time on points like security, ease of use and simplicity. And a bit on modularization but I guess this area needs some more refinement.
Some labels will be renamed in the near future. The section „Switches“ for example includes currently „Levels“. What it really does is to create and visualize/control any kind/amount of areas, such as floors, garden or single rooms. And then everything which is related to this area can be viewed and controlled, such as lights, sockets, thermostats, valves, … It’s technically possible to add the shutters to the „Levels“, but currently it feels more natural to put them in an own section. Time will tell if this should be changed.
The only completely custom module is the „Device“ section. In this section the system is able to show any kind of device that is currently „on“ – means, the system can ping it. This section includes smartphones, tablets, notebooks, PCs, TVs and stuff like a Wii (not my XBox as the Xbox prevents a ping). This means that the system is somehow context aware. I have some hopes that the system can become really smart. Because it is most likely that somebody is at home if the TV is on. Or a laptop. Or a smartphone. Let’s see how this can be used. Best is that this information are available nearly for free and without beacons or any kind of unnatural manual registration.
So what’s next? I still want a always on speech control. And more sensors. But I think first comes some fine tuning and enhancements all around 🙂
My holiday project is an upgrade of my smart home project. New hardware from Raspberry Pi B to Raspberry Pi B+. In addition the software and the services will become a complete overhaul.
My Raspberry Pi B with my DIY home control worked nearly one year 24/7 and gave us a tremendous user experience and fun from any device even remotely. Features so far:
- Lightning control
- Shutter control
- Access to security cams
- Environment information
- Voice control
This said, the new system will be customizable and administrable. The UI gets a responsive design for better tablet support. On top of this I have some nifty ideas for a even better user experience. Will post results and screenshots when I’m satisfied.
Happy holidays everybody!
One real annoying issue working with a Raspberry Pi over Wifi is that the Wifi dongle goes into power saving mode. Thus the ssh connections lags or a connect isn’t even possible. But we can solve that. First we have to check that you have a specific USB dongle by executing the following command:
dmesg | grep rtl8192cu
If you see something like „usbcore: registered new interface driver rtl8192cu“ as result, we can solve the issue. Edit the following file:
sudo nano /etc/modprobe.d/8192cu.conf
and add the following:
# Disable power saving
options 8192cu rtw_power_mgnt=0
Now reboot and enjoy your stable Wifi connection without interrupts.
Since quite a few weeks I only charge my smartphone powered by solar power. I’m a bit skeptical that it works for the 51° latitude in the middle of Europe across autumn and winter. Until now it all worked fine even if the charge process took a while.
I’m using a power pack that can power and simultaneously charge. To start the charging process you have to push a button. As soon as the device is fully charged the power pack shuts down automatically. My real goal is to power a Raspberry Pi independent from the power grid outside 24/7/365. At the current stage I just analyze the output from the solar panel under different conditions. The test phase will continue over the winter month until the second quarter of 2015. With the current knowledge, I can’t use any of the components as the solar panel is not powerful enough and the power pack requires manual interaction. The good news is there are there are plenty of solutions available, like the one from Adafruit.
Here it is. A Banana Pi running an Open-Xchange AppSuite on a 8 GB SD card.
As the Raspberry Pi does not support ARMv7 I had to use the Banana Pi instead. Not too bad as this device is more powerful and better to run a Java backend, a MySQL database and the Apache web server. For mail I’m using an existing mail account in the cloud.
Installation was pretty much straight forward using the existing Open-Xchange quickinstall script. The only thing to mention is that the script is available with git and not with svn:
git clone https://git.open-xchange.com/git/wd/testing/quickinstall -b master
You have to make a few modifications as officially only 32-bit systems are supported. This means the OS architecture check and all office related repositories must be commented out.