Simple Basement Storage Platform

I was at the Milwaukee Makerspace for the last time this year and possibly for the next few months.  Tonight, I spent my time making some simple basement storage platforms in the woodshop.  Altogether, I made four platforms.  The materials needed was:

• Two (2) eight foot long 2x6 boards
• Two (2) two foot by four foot, 1/8 inch thick sheets of hardboard
• A handful of nails

The Makerspace has several great woodcutting tools that made the job go very quickly.  In about an hour, I had four pretty nice looking platforms.  The plan is to give them to a friend of ours from our weekly Bible Study group.

Merry Christmas!

Injection Molding Machine Simulator

For the last month or so, I have been spending my weekly Makerspace time working on simulating an injection molding machine on a microprocessor.  This is a project for work.  I want to setup a test environment to work with Mattec, our MES software used to control injection molding machines in our plastic parts plants.  To make a proper test system, I would like to send signals from a simulated injection molding machine into the system.

Beaglebone Black Fail
I first started working with a Beaglebone Black.  I was able to write a simple python program to turn LEDs on an off at random times.  However, that program only worked once.  After the first time, I could not get it to work.  Not sure what went wrong.  I may have fried the BBB somehow.  It still boots, I can connect to it.  I can execute BoneScript code.  I just can't get any python code to work.

At some point, (may have been before I tried the python code but also certainly after) I tried to upgrade the OS on the BBB to the latest version of Debian dates 2015-03-01.  I followed the same instructions from the last time I did this.  I did not get any errors creating the SD card.  When I bootup the BBB in install mode, the lights start flashing.  All three LEDs are supposed to light solid when the install is done.  However, this never happens.  I've tried several times with no success.

Raspberry Pi and Basic Simulation Definition
So, I moved on to the Raspberry Pi.  I wrote a program to randomly turn LEDs on an off.  If I ever actually get to use this on my test system, rather then turning on the LEDs, the Pi will send an electrical signal to an interface unit.  There will be a signal to say that the fill process is complete, one to say a cycle is complete, and one to indicate that the last piece produced was scrap.

Classes
A part of functionfunctionfunctionthe process, I learned how to use a Class to store data.  I wish I would have learned about this earlier.  I love using arrays in other languages.  There is nothing really like an array in Python.  However, a class is even better than an array.  I made a class that represents a molding machine with sub-classes for the sensors on the machine.  If I want to access the cycle time for the machine, I simply access the data at IMM10.Cycle.AvgTime.  Very cool!

Down Event Probability Using a Poisson Distribution
The machine class has a function that will calculate the probability that a machine will go down during a given cycle.  It uses the poisson distribution function to determine this.  Just input the average number of cycles per month and the average number of down events that machine per month.  The poisson distribution function uses these numbers to determine the probability.  Excellent!

General Python Program Functionality
Multiple machines can be defined with different fill rates, cycle times, scrap probabilities, and down probabilities.  The program continuously simulates cycles for each machine.  It will send a signal when the fill part ends, then another signal when the complete cycle ends.  Next, it decides if the machine functionfunctionproduced scrap during that cycle.  If so, it sends that signal.  Finally, it determines if the machine when down at the end of the cycle.  If so, it sets a timer and waits for the down event to end before resetting the fill and cycle timers.

Determining Times Randomly Using a Normal Distribution and scipy
The time for the fill and cycle are randomly determined based on the average times for that machine. The probability calculation is not a simply random number generator.  It gets a random time that is within one standard deviation of the average, assuming that the probability has a normal distribution.  This is better than a purely random number between the minimum and maximum range.  The probability could be outside of that range but should be normally close to the average.  In a future release, I'd like to add in some kind of randomality to generate outliers.

In order to generate this kind of random number, I had to install a Python library called scipy (www.scipy.org). That library has a function called "percent point function" that will compute the inverse of the cumulative distribution function of a standard normal distribution.

I'm not exactly how the function works, but if I send it a random number between 0 and 1, and tell it to use a mean of 40 and 3 standard deviations, its sends back numbers that appear to be distributed around 40.

Here is one helpful link that explains more about using scipy in this way:

http://stackoverflow.com/questions/20626994/how-to-calculate-the-inverse-of-the-normal-cumulative-distribution-function-in-p

