KAP & UAV Exposure Control Intervalometer Script

OhSnap

Thanks for the fast reply and sorry for my late one.
I have slightly modified your script with some changes for auto shutdown, but otherwise everything is the same.
I have IS turned off, and settings are as suggested in your site.
According to an online EXIF reader SD seems the same for all images (65.53m). Which makes sense since it's in continuous mode.
Please take a look at my attached script. Particularly out of focus images are : IMG_0001 IMG_0004 IMG_0009 IMG_0011 IMG_0012...

KAP.log

99.7KB

waterwingz

OhSnap
According to an online EXIF reader SD seems the same for all images (65.53m). Which makes sense since it's in continuous mode.
Please take a look at my attached script. Particularly out of focus images are : IMG_0001 IMG_0004 IMG_0009 IMG_0011 IMG_0012...

Thanks for posting the log file. I don't have any great answers here but I'll share some thoughts.

One thing that jumps out right away is that you have disabled the script from trying to set the focus at infinity (at least for the images you reference here). So it theory, the focus for first image in continuous mode is whatever Canon picks when it shoots that image and the subsequent images use the same setting. That's okay but I noticed you later let the script set the focus - did that change anything?

The EXIF info all set the same is also interesting - it appears neither the camera or script tried to change the focus while shooting.

So is it posible that we are seeing some sort of motion blurr? Or camera vibration? The focus is actually at infinity but the camera is not stable? If you put the camera on a tripod, point it at landscape scene and let the script take a few hundred photos with the settings you normally use, do you get any out of focus photos?

OhSnap

I did those tests, and seems images from a tripod mount are good. I turned off focus at infinity because it made all the pics blurry,
might have to tweak the distance in the script.
I'm leaning towards a vibration issue myself, weird thing is cameras are mounted on anti vibration bobbins and all props are balanced well.
I'm now gonna test with softer bobbins and see if that makes a difference.
Pictures however look like theyre out of focus and not fuzzy or blurred out like you would expect from vibration,
on the other hand vibes might move the optics around changing the focus.

Will run some more tests and update.

waterwingz

OhSnap
I did those tests, and seems images from a tripod mount are good.

So the script is basically working correctly.

I turned off focus at infinity because it made all the pics blurry, might have to tweak the distance in the script.

There is another huge thread on this forum where we looked at the whole "focus at infinity" issue. We made a lot of improvements but never got it 100% solid for every camera. Sigh ...

link> Manual Focus @ Infinity not working

I'm leaning towards a vibration issue myself, weird thing is cameras are mounted on anti vibration bobbins and all props are balanced well.

There have been quite few discussions on this forum thread on the vibration topic. The easiest way to review them is to click the "PRINT" button, which gives you the complete thread on one page in text mode. You can then use your browser search function ( ctrl-F ) to search on the word vibration and scroll through all the posts

link> KAP & UAV Exposure Control Intervalometer Script in Print Format

I'm now gonna test with softer bobbins and see if that makes a difference.
Pictures however look like theyre out of focus and not fuzzy or blurred out like you would expect from vibration,
on the other hand vibes might move the optics around changing the focus.

This article is very interesting :
link> DYI Drones : Let's Talk Canon Cameras

edit : forgot about this link : Setting focus from scripts or menus

OhSnap

After dozens of tests to figure out why my pics started to get blurry I found the culprit...
I had changed some frame parts to my quadcopter (the arms) and left the rest the same.
However it turns out, the different material properties resulted in vibrations of different frequency...

Vibrations in all cases were minimal, but seems the camera is more susceptible to lower frequencies.
I fixed it by swapping out propellers that produce less thrust thus have to be operated at higher RPM
and blurry pics disappeared.

Even when on purpose unbalancing the new props blurry pics are far less...

On another note I have made some additions to the script, one of them being an audible battery level indicator, since I cant really see the screen when mounted.

