Physical limitations / Best approach

  • 4 Replies
  • 553 Views
Physical limitations / Best approach
« on: 07 / June / 2017, 03:32:47 »
Advertisements
I'm trying to capture and image based on distance travelled - ideally at 1 metre intervals. The maximum speed would be around 15 km/hr which works out at about 4 and a bit frames per second. From my research it sounds like this is beyond what can be achieved using CHDK? I plan on using a rally trip meter probe to record x pulses / second and a Raspberry Pi to trigger the shutter at the appropriate time, via CHDK. The idea is to be able to capture a consistent, albeit low frame rate, MJPEG style video regardless of speed variation (or even stopping completely).

I have a few (mainly older) cameras available to play with but I'm wondering if they would even handle the kind of workload this would take - if I could trigger a high enough fps, would they simply wear-out/break from the workload? What would be the effect of taking 10k images in a day? Do I need a special kind of camera to achieve what I'm aiming for? If I can achieve even 2 fps, I would be able to try taking a frame every 2m at least.

Any thoughts or pointers greatly appreciated.

*

Offline reyalp

  • ******
  • 11336
Re: Physical limitations / Best approach
« Reply #1 on: 07 / June / 2017, 13:57:15 »
I'm trying to capture and image based on distance travelled - ideally at 1 metre intervals. The maximum speed would be around 15 km/hr which works out at about 4 and a bit frames per second. From my research it sounds like this is beyond what can be achieved using CHDK?
This limit is determined by the camera hardware, not specifically CHDK. You can look at the continuous shooting spec to get an idea of what the realistic rate is.  Most of the cameras that run CHDK cannot shoot stills at anything close to 4 FPS. The cheaper ones tend to be closer to 1 FPS. The G7 X should be able to do around 4 FPS indefinitely.

Note that if you need the camera to re-evaluate focus and exposure between shots, the maximum rate will be significantly lower. If you only need exposure, you may be able to work around this using the previous image to calculate the next exposure.

Some cameras have reduced resolution modes that are significantly faster than the normal still rate.

Quote
I plan on using a rally trip meter probe to record x pulses / second and a Raspberry Pi to trigger the shutter at the appropriate time, via CHDK. The idea is to be able to capture a consistent, albeit low frame rate, MJPEG style video regardless of speed variation (or even stopping completely).
CHDK won't allow you to take mjpeg directly, but obviously you can take stills and convert them.

Quote
I have a few (mainly older) cameras available to play with but I'm wondering if they would even handle the kind of workload this would take - if I could trigger a high enough fps, would they simply wear-out/break from the workload?  What would be the effect of taking 10k images in a day?
Hard to say. A number of people have used these cameras for a lot time lapse shooting, but you are certainly talking about more than the designers would have expected. I have personally put a few hundred thousand shots on a couple of different cameras without failure.
Don't forget what the H stands for.

Re: Physical limitations / Best approach
« Reply #2 on: 07 / June / 2017, 19:02:51 »
Thank you for your thoughts. I will look into the camera you mention - it sounds likely to be the best candidate. I'm not expecting regular refocusing to be needed as the focal length should remain fairly constant. Light levels will change depending on the direction traveled and time of day/weather etc but as the speed will fluctuate regularly, I could script a refocus event when moving slowly (or stopped) as time allows.

From my initial trials it's amazing what CHDK enables - even with all these options now open to me, I wonder if I'm taking the right approach. I seem to be stuck half-way between the video world and still photography. After sleeping on it, I'm now wondering if recording video and simply discarding the majority of the frames might be a more realistic approach? These would probably be significantly more difficult to achieve, though.

Thanks again for your feedback.

Re: Physical limitations / Best approach
« Reply #3 on: 07 / June / 2017, 21:07:18 »
I'm trying to capture and image based on distance travelled - ideally at 1 metre intervals. The maximum speed would be around 15 km/hr .......
Any thoughts or pointers greatly appreciated.
....effect of taking 10k images in a day?...
".......effect of taking 10k images in a day?......" On my a480 no problems with 10k++, except for battery changes
and SD-Card changes. Just use a SD-Card Extender cable and external battery backup.

TriggerTrap is a (that is Now Open Source) Android and IOS app that might be of interest....(TT has an Optinal "DISTANCE TRAVELED SWITCH")
"....Now Open Source: Triggertrap Mobile  (Ada) Dongle..."
OR
"...how-a-half-million-dollar-kickstarter-project-can-crash-and-burn..."

Triggertrap’s camera triggering infrastructure is based on 3 parts:-

1/. The Triggertrap Mobile App is pretty simple:-
It outputs a 19 khz sine-wave tone for a very specific duration.
Of course, the magic is in how often, for how long, and how fast you send the tone.
We are planning on open-sourcing our iOS and Android app in the next month  (Feb 2017)— stay tuned.

2/. The Triggertrap Mobile Dongle plugs into your phone.
It takes this tone and turns it into a ("DISTANCE TRAVELLED") switch — if the tone is played, it closes the circuit.
If not, it, er, doesn’t....

3/. Finally, you need a camera connection cable running from the Mobile Dongle to the camera.
There are quite a few different ones — to find the right one, try this...  [Version 1; Needs .... Design modification's .... for CHDK]

Building a Triggertrap (Ada) compatible Mobile Dongle.....

As Triggertrap is currently on its way out of business,....
"...We want to open-source the hardware we have been creating for a long time, so the design files are now available on GitHub..."

Note Triggertrap version 1 was originally Open source BUT ... the dongle was designed for DSLR based Cameras.
Also it had design flaws that made version 1 unreliable.
To make (the App) compatible with a CHDK USB Remote Release some design modification's may be needed.....(more info if there is any interest)

H-H

Edit #1  Added Building A DIY Trigger Trap v1 Mobile-01.jpg [Version 1; Design modification's may be needed for CHDK]
Ref #1:- https://en.wikipedia.org/wiki/Triggertrap
Ref #2:- https://github.com/Triggertrap/Triggertrap-V1/tree/master/hardware/TriggerTrap [Version 1]
« Last Edit: 08 / June / 2017, 01:06:28 by Hardware_Hacker »


*

Offline reyalp

  • ******
  • 11336
Re: Physical limitations / Best approach
« Reply #4 on: 08 / June / 2017, 02:03:31 »
I will look into the camera you mention - it sounds likely to be the best candidate.
The G7 X is somewhat expensive, so you have other powershots lying around you might want to use do some initial development with them to decide with the overall approach is going to work for you. Note only the original G7 X is supported, not the current MK2 version. You can sometimes find good deals on Canon's refurb site

Quote
Light levels will change depending on the direction traveled and time of day/weather etc but as the speed will fluctuate regularly, I could script a refocus event when moving slowly (or stopped) as time allows.
If you want to adjust exposure based on the previous shot, my rawmeter and contae scripts are examples.

That kind of approach works well for smoothly varying lighting (like sunsets or passing clouds), but if you suddenly transition from full sun to full shade or vice versa you could end up with a few frames badly under or over exposed.

Quote
After sleeping on it, I'm now wondering if recording video and simply discarding the majority of the frames might be a more realistic approach? These would probably be significantly more difficult to achieve, though.
That's certainly an option, but you wouldn't be able to do it on camera with CHDK, at least not without a whole lot of reverse engineering. You'd need to record normal frame rate video and then periodically download the files and post process to drop everything but the frames of interest. This would let you use a much cheaper camera, and also reduce chances of mechanical failure since the mechanical shutter isn't used in video.

If you only need very low resolution (~640x480) you could grab live view frames with chdkptp.
Don't forget what the H stands for.

 

Related Topics