blight=1 -- backlight on / current state
bldisp=true -- turn off display with eventproc if true
if call_event_proc('DispDev_EnableEventProc') == -1 then
if call_event_proc('DispDev.Create') == -1 then
bldisp=false -- must turn off display with set_backlight
end
end -- end of initialization code
function backlight(bl) -- bl=0 off, 1 on, -1 toggle
if(bl<0)then bl=bitxor(blight,1) -- toggles 0 or 1
elseif (bl>1)then bl=1 end
if(bl==blight)then return end -- don't double set to current state
blight=bl
if(bldisp)then
if(bl==0)then call_event_proc('DispCon_TurnOffDisplay')
else call_event_proc('DispCon_TurnOnDisplay') end
else set_backlight(bl) end
end
I discovered something interesting about set_backlight while adding this function to my custom C code in CHDK. If you try to turn off the backlight by calling TurnOffBacklght() twice or more, without a "sleep" in between, the backlight doesn't go off. I assume this applies to set_backlight(0) if there is no sleep (lua yield) between calls, although I haven't tested it.
My only suggestion would be to try reyalp's method of turning the display off with event_proc instead of set_backlight. I've been using it, and it really does turn the power off to the display, with resulting increase in battery life (15% versus 10% in my test).Thanks. Seems like a good idea but for a 5% power saving gain I think I'll pass for now. There are enough things to go wrong with a new & complex script like this! Adding a relatively untested method to toggle the backlight seems like one risk too many.
I believe there is a problem with turning off the display instead of turning off the backlight.I seem to recall that too. And while the battery savings is interesting, I'm not sure its really necessary on for a kite or UAV shooting sequence. With just the backlight off, my experience shows 3 to 4 hours of shooting time. Seems like a long time to hold onto a kite string?
I believe there is a problem with turning off the display instead of turning off the backlight.When you turn off the display with the camera display button, it cancels manual focus and returns to auto-focus on some cameras, including the G1X. Using the event_proc method of turning off the display doesn't affect the manual focus.
having full control of not only the shutter speed and ISO values but aperture and ND filter settings as well - with the ability to easily adjust the ranges they work over - should give people plenty of things to experiment with and optimize their personal shooting experience.
Whilst that is true, I believe it is not necessary.You may very well believe its acceptable to force the camera's lens wide open and the ND filter out.
I tested the script on my camera. I use a Canon IXUS 230 HS (ELPH310HS) version 1.00e. I noticed that when first installed, the script starts and works fine. When the camera is restarted, it fails with "could not load propcase.lua". I researched this a bit and it seems it's related to memory issues and pools.So if you start the camera "cold", have you loaded and run the script for an extended period of time (10 minutes) taking pictures? Is it only when you stop the script and rerun it that you have this problem?
So I removed some of the functions that I didn't require for my camera like the iris control and some of the focusing methods. This got rid of the memory issues.Painful but whatever works. On my "low memory" A1200 I never had to do that.
The next strange issue is that when the camera shuts down with the script running, on restart it crashes. When I press the shutter to stop script execution on reboot, the cam starts ok and then the script can be restarted.Strange. Just a guess here - do you have logging to the SD card enabled? And by "shut down" do you mean you press the power button while the script is running?
Some of the uav control boards use 5V usb power to do the photo triggering. For cams without gps, this is great, because the position of the trigger is stored on the controllers storage. So in the end I removed the intervalometer too and replaced that with usb trigger, where a much longer pulse shuts down the camera.I'm now glad I added the USB functionality too :)
It would be an interesting idea to extend the script to choose what happens with the usb trigger, but obviously I'm having troubles fitting the script in memory already. Is there any setting I can make to influence the use of memory?There are a couple of things to try.
Further to all my above questions, if you stop the script (when it has been launched after a cold start) by pressing the "Menu" key while it's running (rather than the shutter button or the power button), can you then successfully restart and run the script?I tested the script on my camera. I use a Canon IXUS 230 HS (ELPH310HS) version 1.00e. I noticed that when first installed, the script starts and works fine. When the camera is restarted, it fails with "could not load propcase.lua". I researched this a bit and it seems it's related to memory issues and pools.So if you start the camera "cold", have you loaded and run the script for an extended period of time (10 minutes) taking pictures? Is it only when you stop the script and rerun it that you have this problem?
I want to enforce infinite focus distance, but I am failing toThere is a choice of MF setting methods available as a user parameter for the script. Not every one will work with every camera unfortunately but when they do they will force the focus to infinity. If you use the AFLock method, which should work for your camera, just be sure the camera is pointed at something off in the distance when the script starts.
I have written :Setting the Av (aperture) is only useful on cameras with an adjustable aperture. The A2500 has a fixed aperture and thus will not respond to those settings. (Any changes you see in the aperture reported in your picture's EXIF or the camera's on screen display are caused by changes in zoom position).
Min Av : 8
Target Av : 8
Max Av : 8
So I am expecting 8 as Av but I am getting 2.8/3... What am I doing wrong ?
just be sure the camera is pointed at something off in the distance when the script starts.
So from my multirotor, I will therefore aim at the skyline, start the script, then put it on the ground and start flying.The "trick" here is making sure the camera actually has something to "focus" on. Clouds or a building way off in the distance work well here. Clear blue skys do not.
A cool thing would have been to focus at the time of the very first picture and not when starting the script, so that delay before first picture can be used for taking off and elevate high enough before initial focus.That's easy enough to add to the script but why not just let the camera focus before every shot then?
That's easy enough to add to the script but why not just let the camera focus before every shot then?
Don't know if you seen my post on the KAP forum, but it would be great for if there was an option to set focus by hyperfocal distance.Yes, I've seen the post. Thanks for using the script and commenting positively.
If the focus lock is set to off in the script, and you use CHDK to set the focus to hyperfocal distance before running the script the photos will be taken at the hyperfocal distance.Your camera is one of those that can set focus without being in MF (or AFL) mode. Lucky you! I'll probably modify the script params so people with camera models like that will be able to set infinity or hyperfocal focus without the trying for MF or AF lock.
You will want to make sure Iris is not enabled for AV Mode in the script, as different apertures will affect the hyperfocal distance.The script will take that into account.
Looking forward to the next upgrade.Me too :) Should be this week some time.
Would it be possible to add 1/640 as a Target Tv?Yes - good idea.
waterwingz, here's a comparison between infinite and hyperfocal. Infinite appears to do a better job unless Safety MF is set to on.Thanks for taking the time to put this together. Its nice to see some actual data! To my tired eyes, the hyperfocal image is clearly inferior and the other three are about the same. But then I've never been much good at "pixel peeping" - how do you see it?
f/4.0 1/800 ISO:80
I would like to be able to set the script to shoot at 1/640 with AV mode Iris. On a clear sunny day this would keep the aperture around f/4.0 on my A590. Perfect for one of my favorite KAP shooting environments. :)Here's link to version 1.2 :
When I click on the link to download version 1.2 it ask me to sign up for box. With the original script I didn't need to sign up. Would it be possible to download version 1.2 without having to sign up?Box.com can be annoying that way sometime. Rather than fix it, I updated the wiki page to reflect the changes in the script and updated the normal link to provide the 1.2 version.
I install KAP UAV script for my CHDK Canon S110 ONLY to take photo from my Dji550 exacopter… I use a remote lcd screen with TX RX to see image from Canon Camera in the sky to my monitor on the field.What you have done here has a couple of problems.
It works well but I have some question for you.
I shot manual mode in CHDK; so in Enanched Photo Operation/Override Tv i put 1/1250 and the dot, Override Av 2,05 and the dot, Override ISO 100 and the dot, so all photo has some exposure… How can I do the same with KAP UAV script ??? Which are the correct parameters here?? I try to Override Tv+Av+Iso like I write here up and try to put these values in your script like this…
Av Mode none
Target Tv 1/1250
Tv Max 1/1250
Lowest Av 2,8
Target Av 2,8
Highest Av 2,8
ISO Min 100
ISO Max1 100
ISO Max2 100
But when I see photos in Lightroom (with this values just up here in your script) I saw this in metadata info:Sometimes, the exif meta values in the image information are the values that the Canon firmware is trying to use. They are not the override values that CHDK forces the camera to use. I'm not clear on when that happens and when it does not.
AV 2.0
Iso 50
and different TV from 1/1700 to 1/590….
The script try to use always the correct time shutter, good, but it is possible fix it, as my request (1/1250 sec.) ???? Can you help me??? Thanks a lot Milobg www.skymotion.it (http://www.skymotion.it)If you just want to lock the exposure at 1/1250 and still use the script, then you are going to have to let the script adjust the aperature and ISO values to get a good exposure setting. Try this :
So first I try the values you suggest me…. I put camera outside my window to taking photo to bright an dark areas:Its very strange that you see this behavior. With those settings, the shutter speed should not drop below 1/1250 until the ISO hits 1600. I'll take a look - you might have discovered a bug or the EXIF ISO values are not being reported correctly in LightRoom
• Av Mode : both
• Target Tv : 1/1250
• Tv Max : 1/1250
• Lowest Av : 2.0
• Target Av : 2.8
• Highest Av : 8.0
• ISO Min : 100
• ISO Max1 : 400
• ISO Max2 : 1600
After I look all photo in Lightroom… All photos have a good exposure… but the ones in dark light have 1/640 and 400 iso….
I do not want this….
So I need an intervallometer with Zoom, Lock Focus to infinity and Lock exposure to my values... Is it possible????If that's all you need, its a simple script. Do you have a link to the "conservation drone" script you mentioned - it might be easiest just to modify that.
So first I try the values you suggest me…. I put camera outside my window to taking photo to bright an dark areas:Can you enable logging and repeat this test? Use the last parameter in the script menu that says Logging and set it to Both.
Hi Like you told me yesterday, here is the KAP.log file....Thanks. Only the last seven shots in the log are setup as you described in your previous posts. The only shot there not at 1/1250 is IMG_7351.JPG. It's shooting at 1/800 because the ISO is maxed out at 1600. The script seems to be performing exactly as designed.
now if I want to lock exposure with your script...To get the correct exposure, the script will lower the shutter speed once the ISO is at maximum and the f-stop is fully opened. Otherwise you will have an underexposed picture. You could try setting ISO Max2 to 3200 to help with this.
What do you suggest to me??
I have the target shutter speed set to 1/1600, and most images are being shot correctly at that speed, however I've come across a couple which were shot at a lower shutter speed and iso, and are blurry because of it.This is most curious. Would you say the exposure was correct (i.e. not too dark or too bright) even though the shutter speed was not what you required?
In my kap.log for some of those files, this is the output:First of all, the script did try to take every shot at 1/1600. You can see that in the log lines that start with the word "actual".
2013Dec06 15:02:52 26) IMG_1022.JPG
2013Dec06 15:02:52 meter : Tv:1/640 Av:2.8 Sv:80 827:827
2013Dec06 15:02:52 actual: Tv:1/1600 Av:- Sv:160
2013Dec06 15:02:59 27) IMG_1023.JPG
2013Dec06 15:02:59 meter : Tv:1/320 Av:5.6 Sv:80 910:910
2013Dec06 15:02:59 actual: Tv:1/1600 Av:- Sv:400
2013Dec06 15:02:59 AvMin:2.8 NDF:none foc:infinity
2013Dec06 15:03:07 28) IMG_1024.JPG
2013Dec06 15:03:07 meter : Tv:1/125 Av:5.6 Sv:n/a 838:838
2013Dec06 15:03:07 actual: Tv:1/1600 Av:- Sv:640
2013Dec06 15:03:07 AvMin:2.8 NDF:none foc:infinity
2013Dec06 15:03:13 29) IMG_1025.JPG
2013Dec06 15:03:14 meter : Tv:1/500 Av:2.8 Sv:80 780:780
2013Dec06 15:03:14 actual: Tv:1/1600 Av:- Sv:250
2013Dec06 15:03:14 AvMin:2.8 NDF:none foc:infinity
When I look at the exif for these files, they don't match up to the log:Do the exif values for other images match the log entries made by the script? ( Other than ISO80 being reported as ISO50 ).
IMG_1022.JPG is 1/400, f2.8, iso 50.
IMG_1023.JPG is 1/200, f2.8, iso 50
IMG_1024.JPG is 1/1600 iso 640 (as it should be)
IMG_1025.JPG is 1/320, f2.8, iso 50.
Just did a test with the AV Mode set to NDFilter, and pretty much every shot is way overexposed, generally with a shutter speed of 1-250-1/400 at iso 50 (target shutter speed was set to 1/1250)Looks like you took those shots in bright light? In every one of those shots, the camera appears to be inserting the ND filter and taking an exposure reading that way. This is different behavior from what I've seen on my cameras - I will have to study it a bit.
How do you tell if the exif values are correct or not? I was just shooting straight down onto grass (the same area and conditions as yesterday) and it's a reasonably sunny day today. The overexposed images that were produced make me think that it did actually use a slower shutter speed, but I'm not much of an expert with chdk cameras.The script log reports that CHDK is trying to override the shutter to 1/1250. I would be very surprised if that does not happen. On my A1200, once you ask for a shutter speed above the normal camera upper range, the exif data does not save the higher shutter speed for some reason even though the image is taken at the faster speed.
These overexposed shots all have motion blur too, so I still think the shutter speed is low.If that's true, then it would mean the CHDK port for the SD960 is seriously broken. Nothing much I can do about that with a script.
Bug reports are welcome (preferably with a description on how to reproduce).These overexposed shots all have motion blur too, so I still think the shutter speed is low.If that's true, then it would mean the CHDK port for the SD960 is seriously broken. Nothing much I can do about that with a script.
Bug reports are welcome (preferably with a description on how to reproduce).The script does not correctly handle the situation where the camera wants to insert the ND filter and reports using a smaller f-stop setting as a result. It assumes the reported Av value is the actual aperture f-stop setting and does its exposure calculations based on that. When the actual shot occurs, it ends up using calculations based on the ND filter being inserted even though it does not insert that filter.
I have applied the 'short shutter press' override fix in changesets 3264, 3265, but I'm not sure if that will have any influence on this script.Thanks for that. Reading your commit comments, it appear this only happens on the first shot? In this case, according to the script's log, if there is a bug then it is happening through-out the intervalometer run on many shots.
-- set up all exposure overrides
set_tv96_direct(tv96setpoint)
set_sv96(sv96setpoint)
if( av96setpoint ~= nil) then set_av96_direct(av96setpoint) end
nd_string="none"
if(Av_mode > 1) then -- ND filter available ?
if ( insert_ND_filter == true ) then
set_nd_filter(1) -- activate the ND filter
nd_string="NDin"
else
set_nd_filter(2) -- make sure the ND filter does not activate
nd_string="NDout"
end
end
-- and finally shoot the image
press("shoot_full_only")
sleep(100)
release("shoot_full")
repeat sleep(50) until get_shooting() == false
I have applied the 'short shutter press' override fix in changesets 3264, 3265, but I'm not sure if that will have any influence on this script.Looking at the code in core/shooting.c, it does not look like the change to the aperture_sizes_table[] in this patch going to change the value returned by get_av96() if the ND filter is inserted ?
The script does not correctly handle the situation where the camera wants to insert the ND filter and reports using a smaller f-stop setting as a result. It assumes the reported Av value is the actual aperture f-stop setting and does its exposure calculations based on that. When the actual shot occurs, it ends up using calculations based on the ND filter being inserted even though it does not insert that filter.I thought PROPCASE_AV should show the chosen Av value (it seemed to when I recorded the possible Av values).
The fix for cameras without an adjustable aperture is to use get_prop(props.MIN_AV) to determine the actual Av96 value of the aperture rather than the get_av96() function.This is probably correct for DOF calculations, but is it really good basis for determining exposure?
Reading your commit comments, it appear this only happens on the first shot?Testing this is rather boring, but it seemed to only affect the Tv override, when ISO was also overridden, and mostly when doing a short press. I've only seen this right after transitions to rec mode, subsequent shots were correct.
The camera may engage the ND filter in bright light, but take the picture without it (not CHDK related).I was referring to live view, the ND is moved to its final position on half-shoot.
is about the issue here, that's a script logic problem and not related to the patch
Probably, but people without the cam will now at least see what's available.I have applied the 'short shutter press' override fix in changesets 3264, 3265, but I'm not sure if that will have any influence on this script.Looking at the code in core/shooting.c, it does not look like the change to the aperture_sizes_table[] in this patch going to change the value returned by get_av96() if the ND filter is inserted ?
I thought so too. But looking at the logs posted above, the Av values I highlighted in red are straight from a get_av96() call and as I commented, for the SD980 they can only change like that if the zoom shifts or the ND filter engages. The OP says he did not move the zoom, so that leads me to the conclusion that PROPCASE_AV is changed when the camera plans to insert the ND filter. (i.e. the reported APEX96 value is the effective aperature value and not the ratio of the lens' focal length to the diameter of the entrance pupil.)The script does not correctly handle the situation where the camera wants to insert the ND filter and reports using a smaller f-stop setting as a result. It assumes the reported Av value is the actual aperture f-stop setting and does its exposure calculations based on that. When the actual shot occurs, it ends up using calculations based on the ND filter being inserted even though it does not insert that filter.I thought PROPCASE_AV should show the chosen Av value (it seemed to when I recorded the possible Av values).
On a camera without an adjustable aperature this works correctly (assuming you control the ND filter in the script as well) and is a tricky way to detect if the camera planned to use the ND filter (thanks to reyalp for that one).QuoteThe fix for cameras without an adjustable aperture is to use get_prop(props.MIN_AV) to determine the actual Av96 value of the aperture rather than the get_av96() function.This is probably correct for DOF calculations, but is it really good basis for determining exposure?
A subsequent test of 6 shots gives exif showing 1/1250.Sound a bit like the bug srsa_4c patched yesterday. If you download the latest build from the autobuild this might just go away.
Looks to be working pretty well now. Getting a few not-so-sharp images still, but could just be due to gimbal shake...Good to hear - thanks for reporting back!
Looks to be working pretty well now. Getting a few not-so-sharp images still, but could just be due to gimbal shake...Good to hear - thanks for reporting back!
What Tv value is reported in the exif & the script log for those images ?
Exif shows all were shot at 1/1600, f2.8, and the ISOs all match up.Gotta like that! Thanks to srsa_4c for making the fix to the SD980 !
Hi waterwingz, would it be possible to add a function to turn off the camera when it completes shooting the total number of shots?Doesn't sound like a big problem to add. At one point I had the code simply switch to playback when shooting was done so that the lens could retract prior to landing. I assume you are asking for the same reason?
Yes, that's the reason. Thanks for adding it to the script.Hi waterwingz, would it be possible to add a function to turn off the camera when it completes shooting the total number of shots?Doesn't sound like a big problem to add. At one point I had the code simply switch to playback when shooting was done so that the lens could retract prior to landing. I assume you are asking for the same reason?
First time on this forum. I just got a SX260 to use on a quadcopter. I want to take off without the lens extended and then start this script. How would some one go about doing that?Easy - all you need to do is set the script's Start Delay and then start the script just prior to launch.
I see there is a parameter to turn off the backlight off. However, it doesn't appear that my backlight turns off what is this suppose to look like? Does the screen dim or turn off? It doesn't appear to be dimming.If you have your shot rate set fairly high, on the order of one shot every 5 sec or less, then the backlight never gets a chance to turn off. Its a long standing limitation of the CHDK script set_backlight() command caused by the fact that the backlight turns on after every shot, requiring the script to pause briefly to turn it back off again.
exiftool -a -u -g1 -h IMG_0181.JPG > IMG_0181.HTMLreportsFocus Distance Upper 0.78 m
which I think indicates that it was trying to focus quite close. If I set my D10 to infinity in MF mode, I getFocus Distance Upper 15.69 m
Focus Distance Lower 0 m
With the SX260 HS I haven't been able to figure out how to get the focus to lock at infinity. I even tried to take pictures using just M mode (no CHDK) and using these settings:What setting are you using for the focus mode in the script? Its possible you are locking the focus when you run the script and its staying locked between runs.
I am using aflock for the Focus @ Infinity Mode parameter. Also, does it matter what mode the camera is in when tthe script is running? Which mode should it be it M, Av, Tv, AUTO etc?The mode should not matter - the script will override. But try disabling the aflock - go with "none" for now and power cycle the camera before running the script again.
I took the memory card out and reset the camera. Then put it back in with the changed Focus param to "none".Sorry - I'm sitting in a very cramped coach seat on an airplane right now and can't do much in the way of testing. Can you enable logging to the SD card, rerun the test, and post the result here?
I went outside and point the camera at the overcast clouds and ran the script. The properties of each photo say that the focal length is 4mm.
the properties of each photo say that the focal length is 4mm.The focal length is the lens focal length (zoom level), not the focus distance.
The "Focus Distance Upper" and "Focus Distance Lower" items I mentioned earlier should tell you something about the the focus distance, but the meaning is not entirely clear to me. This can be displayed with exiftool, but they are proprietary Canon "maker notes" so many programs will not display them. It is also not certain they would correctly reflect CHDK overrides.Alternatively, if you go to CHDK Settings -> OSD Settings and select Show OSD [ * ] and then go to CHDK Settings -> OSD Settings->DOF Calculator and set Show DOF Calculator to [ In Misc ] and select Show Sub. Dist. in Misc [ * ] you will get a nice on screen display of the current focus distance in mm.
If you are testing on the ground, you can aim the camera at something close. If it is in focus, the camera AF is active and your override to infinity is not working.
I'm using it with remote control function: i'm starting the camera in Playback mode (lens closed) and i'm playing with the voltage supplied on the camera mini usb connector ( 0v-5v) to start and stop the script.Script updated to version 1.6 When USB control is enabled and USB power is "Off" then the camera will be placed into playback mode. When USB control is enabled and USB power is "On" then camera is placed into shooting mode.
Now if i'm stopping the script the lens remain opened and for me it would be perfect if when i stop the script camera to turn off the lenses and remain in playback mode, it is possible? If i want to restart the script lens to open again, and so on.
Can you please tell me from where i can download v1.7? I have tried here http://chdk.wikia.com/wiki/KAP_%26_UAV_Exposure_Control_Script (http://chdk.wikia.com/wiki/KAP_%26_UAV_Exposure_Control_Script) but it seems that is v1.6There is no 1.7 - I meant to say 1.6.
Set the Canon lens retract parameter to 0 Seconds if you want the lens to retract as soon as USB power is removed.
Edit : fixed new version number.
Sorry for asking but can you point me to the parameter that is responsible to retract the lens ? What exactly i must modify and where on the script?I'm not sure what it is that you think you want to modify? Lens retract delay is done by setting that value in the Canon menus.
Sorry for asking but can you point me to the parameter that is responsible to retract the lens ? What exactly i must modify and where on the script?I'm not sure what it is that you think you want to modify? Lens retract delay is done by setting that value in the Canon menus.
Now i have understood, the parameter that you talked about if from the Canon menu.Thank you too. I think its a good upgrade to the script.
I have made a trial and is working as expected, THANK YOU!
Thanks waterwingz for the amazing script. 8)You're welcome. But to be clear, equal credit goes to peabody (http://chdk.setepontos.com/index.php?action=profile;u=7384) (a.k.a. wayback). It was very much a joint effort.
can your script be altered to include video recording so that stills and video can be taken on the same flight ?Its just a script and as such always possible to modify. How would you see this working? Take a short video every so many seconds with video duration and interval user defined? Or trigger video mode via the USB remote input? Or both, I guess.
Does it have an adjustable iris and nd filter? Can't seem to find any info around on this.They have both. The next release of the script will force the ND filter off if the user does not select a mode that allows it. Apparently several people have set the AVmode to no ND filter on cameras that actually have one, and that can throw things off. So will setting AVmode to none when your camera has an adjustable iris and an ND filter.
I've done a couple of test runs so far with 1/1250 shutter with AVmode set to none, but I'm getting a lot of overexposed and blurry images.
Also what's the best focus at infinity mode to use with this camera? I'm currently using AFL and it seems to show focus set to infinity in the kap.log. 'aflock' didn't seem to work.While we continue to sort the whole SD override thing out, if you have something that works, use it. We are getting really close now.
Is there a way to keep the HDMI port active while the script is running? It works until the script starts, then it seems to stop outputting to the HDMI port.Most of my cameras have an HDMI port so I've never tried to use it. Does it stop outputting to the HDMI port when you run any script or just with the kap_uav.lua script?
Most of my cameras have an HDMI port so I've never tried to use it. Does it stop outputting to the HDMI port when you run any script or just with the kap_uav.lua script?
Is there a way to keep the HDMI port active while the script is running? It works until the script starts, then it seems to stop outputting to the HDMI port.Most (if not all) cameras are incapable of outputting HDMI while in shooting mode.
Most (if not all) cameras are incapable of outputting HDMI while in shooting mode.
Does it work if you switch the camera to shooting mode without the script?
The 11 pin mini usb plug will have to be the thing to use then.I'm not clear which camera you are using, but it's not necessarily safe to assume it will support video out in shooting mode using the analog out either. The Canon manual should tell you if it does, see discussion in http://chdk.setepontos.com/index.php?topic=11290.10 (http://chdk.setepontos.com/index.php?topic=11290.10)
Hi waterwingz,
Can the interval part of the script be bypassed and the camera be triggered through the USB with a CHDK cable instead?
Oops :-[ should have read the wiki a little closer. This is stated under features:The feature enables/disables interval shooting. So when USB remote is active, the script shoots at whatever rate you have specified in the script parameters. Probably fine for most applications but it does not give you one shot per USB activation if that's what you were looking for.
shooting enable / disable via USB remote signal
Here's a link to a tutorial that shows how to use a flight controller to trigger a camera running CHDK based on distance intervals as the vehicle travels.Wow, that page and all the ones it links to are a whole new world. Lots of CHDK references there too - nice to see.
http://diydrones.com/profiles/blogs/apm-to-chdk-camera-link-tutorial (http://diydrones.com/profiles/blogs/apm-to-chdk-camera-link-tutorial)
Would your script work with something like this?
I am very interested :) and do have the hardware to do the testing.Okay - game on.
So what do you want to be able to do from the ArduPilot Mega ? Can you program that end? Simply telling the CHDK script to shoot is easy. Shutdown mode too. What about switching to video and back on command? Or zoom in / out? All possible from the CHDK end but I can't really help you (much) with programming the ArduPilot Mega unless there is more documentation somewhere online.The setup outlined in the link I posted is designed to be used for aerial mapping. It would be great to use it in conjunction with your scripts ability to set the camera parameters for taking good photos from a moving object. Something that would be nice to add to your script, for this setup, would be to have it turn the camera off after a set number of photos are taken. This would cause the lens to retract and make for safer landings. There are probably more things to suggest, but I'm getting tired and my brain is getting fuzzy.
The setup outlined in the link I posted is designed to be used for aerial mapping. It would be great to use it in conjunction with your scripts ability to set the camera parameters for taking good photos from a moving object.There is a discussion about doing aerial mapping (with pictures at the end) in this forum thread : http://chdk.setepontos.com/index.php?topic=8984 (http://chdk.setepontos.com/index.php?topic=8984) . Most of the discussion is about getting the shot rate as fast as possible to provide maximum overlap in images. Unfortunately, the best way to do this is to lock exposure, zoom, and focus so that the camera can fire at its maximum rate.
Something that would be nice to add to your script, for this setup, would be to have it turn the camera off after a set number of photos are taken. This would cause the lens to retract and make for safer landings.Ummm ... you mean by using the existing script parameter settings to define the Total Shots and then selecting the Power off when done? option? :-[
There is a discussion about doing aerial mapping (with pictures at the end) in this forum thread : http://chdk.setepontos.com/index.php?topic=8984 (http://chdk.setepontos.com/index.php?topic=8984) . Most of the discussion is about getting the shot rate as fast as possible to provide maximum overlap in images. Unfortunately, the best way to do this is to lock exposure, zoom, and focus so that the camera can fire at its maximum rate.I'm not interested in getting as many shots as quick as possible. I would rather control where the pictures are taken and the quality of the pictures to make the whole system as efficient as possible, including post processing of the photos.
Ummm ... you mean by using the existing script parameter settings to define the Total Shots and then selecting the Power off when done? option? :-[:-[ uhh... yes that's exactly what I was suggesting, so would your script work, as it is, to have the APM trigger the camera and your script control the camera parameters? Would I set the shot interval to 0 so the shots are just triggered by the APM/USB?
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2Fyv5jkW7.png&hash=7ea363e0ed49626d9f49fbc1c9ae1503)
so would your script work, as it is, to have the APM trigger the camera and your script control the camera parameters? Would I set the shot interval to 0 so the shots are just triggered by the APM/USB?Maybe. It will depend on how the APM trigger was configured. If the trigger turns on the 5V USB signal and leaves it on when pictures are required, the script will happily shoot continuously if the shot interval is set to 0.
But if the APM simply pulses the USB signal for less that 500 mSec then the script might or might not take a picture after each pulse. And shorter pulse widths will be less likely to succeed.
It would be trivial to modify the script to handle the second scenario. I would also be easy to trigger a camera shutdown by using a longer pulse, as suggested in some of the documentation that you linked.
If I interpret this right, it looks like if you set the distance to 10 meters. Every time the vehicle reaches a 10 meter interval, calculated from GPS readings, a pulse that last 1/10th of a second is sent to the camera USB port via the A9 pin on the APM. If this is correct, could it be made to work as the triggering mechanism with your script?This is very close.
repeat wait_click(20) until ((get_usb_power(1) == 1) or ( is_key("menu")))Alternatively, you could change the value of CAM_DURATION to 600 and get the same result (albeit with a slightly slower average response speed).This is very close.Cool 8) thanks, I'll take a shot at modifying the script.
The current script (for no particular reason) only checks the USB status ever 1/2 second while waiting for it to activate. If you make a small edit to the script (line484) you can have it check every 20 mSec (with no ill effect) like this:Code: [Select]repeat wait_click(20) until ((get_usb_power(1) == 1) or ( is_key("menu")))Alternatively, you could change the value of CAM_DURATION to 600 and get the same result (albeit with a slightly slower average response speed).
Update : are you planning on a copter or plane approach? I think I found the source on that site, look at it now. Doesn't look like it supports a "shut down" pulse thoughRight now I'm using a copter, but plan on also using a plane down the road. A plane can stay aloft quite a bit longer on the same amount of power. Will your script still shut off the camera after the set number of photos is reached?
Cool 8) thanks, I'll take a shot at modifying the script.You also need to make the same change on line 383 of the 1.6 version of the script. Note that the script will wait for the first pulse to actually switch into shooting mode, extend the lens, and set the zoom position.
Right now I'm using a copter, but plan on also using a plane down the road. A plane can stay aloft quite a bit longer on the same amount of power.The only issue with using a plane then is the speed over the ground. The fastest the script can shoot will vary a bit from camera to camera but you can probably assume 3 seconds per shot for planning purposes.
Will your script still shut off the camera after the set number of photos is reached?Depending on how you configure it, it will either put the camera into playback mode (and thus withdraw the lens) or completely shut the camera down.
As much as I like this script, I cannot seem to be able to keep any settings changes...Nothing to do with the script itself, its an ongoing problem with the 1.3.0 version of CHDK.
When I switch the camera off (Canon A2500), all data is back to start...
A fix for this is in trunk autobuild 3392 and later. Let us know if the settings still aren't saving. There may be other issues involved.As much as I like this script, I cannot seem to be able to keep any settings changes...Nothing to do with the script itself, its an ongoing problem with the 1.3.0 version of CHDK.
When I switch the camera off (Canon A2500), all data is back to start...
http://chdk.setepontos.com/index.php?topic=6179.msg111409#msg111409 (http://chdk.setepontos.com/index.php?topic=6179.msg111409#msg111409)
I can't tell from the thread if its been totally resolved but you might want to grab the latest update from the autobuild server.
For script specific parameters (rather than CHDK settings), there are cases where they aren't saved correctly if you don't run the script between setting the parameters and rebooting.Feels good to know I'm not completely crazy ..
For script specific parameters (rather than CHDK settings), there are cases where they aren't saved correctly if you don't run the script between setting the parameters and rebooting.Feels good to know I'm not completely crazy ..
I have made some flights in the past days and it seems that around 50% of the pictures are not so sharp/clear.Looking at the images, can you decide if it's a focus issue or a shutter speed (motion) issue?
During my flights i have the parameter "focus at infinity mode - none" , to what value do you recommend to change it ?Using that parameter to set focus at infinity has a couple of advantage. First of all, the camera will not accidentally focus on the kite string. Secondly, to avoid issues if there is a lot of motion and it has trouble finding a focus point, setting at infinity is a safe setting. FInally, the camera will tend to cycle shots more quickly if it does not have to focus between shots.
I have made some flights in the past days and it seems that around 50% of the pictures are not so sharp/clear.Looking at the images, can you decide if it's a focus issue or a shutter speed (motion) issue?
QuoteDuring my flights i have the parameter "focus at infinity mode - none" , to what value do you recommend to change it ?Using that parameter to set focus at infinity has a couple of advantage. First of all, the camera will not accidentally focus on the kite string. Secondly, to avoid issues if there is a lot of motion and it has trouble finding a focus point, setting at infinity is a safe setting. FInally, the camera will tend to cycle shots more quickly if it does not have to focus between shots.
I'd recommend updating to the 2.2 version of the script - it has a much enhanced focus at infinity ability. It gets even better if you update to the current 1.3.0 version of CHDK. In either case, experiment on the ground with the different modes - some of them will not work with the stable version of CHDK (1.2.0). The 2.2 version of the script will warm you when that happens.
I do not have the proper "eyes" to see from where it could come the issue , maybe you can take a look, i have on the link below some pictures as example and the final result ( multiple pictures put together with Microsoft ICE). Please tell me your point of view.It would be better to post some examples of the "bad" images using the original file. This would give us the most chance of understanding the problem, and we wouldn't have to download the whole >100 meg zip.
I do not have the proper "eyes" to see from where it could come the issue , maybe you can take a look, i have on the link below some pictures as example and the final result ( multiple pictures put together with Microsoft ICE). Please tell me your point of view.Like reyalp suggests, this will be a lot easier if you would just attach two images here - one that you think is good and one that is bad. The composite image you posted dragged my machine to its knees for a couple of minutes.
It is working too well with v 1.6 to change it :) . I will do some more tests with this version and after this i will jump to v 2.2 .Good to hear. But as I said, the focus at infinity code is much improved in 2.2
I believe the following issue is purely KAP_UAV relatedActually, it's not. Both the 1.2, 1.6 and 2.2 versions of the script are just fine.
With the new version of KAP_UAV I have now the following msg :This tells me you are running the 3250 build of CHDK release 1.3.0. That's an older version of CHDK 1.3.0 released prior to the problems with saving script parameters and before the changes to SD overrides that the 2.2 version of kap_uav.lua needs when using CHDK 1.3.0
*** STARTED ***
KAP 2-2 started - Press Menu to exit
CHDK 1.3.0-3250 a2500 100a Nov 28 2013
CHDK 1.2.0 build 3276 or higher required
*** FINISHED ***
So my beloved kap_uav script is on strike.
Is CHDK 1.3.0 not higher than 1.2.0 ?This is probably why you are confused. The source code for all versions of CHDK are kept in same svn version control repository. When an change is made to any version, the revision number for the whole repository increments. So CHDK 1.3.0-3250 is actually older than CHDK 1.2.0-3275 in terms of what version of the code repository it was built from, even though it may contain changes and updates not found in CHDK 1.2.0-3275.
FYI, other scripts installed per default still work well (intervalometer, etc...)They will as long as they are not trying to use the new features of 1.3.0
*** UPDATEProving my point. kap_uav 1.2 does not use the new MF features of 1.3.0 and so does not need a recent version of 1.3.0 And the old version of 1.3.0 you are using did not have the problem with saving script parameters. (Incidentally, kap_uav 1.6 (https://app.box.com/s/4zne4yiytqv41flp44i7) is the most recent version that does not need an up-to-date 1.3.0 release)
I kept CHDK 1.3 but downgraded to KAP_UAV 1.2 and guess what ? It works fine but also saves the script parameters values !
From the images I could see - and I'm not a pixel peeper - the issue seems to be focus rather than motion blur. Unfortunately, Canon in its wisdom does not embed focus distance information in its exif data. Did you happen to enable logging in the script? Focus distance of each shot is recorded there.
This morning i have made some flights using v2.2 and settings at infinity mode @shot :According to your log, only a few of your shots were actually focused at infinity. Some are focused as close as .2 meters.
I observed on the log that I am using CHDK 1.2.0-3338 , this could affect somehow the "focus at infinity mode" performances?
This morning i have made some flights using v2.2 and settings at infinity mode @shot :According to your log, only a few of your shots were actually focused at infinity. Some are focused as close as .2 meters.
I observed on the log that I am using CHDK 1.2.0-3338 , this could affect somehow the "focus at infinity mode" performances?
And according to reported test results for the sx230, the @shot mode will not work.
Please try setting the "focus at infinity mode" to MF .
Update : IMG_4723 is marked as good while IMG_4724 is marked as bad. Both have their focus set at 3.2m. So something else is affected the image quality. But the focus setting is not helping. Unfortunately, none of the images in your sample set (good or bad) are focused at infinity.
Thanks for the advices I will do another flight with focus at infinity mode set to MF and come with the feedback.You might want to delete the log file from your SD card prior to the test. Each test adds to the previous one so it can get pretty big.
Thanks for the advices I will do another flight with focus at infinity mode set to MF and come with the feedback.You might want to delete the log file from your SD card prior to the test. Each test adds to the previous one so it can get pretty big.
The new log shows the camera going into AFL mode but the focus is not being set to infinity.Thanks for the advices I will do another flight with focus at infinity mode set to MF and come with the feedback.You might want to delete the log file from your SD card prior to the test. Each test adds to the previous one so it can get pretty big.
I have made an indoor test using MF but i have an error on the screen : 218: native calls disabled and the script stops.
Using AFL the script is running with no issues.
I have attached the last information from the KAP log.
Today i had the chance to do some flights with CHDK 1.3.0-3402 sx230hs , KAP v2.2 - i have tried MF also AFL modes. Looking at the KAP log it seems that during AFL the focus was set to infinity in the majority of cases while on MF only few times.Thanks for the log ! Seems to be related to stopping and restarting shooting via the USB signal.
I have noticed that , even if in the script the interval between pictures is set at 3 seconds, the pictures are captured at an interval of 2,3 or even 4 sec , what could cause this ?The script is only working in 1 second increments, so some variation around the interval setpoint is to be expected. I'll take a look at switching to milliseconds and see if I can get the interval to be more repeatable.
And last observation , majority of pictures were blurry. In the KAP log I saw almost all over the place : " actual: Tv:1/800" , also the sky was covered by clouds... Could I "force" somehow to have values for Tv around 1/1600 ?Blurry is not good. The script is doing what it can with the available light. Hoever, you have set the maximum ISO to 800 so it likely can't set the shutter speed much over 1/800 second and still get the correct exposure.
Update : v2.4 of the script now available for download - interval timing should be more precise
Attached the log after 3 flights done today with v2.4.The log showing taking 324 seconds to take 100 shots or about 3.2 seconds per shot (if my math is correct) and you asked for a 3 second shot rate. Pretty close. Just for fun, what does it look like if you ask for a 5 second shot rate?
I am using a low cost SD card, I suppose that the Write speed is not very high , maybe this could cause the issue regarding the interval between pictures ?That might make a small difference. I can't tell from the log - do you have RAW or DNG enabled? That would make a huge difference.
Attached the log after 3 flights done today with v2.4.The log showing taking 324 seconds to take 100 shots or about 3.2 seconds per shot (if my math is correct) and you asked for a 3 second shot rate. Pretty close. Just for fun, what does it look like if you ask for a 5 second shot rate?
That might make a small difference. I can't tell from the log - do you have RAW or DNG enabled? That would make a huge difference.RAW and DNG are not enabled.
Can you guide me to some instructions regarding the GPS goodies :) ?Sorry - don't have a camera with GPS so I've never looked at it. I'd be guessing, just like you.
The information regarding ISO are recorded for each picture in the log ?Yes.
Or , in another words, what is the meaning of the parameters from below ( eg. Sv) :Tv , Av, Sv are standard acronyms for Time Value (shutter speed). Aperature Value (f-stop), and Sensitivity Value (ISO setting).
2014May03 08:19:28 1) IMG_6422.JPG
2014May03 08:19:28 meter : Tv:1/160 Av:4.0 Sv:100 720:720
2014May03 08:19:29 actual: Tv:1/1600 Av:3.2 Sv:500
2014May03 08:19:29 AvMin:3.2 NDF:NDout foc:infinity
Today I have done 2 flights using the same value for shutter speed but using different values for ISO ( I am working to find the best camera settings).Your first flight had the ISO2 limit set to 800 while second flight had the ISO2 limit set to 200. This forced lower shutter speeds on the second flight and thus the blurring.
After the flights while looking at the pictures I observed that the pictures from the second flight are more blurry , the reason could be the weird value for shutter speed from the KAP log (the value is totally different from my settings, I have as target 1/1600 and the pictures are at 1/320 for example).
Is there any relation between ISO target values and Shutter speed target values (one of the parameters has "priority" comparing with the other one?).Full documentation here : http://chdk.wikia.com/wiki/KAP_UAV_Exposure_Control_Script#Calculation_Algorithm (http://chdk.wikia.com/wiki/KAP_UAV_Exposure_Control_Script#Calculation_Algorithm)
But I feel there is some strange behave and some point need improve.Okay .. let's take a look.
My camera is elph320 hs.Thanks for that. It would be good to know what version of CHDK you are using, and the version of the script.
TV min 640, target 1000, max 2000Looks pretty reasonable.
F min 2.8, target 4, max 8
ISO min 80 max1 400 max2 800
AFL mode
1. My flight was 300 meter high. Some picture are good, more are not good. Bad picture looks like has focus problem.Hmmm ... so most likely causes are either low shutter speed, bad focus, UAV vibration, or earthquakes.
My wing is kind of stable while flying, maybe bank and pitch in 5 degree. My camera is not in perfect status because was a hard crash before. But taking picture in the ground is normal.Sound like you should be okay then. Hard crashes really suck though - kind of like watching $100 bills burn in a bucket.
Is that possible camera focus ability has problem, maybe focus lock time is too long ? How to verified it ?The script locks the focus prior to the first shot. It should not change after that, so focus lock time or focus ability should be "all good" or "all bad". Unless the camera actually failed to lock focus that is. Need to see the script log.
How to verified it ?Let's start with the script log file? Please post it here.
That bank and pitch should not cause the problem right, because shutter was really fast at 1000.Shutter speed at 1/1000 is probably the minimum you want to use. Faster would be better.
2 USB control is really working great, but the problem is the time, when I trigger it, it took 6 second to be ready for another trigger, before that if you trigger it, it just been ignored. How can I improve it ? Because if I put intervalometer camera can the picture in 3 second fastest.The USB control mode was setup to start/stop intervalometer shooting when the USB power = 5V ( i.e. On). It was really not designed for single shot shooting via USB pulses. Obviously it could be changed to do that if necessary if you can't leave the USB on when you want the UAV to be shooting. The nice thing about the current setup is that it retracts the lens when USB power is absent. This slows down the cycle time but is a really nice thing to have prior to your UAV rejoining the ground.
I can not find anything strange in the log. but the picture some are bad and some are really good.Sorry. Maybe it's me, but none of these pictures look very good compared to many KAP and UAV pictures I've seen taken using CHDK with less expensive cameras.
https://plus.google.com/photos/105328353808607790727/albums/6011616743782592257
QuoteMy camera is elph320 hs.Thanks for that. It would be good to know what version of CHDK you are using, and the version of the script.
Quote1. My flight was 300 meter high. Some picture are good, more are not good. Bad picture looks like has focus problem.Hmmm ... so most likely causes are either low shutter speed, bad focus, UAV vibration, or earthquakes.
QuoteMy wing is kind of stable while flying, maybe bank and pitch in 5 degree. My camera is not in perfect status because was a hard crash before. But taking picture in the ground is normal.Sound like you should be okay then. Hard crashes really suck though - kind of like watching $100 bills burn in a bucket.
QuoteIs that possible camera focus ability has problem, maybe focus lock time is too long ? How to verified it ?The script locks the focus prior to the first shot. It should not change after that, so focus lock time or focus ability should be "all good" or "all bad". Unless the camera actually failed to lock focus that is. Need to see the script log.
QuoteHow to verified it ?Let's start with the script log file? Please post it here.
you are right, you can see in log, all are taken in 1/1000, no blur, just no focus.QuoteThat bank and pitch should not cause the problem right, because shutter was really fast at 1000.Shutter speed at 1/1000 is probably the minimum you want to use. Faster would be better.
[/quote]Quote2 USB control is really working great, but the problem is the time, when I trigger it, it took 6 second to be ready for another trigger, before that if you trigger it, it just been ignored. How can I improve it ? Because if I put intervalometer camera can the picture in 3 second fastest.The USB control mode was setup to start/stop intervalometer shooting when the USB power = 5V ( i.e. On). It was really not designed for single shot shooting via USB pulses. Obviously it could be changed to do that if necessary if you can't leave the USB on when you want the UAV to be shooting. The nice thing about the current setup is that it retracts the lens when USB power is absent. This slows down the cycle time but is a really nice thing to have prior to your UAV rejoining the ground.
I can not find anything strange in the log. but the picture some are bad and some are really good.Sorry. Maybe it's me, but none of these pictures look very good compared to many KAP and UAV pictures I've seen taken using CHDK with less expensive cameras.
https://plus.google.com/photos/105328353808607790727/albums/6011616743782592257
Picture 12 of 14 is particularly confusing ... there is a small section of forest in the center of the shot that seems clear but the rest of the image appears to be under a cloud or something ?
Maybe this is because these are downsized images? Can you post both a full size good & bad image to a file sharing site ( hint : box.com please - no spam or dancing balony) along with the image name/number from the log file? That would help a lot!
FWIW, the script seems to be performing well. The log shows shutter speeds at 1/1000 min - that's good. And the focus is reported as 'infinity" in all shots - also good.
ISO setting are fairly low. I suspect you could jack up the Tv target to 1/2000 safely.
Not sure what else to say here. I can't correlate the image names in the log ( IMG_1803.JPG ) to the images you kindly posted on plus.google.com.
it is great to know that still my picture are bad, because it means I can improve it. lololo...Downloading now .. my slow connection will take a few moments.
https://app.box.com/s/i0vi6x5m6zx56ipqnxky can you download the original pic with original name to have a review ?
Today was not a sunny day, but cloud is not so heavy. what I am thinking is that camera set to infinity, so that is really infinity, from which distance to infinity all are focus ?Everything from about 2 meters to infinity should be in focus - the depth of field on these little camera is amazing.
Update : not sure what to say here. The full size images are not "sharp". Far from it. And it does not look like a focus issue. You might try using the simple intervalometer script included with CHDK and set the camera into "Sports" mode with ISO force to 1600. Just to see what the camera can do on its own? Also, I'd be curious to see a picture taken on the ground under similar lighting conditions in Auto or P mode of the local landscape seen in these picture - with the center of the picture pointed off into the distance.
but one question, you can compare the picture, for example IMG1813, 1810. the detail of the red car, and the cow. still is not good ? but you can see, at least these few picture has more detail than the others. and why you say that it is not like a focus issue?IMG1810 is better than most of the images but the green colors on the ground look to be all smudged.
by the way, can you post some picture of your camera shoot point down from around 300 meter high? I really want to know how good and detail could a camera make it.I don't have any pictures of my own but these shots are what I was expecting to see : http://chdk.setepontos.com/index.php?topic=6118.msg91326#msg91326 (http://chdk.setepontos.com/index.php?topic=6118.msg91326#msg91326)
2 USB control is really working great, but the problem is the time, when I trigger it, it took 6 second to be ready for another trigger, before that if you trigger it, it just been ignored. How can I improve it ? Because if I put intervalometer camera can the picture in 3 second fastest.The USB control mode was setup to start/stop intervalometer shooting when the USB power = 5V ( i.e. On). It was really not designed for single shot shooting via USB pulses. Obviously it could be changed to do that if necessary if you can't leave the USB on when you want the UAV to be shooting. The nice thing about the current setup is that it retracts the lens when USB power is absent. This slows down the cycle time but is a really nice thing to have prior to your UAV rejoining the ground.
The USB control mode was setup to start/stop intervalometer shooting when the USB power = 5V ( i.e. On). It was really not designed for single shot shooting via USB pulses. Obviously it could be changed to do that if necessary if you can't leave the USB on when you want the UAV to be shooting. The nice thing about the current setup is that it retracts the lens when USB power is absent. This slows down the cycle time but is a really nice thing to have prior to your UAV rejoining the ground.
Hi Waterwingz, can you include a new feature into your script, let Gentled CHDK2 USB cable PWM signal trigger the camera to make a shoot? for that people can use control board to control shooting by fly distance. also control many shooting parameter during the fly.I'll take a look but I don't have any Gentled stuff so somebody will need to do the testing.
If it's possible it would be nice to have an improved version that works faster with the "usb control" because, as already reported after the "usb shot" the script shows the preview of the image (can not be disabled, or can not find how to do it) and to take the next shot it takes too many seconds, not usefull during flight with a plane for orthophoto.You need to disable the "preview" in the Canon menus. This is not something that CHDK controls. On every one of my cameras, you can adjust the time that the preview is displayed - including turning the feature off.
You need to disable the "preview" in the Canon menus. This is not something that CHDK controls. On every one of my cameras, you can adjust the time that the preview is displayed - including turning the feature off.
Meanwhile, when I look at the Gentled stuff (above), I'll also add a "single shot via USB mode" that should be a lot faster. The current code actually goes to playback mode between shots (to retract the lens in case you are landing) and this slows things down a lot.
The "preview" in the Canon menus is disabled. Same issue with Canon Ixus 140 and 125.It's because the camera goes into playback mode when USB is inactive (i.e. intervalometer off). When I add the "single shot under USB control" mode, you won't see that.
If you possible add an option to disable the preview or better some like "go to preview only if there's no usb command for x seconds", thanks!
Hi Waterwingz, can you include a new feature into your script, let Gentled CHDK2 USB cable PWM signal trigger the camera to make a shoot? for that people can use control board to control shooting by fly distance. also control many shooting parameter during the fly.What shooting parameters are you interesting in controlling mid-flight? Other than taking an actual photograph, what kind if things would you want to change during a flight? Zoom? Switch to video mode? Shoot in high speed burst mode (with exposure locked) ? Retract lens? Reformat the SD card?
Hi Waterwingz, can you include a new feature into your script, let Gentled CHDK2 USB cable PWM signal trigger the camera to make a shoot? for that people can use control board to control shooting by fly distance. also control many shooting parameter during the fly.I'll take a look but I don't have any Gentled stuff so somebody will need to do the testing.
Note that on some cameras, the USB pulse width timing is pretty inaccurate. This might need the new HP timer functions enabled.
I will test for you.Thanks. I now have all the code changes done to add the two new USB modes - single shot per USB pulse and Gentles pwm detection mode - in addition to the old mode of intervalometer while USB power is present. Not quite sure how to tell the lens to retract in single shot per USB pulse mode though.
I will test for you.
Nice, if you want i'm here for testing the "one shot usb" function with my two Ixus.Here you go. Beta release of version 2.5 of the kap_uav.lua script is here > kap_uav_2.5_beta.zip (https://app.box.com/s/bl00mviahfedwp81hqwp)
I have an IXUS 132 and do not appear to be able to lock the camera into infinite focus.What version of CHDK are you using ? (the full filename of the CHDK zip file you installed) And what version of the script?
I have tried AFL and @Shot & MF but it will continue to attempt to focus with the small blue square appearing on the screen.Did you disable the Canon ServoAF and ContinuousAF modes? Those modes will override the CHDK Subject Distance Override settings.
The log shows that it is not focused at infinity, but it does not give me any errors.Looking at the log, Canon auto-focus is probably focusing your pictures probably correctly though CHDK is unable to lock the focus (see previous comment).
In log file:I have an IXUS 132 and do not appear to be able to lock the camera into infinite focus.What version of CHDK are you using ? (the full filename of the CHDK zip file you installed) And what version of the script?
2014Jun21 16:53:43 KAP 2.4 started - press MENU to exit
2014Jun21 16:53:43 CHDK 1.3.0-3387 ixus132_elph115 100b Mar 17 2014
thanks ;)In log file:I have an IXUS 132 and do not appear to be able to lock the camera into infinite focus.What version of CHDK are you using ? (the full filename of the CHDK zip file you installed) And what version of the script?Code: [Select]2014Jun21 16:53:43 KAP 2.4 started - press MENU to exit
2014Jun21 16:53:43 CHDK 1.3.0-3387 ixus132_elph115 100b Mar 17 2014
I'd like to ask for camera and shot specific analysis help, as far as setting the mins and maxes and such, and I'm not sure if it's better to ask here or start a new thread in the general newb forum.Here works fine for me - and I suspect I'll be answering most of your questions. However, I'm travelling for the next couple of days on a photography trip somewhat at "the ends of the earth" so network connectivity might make my response time a little slow.
2014May23 10:51:00 Tv:1/1000 max:1/2000 min:10 ecomp:0.0You probably want to crank Tv max up. Way up.
2014May23 10:53:39 AvMin:3.2 NDF:NDin foc:0.9mThat's one problem. With MF Mode set to zero, the script will not attempt to lock focus at infinity for you and is doing its best to autofocus instead.
I think the "foc:0.9m" is my problem there.
My preferred method of messing with this kind of thing is to save my own edits as revs, for specific conditions. I'm thinking I could set "foc:infinity" in the script, and possibly Tv min:1/1000.You do all that with the setup parameters in the script menu. You can even save as many as 10 different combinations of parameters for later use. If you are not familiar with that, scroll down in the CHDK script menu - the kap_uav.lua script has a lot of things you can adjust to suit your application.
Happy to post the pics, but I didnt see many others doing that.We can cross that bridge when we come to it.
Regarding the shutter speed, the a495 specs show max shutter speed 1/2000. Will it make any difference to set it higher?It might, but it won't be a lot of difference. On the SX260, the shutter speed maxed out at about 1/3500. Anything faster didn't change the actual exposure of the picture.
Regarding the focal length and MF mode, what's the recommended setting?The ideal is to set it at the hyperfocal distance, which is as close as the camera will focus and still have infinity be in focus. That way pictures of ground objects will be sharper at low altitude.
Last, the three times I've been out, a set of two AA batteries has lasted about 30 minutes. Is this expected, because the script is using a lot of processing power? Or am I doing something wrong? I've used fairly new Eneloops, and brand new disposable Duracells.I would try AA lithium batteries. They're advertised to last 7 times longer, so they should last a few minutes longer, at least :) They are more expensive, though.
Try it and see. Just be sure to compare the actaul images rather than reported settings. Some cameras have been reported to go up over 1/5000. Unlike ISO and f-stops, this is one setting where CHDK can usually substantially extend the available range.Regarding the shutter speed, the a495 specs show max shutter speed 1/2000. Will it make any difference to set it higher?It might, but it won't be a lot of difference. On the SX260, the shutter speed maxed out at about 1/3500. Anything faster didn't change the actual exposure of the picture.
In practice, using hyperfocal distance rather than infinity does not produce any measurable difference in the resulting images with Canon P&S cameras. The lens depth of field is so high that it's not worth the effort to even try. So for the kap_uav.lua script, you can just have the script set the focus at infinity and be done with worrying about that.QuoteRegarding the focal length and MF mode, what's the recommended setting?The ideal is to set it at the hyperfocal distance, which is as close as the camera will focus and still have infinity be in focus. That way pictures of ground objects will be sharper at low altitude.
If you're setting it manually before starting the script, you could crank the focus up to infinity and then back off one notch. A script can find the hyperfocal distance and set it to that, if it has that feature.
Camera settings can change battery life quite a bit. But what you need to remember is that normally these cameras power off after 30 seconds if there is no activity, resulting on a perceived long battery life. With an intervalometer script, the camera processor never shuts down and draws power continuously. It's not a question of the script using a lot of processor power - it's just a question of not shutting down after a shot is taken. The display off settings in the script parameters can help as lapser noted.QuoteLast, the three times I've been out, a set of two AA batteries has lasted about 30 minutes. Is this expected, because the script is using a lot of processing power? Or am I doing something wrong? I've used fairly new Eneloops, and brand new disposable Duracells.I would try AA lithium batteries. They're advertised to last 7 times longer, so they should last a few minutes longer, at least :) They are more expensive, though.
There may be camera settings that are using a lot of power. Image stabilization might be using a lot of juice. You could try shutting it off and see if the pictures are still sharp. GPS also uses a lot of power, if the camera has it. Shutting the display off saves about 10 or 15% power use.
I will test for you.Thanks. I now have all the code changes done to add the two new USB modes - single shot per USB pulse and Gentles pwm detection mode - in addition to the old mode of intervalometer while USB power is present. Not quite sure how to tell the lens to retract in single shot per USB pulse mode though.
If I can find another hour today and my Arduino test rig will fire up and send precision pulses, I'll do some testing prior to sending you a new version.
I'm using a Elph 300 in a fixed wing for aerial mapping. I can't slow the plane down any more. The fastest I can get pictures are about 3.5 seconds apart. That just doesn't get enough overlap to build a map.That seems a bit slow but consistent with my results.Do you have "RAW/DNG" enabled? That will slow things down.
What are the best settings to achieve smallest shot interval, or is that just a limitation on the camera?That's a limit when you cycle through a complete "shooting" cycle. A fast Class 10 SD card can help a bit. After that you need a different script. Try these on the ground and see how fast you can get :
Also, is there a known canon point and shoot that takes that fastest pictures?I don't believe anyone has done a comparison across the brand.
What are the best settings to achieve smallest shot interval, or is that just a limitation on the camera?
That seems a bit slow but consistent with my results.Do you have "RAW/DNG" enabled? That will slow things down.+ 'review' should be off in the Canon menu + AFL or MF to eliminate refocusing
+ 'review' should be off in the Canon menu + AFL or MF to eliminate refocusingGood point on the "review".
Camera is ELPH300(IXUS 220HS) with 1.2.0-3418 CHDK.Personally, I only use the 1.3.0 version of CHDK. Despite the name, it has always been very stable for me. And it does a much better job of focusing at infinity on a lot more cameras that 1.2.0
1. What metering mode we should use in genarally? Does is make any difference for exposure or will chdk/KAP&UAV overdrive this setting anyway?The script uses whatever metering mode is set in the camera. It does not try to override it.
2. Not sure about what is possible with usb remote. Is it possible to do following at one flight:The latest version of the script has "place holders" where you can insert whatever code you want to run for any particular pulse width. Changing zoom position, starting and stopping video is all possible. Turning the camera off is possible as is stopping the script. But turning the camera on or starting the script is not possible.
a. turn camera and script running on/off?
b. Zoom in/out?
c. Change camera mode between video and script mode? Recording video on/off?
I can use Arduino to generate pulses, but not sure what are actually the limits and is possible.
@param e Exposure Comp (stops)Thanks - I'll fix that in the next update. As it stand, selecting the first 0.33 value will give you -1/3 stop ev comp, selecting the second 0.33 value gives you +1/3 stop ev comp. It's just the label that's wrong.
@default e 6
@values e -2.0 -1.66 -1.33 -1.0 -0.66 0.33 0.0 0.33 0.66 1.00 1.33 1.66 2.00 <--missing "-" for negative 0.33??
2. When using Video Interleave and Video Duration the camera stops responding after hitting Interrupt button, when camera is taking video. Have to take battery out to reset. Interrupt works if it is done during photo shoot.I'll look at that but it may not be something that I can fix.
Personally, I only use the 1.3.0 version of CHDK. Despite the name, it has always been very stable for me. And it does a much better job of focusing at infinity on a lot more cameras that 1.2.0I tried latest 1.3 but it hangs the camera if using Zoom position from script. It drives the zoom to correct position and then camera shuts down.
The latest version of the script has "place holders" where you can insert whatever code you want to run for any particular pulse width. Changing zoom position, starting and stopping video is all possible. Turning the camera off is possible as is stopping the script. But turning the camera on or starting the script is not possible.I'll check this out after i get my usb cable done.
2. When using Video Interleave and Video Duration the camera stops responding after hitting Interrupt button, when camera is taking video. Have to take battery out to reset. Interrupt works if it is done during photo shoot.
I'll look at that but it may not be something that I can fix.Ok. I tried more and found:
I tried latest 1.3 but it hangs the camera if using Zoom position from script. It drives the zoom to correct position and then camera shuts down.Strange. What setting are you using for Focus @ Infinity Mode ? What happens if you try None ? What if you try one of the other options ?
Ok. I tried more and found:Pressing the Menu key tells the script that you want it to shut down, so it gracefully stops whatever it's doing and exits. Pressing the shutter key actually abruptly halts the script in the middle of whatever it was doing - no graceful shutdown. This can be problematic if the script is currently recording in video mode. I don't know why but it is.
-Interrupt when recording Interleave video works ok if i hit MENU first and just after that "shoot" button. I've always started and stopped scripts just pressing Shoot button ::)
Another possible cause of the crash is that camera requires #define CAM_NEED_SET_ZOOM_DELAYI tried latest 1.3 but it hangs the camera if using Zoom position from script. It drives the zoom to correct position and then camera shuts down.Strange. What setting are you using for Focus @ Infinity Mode ? What happens if you try None ? What if you try one of the other options ?
Strange. What setting are you using for Focus @ Infinity Mode ? What happens if you try None ? What if you try one of the other options ?Seems to hang with every settings or at least i didn't find any of them to be much better or worse. Have to test more though.
Another possible cause of the crash is that camera requires #define CAM_NEED_SET_ZOOM_DELAYFw is 100C. This might be the problem or at least it is related. When camera hangs it first move the lens to correct position, then very quickly after that i hear low sound like one click and then immediately it shuts down.
@M141. What is the fw version of your camera?
Might be worth just doing some zoom testing. http://chdk.setepontos.com/index.php?topic=7071.msg76192#msg76192 (http://chdk.setepontos.com/index.php?topic=7071.msg76192#msg76192)I tried zoom test script and with chdk 1.3 camera always shut down between zoom set 2 and 3. Once it went up to 5 before hang. With chdk 1.2 camera runned zoom steps 1-64 up and down multiple times without any problem.
In attachment, a test version with: #define CAM_NEED_SET_ZOOM_DELAY 300I tried with this version and there was no difference vs original 1.3.
Please test it and report the results
Using v3.1 and have pushed shutter all the way up to 1/1600 and still have blurring on the 3rd or 4th image and the next is crisp.1/1600 is not really all that high - but it's a lot better than 1/100 !
Implementing all the changes you noted and will test/fly tomorrow.You might want to do some testing prior to flying? Place the camera on a tripod and take some pictures where you have objects distributed between short, medium and long range. Taking a picture down the lenght of a fence is a good example. Then let the script run a couple of time, taking two or three picutred each run. Check the pictures carefully on your PC to determine where the camera was focused.
Implementing all the changes you noted and will test/fly tomorrow.Just select the scenery focus setting in the Canon and let the Canon autofocus try to do its job.
I don't know - I'll have to download the sx260 manual and take a look tonight. Looking at the log, the camera "thinks" that it's focussed at infinity.Just select the scenery focus setting in the Canon and let the Canon autofocus try to do its job.How is this set on the sx260?
How do you disable the following:From what you posted below, it looks like you now have done that. They show up in the log file that way too. Although I see you are now using "M" mode - I think that should be okay.
Mode:PLAY,Continuous_AF:1,Servo_AF:1
Is there a way to dump the settings, both KAP_UAV settings and camera setting to a file?The kap.log file already has that for the things it cares about.
Here is the link to the images shot this AM, and similar results.Thanks - won't bet able to download until tonight. The exposure settings in the log look strange - it will be interesting to see the actual pictures.
https://www.dropbox.com/s/uok9081z8xiwdwc/140718_DCIM-1.zip (https://www.dropbox.com/s/uok9081z8xiwdwc/140718_DCIM-1.zip)
Current camera AF settings;The kap.log file show these as being disable too - that's good.
...
Servo AF - off
Continuous AF - off
...
IS Settings/Modes - offYou probably want to leave the IS (image stabilization) modes enabled.
IS Settings/Modes - offYou probably want to leave the IS (image stabilization) modes enabled.
Update : I'm afraid that I'm getting a really bad sense of deja vu here.
The best focus of all your pictures (e.g. IMG_3218.JPG) are the ones taken of the pavement, inches away, when your UAV is on the ground ! Yet kap.log file says the camera is focussed at infinity and the Canon Maker Notes information in the image file report subject distance as 6553 (which I believe is 655 meters). And while many of the aerial shots are quite good, at least 3/4 of them are whacked. Again, the image maker note data all shows 6553.
I guess we have to add the sx260 to the S100 and ixus125 as cameras that refuse to set_focus as requested by the script. We really need to find a way to solve this.
I have a set completed with MaxISO2 at 1/1600 as it does not got to 3200 and F/5.0 with pretty much same results. Those images I have not uploaded though.Yea - it's a focus issue rather than shutter speed I'm afraid.
I am going to do another flight now, with the Min Fstop at 4.0. Any other thoughts/suggestions/recommendations?Leave the "Focus @ Infinity Mode" option at "None" and let the camera fend for itself ? Or take a look at pages 125 & 126 of the manual for your camera : http://gdlp01.c-wss.com/gds/7/0300007147/01/pssx260hs-sx240hs-cug-c-en.pdf (http://gdlp01.c-wss.com/gds/7/0300007147/01/pssx260hs-sx240hs-cug-c-en.pdf) and put the camera into native MF mode, set at infinity. (leaving the CHDK option at "none")
After the above flight, I am going to remount the camera with more vib dampening to see what the impact is if the results do not improve.Can't hurt but I don't think it's the root cause of the issues.
Crazy thing is, I can not believe I am the only one who has had this challenge, yet, it's all good.Thanks for keeping your "chin up" on this. It's most frustrating. And you are not the only one - an S100 owner and ixus125 owner have discovered the same thing. Still, over 1250 people have downloaded the script but no telling how many have actually tried it. I'll bet there are only a few camera models that have this issue.
Attached is the log.I'd be curious to see a log & pixs where you set the camera to "P" mode rather than "M". Page 115 of your user manual.
Will have the images uploaded shortly.
The one change in this flight was to set f/4.0, and still in manual on the camera and script.
Will make the changes you noted and test it now.
Hi!
Waterwiz, the script is working as it should and its very nice. I tested it these days and the speed right now is amazing and I learned that my only limitation with this camera is the battery. Sometimes I get the same GPS coordinates for 2 pictures in sequence, but then I manually edit the coordinate so the orthoretification software doesn't get confused.
The attachment is just a test. :)
Anyway, thanks again both of you, waterwiz and lapser, you really have helped me a lot here!
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fimg23.imageshack.us%2Fimg23%2F8829%2Fflorestav.jpg&hash=09872ccca06883bc667857b2756f50c2)
I inquired on this post as well. It's been done, need to figure out how.Unfortunately, it seems most people join this forum but either don't supply an email address or don't have responses to threads they've posted in setup to notify them via email. So alkasber will likely never be heard from.
Check out the ground pic's and what are your thoughts on the focus.Okay - explain to me your exact settings for this last sequence. I notice you still have the shooting mode in "M" rather than "P". And it looks like you set the camera into Manual Focus mode with the focus locked at infinity? If so, then why are the pics of the pavement so perfectly in focus when the camera is inches away. This is not making sense.
We could try something else basic here. Using just the Canon menus (no CHDK yet), put the camera in Tv priority mode (pg 140 in the manual), set the shutter speed as high as it will go, select Canon Manual Focus mode and lock that at infinity (pg 125-126), and then just run the simple interval.lua script that comes with CHDK ( in the A/CHDK/SCRIPTS folder).
Make sure you have set Enhanced Photo Operations -> Disable Overrides [ Yes ]
Is there a script that will read all the camera settings, chdk settings and dump it to a file?No.
Settings;I've assumed you are somewhere in the western USA by the previous pictures but these pix are all really dark - and you'd have to be about 500 miles east of Boston to be that dark right now.
TV mode
Shutter: 1/3200
Focus: camera manual/infinity
Script: interval.bas
Disable Overrides: YES
Images are uploading, set ISO to auto, lighting is better, and not great.Those don't look too bad for ISO3200. Could try dialing the Tv value back to 1/1000 and trying again tomorrow in normal day light.
Those don't look too bad for ISO3200. Could try dialing the Tv value back to 1/1000 and trying again tomorrow in normal day light.Will give this a shot in the AM and check the results.
I did note that the Maker Note data say Subj Dist 6553 for every shot still - even though it is clearly auto focusing at different distances in these shots.The flight altitude is set at 100 meters so, not sure what the Subj Dist value of 6553 is though.
The flight altitude is set at 100 meters so, not sure what the Subj Dist value of 6553 is though.6553 means 65535 millimeters - (also -1 in binary) - and is supposed to represent infinity to the camera.
Hi timvand,
On the link below there are the parameters used by me on a Canon SX230 (starting with page 13):
http://www.myap.ro/wp-content/uploads/2014/07/Gluonpilot-photomapping-setup-v1.31.pdf (http://www.myap.ro/wp-content/uploads/2014/07/Gluonpilot-photomapping-setup-v1.31.pdf)
What flying platform you use ? The cruise speed is a very important parameter to obtain good pictures.
Thanks I will re-review these settings after I do a quick test of the settings from WW suggested yesterday. One way or the other, I WILL, with the assistance from others, get this to work.I've been communicating with zeno (dave mitchell) who has an s100 - one of the cameras that also won't focus at infinity - and he is using the kap_uav.lua script successfully. He even sent me a link to some great shots he took in Italy. One difference is that he sets the Focus @ Infinity Mode to None and lets the camera's AF take over - which would explain why he is not having problems. That's basically what I've been working you towards with my instructions from last night - use Tv mode with a 1/1000 shutter speed, set the Canon MF to infinity, and then let a simple intervalometer script run.
Thanks I will re-review these settings after I do a quick test of the settings from WW suggested yesterday. One way or the other, I WILL, with the assistance from others, get this to work.I've been communicating with zeno (dave mitchell) who has an s100 - one of the cameras that also won't focus at infinity - and he is using the kap_uav.lua script successfully. He even sent me a link to some great shots he took in Italy. One difference is that he sets the Focus @ Infinity Mode to None and lets the camera's AF take over - which would explain why he is not having problems. That's basically what I've been working you towards with my instructions from last night - use Tv mode with a 1/1000 shutter speed, set the Canon MF to infinity, and then let a simple intervalometer script run.
Could try dialing the Tv value back to 1/1000 and trying again tomorrow in normal day light.
Hi taking this conversation from Facebook to here for the convenience of attaching files.Looking at the log, the script takes each shot at the almost the same exposure setting - gradually increasing the ISO as the scene darkens towards the end. I should not have been flickering like that.
Sure.These look to have been post processed? Do you have the originals from straight out of the camera?
I will try to do a test in the next few day, with servo_AF off, ND filter off, 5 seconds, and infinity focus to off and see how that comes out.Thanks - you probably only need 20 or so shots to see what helps.
I did another test with v3.3. With this one the ND Filter was in use and focus was set to MF, started off with 150 images as a 5sec interval, followed by 150 at 4sec, then 150 at 3sec and finishing off at 150 as 2sec interval.This is quite interesting. The random jumps in exposure are all gone. However, the script did not attempt to use the ND filter - probably because the shots were later in the day and the scene darker so it did not need to use it. I'm thinking I need to do more testing of the ND filter use.
Other than underexposing at the shorter interval (but that could be in part due to the conditions) the exposures seem fairly consistent.You are seeing the "filter factor" at work there. The filtering is so high that the exposure changes lag the actual scene illumination changes as evening approaches. I have an improve version of the filter I'm working on to remove a small offset error at high filter factors. But you will probably want to Medium or even Low settings for the filter factor in any case based on what I see here.
In spite of script set to MF it appears to change from shot to shot. I am assuming some of my focus issues have to do with the camera itself and how it reacts to the script. Could this me a case of not the right tool for the job? Has there been anyone who had done a fair amount of timelapse with the S series camera (S90,S100,S110,S120) since they do have manual focus?There have been many thousands of CHDK timelapses with all kinds of cameras. I personally have used my G, S, IXUS, A and SX series cameras. However, the vast majority of all those sessions have been with the camera in autofocus mode or with a simple AFL set at the start of the script. On many of those cameras, up until recently, the AFL really did nothing.
Did another test today on a Canon Elph300HS with CHDK 1.3 and KAP & UAV Exposure Control Script v3.3MFThanks Mark! Log looks good based on a quick scan. I'll take a more detailed look later today.
I use the CHDK 1.2.0 (full).That should be okay but using CHDK 1.3.0 might be something to try instead.
After a random number of pictures taken by the script : it crash !Please post the actual ROMLOG.LOG file. It would also be good to get a copy of the script's log file.
I have the following indication in the file "crash.log" : !!!WatchDog expired!!!
Did another test today on a Canon Elph300HS with CHDK 1.3 and KAP & UAV Exposure Control Script v3.3MF
Here is another test shot on a Canon Elph300HS with CHDK 1.3 and KAP & UAV Exposure Control Script v3.3MF@MarkB : I find myself wishing that I had setup the script log file to put the data about each shot on a single tab delimited line. Importing that into a spreadsheet for analysis would be a breeze. Things like comparing the time interval between each shot to try and understand the speed changes in your videos would be trivial.
That should be okay but using CHDK 1.3.0 might be something to try instead.
Decided to try another test. The settings this time: ND Filter was in use, focus was set to AFL, images taken at a 3sec interval, and meter filter factor was set to low. The time interval also doesn't seem consistent as can be seen with the speeding up or slowing down of action in the video.I'm travelling this week but I finished the little script that converts the log files into something I can easily analyze in a spreadsheet. I'll look at timing first.
Decided to try another test. The settings this time: ND Filter was in use, focus was set to AFL, images taken at a 3sec interval, and meter filter factor was set to low. The time interval also doesn't seem consistent as can be seen with the speeding up or slowing down of action in the video.Had a quick look at this on the plane today and it's quite interesting. Here's a couple of plots from your log files - the shot number is on the X axis and the number of seconds between shots is the Y axis (one was the 3 second per shot log, the other the 5 second per shot log)
Had a major error and the sequence stopped early. See error at the end of the log. Though this might have to do that I was saving RAW files by accident and the 16g card ran out of memory,The error occurred because the camera stopped being ready to shoot within 2 seconds after a half-press. Once it got into that mode, it appears to have become stuck in that mode. I don't see anything in the log that might have caused that - the scene illumination had not shifted much.
Did another test befor and after sunset with filter factor set to medium. Lots of flickering and the change in speed.No lockup reported in the log like the one we saw in series 7. The same time sequence thing is happening though :
One note, I set this for 3000 images and it stopped before that. I wasn't home so don't know if there was an error message. The camera was powered off and the lens was still extended. Hit the power to turn it back on then off again to retract the lens.
I didn't keep any of the RAW files but I do have the jpeg's from test 7, I also have the jpeg's from test 8. I only had RAW files saved for the one test and none of the others. Just lest me know which jpeg's you would like to see.JPG will be all I need. I'll let you know.
I would be happy to test a simplified intervalometer script that just shoots every 4 seconds in AUTO mode and that also logs to the SD card, is there one you suggest? As a note I usually shoot in program mode, would that affect the results in any way?Program mode is fine. Attached is a stripped down script that lets the camera control the focus and exposure and logs every shot. Let's see if it slows down every 300 pictures or so as well? It's possible that opening and closing the log file for each log line is causing part of the problem.
For fun I did a test with the AUTOEXP3 script yesterday set at a shot every 3 seconds. It seems to hold the 3 seconds.Does the exposure not seem to flicker here too? Looks a bit like that to me.
For fun I did a test with the AUTOEXP3 script yesterday set at a shot every 3 seconds. It seems to hold the 3 seconds.Does the exposure not seem to flicker here too? Looks a bit like that to me.
Another test this weekend with the latest TLAPTEST script/ Some flicker and slow down and speed up.I'll take a look tonight. Meanwhile, can you try the same sequence but with all logging disabled? ( set the Logging parameter to "none").
-- Video mode
function check_video(shot)
local capture_mode
if ((video_mode>0) and(shot>0) and (shot%video_mode == 0)) then
unlock_focus()
sleep(500)
focus_mode = 2 -- Change focus mode to AFL @ Infinity??
lock_focus()
printf("Video mode started. Button:"..tostring(video_button))printf("Video mode finished.")
sleep(1000)
unlock_focus()
focus_mode = 0 --mode back to 0 (None)
sleep(500)
lock_focus()
return(true)
else
return(false)
end
endAnother test this weekend with the latest TLAPTEST script/ Some flicker and slow down and speed up.Interesting result!
When using " video interleave" mode i like to set focus mode to AFL@Infinity with video. I'm shooting with IXUS 300ELPH and it sucks with autofocus in video. For pictures i'm using setting "none" with good results. So maybe this script should have separate parameter for video and picture focus?I don't have a lot of experience with trying to use manual focus with video (although I have a little experience with MF and regular shooting) so I'm not prepared to try this right now. But the nice part about CHDK scripts is that you can edit and modify to suit your needs and desires.
So far i simply tried to force focus mode to AFL everytime video is recorded. It seems to work ok with chdk 1.2 but not with chdk 1.3? With 1.3 it seems to lock focus everytime very near like <2.5m:You now have my full and undivided attention. Would you mind enabling logging in the script parameter in the CHDK Script menu and run the test with both 1.2.0 and 1.3.0 and post the logs here?
On quick inspection, this looks okay. Nice hack!Code: [Select]-- Video mode
function check_video(shot)
local capture_mode
if ((video_mode>0) and(shot>0) and (shot%video_mode == 0)) then
unlock_focus()
sleep(500)
focus_mode = 2 -- Change focus mode to AFL @ Infinity??
lock_focus()
printf("Video mode started. Button:"..tostring(video_button))
......
printf("Video mode finished.")
sleep(1000)
unlock_focus()
focus_mode = 0 --mode back to 0 (None)
sleep(500)
lock_focus()
return(true)
else
return(false)
end
end
By the way is there any good editor that is made specially for scripts?Any programming editor that supports syntax highlighting for Lua will work. For Windows I'd suggest notepad++ although there are a raft of others.
The frequency of the slow downs has stayed the same in every test (approximately every 150 images) regardless of shot frequency or # of writes. However, it seems that once it slows down, decreasing the number of log writes per picture makes a big difference in the delay - 12 seconds down to about 5. Which I think makes sense as you are writing once instead of four times while the card is running slow.Are all these tests being done with the same card? If so, it would be every interesting to know what brand / size / model it is, and if different brands show the same behavior. Apologies if this was mentioned earlier, I skimmed the last few posts but I haven't been following closely.
Are all these tests being done with the same card?MarkB has told me that he has CHDK loaded on a Patriot LX series 16GB Class 10 card that he has been using for the tests. He also has a Lexar Platinum II 16GB 200x Class 10 and a Kingston 16GB Class 10 but has not tried those.
Apologies if this was mentioned earlier, I skimmed the last few posts but I haven't been following closely.I try to keep most discussion out of PM's but this one has been a little busy and has gone both ways.
You now have my full and undivided attention. Would you mind enabling logging in the script parameter in the CHDK Script menu and run the test with both 1.2.0 and 1.3.0 and post the logs here?Sure! I already had enabled logging and posting 2 logs. 120 log is from flight few days ago and pics + video seems to be ok.
-- Video mode
function check_video(shot)
local capture_mode
if ((video_mode>0) and(shot>0) and (shot%video_mode == 0)) then
unlock_focus()
sleep(500)
press("shoot_half")
sleep(2000)
click("left")
sleep(500)
release("shoot_half")
printf("Video mode started. Button:"..tostring(video_button))For Windows I'd suggest notepad++ although there are a raft of others.Downloaded and it's great. Earlier i was using PSPad and noticed i somehow had 5-6 years old version of it ::) Now it's updated but i think Notepad++ is still better...
I recently sent our s100 for repair and when it came back the images captured using the script were extremely blurry yet when the same parameters are used just taking a picture manually (1/1600 tv; ~3.5av; ~200 ISO all at infinity) the images are crystal clear.Do I understand that your S100 would focus properly with the kap_uav.lua script prior to sending it for repair but not after it was returned? (Or had you not tested it prior to having it fixed?)
When talking to the manager he mentioned that if a camera is sent to canon for repair they will automatically install the latest firmware even if that model (s100) has been discontinued...could this have any effect on the inability of the camera to focus using the script?No. If they had upgraded the firmware, you would need a whole new version of CHDK installed for that firmware. The old one simply would not work.
I have another s100 with an IR lens that I swap the sd card with that uses the script with no issues but for some reason I can't get the newly repaired camera to work with the script...So does the IR converted camera focus properly? (How do you know if you are using it for IR ?)
am I missing something extremely obvious?Just the sight of me slitting my wrists in frustration over this problem.
...which has been an absolute lifesaver for us btw...if you have any ideas I would really appreciate the help seeing as we will start combining the fields soon and will start losing opportunities to fly our fields.Well, I'm still working the issue. I have a theory that in auto focus mode some cameras focus well based on feedback control but they will not set a manual focus accurately due to calibration issues. Just a theory at the moment - I'm using a test script with my cameras to compare lens mechanical posting and subject distance as reported by the camera to try and track this down.
5. I just tried the camera in the kitchen without infinity and the images did seem to be a little better...does this mean I should take the camera out of 'M' mode and run it in something else or would this not make a difference?Leaving it in 'M' mode is fine - the script overrides all the M settings anyway. What you want to try is setting the script parameter that says Focus @ Infinity Mode to None. That will let the S100 autofocus and hopefully do a better job that the script can when it requests "infinity" and doesn't get it with the S100.
I/we really appreciate the help and can't say enough how much this script has helped us...especially when using IR in changing light conditions, the previous stitched images had basically zero value for us when having to do multiple flights to capture a field so thank you for making me look much better at my job than I really am.Thanks. Always good to meet yet another member of the growing group of kap & uav users who have discovered the value and power of scripts written in Lua.
@MarkB : modified version of latest test script that let's you disable all logging to the SD card. Please do another time lapse run and see if the speed up / slow down goes away completely?Another test this weekend with the latest TLAPTEST script/ Some flicker and slow down and speed up.I'll take a look tonight. Meanwhile, can you try the same sequence but with all logging disabled? ( set the Logging parameter to "none"). It will be interesting to see if all the speed changes go away
But i need a little help. I use a UAV to shoot vertical photos every 3s (Photogrammetry), i always use AUTO and it works very very well when is sunny. The problem is when its alot cloudy i get everything blurry and unfocus, already tried to play with the iso's an shutter speed but still cant find a good solutionAre you letting the script control exposure or relying on the camera?
Can anyway give me some advice on what should i use?
So i should use minimum shutter between 1/500 or 1/1000 and iso above 100 but below 1000. Correct?Start with 1/1000 and let the max ISO1 be 800 and max ISO2 be 1600 and see how it looks ?
And should i use this setup for sunny days and cloudy days? And the F-Stop? low = 2.8, target = 4.0, max = 8.0?I'm travelling this week so doing this all from memory via a mobile phone. Does your camera actually even have a user adjustable aperture? If not, the script will just ignore those settings.
And btw in the Focus @ infinity mode i choose the none option, right?If it works for you (and it does for most people) then the setting focus at infinity to MF is probably best. Gives the camera one less thing to do between shots.
So i should use minimum shutter between 1/500 or 1/1000 and iso above 100 but below 1000. Correct?Start with 1/1000 and let the max ISO1 be 800 and max ISO2 be 1600 and see how it looks ?
QuoteAnd should i use this setup for sunny days and cloudy days? And the F-Stop? low = 2.8, target = 4.0, max = 8.0?I'm travelling this week so doing this all from memory via a mobile phone. Does your camera actually even have a user adjustable aperture? If not, the script will just ignore those settings.
QuoteAnd btw in the Focus @ infinity mode i choose the none option, right?If it works for you (and it does for most people) then the setting focus at infinity to MF is probably best. Gives the camera one less thing to do between shots.
Update : one of the common causes of blurr is vibrations on the UAV platform. You have some good pix so that's probably not an issue. Also, it seems that turning off image stablization (if your camera allows that) is may actually a good idea - YMMV.
Every time i put 3s interval photo the script dont use it, sometimes use 2s interval, and in the next point use 5s or 4s. Totally random. Is this a bug or what? WierdYou may be running into a limit on how fast the camera can shoot. Three seconds per shoot using standard shooting methods is pretty much the limit for most small P&S cameras. Because of this you will see shots at 2,3 and 4 seconds. Try setting the shoot time to four seconds and see if things settle down?
The problem is if i use the intervalometer default script it works in 3s, it even work in 2s timer.Understood. But humor me and let me know what happens when your run kap_uav with a four second interval ?
My apologies for taking so long.No worries - I know how that goes. And I'll apologize for the late response by me too.
I used the same SD card I had been using for all the previous test. In the video there does not seem to be the time shift I have been previously experiencing. Unfortunately it was a cloudless sky and the clouds moving was the easiest way to see the shift in the interval time, but the shadows moving and the traffic seems to be consistent.I think the pretty much demonstrates that when the log file is "flogging" the SD card with log messages, in addition to the actual image data being stored, every 4 seconds, then the SD card bogs down. I'll look at doing a "delayed write" log file that only updates every so often - or maybe after shooting has completed. The issue there is making sure people shut the script down cleanly so that the log file has time to be written.
There is some flicker in the exposure. It is not the huge jumps I have seen in some of my other attempts but still there. This might be down to the limitations of the camera since it is one without an iris in the lens so if there is any breathing in the focusIn these later tests (unlike kap_uav.lua which tries for the highest shutter speed at reasonable ISO) the camera exposure is running in full "AUTO" mode. Nothing to do with the script. The flashing seems to be some sort of artifact of the camera AE operation - either it is not responding to legitimate exposure changes very well or the scene is actually changing like that as clouds roll over.
The problem is if i use the intervalometer default script it works in 3s, it even work in 2s timer.Understood. But humor me and let me know what happens when your run kap_uav with a four second interval ?
So i tried with 4s, 3s and 2s. And the results were always the same, very very random between 5s to 6s.I should have asked this right away. Do you have RAW or DNG enabled?
The weird thing is that between shots the real time don't look that big. I'm using the default parameters in the KAP Script.
I should have asked this right away. Do you have RAW or DNG enabled?
Gonna remove the script and reinstall it again.That does not really reset everything. You also need to click on "Load default param values" in the CHDK Script menu.
I'm trying to get this to work with a gentwire using PWM. So far using the defaults It will turn off, turn on, and take a picture. I was wondering if anyone made a script that would allow for off, turn on, and take pictures at an interval until turned PWM turned it to one of the other two modes.Hi Jim. You are the first person to report using the gentwire device and it's good to hear it's working. I added that code without the ability to really test it with an actual gentwire module ( I used an arduino board to generate the pulses for testing ).
Any recommendations?Asking for camera recommendation on this forum is often a good idea. However, most of the people who post here usually only have experience with one or two models (the one they happen to own and use) so most of the advice you will receive is basically opinions.
Culd you post your setup with the s100?Shot Interval (sec) [ 3 ]
Culd you post your setup with the s100?Shot Interval (sec) [ 3 ]
Total Shots (0=infinite) [ 0 ]
Power off when done? [ ]
Exposure Comp (stops) [ 0 ]
Tv Min (sec) [ 1/200 ]
Target Tv (sec) [ 1/1000 ]
Tv Max (sec) [ 1/5000 ]
Av Low(f-stop) [ 2.0 ]
Av Target (f-stop) [ 4.0 ]
Av Max (f-stop) [ 8.0 ]
ISO Min [ 80 ]
ISO Max1 [ 400 ]
ISO Max2 [ 1600 ]
Meter Filter Factor? [ Off ]
Allow use of ND filter? [ Yes ]
Zoom position [ 0% ]
Focus @ Infinity Mode [ MF ]
Video Interleave (shots) [ Off ]
Video Duration (sec) [ 0 ]
USB Shot Control? [ None ]
Backlight Off? [ * ]
Logging [ Both ]
Love you :-*Umm ... let's not get too carried away here. Those are sample values that should be useful. As you start using the script you will probably want to tune for your own use.
Thanks waterwingz =)
]Which one is the diference between the AFL and MF? what i need to do if i choose one of them to put them to infinity?There are two methods that Canon cameras will accept to disable auto focus and allow manual focus. These are AFL (for auto focus lock) and MF (for manual focus). For most cameras, either method will work. For some only one or the other works. The script allows you to pick which one you would like used - typically AFL will work fine for almost every camera. If it does not work for yours, try MF.
For example with the AFL: i start the cammera pointing to something really far (infinity) but how i focus that object in the infinity? and when is focused i start the script so i start to take photos. is it correct?Not correct. The script will put the camera into AFL mode and then set the focus distance at infinity. You do not need to point the camera at anything (near or far) for this to happen. Same thing for MF mode.
and other question, in which option needs to be the cammera? Auto, P, Tv, Av??The script will override all exposure and focus values so it should not matter. However, in general, P mode is usually the least likely to cause problems.
]Which one is the diference between the AFL and MF? what i need to do if i choose one of them to put them to infinity?There are two methods that Canon cameras will accept to disable auto focus and allow manual focus. These are AFL (for auto focus lock) and MF (for manual focus). For most cameras, either method will work. For some only one or the other works. The script allows you to pick which one you would like used - typically AFL will work fine for almost every camera. If it does not work for yours, try MF.QuoteFor example with the AFL: i start the cammera pointing to something really far (infinity) but how i focus that object in the infinity? and when is focused i start the script so i start to take photos. is it correct?Not correct. The script will put the camera into AFL mode and then set the focus distance at infinity. You do not need to point the camera at anything (near or far) for this to happen. Same thing for MF mode.Quoteand other question, in which option needs to be the cammera? Auto, P, Tv, Av??The script will override all exposure and focus values so it should not matter. However, in general, P mode is usually the least likely to cause problems.
I have the s100,you told me you have the mf, but i really dont know the difference. Which one do you recommend me? I am a bit noob but i learn very fast heheEither will work. Use MF if you want me to make the decision for you.
Another thing, you are saying that the P is the best one? I tried a couple of photos moving my cammera with my hand (trying to simulate the flight with my drone) but the phottos were a bit moved (blurry)That will depend on what Tv settings you are using (shutter speed) and how fast yoou moved the camera. Nothing to do with the script - it's simple physics.
I have the s100,you told me you have the mf, but i really dont know the difference. Which one do you recommend me? I am a bit noob but i learn very fast heheEither will work. Use MF if you want me to make the decision for you.QuoteAnother thing, you are saying that the P is the best one? I tried a couple of photos moving my cammera with my hand (trying to simulate the flight with my drone) but the phottos were a bit moved (blurry)That will depend on what Tv settings you are using (shutter speed) and how fast yoou moved the camera. Nothing to do with the script - it's simple physics.
Ok, i didnt changed the defaults settings. But i will try it in the air instead with my hand hahaha and i hope the results will be better.I'd suggest starting with the ones I posted earlier in this thread. < link > (http://chdk.setepontos.com/index.php?topic=10822.msg119218#msg119218)
Just changued the settings. :-*Ok, i didnt changed the defaults settings. But i will try it in the air instead with my hand hahaha and i hope the results will be better.I'd suggest starting with the ones I posted earlier in this thread. < link > (http://chdk.setepontos.com/index.php?topic=10822.msg119218#msg119218)
What i need to do if they continue dark with natural light?You need to look at the exposure values that the script used ( Tv, Av, Sv ) and determine if any of them are at the limit values set in the parameters for the script.
What i need to do if they continue dark with natural light?You need to look at the exposure values that the script used ( Tv, Av, Sv ) and determine if any of them are at the limit values set in the parameters for the script.
My question would be: For the RC PWM control what kind of cable do I need?gentWIRE-USB
I would prefer to use all 6 options. Also where should I set my "don't do anything PWM"?I understand the "6 options" part. But what do you mean by "don't do anything PWM"?
I have a gentWIRE-USB which converts the PWM to Pulses for the script below but using that wire I was getting random actions and many errors in-between .What camera are you using? After a lot of fussing and worry last year, it turned out that some cameras are have better accuracy measuring PWM data (in shooting mode) than others. I emailed with George at Gentles and he indicated not having run into this problem but my testing leads me to believe it will happen.
set_remote_timing 1000
while 1
do
k = get_usb_power
until k>0
if k < 5 then gosub "ch1up"
if k > 4 and k < 8 then gosub "ch1mid"
if k > 7 and k < 11 then gosub "ch1down"
if k > 10 and k < 14 then gosub "ch2up"
if k > 13 and k < 17 then gosub "ch2mid"
if k > 16 and k < 20 then gosub "ch2down"
if k > 19 then print "error"
wendHello waterwingz, I wanted to say thanks for making this script.A lot of CHDK people have helped to make the script happen. I'll say thanks for all of them.
I was originally going to ask about an error I was having, but it turns out it was due to being on a developmental 1.4 version of chdk.So was it an error or just a message about the version of CHDK you were using? I'll be fixing that in the next update regardless.
A) are there any other camera settings I need to set up before starting the script? GPS is on, and I had some custom settings in the C mode prior to installing / configuring the script - does it matter what shooting mode my s100 is dialed to?Hmmm .. well, the script will use CHDK to override Canon exposure settings so that is gets the Tv, Av, and Sv settings it thinks is needed. To be safe, P mode should work for most cameras but you can probably use your C mode stuff - CHDK will override the settings it needs to.
B) is there any way to disable to automatic rotation of images / orientation sensor in the s100? this is not really a script specific question, but you seem knowledgeable of the s100AFAIK, the camera will take the image it sees - full sensor resolution. Any automatic rotation you see is only happening to the image displayed in the camera's LCD. The final result you get from the SD card should be the full sensor resolution with something in the image EXIF information that tells PC software about the camera's rotation at the time the image was taken.
I don't know where I went wrong, but after a few seconds of it working it went from taking pictures every few seconds, to taking video! I'm sure I am doing something very obviously wrong, but I cant work it out!...the video option appeared to be switched off?Strange. I can test tonight on my S100 to see if I can reproduce this.
Cheers!
I also started playing with some of the parameters, and when I tried to revert the parameters back to defaults it didn't seem to want to do anything....it just held onto my settings I had put in myself!How did you attempt to do that?
I have been worrying a lot recently that my S100 may be a bit of a dud...and the focus seems very soft, and I have been advised that this script will get the best out of my camera, so now I just have to work out how to use it properly!We have had issues with focus at infinity with several user's S100's so I bought one to try it our. Naturally mine works properly without issues. Are your images soft without CHDK loaded?
I was speaking to Dave Mitchell and he said that I could use it with my autokap rig, but couldn't remember which of the options to select for the usb shooting mode, i.e. on/off, none, oneshot or pwm?You'll have to tell me what you are hooking up to the camera before I can answer that.
Finally I was wondering if I can use the script if I want to just take shots with it on my remote controlled rig, where a servo arm comes down and presses the shutter?No. If you press the button with the shutter script running, the script will simply stop. The script does a lot of complex exposure calculations and then takes each shot itself. You could modify the script so that it disables the shutter button from shooting and then monitors the state of that button and shoots when you press it. Not sure that gets you much though?
When i use the USB Shot Control option On/Off I have to use the switch of my radio twice to start shooting. After the first time i only get the message "waiting for USB..." and it needs the second push to start shooting pictures. Is that ok ? And if it is, why is it better not to start immediately...I think your issue here (and below) is not understanding how the USB Shot Control options work.
The second question is more important. In the chdk settings "Enable Remote" won't stay checked after on use of the script - that means i have to check this option every time before start otherwise my rc switch won't start the script at all.The script sets the "Enable Remote" setting to "Enabled" when it starts. It resets it to not enabled when it completes. I had not though about people actually trying to start the script with their remote as well. Thank you for finding this and reported it!
set_config_value(121,0) -- USB remote disable
As far as i understand i need the initial USB 5v not till then the script starts with the second impulse.The "normal" sequence with this script is :
My problem with that is that i don't get a feedback of the actual stat and therefore I am never sure if the camera is shooting when my quadcopter is in the air. Yes, with only one needed push i wouldn't know that either...
Probably there won't be a perfect solution for me...
As I read in some post above - if i want to use the PWM function I need this particular cable you mentioned.That's probably the easiest way to do it. You could build your own with a small microcontroller but why bother?
I there some micro controller inside to transform the signal?I assume so.
I tried some funny time changing the script to get some longer lasting 'windows' for the pulse and tried to emulate it by hand - just got error messages. You see I am not a tech guy (in fact a gardener) and need a lot of try and errors.I can't help here unless you post your modified script and the exact error messages you saw.
Hello, I made a few modifications to the v3.3 KAP_UAV script (for CHDK v1.3). My focus was to adapt the script to flying a fixed wing with pixhawk autopilot and a cheap hobbyking relay adapter (using the scripts "PWM" mode).Nice!
Changelog vs stock 3.3:
- Added an option to use the external USB timer when reading USB pulse widths ("set_remote_timing" command)
- Added an option to stop the script after X minutes (useful to ensure the lens will retract if I cannot signal the script to stop)
- Added a buffer to the log routine, in order to prevent write delays on slow SD cards. The Log is written every 0.1 second
- Removed a limitation that prevented the camera to power off when setting "Total Shots" param to 0 (infinite shots)
- Customized the pwm_mode to suit my needs: a short pulse signals "shoot", and a longer pulse signals "stop script" (mission end)
- Added logging in a few places, the most interesting place is in the "pwm_mode(pulse_width)" function, it now logs the measured pulse width (useful for debugging purposes when using a cheap relay with poor timing control)
:133 attempt to index global 'log' (a nil value)
I have logging enabled for the script (screen and SD card), I don't know much about the 'logging' process though - I can see a 'LOG' folder in the CHDK folder but it is empty (perhaps it's trying to write to a file that doesn't exist?)The log file is actually stored in the root of the SD card (the top level directory folder) rather than the LOG folder. It is called KAP.log. If you can find that and post it here, it will make fixing this much easier.
Thanks for the reply, the output in the KAP.log file is below:As it happens, I too have an A560 and get the same crash (which doesn't happen with my S100 or A1200 or G10).
I'm using it on a S100 camera for photomapping purposes , in order to geotag the pictures I need to do a correlation between the hour/minute/second when the picture was done and the hour/minute/second when my autopilot recorded the corresponding coordinates.Just curious here - do you use the S100's GPS capability here? Or is it too slow / inaccurate to be useful?
My autopilot records 4 time per second the coordinates (longitude,latitude,altitude) , so for 1 picture I have 4 possible locations. To be easier to geotagg the image with the right values is possible to have also on KAP.log file the second divided to 4 or 2 timeframes ? So to have HH/MM/SS/xx where xx represent 00 / 25 /50 /75 th of a second ?The camera's system clock only provides the time to a one second resolution and that's what the script currently uses. The internal tic timer is more accurate - it works in 10 mSec increments. There have been several discussions about this on the forum :
Also , to better understand , the hour recorded in the log is the hour when:I'm afraid it's pretty much your first case. The time stamp is when the actual log file entry is record in the log. Which happens after quite a bit of additional code that collects shot data and formats it. That has not been a problem to date but it would be trivial to record the actual time stamp at the moment the shutter is commanded to release. With a bit more work (see my comments above) the script raw shooting hooks could get even closer to when the actual image is taken.
- the picture is recorded on the memory card;
- camera start to focus to take the picture;
-the script gives the "command" to the camera to take the picture ?
Thanks a lot for your feedback, if it will be possible to implement hook_shutter() function on the KAP script I will test it during several flights.I've added it to the v3.4 release that I've been working on. There are several other changes in there that have not had any testing. I'll do some unit testing of each of the changes and then ask you to give it a try? There are a few other script users who might also be willing to give the changes a whirl. That should be the last version before CHDK 1.4.0 becomes the "stable" release and I can upgrade the script to use the new functionality that brings.
Okay - found the problem. Not really sure why it's camera specific but adding a short delay after releasing the shutter button when halting video cures the problem.
Test script here : xkap_uav.lua (https://app.box.com/s/fczbteiduuysfme8h678uepnaea4uyf2)
Thanks a lot for your feedback, if it will be possible to implement hook_shutter() function on the KAP script I will test it during several flights.I've added it to the v3.4 release that I've been working on. There are several other changes in there that have not had any testing. I'll do some unit testing of each of the changes and then ask you to give it a try? There are a few other script users who might also be willing to give the changes a whirl. That should be the last version before CHDK 1.4.0 becomes the "stable" release and I can upgrade the script to use the new functionality that brings.
As a small aside, the script now returns to taking still frames once the camera has finished shooting the video, I have turned the flash to 'off' initially but when the video finishes the flashmode seems to revert to 'auto'? I thought about changing the flashmode each time using the lua script but I can see a 'get_flash_mode' function but no obvious 'set_flash_mode' option? Am I missing something obvious?One of the (many) things the script does at startup is disable the flash and the AF assist beam. The code looks like this:
set_prop(props.FLASH_MODE, 2) -- flash off
set_prop(props.AF_ASSIST_BEAM,0) -- AF assist off if supported for this cameratried to use the 3.4a script on my IXUS970. It doesn't work. (CHDK 4138)There have been almost 100 downloads for 3.4a. This is the first problem report.
Checked also on IXUS130. The KAP_UAV 3.4a works great.(1.6 also)So to be very clear, does this mean there is no problem when using the script on your IXUS130?
I can start the script, one photo is taken (and stored), then nothing else happens.Hmmm ... I'll need to know a little more about what "nothing else happens" means.
I can leave the script with the playback key but i can not contol the camera as usual. After restart I always can reproduce that.The 3.4 version of the script should only halt when you press the MENU key. All other keys should be locked out - including the shutter button and Playback key. It's possible that there is a problem with the CHDK port for the IXUS 970 where this does not work properly.
Focus@Infinity doen't change the problem.Good to know - thanks.
Sorry for that.tried to use the 3.4a script on my IXUS970. It doesn't work. (CHDK 4138)There have been almost 100 downloads for 3.4a. This is the first problem report.
There are only problems with the IXUS970?Yes.
Hmmm ... I'll need to know a little more about what "nothing else happens" means.1. Load Script.
... and post them here.done.
Please confirm that you can stop the script when it "hangs" by using the MENU key?No, for the moment I can't confirm.
Sorry for that.No apology necessary - it's always good to get feedback early of problems. I was just trying to point out that it was probably something specific to your situation rather than a general problem.
Thanks - that's good to know.QuoteThere are only problems with the IXUS970?Yes.
1. Load Script.Based on this description and the photo you posted, I think that I know what might be happening.
2. In Alt-Mode press shoot -> Script starts, four lines of Results appear, one photo is taken and reviewed.
3. the camera seems to be frozen.
4. menu button pressed, screen stays with the already taken picture (and nothing else). Nothing else happens. (like frozen)
5. Review button pressed: immediatly i can see the four result-lines and the next photo is taken.
but from now on there is nothing going on automatic.
Sometimes the result lines are a little bit dearranged and show: shot in auto mode, meter reading invalid.
6. when I press print-button(Alt-key) the result lines disappear. (but the photo is still on the screen and
nothing else)
I cannot go back in Alt-mode
pressing review button reboots the camera.
I will try to make a fresh copy of CHDK and the script in the evening.It will not hurt to try this but I don't think there is anything wrong with your CHDK installation or how the script is installed.
I'm using it successfully with USB Shot Control set to One Shot with a Pixhawk Autopilot. However, I'm unable to retract the lens. I see you've implemented a couple of features that will almost work (PWM and return camera to playback mode). Can the script be set so that I use multiple PWM values to, extend lens, take picture, retract lens?I have not looked to see if there is some sort of event_proc that could be used to force the lens to retract.
QuoteI will try to make a fresh copy of CHDK and the script in the evening.It will not hurt to try this but I don't think there is anything wrong with your CHDK installation or how the script is installed.
I told you, when I press the review button, then I switch over to another picture.There is something else I probably should have asked earlier. Do you have the camera setup to switch to "review" mode after each shot? And probably worse still, is it setup to "hold" the review image rather than time out automatically and return to shooting mode?
...
Pressing review key works again ... and so on.
If so, what happens when you turn that stuff off using the Canon setup menu and just have the camera stay in shooting mode all the time?
I usually have two seconds review time. When I switch that to OFF in Canon menu than there is no difference in the script behavior.Thanks for trying.
The behavior of the Playback key is strange. Do you also use it as the CHDK <ALT> key by any chance?Not by intention. There was a lot of keyboard stuff in the last weeks, maybe something changed?
What happens if you just start the script and let it sit there - don't press any buttons. Does it take a picture every so often? Or just sit there hung forever?The picture stays foreever, no additional pictures.
What does the LCD console say in that case?nothing, there isn't any overlay.
If you exit via the Menu button you can go to the CHDK Miscellaneous Stuff menu -> Console -> Display last console to see what was on the console during the test.When I am able to leave by menu key, for that case you already have a valid kap.log
Can you ... record video of the operation
There was a lot of keyboard stuff in the last weeks, maybe something changed?That's a very interesting thought! The changes are all in CHDK 1.4.0 - which is what you are using. What happens if you load CHDK 1.3.0 into your camera and run that?
But why other scripts work?Other scripts might not using the set_exit_key() (http://chdk.wikia.com/wiki/Script_commands#set_exit_key) function, the new RAW script shooting hooks, or the same methods of reading & setting exposure that the kap_uav.lua script uses.
I don't have a lot of time today but I will send you a link to a test version of the script that will have a lot more debugging information logged. At this point we need to figure out exactly where the script is stopping.QuoteWhat happens if you just start the script and let it sit there - don't press any buttons. Does it take a picture every so often? Or just sit there hung forever?The picture stays foreever, no additional pictures.QuoteWhat does the LCD console say in that case?nothing, there isn't any overlay.
There was a lot of keyboard stuff in the last weeks, maybe something changed?That's a very interesting thought! The changes are all in CHDK 1.4.0 - which is what you are using. What happens if you load CHDK 1.3.0 into your camera and run that?
Debug version of the script : ku_test.lua (https://app.box.com/s/hnxfrge16xn748lb5a3gowk92v76x28f)
Please run this and post the resulting log here.
TIA
two KAP.LOGs as attachment.Now we are getting somewhere! I can see where the script hangs up :
dprint("Debug :hook_shoot.set")
press('shoot_full') -- and finally shoot the image
dprint("Debug : shoot_full")
while not hook_shoot.is_ready() do sleep(10) end -- wait until the hook is reached
dprint("Debug : hook_shoot.is_ready done") The hook_shoot.is_ready() function never returns true on your older camera. Either something wrong with the raw hooks or (more likely) something I am doing wrong while trying to use them. Will likely need some of reyalp's help here.The hook_shoot.is_ready() function never returns true on your older camera. Either something wrong with the raw hooks or (more likely) something I am doing wrong while trying to use them. Will likely need some of reyalp's help here.This sounds like this is probably a bug in the ixus970_sd980 capt_seq.c, such that there is a code path where wait_until_remote_button_is_released is never called. Further debugging should go in the porting thread: http://chdk.setepontos.com/index.php?topic=3246.130 (http://chdk.setepontos.com/index.php?topic=3246.130)
@exposeIT I think I found the issue, please try the test build posted in the porting thread.
I posted a test build in the porting thread,
Hello Waterwingz,
Thanks for the awesome script! I'm using it successfully with USB Shot Control set to One Shot with a Pixhawk Autopilot. However, I'm unable to retract the lens. I see you've implemented a couple of features that will almost work (PWM and return camera to playback mode). Can the script be set so that I use multiple PWM values to, extend lens, take picture, retract lens?
Thanks!
Brian
Brian, I am also using PixHawk with CHDK. Unfortunatedly, "PWM" is not the best name for that mode. The script is not reading a RC PWM signal. It just reads 5v DC signal (what it does is measure for how long there is a 5v voltage in the usb power line).Well, PWM is an acronym that means Pulse Width Modulation. With PWM information is conveyed by an input pulse via the length of the pulse. CHDK's USB input function can read such "pulse width modulated" signals. And as such, calling the CHDK PWM input by that name is correct.
You cannot use the pixhawk as is to drive the camera's (As I understand the issue with the PixHawk output is a question of the Pixhawk only providing a 3.3V PWM signal and the Canon camera USB port expecting 5V. So a level translator is needed. Many others have interfaced a Pixhawk directly to a CHDK camera using the PWM capability of both. I'll dig up the links later if necesary.wrongly named) "PWM" mode. What I did is buy a "RC controlled switch (http://www.hobbyking.com/hobbyking/store/__46040__Turnigy_Receiver_Controlled_Switch.html)", and connect it to the Pixhawk's channel 7 output on one side and a gutted USB port on the other.
I don't have any formal knowledge about the subject, so I may be wrong. I believe that to be able to call a pulsed signal "PWM" the signal has to pulse regularly (for example every 20ms), and what you vary is how long you keep the pulse high. I don't know if it can be called PWM when there is no pulse repetition.Brian, I am also using PixHawk with CHDK. Unfortunatedly, "PWM" is not the best name for that mode. The script is not reading a RC PWM signal. It just reads 5v DC signal (what it does is measure for how long there is a 5v voltage in the usb power line).Well, PWM is an acronym that means Pulse Width Modulation. With PWM information is conveyed by an input pulse via the length of the pulse. CHDK's USB input function can read such "pulse width modulated" signals. And as such, calling the CHDK PWM input by that name is correct.
What you are talking about here are not the Pixhawk's main RC PWM outputs (which output a 5v PWM signal), but it's auxiliary outputs, which can be configured as switches, but output a 3.3v signal instead of a 5v signal. These switches could be used to drive your script's "PWM" mode, but in order to do so you need to drive the voltage up to 5v.Quote from: NaccioYou cannot use the pixhawk as is to drive the camera's (As I understand the issue with the PixHawk output is a question of the Pixhawk only providing a 3.3V PWM signal and the Canon camera USB port expecting 5V. So a level translator is needed. Many others have interfaced a Pixhawk directly to a CHDK camera using the PWM capability of both. I'll dig up the links later if necesary.wrongly named) "PWM" mode. What I did is buy a "RC controlled switch (http://www.hobbyking.com/hobbyking/store/__46040__Turnigy_Receiver_Controlled_Switch.html)", and connect it to the Pixhawk's channel 7 output on one side and a gutted USB port on the other.
Otherwise, there is a device available from Gentles that will directly connect an RC servo signal to the camera.
I don't have any formal knowledge about the subject, so I may be wrong. I believe that to be able to call a pulsed signal "PWM" the signal has to pulse regularly (for example every 20ms), and what you vary is how long you keep the pulse high. I don't know if it can be called PWM when there is no pulse repetition.While I don't agree with the limitation that a regular pulse series is required, I do understand that it's the most common way PWM is implemented.
Anyway, this is not really important except for one detail: In RC the standard is to use a PWM signal at 5v, with the pulse's length (usually) varying between 900 and 1900us, and the pulse repeating every 20ms. If you have RC background and read 5v PWM, you might believe this script's "PWM" control scheme is compatible with RC's standard PWM, when it is not.Using the new high precision timer in CHDK 1.3.0 it is quite possible to read and interpret a PWM sequence generated to this specification. So it can be quite compatible if setup correctly.
What you are talking about here are not the Pixhawk's main RC PWM outputs (which output a 5v PWM signal), but it's auxiliary outputs, which can be configured as switches, but output a 3.3v signal instead of a 5v signal. These switches could be used to drive your script's "PWM" mode, but in order to do so you need to drive the voltage up to 5v.True. Although as I said, you can also use the PWM output with a few code changes.
The Gentles device reads the Pixhawk's main RC outputs' PWM signal (or any RC receiver's PWM signal) to drive a switch which outputs 5v pulses.Hmmm ... well seeing as we are on a terminology kick today, I think those PWM outputs your are describing are simply the standard RC digital servo signal that had been around forever?
Using the new high precision timer in CHDK 1.3.0 it is quite possible to read and interpret a PWM sequence generated to this specification. So it can be quite compatible if setup correctly.Really? This is great news to me! I never thought the hardware might be able to read pulses with sub millisecond resolution! Implementing this would be great, it would enable anyone with a RC radio system to control a canon camera without any extra hardware! As soon as I get my SD1100 back I will try to program a script to do just that.
Hmmm ... well seeing as we are on a terminology kick today, I think those PWM outputs your are describing are simply the standard RC digital servo signal that had been around forever?That is correct. If we can get the camera to read the standard servo signal it would enable a lot of people to do great stuff at almost no extra cost.
I never thought the hardware might be able to read pulses with sub millisecond resolution! Implementing this would be great, it would enable anyone with a RC radio system to control a canon camera without any extra hardware!Now comes the disclaimers. :o
#define CAM_REMOTE_HIGHSPEED_LIMIT 250This will give fairly course resolution of a standard servo signal. Lower values may be possible but you are on the bleeding edge at that point - some cameras with better processor may work better than others. Still, with this setting you should be able to distinguish the servo control pulses (1.0 mSec to 2.0 mSec) in steps of 250 uSec ( or 5 discrete "positions").As soon as I get my SD1100 back I will try to program a script to do just that.That's pretty much the only way to find out. The script function you are looking for is set_remote_timing() (http://chdk.wikia.com/wiki/USB_Remote_V2#set_remote_timing.28uSec.29). I guess the first question is how many discrete commands you want to give? Shoot, zoom in, zoom out, shutdown ?
I guess the first question is how many discrete commands you want to give? Shoot, zoom in, zoom out, shutdown ?My use case (orthophoto for aerial surveys) only requires three instructions: "mission start", "shoot", and "mission end". Your script takes the first pulse (any length) as mission start, so I really need only two distinct commands, meaning I don't need a lot of resolution. Right now the APM configuration limits the PWM min and max values to 800 and 2200us (pixhawk hardware can probably do a lot better, but that might mean messing with the [open source!] firmware, which I am not ready to do, as I don't want to destroy my expensive hardware in a crash), so I should be able to use 800us as baseline, 1500us as "shoot", and 2200us as "mission end".
Let us know if you need a custom build to try this out.Unfortunately I don't have the camera with me, and I will not be getting it at least for a month, so right now all I can do is write very long posts... But assuming this change has low chances of bricking my camera I will definitely ask for a custom build.
If this gets implemented, the message to the camera would become very small, and it would get buried in a lot of noise... So in order for this to work there should be a way for the camera to disregard the noise (baseline 800us pulses), and only report the signal (1500us and 2200us pulses). I don't know how easy or hard this might be. Do LUA scripts get compiled and then run using native camera code or are they interpreted every time? The answer to that question might determine if the code that detects the signal vs the noise should be implemented in firmware code (fast?) or LUA code (slow if interpreted?), as this code would be executed a lot.The high precision pulse counting / measurement code runs in a interrupt service routing written in C. There is a Lua call to allow it to read buffered data from that routine.
For how long should the pixhawk hardware send the 1500us and 2200us pulses? I believe this will depend on how long it takes the camera to run one loop of the script... If the pixhawk sends the pulse for a very short time and the timing is such that the camera misses reading it, the signal might get lost... On the other hand, if the signal is sent for too long, the camera might take the same action twice...
Has anybody timed the shortest & longest time to run a complete loop? The longest time will probably vary if for example the camera has to write the log to disk, or perform other actions...I don't think this will be much of an issue.
Finally, the signal will probably be repeated a few times, I wonder how the camera reads that. If for example it constantly reads for a signal and buffers, and then sends whatever it buffered when the LUA script asks, this whole thing might be difficult to implement... I don't know if I can get the pixhawk hardware send only one 1500us pulse and then revert to 800us.This can be fairly easily handled in the Lua code.
This can be fairly easily handled in the Lua code. But rather than continue worrying about the various "armchair theories" it would be better to just hook up the camera to a RC receiver and try it.I'm itching to try this out, unfortunately I won't be able to for at least a month :'(
be fairly easily handled in the Lua code.
I'm itching to try this out, unfortunately I won't be able to for at least a month :'(Like I said, this is pushing the envelope a bit but if you only need three states, there should be enough resolution to pull that off reliably.
The high precision pulse counting / measurement code runs in a interrupt service routing written in C. There is a Lua call to allow it to read buffered data from that routine.Did someone actually test the code with sub-millisecond repetition rate? As far as I remember, timers are not very accurate when called that often.
Yes, there was some work done and reported in the thread where all this was documented. The OP was running a bit banging UART at 1 kbps and getting responable results. I couldn't find the post but I believe from memory that thing got really shakey down below 500 uSec timer rate. Which is partly why I set the lower limit that can be set from a script at 1 mSec.The high precision pulse counting / measurement code runs in a interrupt service routing written in C. There is a Lua call to allow it to read buffered data from that routine.Did someone actually test the code with sub-millisecond repetition rate?
As far as I remember, timers are not very accurate when called that often. Also, Naccio mentioned an SD1100, which is a DIGIC III model. The ARM core in DIGIC II and III runs at 36 MHz (DIGIC 4 and 5 is clocked higher, at least 72 MHz). edit: not to mention that CPU load is much higher in shooting mode.All true. The question is whether we can differentiate a 1 mSec pulse, a 1.5 mSec pulse, and a 2 mSec pulse to get the three states required. As I've said a few times now, this is pushing the envelope and not guaranteed, but it seems worth trying?
I couldn't find the post but I believe from memory that thing got really shakey down below 500 uSec timer rate.Found it : http://chdk.setepontos.com/index.php?topic=11342.msg111415#msg111415 (http://chdk.setepontos.com/index.php?topic=11342.msg111415#msg111415)
I already have CHDK installed on my Canon S110, how do I go about adding this script into it and is there a link anywhere on how to do it????Well, you could always RTFM (http://chdk.wikia.com/wiki/CHDK_1.3.0_User_Manual). The particular section you are looking for is here (http://chdk.wikia.com/wiki/CHDK_1.3.0_User_Manual#Scripting_.28program_your_camera.29).
I already have CHDK installed on my Canon S110, how do I go about adding this script into it and is there a link anywhere on how to do it????Well, you could always RTFM (http://chdk.wikia.com/wiki/CHDK_1.3.0_User_Manual). The particular section you are looking for is here (http://chdk.wikia.com/wiki/CHDK_1.3.0_User_Manual#Scripting_.28program_your_camera.29).
This (http://chdk.wikia.com/wiki/Scripts) might help as well, although it's a bit old.
Finally, there is some documentation (http://chdk.wikia.com/wiki/KAP_UAV_Exposure_Control_Script) on the actual script.
Thank you for that, you've saved me hours of reading / trawling to find it so it is very much appreciated!!!One final gift then : http://chdk.wikia.com/wiki/CHDK_Links (http://chdk.wikia.com/wiki/CHDK_Links)
Anybody any idea what that may be????
The oly thing I could find the referenced it's filename is cchdk3 .... is that what you meant??Go to the CHDK menus -> Miscellaneous Stuff -> Show Build Info and tell me what it says for CHDK Ver : and Revision :
it was probably from about July last year if that helps??
I keep getting "* USB Pulse Width Error".Be aware that the "stock" USB PWM code is just something I threw together as a demo of how you can add PWM input to the script. It has not exactly had a lot of user testing in the real world.
I am utilizing an Arduino Nano to convert from an RC PWM output to the required USB power pulse. I have tested the output on my oscilloscope and it's outputting the correct pulse widths.To confirm what I have written above, it will help a lot if you tell me what pulse widths your Arduino is producing !
I have been looking through KAP 3.4 and noticed it's using get_usb_power(2), i tried changing this to get_usb_power(0), and now i get one correct pulse width before the error.Not really sure what is happening here.
I am very much a newbie when it comes to CHDK programming, so just wondering if anyone has solved this or could hep to solve it?I think we can probably drag up someone who is somewhat familiar with that script ::) Once I know what pulse widths you are actually using, modifying the PWM detection code in the script should be trivial. Sorry for not catching that sooner.
With this script running does it take "total" control of the camera?The script only controls the shutter speed, aperture, ISO sensitivity and ND filter position. And obviously the shutter button. It attempts to disable the built-in flash and the "flash assist" lamp. Other than that, everything else is controlled by the Canon menu settings.
I know you obviously set the shutter speed / aperture etc so it controls those but if you have things in the camera set like photo stabiliser and choosing colour preferences for various scenes like highlighting blues for sky and sea pictures will they still work depending what mode the camera's in or are they overwritten??
I keep getting "* USB Pulse Width Error".Be aware that the "stock" USB PWM code is just something I threw together as a demo of how you can add PWM input to the script. It has not exactly had a lot of user testing in the real world.
In the demo, the error message is displayed when the script checks the CHDK USB PWM control code for the width of the most recent pulse received and is told it's 20 mSec or more. This is an oversight on my part - when the demo code was added, the CHDK high speed timer option was not available so the pulse width values in the demo code are off by a factor of 10. The original intent was for that error to trigger if a pulse of more than 200 mSec was received.QuoteI am utilizing an Arduino Nano to convert from an RC PWM output to the required USB power pulse. I have tested the output on my oscilloscope and it's outputting the correct pulse widths.To confirm what I have written above, it will help a lot if you tell me what pulse widths your Arduino is producing !QuoteI have been looking through KAP 3.4 and noticed it's using get_usb_power(2), i tried changing this to get_usb_power(0), and now i get one correct pulse width before the error.Not really sure what is happening here.
Using get_usb_power(0) gets the most recent pulse width but it's unbuffered. You could lose pulses.
More info about all that here : USB Remote Scripting Interface (http://chdk.wikia.com/wiki/USB_Remote#.E2.80.8BScripting_Interface)QuoteI am very much a newbie when it comes to CHDK programming, so just wondering if anyone has solved this or could hep to solve it?I think we can probably drag up someone who is somewhat familiar with that script ::) Once I know what pulse widths you are actually using, modifying the PWM detection code in the script should be trivial. Sorry for not catching that sooner.
I did look at the script to make sure they would be suitable. I read somewhere the script values were in centi-seconds.When I updated the script to use precision timing, I also increased the resolution to milli-seconds. That was probably a mistake.
set_remote_timing(1000)toset_remote_timing(10000)I personally don't mind either way, as long as it's noted somewhere in the wiki.I'm testing the next script release now. In that version there is a new user parameter that lets you specify the USB remote precision to use (defaults to centiseconds). And the PWM code adjusts to that setting so the you always specify the pulse lengths in milliseconds (with defaults set for the fight controller article you linked).
but I received a weird error (picture attached).char(239) is the first character of the UTF-8 BOM (http://en.wikipedia.org/wiki/Byte_order_mark#UTF-8). Try saving your script files as plain text (ANSI, ASCII), not UTF-8 or Unicode.
Here you go.but I received a weird error (picture attached).char(239) is the first character of the UTF-8 BOM (http://en.wikipedia.org/wiki/Byte_order_mark#UTF-8). Try saving your script files as plain text (ANSI, ASCII), not UTF-8 or Unicode.
I've just updated this script from v3.3, for some reason on my A560 any video I record seems to only last 1 second? (I have the video duration set to 10 seconds). It continues taking still images after each video just fine, thought I'd mention it as a possible bug though.
capmode.set('VIDEO_STD')I'll have to play with it - maybe the A560 does not have a valid value for VIDEO_STD.As a secondary point, if I wanted to alter the file to a) Increase the number of still images that the script took before shooting video, and b) wanted to increase the length of the video that the script took, what would be the upper limit of either variable?
@param v Video Interleave (shots)
@default v 0
@values v Off 1 5 10 25 50 100
to what ever shot interval you want. Then change the 100 value here to the same number : video_table = { 0, 1, 5, 10, 25, 50, 100 }
@param w Video Duration (sec)
@default w 10
@range w 5 300
to the number of seconds you want.(I tried altering the length of the video to 9999 and got an error message?)
I've just updated this script from v3.3, for some reason on my A560 any video I record seems to only last 1 second? (I have the video duration set to 10 seconds). It continues taking still images after each video just fine, thought I'd mention it as a possible bug though.This seems to have slipped in with the focus at infinity changes in 3.4. The A560 does video interleave correctly with v3.3.
I've just updated this script from v3.3, for some reason on my A560 any video I record seems to only last 1 second? (I have the video duration set to 10 seconds). It continues taking still images after each video just fine, thought I'd mention it as a possible bug though.This seems to have slipped in with the focus at infinity changes in 3.4. The A560 does video interleave correctly with v3.3.
Can you confirm that the problem only happens when you do not have the Focus @ Infinity enabled?
Update : it appears that all of these symptoms can be fixed by inserting a short delay between when the script switches the camera to video mode and when the script does a "shoot_full" to starts recording. I'll post an updated script tonight.
Script updated to version 3.4d with fixes for video interleave. It appears older cameras need a lot more time to switch modes and to save things to the SD card.
Script modified to accommodate this - now works well on my A560.
Update available from the usual download link : kap_uav.lua (https://app.box.com/files/0/f/0/1/f_11162762030)
QuoteAs a secondary point, if I wanted to alter the file to a) Increase the number of still images that the script took before shooting video, and b) wanted to increase the length of the video that the script took, what would be the upper limit of either variable?
To extend the number of images taken between each video clip, change the 100 value here :Code: [Select]@param v Video Interleave (shots)to what ever shot interval you want. Then change the 100 value here to the same number :
@default v 0
@values v Off 1 5 10 25 50 100Code: [Select]video_table = { 0, 1, 5, 10, 25, 50, 100 }
To extend the video time, change the 300 value here:Code: [Select]@param w Video Duration (sec)to the number of seconds you want.
@default w 10
@range w 5 300
@param v Video Interleave (shots)
@default v 0
@values v Off 1 5 10 25 50 400
@param w Video Duration (sec)
@default w 10
@range w 5 1200
Following from your post above, I tried to change the code to extend the number of shots and the duration of the video (the relevant section of the code is below), when I run the script I get an error right away saying "uBasic:1 Unk stmt"? This is the same if I edit the file in normal Windows notepad of in Notepad++If the script is written in Lua then it must have an extension of .lua e.g. kap_uav.lua
Is there a way to stop the countdown and so save the battery life?I'm guessing that you have not disabled the Shot Review setting in the Canon Menu (i.e. set it to Off) ? That's the Canon setting that determines how long a copy of your most recent image taken is displayed after the shot completes. It needs to be set to Off for the script to be able to disable the LCD.
To access it, I had to remove the SD-card and then go back into shooting mode to disable it.You should have been able to just exit CHDK <ALT> mode and use the Canon menus normally.
Now I am investigating the photo quality issue. On a bright sunny day, photos taken from my balcony are all dark. Isnt the default setting supposed to get us the best possible pictures? I have not changed any of the default settings except for enabled the infinity focus.This sound like it might be an issue with the camera's ND filter and thus a possible porting problem with the IXUS115.
Thanks! Here is one of the images - https://www.anony.ws/image/DKUR (https://www.anony.ws/image/DKUR)Thanks. Some interesting things happening in the log that I will need to study more closely. It looks like the script tries to force the camera's ND filter out so that it can shoot at a higher shutter speed / lower ISO setting. But if the ND filter does not actually retract and is still in the light path, your images will be underexposed by about three f-stops. And that's about what I see in the image you posted.
I have attached the log file also.
Thank you for the test script. I installed on my SD card and let it take 2-3 photos. But there are no log files in the CHDK/Logs folder! What am I doing wrong?The script will take exactly two photos.
Tried again and got the following in the logs:That's better.
ND Test : avmode= 1
ND out tv=992 av=294 sv=499 bv=830 exp=42
ND in tv=704 av=294 sv=499 bv=837 exp=47
...done
*** FINISHED ***
Here are the two images:Well, two images look to be exposed identically. Yet the exif info reports two very different exposures :
https://www.anony.ws/image/DK6U (https://www.anony.ws/image/DK6U)
https://www.anony.ws/image/DK6p (https://www.anony.ws/image/DK6p)
It also took the corresponding raw image. I should disable the setting for raw files, right? We only want jpg images here?For the purposes of the test strip, RAW images are not needed. But they don't hurt anything.
All of which tells me that ND filter control appears to be working correctly on your camera. And that I need to find another explanation of why the exposure is so dark in the original images you posted.I've now retested the ND filter logic of kap_uav.lua on my trusty A1200 (which like your camera has an ND filter and not an adjustable aperture).
Thanks. I was able to take some pictures. Here is one from today: https://www.anony.ws/image/DKTZ (https://www.anony.ws/image/DKTZ)Thanks.
Looks much better compared to last time but still not perfect. What do you think is going on?Looks pretty close to perfect to me. 8)
Here are the two images one before and one after shutting off the script and power cycling the camera. The black bar at the bottom of the before image is just the floor under the camera...The images look identical but the exif info indicates the f-stops are three apart.
I have also attached the KAP.log. When I pressed menu to stop the script, It showed a "log file open error". Do not know what this means.Unfortunately, it means the script was unable to open the log file as it existed (camera too busy doing other I/O) and thus did not write out the log data. When this happens during normal shooting, the script just carries on and retries later. On script exit it does not get the chance to retry though - I will have to fix that.
Thanks again! I was able to set the camera to the settings you recommended. Here is a latest image:I searched the log file and the entry for this image is missing. Did you shoot it with the script? (If so, then we had another log file write error on exit ..)
https://www.anony.ws/image/DKCA (https://www.anony.ws/image/DKCA)
Sorry! I made a mistake in my previous test. When I power cycled the camera, I forgot to switch off the KAP script. So theecond image is also taken with the script running!I thought something like that must have happened. Thanks for checking.
Here are the two images (one with script running and then switched off the camera, turned off the script by making the SD card RW and then using the P mode of the camera to take the picture): The images look pretty identical..Different exposures though ...
I have also uploaded the log.The image information is missing again - likely due to the script being unable to open the log file while it is exiting. Maybe it's because the previous image is still being saved - especially if you have RAW enabled. Can you wait an additional 5 seconds next time before and after exiting the script? Meanwhile, I've updated the test script with code that should prevent that.
I have attached the two log files for you to review. Let me know what you find.The second attached file ( LOG_0002.TXT ) is from the test script. I you have a log file from after the issues with video mode?
Are you looking for a different log file?My mistake - the log messages related to video recording are in the log you posted. I just did not look far enough back.
Hopefully last question. Should I use the beta version of the script or the regular version? I am assuming that you felt that the problem is solved in the beta version. Am I right?The "fix" is to run the camera in P mode (along with the other settings mentioned here (http://chdk.wikia.com/wiki/KAP_UAV_Exposure_Control_Script#Camera_Settings). So either version of the script will work for you.
I'm trying to figure out how to use shutter release using a TX / Receiver and what settings I need / what they mean?? In the KAP Script menu near the bottom there's USB Shot Control and the options toggle between none, On/Off, OneShot, and PWM, I'm guessing this needs to be enabled.As is happens, somebody wrote a little bit of documentation (http://chdk.wikia.com/wiki/KAP_UAV_Exposure_Control_Script) for the script. The section about Parameter Setup (http://chdk.wikia.com/wiki/KAP_UAV_Exposure_Control_Script#Parameter_Setup) covers much of what you are looking for.
I wouldn't know which setting to select and is I need a 3 position switch and if so whether the 1st click would focus it and the 2nd take the shot???There are several ways to set things up but the default is for the script to manage the complete shot when the USB 5V pin goes to 5V.
I also tried to put the Shot Interval down to 0 but the lowest it'll go is 2 seconds, will it still continue taking shots of it's own accord or is there another way I can switch that off to use a manual trigger rather than the intervalometer??The shot interval will not go lower than 2 seconds because for the most part, Canon Powershots cannot complete a shooting cycle any faster without using the camera's continuous mode. And using continuous mode has its own complications, although I have considered adding it as a script option.
I also found in the Main CHDK menu, CHDK Settings, Remote Parameters and the 3 further headingsAll of those options are essentially only for shooting via a USB remote switch when you are not using a script. The kap_uav.lua script ignores them so it makes no difference how they are setup (although Enable Sync [ ] should probably not be enabled).
Remote enable ... I'm guessing I need to enable this?? Switch type ... Options ... None, OnePush, TwoPush, CA-1 I'm not sure what these mean and if I should do anything with them???? Control Mode ... Options ... None, Normal, Quick, Burst, Bracket, Zoom .... again I've no idea what these are and if I need any of them ???
Also can I use the zoom with this and again any idea how to set it up??The script will let you set a fixed zoom position to use when shooting. If you want to be able to zoom in and out then you need USB Shot Control [ PWM ] and a suitable flight controller like a pixhawk (http://www.tuffwing.com/support/pixhawk_camera_trigger_cable.html) than can send pulse width modulated signals.
I wouldn't know which setting to select and is I need a 3 position switch and if so whether the 1st click would focus it and the 2nd take the shot???There are several ways to set things up but the default is for the script to manage the complete shot when the USB 5V pin goes to 5V.
I've got it all working, it's on a 3 position switch and I have to move it 2 clicks to get it to take a shot, can I set it so it'll trigger the shot on 1 clickSorry - I'm not sure what you are describing here. What kind of switch are you using? A data sheet, link, diagram, or just post a picture here might help.
I've got it all working, it's on a 3 position switch and I have to move it 2 clicks to get it to take a shot, can I set it so it'll trigger the shot on 1 clickSorry - I'm not sure what you are describing here. What kind of switch are you using? A data sheet, link, diagram, or just post a picture here might help.
I'm using a Futaba Transmitter / receiver on a multirotor so a standard switch that's built into the transmitter some of which are 2 position and some of which are 3 positions switches.The more important question then is what receiver are you using and what output channels does the receiver have? Only three wire servo output control or does it have on/off ( 5v/0v ) outputs?
Any idea as well at beyond what distance you're best off using the infinity setting, I'm guessing if most of the shots I'm doing are going to be beyond 20 mtrs then it's probably going to select infinity anyway even if it was set to auto focus.It should select infinity anyway, but focusing takes time and slows down your maximum shot rate. And if your kite or UAV is moving much, it may have trouble actually locking the focus. Which will either result in it not focussing or in it taking a long time to focus.
I'm using a Futaba Transmitter / receiver on a multirotor so a standard switch that's built into the transmitter some of which are 2 position and some of which are 3 positions switches.The more important question then is what receiver are you using and what output channels does the receiver have? Only three wire servo output control or does it have on/off ( 5v/0v ) outputs?
Cheers for the infinity that makes sense!!!!!
The RX is a Futaba R7008SB, I'm just googling the specs as well to see if I can make head or tale of it!!
The very 1st time I tried it last night I was getting a waiting for USB input signal I think I re-started the camera and then it worked.Well, my guess would be that the script is waiting for a USB signal ::)
Today I can't get it to respond at all and nothing has changed. I've tried unplugging the USB, re-plugging it in, staring the camera with the USB in and without it in and it just sits and says waiting for USB input signal.
I tried switching it to PWM in case that makes a difference and again nothing ...... any ideas???
My pictures though are awful and very unclear, I really wanted to get a decent depth of field so set my target AV at 7.1 and shutter at 1/800 which is throwing the ISO up to around 800, maybe that's the issue, I'll wind the AV back to 4.0 and the shutter speed up and see what effect.Please be more descriptive than just saying "awful". Are they badly exposed? (i.e. too dark or too bright). Or are they out of focus? Or are they blurry? Or too noisy at the pixel level? Were you testing while holding the camera still on the ground or was the camera shooting on a moving UAV?
Sorry I've been a bit quiet, just after I posted the last post I thought I'd take the other UAV up with the GoPro camera with a non fish eye lens in the same lighting conditions as I just done the shots with the S110 to get a direct comparison ..... I was hoping the Canon would improve on the GoPro shots and I had a complete fly away over the roof of my house and beyond some trees so I had no idea where it went heading towards fields opposite.What happens if you try a side-by-side comparison of the GoPro and S110 sitting stable on the ground, pointed at an outdoor scene with object several humdred feet away? (Make sure to adjust the zoom so the images are framed the same way - in your posted pix the GoPro is using quite a bit longer focal length than the S110)?
The pictures are blurry, very blurry and add insult to injury before the UAV decided it had a will of it's own and ran away I got a couple of pics for comparison and they're much clearer than the Canon.Having looked at many KAP and UAV pix online, I would not describe either of these as "very blurry". The GoPro image only appear clearer partly because it is using a longer focal length. Again, a comparison to what those two cameras can do when stationary on the ground is probably the next step.
The gimbal for the S110 is a servo driven oneYour biggest challenge here is how good your vibration absorbing mounting is. Apparently the S110 image stabilization mechanism "floats" the lens - even when it's off. So any vibration from the UAV motors can be very problematic. More info here : Let's talk Canon cameras (http://diydrones.com/forum/topics/lets-talk-canon-cameras)
The pictures are blurry, very blurry and add insult to injury before the UAV decided it had a will of it's own and ran away I got a couple of pics for comparison and they're much clearer than the Canon.In addition to what waterwingz said: The images you posted 1280x720, which is far less than the resolution of the s110 sensor. Original resolution would be much more useful to understand where any blurring is coming from. If the files are too large to post here, use a file hosting site like dropbox, google drive etc, or crop out a section at 1:1 zoom.
I've attached the log and a pic from each.
I have a built a UAV specially for a mission but in order to actually do the mission I need to get the shot interval of my Canon S110 under 1.5s. Can anybody tell me how can that be done?How much under 1.5 seconds? With most Canon Powershots, the fastest you can cycle a complete focus, set exposure, shoot, save image sequence is about 2 seconds.
Thanks waterwingz!Do you want to try this yourself or would you be willing to test a beta version of the kap_uav.lua script that does this?
I will get back to you shortly, once I have merged this with a little PWM control and have the results. I need 1.4s interval. Pictures will be merged. If I keep the shot button pushed the interval is 1.2s. that is about 5meter difference in the air. I just have to get the script right now.
A terrain follow mission at 80m above tree level in the hills at 20m/s speed.I'll get you something tonight ( 10 hrs from now plus/minus ). I assume at this point that your flight controller will send +5V to the camera USB port when it wants continuous shooting? We could use a PWM encode message (which the pixhawk type controllers will support) but that will take a little more testing.
will that work?
I have the gentlewire as I was using APM previously. I will also need to stop the shooting and shut down the camera before landing so I would like to keep using the the gentlewire.Using just the USB signal, I have it setup to shoot when USB is asserted (powered on) and switch to playback mode (i.e. lens retracted) when USB is off. This allows you to enable shooting on a pass by pass basis and still have the lens safely retracted on landing. With the Gentwire cables we have more options - start continuous shooting, pause continuous shooting, goto playback mode and complete shutdown being the most obvious one.
2015Jun20 16:23:33 KAP 3.6 started - press MENU to exit
2015Jun20 16:23:33 CHDK 1.3.0-4132 s110 102b Mar 31 2015
2015Jun20 16:23:33 Mode:PLAY,Continuous_AF:0,Servo_AF:0
2015Jun20 16:23:33 Tv:1/1000 max:1/2000 min:10 ecomp:0.0
2015Jun20 16:23:33 Av:4.0 minAv:2.8 maxAv:8.0
2015Jun20 16:23:33 ISOmin:100 ISO1:400 ISO2:800 M:800
2015Jun20 16:23:33 Focus:OFF Video:0 USB:3 Tmo:0
2015Jun20 16:23:33 AvM:3 int:0 Shts:0 Dly:0 B/L:0
2015Jun20 16:23:33 Warning : camera ISO not in AUTO mode
2015Jun20 16:23:34 waiting on USB signal
2015Jun20 16:23:34 Menu key exit request
2015Jun20 16:23:34 Loggger : log file updated.
2015Jun20 16:31:16 KAP 3.6 started - press MENU to exit
2015Jun20 16:31:16 CHDK 1.3.0-4132 s110 102b Mar 31 2015
2015Jun20 16:31:16 Mode:PLAY,Continuous_AF:0,Servo_AF:0
2015Jun20 16:31:16 Tv:1/1000 max:1/2000 min:10 ecomp:0.0
2015Jun20 16:31:16 Av:4.0 minAv:2.8 maxAv:8.0
2015Jun20 16:31:16 ISOmin:100 ISO1:400 ISO2:800 M:800
2015Jun20 16:31:16 Focus:OFF Video:0 USB:3 Tmo:0
2015Jun20 16:31:16 AvM:3 int:0 Shts:0 Dly:0 B/L:0
2015Jun20 16:31:16 Warning : camera ISO not in AUTO mode
2015Jun20 16:31:18 waiting on USB signal
2015Jun20 16:31:23 USB start signal received
2015Jun20 16:31:26 Mode switched to M
2015Jun20 16:31:26 Loggger : log file updated.
2015Jun20 16:31:59 KAP 3.6 started - press MENU to exit
2015Jun20 16:31:59 CHDK 1.3.0-4132 s110 102b Mar 31 2015
2015Jun20 16:31:59 Mode:PLAY,Continuous_AF:0,Servo_AF:0
2015Jun20 16:31:59 Tv:1/1000 max:1/2000 min:10 ecomp:0.0
2015Jun20 16:31:59 Av:4.0 minAv:2.8 maxAv:8.0
2015Jun20 16:31:59 ISOmin:100 ISO1:400 ISO2:800 M:800
2015Jun20 16:31:59 Focus:OFF Video:0 USB:3 Tmo:0
2015Jun20 16:31:59 AvM:3 int:0 Shts:0 Dly:0 B/L:0
2015Jun20 16:31:59 Warning : camera ISO not in AUTO mode
2015Jun20 16:32:00 waiting on USB signal
2015Jun20 16:32:01 USB start signal received
2015Jun20 16:32:04 Mode switched to M
2015Jun20 16:32:04 Loggger : log file updated.
2015Jun20 16:33:10 KAP 3.6 started - press MENU to exit
2015Jun20 16:33:10 CHDK 1.3.0-4132 s110 102b Mar 31 2015
2015Jun20 16:33:10 Mode:PLAY,Continuous_AF:0,Servo_AF:0
2015Jun20 16:33:10 Tv:1/1000 max:1/2000 min:10 ecomp:0.0
2015Jun20 16:33:10 Av:4.0 minAv:2.8 maxAv:8.0
2015Jun20 16:33:10 ISOmin:100 ISO1:400 ISO2:800 M:800
2015Jun20 16:33:10 Focus:OFF Video:0 USB:3 Tmo:0
2015Jun20 16:33:10 AvM:3 int:0 Shts:0 Dly:0 B/L:0
2015Jun20 16:33:10 Warning : camera ISO not in AUTO mode
2015Jun20 16:33:11 waiting on USB signal
2015Jun20 16:33:19 USB start signal received
2015Jun20 16:33:23 Mode switched to M
2015Jun20 16:33:23 Loggger : log file updated.
2015Jun20 16:33:47 KAP 3.6 started - press MENU to exit
2015Jun20 16:33:47 CHDK 1.3.0-4132 s110 102b Mar 31 2015
2015Jun20 16:33:47 Mode:PLAY,Continuous_AF:0,Servo_AF:0
2015Jun20 16:33:47 Tv:1/1000 max:1/2000 min:10 ecomp:0.0
2015Jun20 16:33:47 Av:4.0 minAv:2.8 maxAv:8.0
2015Jun20 16:33:47 ISOmin:100 ISO1:400 ISO2:800 M:800
2015Jun20 16:33:47 Focus:OFF Video:0 USB:3 Tmo:0
2015Jun20 16:33:47 AvM:3 int:0 Shts:0 Dly:0 B/L:0
2015Jun20 16:33:47 Warning : camera ISO not in AUTO mode
2015Jun20 16:33:49 waiting on USB signal
2015Jun20 16:33:50 USB start signal received
2015Jun20 16:33:53 Mode switched to M
2015Jun20 16:33:53 Loggger : log file updated.
2015Jun20 16:50:46 KAP 3.6 started - press MENU to exit
2015Jun20 16:50:46 CHDK 1.3.0-4132 s110 102b Mar 31 2015
2015Jun20 16:50:46 Mode:PLAY,Continuous_AF:0,Servo_AF:0
2015Jun20 16:50:46 Tv:1/1000 max:1/2000 min:10 ecomp:0.0
2015Jun20 16:50:46 Av:4.0 minAv:2.8 maxAv:8.0
2015Jun20 16:50:46 ISOmin:100 ISO1:400 ISO2:800 M:800
2015Jun20 16:50:46 Focus:OFF Video:0 USB:3 Tmo:0
2015Jun20 16:50:46 AvM:3 int:0 Shts:0 Dly:0 B/L:0
2015Jun20 16:50:46 Warning : camera ISO not in AUTO mode
2015Jun20 16:50:47 waiting on USB signal
2015Jun20 16:51:09 USB start signal received
2015Jun20 16:51:12 Mode switched to M
2015Jun20 16:51:12 Loggger : log file updated.
2015Jun20 16:55:17 KAP 3.6 started - press MENU to exit
2015Jun20 16:55:17 CHDK 1.3.0-4132 s110 102b Mar 31 2015
2015Jun20 16:55:17 Mode:PLAY,Continuous_AF:0,Servo_AF:0
2015Jun20 16:55:17 Tv:1/1000 max:1/2000 min:10 ecomp:0.0
2015Jun20 16:55:17 Av:4.0 minAv:2.8 maxAv:8.0
2015Jun20 16:55:17 ISOmin:100 ISO1:400 ISO2:800 M:800
2015Jun20 16:55:17 Focus:OFF Video:0 USB:3 Tmo:0
2015Jun20 16:55:17 AvM:3 int:0 Shts:0 Dly:0 B/L:0
2015Jun20 16:55:17 Warning : camera ISO not in AUTO mode
2015Jun20 16:55:18 waiting on USB signal
2015Jun20 16:55:19 Menu key exit request
2015Jun20 16:55:19 Loggger : log file updated.
2015Jun20 17:12:20 KAP 3.6 started - press MENU to exit
2015Jun20 17:12:20 CHDK 1.3.0-4132 s110 102b Mar 31 2015
2015Jun20 17:12:20 Mode:PLAY,Continuous_AF:0,Servo_AF:0
2015Jun20 17:12:20 Tv:1/1000 max:1/2000 min:10 ecomp:0.0
2015Jun20 17:12:20 Av:4.0 minAv:2.8 maxAv:8.0
2015Jun20 17:12:20 ISOmin:100 ISO1:400 ISO2:800 M:800
2015Jun20 17:12:20 Focus:OFF Video:0 USB:3 Tmo:0
2015Jun20 17:12:20 AvM:3 int:0 Shts:0 Dly:0 B/L:0
2015Jun20 17:12:20 Warning : camera ISO not in AUTO mode
2015Jun20 17:12:21 waiting on USB signal
2015Jun20 17:12:50 USB start signal received
2015Jun20 17:12:53 Mode switched to M
2015Jun20 17:12:53 Loggger : log file updated.
2015Jun20 17:39:15 KAP 3.6 started - press MENU to exit
2015Jun20 17:39:15 CHDK 1.3.0-4132 s110 102b Mar 31 2015
2015Jun20 17:39:15 Mode:PLAY,Continuous_AF:0,Servo_AF:0
2015Jun20 17:39:15 Tv:1/1000 max:1/2000 min:10 ecomp:0.0
2015Jun20 17:39:15 Av:4.0 minAv:2.8 maxAv:8.0
2015Jun20 17:39:15 ISOmin:100 ISO1:400 ISO2:800 M:800
2015Jun20 17:39:15 Focus:OFF Video:0 USB:3 Tmo:0
2015Jun20 17:39:15 AvM:3 int:0 Shts:0 Dly:0 B/L:0
2015Jun20 17:39:15 Warning : camera ISO not in AUTO mode
2015Jun20 17:39:16 waiting on USB signal
2015Jun20 17:39:16 Menu key exit request
2015Jun20 17:39:16 Loggger : log file updated.
2015Jun20 17:41:20 KAP 3.6 started - press MENU to exit
2015Jun20 17:41:20 CHDK 1.3.0-4132 s110 102b Mar 31 2015
2015Jun20 17:41:20 Mode:M,Continuous_AF:0,Servo_AF:0
2015Jun20 17:41:20 Tv:1/1000 max:1/2000 min:10 ecomp:0.0
2015Jun20 17:41:20 Av:4.0 minAv:2.8 maxAv:8.0
2015Jun20 17:41:20 ISOmin:100 ISO1:400 ISO2:800 M:800
2015Jun20 17:41:20 Focus:MF Video:0 USB:3 Tmo:0
2015Jun20 17:41:20 AvM:3 int:0 Shts:0 Dly:0 B/L:0
2015Jun20 17:41:20 Warning : camera ISO not in AUTO mode
2015Jun20 17:41:21 waiting on USB signal
2015Jun20 17:42:14 USB start signal received
2015Jun20 17:42:17 Loggger : log file updated.ch1up - works as it should: with interval set to 0 it makes sets shooting parameters and then it starts shooting atCan you be a little more specific? Is the focus off? Or the exposure? Remember, when shooting in continuous mode, the script locks the focus & exposure after the first shot. If you point the camera somewhere different, the script does not adjust. This should probably not be a problem when mappping if you start your shooting sequence once the UAV is on station but may seem confusing on the ground.
1.05s interval with the same settings. if camera moved picture quality degrades.
ch1mid and ch1down I am not sure how it should work.I don't have a pixhawk so that code was just a guess. In your PM you mentioned "ch1mid - gives me lens error and is shuts down". It would be interesting to see the ROMLOG.LOG file for your camera - can you go to the CHDK debug menu, dump the log, and post it here?
Strange that no image data is recorded. If you are getting a crash in the ch1mid code then that could explain it - the log file only writes to the SD card occasionally and never when continuously shooting. I did not want the delay from writing a big file to throw off the fast shot rate. Might need to reconsider that if the log buffer gets too large.Code: [Select]2015Jun20 17:41:20 KAP 3.6 started - press MENU to exit
2015Jun20 17:41:20 CHDK 1.3.0-4132 s110 102b Mar 31 2015
2015Jun20 17:41:20 Mode:M,Continuous_AF:0,Servo_AF:0
2015Jun20 17:41:20 Tv:1/1000 max:1/2000 min:10 ecomp:0.0
2015Jun20 17:41:20 Av:4.0 minAv:2.8 maxAv:8.0
2015Jun20 17:41:20 ISOmin:100 ISO1:400 ISO2:800 M:800
2015Jun20 17:41:20 Focus:MF Video:0 USB:3 Tmo:0
2015Jun20 17:41:20 AvM:3 int:0 Shts:0 Dly:0 B/L:0
2015Jun20 17:41:20 Warning : camera ISO not in AUTO mode
2015Jun20 17:41:21 waiting on USB signal
2015Jun20 17:42:14 USB start signal received
2015Jun20 17:42:17 Loggger : log file updated.
function ch1up()
printf(" * usb pulse = ch1up")
shot_request = true -- single shot unless interval = 0 causes continuous shooting
end
function ch1mid() -- put camera into shooting mode and lock the focus
printf(" * usb pulse = ch1mid")
if ( get_mode() == false ) then
switch_mode(1)
lock_focus()
end
end
function ch1down()
printf(" * usb pulse = ch1down")
if ( get_mode() ~= false ) then
shot_request = false -- cancel in case interval = 0 is causing continuous shooting
switch_mode(0)
end
endCan you be a little more specific? Is the focus off? Or the exposure?
both KAP and ROMLOG are attached.The ROMLOG shows that the last crash was on June 12th. The dates in your KAP log are correct (i.e today's date) so the ROMLOG is old. Meaning that whatever else is happening, its not CHDK crashing the camera.
I hooked it up to the autopilot so I can give the "wire" precise PWM input.I have an Arduino clone that generates servo type PWM signals that I used to write the USB pulse width code. I'll hook it back up and do some testing too.
there is a small issue. I commented out all commands for PWM control so when I modify PWM input it should have only printed the commands on the screen, but it triggers the continuous shooting then it freezesWell, the way the logic works in USB modes, the script waits for the first pulse and then just starts shooting. That makes sense in the first two USB modes but probably not in the PWM mode. I'll work on that.
KAP.log attached.Looks really good! I can see that the gentwire sends the same pulse repeatedly? But they are mostly ch2up? I assume that is due it simply repeating the servo command pulses from the RC receiver and ch2 up is something you leave active ? I guessed that might happen when I rewrote the PWM logic but I'll probably want to filter the log entries that result from that.
occasionally I get an invalid PWM input at 210 but I think that is due to the gentlewire.Might be the gentwire but I've seen the same thing with my arduino test rig. I'm pretty sure it will happen if CHDK gets two pulses too close together and misses the gap between them. But it could be something else.
so far the testing has been done only on the ground but tomorrow morning I will fly the mission. Many many thanks! I could have not done it so fast without your help! I will get back on final results tomorrow after the flight.Thanks for all your testing. I can simulate things all I like with my test rig but there is nothing like taking the script out into the real world. I'll keep plugging away looking for glitches and "bumps in the night". I also want to take a look at shooting in Canon continuous mode. On some cameras, that might be even faster!
please see attached the KMZ for today's flight.My version of 'marble' doesn't want to open your file. Is there another program I should be using?
I think, that due to the speed of the aircraft and the wind turbulence we need higher shutter speed, but I am not sure what the speed was now. Can you please advise the shutter speed used?I tried to setup the logging so that complete exposure information is included with the first shot. Looking at the log, I failed to get that right. I'll fix it in the next update.
On a deeper look I got a little puzzled. The pictures from earlier flights were 6.xxMB, these are around 4.5MB. can this script modify the resolution?To the best of my knowledge, that has nothing to do with the script. Are you sure you did not change anything in the Canon menus? Also, these pictures are mostly green trees - they might compress better than your whatever you were previously shoooting? Just a guess.
From my point of view the quality of the pictures could be improved - for me are blurry- but I do not know with what parameter I must play , any advice ?CHDK cannot make your camera better than it is. But it can help you get the most out of your camera.
I suggest that you NOT use Auto mode.
Genlewire gets 1100/1500/1900 PWM from the autopilot on each channel. From gentlewire we have the pulses you are familiar too. I feel too that the pulse error comes from the missing gap. I mainly get that when the system is desarmed. GW gets 5 volts, but no signal. I can live with it for now.I just noticed this in the gentWIRE-USB2 manual (http://www.gentles.ltd.uk/gentwire/Manual-usbc2.pdf) :
RC recevier / autopilot is providing continuously the PWM value not only when change happens.Yes, that's pretty much standard for every RC system. It's basically an old semi-analog system where servos need constant position updates. My question, repeated below, is whether the gentwire-usb2 also provides continuous PWM values (suitably modified) to the camera? Or does it just provide one pulse each time the control lever position on the transmitter changes?
at the begining of each shooting session you will see many 210s . before I activate the output the wire gets only 5 volts and no signal.That's what the gentwire-usb2 documentation says you should see too. That part is clear.
that is why you see so many CH2MID in my logs: ch2 trim is set to 1500.This is the part that confuses me. Does the gentwire-usb2 sent only one single pulse each time the servo position for either ch1 or ch2 changes? Or does it continually send pulses over and over with length determined by the last change made? And. why does it send so many CHD2MID pulses but only one CH1UP and CH1MID each time?
I am really looking forward to test the new version!New version : kap_uav.lua v3.6 beta6 (https://app.box.com/s/8s9oxzdwpem5mughte7665281o2avluk) I have enhanced the PWM code quite a bit. Note that on line 420 is says :
PWM_required_repeats = 0The value set here determines how many identical pulses in a row are needed to trigger any action. This extra bit of error proofing should almost competely eliminate false actions due to a single pulse error. However, it only works if the gentwire-usb2 sends multiple pulses at each channel position.Does the gentwire-usb2 sent only one single pulse each time the servo position for either ch1 or ch2 changes?Good question! and I can only answer from experience: yes and no.
The value set here determines how many identical pulses in a row are needed to trigger any action. This extra bit of error proofing should almost completely eliminate false actions due to a single pulse error. However, it only works if the gentwire-usb2 sends multiple pulses at each channel position.
PWM_required_repeats = 3 . 2015Jun24 09:41:15 * usb pulse = idle pulse (210 mSec)
2015Jun24 09:41:16 * usb pulse = ch2mid (150 mSec)
2015Jun24 09:41:16 * usb pulse = ch1mid (60 mSec)
2015Jun24 09:41:22 * usb pulse = idle pulse (210 mSec)
2015Jun24 09:41:23 * usb pulse = ch2mid (150 mSec)
2015Jun24 09:41:25 * usb pulse = idle pulse (210 mSec)
2015Jun24 09:41:25 * usb pulse = ch2mid (150 mSec)
2015Jun24 09:41:27 * usb pulse = ch1mid (60 mSec)
2015Jun24 09:41:30 * usb pulse = idle pulse (200 mSec)
2015Jun24 09:41:30 * usb pulse = ch2mid (150 mSec)
2015Jun24 09:41:31 * usb pulse = ch1mid (60 mSec)
2015Jun24 09:41:35 * usb pulse = idle pulse (210 mSec)
2015Jun24 09:41:36 * usb pulse = ch2mid (150 mSec)
2015Jun24 09:41:37 * usb pulse = ch1mid (60 mSec)
2015Jun24 09:41:50 * usb pulse = idle pulse (210 mSec)
2015Jun24 09:41:50 * usb pulse = ch2mid (150 mSec)
2015Jun24 09:41:51 * usb pulse = ch1mid (60 mSec)
6-10 have been taken in AUTO camera modeI took a quick look but the image names in your upload don't seem to match the image names in the log. When I try to match up timestamps, they are slightly off. I need a little more study to discover the sequence. According to the log file, the darker correctly exposed image is the second picture in each sequence for example
11-14 Manual Mode
15-19 P mode
what really puzzles me is the difference between the first and the 2-5 picture of each batch. I do not see any difference in exif data but there is a significant difference in the looks of the JPG.You have the script exposure setting set strangely. You have ISO pegged very high the shutter speed locked at 1/2000. I guess it's possible that the camera cannot actually keep up with the requests of the script. But that's just a guess.
What happens when you reshoot the sequence in P mode only (which gets rid of the various auto focus interactions) and use :
2015Jun24 16:58:00.600 1) IMG_0170.JPG
2015Jun24 16:58:00 meter : Tv:1/1250 Av:4.0 Sv:1600 609:609
2015Jun24 16:58:00 actual: Tv:1/1000 Av:2.8 Sv:500
2015Jun24 16:58:00 AvMin:2.8 NDF:NDout foc:infinity
2015Jun24 16:58:02 timeout on hook_shoot.is_ready
2015Jun24 16:58:02.800 2) IMG_0186.JPG
2015Jun24 16:58:03.000 3) IMG_0186.JPG
2015Jun24 16:58:04.020 4) IMG_0187.JPG
2015Jun24 16:58:05.040 5) IMG_0188.JPG
2015Jun24 16:58:05 Total shots count reached.
2015Jun24 16:58:05 script halt requested
2015Jun24 16:58:05 Loggger : log file updated.
015Jun24 17:01:27 KAP 3.6b6 started - press MENU to exit
2015Jun24 17:01:27 CHDK 1.3.0-4132 s110 102b Mar 31 2015
2015Jun24 17:01:27 Mode:P,Continuous_AF:0,Servo_AF:0
2015Jun24 17:01:27 Tv:1/1000 max:1/2000 min:1/100 ecomp:0.0
2015Jun24 17:01:27 Av:2.8 minAv:2.8 maxAv:8.0
2015Jun24 17:01:27 ISOmin:100 ISO1:800 ISO2:1600 M:0
2015Jun24 17:01:27 Focus:MF Video:0 USB:0 Tmo:0
2015Jun24 17:01:27 AvM:3 int:0 Shts:5 Dly:0 B/L:0
2015Jun24 17:01:30 Loggger : log file updated.
2015Jun24 17:01:31.550 1) IMG_0189.JPG
2015Jun24 17:01:31 meter : Tv:1/200 Av:2.0 Sv:n/a 677:677
2015Jun24 17:01:31 actual: Tv:1/1000 Av:2.8 Sv:320
2015Jun24 17:01:31 AvMin:2.8 NDF:NDout foc:infinity
2015Jun24 17:01:32.600 2) IMG_0190.JPG
2015Jun24 17:01:33.610 3) IMG_0191.JPG
2015Jun24 17:01:34.630 4) IMG_0192.JPG
2015Jun24 17:01:35.640 5) IMG_0193.JPG
2015Jun24 17:01:35 Total shots count reached.
2015Jun24 17:01:35 script halt requested
2015Jun24 17:01:36 Loggger : log file updated.
2015Jun24 17:03:24 KAP 3.6b6 started - press MENU to exit
2015Jun24 17:03:24 CHDK 1.3.0-4132 s110 102b Mar 31 2015
2015Jun24 17:03:24 Mode:PLAY,Continuous_AF:0,Servo_AF:0
2015Jun24 17:03:24 Tv:1/2000 max:1/2000 min:1/2000 ecomp:0.0
2015Jun24 17:03:24 Av:2.8 minAv:2.8 maxAv:8.0
2015Jun24 17:03:24 ISOmin:100 ISO1:800 ISO2:1600 M:0
2015Jun24 17:03:24 Focus:MF Video:0 USB:0 Tmo:0
2015Jun24 17:03:24 AvM:3 int:0 Shts:5 Dly:0 B/L:0
2015Jun24 17:03:28 Mode switched to P
2015Jun24 17:03:30 Loggger : log file updated.
2015Jun24 17:03:32.700 1) IMG_0194.JPG
2015Jun24 17:03:32 meter : Tv:1/200 Av:2.0 Sv:n/a 671:671
2015Jun24 17:03:32 actual: Tv:1/2000 Av:2.8 Sv:640
2015Jun24 17:03:32 AvMin:2.8 NDF:NDout foc:infinity
2015Jun24 17:03:33.710 2) IMG_0195.JPG
2015Jun24 17:03:34.730 3) IMG_0196.JPG
2015Jun24 17:03:35.770 4) IMG_0197.JPG
2015Jun24 17:03:36.790 5) IMG_0198.JPG
2015Jun24 17:03:36 Total shots count reached.
2015Jun24 17:03:36 script halt requested
2015Jun24 17:03:37 Loggger : log file updated.
I suggest that you NOT use Auto mode.
OK, understood :) , I will do only P mode with the Focus @ infinity enabled/disabled.
Thank you.
2 flights done yesterday , the quality of the pictures is better in P mode than in Auto mode. Regarding the quality of the pictures for P mode with Focus @ infinity enabled/disabled I do not see a big difference , please find below the results from yesterday.
@mirax7
is it a multicopter or a fixed wing?
What altitude were you flying at?
I am going out to the forest...
PWM_required_repeats = 1 setting the camera did not start to work just listed the input readings.the camera did not start with theThis is correct. I heard from James Gentles about the gentwire-USB2 device and it only sends one pulse per servo channel PWM change.Code: [Select]PWM_required_repeats = 1setting the camera did not start to work just listed the input readings. After changing to 0 camera worked.
Did you change anything else? pictures are larger than ever, and the time between the shots went from 1.1 to 1.3+ seconds. I need to go to 1.1 or under.I have not changed anything that would affect file size of the JPG images. And there should be nothing in the script that will affect file size either. Are you sure you have not changed anything in the Canon menus? I am currently getting shooting rates just under 1 second per picture on my S100.
Is there any delay that I can decrease?Not that I know of - I've already been down that route and eliminated or shortened every delay I could find.
Do you have any suggestions how I could go back to under 1.1s interval or what caused the increase?High ISO typically adds significant processing time.
You are right! The pictures from today looked much better than the previous ones. I surely have to get the f2.0 set and hope for the best. Some of today's forest images are too bright.But f2.0 will make things even brighter. You are probably better off letting the script do its job providing the fastest shutter speed at lowest acceptable ISO by giving it a range of values to work with Set the min & max Av range to f2.0 to f8.0. Set Av target to f2. Same goes for the ISO values - ISO min =100, ISO threshold 1 = 400, ISO threshold = 1600. And the shutter speeds at Tv target 1/1000, Tv min 1/500, Tv max 1/5000.
Do you have any suggestions how I could go back to under 1.1s interval or what caused the increase?As discussed, shooting at ISO1600 is a problem if you want 1 second speeds. File sizes get bigger and in-camera processing times go up.
Input PWM on ch2 are stable at 1500. maybe I need to trim that a little up or down.But why are ch2mid pulses being generated repeatedly? Look at the log - this sequence just keeps repeating :
2015Jun25 11:03:35 * usb pulse = ch2mid (150 mSec)
2015Jun25 11:03:38 * usb pulse = idle pulse (210 mSec)
2015Jun25 11:03:39 * usb pulse = ch2mid (150 mSec)
2015Jun25 11:03:41 * usb pulse = idle pulse (210 mSec)
2015Jun25 11:03:42 * usb pulse = ch2mid (150 mSec)
2015Jun25 11:03:45 * usb pulse = idle pulse (210 mSec)Are you doing something to make that happen?We have to somehow give back the shot control to the autopilot for each shot and still have the ~1s interval. Even if the same settings of the first picture persist throughout the entire session. Do you see any chance for this? Otherwise I cannot get the GPS and IMU data injected into the EXIF or have any kind of correlation between flight and pictures.Hmmm ... a new requirement ;)
2015Jun26 08:30:20 KAP 3.6b7 started - press MENU to exit
2015Jun26 08:30:20 CHDK 1.3.0-4132 s110 102b Mar 31 2015
2015Jun26 08:30:20 Mode:PLAY,Continuous_AF:1,Servo_AF:2
2015Jun26 08:30:20 Tv:1/5000 max:1/10000 min:1/2000 ecomp:0.0
2015Jun26 08:30:20 Av:2.0 minAv:1.8 maxAv:8.0
2015Jun26 08:30:20 ISOmin:100 ISO1:800 ISO2:800 M:0
2015Jun26 08:30:20 Focus:MF Video:0 USB:0 Tmo:0
2015Jun26 08:30:20 AvM:3 int:0 Shts:5 Dly:0 B/L:0
2015Jun26 08:30:24 Mode switched to AUTO
2015Jun26 08:30:27 Loggger : log file updated.
2015Jun26 08:30:28.640 1) IMG_0001.JPG
2015Jun26 08:30:28 meter : Tv:1/500 Av:2.2 Sv:n/a 805:805
2015Jun26 08:30:28 actual: Tv:1/5000 Av:2.0 Sv:320
2015Jun26 08:30:28 AvMin:2.0 NDF:NDout foc:infinity
2015Jun26 08:30:29.860 2) IMG_0002.JPG
2015Jun26 08:30:31.080 3) IMG_0003.JPG
2015Jun26 08:30:32.280 4) IMG_0004.JPG
2015Jun26 08:30:33.480 5) IMG_0005.JPG
2015Jun26 08:30:33 Total shots count reached.
2015Jun26 08:30:33 script halt requested
2015Jun26 08:30:34 Loggger : log file updated.
can I get a copy of the new script? I would like to test it in flight tomorrow.link > kap_uav.lua v3.6 beta 8 (https://app.box.com/s/b9zmzm4zk83ayme036843akye7l1mdt6)
Just a small concern about the pictures being too dark in cloudy weather.Like I said, the script can't change the physics of photography. The exposure is a function of available light, shutter speed, lens aperture, and the ISO sensitivity setting. For any given illumination, if the shutter speed goes up then the aperture must open more or the ISO must go up to maintain the correct exposure. These little Canon P&S cameras are never going to replace the aerial reconnaissance cameras used by the military.
Right now I am more concerned about the shutter control being controlled not by numbers and not autopilot. Do you see any chance of getting the autoopilot back in control without sacrificing the speed?Well, there is one more hack that might work.
OK, with all these modifications we had in the last week or so, how much did we sacrificed from the original functionality?Nothing - everything we have done is good stuff that I will roll into the next official release.
Right now the math says that I need a shot every 0.8s, so at 0.55s I get an ~30% excess. if plane slows down to half (ground speed) I get an additional 50% excess. :(So I'm assuming by this that you want to try the hack I proposed in my previous post? Do you want to try USB 5V on/off control or continue to use the gentwire-USB2?
At #1153 for some reason the perfect .5-.6 interval went to 1.5. I was sitting with my back to the camera so I only noticed a little late that the speed has reduced from the sound.That's a bit concerning. Did the actual images change at all? Are the file sizes all the same?
I would prefer to keep the gentwireHere's how the new sequence will look based on my understanding of the gentwire-USB2 and how it interacts with your flight controller :
When can I test the AP controlled version?Working on it now - should be done tonight.
I forgot to mention that I changed the gentwire and as you can see in the log the ch2mid repeat stopped. Next week, I hope, i will be able to repair the big wing. With that I will be able to do all the testing you require to get script in finished.Let me know if beta 9 works for you? And you forgot to attach the log :-[
I went out testing today I made 3 flights and not a single picture from B9. :(So I assume you did not test things on the ground first?
I just came back and set up a test rig: fully analog, no chance of error... B9 freezes. :oCan you be more specific than "freezes" ? Does it get past the initial "waiting on USB signal" message? If so, it should loop slowly taking picture every 10 seconds if pulses are not received more quickly than that.
I reload the B8 workand it works...B8 just starts and runs as fast as it can until it it told to stop. No sync with the flight controller or anything else to wait for.
I go again through the settings and I it strikes me: Gentwire is not capable to work with PWM inputs less then .7 seconds.I'm confused here. The gentwire-USB2 will take a servo pulse signal between 1 mSec and 2mSec repeated ever 20 mSec and convert that into a pulse between 20 mSec and 180 mSec. Where does .7 seconds come into this discussion?
I connect the AP and I get my confirmation: once I go at .6s camera stops shooting (only the 10 second shots are taken). >:(Hmmm .. are you sure that the pixhawk is changing it's servo output so that it should cause the gentwire to send ch1up and then ch1mid and then ch1up again?
After a cigarette,Tobacco ? :D
I decide to test the capability of the AP. Can it output .1s PWM signal? :o NO it cannot, no matter what I try!?Again, I'm confused. Please draw me a diagram of what you mean by .1s PWM signal ?
I will run another round at the Pixhawk forum, but so far I see no possibility of actually using the the autopilot as shot controller.
P.S.: Maybe somebody with another autopilot will be able to use it.
I 'll do a drawing this afternoon. Meanwhile: I went and flew a test mission with B8 this morning and some of the pictures came out really bad. It looks like I am the first to need vibration dampening on a foamy or a new motor and prop balanced.... I will review logs this afternoon.I wish I knew more about the pixhawk programming (and had one to play with).
I start to get the test, I read the various posts, but if someone could describe specifically the best configuration parameters for the camera, the general setup menu canon, setup in CHDK and KAP & UAV ..... ..Camera setup recommendations are given here : Camera Settings (http://chdk.wikia.com/wiki/KAP_UAV_Exposure_Control_Script#Camera_Settings). That wiki page also contains some other good advice that might be worth reading.
I have been testing it around, and I've found I can start a script with my simplePush usb remote controller. what I cannot find, is a way to stop the script execution with the remote controller. Is it possible to start and later stop the script with the USB remote?It depends somewhat on the design of your remote. If you are using a simple two position switch, the script can be setup so that it shoots continuously when the switch is in the "On" position and not shoot when the switch is in the "Off" position. But if you have a momentary contact pushbutton then you can only start shooting with it.
What is the difference between Gentwire and Tuffwing trigger cable?AFAIK the Tuffwing Trigger Cable (http://www.tuffwing.com/store/store.html#PixHawk_Camera_Trigger_Cable) simply converts the 3.3V output level of a flight controller digital output (relay) to the 5V level expected on the camera's USB port.
is there a 3.6b10?not yet :P
Attached is the sketch I promised a few days back.
I am doing some brainstorming as I find hard to believe the current situation: Pixhawk can generate microsecond level PWM signal, but I cannot get millisecond level output directly to camera.
Gentwire was the easy solution that should still work, but it doesn't work for some reason under .7 seconds.
As you have already talked to Mr. Gentles, can you please check with him if there is a minimum time for the input signal under which signals are disregarded?Sent him another email. He is usually pretty responsive so I expect an answer shortly. He is probably celebrating British Thanksgivings Day, help on July 4th every year.
I just received a very detailed answer from James. The gentWire-usb2 needs to see five cycles of servo PWM readings at the same value before it outputs a pulse the the camera. So with a standard servo signal repeat rate of 20 mSec that means 100mSec of active signal. That's right on the threshold of what you are trying to get the flight controller to do.As you have already talked to Mr. Gentles, can you please check with him if there is a minimum time for the input signal under which signals are disregarded?Sent him another email. He is usually pretty responsive so I expect an answer shortly. He is probably celebrating British Thanksgivings Day, help on July 4th every year.
100ms = .1s.
So with a standard servo signal repeat rate of 20 mSec that means 100mSec of active signal.
I'm starting to question the validity of trying to operate at 1 fps this way. If the flight controller has to send servo pulses for at least 100 mSec ( 5 x 20mSec per pulse cycle) and then the gentwire-USB2 needs to send a pulse between 30 and 180 milliseconds and then the script needs to recognize and act on that (another 100 mSec by my guess) then we have a latency of around 1/3 of second between when the flight controller says to shoot and when the actual shot happens.So with a standard servo signal repeat rate of 20 mSec that means 100mSec of active signal.100ms = .1s. Exactly! Now, I did some ground testing today, but it wasn't conclusive. I will post an update as soon as the camera battery recharges.
we have a latency of around 1/3 of second between when the flight controller says to shoot and when the actual shot happens.If that latency is constant it doesn't bother me as I can calculate with it during processing.
Seems like it would be better to use the digital output relay mode from the flight controller and skip the gentwire all together?I've been having the same bad feeling for a while, but I hoped I don't have to mess with the pixhawk source code.
If the pixhawk ArduPilot software is open source I suppose it might be worth taking a look to see what it actually does?
It will vary some - as much as +/- 50 mSec would be my educated guess.we have a latency of around 1/3 of second between when the flight controller says to shoot and when the actual shot happens.If that latency is constant it doesn't bother me as I can calculate with it during processing.
I've been having the same bad feeling for a while, but I hoped I don't have to mess with the pixhawk source code.I'd (again) suggest that you try using a 3.3-to-5 V conversion device and run the pixhawk camera control in DO (relay) output mode rather than PWM mode via the genwire.
can you please check and advise the minimum PWM Canon cameras can react to? Is it not possible that it could react under 2ms?As reported here, http://chdk.setepontos.com/index.php?topic=10822.msg123037#msg123037 (http://chdk.setepontos.com/index.php?topic=10822.msg123037#msg123037) my initial tests are promising. It needs a custom build that allows the CHDK high performance timer code to run faster than the current 1mSec limit and that could have serious impact on camera performance - especially on lower spec cameras. And it will require some level of filtering / error correction to be reliable. Using pixhawk DO relay output camera control seems like a better option.
I successfully forced my will on the pixhawk and I got the PWM up to 32767 which is 32ms for the Canon.Interesting. Standard servo pulses only range from 1 to 2 ms in duration. This is quite an increase.
I also have no idea what relay I should use. Which one can work with under ms precision.It doesn't need to be under a millisecond.
for this mission I need only 3 positions: shoot/halt/shut_down. (<10 / 10-20 / 20<). Can you please check if your s100 can work with these ms values?As long as the script's USB Timer Precision (msec) value is set to 1 then accurately measuring 10 mSec vs 15 mSec vs 20 mSec will not be a problem.
For the moment I will stick with the DIY version as the others will take a week to get here. I will go today and try to find the components in the nearest city.There are several other circuit diagram in the link I posted (http://diydrones.com/forum/topics/using-aux-pins-as-relays-for-chdk) that will also work but the one I posted the schematic for is the simplest. There are also some construction suggestions (http://diydrones.com/forum/topics/using-aux-pins-as-relays-for-chdk?commentId=705844%3AComment%3A1923812) posted there is you have not done a lot of DIY electronics assembly.
I successfully forced my will on the pixhawk and I got the PWM up to 32767 which is 32ms for the Canon.Would you mind posting screen shots of what you setup in the Arduplane Mission Planner software to do this?
That would let you use values up to 65 mSec.YOu got that right and I did go up to 65000 initially and it was stable BUT at the first restart it automatically rewrote to 32767.
--[[
@title PWM Tester
--]]
set_console_layout(1, 1, 44, 10)
print("USB pwm test started")
set_config_value(121,1) -- make sure USB remote is enabled
count=0
repeat
x=get_usb_power(0)
if ( x > 0 ) then
print("width ="..(x*1).." mSec")
count=count+1
end
until is_pressed("menu")
set_config_value(121,0) -- make sure USB remote is disabledYOu got that right and I did go up to 65000 initially and it was stable BUT at the first restart it automatically rewrote to 32767.How did you set that? In Mission Planner? Or manually editing the MAVLink file?
Even though I can only speculate, as I am neither a computer nor an electronics expert, the 32*1024 on a 32 bit CPU looks to me as some system limit that I don't want to mess with.32767 is the largest positive 16 bit signed number. The code I looked at was using unsigned 16 bit numbers but somewhere in there some piece of code is probably switching between signed and unsigned.
I have made the circuit ready but it is not working correctly for some reason. It gets some PWMs, but it doesn't make sense.Thie script needs to enable precision timing. Add this to the start of your code
set_remote_timing(1000)
Both telemetry and on-board log confirmed .YOu got that right and I did go up to 65000 initially and it was stable BUT at the first restart it automatically rewrote to 32767.How did you set that? In Mission Planner? Or manually editing the MAVLink file?
Even though I can only speculate, as I am neither a computer nor an electronics expert, the 32*1024 on a 32 bit CPU looks to me as some system limit that I don't want to mess with.32767 is the largest positive 16 bit signed number. The code I looked at was using unsigned 16 bit numbers but somewhere in there some piece of code is probably switching between signed and unsigned.
I have made the circuit ready but it is not working correctly for some reason. It gets some PWMs, but it doesn't make sense.Thie script needs to enable precision timing. Add this to the start of your code
set_remote_timing(1000)The code alterations are relatively minor and there is not likely to be other talk about the rest of the script so I would not favour a split.OK. :)
Occasionally there is a 37-38 but I guess that is when it misses a pause.What determine the time between pulses?
It might sound strange, but I have no idea. I will look into it once I have a little time.Occasionally there is a 37-38 but I guess that is when it misses a pause.What determine the time between pulses?
function pwm1(pwidth)
if( repeat_check("mode=2",pwidth ) >= PWM_required_repeats ) then
usb_shooting_mode = 2 -- request the next shot
end
end
function pwm2(pwidth)
if( repeat_check("mode=1",pwidth ) >= PWM_required_repeats ) then
usb_shooting_mode = 1 -- neutral position - do nothing
end
end
function pwm3(pwidth)
if( repeat_check("nothing",pwidth ) >= PWM_required_repeats ) then
--usb_shooting_mode = 1 -- set camera as waiting to shoot
end
end
function pwm4(pwidth)
repeat_check("shut down",pwidth)
shut_down()
-- = 0 -- put camera into playback / sleep mode
end
function pwm_mode() -- sample PWM code for Gentles gentwire-usb2 - note that values are in milliseconds
local pw = get_usb_power(2) * usb_precision
if pw > 0 then
if ((pw < 1) or (pw > 20)) then repeat_check("invalid pulse",pw)
elseif pw < 5 then pwm1(pw)
elseif pw < 10 then pwm2(pw)
elseif pw < 15 then pwm3(pw)
elseif pw < 20 then pwm4(pw)
elseif pw < 225 then repeat_check("idle pulse",pw)
end
end
endLooking at the ardupilot source code, the internal calls to the hardware abstraction layer pass the pulse width required (the stuff you set) but no setting for pulse frequency. I'll do some more digging.QuoteWhat determine the time between pulses?It might sound strange, but I have no idea. I will look into it once I have a little time.
Pixhawk generates output continuously so Camera continuously gets PWM input.The existing code handles receiving the same pulses repeatedly. And there is risk of backlog pile-up in any case - requests are not queued.
If each input is considered as executable we will have a huge backlog pile-up. this might be a problem.
The idea of executing only the first and disregard subsequent identical shoot inputs within 0.55s (so far the minimum shot interval I have seen) seems necessary. Unfortunately this cannot be the same for the pause(usb_shooting_mode = 1 ) as 0.6-0.7s shot interval should be usable.
there are also a few bugs in B9:This is not really a bug. In beta9, once you start shooting continuously the script stays locked waiting for a pulse to start the next shot. There is a timeout after 10 seconds of waiting without receiving a pulse so if you press MENU and just wait it should eventually exit the script and save the log. Once we get the basics working I'll see if I can improve on this.
- Log was not updated
- Screen was not updated
- Menu button did not finish the script running
- Shoot button did not interrupt the script running
I have altered the code a little and ran a short test :This is a pretty bad idea. If you just shut the camera down like this, you will lose everything not yet saved from the log file and the next time CHDK starts the USB remote will be enabled. I'd suggest calling the restore( ) function before issuing the shut_down( ).Code: [Select]
function pwm4(pwidth)
repeat_check("shut down",pwidth)
shut_down()
end
Here's a improved version of your PWM test script that will tell you how long the pulse & spaces are :What determine the time between pulses?It might sound strange, but I have no idea. I will look into it once I have a little time.
--[[
@title PWM Tester
@chdk_version 1.3
--]]
print_screen(123)
set_console_layout(1, 1, 44, 10)
set_remote_timing(1000)
print("USB pwm test started")
set_config_value(121,1) -- make sure USB remote is enabled
count=0
repeat until get_usb_power(2) == 0
repeat
x=get_usb_power(2)
if ( x > 0 ) then
count=count+1
print(count..") pulse="..x.." mSec")
elseif (x < 0 ) then
x=0-x
print(count..") space="..x.." mSec")
end
until is_pressed("menu")
set_config_value(121,0) -- make sure USB remote is disabledNote that this test script creates a log file of its output. You can find it on the SD card as A/CHDK/LOGS/LOG0123.TXT Please post the log here when you get some testing done?
restore( )
sleep(2000)Pixhawk generates output continuously so Camera continuously gets PWM input.I'm afraid that this could be a problem if the pixhawk cannot generate a few distinguishable PWM pulses at each waypoint / distance travelled over the ground so that the next shot can be trigggered.
I think I found this answer. From :What determine the time between pulses?It might sound strange, but I have no idea. I will look into it once I have a little time.
elseif pw < 5 then pwm1(pw)
elseif pw < 10 then pwm2(pw)
elseif pw < 15 then pwm3(pw)
elseif pw < 20 then pwm4(pw)
Mission settings: DO_SET_CAM_TRIGG_DIST=17meter (like @ ~80m altitude)I'm going to do a wikia "how to" write-up about this once the next script revision is released. So I'm trying to keep track of the necessary setup steps for the pixhawk (ardupilot). I'll also add some code to allow picking either a gentwire-USB2 or an Ardupilot from the script parameters and using good default values / code for each.
Timing works like a charm! I reached the mission start point at picture 31. I was going 50-60Km/h till I exited the village, that is picture 95. I accelerated to 90Km/h held it there for a while and then accelerated to 110Km/h. Then mission finished. The pause between the pictures can be can be seen by the mode=1 repeated xxGood!
There is only one modification that is absolutely needed : please take out the 10s interval picture taking, as first picture (the one that sets the focus and other things ) needs to be taken at mission operation start, above the target area.I don't really want to do that because if the flight controller stops sending pulses once continuous shooting starts, the script will appear to hang. That is going to confuse a lot of people trying to use the script.
I used the slightly modified version with the altered PWM ranges.Pushed : 7500 and Not Pushed : 3500 ?
Oh, Question: Should I use ND filter or not? I need crisp crystal clear images.The ND filter can be left as Yes. The script will only use it if the Maximum Tv and minimum ISO setting that you allow in your other settings will result in an overexposed picture. Which is not likely given your settings.
I don't really want to do that because if the flight controller stops sending pulses once continuous shooting starts, the script will appear to hang. That is going to confuse a lot of people trying to use the script.
What is supposed to happen is for the flight controller not to start sending pulses to the camera until it is over the target area and ready to shoot. This will leave the lens retracted and the camera idling in a low power standby mode (i.e. playback) prior to the first shot.
Also, when a timeout occurs, the camera should refocus & reset the exposure on the next shot. That appears to not be working so I will fix that.
Does that sound better than simply disabling the timeout?
Bottom line is setting focus F-stop ISO and other things has to be done at the operations area for the operations area.Getting rid of the 10 second timeout will not make this happen.
I will do a test flight on Monday.Bottom line is setting focus F-stop ISO and other things has to be done at the operations area for the operations area.Getting rid of the 10 second timeout will not make this happen.
However, resetting the focus & exposure on a timeout will (should you happen to accidentally start shooting in continuous mode prior to reaching the target area).
You need to go to Config/Tuning -> Param Tree -> Camthen pick an RC channel you would like to control the shutter (I used RC7):
- CAM_DURATION - 1
- CAM_SERVO_OFF - 8000
- CAM_SERVO_ON - 3000
- CAM_TRIGG_DIST - 0
- CAM_TRIGG_TYPE - 0
- RC7_FUNCTION - 10
- RC7_TRIM - 8000
- RC7_MAX - 32767
Can you fix the reset by then?
I notice that you set CAM_SERVO_OFF to the same value as RC7_TRIM. What does the pixhawk generate if you make them different ( say 8000 and 11000 ) ?
Could you focus on the reset debugging so it makes the reset every 10 seconds?kap_uav.lua 3.6 Beta 10 (https://app.box.com/s/zmhm2cvatwp3ez2umhegpiihjudrvx9q)
OK!Could you focus on the reset debugging so it makes the reset every 10 seconds?kap_uav.lua 3.6 Beta 10 (https://app.box.com/s/zmhm2cvatwp3ez2umhegpiihjudrvx9q)
Changes in this version :
- The PWM code changed for ardupilot use (gentwire-USB2 temporaily remove)
- Camera waits in playback mode until first pwm1 pulse received ( 3 mSec)
You mean 1 shot, right?
- If camera is in Canon continuous mode then shots are released as each pwm1 pulse is received
this can be changed back, right?
- if camera is shooting in continuous mode and no pwm1 pulses are receive for 10 second then continuous shooting stops
- continuous shooting restarts (with focus & exposure reset) at the next pwm1 pulse
- pwm2 to pwm 6 modes are ignored
[/list]
You mean 1 shot, right?Yes.
this can be changed back, right?Not so much changed back (I think the pwm1 message works well now) but added to. The code to shutdown the camera is still there for example - we just currently have no way to generate the necessary pulse width to make it happen.
I made some indoor photos (with outdoor settings, true) but they all came out dark.I don't know if its okay - I'd have to see the log file. But if you have the minimum settings locked up high to drive fast shutter speeds then it is quite possible the script is unable to get a correct exposure in dark conditions.
when the camera was waiting resetting itself the reset worked and the picture on the LCD looked fine. but by the time it got saved the picture became dark. Is this OK?
Something to bare in mind for final debugging: I cannot get my camera with PWM signal from Playback mode do any other mode as it will ask "Change Battery" it does that even with a newly charged battery. I can work around this by starting the script after camera lens are out so it is not that urgent.Strange. None of my cameras do that.
2015Jul16 08:43:43 KAP 3.6b10 started - press MENU to exit
2015Jul16 08:43:43 CHDK 1.3.0-4132 s110 102b Mar 31 2015
2015Jul16 08:43:43 Mode:P,Continuous_AF:0,Servo_AF:0 Drive:1
2015Jul16 08:43:43 Tv:1/5000 max:1/10000 min:1/5000 ecomp:0.0
2015Jul16 08:43:43 Av:2.0 minAv:2.0 maxAv:8.0
2015Jul16 08:43:43 ISOmin:100 ISO1:400 ISO2:800 M:0
2015Jul16 08:43:43 Focus:OFF Video:0 USB:3 Tmo:0
2015Jul16 08:43:43 AvM:3 int:0 Shts:0 Dly:0 B/L:0
2015Jul16 08:43:44 waiting on USB signal
2015Jul16 08:43:59 * usb pulse = pwm2 idle (8 mSec)
2015Jul16 08:46:32 pwm2 idle repeated 7590 times
2015Jul16 08:46:32 * usb pulse = pwm1 shoot (3 mSec)
2015Jul16 08:46:32 USB start signal received
2015Jul16 08:46:32 Logger : log file updated.
2015Jul16 08:46:33.580 1) IMG_0001.JPG
2015Jul16 08:46:33 meter : Tv:1/640 Av:2.0 Sv:50 771:771
2015Jul16 08:46:33 actual: Tv:1/5000 Av:2.0 Sv:400
2015Jul16 08:46:33 AvMin:2.0 NDF:NDout foc:2.8m
2015Jul16 08:46:33 * usb pulse = pwm2 idle (8 mSec)
2015Jul16 08:46:34 pwm2 idle repeated 12 times
2015Jul16 08:46:34 * usb pulse = pwm1 shoot (3 mSec)
2015Jul16 08:46:34.200 2) IMG_0002.JPGThe CAM_SERVO_ON=3500 is held for CAM_DURATION=0.1s. now the Pixhawk log is not accurate enough to determine if this is the real cause, but it surely provides the explanation for the ~0.1s loss.Unless I am very much mistaken, when you set CAM_SERVO_ON=3500 and CAM_DURATION=0.1s, then what you get is 5 pulses of 3.5 mSec each with a 16.5 mSec gap between each pulse.
Now, for the Photo part: this is probably because of my ignorance in the matter.You have the "Focus at Infinity option turned off. Why ?Code: [Select]2015Jul16 08:43:43 Focus:OFF Video:0 USB:3 Tmo:0Can you please tell me the focus distance, is it really 2.8m?
...
2015Jul16 08:43:43 Focus:OFF Video:0 USB:3 Tmo:0
...
2015Jul16 08:46:33 AvMin:2.0 NDF:NDout foc:2.8m
...
The camera seems to have picked 2.8m as a result. This might be good enough given the depth of field of the little lens & sensors on the camera.EXIF ISO=800 log Sv= 400 - which is real?I believe the value in the log is real. CHDK overrides do not alway get properly saved in the EXIF info. Although I'm not sure when that does or doesn't happen. It should be easy enough to experiment with on a desktop though and figure it out.
Can ND Filter cause increase in file size?I would not expect so. Not unless it gets inserted and the ISO setting goes above 800 to compensate, thereby giving a more noisy image which will compress less.
QuoteCan ND Filter cause increase in file size?I would not expect so. Not unless it gets inserted and the ISO setting goes above 800 to compensate, thereby giving a more noisy image which will compress less.
That depends... JPG given. More details in the picture give larger filesizes. So, if the exposure is "better" - with more details - you will get bigger filesizes. But it has nothing to do with NDfilter in or out, ND In can give bigger filesize than ND Out or vice versaMore detail based on "better" exposure will certainly cause some file size variation. However, the changes that netptl39 was seeing were file sizes going from about 2M to 8M. I would expect something a lot more dramatic than a "better" exposure would be needed to cause that. High ISO settings are one example.
Any tips to get the camera to run 3-4 hours?Battery life is a function of the power used by the camera in idle plus the power used taking each shot. Taking a shot actually consumes a lot of power so the only way to really extend battery life in your circumstance is to shoot less frequently.
The cam contains an ND Filter but I am wondering if this mechanical in/out process will work in -40° to -70° C. cold environment.FWIW, these cameras use a mechanical shutter when shooting still images, so if the mechanical parts get frozen, it probably won't work. I don't recall other HAB flights reporting problems with a frozen shutter or ND.
I don't recall other HAB flights reporting problems with a frozen shutter or ND.FWIW I've noticed that most people enclose the camera in a thick insulated foam box to mitigate the temperature effect. Of course the box also helps to protect the camera on "landing ".
My concerns about the Freeze problem are based on other resources who say that this will happen.One of the script parameter options is Allow use of ND filter ? If you set that to [ No ] then the script will never try to engage it and it should stay out of the light path. So if it also freezes up, that won't matter. As long as your Tv Max is set high (1/5000) and your ISO Min is low (80) then you should be okay with that.
As long as your Tv Max is set high (1/5000) and your ISO Min is low (80) then you should be okay with that.
A560 can handle a max TV of 1/2000 - Iso 80 is possible. Which leads me to my inital question - any impact when i leave the nd filter in permanently to reduce the Chance of getting overestimated pics?The script does not support leaving the ND filter in so you would have to change the code if that is what you want to do. One caution I might suggest is to test and make sure that the ND filter actually stays in and does not reset between shots.
Any chance such function could be added?It would be fairly simple to add that.
It might be true that the gain in practice is less than one could hope for on paper (eg no HDR application), but if the cost would only be the need for a larger memory card and more time, I think I would in many occasions still use the option.Okay - I'll add it to the next release. I'm a little busy right now with another project but if you PM me a real email address I'l shoot you a Beta test copy when I have a minute to spare.
I also like to try bracketing. When shooting sunsets or similar changing situations would be handy to have some variation in exposure control between images. HDR images would be tough, but maybe possible with some luck (lots of images), good gimbal + drone and no wind.Plan is to update the latest beta with that early next week. Stay tuned.
One final update before the official release of v3.6.
-Script exit doesn't work. Camera hangs and power off with lens out everytime. Same thing happen if using Menu button, 1 min timeout or number of shots to end script. In Kap log end i see nothing for this problem?I can't reproduce this on my A1200. But maybe you have some settings different than mine.
To help find the problem, would you use the Load default param values menu option in the Script menu to reset all your parameters, change only the Total Shot (0=infinite) setting to [ 3 ] , and then run the script and report what happens?No difference. Camera takes 3 shots and hangs.
7. IS Mode Off (may not be necessary for KAP but should be off for UAV)
On the wiki page you say:That advice comes from several places on the various UAV forums (that I can't find a link to right now of course). I believe the theory is that image stabilization is designed for the kind of motion you get from shaky hands. You'll note that the Canon camera manuals usually recommend turning it off if you are using a tripod as apparently the IS system gets confused if there is no motion at all. For a UAV, I think its the same issue - the types of vibration (high frequency) and movement are not what the IS system expects to see.Quote7. IS Mode Off (may not be necessary for KAP but should be off for UAV)Why would you disable IS (that is image stabilisation, right?) for use on a UAV. I would think the contrary would result in better images. Is a camera without IS better for UAV? or is it only for optical vs. for digital?
What camera model would you recommend?The ixus220 , sx260 , s100 and s110 are all CHDK enabled cameras that seem popular for that application. YMMV.
To help find the problem, would you use the Load default param values menu option in the Script menu to reset all your parameters, change only the Total Shot (0=infinite) setting to [ 3 ] , and then run the script and report what happens?No difference. Camera takes 3 shots and hangs.
2015Sep05 01:55:18 Logger : log file updated.is identical to the code in v3.5 (that you report as working).As I was running an older chdk version (chdk 1.3.0-3416), I upgraded to the latest version (4228) and tested again.Thanks for that note. The script tries to check that the CHDK version used is new enough but I must have missed updating that check when I added the get_sd_over_modes( ) call. I'll fix that in the official release.
the camera takes almost continously pictures: taking an writing the pictures to memory card is indeed not very fast on my little cameraThe best most Powershots will do taking normal picture (i.e. not in continuous or Canon burst modes) is about 2 seconds per shot. Cheap ones are a little slower than expensive models but not by much (a few 1/10s of a second maybe). The script tried to take all three bracketing shots as quickly as possible by holding the "half press" down and using the initial exposure and focus info to set exposure for all three shots. But it really can't make the camera work any faster than that.
One thing that has changed between v3.5 and v3.6 is that the script has become a little larger. I did a quick scan of the porting thread for the ixus220_elph300hs and it does not seem to have a lot of memory compared to some other cameras. Let's try a "loader" script - a small script that loads a larger script such that it takes up a lot less memory. This will no longer be needed in CHDK 1.4.0 (when it finally gets released) but will work for 1.3.0. Simply install the loader script like you would any other script on your SD card (in the same folder as the kap_uav.lua script) and run it.
Btw. is there any drawbacks using this loader?None beyond the complication of needing two files for one program. And that's why the loader functionality is now built into the Lua script engine by default in CHDK 1.4.0.
1.Focus: with the Focus@Infinity set to either [ ] orGetting an S100 to focus at infinity using CHDK has been an ongoing issue.
- distant images are quite blurry, yet close up images (things within ~12 inches) are quite sharp. After stopping the script, I get a brief confirmation onscreen of key parameters and regardless of whether the Focus @ Infinity option is set to [ ] or
- , it always tells me that focus is set to infinity. But the images are NOT consistent with this. Again, photos of distant landscapes are blurry and photo consisting only of things close in are quite sharp. I have all of the AF settings set to off (using the Canon menu) and I've also shut off the Image stabilization feature.
2. Shot Interval: I can't seem to take photos any faster than once every 4 seconds or so. I've tried setting the shot interval to 2 and I've also tried setting it to "Fast". Either way, the best I can get is an interval of about 4 seconds. This simple isn't fast enough to get overlapping photos with the fixed-wing UAV that I'm using. Note that I've also tried the basic Interval.lua script but this also gives me a shot interval of about 4 seconds.That's a bit slow for an S100. I can get a 2 second per shot rate quite easily with mine. Two things that will change that is saving RAW/DNG images and using high ISO values ( >400 IIRC). Also, if you do not have focus locked it will take a little longer to shoot each time.
But it now seems likely that I either got a defective replacement lens or that I did something wrong in my first ever camera repair. Or maybe this is just one of those problematic S100s and that this is unrelated to my repair.Does the problematic camera focus successfully at infinity on the ground with the camera in Autofocus mode?
I made the cable described here along with the script created by Event38 but could not get it to work.AFAIK, that cable only sources 3.3V from the pixhawk, which may not be enough to trigger your camera. There is a long thread about this on the diydrone forum (http://diydrones.com/forum/topics/using-aux-pins-as-relays-for-chdk?commentId=705844%3AComment%3A2092854&xg_source=msg_com_forum) leading to this circuit that you can build yourself or source from tuffwing (http://www.tuffwing.com/store/store.html)
I'll now try it using the KAP_UAV script. I assume that I do this by setting the USB Shot Control to One shot. Correct?There are several ways to interface a flight controller to the script using the USB Shot Control Setting :
WW, I believe dowallin isn't using a pixhawk, but an APM 2.6. I believe the APM hardware has 5v relays, so no circuit is needed for his hardware.Quote from: dowallinI made the cable described here along with the script created by Event38 but could not get it to work.AFAIK, that cable only sources 3.3V from the pixhawk, which may not be enough to trigger your camera. There is a long thread about this on the diydrone forum (http://diydrones.com/forum/topics/using-aux-pins-as-relays-for-chdk?commentId=705844%3AComment%3A2092854&xg_source=msg_com_forum) leading to this circuit that you can build yourself or source from tuffwing (http://www.tuffwing.com/store/store.html)
[SNIP]
Do you have any ideas to "fix" the problem?If AF works at "infinite" distance, then it's possible you can get the distance it thinks it's focused at using get_focus() or the DOF calculator OSD and set it later using set_focus().
RE my "problem" camera: Yes, ground-based photos on Auto (with AF settings on) produce sharp photos at infinity and close up as well. So maybe this is consistent with your theory?Thanks for that update. I continue to think my theory about CHDK being able to focus a camera at infinity is pretty much determined by whether the built-in Canon focus distance information is correct. And that Canon AF does not use those values to pick the best focus.
But not sure that I'll be able to use this camera in my UAV.Well, you do have four more .....
As I said, in my last flight with this camera and using the older "interval.lua" script and with the camera on Auto (with all AF settings on) I got lousy photos. Do you have any ideas to "fix" the problem?Simply answer? Don't use interval.lua. That script was purposely included in the default CHDK build several years ago as the simplest example of an intervalometer script. And so that's what it does - shoots in AUTO mode at a defined interval.
RE attempting to use KAP_UAV linked to my APM2.6 for Distance-based triggering: I can't get it to work.Sorry .. not sure I can help here in a CHDK forum. The script works AFAIK - how your flight controller works is virgin territory for me. Still, I'm willing to try and help.
I have my camera running KAP_UAV with:Sound okay. You might set USB timeout to something like 10 seconds during testing but 0 (or none) should work too.
Shot Interval: Fast
USB Shot Control: One Shot
USB Timeout: (I've tried both 0 and 1)
On the CHDK, Main menu->CHDK Settings->Remote Parameters -> Enable Remote setting is checked.”The script does not care what you set in the CHDK Menus. It will configure things as needed for it to run and then reset things when done to match your CHDK menu settings.
I start KAP_UAV and get a "Waiting on USB" message. But the lens remains closed and no pictures are taken.Given your settings, that says that the script is pretty much waiting for any 0V to 5v to 0V transistion on the USB +5V pin bfore it will start. If it's stuck there ... it's not seeing the signal.
Backing up, here is what I've done:Do you have a volt meter (or other testing device like an oscilloscope) that can confirm that the flight controller is actually sending signals to the cameras?
I made the cable based on instructions here:
1. http://diydrones.com/profiles/blogs/apm-to-chdk-camera-link-tutorial (http://diydrones.com/profiles/blogs/apm-to-chdk-camera-link-tutorial)
Servo plug connected to A9 on my APM2.6. I've also referred to these two pages for additional set up info:Sorry .. I have no knowledge about APM setup so I can't help more at this point.
2. http://planner.ardupilot.com/wiki/common-apm-to-chdk-camera-link-tutorial/ (http://planner.ardupilot.com/wiki/common-apm-to-chdk-camera-link-tutorial/)
3. http://planner.ardupilot.com/wiki/common-camera-shutter-with-servo/#shutter_configuration_with_apm_2x (http://planner.ardupilot.com/wiki/common-camera-shutter-with-servo/#shutter_configuration_with_apm_2x)
I'm stumped. One thing that was a bit confusing from these 3 pages. Page #1 talks about going into the Full Parameters List in the Config/Tuning tab and entering several parameters, which I've done. And, as suggested for testing purposes, I've set the Cam_Trigg_Dist to 1. Zooming in on the Flight Data page in Mission Planner, I can see my plane "wandering" by several meters every few seconds due to GPS error. So this should be enough to trigger the camera.
Webpages #2 and #3 also mention going to the Camera Gimbal Configuration Screen and selecting RELAY in the Shutter dropdown list. I've done this, HOWEVER, I note that if I go to any other page in Mission Planner and then come back to the Camera Gimbal Configuration Screen, my selection of RELAY on the Shutter dropdown list seems to be lost. Maybe this is my problem? Is there something that I need to do to lock or save my selection of RELAY?
If AF works at "infinite" distance, then it's possible you can get the distance it thinks it's focused at using get_focus() or the DOF calculator OSD and set it later using set_focus().We've been down that route several times unsuccessfully in the Setting focus from scripts or menus (http://chdk.setepontos.com/index.php?topic=11078.0) forum thread.
Alternately, you might be able to AF at a distant object and set AF Lock, Integrating either option with waterwingz script (edit: if they work, which is not a given) is left as an exercise ;)Early versions of the script did just that. You were supposed to point the camera at a distant object when you started the script and it would do a set_aflock( ) at that point to lock the focus. Would not be hard to add that back as a customized hack - not sure I'd want it as a supported feature though.
RE attempting to use KAP_UAV linked to my APM2.6 for Distance-based triggering: I can't get it to work.To test your setup you will need a voltmeter. The idea is to configure your APM to raise relay A9 to 5v for 1 second whenever the GPS senses a 1m movement. In order to do this you will configure everything entirely from the "full parameter list" screen, as these are the real values read by APM (the other configuration screens modify these values and show you "pretty" descriptions).
CAM_DURATION: 10 (1 second)Is this actually going to take a shot once per meter? The S100's maximum shot rate (when not in continuous mode) is about one shot every two seconds. That would mean the aircraft needs to be moving slower than 30 meters/minute (or 1.8 kph). Can a fixed wing fly that slow over the ground without a huge headwind?
CAM_TRIGG_DIST: 1 (shoot when the plane moves 1 meter)
Is this actually going to take a shot once per meter? The S100's maximum shot rate (when not in continuous mode) is about one shot every two seconds. That would mean the aircraft needs to be moving slower than 30 meters/minute (or 1.8 kph). Can a fixed wing fly that slow over the ground without a huge headwind?This is only to test if his APM hardware outputs 5v on the relay pins, to start troubleshooting. I used 1m to take advantage that the GPS drifts when inside, so the relay fires without need to move the platform.
The issue I'm having now is that the A2300 will NOT retract it's lens after I remove USB power. It stays in the script running and "waiting for USB power" phase. It doesnt power down and retract the lens. This is the most important part as I need the lens to be protected during landing.Lens retraction requires that the Lens Retract time in the Canon menu be set to 0 sec. Do you have it that way on your A2300? (I'm guessing it is set that way on your other cameras).
With the KAP_UAV script set up as previously instructed, I depress the shutter release. When I do so, the lens does not open but on the LCD on the back of the camera, I get a message in red that says "Waiting on USB, Press Menu to Exit". So, this suggests to me that I've started KAP_UAV correctly but no signal is reaching the camera right?Correct.
Or is there something else that needs to be done with the settings or buttons on the camera?Nope. Nothing at all. Assuming you have still used the settings reported earlier :
The only other thing I can think of is that perhaps I did not make the cable correctly. To test this I'd need to hook up the voltmeter to the pins on the mini-USB but doing this is challenging due to the tiny size of everything and, I'm not sure which pins are supposed to have this 5 volt signal. Any ideas?I have a really simple script that simply reports the state of the camera USB +5V on the camera LCD. Nothing to setup, nothing to configure, nothing to go wrong. Pretty much a "poor man's" voltmeter but if it does not see anything happening, either your cable or flight controller setup is wrong. I'll try to find and post it here.
Naccio,Excellent. Your APM is configured correctly, and as it outputs 5v you only need your custom USB cable to connect your APM to your camera.
OK I've run the test you suggested. On the "Full Parameters List page, I've set all of the parameters as you instructed, EXCEPT, I can't find the "CAM_RELAY_ON:" parameter. See attachment for my options in the "CAM" and "RELAY" section of the "Full Parameters List" page. I hit the "Write Parameters" button to save these selections. I then hooked up a voltmeter directly to the Signal ("S") and ground (-) pins of A9 on the APM.
Periodically, I did get a 5 volt reading as the GPS coordinates bounced around. So, it appears that I have all the parameters set correctly (even without the "CAM_RELAY_ON" parameter).
Next step is to hook up the camera. With the KAP_UAV script set up as previously instructed, I depress the shutter release. When I do so, the lens does not open but on the LCD on the back of the camera, I get a message in red that says "Waiting on USB, Press Menu to Exit".Your cable is probably not built correctly. If you look at the mini USB plug in such a way that you see the connectors, you must build it so that the "S" pin on relay A9 is connected to the leftmost USB connector (pin 1 on the attached image), and the "-" pin on relay A9 is connected to the rightmost connector (pin 4 on the attached image). I would suggest using a continuity tester (most digital voltmeters have them, the voltmeter buzzes when its two contacts are shorted) to check.
So, this suggests to me that I've started KAP_UAV correctly but no signal is reaching the camera right? Or is there something else that needs to be done with the settings or buttons on the camera? The only other thing I can think of is that perhaps I did not make the cable correctly. To test this I'd need to hook up the voltmeter to the pins on the mini-USB but doing this is challenging due to the tiny size of everything and, I'm not sure which pins are supposed to have this 5 volt signal. Any ideas?
It seems to me that the adjustments are off a bit. I followed the instructions for the camera and set the Kap 3.6 settings to burst, pixhawk and checked focus on infinity. All other settings are default. Any suggestions to get a sharper image from my Canon S110 would be greatly appreciated. I attached a photo and kap.log file.Thanks for including the log file. Actually, your one posted image does not look too bad to me. Are some of the others you took better than the others or are they all about the same?
I wonder why the focus on infinity shows disabled when there is a dot next to it. You are talking about the setting in the KAP script, right?My mistake - your setting are correct. The log file you posted has data from 27 different runs of the script. In the first 16 of those, you had "Focus @ Infinity" disabled - in the last 11 runs you had it enabled.
Maybe I'm missing a step?I don't think you have missed anything, but see my last comment below.
I already tried going into the camera settings and manually set the camera to infinity prior to flying but end up with the same slightly blurred photos.This is the key. It's not related to the script settings if using Canon MF mode also has the same problem.
I would leave autofocus on but I get less photos during the mission.So I see you are using the new pixhawk mode? I have not completed the documentation on that so I'm curious about how you have it setup. Thank for posting the log file.
Hey WW! Quick question: When using the new Pixhawk mode, I just have to connect the camera to one of the RC out channels, right?Correct.
If that is the case, with a few script modifications (amount of PWM pulses needed for each action) I could connect it directly to the RC receiver and control the camera just with my RC transmitter, bypassing the pixhawk?
That would mean the script would be ready to be used by any kind of flight controller, as they all have at least four RC PWM outputs...I did some experimenting with this to try and get CHDK to read servo outputs directly. I was able to almost discriminate three stick positions - down, center, up - but it was not extremely reliable. Doing some averaging over multiple pulses helped with that but it was very processor intensive and would likely not have worked well with low end cameras. I'll see if I can find the post where I reported the results.
The pixhawk setup that we discovered somewhat by trial and error generates pulses in the range of about 4 mSec to 20 mSec, which CHDK can discriminate if high precision USB timing is enabled. The servo output of your RC radio generated pulses shorter than 2 mSec, too fast for CHDK to read.Ok, so you modify the pixhawk settings to produce out of spec RC PWM values... Did anybody check with the Pixhawk developers if that could have any repercussions on the pixhawk hardware (physical damage, I suppose there is very low chance) or software (sofware crash midflight :'()?
Did anybody check with the Pixhawk developers if that could have any repercussions on the pixhawk hardwareNo.
I have also an S110 and manual focus setting does not work very well.And yet manual focus seems to work really well on my S100.
Although I did read through the source code - it's open source and available for anyone to download. From what I could see, using the values we "discovered" should not cause any issues.I tried to follow the code but couldn't get past the HAL. I suppose the important code will be on the PX4 middleware.
/// Servo operated camera
void
AP_Camera::servo_pic()
{
RC_Channel_aux::set_radio(RC_Channel_aux::k_cam_trigger, _servo_on_pwm);
// leave a message that it should be active for this many loops (assumes 50hz loops)
_trigger_counter = constrain_int16(_trigger_duration*5,0,255);
}
/*
set radio_out for all channels matching the given function type
*/
void
RC_Channel_aux::set_radio(RC_Channel_aux::Aux_servo_function_t function, int16_t value)
{
if (!function_assigned(function)) {
return;
}
for (uint8_t i = 0; i < RC_AUX_MAX_CHANNELS; i++) {
if (_aux_channels[i] && _aux_channels[i]->function.get() == function) {
_aux_channels[i]->radio_out = constrain_int16(value,_aux_channels[i]->radio_min,_aux_channels[i]->radio_max);
_aux_channels[i]->output();
}
}
}
void RC_Channel::output() const
{
hal.rcout->write(_ch_out, radio_out);
}
/*
* Output a single channel, possibly grouped with previous writes if
* cork() has been called before.
*/
virtual void write(uint8_t ch, uint16_t period_us) = 0;
One of the kap_uav.lua users was trying unsuccessfully to engage in a dialog about the application with the pixhawk team. If you have a contact there feel free to reach out to them?Unfortunately I don't have any contacts. I did find that Lucas De Marchi is currently working on almost all the relevant sections of the APM code, and will try to contact him.
It's possible that cameras in the more expensive G series are actually calibrated - or the lens mechanism does not need calibration.
I really have no idea. The G-series is the most expensive line of P&S cameras that Canon sells. So it seems likely that if any of their cameras have accurate calibration of manual focus setting it would be those ones. But I have no data (or easy way to collect any data) to support the proposition.It's possible that cameras in the more expensive G series are actually calibrated - or the lens mechanism does not need calibration.On this related note, is the G-series then the least expensive line in which you don't have to worry about this problem with "infinity" possibly not really working correctly?
It turns out that my S110 won't focus on infinity. The lens calibration is off. I tested two Canon S110 cameras with the exact same settings using KAP_UAV and the infinity button active. One camera takes perfect photos and the other camera produces blurry photos. Go figure...It wasn't the script. It's the darn cameras. Some are calibrated to work and some won't.Thanks for reporting this. It's very consistent with my theory that Canon P&S manual focus settings are often poorly calibrated - even on cameras that claim to offer MF capability. And the reason you don't see this in autofocus mode is that the camera adjusts the lens position via a closed loop feedback system until it sees the sharpest image. It has no concept or need for physical distance values.
Just FWIW, prior to this http://chdk.setepontos.com/index.php?topic=12103.msg125325#msg125325 (http://chdk.setepontos.com/index.php?topic=12103.msg125325#msg125325) setting distances >64k on S100 through CHDK probably didn't work correctly.I've struggled with this. Given the depth of field of these little camera lenses, and the concept of hyperfocal distance, it seems strange that values < 64K like 50,000 or 30,000 do not appear to give sharp focus out to infinity.
I've struggled with this. Given the depth of field of these little camera lenses, and the concept of hyperfocal distance, it seems strange that values < 64K like 50,000 or 30,000 do not appear to give sharp focus out to infinity.I seem to have deleted my test shots, but the differences was pretty noticeable on sx160 at the long end of the zoom (~440mm equivalent)
I seem to have deleted my test shots, but the differences was pretty noticeable on sx160 at the long end of the zoom (~440mm equivalent)I was not trying to suggest that the bug was not an issue. I'm just not sure it explains why some S100's work with CHDK SD overrides and others, using identical settings, do not?
I was not trying to suggest that the bug was not an issue. I'm just not sure it explains why some S100's work with CHDK SD overrides and others, using identical settings, do not?Sorry, I didn't mean to suggest that it completely explains it, only that it may have been one confounding factor.
I wonder if anybody with those problem cameras has tried setting a much closer distance to get sharp pictures.It turns out that my S110 won't focus on infinity. The lens calibration is off. I tested two Canon S110 cameras with the exact same settings using KAP_UAV and the infinity button active. One camera takes perfect photos and the other camera produces blurry photos. Go figure...It wasn't the script. It's the darn cameras. Some are calibrated to work and some won't.Thanks for reporting this. It's very consistent with my theory that Canon P&S manual focus settings are often poorly calibrated - even on cameras that claim to offer MF capability. And the reason you don't see this in autofocus mode is that the camera adjusts the lens position via a closed loop feedback system until it sees the sharpest image. It has no concept or need for physical distance values.
I wonder if anybody with those problem cameras has tried setting a much closer distance to get sharp pictures. I already mentioned this, but (for example) my sx280 reaches infinity at around 1000 mm, setting native manual focus beyond that gives increasingly blurred pictures (that means, focus goes beyond infinity). This is at wide angle of course.During testing, we used a script to run the focus out from about 20cm to infinity in steps. I'm trying to find the test photos - what you are suggesting is that the best focus at infinity might occur at 1 meter SD override value! That's certainly interesting.
The issue here is that unlike when I ran this on the sd750, I don't see any area to enter the parameters that I'd like to set for the duration of the script such as shot interval or target TV. There are no further options to scroll to below the line that says "._kap_uav.lua".There seems to be something wrong with the script file you are trying to load. If you use the current version of the script, you should see the words KAP UAV 3.6 in the Script screen - not ._kap_uav.lua I'm guessing there is a file called ._kap_uav.lua on your SD card and it's not the kap_uav.lua script you want to use (note the period & underscore at the start of the invalid filename.)
This is a Mac problem.Thanks - I wondered about that. So the actual script file should be in the SD card - the OP just loaded the wrong file?
It's a pain when scrolling through a directory on the camera - you have to skip over all these non-files.
Ww...I updated to ver 3.6 and my previously functioning 330HS on ver 3.5 now will not save the pic... my Iris fires the script... it opens the lens and the red af beam lights... but no pic. I'm able to save a pic using the camera shutter release.Iris = flight controller?
I deleted my ver 3.5....would you have that version available for me to download so I can troubleshoot?attached
Your code is a work of art IMHO.link > work of art (https://en.wikipedia.org/wiki/The_Scream)
I'm not getting any pic saved using KAP 3.5 either.Okay - finally had a chance to look at the logs. There is a bunch of older log information from this summer showing successful shooting with KAP 3.5 (as well as some really old 3.4 log info from last winter). So it was working with your camera at one point.
hook_shoot.set(10000)
press('shoot_full')
wait_timeout(hook_shoot.is_ready, true, 2000, 10, "timeout on hook_shoot.is_ready") This part is a bit complicated to explain so I'm hoping reyalp will chime in later. What is supposed to happen in each line is :This part is a bit complicated to explain so I'm hoping reyalp will chime in later.Haven't really digested the code, but I noticed this in the log before the hook timeouts
2015Dec07 16:10:13 Mode:PLAY,Continuous_AF:0,Servo_AF:0Suggests the camera hasn't switched to rec, which might explain the timeout. I would expect the shoot_full press to make it switch though, as long as the camera doesn't think USB is connected.
Suggests the camera hasn't switched to rec, which might explain the timeout. I would expect the shoot_full press to make it switch though, as long as the camera doesn't think USB is connected.The script explicitly switches to shooting mode only when it is ready to shoot if you start it in playback. Which is something you generally want to do when launching a kite or UAV. The log file indicates when that happens.
The log file indicates when that happens.I'm probably missing something, but I don't see any "Mode switched to...", although it looks like switch_mode(1) should be called, and should print that line if it thinks it needed to switch.
2015Dec07 16:11:00 KAP 3.5 started - press MENU to exit
2015Dec07 16:11:00 CHDK 1.3.0-4152 ixus255_elph330hs 100f Apr 15 2015
2015Dec07 16:11:00 Mode:PLAY,Continuous_AF:0,Servo_AF:0
2015Dec07 16:11:00 Tv:1/1000 max:1/2000 min:10 ecomp:0.0
2015Dec07 16:11:00 Av:4.0 minAv:2.8 maxAv:8.0
2015Dec07 16:11:00 ISOmin:100 ISO1:400 ISO2:800
2015Dec07 16:11:00 Focus:OFF Video:0 USB:1 Tmo:0
2015Dec07 16:11:00 AvM:2 int:4 Shts:0 Dly:0 B/L:0
2015Dec07 16:11:06 timeout on hook_shoot.is_ready
I'm probably missing something, but I don't see any "Mode switched to...",The 3.6 version of the script does that but the 3.5 does not. Just another little thing that got cleared up along the way.
...
although it looks like switch_mode(1) should be called, and should print that line if it thinks it needed to switch.
OK gents - I appreciate this insight...so I tested today by backtracking the Canon standard camera presets...the KAP website says use "P" mode...but when I switched back to "Auto", the camera accepted each and every USB trigger event I manually injected thru the Pixhawk. Go figure. Now I got these results using ver 3.5.This is a bit odd, generally I'd expect Auto to be more likely to refuse to shoot than P.
I also just loaded the ver 3.6 script, and it also ran without issue in the camera's "Auto" mode.
One thing that might be worth checking is the flash setting in the Canon firmware for each of these modes. If it isn't already off for P mode, I'd suggest trying with it off.The script attempts to disable the built-in flash by setting a propcase
set_prop(props.FLASH_MODE, 2) -- disable built-in flashThe script attempts to disable the built-in flash by setting a propcaseOther possibilities: Flash mode propcase is wrong on that camera, or uses a different value for disable.Code: [Select]set_prop(props.FLASH_MODE, 2) -- disable built-in flash
AFAIK, the main difference between P and AUTO modes is that P mode allows the user to set things like ISO, White balance, Coloration schemes, and some features of the built-in flash. I guess it's possible on some cameras, in P mode and in low light situations, that setting the FLASH_MODE prop blocks taking an actual shot?
For what its worth...just tested ver 3.6 after shutting off auto flash .. which covered Auto and P modes. Placed camera in P mode and it fired without incident. nice pics too at ISO 800 etc.@davefolts : There are a few things that could be tested if you have the time.
Attached the KAP log file.
Seems like progress has been made.
This is a great capability. Will let y'all know how the pics look after I fly and capture some property survey shots tomorrow.
Other possibilities: Flash mode propcase is wrong on that camera, or uses a different value for disable.Or setting that propcase sets the flash mode in a way that the camera does not respect during shooting (i.e. flash disabled but the exposure firmware still waits for the flash to be ready prior to releasing the actual shot).
One thing I noted is that on a sunny day the pictures (both jpg & .DNG) need to be color-corrected in Photoshop as they appear somewhat over exposed. I will try and get out at noon and see if sun angle makes a difference. (I suspect it does ease the shadow issues somewhat.)I can take a look at this and comment if you post your log file as an attachment here. Look in the top folder of your SD card for a file called kap.log
I also note that the script will allow the pixhawk to signal a shutter release about every three seconds...not bad for speed. I did have focus set at infinity and zoom is @ 20%FWIW - the latest script version lets you shoot in continuous mode (sync'd to the pixhawk position over the ground) at rates approaching 2 fps on most cameras.
Thanks WW....I attached the KAP log labelled - 23 DecemberI had a quick look at that and didn't see anything obvious. I was looking for shots where the exposure setting hit a hard limit and could not correctly expose an image. I did not find any.
2015Dec23 15:03:57.580 10) IMG_0400.JPG
2015Dec23 15:03:59 meter : Tv:1/80 Av:3.2 Sv:80 535:535
2015Dec23 15:03:59 actual: Tv:1/800 Av:- Sv:800This should work unless the camera was trying to also insert the ND filter. With a report Av:3.2 that should not be the case and the script holds it out. But if it actually was to be inserted, that would cause a three stop exposure error in the final image. function pwm5(pwidth)
update_zoom(50)
end Many thanks in advance!Thanks for the POLOLU idea! Works nice with RC controller directly. I will hook it up to the Pixhawk on Tuesday or Wednesday.Thanks! Naturally I can't remember what idea that was and a quick search of this thread does not shed any light. Refresh my memory?
May I ask you for one line of code? The "update_zoom(xx)" seem to set the zoom at a certain value.Lacking any better idea about what to do with that signal, I'll make an addition (or at least post how to do that here). It's going to be a little more than one line - naturally.
I would like to have the camera zoom in and out step-by-step (let's say by +-10) at each pwm5/pwm7 received
Any thoughts? Is this perhaps a limit on the camera?Most of the Canon Powershots take a little over two seconds to focus, set exposure, shoot, and save the resulting image to their SD card. A fast SD card helps a bit here but not much. Keeping the ISO setting below 800 also helps. Finally, you also don't want to be saving as RAW/DNG - that really slows things down.
Bonjour Jacques,
Welcome!
To have a better understanding can you please specify the Airframe/stall speed, the Autopilot, the triggering cable?
Thansk!
Tom
Any thoughts? Is this perhaps a limit on the camera?Most of the Canon Powershots take a little over two seconds to focus, set exposure, shoot, and save the resulting image to their SD card. A fast SD card helps a bit here but not much. Keeping the ISO setting below 800 also helps. Finally, you also don't want to be saving as RAW/DNG - that really slows things down.
To go faster, run the script in continuous mode by selecting Pixhawk for the USB Shot Control? setting. In that mode, the camera takes an initial exposure for the first shot and uses that setting for all subsequent shots. It will shoot each time the USB signal from your flight controller toggles - people have reported getting two shots per second this way ! The process resets each time the script stops seeing pulses from the flight controller.
Good Point WW - Here is the link to three jpegs for you to examine:I took a look and compared to the log you posted earlier. I can't see anything wrong or even unusual.
I have a 3 channel video source switcher with a video transmitter (not tested yet but it should work.). One of these sources is planned to be the Canon.You might want to check your camera. Most of the Powershots sold over the last several years will not output "live" video in shooting mode. Some of the older ones apparently do.
Looking forward for the zooming code.Here you go - tested offline as I don't currently have my PWM test setup running.
function ch2up(pwidth)
if( repeat_check("ch2up",pwidth) >= PWM_required_repeats ) then
if (get_zoom() < get_zoom_steps()) then set_zoom_rel(1) end
end
end
function ch2down(pwidth)
if( repeat_check("ch2down",pwidth) >= PWM_required_repeats ) then
if (get_zoom() > 0) then set_zoom_rel(-1) end
end
end
Thanks WW-Good Point WW - Here is the link to three jpegs for you to examine:I took a look and compared to the log you posted earlier. I can't see anything wrong or even unusual.
As far as the images go, this is a lot of contrast due to the extreme lighting conditions. The sun on the swimming pool, tall trees and rooftops makes them clearly over exposed. But the bushes in the gardens along the house wall are perfectly exposed, as are a lot of the other details (and you with your remote in your hand).
At run i'be got the message :This means that you do not have CHDK correctly installed on your SD card. The script is looking for a file called wrap13.lua on the SD card in the folder named A/CHDK/LUALIB but cannot find it.
A/CHDK/SCRIPTS/WRAP13
IB/WRAP13.LUA
TERMINATED
I used acid software to have the good CHDK version. I use a 16 Go SD card without autoboot method.If CHDK starts then you have the correct CHDK version for your camera.
I've tried many intervalometer scripts. Those on Ubasic work fine, those under Lua don't.That's because you have not installed CHDK correctly and are missing some required files. Lua is quite a bit more sophisticated than uBASIC and uses more files. uBASIC has limited features and does not need any additional files.
Is stick utility very different from acid ?ACID simply tells you what firmware version you have.
WW- Quick one: Regarding the video segment interval between stills in KAP 3.6. I'm trying to shoot a "miniature faking" segment (using the standard settings on the camera) between stills and in testing, altho the KAP script requests video shooting, the display simply goes blank on my 330HS and no video is recorded. Display comes back after the segment of 5 seconds is over.How do you know that the script requests video shooting? Does it say Video recording started on the LCD? It might help if you post the log file although video mode does not really log much.
WW- Indeed it says Video Recording Started. I have the display left on so I can see what KAP is doing. The screen goes blank after "Video Recording Started". Comes back after its done.
Attached the 2 Feb log entries.
tks
Dave
I suspect the issue is that the 330HS uses a separate button to start/stop video recording. I came about this suspicion when I looked at an older CHDK manual where the remote functions were described in detail. "If camera has a dedicated video button, will start and stop video using that button rather than the shutter switch."Thanks for that hint. The port was missing a definition, should be corrected (https://www.assembla.com/spaces/chdk/subversion/commits/4415) in releases r4415 and newer.
I suspect the issue is that the 330HS uses a separate button to start/stop video recording. I came about this suspicion when I looked at an older CHDK manual where the remote functions were described in detail. "If camera has a dedicated video button, will start and stop video using that button rather than the shutter switch."Thanks for that hint. The port was missing a definition, should be corrected (https://www.assembla.com/spaces/chdk/subversion/commits/4415) in releases r4415 and newer.
I wonder how to modifiy your script for recording lens temperature.All you need is a very simple change to the script's logging function. I'll post a modified script in a day or two after I find my camera to test the change.
Is there a way to have this function ?
The script handles cameras with a separate video button differently than those without a separate button. As I suggesterd earlier, that only works if the CHDK port is setup correctly for the camera. I'm glad srsa_4c spotted the missing definition as it saved me posting a test script to prove this out.
Still my mind with my balloon project. I wonder how to modifiy your script for recording lens temperature.Added in release 3.7 of script. Available at the usual download address (https://app.box.com/s/a5tbl1xasp8m3a57fclx).
Is there a way to have this function ?
Added in release 3.7 of script. Available at the usual download address (https://app.box.com/s/a5tbl1xasp8m3a57fclx).
My first tests was with 1 shoot / 5s. The scrip was sometimes crashing after 11 shoots. when it was (often) working, the ixus worked for 2h by -25°C in fridge (with light for exposure shutter).When you say the script is crashing, do you mean the script ends, or the whole camera shuts down?
1- CHDK start on the SD card. Chdk is it more stable with firmware update.This would be unusual. Normally, it shouldn't make any difference, and in the cases where there are problems it's usually the firmware update that has them.
2- I just drag and drop your downloaded script under OS X 10.11 on SD cardThis should not make the script unstable. If it runs at all, it shouldn't matter how you copied it.
I've tried your new script. I've a trouble that i already had before with your first scrip , but now it's stronger.In addition to reyalp's comments, I'd like to suggest that your problems are most likely not related to the script. To prove or disprove this, please rerun your refrigerator test using the simple interval.lua script that comes with CHDK at a 10s interval and see what happens.
My first tests was with 1 shoot / 5s. The scrip was sometimes crashing after 11 shoots. when it was (often) working, the ixus worked for 2h by -25°C in fridge (with light for exposure shutter).
I'v tried with 10 s and 7s. It always crash after few shoots. So i've tried again with your last script with 10 s and it always crash too.
the camera message isIs the clock set correctly on your camera? If it is, then this is an old romlog unrelated to the current errors.
...
Occured Time 2011:11:14 03:11:16
Task ID: 23461937
the camera message isI have a suspicion. Your cam might be broken. Try using it without CHDK for more than a minute.
a camera error was detected
will shut down
restart your camera.
call_event_proc("UI.Create")
call_event_proc("UIFS_WriteFirmInfoToFile",0)This will produce a text file in the root of the card.I have a suspicion. Your cam might be broken. Try using it without CHDK for more than a minute.Or his camera simply may not work well at -25 deg C (as I suggested a couple of posts earlier).
I have a suspicion. Your cam might be broken. Try using it without CHDK for more than a minute.
Well see srsa4. The camera shutdown after 1 minute with a E32 error >:(That's what I suspected - E32 means there's a problem with the image stabilizer. As far as I know, it's usually caused by a broken flex cable inside the lens unit (see ebay item 251353559253). That flex cable is also responsible for operating the mechanical shutter and the ND filter - if it breaks completely, you'll lose them too.
First of all my photos were all over-exposed with default settings-This is the second time this has been reported as an apparent issue. See :
What is the best way to reduce the exposure to normal levels? Is Exposure Compensation the way to go?Obviously it would be best to figure out why the pictures appear to be overexposed. Do you have that issue using the script to take images in normal lighting on the ground or just when the camera is "airborne"?
Secondly I run an NDVI filter on one of my cams, should I use the ND Filter setting or that would alter the results?Assuming the filter is mounted in front of the lens, you should probably set the ND Filter option in the script menu to Off.
I have attached the log file.There are several potentially interesting things in the log indicating that the camera / script was having trouble setting the exposure.
The camera was mounted on a quadcopter and was indeed being triggered by a usb cable. I am using a Pixhawk autopilot that also controls the camera trigger and shoots at regular distance intervals. The usb cable I used is the one sold by http://www.tuffwing.com/ (http://www.tuffwing.com/) .I'm not a pixhawk expert but it would be good to know how you set it up to trigger the camera.
2016Feb16 14:21:23 CHDK 1.4.1-4381 ixus240_elph320hs 101a Jan 27 2016
2016Feb16 14:21:23 Mode:PLAY,Continuous_AF:0,Servo_AF:0 Drive:0
2016Feb16 14:21:23 Tv:1/1000 max:1/2000 min:10 ecomp:0.0
2016Feb16 14:21:23 Av:4.0 minAv:2.8 maxAv:8.0
2016Feb16 14:21:23 ISOmin:100 ISO1:400 ISO2:800 M:0
2016Feb16 14:21:23 Focus:OFF Video:0 USB:2:1 Tmo:0
2016Feb16 14:21:23 AvM:2 int:1 Shts:0 Dly:0 B/L:0
2016Feb16 14:21:24 waiting on USB signal
2016Feb16 14:22:42 USB start signal received
2016Feb16 14:22:46 Mode switched to P
2016Feb16 14:22:46 Logger : log file updated.
2016Feb16 14:22:53 timeout after shoot full
2016Feb16 14:22:47.500 1) IMG_0048.JPG
2016Feb16 14:22:53 meter : Tv:1/200 Av:2.8 Sv:100 649:649
2016Feb16 14:22:53 actual: Tv:1/1000 Av:- Sv:400
2016Feb16 14:22:53 AvMin:2.8 NDF:NDout foc:infinity
2016Feb16 14:22:55 timeout on hook_shoot.is_ready
2016Feb16 14:22:55.760 2) IMG_0048.JPG
2016Feb16 14:22:58 meter : Tv:1/1000 Av:2.8 Sv:400 649:649
2016Feb16 14:22:58 actual: Tv:1/1000 Av:- Sv:400
2016Feb16 14:22:58 AvMin:2.8 NDF:NDout foc:infinity
2016Feb16 14:23:12 timeout after shoot full
2016Feb16 14:23:06.790 3) IMG_0049.JPG
2016Feb16 14:23:12 meter : Tv:1/200 Av:2.8 Sv:100 646:646
2016Feb16 14:23:12 actual: Tv:1/1000 Av:- Sv:400
2016Feb16 14:23:12 AvMin:2.8 NDF:NDout foc:infinity
2016Feb16 14:23:15 timeout on hook_shoot.is_ready
2016Feb16 14:23:15.050 4) IMG_0049.JPG
2016Feb16 14:23:17 meter : Tv:1/1000 Av:2.8 Sv:400 646:646
2016Feb16 14:23:17 actual: Tv:1/1000 Av:- Sv:400
2016Feb16 14:23:17 AvMin:2.8 NDF:NDout foc:infinity
2016Feb16 14:23:25 timeout after shoot full
2016Feb16 14:23:19.180 5) IMG_0050.JPG
2016Feb16 14:23:25 meter : Tv:1/200 Av:2.8 Sv:100 623:623
2016Feb16 14:23:25 actual: Tv:1/1000 Av:- Sv:500
2016Feb16 14:23:25 AvMin:2.8 NDF:NDout foc:infinity
2016Feb16 14:23:27 timeout on hook_shoot.is_ready
2016Feb16 14:23:27.440 6) IMG_0050.JPG
2016Feb16 14:23:30 meter : Tv:1/1000 Av:2.8 Sv:500 623:623
2016Feb16 14:23:30 actual: Tv:1/1000 Av:- Sv:500
2016Feb16 14:23:30 AvMin:2.8 NDF:NDout foc:infinity
2016Feb16 14:23:38 timeout after shoot full
CHDK bug would always select it after changing other settingsAFAIK, this is not a bug that anyone else has reported. However, it is very easy to enable it accidentally while working in <ALT> mode - CHDK has an annoying keyboard shortcut feature that can't be fully disabled.
What about the exposure issue? What do you think causes it?Do you get the same problem when you shoot without RAW enabled?
Ok it seems the RAW was getting enabled when I was accidentally pressing the debug button (it's a touchscreen).Correcting the exposure should only improve the "quality" of the pics.
The over-exposure issue happens whether with raw enbaled or not. Today did a couple of flights with exposure comp. set at -0.66 and that pretty mutch corrected it, but I'm worried it may alter the quality of the pics.
I'll have to wait till tommorow, it's almost 9pm here.No problem.
Yes. Point the camera at something and launch the script. It will switch to shooting mode if necessary and immediately take the two shots.
So I only copy the script in the scripts folder and just activate it?
Here is the result after setting the exposure comp to -0.66 : https://www.dropbox.com/s/135par85djmm6f7/IMG_0181.JPG?dl=0 (https://www.dropbox.com/s/135par85djmm6f7/IMG_0181.JPG?dl=0)I was a little worried that the ND filter is not being handled correctly but the exposure comp needed would need to be a lot more than -0.66 if that was so.
Also one more question, most flights are done between 40-60m do you think enabling focus at infinity would be a good idea? Some pics with default auto focus turn out a bit blurry.I would definitely recommend using focus at infinity for KAP and UAV work.
@WWHmmm ... that would certainly explain it. The result of having that #define missing when it's needed would be a one f-stop overexposure when CHDK attempts to set the SV96 value. I was hoping to see something like that with the test script I posted but tracking it down without your hint here would have been hard!
The ixus240/elph320 port doesn't redefine CAM_MARKET_ISO_BASE. Could that be the cause of wrong exposure?
I can clearly see a difference between the two, if that's what we're looking for.Thanks. That pretty much confirms a problem with the port. To confirm the source of that problem, can you please run the test script I posted above and report the results? Fixing the camera port will be easy if that confirms the cause.
I run the above script but it doesn't take a picture it just focuses and displays some ISO levels, If that's ok?That's perfect - thanks! It confirms that the ixus240/elph320 (and almost certainly the ixus255/elph330 based on previous posts) need to redefine CAM_MARKET_ISO_BASE in their platform_camera.h build files.
It always tries to correct the exposure by changing the shutter speed or the ISO levels and almost never the aperture f, I'm no camera expert but shouldn't that be the other way round? First "f" then ISO and as last resort shutter speed?That's because your camera does not have an adjustable aperture.
The vast majority of the pics have a set aperture of f/2.7.
Is it the way it's supposed to work?
Just FYI tried the focus at infinity for the 240HS and it falls in the category of non working. All the pics turn out blurry.On cameras where this happens, it's usually worst at wide angle lens settings. The script tries to set the focus at 50 metres (50000mm) but the setting that works best might be as close as one or two metres (1000mm).
Any updates on the fixed code for the 240HS?The issue has been fixed, please upgrade to the most current (http://mighty-hoernsche.de/) official release.
About one photo is missing ever 30 pics taken ... I have attached the log of one of the cams incase that helpsFor the camera that produced that log file, can you please tell me the image name (e.g. IMG_0284.JPG) that you think is before (or after) one of the missing images?
Relay mode, approx one photo missing from each camera no matter the time interval between the photos. Pretty consistant at -1 pic on every fight.As per my previous request, if you can identify the file name of the photo that occurred before the one that is missing it would help me to interpret the log that you posted.
Servo mode, mutch higher trigger speeds- less shutter lag. However in this case extra photos are a common scenario, the numbers vary, from +1,+2 to -1 on every flight.Extra photos? I'm not sure that I understand what an extra photo is? Again, image file names that I can cross reference with the log would help a lot here.
It almost looks like there is no way around it ?With over 5000 downloads of the script, I think it's fair to say it is pretty stable. So we just need to figure out what is happening here in your specific case.
Also is there a way to set the lens to extract once turning on the camera? Right now the lens extract upon first usb command which increases the shutter lag of the first photo alot.Well, you could start the camera in shooting mode in the first place? Just press and hold the On/Off button until you hear the lens extend when you power up the camera. Or half-press the shutter button to switch to shooting mode prior to launching your aircraft. I could add something to activate the lens when the script starts but that would have to be an additional option as most people seem to prefer the lens retracted during take-off and landing phases of a flight (for obvious reasons).
Problem is that I don't know exactly which photo is missing. When trying to geottag the software reads the Pixhawk flight log and identifies the camera trigger commands. If the tirgger command number and the picture number don't mutch then geottag is impossible.Does the geottag software not give an error message that identifies the image it can't find? Or can we look at the pixhawk flight log and CHDK script's log and figure it out for ourselves?
Is there a line I could add/ or modify to extend the lens prior to takeoff? Because right now the lens extend on the first camera trigger command and that increases the shutter lag of the first pic to around 2.5sSure, but did you read my previous response for two options that don't require modifying the script?
Well, you could start the camera in shooting mode in the first place? Just press and hold the On/Off button until you hear the lens extend when you power up the camera. Or half-press the shutter button to switch to shooting mode prior to launching your aircraft.
if ( wait_for_usb_active() == false) then -- can we start ?
printf("Menu key exit request")
restore()
return
else
printf("USB start signal received")
usb_shooting_mode = 2
end
I tried holding the on/off button and half pressing the shutter but it has no effect, the lens remain closed.Sorry - should have been clearer. You need to do either of those things prior to entering <ALT> mode and starting the script. In the case of the On/Off button, you should be able to turn the camera on in shooting mode (i.e. lens extended) by holding down the On/Off button rather than just pressing it quickly. The half press trick works when the camera is NOT in <ALT> mode (and the script not running).
The flight log - as far as cams are concerned only records cam_trigger commands and GPS co-ordinates.Does it time stamp each record?
The flight log does time stamp every action recorded. Using GPS time.Perfect. Should be possible to match up the "missing" shot if that's the case - the kap log is timestamped to .001 seconds. Once you align the first shot, the rest should fall in line until the miss or extra shot shows up.
Just tried the code modification you suggested (Deleted the exact lines you posted). The lens do exctract but only for about 4 seconds and then retract back again.There is a script parameter that you can set to control this. No code modifications required. It's called
It is already set at 0 when tha's happening.Yea, deleting that code also requires one more small change to work properly.
I set the camera activate and retract by rc radio. However, lens retract after 60 sec. I would like the lens response without a delay.You can find that setting in the Canon menu.
To be a little more specific, the setting is usually in the Canon menu with the tools icon and says Lens Retract. Set it to 0 sec.I set the camera activate and retract by rc radio. However, lens retract after 60 sec. I would like the lens response without a delay.You can find that setting in the Canon menu.
I have a photo number discrepancy again. Pixhawk commanded 36 pics to be taken but 38 were actually shot.Thanks for posting those logs. It took a bit of work to figure out the pixhawk log but I eventually got it. And I'm pretty sure I know what is happening.
Here is the link to the Flight log and KAP log : https://drive.google.com/folderview?id=0B-Ks32HaA8XZelJZYW1TZFdmelU&usp=sharing
Fist pic is: IMG_1811 Last pic: IMG_1848. I'd appreciate if you could take a look.
if not wait_for_shoot_pulse(5000) thenI also added a shut_down() function after the same "if" statement for the camera to shut down after the mapping is complete and protect the lens.That will cause the camera to power down with the shooting "half-press" still engaged. You will also lose the last parts of the log file and any configuration things modified by the script will not be reset.
--[[
KAP UAV Exposure Control Script v3.7
Licence: GPL (c) 2013, 2014, 2015, 2016 by waterwingz
-- with contributions from wayback/peabody & Naccio
Please check for the latest version (and documentation) at :
http://chdk.wikia.com/wiki/KAP_%26_UAV_Exposure_Control_Script
@title KAP UAV 3.7
@chdk_version 1.3
@param i Shot Interval (sec)
@default i 2
@values i Burst Fast 2 3 4 5 10 15 20 30 45 60 90 120 180 240 300
@param o Shutdown (minutes, 0=never)?
@default o 0
@range o 0 240
@param s Total Shots (0=infinite)
@default s 0
@range s 0 10000
@param j Power off when done?
@default j 0
@range j 0 1
@param b Display Off?
@default b 1
@values b No Yes Delayed
@param d Start Delay Time (sec)
@default d 0
@range d 0 60000
@param g Exposure Bracketing
@default g 0
@values g Off +/-0.33 +/-0.66 +/-1.00 +/-1.33 +/-1.66 +/-2.00
@param e Exposure Comp (stops)
@default e 5
@values e -2.0 -1.66 -1.33 -1.0 -0.66 -0.33 0.0 0.33 0.66 1.00 1.33 1.66 2.00
@param z Zoom position
@default z 0
@values z Off 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
@param c Focus @ Infinity
@default c 1
@range c 0 1
@param y Tv Min (sec)
@default y 5
@values y None 1/60 1/100 1/200 1/400 1/640 1/800 1/1000 1/1250 1/1600 1/2000
@param t Target Tv (sec)
@default t 7
@values t 1/100 1/200 1/400 1/640 1/800 1/1000 1/1250 1/1600 1/2000 1/5000
@param x Tv Max (sec)
@default x 3
@values x 1/1000 1/1250 1/1600 1/2000 1/5000 1/10000
@param f Av Low(f-stop)
@default f 1
@values f 1.8 2.0 2.2 2.6 2.8 3.2 3.5 4.0 4.5 5.0 5.6 6.3 7.1 8.0
@param a Av Target (f-stop)
@default a 2
@values a 1.8 2.0 2.2 2.6 2.8 3.2 3.5 4.0 4.5 5.0 5.6 6.3 7.1 8.0
@param m Av Max (f-stop)
@default m 13
@values m 1.8 2.0 2.2 2.6 2.8 3.2 3.5 4.0 4.5 5.0 5.6 6.3 7.1 8.0
@param p ISO Min
@default p 0
@values p 80 100 200 400 800 1250 1600
@param q ISO Max1
@default q 2
@values q 100 200 400 800 1250 1600
@param r ISO Max2
@default r 3
@values r 100 200 400 800 1250 1600
@param n Allow use of ND filter?
@default n 1
@values n No Yes
@param v Video Interleave (shots)
@default v 0
@values v Off 1 5 10 25 50 100
@param w Video Duration (sec)
@default w 10
@range w 5 300
@param u USB Shot Control?
@default u 2
@values u None On/Off OneShot GntWire Pixhawk
@param k USB Timeout (secs 0=off)
@default k 60
@range k 0 240
@param h Shot Sync LED
@default h 0
@values h Off 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
@param l Logging
@default l 3
@values l Off Screen SDCard Both
Spares : none
--]]
it works very well but the display off function let the display go on every time it takes a picture, then goes off again, is this normal or I made some mistakes?The display should stay off and not come back on after each shot when the Display Off function is enabled. However, you need to set the Review setting in the Canon shooting menu to Off for this to work. Do you have it set that way ?
Camera mode in "P" or Program (not Auto, M, SCN, or Live)
ISO in Auto
Continuous AF Off (setting the camera in P mode will automatically turn this off on cameras without this menu option)
AF Frame not in Tracking AF
Servo AF Off
Safety MF Off
IS Mode Off (may not be necessary for KAP but should be off for UAV)
Review Off
Lens retract 0 sec.Yes I have set Review OFF, all the settings here:Okay - that's good. It turned out that was the problem here : link (https://chdk.setepontos.com/index.php?topic=10822.420)
CHDK reset to default, however I can't remove the disable overrides option, I remove and it returns, maybe the script wants itThe script will work either way. The reason it turns off is likely the "Disable Overrides on Startup" menu option at the very bottom of the CHDK Enhanced Photo Operations menu. If it is selected then deselect it.
In attachment the file requested and a video too, thank youThanks for the video and log. I can reproduce the problem now. Might take me a bit to fix and test - I'll post something to try shortly and add the fix to the next script updated this weekend.
Wow this is great, thank you very much! :xmasTry this?
Try this?waterwingz (what's your name?) I had packed my equipment and was going to sleep then I saw your message so went back to test the script and it works, problem resolved!
I had packed my equipment and was going to sleep then I saw your message so went back to test the script and it works, problem resolved! Tomorrow I will go to make some flights, saturday I will come back and let you know if it worked after hundreds of pictures.So, because I am evil, I will point out that you are using the USB "OneShot" mode with your Pixhawk UAV. Which limits you to about one shot every 2 seconds (at best).
Sure I will, very interesting, and if you check the latest apm plane 3.5.1 / 3.5.2 it seems it can log the picture number, I don't know if we can apply it to cameras without external flash, see you soon and thanks again!I had packed my equipment and was going to sleep then I saw your message so went back to test the script and it works, problem resolved! Tomorrow I will go to make some flights, saturday I will come back and let you know if it worked after hundreds of pictures.So, because I am evil, I will point out that you are using the USB "OneShot" mode with your Pixhawk UAV. Which limits you to about one shot every 2 seconds (at best).
But your Pixhawk and CHDK can get down to 2 shots per seconds! Depending on what you are doing, that may not matter. But if you get to the point when you want to shoot that fast, check back here?
Sure I will, very interesting, and if you check the latest apm plane 3.5.1 / 3.5.2 it seems it can log the picture number, I don't know if we can apply it to cameras without external flash, see you soon and thanks again!Now that is interesting!
I'd love to try using the kap log to provide the time information for geotagging but can't find any software which will accept image time information from an external source - any ideas?The script log was originally setup to be easy to import into a spreadsheet. That's still possible but there is now a lot of additional information in there that can be hard to filter out. Cleaning that up is on my "to-do" list so if you can give me a better idea about what you are trying to do I might be able to help. I've given some thought to having the option of two logs - one like the existing one and the other just containing picture info - perhaps formatted as XML. Seems like it would not be too hard to write a PC script to take that log info and insert it into each image EXIF data for example.
,
I'd also be very interested in how precise the GPS clock sync on the S100 would be relative to the clock on the Pixhawk (also GPS synced) if anyone happens to know?You might be on your own with this one. Perhaps some on the ground testing with the pixhawk and camera might tell you something if you can figure out a common way to sync.
I have posted a query to the Mission Planner devs asking if they could add a feature to import the KAP script log info to their geotag utility, so will see what happens. Ideally I want to be able to geotag images to cm precision whilst flying. A secondary RTK GPS will provide flight path information, either (ideally) from the Pixhawk dataflash logs, or from the GPS system logs with post processing. As I am already using the S100 and CHDK/KAP script for mapping it seems worth putting some time into getting the most out of the hardware - though it will depend how accurately the GPS clocks on the pixhawk and S100 are synced.If you are going down that path anyway, the idea of having the pixhawk log the exact point at which each photo is taken via a digital input watching one of the camera LEDs might be something to pursue again.
Yep - the next release of Copter (3.3.4) will support triggering of a log message via the hotshoe of a camera so will probably look in that direction. I guess that feature could be adapted to use a photoresistor and the flash sync LED.I don't think any Canon P&S cameras have a "flash sync" LED (i.e. an LED that fires at the exact moment the shutter opens for sync with an external flash).
So, because I am evil, I will point out that you are using the USB "OneShot" mode with your Pixhawk UAV. Which limits you to about one shot every 2 seconds (at best).
But your Pixhawk and CHDK can get down to 2 shots per seconds! Depending on what you are doing, that may not matter. But if you get to the point when you want to shoot that fast, check back here?
Can the Canon EOS M3 run the KAP script by default?Based on what reyalp reported in the EOS M3 porting thread, the M3 port is incomplete and doesn't support exposure adjustment. So the value of the kap_uav.lua script would not be much at that point.
EOS M3 porting
I looked at the existing source a some more and it's less complete than I initially thought. capt_seq was not implemented at all, and it uses propset6 with no modifications. This means that essentially no shooting functions will work.
Just a quick report, I have had some success with accurate geotags using the KAP log time stamps - the time stamping is accurate enough to be useful in combination with post processed RTK GPS data, I have achieved sub metre precision, with the majority of tags within 30cm of the calculated image positions using Pix4d. This is the limit of accuracy of the GPS system at the moment, bu with more accurate position data clock syncing between GPS becomes even more of an issue.
Unfortunately the S100 GPS clock sync is not accurate enough - I have had to use trial and error to discover an offset which works for a given project, not impossible but time consuming.
I guess the S100 internal clock received GPStime, applies the UTC offset and rounds to the nearst second at some point? A shame as it clearly could get an accurate sync in terms of hardware...
Does the time wrote by the script differs from the time wrote by the camera in the exif of the photo?I would be amazed if the two times were different. But understand that the script log resolution is better than 0.01 Sec - the exif info is usually only in increments of one second.
Most probably I messed up a setting somewhere working on the new interface, but I have no idea where.Please post your most recent log file as an attachment here.
The images I have been getting are at least 2 stops overexposedWhat version of CHDK are you using? There is a bug in some versions with ISO settings that is unrelated to the script.
The images from this camera are terribly grainy so I was hoping to lock the iso at 100 and chance a slower shutter speed. If someone could point me in the right direction I would be most appreciative.The CHDK script parameters for the kap_ uav.lua script let you specify the ISO range that will be used. No editing of the code is necessary. It's all right there in the CHDK script menu if you scroll down far enough.
What version of CHDK are you using? There is a bug in some versions with ISO settings that is unrelated to the script.This camera doesn't have CAM_MARKET_ISO_BASE set, and probably should since it's DryOS R50.
Im using version 3.7. Isobase says base=200 set can_market_is I_base_200The fix for your issue was added to CHDK yesterday. If you download and reinstall CHDK your issue with 2 stop overexposure will be fixed. You can keep using the same version of the script.
the file it downloads tonight would have the fix applied?Yes. To be certain, you could manually delete the earlier file first.
function ch2up(pwidth)
if( repeat_check("ch2up",pwidth ) >= PWM_required_repeats ) then
usb_shooting_mode = 0 -- put camera into playback / sleep mode
in_continuous_mode = falsewhere the script write the options of the KAP_UAV? I want to make backup of mine SD cards and I am only copying the kap_uav_3-7a.lua but I would like to backup the options I select too, do I have to edit the script and set them as Default?CHDK saves the parameter values used by any script in the A/CHDK/DATA folder on your SD card. If you look at the files in that folder, you will see at least two files for each script you have run that have the same filename as the script.
continuous mode = "Burst", right?I'm not sure what you are asking me here and why you are asking. So providing a good answer might be tough.
is there a specific reason for the: in_continuous_mode = falseThat particular piece of code is called when a specific PWM signal is received (typically from a flight controller). It was intended to allow the flight controller to halt (or reset) a continuous mode shooting sequence. To do so, it changes a couple of variable that are used to control the shooting state - including the one that indicates the camera is currently shooting in continuous mode.
how can I turn off the camera gyro? I have half the pictures as landscape the other half(due to a maneuver in the air ) as portrait.I don't think the camera records a different image based on orientation.
I bought an SX200IS, ... Can you please help me get it down to .5s (as the S110)?This is technically not possible. See the specifications for the SX200 (http://www.dpreview.com/products/canon/compacts/canon_sx200is/specifications) - Continuous drive 0.8 fps.
Well, 0.8 fps is 1.25 seconds per shot. Which is better than 1.8 seconds per shot.I bought an SX200IS, ... Can you please help me get it down to .5s (as the S110)?This is technically not possible. See the specifications for the SX200 (http://www.dpreview.com/products/canon/compacts/canon_sx200is/specifications) - Continuous drive 0.8 fps
Do I absolutely need a DIGIC V with CMOS for the 2fps or there a DIGIC 4s with CCD that can have that?As msl suggested, the Canon specification for continuous shooting will give you an upper bound on the possible shooting rate. CHDK will never be much faster, and depending on the particular script and settings may be significantly significantly slower.
waterwingz APM PLane software is ready to log from hotshoe feedback:I guess if you have a camera with a hotshoe then this could be interesting. Unfortunately most small cameras suitable UAV work do not have one. The ability of kap_uav.lua to blink an LED when the shutter opens, coupled with a little extra hardware, might be useful instead.
However, I have a customer with a different S110. His flashes the LED for close to 1 second. That causes extra CAM events in the Pixhawk log. A resistor change may help hold the hi / lo state, but I'd like to figure out why the LED stays on so long on his S110. It's not the shutter speed. That will make the LED stay on if you make it long.If all the hardware is the same then i guess that leaves two options.
Any idea where to start?I can add something to log the actual on & off times for the LED if you can get him to run a test version and report back.
That'd be great. Let me know where to download. Thanks!Test version : https://app.box.com/s/xm53d9wuu8pj2y6go674zx6uw9ckrl1z
When you say "fast" and "burst" modes are you talking about Shot Interval (sec) fast and burst?Yes.
Also, what should Shot Interval (sec) should be set to if using USB trigger type "OneShot"? There used to be a setting for "0".I guess that's not exactly clear. If you are using any of the USB trigger types, then setting Shot Interval to Burst will shoot in continuous mode (i.e. with "half-press" maintained and the shots triggered by a full press only.) Setting it to Fast (or any number) causes each shot to do a full half-press - full-press sequence for each shot.
What do you think is causing the extra un-triggered pictures?This was discussed recently here ( https://chdk.setepontos.com/index.php?topic=10822.msg127196#msg127196 )
Here's the log with LED flash duration. Seems to be well under a second. Not sure why I thought it was slower.Thanks. Individual shots clock in at 3/4 of a second - continuous mode shots running 0.4 seconds.
Do you have another recommendation for a point and shoot like the S110 that can be USB triggered? S110s are great, but getting really expensive and hard to find. Other Canon point and shoots just aren't as clear.AFAIK every CHDK enabled camera can be USB triggered. I wrote the code currently in use so there is a 50:50 chance I know what I'm talking about here. 8) The trick is probably finding a Powershot that is CHDK supported, commercially available, and not brutally expensive. The Canon refurb store is a great source but it's hit and miss as to what they have available.
it's hard to get to the MENU button to turn it off...in the past, I've just used the shutter button, which would be far easier. Is there a setting that I'm missing?The default CHDK method of using the shutter button to halt a script essentially stops the script dead in its tracks. So the kap_uav.lua script disables that action. This allows the script time to clean up and close its log file - something not otherwise possible even when the script uses the "restore" functionality.
I tried to setup the shutter as requested on vendors page (http://www.mobilexcopter.com/files/Simple_multi_shutter_Pixhawk_settings.pdThanks for the link - I had not seen that page before.
I installed the latest CHDK and the latest KAP_UAV Script on the camera and configured it according to the wiki page.Thanks for attaching your log file. Everything looks correct in your setup but the log entries show that the pulses the camera sees from the pixhawk seem to be somewhat random in length.
How do I need to configure the CAM_Duration to make this work properly ? I tried 0, 1 , 5 , 10 but none of these seem to produce a reproducible result.As I don't own a pixhawk I will check this with someone who does and uses the script.
Is this some issue of the shutter cable or does the script need some adjustment to work with that cable and the pulse it sends ?
Can someone point me in the right direction?The script ignores all of the settings from the CHDK USB remote menu so it does not matter how you set them.
Of course! Meant to and forgot, here's the log.Thanks. I took a quick look and did not see anything wrong with your setup. There were a lot of changes recently made tuning "pixhawk" mode for sub one second shooting. It's possible something broke in "gentwire" mode as a result. I don't think many people are using that device so a new bug may not have surfaced yet. I'll take a closer look tonight at the logic.
Of course contact me if your want more informations about this flight !Or you could post an update here?
I don't really undestand your questio but I'll reply with pleasure. Do you want more pictures ? KAP log ?The log file would be interesting.
I'm not sure it would be an issue with the logic of the script. It was working for me last week, albeit slowly. I can't figure out why it would be going into continuous mode. And I think the way it was working last week isn't working now. I'm pretty new to using this, sorry i'm not more definite. I was hoping it would be a no brainer, but maybe not.Haven't forgotten this. I just need to find my Arduino clone kit that simulates a gentwire 2 for testing. Hang in there.
(snip)Hello cndnflyr! What board are you using? Can you post you APM configuration parameters?
I'll see what i get when it's going through the pixhawk.You could also connect the gentwire2 directly to the camera and validate that the kap_uav.lua script will work with it directly (it should).
After modifying the script, here are the stick and result combinations:
Throttle, Pitch, Result
down, middle, 6
down, down, 8
down, up, 3
middle, middle, 15
up, middle, 12 (keeping the pitch in the middle, as I move the throttle up and down I get values from 12 to 19)
Moving the throttle gives me values between 12 to 19 regardless of where the pitch is set
Same with the Pitch. Leaving the throttle in one position (doesn't matter which), moving the pitch gives me values between 3 and 9.
Movement of the RC Transmitter stick from one extreme to the other will send a single trigger to the camera at either end and in the middle. The example scripts, or user generated scripts, can detect the following pulse lengths on the USB power with the get_usb_power function which counts with 10mS resolution:
Channel 1 USB Pulse Channel 2 USB Pulse Low position 30mS Low position 120mS Mid position 60mS Mid position 150mS High Position 90mS High Position 180mS
In addition to the above, a 210mS pulse will be sent every 5 seconds if neither servo is connected to a RC receiver. If the RC receiver looses communication with the transmitter and the receiver stops sending pulses to the servos, then the USB output will go high continuously until communication is re-established.
[/t]
Didn't have time to try different things today, but the modified test script showed a constant "6" when plugged into the Pixhawk. I suppose I need to figure out how to get other values.Try setting these APM params:
One thing I haven't quite understood is the parameters necessary in Mission Planner to get the two channels working. I haven't come across examples of this yet. I'm assuming two AUX ports would be set to something, but it won't let me have two set to camera trigger. Ah well, for tomorrow.
Super! It works flawlessly now. Thank you for the suggestion. Could you explain what the difference was?Glad I could help! :)
I posted earlier about getting the script to work and I managed to get it to work with the SimpleShutter cable from http://www.mobilexcopter.com. I managed to trigger the camera using my pc version of mission planner and my RC (chan7).Please copy the KAP.LOG file from the root folder of your SD card and attach it to a post here.
I tried to use 3DR Tower software to use the structure scanner to fly over an area and automatically take pictures. As S90 is not available in the Tower software I chose S100 but it does not seem to take any pictures. CHDK is running and the KAP_UAV Script is running as well.
Do I need the script ?It's possible to trigger shots with just the CHDK USB Remote settings. But it all depends on how you have your flight controller software configured.
I actually wanna trigger the camera via the 3DR Tower Software on my android tablet but as there is no S90 to choose, I chose S100 in there.I took a very quick look at the 3DR Tower git repository but it was not clear what the camera setting is supposed to do. Certainly the code has no way to know if you have an S90 or S100 attached.
Here is my KAP.log for today:From your log file, it does not look like your system is toggling the USB line to the camera at all. So this does not appear to have anything to do with CHDK or the kap_uav.lua script.
I am not even 100% sure this is the right place but I am a bit unsure how to debug that.I notice you've posted this issue over on the ardupilot forum (and possibly elsewhere?). That's probably a better place to get an answer.
Acording to the maker of my shutter cable, the pulse sent to the chdk script is hat the pixhawk outputs (like it mirrors it).This one ? Simple Canon shutter - Pixhawk version (http://www.mobilexcopter.com/shop.htm#!/Simple-Canon-shutter-Pixhawk-version/p/53286831/category=15393052)
How long should a pulse be at least for the OneShot Mode ?It should catch anything longer that a couple of milliseconds.
What does this log tell me ? (It shot 1 picture at the beginning but that's all)Basically, it tells you what you just said - i.e. it shot 1 picture at the beginning but that's all.
I am still wondering if it's some issue of the Tower App or the pulse sent or the App doesn't correctly send the commands to trigger but the people there are a bit unresponsive so maybe I need to dive into the app code ...At this point, I don't think it the kap_uav.lua script, or how you have set it up, that is causing the problem. So I've attached a simple script that measure the width of each USB pulse and prints the result to the camera LCD. It also reports the time between pulses. You might want to use it to test if pulses are being generated (and how long they are) while you work on your flight controller setup. Should be accurate down to about 1 mSec resolution.
Going to do some tests :)You can ensure the USB test script is working by using a standard USB cable between your camera & PC. Just plug & unplug the cable a few times while the script is running and your should see timing values scroll up the screen.
this set wrong?That looks like a normal log file. Are you having a problem with using the script? Can you tell me what is not working? And tell me what equipment you are using?
The picture (Attachment) is not in focus. The problem is the set uav.kap or the UAV vibration?Blurred UAV pictures can be caused by several things. Determining the actual cause can take some time and patience.
However, I have a customer with a different S110. His flashes the LED for close to 1 second. That causes extra CAM events in the Pixhawk log. A resistor change may help hold the hi / lo state, but I'd like to figure out why the LED stays on so long on his S110. It's not the shutter speed. That will make the LED stay on if you make it long.If all the hardware is the same then i guess that leaves two options.
The most likely option would be some difference in either the Canon menu settings or the CHDK settings. I'm not too sure what that might be but having RAW Enabled (either Canon RAW or CHDK RAW/DNG) would certainly do it.
The other option might be a slow SD card, or maybe an almost full one, or one with a really large log file. The script writes to the log file in between the points where it turns the LED on and off.QuoteAny idea where to start?I can add something to log the actual on & off times for the LED if you can get him to run a test version and report back.
I'm going to install an emlid RTK system, how about using the Canon S110 LED to log picture time, is it possible and how to do it? I bought a cable for Sony hotshoe, easy to remove the hotshoe adapter and the RTK has a logging software.I'm not sure that I fully understand your request. The existing script already has the ability to "blink" any of the camera's LEDs at the exact moment the exposure starts (or at least as close as technically possible). Do you need something else or different?
What is the parameter on the script and how do you catch the "blink" of the led on the S110? Thank youI'm going to install an emlid RTK system, how about using the Canon S110 LED to log picture time, is it possible and how to do it? I bought a cable for Sony hotshoe, easy to remove the hotshoe adapter and the RTK has a logging software.I'm not sure that I fully understand your request. The existing script already has the ability to "blink" any of the camera's LEDs at the exact moment the exposure starts (or at least as close as technically possible). Do you need something else or different?
What is the parameter on the scriptEvery Canon P&S camera is a bit different from the others. But a CHDK script can turn each of the camera's LED's on & off. It does this using the LED number - which is simply a value assigned during CHDK porting to each LED by the developer. There is no standardization about what number turns on which LED as each camera is different. So you have to either read the developer's notes (usually in the camera's lib.c file), or pick the number by trial & error, or use a small script that scrolls through all values slowly allowing you to figure out what number corresponds to each LED.
<snip>
I found this:
@param h Shot Sync LED
@default h 0
@values h Off 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
and how do you catch the "blink" of the led on the S110? Thank youI'm not sure that you understand what is intended here? The script will cause your camera (your S110) to turn an LED on when the camera's shutter opens, and off again shortly after it closes. It's up to your flight controller and its hardware to detect that "blink" and do something with it.
Yes mate, I am searching for someone who already did the hardware to detect the "blink"I worked with bchristal (http://chdk.setepontos.com/index.php?action=profile;u=27439) on the original implementation. You can try sending him a PM and I'll send him an email directly to ask.
PM sent, thank you very muchYes mate, I am searching for someone who already did the hardware to detect the "blink"I worked with bchristal (http://chdk.setepontos.com/index.php?action=profile;u=27439) on the original implementation. You can try sending him a PM and I'll send him an email directly to ask.
PM sent, thank you very muchIt would be good if you can share anything you learn.
Brian pointed me to this beautiful cable http://tuffwing.com/support/Install_a_canon_precision_geotag_cable.htmlPM sent, thank you very muchIt would be good if you can share anything you learn.
I made some tests with a phototransistor I have removed from a remote, Canon S110 LED blinks too fast for me to catch the Voltage on the meterYou could use a simple script to activate the LED for longer periods for testing purposes.
Be aware that the tuffwing Canon IR cable actually sends 3.3V and not 5V like I said before, my faultTechnically the tuffwing Canon IR cable does not "send" anything - 3.3V or 5V. It contains a phototransistor that acts as a switch that changes to a low impedance state when enough light enters it's lens (causing a base to emitter current that allows a much larger collector to emitter current to flow). So the three wires in the cable hook to +V, GND, and signal from the flight controller. I suspect it will work just as well with V=3.3V as it does with V=5V.
In this case, cable for log photo time, it is the module that sends an on or off signal to the pixhawk (signal) pin.Be aware that the tuffwing Canon IR cable actually sends 3.3V and not 5V like I said before, my faultTechnically the tuffwing Canon IR cable does not "send" anything - 3.3V or 5V. It contains a phototransistor that acts as a switch that changes to a low impedance state when enough light enters it's lens (causing a base to emitter current that allows a much larger collector to emitter current to flow). So the three wires in the cable hook to +V, GND, and signal from the flight controller. I suspect it will work just as well with V=3.3V as it does with V=5V.
In this case, cable for log photo time, it is the module that sends an on or off signal to the pixhawk (signal) pin.Agreed!
In this case, cable for log photo time, it is the module that sends an on or off signal to the pixhawk (signal) pin.Agreed!
At the risk of being pedantic (https://www.vocabulary.com/dictionary/pedantic), the module gets 5V or 3.3V from a flight controller and returns that voltage to one of the flight controller's inputs when the camera shutter is open as indicated by the designated camera LED.
My point is that the module does not "source" any power - it simply switches a voltage that it gets from the flight controller back to the flight controller when the camera LED is illuminated. So the cable should work for flight controllers that use 3.3V or 5V.
I'm not an electronic expert but I can't buy from USA right now so I have to try to make this cable by myselfDo you have the circuit diagram that you need? And a suitable photo-transistor?
Can you point me to a script that leaves the S110 LED ON?Simple script attached.
I have some photo diodes (2 legs only) 5 and 8 mm and some BC547 BC557 I usually put on the pixhawk shutter cable circuit, the circuit diagram is what I am trying to discover
This is my first post here. I've done some research, but have not seen an answer to my, hopefully simple,problem.Please post the kap.log file from the top level folder (root) of your SD card as an attachment here.
added improved LED sync code to create shorter "on time" for syncing with pixhawk flight controllerIf you remember you created 3.7a because it was not shutting off the display in 3.7
What is the difference between USB shot control "One shot" and "Pixhawk"?In "One shot" mode the camera will focus, set exposure, and shoot each time the USB +5V signal activates.
I am using One shot with pixhawk by one year with success, I have a circuit that input 5V and 3.3V relais and output 5V to the USB cable, am I outdated with this setup?No.
Shot Interval is set to Fast is it ok?Yes.
p.s. I have the same problem I had with 3.7 the display turn off but turn on again when shooting photoSo are you saying that the display would not stay off in 3.7 but 3.7a worked properly? And now 3.8 does not?
Comparing 3.7 to 3.7a the only difference is on line 966
if( not(is_key("no_key")) and not(is_key("remote")) and (backlight_saver>0) and (blite_timer==0)) then
but 3.8 is identical to 3.7a :( ?!
This is my first post here. I've done some research, but have not seen an answer to my, hopefully simple,problem.Please post the kap.log file from the top level folder (root) of your SD card as an attachment here.
Thanks. Here it is.Ummm .. the most recent entry in that log file is from Sept 29 2016? Which suggests these possibilities :
So are you saying that the display would not stay off in 3.7 but 3.7a worked properly? And now 3.8 does not?I have formatted, installed everything from scratch and now it works, sorry for the false alert
Thanks. Here it is.Ummm .. the most recent entry in that log file is from Sept 29 2016? Which suggests these possibilities :
- the time is set incorrectly in your camera?
- you accidentally (or purposely?) disabled the script log function using the script parameter choices in the CHDK Script menu?
- you did not get this log from the card that was actually in your camera when you saw the double exposures?
In any case, that log file does not have any shooting information so it's not going to be any help. I was really hoping to see what the log said about the script options you selected and to see the very detailed information it keeps about each shot.
If we can't solve this, you will probably need to get a new log by doing another shooting run so that I can see what's happening.
Best I can offer. Sorry.
I have several cameras. Here is another log file with more detail.That's better - thanks for posting that. I now understand what is happening.
1) I tried the "turn display off" setting but it dos not work. When I have the script triggered from USB or when I have the script on "every 10 seconds", after the first picture the display stays off, but the second picture will turn the display on again and it stays like this. Can this be fixed somehow?I don't have my S100 handy right now but the code has been extensively tested with that camera so I'm very sure the display off function works. And I just tested this on my G10 and it works as expected there too.
2)Since I want to use the script to trigger a picture after 5-10 seconds I want to geotag the pictures using a photodiode as mentioned in the posts before. I tried some settings and the shot-sync-led: 10 will make the front led to light up 3 seconds after every shot.FWIW, the S100 can shoot at two frames a second continuously using the kap_uav.lua script. And as it happens, there is currently an active thread here on the forum discussing exactly what you are looking for :
Is there any manual how to build a cable for the pixhawk's digital input using a photodiode - I could not find anything.
But I can not find the Setting Shot Review in the regular Canon menu - or is it within the CHDK menu?The Canon menu (the one you get when you press the Menu button) is different in shooting and playback modes. You need to be in shooting mode (i.e. lens extended) and then look for this :
Is the USB shot control for Pixhawk camera model specific?There is nothing camera model specific in the script. Most likely what is happening here is that you have the script configured differently or something in the Canon setup configured differently. There is also a small chance of a bug in the CHDK port for your A3400.
Is the USB shot control for Pixhawk camera model specific?There is nothing camera model specific in the script. Most likely what is happening here is that you have the script configured differently or something in the Canon setup configured differently. There is also a small chance of a bug in the CHDK port for your A3400.
The first step in figuring this out is to look at the script's log files. Please post the KAP.LOG file from both camera as attachments here. You will find them in the top level folder of your SD cards..
Is the USB shot control for Pixhawk camera model specific?There is nothing camera model specific in the script. Most likely what is happening here is that you have the script configured differently or something in the Canon setup configured differently. There is also a small chance of a bug in the CHDK port for your A3400.
The first step in figuring this out is to look at the script's log files. Please post the KAP.LOG file from both camera as attachments here. You will find them in the top level folder of your SD cards..
Here are two files. The log from the A3400 configured to use USB Shot Control as OneShot and the A3400 configured to use USB Shot Control as Pixhawk.A quick look at those logs shows me that both were run in "One Shot" mode. Look for :
Here are two files. The log from the A3400 configured to use USB Shot Control as OneShot and the A3400 configured to use USB Shot Control as Pixhawk.A quick look at those logs shows me that both were run in "One Shot" mode. Look for :
Focus:AF Video:0 USB:2:1 Tmo:0
in the log. The "USB:2" means one shot mode. Pixhawk mode is "USB:4".
Please post a log file with your A3400 set to pixhawk mode. It would be nice to see the results of taking a couple of test shots too - don't just stop the script and dump the log please. (Logs with both One shot and Pixhawk modes selected please).
In the meantime, I'll find one of my debug scripts that dumps a lot more info to the log file so that we can see if your A3400 CHDK port is possibly buggy.
Also, if you look at KAP UAV Exposure Control Script : Camera Settings (http://chdk.wikia.com/wiki/KAP_UAV_Exposure_Control_Script#Camera_Settings) it is strongly suggested that you turn off Continuous Autofocus and Servo Autofocus in your camera's Canon menu. In all three logs, you have it turned on. That's most likely not related to your pixhawk problems but could cause other focus related issues later.
edit : my last comment in this post may explain why your A4000 log has entries that say : Warning:MF enable failed***
Here are two files. The log from the A3400 configured to use USB Shot Control as OneShot and the A3400 configured to use USB Shot Control as Pixhawk.A quick look at those logs shows me that both were run in "One Shot" mode. Look for :
Focus:AF Video:0 USB:2:1 Tmo:0
in the log. The "USB:2" means one shot mode. Pixhawk mode is "USB:4".
Please post a log file with your A3400 set to pixhawk mode. It would be nice to see the results of taking a couple of test shots too - don't just stop the script and dump the log please. (Logs with both One shot and Pixhawk modes selected please).
In the meantime, I'll find one of my debug scripts that dumps a lot more info to the log file so that we can see if your A3400 CHDK port is possibly buggy.
Also, if you look at KAP UAV Exposure Control Script : Camera Settings (http://chdk.wikia.com/wiki/KAP_UAV_Exposure_Control_Script#Camera_Settings) it is strongly suggested that you turn off Continuous Autofocus and Servo Autofocus in your camera's Canon menu. In all three logs, you have it turned on. That's most likely not related to your pixhawk problems but could cause other focus related issues later.
edit : my last comment in this post may explain why your A4000 log has entries that say : Warning:MF enable failed***
Ok I know why the log showed USB:2, its because it was the log from the previous attempt when I had it set to OneShot. When I set it to Pixhawk, no log gets created and the display doesn't get past 'waiting on USB'. I even tried to plug it into the USB port on my laptop numerous times but the script doesn't go past 'waiting on USB'. This model does work though when it is set to OneShot.So the USB is working. That's a good start.
Ok I know why the log showed USB:2, its because it was the log from the previous attempt when I had it set to OneShot. When I set it to Pixhawk, no log gets created and the display doesn't get past 'waiting on USB'. I even tried to plug it into the USB port on my laptop numerous times but the script doesn't go past 'waiting on USB'. This model does work though when it is set to OneShot.So the USB is working. That's a good start.
I took a quick look at the code and the log buffers don't start writing to disk right away. That's why you don't get a log. I'll fix that.
It also looks like the internal timers in your camera mau not be accurate. Or they are just enough different (either fast or slow) to throw off the pulse width measurements that the script performs. We should be able to confirm that once the log issue is resolved.
I'll get back to you tonight.
I took a quick look at the code and the log buffers don't start writing to disk right away. TI took a closer look. If you press the camera's MENU button while it is waiting for USB pulses (and after you are sure that your pixhawk has sent a few pulses) then the script will write out a log file and stop. Please do so?
I took a quick look at the code and the log buffers don't start writing to disk right away. TI took a closer look. If you press the camera's MENU button while it is waiting for USB pulses (and after you are sure that your pixhawk has sent a few pulses) then the script will write out a log file and stop. Please do so?
Here it is.Okay - it's not seeing the start pulse. Please run the attached script on both your cameras with the pixhawk attached and requesting shooting.
Here it is.Okay - it's not seeing the start pulse. Please run the attached script on both your cameras with the pixhawk attached and requesting shooting.
You'll see USB pulse width info on the LCD. It will also create a log file ( CHDK/LOGS/LOG_0001.TXT ) on your SD card. Please attach results from both cameras here.
AttachedBoth logs look like the pixhawk is just "idling". There is no "shoot pulse" (i.e. >1 mSec & < 5 mSec) in either log. Did you actually configure the pixhawk to simulate actual shooting requests?
AttachedBoth logs look like the pixhawk is just "idling". There is no "shoot pulse" (i.e. >1 mSec & < 5 mSec) in either log. Did you actually configure the pixhawk to simulate actual shooting requests?
After powering the camera and hooking the USB to the pixhawk I turned on the pixhawk (connected via battery) then I hooked it up to laptop and triggered camera through Mission Planner.I'm not sure what to suggest here.
After powering the camera and hooking the USB to the pixhawk I turned on the pixhawk (connected via battery) then I hooked it up to laptop and triggered camera through Mission Planner.I'm not sure what to suggest here.
My first thought is that your pixhawk setup is not what the script is expecting for [ Pixhawk ] mode. The pixhawk can be setup to trigger a camera a number of ways, but to get faster shooting ( < 1 second/shot ) you need to follow these guidelines :
Pixhawk Camera Trigger Cable (http://tuffwing.com/support/pixhawk_camera_trigger_cable.html).
When you set the script to [ Pixhawk ] mode, it expects at 3 mSec pulse from the pixhawk to start shooting and another 3 mSec pulse for each additional shot. According to the test script logs from either camera, your setup is generating 100 mSec pulses.
The KAP.LOG file for your A3400 also shows it receiving only 100 mSec pulses - which is why it does not start shooting.
The mystery here is why your A4000 KAP.LOG file shows it shooting? It must be receiving ~3 mSec pulses - it won't shoot any other way.
Before I try to hack up the script to dump more info about what your A4000 is doing, would you mind repeating the original tests for both cameras with the pixhawk remaining powered between tests. I can only guess that you maybe lost the correct setup of the pixhawk after you tested the A4000 and before you tested the A3400?
Please accept that I'm not trying to say you've done anything wrong. I just can't figure out what else I might have missed. Something is different - but what?
Sure I will re-test but I won't be able to until Monday.I may be less available next week so please excuse any delayed response
I will note that I am using the 3dr x-8+ with the mapping package. I think the setup has the port setup as relay. (https://3dr.com/wp-content/uploads/2015/04/Mapping-Package-Instructions-v1.pdf)That package uses a much older version of the script. It almost certainly does not support the newer & faster [ Pixhawk ] mode - you should be using [ Oneshot ] mode and shooting slower than 2 seconds per shot. I would not expect the script to work at all when set to [ Pixhawk ] with their software setting up the pikhawk controller.
The entire reason I want to change from OneShot to Pixhawk is because half the pictures were coming out underexposed and from what I have read, I can get a faster picture rate using the pixhawk setting.Can you elaborate on "half the pictures were coming out underexposed"? Does that mean every second picture sequentially? Or were you generalizing to say that sometimes some of the pictures are randomly underexposed? And by how much?
Sure I will re-test but I won't be able to until Monday.I may be less available next week so please excuse any delayed responseQuoteI will note that I am using the 3dr x-8+ with the mapping package. I think the setup has the port setup as relay. (https://3dr.com/wp-content/uploads/2015/04/Mapping-Package-Instructions-v1.pdf)That package uses a much older version of the script. It almost certainly does not support the newer & faster [ Pixhawk ] mode - you should be using [ Oneshot ] mode and shooting slower than 2 seconds per shot. I would not expect the script to work at all when set to [ Pixhawk ] with their software setting up the pikhawk controller.QuoteThe entire reason I want to change from OneShot to Pixhawk is because half the pictures were coming out underexposed and from what I have read, I can get a faster picture rate using the pixhawk setting.Can you elaborate on "half the pictures were coming out underexposed"? Does that mean every second picture sequentially? Or were you generalizing to say that sometimes some of the pictures are randomly underexposed? And by how much?
Are you thus trying to shoot faster to increase the chances of getting good shots?
It would be interesting to see one of the underexposed images and to compare it and it's EXIF info to the settings in the KAP.LOG file. The way your script is configured (according to the logs) it will not shoot slower than 1/1000 sec and will not raise the ISO above 800. (Note : neither camera has an adjustable aperture - the f-stop will vary only with the zoom poistion). On a cloudy day, this could lead to underexposure.
If the script is in fact hitting an exposure limit, you could lower the Tv min value to something like 1/400 and the ISO2 Max to 1600 and still get acceptable images.
It's very random, sometimes the pictures are perfect and then i'll get random underexposed ones (usually in succession).In most of the script USB modes, the script measures and resets exposure before each shot.
I tried to slow the frequency of the images to one every 6 seconds, but it doesn't seem to have any impact.I would not expect shooting speed to affect exposure in most script modes.
What setting do you suggest in the Pixhawk for the following? CAM_DURATION to 1 (pulse length in deci-seconds)I don't have a pixhawk so can't really comment on settings beyond the link I posted earlier. I do know that the required [ Pixhawk ] mode settings are a bit of a hack on the flight controller side - the settings required are not something anyone would normally do.
It's very random, sometimes the pictures are perfect and then i'll get random underexposed ones (usually in succession).In most of the script USB modes, the script measures and resets exposure before each shot.
However, if you are using [ Pixhawk ] mode then the script locks the exposure when it takes the first shot in a sequence. That's one of the tricks it uses to get cheap little Powershots to shoot faster than two seconds per frame. Exposure is reset only after a USB timeout (no shots withing a defined time interval). Typically this occurs at the end of a shooting pass while the UAV "turns around" for another pass.
How bad is the underexposure? And can you confirm that the exposure settings are at the specified limit and the image EXIF information also show that?QuoteI tried to slow the frequency of the images to one every 6 seconds, but it doesn't seem to have any impact.I would not expect shooting speed to affect exposure in most script modes.QuoteWhat setting do you suggest in the Pixhawk for the following? CAM_DURATION to 1 (pulse length in deci-seconds)I don't have a pixhawk so can't really comment on settings beyond the link I posted earlier. I do know that the required [ Pixhawk ] mode settings are a bit of a hack on the flight controller side - the settings required are not something anyone would normally do.
I don't have the kap.log files from previous flights but here are two images from the same flight. I resize them so I could attach to this post.Now we are getting somewhere. Assuming the resize operation did not mangle the internal EXIF info, this is quite interesting. You've picked two sequential shots with dramaticly different exposures.
IMG_0569.JPG Tv : 1/1250 Av: f9.0 Sv: 160
IMG_0570.JPG Tv : 1/1250 Av: f3 Sv: 200I don't have the kap.log files from previous flights but here are two images from the same flight. I resize them so I could attach to this post.Now we are getting somewhere. Assuming the resize operation did not mangle the internal EXIF info, this is quite interesting. You've picked two sequential shots with dramaticly different exposures.
Here's the info from the EXIF data :Code: [Select]IMG_0569.JPG Tv : 1/1250 Av: f9.0 Sv: 160
IMG_0570.JPG Tv : 1/1250 Av: f3 Sv: 200
Same shutter speed, slightly higher sensitivity in the second (brighter) image. Not enough to explain the exposure difference though.
But notice the Av (aperture value) settings : f9.0 vs f3!! This is a huge change - enough to completely explain the exposure difference. But note my previous comment - the A4000 does not have an adjustable aperture. The fixed aperture should be reported as somewhere between F3 & F5.9 depending on the zoom position (the effective aperture gets smaller as you zoom in). If you are shooting at the widest angle, that would be f3. So that only leaves one thing - the internal switchable neutral density filter.
In the first image - the underexposed one - the image EXIF information indicates that the internal ND filter was used. In the second, correctly exposed image it was not. Why?
This is where it would be really nice to have the KAP.LOG file. I'm pretty certain that the script did not try to insert the ND filter in the first shot. In fact, it would have tried to force the ND filter to stay out. But the Canon exposure logic appears to have inserted it - ignoring CHDK's override.
All of which leads me to the conclusion that the script command that controls the ND filter might not work on your A4000.
We can test that if you have time. I've attached a little script that takes two sequential shots - one in "auto" and the other with the ND filter forced to the opposite state from whatever the camera picks for the first shot. If you point the camera at something really bright (a 60W light bulb from 12" away for example) and shoot in Canon AUTO mode, it should insert the ND filter. Let's see if a script can override that in the second shot. Do the resulting images look the same or different?
Edit : is seems that I have been down this road before without a clear resolution : ND filter swinging in even when "ND filter state" is "Out" (https://chdk.setepontos.com/index.php?topic=10552.0) A work-around might be to configure the camera so that it does not try to use the ND filter on its own. Not sure what those settings are though.
Keep in mind the exact same thing happened with the A3400 in OneShot mode.I can't find anything in the A3400 or A4000 porting thread indicating that the ND filter override was ever tested. It's possible neither of them work properly - they were probably created from the same code base. And they were both done as "blind ports" - meaning the CHDK developer did not have access to the camera during the porting process. Testing was likely left to CHDK beginners and may not have been too complete.
It's 100% hit or miss. I flew 5 flights that day, the first one was flawless and every image was perfect. It was roughly the same time of day too, so the brightness shouldn't have changed too much between flights.The constant brightness makes me wonder why the camera would decide to activate the ND filter on its own. It really should have set it in or out and left it there - seems unlikely it would change it. But if the script set_nd_filter( ) function is flakey, it could cause changes each shot.
I will test this Monday and let you know.In addition to the ndtest script, it would be instructive to know if the ND Filter State setting in the CHDK Enhanced Photo Operation menu works properly.
I don't have the kap.log files from previous flights but here are two images from the same flight. I resize them so I could attach to this post.Now we are getting somewhere. Assuming the resize operation did not mangle the internal EXIF info, this is quite interesting. You've picked two sequential shots with dramaticly different exposures.
Here's the info from the EXIF data :Code: [Select]IMG_0569.JPG Tv : 1/1250 Av: f9.0 Sv: 160
IMG_0570.JPG Tv : 1/1250 Av: f3 Sv: 200
Same shutter speed, slightly higher sensitivity in the second (brighter) image. Not enough to explain the exposure difference though.
But notice the Av (aperture value) settings : f9.0 vs f3!! This is a huge change - enough to completely explain the exposure difference. But note my previous comment - the A4000 does not have an adjustable aperture. The fixed aperture should be reported as somewhere between F3 & F5.9 depending on the zoom position (the effective aperture gets smaller as you zoom in). If you are shooting at the widest angle, that would be f3. So that only leaves one thing - the internal switchable neutral density filter.
In the first image - the underexposed one - the image EXIF information indicates that the internal ND filter was used. In the second, correctly exposed image it was not. Why?
This is where it would be really nice to have the KAP.LOG file. I'm pretty certain that the script did not try to insert the ND filter in the first shot. In fact, it would have tried to force the ND filter to stay out. But the Canon exposure logic appears to have inserted it - ignoring CHDK's override.
All of which leads me to the conclusion that the script command that controls the ND filter might not work on your A4000.
We can test that if you have time. I've attached a little script that takes two sequential shots - one in "auto" and the other with the ND filter forced to the opposite state from whatever the camera picks for the first shot. If you point the camera at something really bright (a 60W light bulb from 12" away for example) and shoot in Canon AUTO mode, it should insert the ND filter. Let's see if a script can override that in the second shot. Do the resulting images look the same or different?
Edit 1 : is seems that I have been down this road before without a clear resolution : ND filter swinging in even when "ND filter state" is "Out" (https://chdk.setepontos.com/index.php?topic=10552.0) A work-around might be to configure the camera so that it does not try to use the ND filter on its own. Not sure what those settings are though.
Edit 2 : it looks like nafraf did the A4000 port (https://chdk.setepontos.com/index.php?topic=9443.0)blind. I don't see anything in the porting thread that indicates the ND filter override was actually tested.
When you set the script to [ Pixhawk ] mode, it expects at 3 mSec pulse from the pixhawk to start shooting and another 3 mSec pulse for each additional shot. According to the test script logs from either camera, your setup is generating 100 mSec pulses.
The KAP.LOG file for your A3400 also shows it receiving only 100 mSec pulses - which is why it does not start shooting.
I changed this setting to .3 to send the 3 millisecond pulse and now both cameras trigger correctly using USB Control = Pixhawk.That makes sense.
I changed this setting to .3 to send the 3 millisecond pulse and now both cameras trigger correctly using USB Control = Pixhawk.That makes sense.
But there is still a potential issue with the ND filter.
The images you posted suggest that it is working - or at least that it can force the filter in. Your mobile phone lamp isn't really bright enough to force the filter in. A 60w build from 12" away would be a better subject.
Try setting the ISO high with the Canon menu and see if you can get the script's first shot to have the filter inserted? That should produce an over exposed second shot, showing that the filter can also be forced out?
What am I missing?I really hate to say this, but I don't think I can help. I don't own a pixhawk (although I'd like to someday) so I can't comment on the software with any knowledge. Sorry.
I can now control the camera BUT it takes two pictures every time I give it 1 command to take a picture.IIRC, selecting burst mode causes the script to use some tricks to achieve the fastest shot rate possible. That means it shoots continuously when the USB signal is active. One drawback to using this mode is that you always get one more shot than you asked for.
Is there any possible way to write metadata on a picture while/or after triggering it?That's probably the easiest part of what you propose. See these links :
Is the CHDK or a script capable of doing so?
It would be great if there was a way to geotag a picture when triggering it, using gps data from pixhawk or other flight controllers.Some CHDK supported cameras include built-in GPS (e.g. S100) so there is no real work to do other than enabling it on the camera.
I believe communicating the coordinates would be possible even with a primitive one bit communication (5v or 0v)If you had a flight controller that can be a USB "master" then sending data in USB packets to a CHDK script is pretty trivial : ( read_usb_msg( ) (http://chdk.wikia.com/wiki/Lua/PTP_Scripting#read_usb_msg) ). However, it's not likely any commercially available flight controller will include USB master functionality. :'(
but what about writing it?Have fun!
That's probably the easiest part of what you propose. See these links :Thank you for those links, this seems to cover what I'm looking for. I will dwell more on them once I get a bit more time.
Write to EXIF data? (https://chdk.setepontos.com/index.php?topic=12519.0)
TagMe, the Lua EXIF tagger (http://chdk.wikia.com/wiki/Lua#TagMe.2C_the_Lua_EXIF_tagger)
Some CHDK supported cameras include built-in GPS (e.g. S100) so there is no real work to do other than enabling it on the camera.I prefer to use smaller, more lightweight cameras like the 125HS, additionally the Flight Controller GPS tends to have significantly higher accuracy.
If you had a flight controller that can be a USB "master" then sending data in USB packets to a CHDK script is pretty trivial : (
read_usb_msg( ) (http://chdk.wikia.com/wiki/Lua/PTP_Scripting#read_usb_msg) ). However, it's not likely any commercially available flight controller will include USB master functionality.Otherwise, "bit banging" (https://en.wikipedia.org/wiki/Bit_banging) a serial message between the flight controller and camera is quite possible - assuming you have the ability to reprogram your flight controller and understand a bit about writing Lua scripts for CHDK.
Hmm I'm not sure what you mean by "master" functionality, the flight controller is capable of sending trigger commands (essentially 5v to cam), or is "master" something else?A "USB host", like a PC or raspberry pi, as opposed to a "USB device" like the camera. This would be a USB protocol connection, rather than re-purposing the 5v line.
Hmm I'm not sure what you mean by "master" functionality, the flight controller is capable of sending trigger commands (essentially 5v to cam), or is "master" something else?Your request was for some method of sending GPS data from your flight controller to a CHDK enable camera.
2018Apr26 14:09:50.860 248) IMG_1205.JPG
2018Apr26 14:09:52 meter : Tv:1/1250 Av:7.1 Sv:80 1225:1225
2018Apr26 14:09:52 actual: Tv:1/2000 Av:4.0 Sv:200 Temp:43
2018Apr26 14:09:52 AvMin:2.0 NDF:NDin foc:infinity
2018Apr26 14:09:55.900 249) IMG_1206.JPG
2018Apr26 14:09:57 meter : Tv:1/1250 Av:2.6 Sv:80 1216:1216
2018Apr26 14:09:57 actual: Tv:1/2000 Av:8.0 Sv:100 Temp:43
2018Apr26 14:09:57 AvMin:2.0 NDF:NDout foc:infinityDear waterwings today I had a problem with this great script I am using from a lot of time with success.Please post the entire log file as an attachment here. TIA.
Are you able to write an APP or know who can do for SONY Alpha cameras?I have not heard of any method of hacking a SONY Alpha. Sorry.
From what I understand (unless I'm not setting something up right) the chdk firmware can't natively read the pwm output from the pixhawk because the pulses are too short.IIRC standard servo PWM output pulse widths run over a range of 1 mSec to 2 mSec. Some time ago, I did some experimenting with the CHDK high precision timer feature in Lua and found that you can almost resolve 10 steps between 1 & 2 mSec. But it's right on the hairy edge of what the camera can do and I would not recommend trying it with anything important.
So I'm trying to set up pulsed output from the relay using some of the logic switches on my taranis rx. It will not be fast acting because the logic switches from the rx can only be as short as 1ds, but could greatly expand controllability of the script in the air. So now that you have my backstory, here's what I'm trying to get it to do.I don't know much about taranis rx units. Do I understand that you are going to ignore your Pixhawk flight controller and hook your camera's CHDK controlled USB port directly to a single relay that is in turn attached to an output from your rx unit? And you want to vary the on/off pattern coming from the relay to create a protocal that triggers your CHDK script to do different things? And your rx unit can be programmed somehow to do all of this?
I'll be utilizing two 3 position switches and one momentary switch from the taranis. < snip >I'm not sure I would set things up exactly this way but there may be constraints on what you can do with your taranis rx unit that I am unaware of. One concern that might make it tricky is making sure the 1d sec shutter trigger pulse does not get mistaken for the 2 or 3 1ds pulses used to switch modes. It can be done but the code gets more complicated.
In this mode the trigger should also cause it to begin recording.
QuoteIIRC standard servo PWM output pulse widths run over a range of 1 mSec to 2 mSec. Some time ago, I did some experimenting with the CHDK high precision timer feature in Lua and found that you can almost resolve 10 steps between 1 & 2 mSec. But it's right on the hairy edge of what the camera can do and I would not recommend trying it with anything important.
Is the script already set up to do this using the included sample code for pixhawk? I was reading the timing as 5,10,15, and 20 ms. Am i misinterpretung those or maybe this is from an earlier version of the code?QuoteI don't know much about taranis rx units. Do I understand that you are going to ignore your Pixhawk flight controller and hook your camera's CHDK controlled USB port directly to a single relay that is in turn attached to an output from your rx unit?
Not exactly. The pixhawk can be set to use a servo output as a digital relay, the relay can then in turn be programmed to activate on a high pwm input from a channel. Also I misspoke, the Taranis is a handheld txQuoteAnd you want to vary the on/off pattern coming from the relay to create a protocal that triggers your CHDK script to do different things? And your rx unit can be programmed somehow to do all of this?
Exactly. The taranis has some pretty powerful logic circuitry, including timers and such. I was hoping to alter the code to utilize a combination of pulse counting and pulse widths to put as many functions in as short of time as possible. Of course, if im setting up the pixhawk wrong, a pwm input would be much easier to program and alter code on.QuoteI'm not sure I would set things up exactly this way but there may be constraints on what you can do with your taranis rx unit that I am unaware of. One concern that might make it tricky is making sure the 1d sec shutter trigger pulse does not get mistaken for the 2 or 3 1ds pulses used to switch modes. It can be done but the code gets more complicated.
By the way, does 1ds mean 100 mIlliseconds?
In any case, you'll want to hack out all the code starting around line 420 where it says
====== PWM USB Pulse Controlled Functions ==========
and replace it with your own code. If you are stuck, I could probably give you a quick and dirty version to try out - debugging would be up to you though.
Help with either getting the script to work with native pwms or the relay output ive been working on would be awesome. Your script is complicated and i know every piece has a purpose, so even if i knew what i was doing (and i dont) i feel like i would spend more time breaking it then getting it to do what i want.
Is the script already set up to do this using the included sample code for pixhawk? I was reading the timing as 5,10,15, and 20 ms. Am i misinterpretung those or maybe this is from an earlier version of the code?The test I mentioned was just that - a test. I never included the test code in the script.
The pixhawk can be set to use a servo output as a digital relay, the relay can then in turn be programmed to activate on a high pwm input from a channel. Also I misspoke, the Taranis is a handheld txOkay - that makes more sense now.
Help with either getting the script to work with native pwms or the relay output ive been working on would be awesome. Your script is complicated and i know every piece has a purpose, so even if i knew what i was doing (and i dont) i feel like i would spend more time breaking it then getting it to do what i want.Might not be able to get to this for a couple of days but I will take a look. I have an updated version of the script that uses the more recent style for user variables. I keep meaning to release it but it needs testing. You can be the guinea pig to make sure I did the update correctly. ;)
Also yes, ds for decisecond, so 100msThanks
I'll be utilizing two 3 position switches and one momentary switch from the taranis. The momentary switch needs to trigger the shutter, regardless of anything else. It's set up now to switch high for 1ds, then off for 6ds.I got a chance to do a bit of work on this. Before I go any further, I'd like confirmation that you can actually configure your Tx unit to produce these pulse sequences. They are pretty specific so I'd rather only code this once.
The first switch will output single nonrepeating pulses of 6, 7, and 8ds to cause the script to enter one of three modes. The second switch will output either 2 or 3 1ds pulses high, then 6ds pulse low, repeating until the switch is off.
The first mode will be a zoom mode. Switch 2 will zoom in or out dependkng on switch position.
The second mode will be exposure correction, switch two will raise or lower the target ev.
The third mode will be a recording mode, switch two will set the framerate. In this mode the trigger should also cause it to begin recording.
Hey again, I'm having this issue wioth my 125hs. running with pixhawk on continuous mode. Some pictures are out of focus while others are OK, distance between cam and ground are the same.Sigh. Focus issues again.
How is that possible? Since continoues mode keeps the initial focus.
According to an online EXIF reader SD seems the same for all images (65.53m). Which makes sense since it's in continuous mode.Thanks for posting the log file. I don't have any great answers here but I'll share some thoughts.
Please take a look at my attached script. Particularly out of focus images are : IMG_0001 IMG_0004 IMG_0009 IMG_0011 IMG_0012...
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 ...
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
I'm now gonna test with softer bobbins and see if that makes a difference.This article is very interesting :
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.
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-3353mmHow did you test this? I thought you had focus locked in the script?
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.
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.
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 .. 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.
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)
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.
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.
At longer zooms, the values go much higher.
Sure. Although I'm not sure every CHDK camera can actually produce sounds - I'm pretty certain some of mine don't.
Yes, I only looped having half-press and having set the camera focus mode to continuous AF.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.
This way the camera would refocus on every distance change. No need for set_focus().
AFAIK all powershots have sounds. The one tricky bit is if you mute sounds in the menu, it also mutes play_sound.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 ?
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 ?
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 ?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 ?AFAIK:
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 (http://www.tuffwing.com/support/pixhawk_camera_trigger_cable.html).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.
Before I speculate further, I'll wait for @reyalp to point out the obvious thing we are missing here 8)Nothing obvious to me.
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)?
File Browser reports 7.49G (screenshot attached). BTW, thank you both for such quick response.Nice. Can you also find the /gen/cnf_core file using the CHDK file browser and screenshot it?
@reyalp Mac file naming error? Doesn't look like it but I'm out of ideas.Don't think so, since CNF_CORE would have been installed by stick along with all the others.
Firmware Ver GM1.00D (1.0.0.0)Thanks. Test build in the A3000 porting thread: https://chdk.setepontos.com/index.php?topic=5593.msg138862#msg138862
Thanks. Test build in the A3000 porting thread: https://chdk.setepontos.com/index.php?topic=5593.msg138862#msg138862To close the loop in this thread, the issue reported about the script halting while trying to load the /gen/cnf_core file was fixed here (https://chdk.setepontos.com/index.php?topic=5593.msg138885;topicseen#msg138885) by freeing up more memory in the specific camera's port.
Hi @waterwingz, would you mind taking a look at the attached log? When the Shot Interval is set to [Fast], the Shot Sync LED stays ON a little longer than a second. In [Burst] mode, the LED drops under a second; but it turns ON twice between shots. TIA!It's been a while since I've looked at the script's Fast & Burst modes.
@srsa_4c, attached the log file generated by hooktest.lua script. Thanks!That's not it, look for hooktest.log .
@srsa_4cWell, as you can see, this script also reports failures. I'll try to compare the port's capt_seq.c to another cam's from the same era.
Sorry, my bad. Here is the correct one.
I'm not able to trigger the camera when "USB Shot Control" set to Pixhawk and "Shot Interval" set to Fast. It works when it's set to OneShot, but the time per shots seems to be slow (attached log -- sunny day outside). Does the Pixhawk setting only works exclusively with the Tuffwing trigger cable (http://www.tuffwing.com/support/pixhawk_camera_trigger_cable.html)? I'm using the one from mobilexcopter (https://www.mobilexcopter.com/shop.htm#!/Simple-Canon-compatible-shutter-Pixhawk-version/p/53286831) instead, do you think that is a factor?Setting "USB Shot Control" to OneShot will trigger a shot each time the USB +5V level toggles. The "Shot Interval" setting is ignored. Your mobilexcopter (https://www.mobilexcopter.com/shop.htm#!/Simple-Canon-compatible-shutter-Pixhawk-version/p/53286831) interface triggers shots in that mode so I think it's working just like the Tuffwing trigger cable (http://www.tuffwing.com/support/pixhawk_camera_trigger_cable.html) interface. Your hardwarde choice is not an issue.
| Mode | Setting | Results |
| PixHawk | Fast | fail |
| PixHawk | Burst | fail |
| PixHawk | Fast | fail |
| PixHawk | Fast | fail |
| OneShot | Fast | slow random shots |
| OneShot | Burst | random shots |
| On/Off | Fast | fail |
| One Shot | Fast | fail |
| None | Fast | 3 sec per shot |
| PixHawk | Fast | fail |
| OneShot | Fast | slow random shots |
Setting "USB Shot Control" to OneShot will trigger a shot each time the USB +5V level toggles. The "Shot Interval" setting is ignored.
Are you actually using a Pixhawk controller? In Pixhawk mode, the script is waiting for a pulse of a certain length to take a shot - if you are not using a Pixhawk you'll need to setup something to get the same pulse width.
the only "Shot Interval" setting that matters in Pixhawk mode is Burst - which starts continuous shooting as fast as the camera will cycle when the Pixhawk requests a shot.
Edit 1: You need to jumper your Pixhawk correctly so that your interface cable can get +5V from the middle pin of its connector. Typically this requires getting the +5V from your BEC and connecting it to the middle row of pins of the pixhawk.
Edit 2: took another look at your log - thanks for providing that, it helps a lot. From what I can see, you have tried the following combinations :
Mode Setting Results
PixHawk Fast fail PixHawk Burst fail PixHawk Fast fail PixHawk Fast fail OneShot Fast slow random shots OneShot Burst random shots On/Off Fast fail One Shot Fast fail None Fast 3 sec per shot PixHawk Fast fail OneShot Fast slow random shots
Note that shooting never starts in Pixhawk mode regardless of the shot rate setting. This suggests that the script never sees the required 3 mSec start pulse from the Pixhawk. However, it does seem to see some USB activity as shown by the random shooting in OneShot mode (it shoots each time it detect the USB signal changing).
So my guess here is that you are not matching the setup of you PixHawk to what the script is expecting to see on the USB +5V line?
Looking for some help with my aerial shoots being extremely over exposed. I have a Powershot SX610 in a fixed wing drone and being triggered by a pixhawk. The attached picture was taken today at 400 ft on a sunny day.Please post the log file created by the script (kap.log) as an attachment here. It should be located in the top level folder of your SD card.
Looking for some help with my aerial shoots being extremely over exposed. I have a Powershot SX610 in a fixed wing drone and being triggered by a pixhawk. The attached picture was taken today at 400 ft on a sunny day.Please post the log file created by the script (kap.log) as an attachment here. It should be located in the top level folder of your SD card.
Were all shots over exposed or just some of them? If only some were, it would be helpful to know some of affected image filenames too as I look through the log.
Did you try shooting on the ground with the script? Disable the USB / Pixhawk stuff and just run the script as an intervalometer while the camera is pointed at a normal daylight exposure scene.
kap.log attached. All of the pictures (1/26/2019) on that flight were overexposed, 27 in total. I will try the intervalometer later today. Thanks for the guidance and any additional thoughts.Thanks for the log - I'll take a few minutes to study it later today.
Those previous logs were all tests in the garage primarily making sure the pixhawk would trigger the camera.I thought that might be the case - the Bv (brightness values) are quite low as might be expected indoors. Important clue there - read on.
I used your suggestion and tested the intervalometer. The intervalometer scripted running looks good.Actually, I meant for you to run the kap_uav.lua script in "intervalometer mode" (i.e. with the Shot Interval set for shooting every 10 seconds or so - no pixhawk used).
I ran KAP again and made numerous adjustments to TV, ISO, Exposure and I'm getting closer.Looking at your log file, the final script run (with the overexposed images) was done in very bright daylight. And that seems to be causing problems between the camera and script over the use of the ND filter. Strange to stumble on this now with a script that's been downloaded over 5000 times and used mostly outdoors.
It seems likely that sx610 could suffer the same ND control problem that elph180, since they are both relatively new cameras.Thanks - I did consider that the sx610 camera port is new. AFAIK, the bug you mention is the ND filter not doing what the script asks. But in the log file, I'm not sure the script is actually making the request in the first place. It's more like it is failing to realize that the exposure settings (Tv,Sv, NDF position) are being made with the ND filter engaged.
Any addition thoughts?As I mentioned previously, the script seems to struggle when the Canon firmware tries to use the ND filter. Your tests are not using brightly lit subjects so the script will work fine as is. I'm looking at whether the script has a bug when the camera uses the ND filler. If you lock the exposures settings to a small fixed range you are essentially defeating that purpose of the script and basically taking manual mode exposures.
Some of my early tests in the garage where in a "Hybrid" mode. The latest items uploaded have the phone in Camera only mode and in "P". 2019Jan29 11:42:08 Mode switched to PSorry to keep going back to this but unless I missed a post, your over-exposed shots taken from your UAV were all done using etiher HYBRID_AUTO mode in the first log you posted and LOWLIGHT in the second log.
I agree I'm defeating the script purpose by restriction the settings. I welcome any recommendations.
A side by side comparison shows the Normal operation still looks better. Any addition thoughts? log and sample pictures can be download at the link below.The biggest difference between the two images seems to be the focus. The log shows that the camera is AFL (auto focus lock) mode so it's possible that it is not focusing at infinity well. CHDK based manual focus & focus at infinity on some Powershots just does not work right, But that is the subject of a different very long thread on this forum.
Sun was out today so I put the SX610 on an old quad and took a couple pictures. Every picture seemed to be extremely washed out. Focus seemed to be a problem as well.Thanks Paul. Those pictures and the log file help a lot. 8)
I had better luck setting the Focus to infinity in the script. New log and sample pictures are in the link.You mention using an "old quad". Could this be a vibration issue? We've been down that road here many times but it will be hard to tell from the photos until we get the exposure fixed. The usual first test is to shoot when stable on the ground at a brightly lit scene.
As for the other shots being out of focus, I wouldn't rule out some vibrations.
As for the other shots being out of focus, I wouldn't rule out some vibrations.
Can you check the logs in the Pixhawk from that last flight to see the vibration levels? e.g. AccX and AccY should be between -3 and +3 and AccZ between -15 to -5.
http://ardupilot.org/copter/docs/common-measuring-vibration.html#imu-dataflash-log-message
The last flight was not with a Pixhawk.
Can you check the logs in the Pixhawk from that last flight to see the vibration levels? e.g. AccX and AccY should be between -3 and +3 and AccZ between -15 to -5.I'm kind of curious about where you found those acceleration thresholds? And if anyone has correlated them to how the affect the Canon lens mounting mechanisms?
I'm kind of curious about where you found those acceleration thresholds?
I'm kind of curious about where you found those acceleration thresholds?
There was a link to that information in the original post, but here is again.
http://ardupilot.org/copter/docs/common-measuring-vibration.html#imu-dataflash-log-message
Yes, I am more than willing to do testing as I really want this to work. Please PM me.See this thread : use of propcase MIN_AV when the camera inserts its ND filter (https://chdk.setepontos.com/index.php?topic=13679)
Yes, I am more than willing to do testing as I really want this to work. Please PM me.See this thread : use of propcase MIN_AV when the camera inserts its ND filter (https://chdk.setepontos.com/index.php?topic=13679)
I attached an updated build for the sx610hs on the porting thread (https://chdk.setepontos.com/index.php?topic=13355.msg139332#msg139332), but I can't test it myself. You should also delete the test kap_uav.lua script that I sent you and revert to v3.8 for now.
I tested the 4.0b7 today in the plane. It looks pretty good to me.Thanks for doing that.
im having problems actually downloading the script,on the ge.tt page when i click any of the download buttons the page loads something and stops.. never letting me download. I tried with Firefox and Edge.. any advice?
The attached script was giving me a syntax error when running through the camera.That means I did not post the correct recent version of the script. That's the danger with me trying to find stuff with my mobile phone while I am away from my development station and backups. :-X
Ixus185 discussion moved to https://chdk.setepontos.com/index.php?topic=13837.0This question was evidentally sweep up with the move, resulting in my missing it and not providing any response ...
@waterwingz could you please also help me my display keeps switching on and off on the SX240HS that i finally got the CHDK working with your script i set display to off but it keeps switching on....@willievermeulen :
Ixus185 discussion moved to https://chdk.setepontos.com/index.php?topic=13837.0This question was evidentally sweep up with the move, resulting in my missing it and not providing any response ...@waterwingz could you please also help me my display keeps switching on and off on the SX240HS that i finally got the CHDK working with your script i set display to off but it keeps switching on....@willievermeulen : What setting are you using for Display off mode (day) and Display off mode (night) ? (The choices are None LCD BKLite DispKey PlayKey ShrtCut).
Also, does your display switch on each time it shoots? And then does it turn off again immediately after?
Please post the KAP.log file from the root folder of your SD card here as an attachment?
Also i just put disable display on yes on the script settings, i dont understand the other day and night things?(or i havent seen them)My mistake - I was looking at a different script. You've answered my actual question here. Thanks.
It switches the screen off takes a picture and then previews the picture(so switching on the display) i tried to disable review but it didnt make any difference...When you say "disable review", did you mean setting the Shot Review setting in the Canon Menu (i.e. not a CHDK menu) to Off? That's the Canon setting that determines how long a copy of your most recent image taken is displayed after the shot completes. It needs to be set to Off for the script to be able to disable the LCD.
Also how do a get the pictures to save on the second partition???The SX240hs was released in 2012 and thus does not need to use - or support the use of - dual partitions on your SD card.
I'm very new, so please bear with me. I'm trying this wonderful script and I wonder if it can be controlled via chdkptp? I'm actually hoping to use this on a remote control car with a raspberry pi onboard and trigger (remote) shoot via USB. My understanding is that there's no function for (remote) shooting implemented, but there seems to be some sort of USB mode. Anyone know how to do remote shooting with this script?I'm confused. Why do you want to do remote shooting with this script? Why not just use chdkptp on your Pi to shot without a script running on your camera (i.e. just having CHDK loaded on the camera is sufficient) ?
I'm confused. Why do you want to do remote shooting with this script? Why not just use chdkptp on your Pi to shot without a script running on your camera (i.e. just having CHDK loaded on the camera is sufficient) ?
I just thought that the shutter speed control logic in your script would be useful. If I have just CHDK loaded and run chkptp rs then the shutter speed would have to be handled manually. I might be missing something though.FWIW, if you want to have the exposure and interval control from a camera side script have the images saved over USB with remote shoot, it should be possible using the remoteshoot -script option and a glue script to set the menu options, like what is described in https://chdk.setepontos.com/index.php?topic=13386.msg136688#msg136688
I just thought that the shutter speed control logic in your script would be useful. If I have just CHDK loaded and run chkptp rs then the shutter speed would have to be handled manually. I might be missing something though.FWIW, if you want to have the exposure and interval control from a camera side script have the images saved over USB with remote shoot, it should be possible using the remoteshoot -script option and a glue script to set the menu options, like what is described in https://chdk.setepontos.com/index.php?topic=13386.msg136688#msg136688 (https://chdk.setepontos.com/index.php?topic=13386.msg136688#msg136688)
Thanks for the advice. Is exposure control actually better done on the camera side or PC side?"Better" mostly depends on the details of what you want to do, and your personal coding preferences. Speed or where the actual exposure is calculated shouldn't be an issue in most cases, it's more about how you want the overall control logic to work.