Now I'm trying to automate the camera shutdown based on the
[color=rgb(137, 2, 2😎]get_focus[/color] command.
However after 3353mm I get -1 as return value, any clue why that could be ?
Works fine for 0-3353mm

Again thanks for the help and effort you put in your replies!

waterwingz

OhSnap
After dozens of tests to figure out why my pics started to get blurry I found the culprit...

Thanks for reporting back on that. Too frequently people come here for help and then get busy or something and don't report back on their findings / results.

However after 3353mm I get -1 as return value, any clue why that could be ? Works fine for 0-3353mm

How did you test this? I thought you had focus locked in the script?

Can I assume you started with the camera lens almost touching something and then moved away from that object. And the reported focus distance started at 0mm and kept going until you were about 3.3 meters away. If you moved any farther away you got -1 reported?

Edit : I spent 10 minutes chasing through the get_focus() code hoping to see if -1 means "infinity" - which is my suspicion. Might be - ran out of time to chase it further. Sorry.

reyalp

waterwingz
Edit : I spent 10 minutes chasing through the get_focus() code hoping to see if -1 means "infinity" - which is my suspicion. Might be - ran out of time to chase it further. Sorry.

Yes. When you set_focus (or AF on a distant object, or use Canon MF, on cameras that have it) beyond a certain (camera / zoom dependent) distance, you start getting -1 back from get_focus.

This does not necessarily mean that it's the focus setting that gives the best focus for distant objects, and at lest in the Canon MF case, there can be many focus positions beyond where get_focus starts returning -1.

OhSnap

Waterwigz I tested that with a small script I made that just looped and read get_focus().

It works in a weird way since I seem to max out the focus at roughly 1m, even though
reported value is 3353.

reyalp .. is it normal that it maxes out so quick ? Or could get_focus() be inconsistent ?
If it is true that puts an end to the auto lens retract idea 😳

Waterwingz, would you want to see the battery gimmick I added ? In case you'd like to use it.

waterwingz

OhSnap
Waterwigz I tested that with a small script I made that just looped and read get_focus().

Did your script do "half press" requests to make the camera refocus between each call to get_focus() ?

It works in a weird way since I seem to max out the focus at roughly 1m, even though reported value is 3353. reyalp .. is it normal that it maxes out so quick ? Or could get_focus() be inconsistent ?

I spent a lot of time working and reworking the MF stuff in CHDK. One of my conclusions over time was that while most cameras could be tricked into setting a fixed focus point, the calibration on the models that do not offer true MF under Canon control is pretty much non-existent. The functions to set focus are in the code but somehow not calibrated - or at least the lens mechanism goes to some fixed position but Canon made no attempt to make that position represent the focus distance requested.

I would expect the same lack of calibration exists with get_focus( ) too.

I gave some thought to adding a manual calibration function to CHDK so that a user could adjust where CHDK tells the Canon firmware to position the lens for each requested real distance. It's on my "someday" list as actually performing the calibration would be slow, finickity, and tedious.

Waterwingz, would you want to see the battery gimmick I added ? In case you'd like to use it.

Sure. Although I'm not sure every CHDK camera can actually produce sounds - I'm pretty certain some of mine don't.

reyalp

OhSnap
reyalp .. is it normal that it maxes out so quick ? Or could get_focus() be inconsistent ?

My SX710 goes to -1 around ~4000 at full wide. The point where it changes seems to vary, while I was playing around with manual control sometimes it would go to 4400 and sometimes 3900. At longer zooms, the values go much higher.

This .txt https://app.box.com/s/83xz0ltib3v5ebq6m8edlpn8ju2c4wcb is a log from testing elph180 with chdkptp. Between the 2nd and 3rd runs, I zoomed the lens in and back out to fully wide. (linked because attachments seem to be broken at the moment)

waterwingz
Did your script do "half press" requests to make the camera refocus between each call to get_focus() ?

FWIW, this should not be needed if MF or AF lock is on (including set by set_mf or set_aflock if those work in the port)

According the ixus125_elph110hs platform_camera.h, SD override is only supported with set_mf or set_aflock.

edit: I assumed the script was doing set and get, if it's like waterwingz described, then disregard this.

waterwingz

reyalp
FWIW, this should not be needed if MF or AF lock is on (including set by set_mf or set_aflock if those work in the port)

if i understood the description of his script correctly, it just looped calling get_focus( ). No calls to set_focus( ). So with AFL or MF enabled, the focus distance should not change without a half-press.

OhSnap

waterwingz
if i understood the description of his script correctly, it just looped calling get_focus( ). No calls to set_focus( ). So with AFL or MF enabled, the focus distance should not change without a half-press.

Yes, I only looped having half-press and having set the camera focus mode to continuous AF.
This way the camera would refocus on every distance change. No need for set_focus().

reyalp
At longer zooms, the values go much higher.

Hmmm, maybe if I'd get the camera to zoom in I could get more distance before -1 appears.
Thus being able to use it for the before landing lens retract. Though zooming in and out does sound a bit of
a hassle I will probably give it a go.

waterwingz
Sure. Although I'm not sure every CHDK camera can actually produce sounds - I'm pretty certain some of mine don't.

I use the play_sound function. And use the built in canon sounds. I suppose most have them ?
For anybody who wants to try it I have attached. There are other small changes too.

kap_uav_new2.lua

45.03KB

reyalp

OhSnap
Yes, I only looped having half-press and having set the camera focus mode to continuous AF.
This way the camera would refocus on every distance change. No need for set_focus().

That makes sense. A lot of values only update on half press even if the underlying state updates continuously, but this doesn't apply to get_focus. Beware that continuous AF will prevent CHDK focus overrides from working.

waterwingz
Sure. Although I'm not sure every CHDK camera can actually produce sounds - I'm pretty certain some of mine don't.

I use the play_sound function. And use the built in canon sounds. I suppose most have them ?

AFAIK all powershots have sounds. The one tricky bit is if you mute sounds in the menu, it also mutes play_sound.

waterwingz

reyalp
A lot of values only update on half press even if the underlying state updates continuously, but this doesn't apply to get_focus.

For clarity then, the value returned by get_focus( ) only updates after a half_press ?

reyalp

waterwingz
For clarity then, the value returned by get_focus( ) only updates after a half_press ?

No. I verified that the get_focus value updates continuously on SX710 in continuous AF mode, and I would expect it to be true of most/all other cameras.

waterwingz

reyalp

waterwingz
For clarity then, the value returned by get_focus( ) only updates after a half_press ?

No. I verified that the get_focus value updates continuously on SX710 in continuous AF mode, and I would expect it to be true of most/all other cameras.

So the value returned by get_focus( ) only updates after a half_press unless you are using continuous AF mode, and in that case it updates continuously ?

reyalp

waterwingz
So the value returned by get_focus( ) only updates after a half_press unless you are using continuous AF mode, and in that case it updates continuously ?

AFAIK:
1) get_focus returns the current focus distance
2) Whether the Canon firmware changes the focus distance outside of half press depends on Canon settings. In typical standard AF, it only refocuses on half press.