scipy can be installed on the Raspberry Pi simply by typing  

sudo apt-get install python-scipy

Future Enhancements

For now, when a machine goes down, the duration of the down event is a purely random number between 5 seconds and 4 hours.  In reality, most down time events last less than five minutes, but some can last for days or weeks.  I'd like to have a formula that will mostly pick down event durations that are short but could pick longer ones.  I can't figure that out just yet.

Another future enhancement would be read in machine and sensor definitions from a text file or some other source.  It would be cool if the source data could be managed with a web page.  Then, I could control the parameters of the device remotely.

Also, the Raspberry Pi outputs about 3 volts.  If I need to generate more volts or a higher current, I might have to make a circuit board with transistors.

This brings us up to date.  I'll add more about generating random downtime durations later.

FBI Exit Problem Fixed

I finished the first prototype for the MMS Photo-inator Xsi a few months back.  It will take a picture when someone presses the button.  Then, it displays the picture on the screen for a few seconds.  Next, it flashes the lights on the green and red buttons and waits for the person to press one.  If the person presses the red button, the program deletes the picture and resets.  If the person presses the green button, the program keeps the picture and resets.

One thing that I need the Photo-inator to do is stop displaying the picture if the person presses either the red or green button.  I have not been able to figure that out, until now.  

I tried sending a keystroke to the session but that did not work.  I also tried killing the process but that did not work.  I tried other software and solutions but could not find one.  I spent the last few months trying to figure this out.  It has been extremely frustrating.  Here is how I finally resolved the problem.

I heard that the uinput module for python will allow me to send keystrokes to a session.  I downloaded the source code from here: https://pypi.python.org/pypi/python-uinput

Before I could install the source code, I had to install a supporting program by typing

sudo apt-get install libudev.so

Next, I installed the source code by running

sudo python setup.py buildsudo python setup.py install

I could not get fbi to work in the python program.  Tried it from the terminal and it will not work either.  I keep getting an error message that says, "ioctl VT_GETSTATE: Inappropriate ioctl for device (not a linux console?)"

Used Ctrl-Alt-F1 to switch to tty1 .  Executing fbi on tty1 works perfectly.

If I have the python program execute this: "fbi -a -T 1 -t 1 BBB.jpeg", fbi will display the image.  The -T 1 tells fbi to display the program on tty1.  I need to specify this on my PC but it apparently did that by default when I ran the program on the Raspberry Pi. 

Next, I wrote a small python program to display a picture with fbi, wait a few seconds, then send a q to the uinput subsystem on Linux to simulate a user pressing the letter q.  This worked perfectly.

The test code looked like this:

#!/usr/bin/python
import subprocessimport psutilimport timeimport uinput

subprocess.call("fbi -a -T 1 -1 /home/ken/Pictures/BBB.jpeg", shell=True)time.sleep(3)

#Uinput testsevents = (    uinput.KEY_Q,    uinput.KEY_H,    uinput.KEY_L,    uinput.KEY_O,    )

device = uinput.Device(events)time.sleep(1)
device.emit_click(uinput.KEY_Q)

Finally, I modified the photo-inator program to use the uinput code.  I need to fire up the whole system to test it out.  I'll do that some other day.

I want to display a picture on the screen for at most 30 seconds.  If the user presses a button, the picture should no longer be displayed and the program should move on to the next step.

There are several options to do this.

1. Display a picture in a gui user interface like xwindows
2. Display the picture on a smaller monitor but use an LED screen as the user interface.
3. Display a picture as part of another document from the command prompt
4. Display a picture from the command prompt

I played around with some of the options.  Here are my notes from working on this.  They are not well organized.

Display a picture as part of another document from the command prompt

PDF

Need to make a PDF file.

Display a PDF file.

Close the PDF file on demand.

The Python Imaging Library or PIL might work.  It will display an image but it looks like it uses the computer's default image display program.  Might only work in windows.

Display a picture from the command prompt.

Some people said you could use fbi in another tty session.  fbi does have an option -T to display the image in a different tty.  That does work but it enters the commands at the current prompt on that session.

I can use fbi -t 5 -1 -a -T 2 <image.jpg> to display an image on the second tty and then exit.

