CHDKPTP: for some - a sophisticated work - General Discussion and Assistance - CHDK Forum  
« previous next »
Pages: [1] 2 3   Go Down

CHDKPTP: for some - a sophisticated work

  • 23 Replies
  • 4338 Views
*

Offline andrew.stephens.754365

  • ****
  • 454
CHDKPTP: for some - a sophisticated work
« on: 13 / August / 2014, 11:43:52 »
Advertisements
Due to lack of programing skills/knowledge – including interprocess - I haven’t looked at remote multi-camera control in a while but two recent & ongoing threads have refreshed an interest:

Multi-camera setup project
http://chdk.setepontos.com/index.php?topic=11667.msg114307#msg114307
&
Building a mult-camera rig [was: Re: Battery third (temp) terminal as multipurpose analogue input]
http://chdk.setepontos.com/index.php?topic=11583.msg113395#msg113395

Thanks to the guru members, all those who have posted in those threads and particularly to mphx & novsela for sharing so much!

With reference to reyalp’s splendid alternative ptp client http://chdk.setepontos.com/index.php?topic=6231.msg65069#msg65069 , msl once said:

“This is a very sophisticated work - respect.”

I agree with that.

However, with the aim someday to self-develop a bespoke multi-cam solution I’d like to try and understand a lot more of this sophistication.
 
My first question is whether “we” [those able] could attempt to create a block diagram initially including, say, the various “technologies” involved [e.g pipes / sockets / both?] and perhaps describing which chdkptp source file(s) [to level of section line numbers ?]  enable that functionality. 

In the first instance i’m thinking that a document structured similarly to the one attached could be a decent type template?

I’d also like to create lists of links to related subject matter that folk can refer to / learn from. I’ll put a small list of those I studied yesterday but have, as yet, still been unable to see the wood for the trees in a following post.
Logged
*

Offline reyalp

  • ******
  • 11791
Re: CHDKPTP: for some - a sophisticated work
« Reply #1 on: 13 / August / 2014, 23:02:40 »
Quote from: andrew.stephens.754365 on 13 / August / 2014, 11:43:52
My first question is whether “we” [those able] could attempt to create a block diagram initially including, say, the various “technologies” involved [e.g pipes / sockets / both?] and perhaps describing which chdkptp source file(s) [to level of section line numbers ?]  enable that functionality. 
I don't know about diagrams, but I can try to outline the basic organization.

https://www.assembla.com/spaces/chdkptp/wiki/Scripting_Guide may also be help you get oriented. Discussion here may help me expand it.

I don't think getting to the line number level is useful, at that point you need to understand the actual code, and the best way to do that is to read it.

The main chdkptp code is loosely organized into several layers.

Going roughly from lowest level to highest:
1) ptp.c
Handles ptp communication and some of the connection management functionality. This code was originally inherited from the ptp.c in in ptpcam, but has been substantially modified. The ptp_chdk_* functions generally handle complete PTP transaction involving one of the CHDK PTP extension opcodes defined in chdk_headers/core/ptp.h. Each of these functions takes a PTPParams argument, which includes everything related to the specific connection. Multiple connections are handled just by passing a different connection.

2) chdkptp.c
Provides the ptp related Lua APIs, and also handles some transport specific setup (USB or PTP/IP) and some miscellaneous functionality.

The Lua APIs are chdk.* and chdk_connection.*. These are described some in the wiki page linked above. Together, they provide everything that the rest of chdkptp uses to talk to the cameras. Most of the chdk_connection methods correspond to one of the ptp_chdk_* functions in ptp.c.

Connections are stored in the lua "registry" table by bus/device (or ip/port), so there is a single "connection" object for each connected camera.

3) chdku.lua
Provides more user friendly "wrapper" for the connection object and APIs provided by chdkptp.c, along with a bunch of higher level functions and utilities. It provides methods for executing code, waiting for the results, handling script messages, remote capture and so on. It relies on the rlibs.lua library to manage camera side code.

After this, you get to several different "front ends" that all use chdku for most of their interaction with the camera.

cli.lua
Implements the command interpreter and most of the cli commands like upload, download etc. cli commands can also be executed from code. Unlike the preceding levels, the CLI has a single, current connection that it operates on.

multicam.lua
maintains lists of cameras and allows calling the same functions across all of them. More on this later, maybe.

