a495 chdk ptp - page 3 - General Discussion and Assistance - CHDK Forum  

a495 chdk ptp

  • 36 Replies
  • 8402 Views
Re: a495 chdk ptp
« Reply #20 on: 04 / May / 2011, 18:46:16 »
Advertisements

Here's an image from each of the cameras (in a line) triggered simultaneously while someone jumps in front of them.
Observe the arm and feet positions between the shots to see what I mean about delay.

Gareth

Re: a495 chdk ptp
« Reply #21 on: 04 / May / 2011, 21:17:40 »
Unfortunately, despite my best efforts of having an application with multiple threads and a pulseall to signal those threads to send the putm capture, we're still getting too much delay.
A possible problem with using threads is that you have no control over when each thread will actually resume after the "pulseall". Add to that the extra layers of passing a message to ptpcam and then to a script on the camera.

Also, unless you have 40 processors that are ready to kick in for each thread, I doubt it's faster than just having a loop messaging each camera sequentially. (Even with 40 processors I wouldn't be sure of it.)

Perhaps it is possible to start a script, disconnect and then use the "old" USB trigger. I'm not sure you can programmatically turn power to a USB device on/off, but shouldn't it be possible to supply the power from an external source (though still controlled by the computer)? The camera doesn't need the power supplied via USB, so if USB and the camera allow it, you might even be able to have a PTP session open while switching the power on/off.

B.t.w.: as you seem to be using C#, you might be interested to know that I put a (not 100% percent complete) .NET/C# library for CHDK PTP online today. At the moment it expects a special CHDK version, but it is easy to change that to the current "official" version; just don't use the GetLive* functions. You can find it here (should be downloadable without git).

*

Offline reyalp

  • ******
  • 12314
Re: a495 chdk ptp
« Reply #22 on: 04 / May / 2011, 22:48:01 »
This was the main problem, it was pretty ungraceful. Once I ensured the long running script was shut down after the actual capture, all the crashes and memory problems went away.
Good to know, I've been meaning to look into this in detail, but it's quite convoluted so I wasn't sure how bad it was. It should be possible to terminate the script 'nicely'.
Quote
That builds and returns a A\DCIM\IMG02___05\IMG000023.jpg path by using os.listdir and the last item in the arrays for the DCIM and the IMG????? folders.
Yes it's horrible.
I might be able to use the sequencing number get_exp_count and simplify this down, but figuring out what the IMG???? bit is will be tricky without a statement like above.
The IMG folders are date based, right ? (I don't have a camera new enough to do that, but that's what it looks like...) You can get date strings based on camera clock very easily, with os.date
Quote
To summarise, I now have 4xA495 and they're all being controlled by a bit of C# software. We're doing our final testing before purchasing the entire batch of 40.
That's quite a bit of money.

As you are probably aware by now that the CHDK PTP interface is still quite rough. You should expect to encounter bugs in CHDK and the client tools. You should not expect that they will necessarily be fixed quickly. You should carefully consider the implications of this, especially if you aren't expecting to hack on CHDK or the tools yourself.

What you are trying to do has never been done with CHDK before (using PTP) so no one can tell you wither it is ultimately workable.
Quote
I'm personally quite happy but as the A495 has no manual mode, there's no easy way to set the TV and AV. I tried using proptable and set_prop but I either used the wrong magic numbers (for the values) or it's not implemented in the a495 alpha chdkde firmware i'm using.
Most of the time I got an error from the camera.
The a495 has no adjustable aperture, so you won't be getting Av control. set_tv96_direct should work for Tv, although it's possible the propcase values are wrong in that port.
Don't forget what the H stands for.

Re: a495 chdk ptp
« Reply #23 on: 06 / May / 2011, 03:00:10 »
Sweet as, yeah the USB 4x trigger via PTP is all working good- just a bit of lag.
We're now testing with eye-fi cards which arrived today and USB remote trigger but I've had some weirdness develop.
I'll post it here since we're talking about the a495 and this project but it's probably deservant of it's own thread.

BTW, this is an alternate approach to using PTP for file transfer and PTP USB for the triggering, we're hoping the looping script and the +5v will be faster than sending the message over usb ptp and all the thread nastyness that comes with it
-Just to reiterate, I have all that working.. just a bit of lag between (4) cameras - so when we expand to 40 it will be probably worse.