Starting the fbi process does not make fbi the "session leader".  The shell is the session leader.  fbi is the process group leader for a process group containing only itself.  See this page for more details.

I started the fbi process on tty1. Then, went to tty2 and killed the process in tty1.  That worked.

I started the fbi process on tty1.  Then, killed it from a ssh session on my laptop.  That worked.  So, if I can just find the session number of the fbi session, I should be able to kill it.

Tried running this command to kill the fbi session:

ps axf | grep <process name> | grep -v grep | awk '{print "kill -9 " $1}' | sh

It locked up the tty sessions.  I could still access the pi using ssh but not with the keyboard.  Had to cycle power on the pi.

After rebooting, did the same thing several more times.  It worked every time.  Not sure what this means.

The psutil code has a function that will get a list of all the processes and put them in a dictionary.  I can use that function to find the process running fbi.  However, fbi just seems to mess up the process when it is kicked off from python.

Tried eog.  It only works with x windows.  Same with evince.

It looks like PDF files can only be viewed in x windows.

Maybe the tty idea will work without killing the process.  The idea would be to display the image in tty2 but switch back to tty1 when the user presses a button.

Googling this topic makes it look too complicated.

MMS Photo-inator Xsi Initial Prototype Worked

The next phase of the MMS Photo-inator project was to complete the prototype.  I spent the afternoon and evening of July 3 working on the prototype.

First, I had to desolder a few more 2N6045 NPN transistors from the board I found on the hack rack at the Milwaukee Makerspace.  I needed two more transistors but I removed four just to have some spares.  I broke one of the feet off by wiggling it too much.  Putting the electrical plug under the board gave me the leverage I needed to pull the transistors off the board after the solder was removed.

The trick to removing soldered components from a circuit board is to, first, use flux to better transfer the heat to the board.  The second tip is to use copper desoldering braid to remove solder from the pins.  After removing the solder, the transistors come off pretty easily with a little force.

The next step was to add some small strips of wood to the board that the buttons were mounted to so it would stand up on its own.  I found some extra strips of wood at the Makerspace and attached them to the plywood.

Now that the board is ready, I needed to wire the connections.  Since I want to be able to assemble and disassemble the prototype easily, I decided to use terminal strips.  I attached three terminal strips to the board.  One would be used for the 12v power coming from the power supply to each light.  One strip would be used mainly to complete the 12v circuit to the collector on the transistors.  I also used one connection on that strip to connect the negative wire on the PSU to common ground.  The final strip would be used to connect the switches to the Raspberry Pi -- three sets of connectors for power in, and three sets for power out when a button was pushed.  I used either u-shaped or blade connectors on the ends of the wires to make it easier to connect the wires to the strips, switches, and lights.

After all the wiring on the prototype was done, I made ten connector wires to connect the prototype board to the breadboard for the Pi.  There are four terminal blocks on the breadboard to accept the connector wires.  One block is for the wires that send 3.3v from the Pi to the buttons.  One block is for the wires that receive the 3.3v back from the buttons.  A third block connects the lights to the transistors, completing the circuit.  The final block connects the ground wire from the PSU to the ground on the Pi.  Finally, I had to wire up all of the connections from the Pi GPIO pins to the various parts on the breadboard.  Here is the schematic.  It is also on SchemeIt at this link: http://www.digikey.com/schemeit/#1reo.

The final prototype worked exactly as I hoped.  The lights lit up and were bright.  The Pi recognized that the buttons were being pushed.  And, best of all, the Pi did not get fried.

Next, I need to work on the Python code and get all of the features working.

Building an NPN Transistor Switch Circuit

Introduction
The next step in the MMS Photo-inator project is to design a circuit to switch the light bulbs in the buttons on an off using transistors.  The Raspberry Pi 2 can't provide enough power to make the lights bright enough but it can control electronic switches that allow a higher powered power source to turn the lights on.

Using transistors turned out to be very difficult to me.  The concept of a transistor is pretty simple but actually getting a circuit working is not.  I burned out several transistors trying different things.  I have also read various sources to learn more about transistors but it does not seem to help.  Last weekend, Royce from the Milwaukee Makerspace helped me build a circuit that worked.  I'll try to document what I learned for my own edification.

