Camera Controller
Last updated: Mt. Desert Island, 7 Aug 2010
 
Notions (as already mentioned in the introduction):
 
  a. Intervalometer
b. Trigger the shutter from sensors (e.g. a motion control sensor)
c. Remote control (iPod, web) including remotely viewing the image
 
Possible solutions:
 
 
The simplest configuration to implement Notions (a) and (c) would be just a cable from the iPod to the camera.  Apple has offered the iPod Camera Connector but it appears to be very limited in both functionality (the iPod is just a storage device) and supported devices (it doesn't include the iPod Touch for example).  But it would seem to indicate that a simple cable should work - "just a matter of programming".
 
 
The simple, cheap Arduino connected to the camera's shutter release input port would be an easy way to implement Notions (a) and (b).
 
 
This replaces the USB cable in (2) with a WiFi connection.  The Arduino again connects to the camera's shutter release input port to implement Notions (a) and (b).  A web application (HTML and Javascript) runs on the Safari browser on the iPod.  The app is retrieved over WiFi via the WiShield card from a webserver running on the Arduino Mega card.  The Arduino controls the camera shutter via the DSLR's shutter release cable.  The Arduino can field interupts from sensors (e.g. motion detection) to trigger the camera shutter.  The user interface includes the controls to enable these interupts.  Finally, the Arduino also monitors it's power supply, sending voltage readings (along with webserver statistics) to the user interface.  This is my first implementation.  See the details below.
 
 
To implement Notion (c) (and also get (a) & (b)), I'd need to hook the iPod up to the camera's USB port.  The Arduino add-on board to enable this is the USB Host Shield.  For the connection from the iPod to the Arduino, I'm hoping I'll be able to use a USB Hub.  TBD.  A wireless connection to the iPod isn't that important to me, so this is probably the best configuration.
 
 
The USB Host interface is also readily available on the Gumstix, so this would probably be the easiest to develop.  But a Gumstix would be considerable overkill here (not to mention very expensive).
 

Solution 2a

This is my first pass at implementing the goals (Notions (a) and (b)).  The video of this implementation is on the introduction page.

I am releasing this code under the Creative Commons Attribution-ShareAlike License.  It is released as-is without any waranty.  I'd like to say I'll respond to bug reports and suggestions for improvement, but the reality is that I travel a lot (being retired) and don't generally have my Arduino or DSLR with me.  [I'll add a link to the download page here]

At this time, there are a couple problems.  The first is that I haven't (yet) been able to get caching to work in the browser.  With a manifest file, my pages would successfuly cache (woo-hoo :-) with simple pages.  But when I added communications from the pages back to the webserver, the caching stopped working.  I'm guessing this is something basic that I'm doing wrong, but haven't figured it out yet.  I'll look at it again now that I'm back in the states and have access to my Arduino stuff.  Without caching, the webpage is refetched each time the user moves from page to page in the UI.  I'd guess the delays are less than 1 sec to render a simple page (Rem, Int), maybe 1 sec for a medium size page (Tgr, Adm) and several seconds for the graphic monitor (about 15K is fetched for the graphics library).  These should all be avoidable with page caching.  Not the end of the world as-is, but definitely could be improved.

The second area for improvement is end-to-end reliable deliver of the requests to the server.  Sometimes the request from the UI to the server doesn't get through.  This could be for whatever reason and is probably not uncommon in the initial pass of a distributed system.  I have tried to include (at least) confirmations that a command has been received by the server and acknowledged (e.g. when the Start button is pressed on the Intervalometer, and the server receives it, there is a response back to the browser that causes the text on the button to change to read, "Stop").  But IMO these communications would all need to be hardened and end-to-end retransmission added to make this a useful tool.  As it is, it's a bit of a toy.  You are welcome to try it and make improvements (feedback is welcome).  And I hope you can reuse ideas or parts of it in your project.

The code

The installation of the code is a bit tedious IF you want to include the features on the Admin page.  They're kind of neat features (monitoring the Arduino and webserver), but do take a little extra work.  [I'll add a link to the installation instructions here]

The User Interface code

The UI code resides in the folder, /ui.  It is HTML and Javascript.  Since the WiFi connection will be a little slow, I've tried to keep the number and size of the communication with the server small.  Makes sense, huh.

You should be able to see a demo of the UI using the directions and link here.  The demo is more interesting if you use an iPod or iPhone.  The UI consists of 4 main pages and a graphical monitor:

Focus invokes the camera prefocus (like pressing the shutter button ½ way).  Expose invokes the full shutter release.  The 3rd control (e.g. "1 sec" shown here) is the delay before the shutter is released.
On this page you can set the total number of images to take, the exposure time, and the interval between exposures.  Press the Start button to start (the button changes to say, Stop when the camera starts taking exposures).  The number of exposures taken and the total elapsed time are shown at the bottom.
On this page, you can set triggers to close the shutter.  For example, here if the sensor connected to the Arduino card pin 18 goes high and the sensor connected to pin 3 is low, the shutter is closed.  This is enabled by pressing the Arm button.
The Admin page shows the Vin on the Arduino board and the regulated breadboard voltage (Board).  Avail mem is measured by the Arduino code (ie. by my sketch).  Response time is measured by the Safari browser - it was the time it took to fetch the data from the WiShield server for this page.  The rest of the counts on this page are from the webserver internals.
This page is invoked by pressing the voltage displayed on the Admin page (e.g. the 8.63 volts in the sample above).  The page plots the Bytes/Sec In & Out to the webserver, the Response Time that the browser sees (in requesting this data from the webserver), and the Vin on the Arduino card.

The server side code

[To-do]

Modifications to the webserver

[To-do]

The graphics library used on the Arduino/webserver monitoring page

[To-do]

Hardware

[Photos and intro are a To-do]  Following are some notes regarding the hardware:

Arduino and WiShield

[To-do]

Shutter control

For the circuit between the Arduino and the camera shutter, I used the design found here.  It uses an optocoupler to isolate the Arduino card from the camera's shutter input.  I used two copies of the circuit - one connected from Arduino's pin 5 to the camera pre-focus input and one from pin 6 to the camera shutter release.  The circuit design also includes test LEDs (in place of operating the actual camera) which is handy for testing.  As well as reducing wear and tear on the cammera.  [More.. To-do]

Voltage divider to monitor the power supply and breadboard voltages

[To-do]

 
References:
 
  Arduino as iPod remote control
Arduino Intervalometer Basics
Arduino Flash library
gphoto.org - open-source code for interfacing to cameras
Gumstix Overo Meets Arduino
High speed photography
Using the USB Host Shield