Lake-bed scientific research photography - page 3 - General Help and Assistance on using CHDK stable releases - CHDK Forum

Lake-bed scientific research photography

  • 25 Replies
  • 11656 Views
*

Offline ahull

  • *****
  • 634
Re: Lake-bed scientific research photography
« Reply #20 on: 29 / August / 2013, 17:16:06 »
Advertisements
Reyalp makes some good points, although I can't think of any other device that would give you the flexibility that CHDK and a Canon camera gives.

One thing you might like to consider (apart from some very rigorous testing), is getting your power controller to reboot the camera at regular intervals, perhaps hourly, or even every 15 mins at a time synchronized with the camera/CHDK.  This assumes your power controller has a real time clock of course. That way if it does crash, it *should* come back to life, if the camera has crashed in the intervening period, you would thus loose very little data. This kind of watchdog function might make things a little more robust.

I would also be tempted to have more than one camera rig, the cost of each dive probably outweighs the cost of a Canon PS. Furthermore, what is the environment like, 300m down, I don't just mean the rather obvious pressure,  is the cold likely to affect operations, batteries perform much worse in cold climates.  How are you intending to house this rig?
« Last Edit: 29 / August / 2013, 17:23:44 by ahull »

Re: Lake-bed scientific research photography
« Reply #21 on: 30 / August / 2013, 05:33:42 »
I think it's not supposed to move during all this time and I'm not qualified to dive 300m for maintenance...
If this is serious, I think you need to carefully consider whether a Canon P&S with CHDK is really an appropriate solution for your application. If the camera hangs 10 days into your project, what are the consequences? How do those consequences compare to the costs of a properly engineered solution designed for your target environment?

Canon P&S are mostly decent quality, but they aren't engineered for months of continuous operation or mission critical reliability. If the camera crashes, the consumer just has to press the power button again, or at worst take the battery out. On top of that, CHDK is a hack. It operates by poking the guts of a complex, completely undocumented system, using techniques that were often discovered through trial and error with limited understanding.

At a minimum, you need to arrange for the ability to hard reboot the camera by cutting the power, and then re-applying it with the power button pressed. You could still end up with a corrupted SD card, which would require physical access to the camera to resolve.

I'm not trying to discourage you from using CHDK. I love to see all the weird and wonderful things people do with it. It might work fine. However, it is important to have realistic expectations.
The consequences aren't problematic if it hangs, we will be testing the rig before deploying and if it happens it happens, we'll try again.

The costs are a problem, commercial products exist for this kind of project, but they are stupidly expensive, I mean 20'000$+. We have access to all the tools needed to build one ourselves.

Right now the idea is still the original one:

  • A microcontroller turns on a relay that powers the camera and an external lamp
  • The camera runs a script that sets up the picture parameters
  • The camera takes a picture and retracts the lens
  • Relay is turned off after x seconds automatically by the microcontroller
  • Microcontroller goes to sleep mode for 6 hours
  • Next picture.

Since the camera is rebooted every time it takes a picture it should work reliably (I hope). The decision to make it this way took a couple of back and forth over the last years, I saw all the alternatives and costs were prohibitive. The best solution for the scope statement of this project was to make a rig of our own.

*

Offline ahull

  • *****
  • 634
Re: Lake-bed scientific research photography
« Reply #22 on: 30 / August / 2013, 07:22:42 »
Given the relative costs of building your own, versus purchasing I agree, its a no-brainer.

However, I still see too many single points of failure here that make me nervous.  For example we have swapped the possibility of the camera hanging for the possibility of the microcotroller hanging (although this is probably a much slimmer chance, but remember the only universal law in this particular universe is Murphys law).

The microcontroller saves us a lot of battery power, but I would be tempted to double up on batteries too, all this may just be my paranoia from years of working with things that go faulty in new, unexpected and interesting ways. 

I think that we could argue that our budget savings (we have just saved ourselves $20,000 after all  ;)) justify an additional rig. If everything works as expected, we get two lots of data (or even get our pictures in stereo), if one breaks down, we still get data, and our very expensive dive team gets saved from having to go through the whole routine multiple times.

I am of course assuming that you are diving to position your equipment rather than using some sort of anchor and float or robotic device to position and retrieve it.   
« Last Edit: 30 / August / 2013, 07:31:21 by ahull »

Re: Lake-bed scientific research photography
« Reply #23 on: 30 / August / 2013, 08:05:25 »
I think that we could argue that our budget savings (we have just saved ourselves $20,000 after all  ;)) justify an additional rig. If everything works as expected, we get two lots of data (or even get our pictures in stereo), if one breaks down, we still get data, and our very expensive dive team gets saved from having to go through the whole routine multiple times.

3D imaging was mentioned, I rapidly brushed if off to an eventual next version of the project.

I am of course assuming that you are diving to position your equipment rather than using some sort of anchor and float or robotic device to position and retrieve it.

An incredibly expensive robot was mentioned, so possible, but not needed as the features on the lake-bed span over vast areas. Currently we plan to just let it fall to place and hope for the best, then pull it back up with a rope, very KISS approach.


*

Offline reyalp

  • ******
  • 14080
Re: Lake-bed scientific research photography
« Reply #24 on: 30 / August / 2013, 16:21:34 »
The costs are a problem, commercial products exist for this kind of project, but they are stupidly expensive, I mean 20'000$+. We have access to all the tools needed to build one ourselves.
That's fine, just wanted to make sure you have realistic expectations.

Quote
  • A microcontroller turns on a relay that powers the camera and an external lamp
  • The camera runs a script that sets up the picture parameters
  • The camera takes a picture and retracts the lens
  • Relay is turned off after x seconds automatically by the microcontroller
  • Microcontroller goes to sleep mode for 6 hours
  • Next picture.
I would suggest attempting to power of the camera from within chdk first, either using shut_down() or post_levent_to_ui('PressPowerButton') Either should work, I would lean toward the latter since it should be exactly equivalent to pressing the physical power button on the camera. In my quick test, it seemed to work even the the power button was actually held down from startup.

This will minimize the chance of leaving the SD card or camera flash params in an inconsistent state. The microcontroller should cut power some safe amount of time after that is expected to take place. A minute or two should be fine if you have a 6 hour interval.
Don't forget what the H stands for.

Re: Lake-bed scientific research photography
« Reply #25 on: 04 / September / 2013, 03:43:12 »
I would suggest attempting to power of the camera from within chdk first, either using shut_down() or post_levent_to_ui('PressPowerButton') Either should work, I would lean toward the latter since it should be exactly equivalent to pressing the physical power button on the camera. In my quick test, it seemed to work even the the power button was actually held down from startup.

This will minimize the chance of leaving the SD card or camera flash params in an inconsistent state. The microcontroller should cut power some safe amount of time after that is expected to take place. A minute or two should be fine if you have a 6 hour interval.
Already done, the lens stayed open and I didn't like that, shut_down() at the end of the script works well with the power button pressed.

 

Related Topics