Learn About Transistors (good luck)
Here are some links to learn more about how to use NPN transistors as a switch:

• https://learn.sparkfun.com/tutorials/transistors
• http://www.dummies.com/how-to/content/electronics-components-use-a-transistor-as-a-switc.html
• https://www.techhouse.org/~dmorris/projects/tutorials/transistor.switches.pdf

Transistorized Switching Circuit
The objective is to turn three individual light bulbs on and off from my Raspberry Pi using transistors.  The basic circuit is shown below.  Note that everything, 12v PSU, RPi, and lights share the same ground.  This is important.

Transistors will be used as electronic switches to allow current from the 12v, 1.8A power supply to flow through the light bulbs.  The Pi will send a 3.3v signal to the base pin on the transistor.  This is the signal that tells the transistor to turn on the light bulb.

According to this site, the Raspberry Pi can safely put out a maximum of 16 mA per GPIO pin and a total of 50 mA on all GPIO pins.  So, I have to be careful and limit the current from the Raspberry Pi to the base of the transistor to 16mA per transistor.

Transistor Specifications
The first thing to do was to determine the characteristics of the transistor my project needed.  This site was helpful to determine what transistor to use.

The transistor has to handle the output from the power supply I will use -- 12v and 1.8A (max) -- to power the lights.  Even though the lights only draw 0.25A, the PSU can put out 1.8A.  I think it is possible for the transistor to draw the full current in some circumstances so I need a transistor that can handle the maximum current from the PSU.   The parameter for current is called Ic(max) on the datasheets.  The parameter for voltage is called VCEO (max).  When I look at the datasheet for a transistor, it has to have characteristics that fall within these two specifications.

Finally, the amount of current that the base needs must be <= 16mA.  This parameter is called IB.  To determine the IB parameter, you have to find the formula on the datasheet.  It is usually something like IC = X * IB.  Basically, divide the current for the load by X to find the current to send to the base.  In my case, the load current is 1.8A maximum.  If, for example, a particular transistor has a formula of IC = 100IB, IB would be equal to 1.8A / 100 or 18mA.

Finding a Transistor
Next, I had to find a transistor that meets the specifications.  The Milwaukee Makerspace has several NPN transistors in bulk.  I looked up the specifications for each one on the http://www.datasheets360.com/ website.  Unfortunately, none of the NPN transistors on-hand matched the requirements.  It seemed like I was going to have to buy a MOSFET transistor like this one on SparkFun.  On a hunch, I looked through the hack rack at the 'space for any parts that may have transistors and found a circuit board that had sixteen 2N6045 NPN transistors.  According to the datasheet, these transistors have an IC (max) of 10A, and a VCEO (max) of 100V.  Both of these are sufficient for this project.  The IB formula for this transistor is IC/100 or 18mA in my case.  This is just a bit higher than the Pi would like but, the load should not draw that many amperes.  The nominal current that the lights will draw is 0.25A.  This means that the base current needs to be 2.5mA under normal load--well within the Pi's capacity.  Finding the circuit board was an unexpected blessing.  Thanks, Big Guy.

I was able to remove a couple of transistors from the circuit board using a soldering iron.

Resistor for the Base
Its important to prevent the transistor from pulling too much current from the Pi and damaging it.  The Pi can be protected from this by placing a resistor between the Pi and the base pin.  Determining the size resistor that is needed was a bit complicated.

First, we made a circuit with one resistor and one 12v lamp.  A regulated power supply was used to determine the minimum current that would turn on the 2N6045 transistor.  To find the exact current level that the circuit was pulling, I unplugged the positive cable from the PSU, connected the red cable from the multimeter to the positive out on the PSU, then, connected the black lead on the multimeter to the circuit.  The minimum current required to activate the transistor turned out to be 8mA.  Finally, using a multimeter to measure the volts from the base to the emitter while the light bulb was on, showed that the PSU was supplying about 1.4v at this current level.

This means that the voltage from the pin on the Pi needs to be lowered from 3.3v to 1.4v at 10mA (rounded up from 8 just to be safe).  The resistor has to remove 3.3-1.4 or 1.9 volts.  Using Ohm's law to calculate the resistance works like this:

R = V/I or
R = 1.9/0.01A or
R = 190 ohms.

