Canon SX260HS accurate geo-tagging

gio_kap

Hi Lanzo; I'm not using the Pixhawk camera feedback feature so I have no direct experience with it (I'm trying to use an external GPS independent of the navigation system for image time-stamping).
I'm sure you've already googled for clues (such as: http://www.tuffwing.com/support/Install_a_canon_precision_geotag_cable.html; http://ardupilot.org/copter/docs/common-camera-shutter-with-servo.html), and your set up seems correct: it appears to be more a Pixhawk hardware/firmware problem.
Sorry for not being able to help.

waterwingz

gio_kap
If weather permits, I'll be soon doing some mapping tests to start checking how this system works and ortho-mosaics accuracy, so I'll be glad and honored to beta test the updated script.

Update : the beta script (after one small upset) allows user defined sync LED "on" time and logs sync LED on & off times to the millisecond. And according to the log for gio_kaps sx260hs , the script is achieving requested 500 mSec LED "on" times within 10 mSec.

However, gio_kap provided a video showing actual erratic operation of the focus assist lamp in his camera, with "on" duration varying from very short to several seconds. Even though the log show each blink to be exactly 500 mSec!

We eliminated obvious stuff with Canon camera settings and disable RAW. Still getting erratic LED performance.

Testing with identical settings on my G10 give rock solid operation so I don't think this is a script issue.

Leaving us with the possibility that the camera_set_led() code in lib.c for the sx260 is calling a Canon firmware routine that does not immediately activate the lamp driver hardware. It looks more like its creating an event request of some type that gets processed later - and not necessarily quickly. if that's true, then using that LED to sync shot time to GPS position via a flight controller is not going to work for this camera model.

gio_kap

Hi All.

Just for information purposes: I posted this topic (with a link to this forum) on the DIY Drones forum, as other UAV users might be interested in this, and might also share their experiences.

gio_kap

And this is the link:

http://diydrones.com/forum/topics/canon-sx260hs-accurate-geo-tagging

srsa_4c

waterwingz
Leaving us with the possibility that the camera_set_led() code in lib.c for the sx260 is calling a Canon firmware routine that does not immediately activate the lamp driver hardware. It looks more like its creating an event request of some type that gets processed later - and not necessarily quickly.

Lots of ports use the LEDDrive firmware function and it doesn't seem to have latency issues (it's good enough for the motion detection test script).
For some reason however, the sx260 port uses a lower level fw function to drive the LEDs, and that affects the AF LED.
To see if that's the cause of the problem, you could make a test build - just remove* the LEDDrive stub from stubs_entry_2.S.

edit:
*Assuming you can rebuild stubs_entry.S

waterwingz

srsa_4c

waterwingz
Leaving us with the possibility that the camera_set_led() code in lib.c for the sx260 is calling a Canon firmware routine that does not immediately activate the lamp driver hardware. It looks more like its creating an event request of some type that gets processed later - and not necessarily quickly.
Lots of ports use the LEDDrive firmware function and it doesn't seem to have latency issues (it's good enough for the motion detection test script).
For some reason however, the sx260 port uses a lower level fw function to drive the LEDs, and that affects the AF LED.
To see if that's the cause of the problem, you could make a test build - just remove* the LEDDrive stub from stubs_entry_2.S.
edit:
*Assuming you can rebuild stubs_entry.S

Thanks - I'll give that a shot. I looked at lib.c but did not think to see if the address had been patched in stubs_entry_2.S.

I assume I can just un-comment the necessary line in stubs_entry.S (rather than rebuild it completely ..) ?

// Stubs below should be checked. Stub not matched 100%, or difference found to current 'stubs_entry_2.S'
//    Name                                     Address      Rule  %  Comp to stubs_entry_2.S
//NHSTUB(DeleteFile_Fut                       ,0xff02163c) //  1 90%        == 0xff02163c
NHSTUB(LEDDrive                               ,0xff1b989c) //120        *** != 0xff04d06c
// ERROR: MakeDirectory_Fut is not found.                  //--- ---    *** != 0xff02214c

srsa_4c

waterwingz
I assume I can just un-comment the necessary line in stubs_entry.S (rather than rebuild it completely ..) ?

If you don't (or can't) rebuild stubs_entry.S, just use the address found there to correct the stub in stubs_entry_2.S. Look at the first line of stubs_entry.S for the reason.

waterwingz

srsa_4c

waterwingz
I assume I can just un-comment the necessary line in stubs_entry.S (rather than rebuild it completely ..) ?
If you don't (or can't) rebuild stubs_entry.S, just use the address found there to correct the stub in stubs_entry_2.S. Look at the first line of stubs_entry.S for the reason.

For the benefit of anyone else reading this later on, srsa_4c is pointing out that stubs_entry.S is a "generated" file. It is created when there is a valid PRIMARY.BIN firmware dump file in the port's sub/firmware directory. So my edit to that file would not be permanent, although it will work as long as the corresponding line in stubs_entry_2.S is commented out and there is no PRIMARY.BIN file in the same directory.