gui.lua  (+ the other gui_*.lua files)
all the GUI stuff

In addition to these, there are a number of support libraries that are used by one or more of the above.

rlibs.lua mentioned above is probably worth describing a little. It implements a system for managing camera side code. Individual "modules" are defined as tables with the camera code in a string, and other fields to define dependencies. rlibs:build creates a single string that can be sent to the camera including the desired modules and all dependencies. This is used by the chdku exec* functions.
Some chdkptp modules like multicam and rsint add additional rlib modules.

As far as "technologies" go, chdkptp just uses libusb, or sockets for PTP/IP. chdkptp is currently single threaded, so although you can have multiple connections, you can only do one transaction at time, and the actual transaction blocks everything else until it's done.
Logged
Don't forget what the H stands for.
*

Offline andrew.stephens.754365

  • ****
  • 454
Re: CHDKPTP: for some - a sophisticated work
« Reply #2 on: 14 / August / 2014, 07:36:58 »
Good stuff reyalp...thanks for the start.

Edit:
 
(i) 15th Aug 2014.
PTP background search string = "PIMA 15740:2000 " 

(ii) 6th Oct 2014.
search string = "Introduction To Using LibUSB-1.0"
« Last Edit: 06 / October / 2014, 04:16:08 by andrew.stephens.754365 »
Logged
*

Offline andrew.stephens.754365

  • ****
  • 454