Putting a 190 ohm resistor between the Pi GPIO pins and the base pins of the transistors should keep the Pi safe from pushing out too much current, while providing enough volts to activate the transistor.

I put a 180 ohm resistor (the 'space had a 180 or 220 ohm but no 190) in the circuit and connected the Pi's 3.3v output pin to the base.  The light turned on!

That was a lot of work and very frustrating at times.  I would have never made it this far without Royce.  That is what is so great about the Milwaukee Makerspace.  There is usually someone around who can help you through the rough spots.

Next, I need to remove some more resistors from the board and build a prototype of the complete MMS Photo-inator project.

MMS Photo-inator Xsi -- 22-25 May session

While at the Milwaukee Makerspace for my weekly Maker-time, I continued working on my idea to use a Raspberry Pi 2 Model B to make a device that will take pictures by controlling an SLR camera. This time, I found some software to display an image, made a prototype with hardware, and wrote most of the python code.

Installed Avahi on the pi so I can connect to the Pi over a network.  This allows me to do coding on my Linux laptop and FTP the files to the Pi.  If something happens to the Pi, I won't lose the code.  The instructions to install Avahi are here.  Changed the name of the device to photoinator in both the /etc/hostname and /etc/hosts files.

I kicked around ideas for a human to interact with the photo-inator.  One of my fellow Makers suggested doing everything in web pages.  That would probably make everything easy including printing the picture but it wouldn't make much use of the Perma-Proto Pi Hat from Adafruit.  I'd like to have the user interact with the photo-inate by pressing buttons and seeing flashing lights.

Also, I would like to display a preview of the picture and let the user decide if it is good enough to keep or not.  How do I get the Pi to display a jpg file without using xwindows?

First, I tried an application called feh to display images.  This web page has the instructions for installing feh: http://feh.finalrewind.org/

After messing around with feh, I realized that it only works from within xwindows.  That does not help -- especially since gphoto2 only runs from the command line and will not work in a terminal session running in xwindows.

The application that I needed is called fbi.  I installed the app using sudo apt-get install fbi.  After that, it just worked.  I ran the program in the directory that has the photos in it.  The way to run fbi is fbi image.jpg -a -t 10 -1.  The -a will auto re-size the image to fit the screen.  -t 10 tells fbi to display the image for 10 seconds.  -1 means that fbi should exit after the timeout.

Next, I wrote a quick shell program to take a picture with gphoto2 then display it with fbi.  I pass the filename to save the picture to as a parameter.  The shell file looks like this:

gphoto2 --capture-image-and-download --filename=$1.jpgfbi $1.jpg -a -t 10 -1

The $1 lets me pass in a file name on the command line.

Next, I used a python program that I found on this Instructable and modified it a bit to control a button and an LED on the Adafruit T-cobbler Plus proto board.  It worked.  I was able to press a button to start the process.  The program flashed an LED, took a picture, and displayed it on the screen for 10 seconds.  Nice.

I spent a good part of the day on Sunday (after church of course) writing a much more robust Python program with subroutines and global variables and all of that nerdy goodness.  

Finally, I spent Memorial Day back at the Makerspace to build the prototype and debug the code.  The prototype has three buttons and four LEDs.  One button is to start the picture-taking process.  Another will let the human choose to Keep the picture they just saw.  The third button will tell the Pi to reset everything and start over.  One of the LEDs will light when the picture-inator is ready to take a picture.  The second LED will blink increasingly fast to warn the user that the picture is about to be taken.  The final two LEDs blink alternately next to the Keep and Reset buttons to encourate the human to push one.  This all works fine.  For the final version, I would like to use small light bulbs instead of LEDs to increase the brightness.  I probably need a stronger power source than the PI to light them.  I will also need a more complicated circuit that includes a transistor.  I'll design and build that in the next session.

Another idea I had was to add a toggle switch to designate the mode that the picture-inator is in -- one shot or continuous.  That should be pretty easy to do but I did not get to it this time.

One of the things I struggled with on the coding side was the GPIO.add_event_detect function.  I originally wanted the program to call a subroutine when a button was pressed.  However, I could not get that to work.  The subroutine might get called the first time the button was pressed but not after that.  Sometimes, pressing the button never did anything.  I ended up punting and doing several things to make this work.

First, the main loop uses GPIO.event_detected to see if any of the buttons were pressed.  Anytime a button is pressed or a state changes, the program turns off event detection for all buttons.  Then, it does whatever the function is meant to do, and turns on even detection for any buttons that need to have it.  Doing all of this should allow the program to always catch button presses and never have false-positives or multiple button presses.

One other problem is that I don't know how to interrupt the picture being displayed.  So, if the person pushes the Keep button while the picture is being displayed, nothing will happen.  I don't think I can fix that.  I spent a lot of time researching a way to call an external program in a separate thread but I'm not sure it is possible.

The bug I am currently working on has to do with debug mode.  When the program is running in debug mode everything works.  However, when I run the program with debug mode turned off, it turns on the ready LED but will not do anything when any button is pressed.  I have not been able to figure out why.

Another bug is if the camera is off, gphoto2 returns an error.  The program cannot handle the error.  Need to figure that out.

Here is a picture of the prototype at this point.

MMS Photo-inator Xsi -- 15 May 2015 Session

Even though I am posting this near the end of May, I am describing my efforts from 15 May 2015.

While at the Milwaukee Makerspace for my weekly Maker-time, I continued working on my idea to use a Raspberry Pi 2 Model B to make a device that will take pictures by controlling an SLR camera. 

Another New Camera

After posting my lackluster progress on the Makerspace Google Group, a Makerspace member named Matt

offered to let me use his Canon EOS Rebel Xsi DSLR camera.  Awesome!  It was waiting for me in my locker when I arrived at the 'space.  I tried using gphoto2 with the Canon.  gphoto2 detected the camera but I still had some issues.  I could not take pictures or basically do anything.

Did some searching on the internet.  One site said that the version of gphoto2 that gets installed with apt-get is not the correct version.  apt-get downloads version 2.4.14.  You need the latest version of both libgphoto and gphoto2.

First, I used sudo apt-get purge gphoto2 to remove the gphoto app.

Next, I did apt-get upgrade and update just because.

Next, I installed a bunch of libraries recommended by this website: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=70049

Next, I downloaded the latest versions of libgphoto2 and gphoto2 using wget.  For example, I typed in wget http://sourceforge.net/projects/gphoto/files/libgphoto/2.5.7/libgphoto2-2.5.7.tar.bz2

In order to unpack the files, I typed tar xjvf libgphoto2-2.5.7.tar.bz2.  A web page that talks about this is here: http://askubuntu.com/questions/25961/how-do-i-install-a-tar-gz-or-tar-bz2-file

After unpacking, I cded to the folder.  The INSTALL file has instructions about what to do next.

Step 1: ran ./configure --prefix=/usr/local.  The second time I simply ran ./configure

Step 2: ran make

Step 3: ran sudo make install

Get some error that the install failed.  It could not remove anything in /usr/local.  I rebooted and got messages about stuff not working.  Looks like the OS on the SD card got corrupted.  The pi will no longer boot.  Yar!

I had to start completely over.  Downloaded a program to format the SD card.  Then downloaded the NOOBs files and copied them to the SD card.  The full version of NOOBs would not copy to the card.  I had to copy the lite version to the card.  That version downloads the install files over the internet when the Pi boots up.  That worked.

Did all the setup stuff again.  Downloaded libgphoto again and went through the complete install.  This time, it worked.

Rebooted.

Downloaded the gphoto2 tar file from sourforge using the same wget command.  Used tar to unpack it.  Then, ran ./configure.  It failed saying "Cannot autodetect popt.h" 

This page (http://www.yannock.be/computer/compiling-gphoto2-on-the-raspberry-pi) lists other packages that need to be installed with gphoto2.  Installed all the packages it suggested:

1. libexif-dev
2. libpopt-dev
3. libfuse-dev
4. mono-devel
5. monodoc-base
6. libmono-2.0.1
7. mono-gmcs
8. python-pyrex

After installing all of this, I had to re-run ./configure.  This time it worked.  Ran make and make install.  It all worked.

Ran gphoto2.  It worked.  

The gphoto2 auto-detect sees the camera.  Was able to take a picture with gphoto2 and save it to the computer.  You have to specify a filename or it always uses the same one.

That's enough for this week.

MMS Photo-inator Xsi -- 8 May 2015 Session

Even though I am posting this near the end of May, I am describing my efforts from 8 May 2015.

While at the Milwaukee Makerspace for my weekly Maker-time, I continued working on my idea to use a Raspberry Pi 2 Model B to make a device that will take pictures by controlling an SLR camera. 

New Camera

I found a Canon PowerShot A540 camera sitting in a drawer in the 3D printer area at the 'space.  I hooked that up to the PI to see if I would fare any better with gphoto2.

Executed gphoto2 -auto-detect.  gphoto2 will only detect the camera if the power is on.  It says that capture is not supported by the driver.  This could be a problem if I want to save power by turning the camera off when the photo-inator is not in use.  The power button is a momentary switch.  So, it has to be pushed to turn the camera on or off.  This is not the ideal situation.

The batteries are low.  Need to find a 3.15v DC power source with a male plug if I want this camera to stay on indefinitely.

I did not have much luck playing with this camera compared to the Canon A470.  Ed from the Makerspace told me about software called CHDK.  CHDK is software that runs on a Canon camera.  It gives you a new user interface and more options.  This might be an option.

The software for the Canon A540 can be found here:  http://chdk.wikia.com/wiki/A540

Not much progress this week.

MMS Photo-inator Xsi -- 1 May 2015 Session

Even though I am posting this near the end of May, I am describing my efforts from 1 May 2015.

While at the Milwaukee Makerspace for my weekly Maker-time, I started working on my idea to use a Raspberry Pi 2 Model B to make a device that will take pictures by controlling an SLR camera.  I think I will call it the MMS Photo-inator Xsi.

Setting up the Pi

The Pi came with a micro SD card that was already formatted with Raspbian and ready to go.  So I did not have to mess around with that.

First of all, as always, I ran sudo apt-get upgrade and sudo apt-get update to make sure everything was up-to-date.

Changed the password for the pi user to wrenchiron.

The keyboard was setup for British English.  Used raspi-config to change it to US E

nglish.

Camera-controlling Software

The software that will control the camera is called gphoto2.  Installed gphoto2 by typing "sudo apt-get install gphoto2".  <note> It turns out that this was not the correct way to install gphoto2.  I document the correct way to install it in a future post. </note>

Typing gphoto2 --list-ports reveals two USB ports, usb:001,003

Connected a USB cable from the pi to my Canon PowerShot A470.  gphoto2 could not find it.  I tried 3/4 USB ports.  My keyboard was plugged into the fourth USB port.

I had to turn the control knob on the back of the camera to "playback" mode.  Then, gphoto2 could see it on the USB port.

Did gphoto2 --list-cameras.  It does not list the Canon PowerShot A470.  There is a 460 and a 480 but not a 470.

The gphoto2 --auto-detect lists the camera as "Canon PowerShot A740".  That camera is in the list.

Some of the commands I tried returned errors.  For example, 

• list-config: PTP I/O error
• capture-image: said "your camera does not support generic capture"

I think I need to find a different camera.

Raspberry Pi Based Photo Booth -- Introduction

The Milwaukee Makerspace got some new Raspberry Pi 2 computers to use in a build night.  We are supposed to make something cool with the Pi and the Adafruit Perma Proto Pi hat.  I'm going to try making a photo booth for new members at the Makerspace.

The main idea for this came from this website: http://www.instructables.com/id/Raspberry-Pi-photo-booth-controller/?ALLSTEPS

The main software for this will be gphoto2.  Here are the steps for how the solution will work.

1. Press start button.
2. Turn on camera.  
3. Display image from the camera on the screen.
4. If timeout, power down.
5. Push a button to take the picture.
6. Display picture and wait for response.
   1. Delete
   2. Continue
   3. Timeout
7. If delete or timeout, delete picture.
8. If continue, 
   1. Print picture
   2. Send picture to Makerspace web site
9. Return to step #3

Components needed

• Raspberry Pi with power supply
• Camera with usb interface
• Start button
• LED display
• Monitor
• Printer
• Internet connection

Alternatives

Have one big button that starts the process.  Turn on the camera.  Display a countdown.  Take a picture and use it.