Thanks to all with the thread suggests and the Pulse all etc- I had considered that. The machine running this rig has an SSD to allow for fastest possible file transfer (hopefully we can max the 802.11n out if we're using eyefi) as well as quad core i7 cpu- I had considered that we still might have problems with 40 threads, but I didn't want to sequentially transfer the cameras.

Unboxed the eyefi card and set it up
Tested shooting and uploading - worked perfectly
Tested a single camera with SD card and USB remote - worked good
Formatted the Eyefi card as FAT16 (ships as FAT32) and restored the eyefi files
Tested the card in the camera - worked
Copied the A495 build onto the eyefi card
Set it up for English and autoboot
Copied my trigger script on
Turned write protect on
Got the remote trigger working (upgraded to the latest autobuild and the remote usb trigger wasn't working but went back to 649 and it started working again)
I'm using a BASIC script running on the camera in a loop to detect the remote trigger
Switch 5v and the camera takes a photo
However, it doesn't upload over the eyefi card
As soon as I quit the script, the eyefi card starts uploading

Any thoughts?
tldr: eyefi with chdk working but upload doesn't happen until script detecting remote trigger is quit


What can I do to trigger the upload? I'm guessing something the script is doing is preventing the camera from updating the FAT table or similar on the sd card so the eyefi firmware doesn't know there's new photos to upload until I quit the script.

While I can quit the script after a trigger, then I have a problem of restarting the script after the upload has happened and I won't have any interface for that (because I'm using USB for remote trigger in this scenario, not for PTP)



Re: a495 chdk ptp
« Reply #24 on: 06 / May / 2011, 03:01:55 »
Unfortunately, despite my best efforts of having an application with multiple threads and a pulseall to signal those threads to send the putm capture, we're still getting too much delay.
A possible problem with using threads is that you have no control over when each thread will actually resume after the "pulseall". Add to that the extra layers of passing a message to ptpcam and then to a script on the camera.

Also, unless you have 40 processors that are ready to kick in for each thread, I doubt it's faster than just having a loop messaging each camera sequentially. (Even with 40 processors I wouldn't be sure of it.)

Perhaps it is possible to start a script, disconnect and then use the "old" USB trigger. I'm not sure you can programmatically turn power to a USB device on/off, but shouldn't it be possible to supply the power from an external source (though still controlled by the computer)? The camera doesn't need the power supplied via USB, so if USB and the camera allow it, you might even be able to have a PTP session open while switching the power on/off.

B.t.w.: as you seem to be using C#, you might be interested to know that I put a (not 100% percent complete) .NET/C# library for CHDK PTP online today. At the moment it expects a special CHDK version, but it is easy to change that to the current "official" version; just don't use the GetLive* functions. You can find it here (should be downloadable without git).

Unfortunately, windows drops the USB connection when you cut/power the 5v- it must be using some sort of detection for something being connected not related to the data lines.
This means my options are _either_ ptp or USB 5v trigger - hence eyefi testing above

*

Offline reyalp

  • ******
  • 12314
Re: a495 chdk ptp
« Reply #25 on: 06 / May / 2011, 16:13:33 »
An possible alternate approach to synchronization using PTP:

All the cameras have a 10ms ish accuracy tick counter (get_tick_count())

You should be able to calibrate these relative to the PC system clock, then set up your scripts to shoot on each camera at a particular tick count that corresponds to the same real time. I'm not sure what sort of accuracy you could get, you'd definitely want to calibrate each camera in turn without a lot of other traffic on the USB.

There are a number of sources of uncertainty in the calibration: your program <-> ptpcam, ptp transport, scheduling variations in the PTP and script tasks, scheduling within the final script that takes the shot. Some of these could be reduced if you are willing to hack the CHDK code a bit, but you'd want to characterize them before expending any effort on that.

What sort of synchronization accuracy do you require ? Is shot latency critical (e.g someone presses a button and all the cameras fire at that instant, or could you schedule the shot 1 second in advance, as long as all the cameras shoot together)

Another option might be CHDK motion detection. You could set the threshold really high so the cameras all go off when they see a flash.

Of course long exposure + flash would be the obvious brute force way to do this.
Don't forget what the H stands for.

Re: a495 chdk ptp
« Reply #26 on: 06 / May / 2011, 22:26:33 »
An possible alternate approach to synchronization using PTP:

All the cameras have a 10ms ish accuracy tick counter (get_tick_count())

You should be able to calibrate these relative to the PC system clock, then set up your scripts to shoot on each camera at a particular tick count that corresponds to the same real time. I'm not sure what sort of accuracy you could get, you'd definitely want to calibrate each camera in turn without a lot of other traffic on the USB.

There are a number of sources of uncertainty in the calibration: your program <-> ptpcam, ptp transport, scheduling variations in the PTP and script tasks, scheduling within the final script that takes the shot. Some of these could be reduced if you are willing to hack the CHDK code a bit, but you'd want to characterize them before expending any effort on that.