cagiva

I have a PowerShot A3000IS camera and installed the latest CHDK builds1.4.1 using the STICK utility; which automatically configures the SD card with two partitions (a small FAT16 and a larger FAT32) since my camera was released before 2011.

I downloaded and copied the kap_uav.lua script into the \CHDK\SCRIPTS folder as described here. After that, I went to the CHDK Miscellaneous menu and enable Lua Native Calls. However, I still get an error loading module '/gen/cnf_core' when I try to run/activate the kap_uav.lua script (see attached picture).

Has anyone resolved this issue? Is the kap_uav.lua script compatible with cameras released before 2011; which usually are configured with two partitions?

waterwingz

cagiva
I have a PowerShot A3000IS camera and installed the latest CHDK builds 1.4.1 using the STICK utility; which automatically configures the SD card with two partitions (a small FAT16 and a larger FAT32) since my camera was released before 2011.

So far .. so good.

I downloaded and copied the kap_uav.lua script into the \CHDK\SCRIPTS folder as described here.

The script needs to be stored in the /CHDK/SCRIPTS of the larger FAT32 partition - did you do that? I'm assuming so as if you somehow managed to boot and run from the smaller partition the script would not be there.

After that, I went to the CHDK Miscellaneous menu and enable Lua Native Calls. However, I still get an error loading module '/gen/cnf_core' when I try to run/activate the kap_uav.lua script (see attached picture).

But if you did somehow manage to boot and run from the smaller partition without a switch to the larger partition then the /gen/cnf_core file would make sense.

Has anyone resolved this issue? Is the kap_uav.lua script compatible with cameras released before 2011; which usually are configured with two partitions?

FWIW, this is not an issue with the script itself. The script has been downloaded over 4500 times and used on a lot of Powershots - including several of mine released prior to 2011 with dual partition cards.

It looks like you've somehow ended up with an SD card missing critical files on the large partition. Either that or an SD card that boots from the small partition and fails to switch to the larger partition.

Before I speculate further, I'll wait for @reyalp to point out the obvious thing we are missing here 😎

reyalp

waterwingz
Before I speculate further, I'll wait for @reyalp to point out the obvious thing we are missing here 😎

Nothing obvious to me.
I'd suggest checking in the CHDK file browser:
1) Does CHDK/LUALIB/GEN/cnf_core.lua exist?
2) What is the displayed free space at the bottom of the file browser, is it a few MB (meaning you are seeing the "small" partition", or roughly size of the card (the large partition)?

If the file is present and the large partition is in use, I'd suggest checking "Miscellaneous->Show Memory Info" in the CHDK menu and posting the value here. Low free RAM could prevent the cnf_core module from being loaded.

If the file browser is showing the small partition, then something went wrong in the card setup, or multi-partition support is broken in the A3000 port (less likely, IMO)

« Previous Page Next Page »