Re: CHDKPTP: for some - a sophisticated work
« Reply #3 on: 15 / August / 2014, 12:56:09 »
Low base here, lots to learn  :(

If it is conceptually correct - or perhaps just useful - to consider chdkptp as the client and chdk as the server then I imagine a "socket listener" continuously running within chdk ?

If so, where in the chdk source could I review this listener?   

[search string: "How to: Create a Socket Listener"
Logged
*

Offline reyalp

  • ******
  • 11791
Re: CHDKPTP: for some - a sophisticated work
« Reply #4 on: 15 / August / 2014, 17:06:59 »
Quote from: andrew.stephens.754365 on 15 / August / 2014, 12:56:09
If it is conceptually correct - or perhaps just useful - to consider chdkptp as the client and chdk as the server then I imagine a "socket listener" continuously running within chdk ?

If so, where in the chdk source could I review this listener?   
For the most part, it's in the original firmware, we just add one PTP opcode (with further CHDK sub-opcodes defined by the first parameter). You can find the CHDK code in http://trac.assembla.com/chdk/browser/trunk/core/ptp.c

The way this works is CHDK creates a task at startup which repeatedly tries to register the CHDK handler until the canon firmware is ready. When the handler is successfully added, that task exits.

All PTP code after that is run in the camera firmwares own PTP task, which handles all the low level USB details and delivers transactions with the PTP_OC_CHDK opcode to the handle_ptp function in ptp.c. There are additional mechanisms to communicate between this task and the tasks where most CHDK code runs.

As the name suggests, the chdk_headers/core/ptp.h mentioned earlier is a copy of CHDK's core/ptp.h. This defines the CHDK protocol and is quite well documented, so it's a good place to start if you want to understand that level of the process.

In general, wen you want to find something in a code base like this, the first thing to do is to look for likely filenames or search for related strings.

Another place you could learn about this is starting at the beginning of the original PTP thread by mweerden http://chdk.setepontos.com/index.php?topic=4338.0
The details have changed a bit over time, but the basic idea hasn't.
« Last Edit: 15 / August / 2014, 17:09:30 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline andrew.stephens.754365

  • ****
  • 454
Re: CHDKPTP: for some - a sophisticated work
« Reply #5 on: 15 / August / 2014, 17:33:02 »
Thanks, as ever.

Edit 19th Aug 2014:
circuitsathome camera control series
Edit 26th Aug 2014:
http://lua-users.org/wiki/ObjectOrientationTutorial
Object Orientation Tutorial - Lua is not really an object-oriented language, and it doesn't have a built-in concept of classes. But it is easily possible to create your own class system using tables and metatables.
Edit 26th Sep 2014:
http://www.wowwiki.com/Object-oriented_programming
In Lua, a function is a variable. As such, it should be noted that a reference to a function can be used wherever a variable is used. The implications of this is that functions can be stored inside tables.
http://www.wowwiki.com/Lua_Scope
File-local variables, Function-local variables, Block-local variables, global
Edit 28th Aug 2014:
http://phrogz.net/lua/LearningLua_ValuesAndMetatables.html#h4
Tables and Metatables and Inheritance
__index as a function ---> If a table has a metatable, and that metatable has a key named "__index" whose field value is a function, that function will be called (with the original table and the key passed as parameters) whenever Lua code asks for a key from the original table and that key doesn't exist. Whatever value that function returns will be returned for the key.
__index as a table ---> If the __index key in a metatable has a field value that is a table, Lua will automatically look in that table for the requested key, if the key doesn't exist in the original table. (And if that other table has a metatable with an __index key, it will look on from there.)
http://phrogz.net/lua/LearningLua_Scope.html
In Lua, if you have a function as a property of a table, and you use a colon ( : ) instead of a period (.) to reference the function, it will automatically pass the table in as the first argument!...self is not a keyword. It's not magical. It's not managed by the language. It's just the name of the first argument passed to your function.
http://www.lua.org/pil/16.html
The effect of the colon is to add an extra hidden parameter in a method definition and to add an extra argument in a method call. The colon is only a syntactic facility, although a convenient one; there is nothing really new here. We can define a function with the dot syntax and call it with the colon syntax, or vice-versa, as long as we handle the extra parameter correctly
Edit 5th Sep 2014:
http://www.thijsschreijer.nl/blog/?p=693
lua_State *L and the registry
Edit 22nd Sep 2014:
http://www.lua.org/demo.html
lua demo
http://studio.zerobrane.com/
Lua IDE
Re: alternative ptp client

Quote from: reyalp on 12 / February / 2012, 13:53:59
Quote from: Microfunguy on 12 / February / 2012, 06:29:55
When you broadcast a message to multiple cameras, how do you handle their replies ?
Loop over all the cameras checking for messages. This doesn't need to happen right away. (mc:wait_status_msg, which is called if you use mc:cmdwait)
So when you do a mc:cmdwait('preshoot') it sends the pre-shoot command to all the cameras, then waits for each one to send a message that indicating that get_shooting is true (or something failed)
Re: CHDK PTP multiple instances

Quote from: reyalp on 08 / November / 2013, 19:36:15
Quote from: Microfunguy on 09 / November / 2013, 13:35:19
Quote

Just trying to understand how Multicam.lua works  .. which is difficult if you do not know Lua.
The ability to connect to multiple cameras is in the C code, not multcam.lua. multicam.lua is just a framework for performing the same actions across multiple connections.
Quote
To open a connection to a device we need a bus number and device number.
When opening multiple connections do we need pointers to multiple PTP_USB,PTPParams and usb_device structures ?
The chdkptp code packages all these into a "connection" object.  This isn't the only possible way to implement multiple USB connections, it just seemed like the most straightforward way to do it with the existing ptpcam code, since all the functions operate on those structures.

In chdkptp, the connection objects are stored in a table in the lua "registry" (unrelated to the windows registry) indexed by bus and device, so there is one connection for each bus/dev pair. chdk.connection() gets or creates a connection object.
Re: Technical aspects of multi-camera PTP communication.

Quote from: reyalp on 17 / January / 2014, 17:02:01
Quote from: Microfunguy on 17 / January / 2014, 06:23:00
Can we open multiple sessions or do we have to open a session, send the operational command, close the session and then repeat for the other cameras ?
You can do either. Connecting / disconnection is likely to be a bit slower.

chdkptp already supports having connections open to multiple cameras. It maintains a separate PTPParams and PTP_CON_STATE (equivalent to PTP_USB in the ptpcam code) for each connection.

chdkptp keeps a table of these as device/bus pairs, since powershots only support one PTP session per camera. chdk_connection() either creates or retrieves these as needed.
...[]...

Quote from: reyalp on 17 / January / 2014, 22:08:29
Quote from: Microfunguy on 17 / January / 2014, 19:47:19
Just to be clear, for each camera and using the corresponding PTPParams and PTP_USB structures, we can open a session with each camera.
Yes.
Quote
When a command such as 'shoot' is entered, it is handled by the single-camera code and the operation command is automatically sent to all connected cameras ?
I'm not really clear what you are asking about.

At the PTP level, each connection is connected to a single camera, so PTP functions can only be called on an individual camera, and the entire program waits for any PTP call to complete.

The normal chdkptp CLI (which implements commands like 'shoot') also has a single "current" connection, stored the global variable con.

The chdkptp Lua API lets you open and operate on as any number of connections. If you have multiple connections opened using the API, you can switch the active CLI connection just by assigning to the con variable.

The multicam.lua module is an example of using multiple connections in the API. It allows you to perform the same operation on multiple cameras using a single command. This module was mostly a proof of concept, it isn't used by the normal chdkptp commands. Example usage is included in a comment at the top of the file.
« Last Edit: 20 / October / 2014, 12:05:47 by andrew.stephens.754365 »
Logged
*

Offline andrew.stephens.754365

  • ****
  • 454
Re: CHDKPTP: for some - a sophisticated work
« Reply #6 on: 05 / October / 2014, 18:31:36 »
Message limit in previous post exceeded - trying to maintain one knowledge silo in my quest...hope admin do not mind.
Edit 6th Oct 2014
Hardware tips from a very helpful forum member. Expensive, but apparently good:
http://www.amazon.co.uk/gp/product/B002ZU7HH2/ref=oh_aui_detailpage_o01_s00?ie=UTF8&psc=1 => MANHATTAN 1.5/12/480 Mbps 13-Port Hi-Speed USB 2.0 Desktop Hub
http://www.amazon.co.uk/gp/product/B005NGQWL2/ref=oh_aui_detailpage_o03_s00?ie=UTF8&psc=1 => Anker® USB 3.0 9-Port Hub + 5V 2.1A Smart Charging Port with 12V 5A Power Adapter [VIA VL812-B2 Chipset and updated Firmware 9081]
 
Re: Noob question, how to run multicam.lua on chdkptp

Quote from: reyalp on 07 / May / 2014, 16:01:03
Quote from: binarystatue on 06 / May / 2014, 23:13:18
Thank you so much. I just learned a super valuable lesson. I will make sure I read and understand the header.
A little more explanation.
! means run Lua code inside chdkptp (as opposed to running it on the camera)

!mc=require('multicam')
loads the module called multicam.lua and makes it available through a variable named mc
!mc:connect()
Connects to all the available cameras.
[Edit note Snapshot r650 – July 26 2014 https://www.assembla.com/spaces/chdkptp/wiki/Changelog Multicam: add support for connecting to specific cameras (r616) add support for persistent serial number mappings (r619, r620, r622, r623, r624, r625)]
!mc:start()
Starts the camera side Lua script on each camera. You must do this before using any other mc functions.
[Edit note: Re: Multi-camera setup project.
Quote from: reyalp on 24 / August / 2014, 15:47:24
multicam commands are implemented as messages sent with chdkptp <connection>:write_msg. The camera side script (rlib code at the bottom of multicam.lua) sits in loop waiting for messages. The message system has a queue that can hold up to 15 messages. Normally, you should wait for the previous command to be processed before attempting a new one, by using cmdwait or a hard coded delay.
]
!return mc:cmdwait('rec')
Switches all cameras to record (picture taking) mode. The cmdwait function waits for the operation to complete, and the return causes the results to be printed.
!return mc:cmdwait('preshoot')
Works as if you had pressed the shutter button half way and waited for focus etc on each camera, and returns when they are ready.
!return mc:cmdwait('shoot')
Tells all the cameras to shoot, and waits for the shot to complete.
!return mc:cmdwait('play')
Switches the cameras back to playback (review) mode
!mc:cmd('exit')
Ends the camera side script. You must do this before using normal chdkptp commands  (like download or ls) with the cameras. To use the mc functions again again, you will need to call mc:start() again.

If you want to do synchronized shooting, you will need to use mc:init_sync() once sometime after mc:start(). For best results, it should probably be after entering rec mode. To shoot synchronized shots, you will need to use the mc:testshots function (or use it as a basis to write your own), which handles the shoot and preshoot commands for you. There are comments on some of these functions in the source that explain how they work.

testshots takes a table of which aren't documented:
nshots: number of shots to take
tv: shutter speed, in APEX96 units
sv: ISO, in APEX96 "real" units
synctime: time (in milliseconds after all cameras are ready) when the shot should be taken. Default is the minimum value calculated by init_sync + 50 ms.

So
!mc:testshots{tv=96,sv=411,nshots=2}
would take 2 shots with a 1/2 second exposure at about ISO 100.

If you want to download and delete files from the cameras, see this thread:
http://chdk.setepontos.com/index.php?topic=11478.0
Re: Building a mult-camera rig

Quote from: waterwingz on 28 / June / 2014, 17:49:17
Quote from: novsela on 27 / June / 2014, 11:35:32
you can send and i will test and report
I've managed to work through reyalp's multicam.lua script and convert it for my project.   There were a few trick to learn along the way as I'm planning on having the camera-side script autostart on the cameras rather than download & run from the host script.  That will allow getting the USB remote setup correct each time the camera boots and will also support the assignment of sequential camera numbering at the camera by their position on the shooting rig. 

Of course this meant a journey into the mysteries of usb_msg_table_to_string() [Edit note: see, currently, line 330 in source:trunk/lua/rlibs.lua@657 http://trac.assembla.com/chdkptp/browser/trunk/lua/rlibs.lua] and the dreaded "script_id" mechanism.[Edit note: see, currently, e.g line 977 in source:trunk/ptp.h@657 http://trac.assembla.com/chdkptp/browser/trunk/ptp.h]

At this point, there are more things to do than there are things done.  However,  it will connect to multiple cameras (currently five in my case - I guess can go to seven with what I have around the house),  shoot with USB remote sync enabled,  and download the latest images.

Here's a link to the two scripts :  bcam.zip  bcamHost.lua runs on the PC from the same directory as multicam.lua,  bcamRem.lua needs to be on the camera and running.  If you need to halt the script on the camera,  press the shutter button and things will shutdown cleanly.

To make this work at the moment,  you really need a chdkptp installed and running.  Once that's running, these two command line entries will trigger a shoot, and download the result :

Code: [Select]
> run  -e"exec bc=require('bcamHost') bc:connect() bc:cmdwait('shoot')"
> run  -e"exec bc=require('bcamHost') bc:connect() bc:download_last()"Mapping the downloaded images into directories (or filenames) based on camera ID number is still to be done.  At some point I need to decide on a Gui.  AutoIT vs IUP/Canvas Draw?  Decision, decisions ...

Update : I've started a wiki page for Shooting with Multiple Cameras using CHDK projects.  There is a growing list of links at the bottom - additional contributions would be most welcome.
when struggling, remember, it's not that easy...
Quote from: zeno on 12 / October / 2012, 09:00:51
Understanding the CHDK source is not a task that's easy, even for proefessional programmers.
« Last Edit: 20 / October / 2014, 17:12:44 by andrew.stephens.754365 »
Logged
*

Offline andrew.stephens.754365

  • ****
  • 454
Re: CHDKPTP: for some - a sophisticated work
« Reply #7 on: 08 / October / 2014, 09:50:00 »
Message limit in previous post exceeded
Re: Precision shoot time in the EXIF

Quote from: reyalp on 03 / August / 2014, 19:18:49
Quote from: t.beauchant on 03 / August / 2014, 18:22:19
What would be the correct sequence of commands through ptp to do the initial setup (focus preset to infinity if that's possible), let the camera do the preshoot process in advance, shoot, and ultimately retrieve the name of the picture then go back to ready state?
This is going to depend on your camera and specific requirements, but my general approach would be to use a message script like rsint and multicam.

You can see msg_shell in rlibs.lua for a more basic example. You can extend this on the fly by sending lua code.

Essentially, at startup you would send a script to the camera using chdkptp, like
Code: [Select]
!con:exec('msg_shell:run()',{rlibs={'msg_shell','serialize_msgs'}})
This starts the msg_shell script and doesn't wait for it to quit. msg_shell sits in a loop waiting for commands sent as messages. The serialize_msgs library allows you to send lua values directly from the camera to Lua scripts running in chdkptp.

Now you can switch to record mode set your focus and exposure settings by sending the exec command, which treats the rest of the message as lua code to execute:
Code: [Select]
> putm exec switch_mode_usb(1)
> putm exec set_mf(1)
> putm exec set_focus(-1)
...
To shoot repeatedly with the same settings, you can just let the script hold shoot_half, and send click'shoot_full_only' for each shot (shoot_full_only is needed because for historical reasons shoot_full implicitly releases shoot_half)
Code: [Select]
> putm exec press'shoot_half'
> putm exec click'shoot_full_only'
> putm exec click'shoot_full_only'
...
> putm exec release'shoot_half'
To retrieve the name of the image, you need to do something a bit more complicated than click 'shoot_full_only': You will need to wait for the shot to be completed by using the raw shoot hook or checking the file counter, and you will need to have your code send back a message like
Code: [Select]
write_usb_msg(string.format('%s/IMG_%04d.JPG',get_image_dir(),get_exp_count()))
You can retrieve the message with the getm cli command, like
Code: [Select]
> getm
4:user:'A/DCIM/103CANON/IMG_3115.JPG'

To combine this with a shot, I'd use something like this (formatted for clarity, if sent it chdkptp putm exec it would be all one line)
Code: [Select]
local prev=get_exp_count()
click'shoot_full'
repeat sleep(10) until get_exp_count() ~= last
write_usb_msg(string.format('%s/IMG_%04d.JPG',get_image_dir(),get_exp_count()))
Rather than using getm, you probably want to use chdkptp side code to wait the message to arrive, and have your controller wait for it to appear on stdout before issuing the next shoot_full_only.
Code: [Select]
> !printf('file:%s\n',con:wait_msg({unserialize=true,mtype='user'}).value)
file:A/DCIM/103CANON/IMG_3119.JPG

In a real application, you'd probably want to create a lua module that has most of this code already in and just have a few functions to call. The multicam module may be a useful example. The rlib part at the bottom defines the camera side code.

Overriding focus is a somewhat complicated and camera dependent subject by itself, and IIRC elph110 may have unresolved issues, so I'm going to leave that for another post.
« Last Edit: 20 / October / 2014, 04:29:27 by andrew.stephens.754365 »
Logged
*

Offline andrew.stephens.754365

  • ****
  • 454
Re: CHDKPTP: for some - a sophisticated work
« Reply #8 on: 20 / October / 2014, 07:45:05 »
Message limit in previous post exceeded
Re: Help with IXUS 220 HS (ELPH300HS) - PTP

Quote from: reyalp on 06 / June / 2012, 16:13:17
Quote from: VincentD on 06 / June / 2012, 10:22:46
EDIT : Another question, is it possible to launch a script which is on the camera using a chdkptp command ?
Yes, you can use regular Lua functions like require, or loadfile etc with the . (lua) or = (luar) commands. If you want to run a script that expects to be run from the camera UI, you'll need to set variables named a, b, c etc. for the menu parameters.

A few things to note:
1) you can only run one script at a time, so if the script does more than just run and exit and you want to control it, you'd need to use PTP messages like the multicam script does. If you use the low level execlua function, you can start a script without exiting the previous one, but this will lead to memory corruption! The higher level chdku functions prevent you from doing this unless you use the clobber option.
2) Multicam itself runs a long running script on the camera, so to run another script you'd have to exit the camera side multicam script, or load and run it within multicam
3) Require runs in a pcall environment. This allows lua to catch errors in the require'd script, but CHDK functions that need to yield (like shoot, wait_click etc) don't work in this environment. A useful pattern to run a camera script is:
loadfile('A/PATH/TO/SCRIPT.LUA')()
which loads the script and executes it.
...[]...

Quote from: reyalp on 13 / June / 2012, 01:53:13
Quote from: VincentD on 12 / June / 2012, 09:58:43
EDIT2 : Ok so i found a solution, i use min_sync_delay to initialize syncat ! =D But i still got one second delay between the time i send the command and the time the photos is taken. Is it normal ?
Some delay is needed, but unless you have a lot of cameras it shouldn't need a second. The way synced commands work is they schedule something to happen at a certain time in the future, so all the command can be sent to all the cameras and they can be ready to shoot at the same time. This trades delay for better synchronization between cameras. The more cameras you have, the more delay will be needed.

I think you figured this out, but to use a synchronized command, you have to run mc:init_sync() once after the cameras are connected, and then send the sync time as an option to mc:cmd for each command you want synced. For example:
Code: [Select]
mc:cmd('shoot',{syncat=500})
would schedule all the cameras to shoot 500ms in the future. Of course, the delay has to be long enough for all the cameras to get the command and be ready. min_sync_delay might not be enough.

It's worth noting that in some windows configurations, init_sync will behave very badly because it only gets time at 15ms resolution. This should be obvious in the output of init_sync, the "send" lines will all be 0 or 15.

If you don't care about having the cameras all shoot at the same time, you could just loop through the list of cameras and send each one a shoot command in turn.

I'm not sure how you are doing you hdr command or what your needs are, but if you want each shot to be synchronized and the time of each exposure accurately recorded, then you probably want to do something like testshots, where the individual shoots are synchronized, rather than the entire hdr sequence. In that case, you should be able to record the shot time pretty accurately by logging the current time + syncat just before you send the shoot command (there is some delay that isn't accounted for in the sync process, but it shouldn't be more than tens of milliseconds).

If you want to post your modified source, I can try to look at it, but no promises.
...[]...

VincentD then shares his code here http://chdk.setepontos.com/index.php?topic=8120.msg86439#msg86439
and comments:

"And the commands i launch are :
!mc=require('multicam')
!mc:connect()
!mc:start()
!mc:init_sync()
!mc:cmd('rec')
!mc:cmd('hdr',{syncat=500})

In order to evaluate if i save the right date of the shoot, i point my camera on my screen (where a counter is running) and then i compare the result i save and what is on the photo. And it appears that the time differs from ~1 second."

reyalp replies here http://chdk.setepontos.com/index.php?topic=8120.msg86493#msg86493:
"in cmds.hdr, you wait_tick precedes shoot. Shoot tries to do a full normal shooting sequence: half press, wait for focus and exposure, then shoot. How long this takes depends on the camera, shooting mode and scene, but it can easily take a large part of a second.

If you look at testshots, it does the half shoot first, and then sends the synced shot once everything is ready."

...[]...

Quote from: VincentD on 15 / June / 2012, 09:22:21
Hello reyalp !

I do the sane thing as in testshots, i mean do a half press, then wait with wait_tick and finally full_press. And now I can save the time of the shot with 100 ms of delay which is really better than 1 second. Thank you very much for all your help.  :)

VincentD
Re: Multi-camera setup project.

Quote from: reyalp on 12 / July / 2014, 17:57:49
Quote from: mphx on 12 / July / 2014, 16:50:32
In other words , you are suggesting to avoid switch thing?Enlighten me a bit about "calibrated sync shooting mode".When i was using multicam commands for shooting (no switch involved) i was using shoot command with syncat parameter.Is there something else there?
With the latest lua files from chdkptp svn and CHDK 1.3 (not currently in a release zip, but I'll probably get another one out this weekend), you can use shoot_hook_sync instead of shoot, which should have substantially better sync.
Quote
Do i have to issue a sync command to ALL cameras with this method?because issuing sync to 8 cameras was taking *some* secs..i cant imagine what time is needed with ~64....
Yes, it would be quite slow. It's possible this process could be sped up, but in any case I wouldn't bet much on the reliability with 64 cams.

Note that you should only have to do init_sync once after startup. Doing it after you have switched to rec mode should give more accurate results.

It's possible you could save the sync timings by serial number, or assuming all your cameras are the same model, just come up with empirical values from running init_sync a few times.
« Last Edit: 21 / October / 2014, 06:45:17 by andrew.stephens.754365 »
Logged
*

Offline andrew.stephens.754365

  • ****
  • 454
Re: CHDKPTP: for some - a sophisticated work
« Reply #9 on: 20 / October / 2014, 10:25:11 »
Message limit in previous post exceeded
Re: Building a mult-camera rig [was: Re: Battery third (temp) terminal as multipurpose analogue inpu

Quote from: reyalp on 02 / September / 2014, 16:27:39
Quote from: waterwingz on 30 / August / 2014, 15:00:42
Quote from: novsela on 30 / August / 2014, 14:45:30
Which command to use for setting shutter speed / iso / aperture ? I prefer to control it from remote
The "sweet point" will change with scene illumination

I believe reyalp set the shoot() command in his multicam script to accept exposure parameters.  Take a look at his source / docs ?   I'm travelling now and can't do so easily from my POS mobile phone
The multicam 'shoot' function does not, but testshots does. Assuming you are using a script like multicam or bcam, you just need to send the 'call' command with lua script to set the desired parameters. See http://chdk.wikia.com/wiki/CHDK_Scripting_Cross_Reference_Page

If you want to be able to enter more friendly units, you can refer to the code for the shoot cli command

edit:
One important thing to remember if you are setting exposure parameters using lua functions is that in general, script overrides are only applied while the script that set them is running. So if you are working with a single camera and do something like this:
Code: [Select]
=set_tv96_direct(1024)
=shoot()
The exposure will not actually be set, because each = command runs as a new script and overrides are cleared in between. Instead, you should use something like:
Code: [Select]
=set_tv96_direct(1024) shoot()


In multicam, the script is started when you use mc:start() and runs until you send the exit command, so you can use
Code: [Select]
!mc:cmdwait('call set_tv96_direct(1024)')
followed by the calls to shoot.

edit:
Corrected typo
sundry item:

Re: 3D SCANNER with multiple Cameras

Quote from: reyalp on 06 / May / 2014, 18:10:21
Quote from: indian22 on 06 / May / 2014, 15:32:53
If i had for example 40 cameras the point 1) become very boring...is there an automatic way to start the cameras?
To do this, you need to have external power supplies you can control, and have some way to hold the power buttons down on the cameras.  Then when the power supply is turned on, the cameras will start immediately. You should still shut the camera down with software (shut_down() from ptp) and then turn off the power supply.

Quote from: reyalp on 12 / May / 2014, 13:10:39
In multicam, you can execute lua code on all cameras using the call command. So
Code: [Select]
mc:cmd('call shut_down()')
Re: SX40HS. Don't work press/release zoom_in/out from CHDKPTP

Quote from: reyalp on 17 / September / 2012, 16:07:49
This is an artifact of the way scripting works. Each = command runs a script. When a script ends, any keys pressed by the script are implicitly released. This is because scripting was originally designed for scripts run through the script menu. For PTP, it would make sense to have a way to override this behavior.

If you do something like =press('zoom_in'); sleep(n) to hold the key for a specific time.

If you want to be able to press/release under your own control instead of a fixed wait, there are some other options
1) Use a long running script like the msg_shell rlib (see lua/rlibs.lua). This runs indefinitely and listens for messages, which you can send by putm. Not that while this script is running, any other chdkptp functions that expect to run a script will not work.
2) Use post_levent_to_ui (see http://chdk.wikia.com/wiki/LogicalEvent) to send Canon keypress events. These should be called something like "PressWideButton", "UnpressWideButton", "PressTeleButton" etc.  You can use get_levent_def_by_index(index) (described at http://chdk.wikia.com/wiki/Lua/Lua_Reference/Levent ) to iterate over the levents available on your camera.
lua commands to get/set ISO and zoom

http://chdk.setepontos.com/index.php?topic=5346.msg51825#msg51825
Re: [SX110] Comparison: CHDKPTP vs Canon's RemoteCapture
Quote from: reyalp on 24 / August / 2012, 16:53:56
Quote
How long can a command line be?  Can I invoke a code text file to run with CHDKPTP ?  .... things of this nature.
There is no specific limit on the length of a command.
There are several ways you can execute file:
1) Upload a file to the camera and then use something like lua loadfile('A/CHDK/SCRIPTS/testprgm.lua')()
2) Use PC side Lua scripting to load your file as a string and send it to the camera to run. The 'rlib' module in chdkptp is one example of this.
Using either of the above, you can also start a script on the camera which reads messages over PTP, so you can build your own custom protocol / command set. There are some examples of this in the chdkptp lua files.

The PC side of chdkptp is very scriptable. In fact, the entire GUI and CLI are written in Lua. You can find all this code in the lua directory, plus some additional examples (multicam.lua and the extras directory)
Re: [SX110] Comparison: CHDKPTP vs Canon's RemoteCapture
Quote from: reyalp on 25 / August / 2012, 15:47:28
Quote
  How do you handle this?  Do you execute each small chunk of a function on the client with handshaking?  Do you transfer the entire file to camera RAM (or SD temp file) and transparently execute from there?
The chdkptp CLI and GUI commands work by building the script on the fly and sending the entire thing over. This is done for simplicity. If you look at chdku.lua con_methods:exec you can see how it's done. rlibs.lua contains a bunch of utility code which is combined with the script to execute. So if you do something like
=return 1
It's actually loading prepending the 'serialize_msgs' code from rlib (76 lines, 1.6 kb) to whatever you enter, sending it to the camera, polling until script execution ends, fetching the return message. Many of the chdkptp cli commands load a lot more code.
« Last Edit: 25 / November / 2014, 07:04:59 by andrew.stephens.754365 »
Logged
Pages: [1] 2 3   Go Up
« previous next »
 

Related Topics