What sort of synchronization accuracy do you require ? Is shot latency critical (e.g someone presses a button and all the cameras fire at that instant, or could you schedule the shot 1 second in advance, as long as all the cameras shoot together)

Another option might be CHDK motion detection. You could set the threshold really high so the cameras all go off when they see a flash.

Of course long exposure + flash would be the obvious brute force way to do this.

Ideally, as accurate as possible (the ultimate would be all cameras firing within 10ms of each other) but we can schedule for a few seconds with an aligned timer over ptp usb.. as you suggest.
Shot latency is semi-critical but not as important as having all the shots at the same time. The trigger sensor is at the top of a skateboard ramp, so as the skaters come up and hit it, we're hoping to get a 360 around them.

The problem with the usb remote trigger and the eyefi cards to get the photos off are that they don't transfer until the script quits.. and if it does that, I have no way of starting it again without being physically in front of the cameras or a messy usb switching system.
Any idea why the photos wouldn't upload until the script quits? the eyefi firmware won't be using the camera CPU so it must be something filesystem/sd card related.
The photo definitely gets written to the card before you quit the script (but i wonder if the fat table's not updated)

I'd be concerned about the tuning with the synchronisation as it may be variable, but if it's going to be consistent and I only need to calculate the offset for each camera once, that might be viable.

Motion detection again might work with the eyefi cards to upload the photos, but then we have the same issue as having a long running script which we need to quit, unless controlling the cameras on PTP

Gareth
« Last Edit: 06 / May / 2011, 22:43:10 by agrath »

*

Offline reyalp

  • ******
  • 12314
Re: a495 chdk ptp
« Reply #27 on: 06 / May / 2011, 22:48:28 »
The problem with the usb remote trigger and the eyefi cards to get the photos off are that they don't transfer until the script quits.. and if it does that, I have no way of starting it again without being physically in front of the cameras or a messy usb switching system.

Any idea why the photos wouldn't upload until the script quits? the eyefi firmware won't be using the camera CPU so it must be something filesystem/sd card related.
No, I have no idea. That is *very* strange, I'm having difficulty imagining how that would even be possible. CHDK doesn't interact with the canon firmware jpeg writing at all, and a script "running" really shouldn't mean anything to the rest of the firmware. A lua script sitting in a tight loop can hog CPU, which might delay a Canon task I guess. Putting a long sleep() in somewhere would prevent that.

It occurs to me eyefi might some heuristic based on how recently the card was accessed, but a running script really shouldn't access the card repeatedly, unless you are using the file io or console log functions. If you are doing something like that, try not doing it ;)
Don't forget what the H stands for.


Re: a495 chdk ptp
« Reply #28 on: 06 / May / 2011, 22:54:43 »
The problem with the usb remote trigger and the eyefi cards to get the photos off are that they don't transfer until the script quits.. and if it does that, I have no way of starting it again without being physically in front of the cameras or a messy usb switching system.

Any idea why the photos wouldn't upload until the script quits? the eyefi firmware won't be using the camera CPU so it must be something filesystem/sd card related.
No, I have no idea. That is *very* strange, I'm having difficulty imagining how that would even be possible. CHDK doesn't interact with the canon firmware jpeg writing at all, and a script "running" really shouldn't mean anything to the rest of the firmware. A lua script sitting in a tight loop can hog CPU, which might delay a Canon task I guess. Putting a long sleep() in somewhere would prevent that.

It occurs to me eyefi might some heuristic based on how recently the card was accessed, but a running script really shouldn't access the card repeatedly, unless you are using the file io or console log functions. If you are doing something like that, try not doing it ;)


Yeah that's what I thought.
I'll make sure I have a timeout on the readkey and put a sleep in after the actual photo is taken.. hopefully that will help. THe eyefi card doesn't interact with the camera and chdk doesn't interact with the camera at that level, but it is definitely the case. We have to quit the script to get the upload to happen. We've tested this on more than one camera now.

The script doesnt do any IO either, it just waits for a trigger, takes the photo then refocuses (half shutter) until the next shoot perhaps that's it?

*

Offline reyalp

  • ******
  • 12314
Re: a495 chdk ptp
« Reply #29 on: 06 / May / 2011, 22:57:29 »
The script doesnt do any IO either, it just waits for a trigger, takes the photo then refocuses (half shutter) until the next shoot perhaps that's it?
If you are sitting in half shoot, I could see that as doing it indirectly by changing the behavior of the Canon firmware somehow. I would try releasing for a few seconds and see what happens.
Don't forget what the H stands for.

 

Related Topics