Automating the Canon A570IS

Sam-Cam

It is now possible to automate many of the Canon Powershot cameras using a "temporary" firmware. You place this firmware on your SD memory card in the root directory and then the camera can load it and utilize its many new or expanded capabilities. This firmware can be automatically loaded and you can specify a script to automatically run once the camera has started. (see bottom of page for details on how to obtain he firmware)

At EOSS we're interested in being able to automate the camera to 1.) get ready for flight and 2.) control the camera during the flight. I downloaded one simple intervalometer script and modified it adding commands to set every feature I could think of in the camera's menu systems to work to the advantage of an airborne camera. Basically the script will:

First execute a reset.

There�s a �reset to default� on one of the camera's menus. By clicking on that and a script writer can be sure of the state of all settings.

After reset the script enters the menu system and:

Turns digital zoom off

Turns off red eye

Turns off MF-Point Zoom

Turns off MF-Safety

Turns off AF-Assist Light

Turns off image review (necessary if set to take really fast sequential photos)

Sets image stabilization to shoot only

Then it uses the hardware buttons and:

Sets the aperture to wide open

Sets the camera to MF (manual focus) and adjusts the focus to infinity

Sets the JPEG compression to superfine (minimal)

Finishes the setup by turning the display off

Once the camera settings have been finalized the camera starts taking photos. In this incarnation of the script it takes photos every 10 seconds for 30 minutes then backs off to taking one photo every 30 seconds returning to the every 10 seconds prior to touchdown.

About precise timing. NO WAY!

You tell the camera to execute a command and the timer is essentially suspended until this action has been carried out. Some commands may happen almost instantaneously, others not so fast. So, you have to take into account how long an action takes and sort of build that delay into your thinking when you write your script. For instance, suppose you want to take maximum resolution photos at minimal jpeg compression (superfine). You tell the camera to shoot every 10 seconds. Well, it takes time for the camera to shoot the photo, and compress the raw data into a JPEG file and then (most of the time) write the file to the SD card. Suppose that processing time takes 1 second. That means your first photo will be taken at zero time, your next photo will be taken at 11 seconds, your third 22 seconds, etc. Alternately you decide to take photos at the smallest size. The processing down to a JPEG image on your SD card will happen faster. So, don't expect to be able to get really precisely timed actions. Leave big time windows open to capture events programmatically and time out how long it takes your camera to execute a script and make mods based on those observations.

So, bottom line in the example above, if you want photos every 10 seconds set the delay between photos to 9 seconds not 10 to give the camera the needed 1 second to do it's job.

NOTE: Time how long the delays are for each action on your camera with your memory card and CHDK firmware installed and running. DO NOT ACCEPT my 1 second delay value above. Different cards write faster, different scripts on different cameras will execute at different speeds. This is definitely a process that needs to be tailored to each hardware/firmware setup.

Video of script executing

This is Version 1.0 NOT the current version of the script executing.

Here is the uBasic code. The video above is running V1.0 and minor changes have been introduced over the past several iterations.

Two big changes. The camera was tested and successfully managed to take over 1400 photos on a set of batteries so I changed the frequency of photos to take one every 10 seconds for the initial 30 minutes of script execution. This usually (well always so far) gets us lots of quick interval shots during launch and climb out from the launch site. The script then backs down to 1 photo per 30 to cover the ascent and burst. During descent the camera switches back into the 1 photo per 10 second mode to capture the landing. So far, this has worked really nicely (one flight :-). See the photos for yourself.

CHDK Firmware

We are currently using this firmware version:

You know, I've looked so I don't misidentify this but I can't find a single full text reference to what the abbreviation stands for. So, I'm dubbing it the "Canon Hardware Developer's Kit". What else could it be? Actually, UPDATE, I've heard it referred to repeatedly as "Canon Hacker Developer Kit" so that is probably the actual expanded abbreviation.

This is a group of folks who know their stuff and have programmed an alternate firmware for some of the Canon Digic II and III series cameras. You need to download the correct version for your camera. So far there have been no reports of bricking cameras. This firmware only loads off the card. It does not overwrite the firmware already installed on your camera. So, in a worst case scenario where your camera locks up, dump the batteries, reinstall them, remove the SD card and start the camera. You should be back to a factory condition.

Go to their Wiki pages. Read stuff, download stuff and write stuff and you'll be on the road to new and useful capabilities for your camera (assuming it's supported).

Problems and Testing

On our first flight the camera failed when it reached an altitude of approximately 43,000 ft. ASL. After the flight I obtained the camera and did some testing.

First test case, I ran our script from that first flight twice with one set of Energizer L91s (use by 2022). I always place the firmware on a 2GB Sandisk Ultra or Extreme SD card. That script takes 680 photos at 7.1 MP with minimum compression so that's a total of 1360 pictures. When I turned off the camera, removed the last batch of images, reinserted the card and then tried to start the camera the lens would only go halfway out and then the camera died. So, in normal room temperatures with new L91s I can easily get over a thousand pictures. I made time lapse movies. Nothing interesting happens but what the hey. YouTube mucks up the first few seconds of each video, not sure why. I didn't optimize them for YT, but those few seconds aren't worth the work of reprocessing the movies and re-uploading. FYI, The first movie has a scene change towards the beginning. I realized that the sun would be beating down on the camera probably causing lots of lens flare so I moved it back a bit to place it in the shadows.

First video, some horses move spritely in the neighbor's yard.

Second video (sunrise looking west you don�t see the sun just its effects)

Second test case, I replaced the batteries with a fresh pair (L91 use by 2022) and started the script up and placed the camera in the freezer at approximately -3 F. Again, the camera took the full 680 photos. This time it was a bit less informative as the freezer is kind of dark (totally) so who knows but ... I had forgotten exactly what time I had started this run and when I returned home I opened up the freezer door, brought the camera out and "SNAP" it took a photo. I quickly returned the camera to the freezer. Later when there was no doubt the script should have completed its run I opened up the freezer and removed the camera. I let it sit there for a little over a minute just to ensure that the script was not taking photos any longer and when no further snapping sounds were forthcoming, I shut down the camera, removed the card and found all 680 photos. The inadvertent opening of the freezer may have been slightly fortuitous in that upon examining all the photos I did find two pictures with exposed images. The first as I was placing the camera into the freezer and that one where I took it out slightly ahead of the end of the script. So ... the camera was apparently working just fine.

I made a time lapse movie of these stills too but really a single flash at the beginning and a single flash towards the end then unremittingly dark frames. Not worth the time uploading and fielding all the complaints from YT viewers.

I then reran the freezer test using the same batteries that were used for the first freezer test. In between tests I decided to change the script slightly to add more rapid capture towards the end of the flight in the hopes of getting a few photos of the final few hundred feet of descent. The new script takes 752 pictures. It ran to the end with the batteries that ran the initial 680 photo test. So that's a total of 1432 photos all taken below 0 deg. F.

I'm beginning to have a fair amount of faith in the camera. Over the past two days I've taken 2,792 pictures using two sets of L91s. The camera has not failed while running a script.

I'm thinking some strange anomaly not previously thought of must be the culprit for our failure on flight day. Everything is running so smoothly in the comfortable test environment that no errors are cropping up. Not really that surprising. Maybe a few cosmic rays got at the processor and it locked up. It did quit at 43K feet which is just below the max density for Cosmics "rays" and secondary partical radiation, I believe?

If I do discover anything strange in future flights and testing I'll post it here for everyone's perusal but as of now, I'm thinking this isn't going to be easily reproducible on the ground. We'll just have to fly again and see what happens.