CHDKPTP: for some - a sophisticated work

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.

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.

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"

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"

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.

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: 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: 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: 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: 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.

---

---

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: 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: 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...

Understanding the CHDK source is not a task that's easy, even for proefessional programmers.

---

---

Message limit in previous post exceeded

---

---

Re: Precision shoot time in the EXIF

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)