But FWIW, I also downloaded the necessary PRIMARY.BIN file as suggested and checked that the revised stubs_entry.S addresses were the same.

I've sent the new build to gio_kap for testing.

gio_kap

Hi; just a quick update on this.
I've tested several iterations of the CHDK build as patiently and generously provided by WaterWingz, however the LED response is not affected by the software, keeping varying the LED pulse width.
In the meantime I tested an Arduino based photo detector (https://www.amazon.it/gp/product/B01M7RRA2M/ref=oh_aui_detailpage_o06_s00?ie=UTF8&psc=1) and it's actually able to nicely detect the rising front of the LED ON pulses, no matter the pulse width; I also checked that the LED turns ON upon shutter activation, so image time-stamping should be accurate.
Thanks to this forum, and great appreciation to waterwingz time and efforts put in.
Regards

srsa_4c

waterwingz
However, gio_kap provided a video showing actual erratic operation of the focus assist lamp in his camera, with "on" duration varying from very short to several seconds. Even though the log show each blink to be exactly 500 mSec!

We eliminated obvious stuff with Canon camera settings and disable RAW. Still getting erratic LED performance.

I realize that OP has found a usable workaround. I'd still like to ask whether there were any experiments using different values for the second argument of set_led. When LED control is implemented with the LEDDrive fw function, the second parameter can be used to set various blinking patterns (when its value is other than 0 or 1). Perhaps it's working differently on this camera.

waterwingz

srsa_4c
I'd still like to ask whether there were any experiments using different values for the second argument of set_led.

To answer your question - no. But I don't recall a suggestion we try that?

When LED control is implemented with the LEDDrive fw function, the second parameter can be used to set various blinking patterns (when its value is other than 0 or 1). Perhaps it's working differently on this camera.

Open to suggestions here. We could iterate the low integer possibilities.

But it seems to be related to how busy the camera is at the time? That too should be possible to test with some different scripts.

srsa_4c

waterwingz

srsa_4c
I'd still like to ask whether there were any experiments using different values for the second argument of set_led.

To answer your question - no. But I don't recall a suggestion we try that?

Normally, 1 should make the LED switch on and stay on (until the firmware doesn't do something with that LED, like using it for AF assist light). This behaviour is also not documented on the scripting page (it's camera dependent anyway, not all ports use LEDDrive).

Open to suggestions here. We could iterate the low integer possibilities.

1..8.

But it seems to be related to how busy the camera is at the time?

Blinking is done by software (a fw task named LEDCon). But, I wouldn't expect that task to have difficulties on this cam when it works normally on other cams.

waterwingz

srsa_4c

waterwingz
But it seems to be related to how busy the camera is at the time?
Blinking is done by software (a fw task named LEDCon). But, I wouldn't expect that task to have difficulties on this cam when it works normally on other cams.

Earlier in this thread, I sent gio_kap a simple script to repeatedly blink the camera's LEDs. He tells me that the result using the focus assist LED is very stable and consistent. So it seems unlikely that the unstable operation seen with kap_uav.lua is related to the second parameter, which IIRC controlled brightness on some older PowerShots?

edit 1 : I'll automate the test version of the script to take 10 shots at each of the settings from 1 to 8. It also occurs to me that the USB timing in the script runs with USB set to 1 mSec (via the high precision timing mechanism) so a test version that runs on a 10 mSec tic might be worthwhile (even though it works fine on other camera).

edit 2 : the precision timing mechanism is only enabled in pixhawk or gentwire USB mode - gio_kap was not using those mode.

srsa_4c

waterwingz
Earlier in this thread, I sent gio_kap a simple script to repeatedly blink the camera's LEDs. He tells me that the result using the focus assist LED is very stable and consistent.

I have no idea then.

the second parameter, which IIRC controlled brightness on some older PowerShots?

Looked up 2 random old ports (a610, s2is):
The a610 port controls LEDs directly by GPIO and ignores the brightness argument in camera_set_led(). The s2is port uses an older fw function that supports brightness setting (probably only effective on some of the LEDs), but doesn't support blinking patterns either.
The set_led script command doesn't currently support a brightness parameter, not sure if it ever did.

waterwingz

srsa_4c
I have no idea then.

Tried a small upgrade to the blinker script by adding the shooting sequence with delays between each step (script attached). It's very stable with the LED's on my G10 - except for the focus assist lamp. That LED turns off as soon a press("shoot_full_only") executes in the script.

Which pretty much explains what gio_kap was seeing on his SX260hs.

I had suggested that gio_kap try using something other than the focus assist lamp in his testing, but the SX260hs has only one other indicator lamp and it blinks during shooting under Canon control so that option was not available. Thus we did not discover this earlier.

srsa_4c

the second parameter, which IIRC controlled brightness on some older PowerShots?

The set_led script command doesn't currently support a brightness parameter, not sure if it ever did.

While I was updating the wiki documentation for set_led() to include information about the "blink" options via the second parameter, I looked at several implementations in my camera's lib.c files and realized the third parameter is ignored. I just assumed it was used in older cams per the existing documentation.

LEDtest4.lua

943b

« Previous Page