PiXPi dslr camera controller

Modular and programmable DSLR camera trigger

Similar projects worth following
Hello, Today I want to share my "PiXPi" project, which currently is about building open-source, programmable DSLR camera's trigger(and hopefully even more in future).I started this project about 2 and a half year ago as I was interested in photography technique which is called "high-speed photography", this technique aims for making perfectly frozen photos of fast-moving things, like bullets, cracking glass, popping balloons, droplets collisions and... creativity should be the only limit herebut I realize that for some photographers there can be also so technical difficulties, so this is the first goal of this project: making "high-speed photography" as easy as possible, but without limiting those with more technical knowledgealso I currently working on adding the possibility to control some motorized devices like timelapse/macro sliders.check out:

What's that about:

So first goals of this project was simple, just creating controller which will make possible to create  nice photos of things that are happening really fast in reliable but as you will see this is extended now a bit and I aiming for a bit more.

But let's start from begging:

I made first experiments about 4 year ago I was inspired by video which i found on YouTube:

It was about hooking sound sensor, camera and Arduino together and using proper program to trigger camera shutter in right moment and generally it worked and generally i really liked this project and started to thinking what I can improve.

First of all it was not handy to reprogram Arduino every time I wanted to change something(I needed to take my laptop to basement :p ), of course I could use lcd screen and button to adjust delays and etc, but I think such way will still not be very handy.

Also I  was thinking about making something which can be used by photographer which are not really into programming and don't have technical knowledge, so device which can be also used by regular photographers.

              one of first attempts, about two and half year ago, this one was with optical sensor detecting hammer                      with which I was hitting bulb.

So then a lot of thinking, designing and prototyping happened....(for more read to design process log)

And now after this years I created board which is equipped with interface to camera, flashes and three modules, which can be quickly and easily configured with graphical interface through smartphone app, it has also unified module interface which give possibility to add new modules easily.

                                                                    Some of prototypes which I created.                                                               

                                                                                     How it works :

Controller board(PiXPI) is running under Linux(OpenWrt) control, on top of it is a Python application which is responsible for receiving, executing and controlling scripts created and sent from smartphone application, which I wrote for this project.

Smartphone App utilize Google's Blockly library for making creating of those scripts/sequences simple as possible. So in effect you can create them using graphical programming interface, using blocks instead of writing any code, no knowledge of Python programming is required for, user do not see Python code at all, he/she will just see blocks .

Scripts which are sent from smartphone are basically strings of python code, python was chosen as language which is powering controller, as it can execute code from string without compiling.

Scripts are sent from android application using Wifi->http->rest protocols.

Scripts are responsible for orchestrating photo shoot sequence, so camera shutter, flash and modules interfacing.

Those blocks with help of Blockly library are under the hood translated into python code...

Read more »


Mount for stepper driver pcb

stl-binary - 8.87 kB - 08/24/2019 at 10:16



Valve holder models, which's used for droplet module

stl-binary - 130.06 kB - 08/24/2019 at 10:04



Valve holder which's used for a pneumatic gun module

stl-binary - 39.14 kB - 08/24/2019 at 10:00



Sensor holder/mount for tripod

stl-binary - 37.29 kB - 08/24/2019 at 09:52


  • 1 × 1455B802[BK] Boxes, Cabinets, Enclosures and Racks / Boxes
  • 1 × PP23 Sensor module case
  • 1 × 1455B1002BK Boxes, Cabinets, Enclosures and Racks / Boxes
  • 1 × 3P025-06 Droplet module/pneumatic gun solenoid valve
  • 1 × Mini CO2 regulator for pneumatic gun, search for: keg mini co2 regulator on Aliexpress

  • Power driving mode

    krzysztof krzeslak09/12/2019 at 18:50 0 comments


    Today I want to introduce new feature it's called: "Power driving mode", it's mode for driving some "action" modules which can be handy in some situations as it's purpose is to drive some modules without any additional external circuit.

    But let's start from recalling how "action" modules are driven in "normal" mode, let's see below image:

                                                                 Port circuit behavior in "normal" mode

    In "normal mode" power Mos-Fet of port is open all the time, low current signal for driving module is delivered through "com" pin.

                                                    And how it looks in Power driving mode:

                                 In power driving mode "com" pin is not used, instead just supply pins are controlled

    In power driving mode "com" is not used(should not be connected) and driving of module can be done through on-board power transistor, so for example you can connect solenoid, or anything other, theoretically max current is approx. 5A(60W), but till this moment I tested max 3A in pulse.

    how to enable:

    I modified App "port configuration" screen to handle enabling of this mode, after choosing port function mode, checkbox where you can select it will appear:

                                                   Power drive mode is valid only for "output" port mode

                             Below you can find small demo with driving some random peripherals:

    Advantage of using this mode:

    You can drive simple "action" modules without external circuit, so for example till this moment I was using board small with Mos-Fet to open and close valve(solenoid) in response to state on "com" pin, but with power driving mode solenoid can be connected directly to "gnd" and "+12v" pins of port and driven just with toggling supply on this pins.

    Disadvantage of this mode:

    When you first think about it using such driving mode should be "best" way of handling such use case as driving solenoids, valves, etc. So maybe you can think, why even I bothered to create "normal" mode as first?

    there's one valid reason for it, when you will take a look at solenoid driving board you can see button there which is used to "emergency/maintenance" opening of valve and I found it really handy to have such button, especially when I was experimenting with "liquid gun" module which was valve with syringe pressurized by springs and I needed way to fill this and it was really hard to do this when I had to control valve open/close from app. 

    It's a little bit easier with "droplet module", but still it's handy to have possibility to emergency valve open for example for filling chamber of valve or just emptying it after use. Without supplying module all the time, there will be no possibility to open valve without using app.

    so in some(or most) cases it's handy to had module supplied all the time.

  • Finals! Wow and what are my further plans

    krzysztof krzeslak09/11/2019 at 16:32 0 comments


    PiXPi is in finals of 2019 Hackaday Prize!

    There was so much great projects submitted and I really feel honoured to be among those 20 chosen for final round. 

    Also I found it awesome to see my project described in finalists announcement post, thanks Mike for nice words! I really want to appreciate this so I thought the best way to say thanks will be to put as much heart into this project as possible, "heart" in this case, can be translated into "hard work" ;) 

    What now:

    I just cooled down a bit to be able to think consciously about that what need to be done as there is not much time, so I came to conclusions that I need to prioritise some areas where the biggest improvements can done, so according to this I chosen as main focus :

    1. Introduce new feature which is "power driving mode" of modules ports:

    I was working on it lately, so stay tuned, it's almost ready and will be soon described in project log.

    2. Finish and show effect of usage "motorised/stepper" module: 

    Currently I got some base which I show in previous logs, but I was not happy with stepper motor driving electronics and during seeking for better solution I came across project called: "Mechaduino"...  which by the way was 2016 Hackaday prize entry!!: and I realised that it should be possible to communicate with my controller as Mechaduino is opensource, so possibly it can be quite easy to modify software of Mechaduino to be controlled through PiXPi controller.... Isn't opensource great?! :) 

    3. Work hard on new video:

    Last, but very important point, as ti's one of requirements of final entry is to create 2-5 minute video which will show project and I got already some initial idea how to do this, but I know it will be quite challenging to do it right. 

    Optional point: New hardware design with better ports protections, after experimenting with "power driving mode" I came to conclusions that I will feel safer when power driving transistors gates for each port will be driven through optoisolators, but it's more on good practice rather that new feature introduction as i experimented quite heavily with power driving and I was not able to burn VoCore port with current protections. Possibly I will start to work on it after 1-st of October.

    What you think about it?! :) 

    It would be really nice to hear some thoughts of community on this project, as this was my main motivation to publish this project here, so don't hesitate to share some I will really appreciate to hear some(Even those critical ones).

  • Controller board specification and software sources

    krzysztof krzeslak08/24/2019 at 18:09 0 comments

    Hello today I wanted share quick summary specification of current controller board design,

    and as this project is meant to be opensource I want to share some sources today I Think both will be good summary for entry round of this contest :).

                                                                v0.9(current)controller version

    Controller software:

    it's Python app sources which is running on controller.

    Hardware specification:

    1 x Optoisolated camera port(2,5mm jack) for camera focus/wake and trigger

    2 x Optoisolated Flash port(3,5mm jack) for flash triggering

    3 x module port, which can be used in following modes:

          Port Red: Input, Output, Com(1-wire), Pulse

          Port Green: Input, Output, Pulse

          Port Blue: Input, Output, Pulse

          Each port has 3 pins: Signal, 12V, Gnd

          Ports connector fits standard servo connectors

    8 x Gpio pins

    1 x mini-B usb connector for accessing Linux command line/serial console.

    1 x 1,27mm 6pin SPI connection for complete flash writing(unbricking, bootloader change, etc. )

    1 x DC jack for 12v supply (should be tolerant up to 22v)

    2 x status led: supply, ready

    3 x port status led

    1 x Buzzer for state indication

    Powered with opensource VoCore2 system on module (

    Which provides:

    - Mediatek MT7628, 580 MHz SoC

    - Memory(ram): 128MB, DDR2

    -  Flash: 16MB

    - Running under Linux(OpenWrt) control.

    It's also fully OpenSource: Complete specifications and sources available on:

  • Some new photos

    krzysztof krzeslak08/24/2019 at 14:02 0 comments


    This time I wanted to share some photos which I took lately, within this I also want to show how setup and program look like for each shoot and also you will see example how modules can be combined.

                                          Doing photos like below was really simple using relay module

                                                                                                 Burning bulb filament
    Read more »

  • Macrorig controlled from app

    krzysztof krzeslak08/20/2019 at 19:41 0 comments


    As i wrote in previous update lately I was working on adding possibility to control macrorig/stepper driver from android app, and just wanted to share some effects of it:

     Generally it works, it's simple and there are some fine tweaks still needed, but it will come in future, what was currently added on app side is:

    Added "step" mode in ports configuration screen:

                                                              "Step" mode can be set on each port

                After setting port into "step" mode following block will become available:

    With these block you can move steppers forward and backward and set desired travel, currently smallest possible move for macrorig is 0,005mm(1 step).

  • it's alive! stepper driver with macro-slider

    krzysztof krzeslak08/18/2019 at 15:13 0 comments

    Hello, today I was finally able to make macro-slider, so I wanted to show off a bit, below is a small demo:

    Currently utilizing of this feature needs to be imlemented on Android app side, but for controller testing i just sent http request from laptop, so next step we be adding blocks for driving this from Android app.

                                          I also designed and 3-d printed some holders for driver board

    As i mentioned in one of logs i decided to use "pulse" like interface for driving stepper boards, it's really simple and work like that:

     pulses below 2ms time will make stepper move in one direction

     pulses above 2ms will make it's moving in opposite direction

     and till now it works pretty well. 

    As currently i've used 1mm/rev trapezoidal screw and stepper motor has standard 200steps per revolution so theoretically it should have 5-microns resolution.

    Currently i already had some ideas about new driver board as I think it will be handy to have there some buttons to "manually" move slider.

    So watch for updates... :)

  • New black robe and few words about cases

    krzysztof krzeslak08/17/2019 at 19:01 0 comments

                                                            Controller in anodised black casing

    Hello, Today I wanted share photo of controller in "a new robe" which is anodised black case I bought those black cases some time ago, but not really used till this time, now as previous case got little dirty I thought that maybe it's a good moment to test this variant. 

    By the way I also realised that in log about board design i skipped somehow case selection topic, it necessarily should be there as case selection was one of first thing which I did when started this project, so board dimensions was designed to fit this cases(to be precise first prototype was intended for 100mm version[1455b1002], but after moving to esp then to vocore I switched to smaller 80mm version[1455b1002] ).

                   I really like this cases as they look very nice and are surprisingly cheap(less than 10 dolars),
                                          they're manufactured by Hammond manufacturing.

                       After removing front panel board can be slidden in/out, as it's held by those ribs on sides

    generally I can't make my decision which color version I like more, this one or old one(natural aluminium), so some opinions are appreciated :)

  • Modules under the hood

    krzysztof krzeslak08/13/2019 at 18:50 0 comments

    Hello, today i wanted share some detailed overview of modules, how they built and more importantly how they communicate with main controller, it's significant as standarized communication interface is something which make possible to easily extend capabilities through adding new module, so I put some thoughts behind design of modules interface.

    So on controller there are 3 modules ports:

    - Port red

    - Port green 

    - Port blue

    Each port consist of 3 pins:

    COMMON: configurable 3,3V input or output (additionally as 1-wire in case of port red)

    12V supply(currently always on, but in future I plan to add "power drive" feature)


                                                                           simplified port circuit
       Actual port driving circuit, there are some port's protections added and mosfet is actually driving low side

    For driving Sensor modules following configuration of port will be used:

    Com pin direction set to input, when sensor is not detecting anything it should give 3,3V after signal is detected it should pull COM pin to GND potential.

    Supply for sensor is provided by two remaining ping - 12V and GND. 

    For driving Action modules

    Com port set to output, when "action" is to be triggered, com port will go to High state out-putting 3.3V, but also reversed logic could be used here with no problems as default state can be configured as "HIGH" state.

    For driving Motorised modules:

    Currently I've implemented 1-wire communication(Over uart, so port red have additionally uart to 1-wire interface circuit)  for bi-directional communication over single pin with motorised modules, thought behind it was that 1-wire interface can serve multiple slaves, so using one port there will be be possible to communicate with multiple nodes, this could be useful for example for some multi axis sliders, but now I come to conclusions that maybe i over-killed it a bit and think about changing this approach to "servo-like" interface, so first I want to try driving motorised module using soft-pwm this will not have possibility of driving mutliple nodes with one port, but then not only port red will be capable to drive motorised module, but each of port, so still it should be fine, anyway I will keep uart/1-wire interface circuit on port red, as this can be useful in future, and interface circuit in quite simple. 

                                                           uart to 1wire circuit specific for port red,
                            based on

                   Ports function are configurable from app, function refer to COMMON pin function:

    (just note that "Com" is communication function of port, it's different thing from "Common" port)

    In case of output's(port blue on this screen), default state can be configured, module selection is not used at all now, but thought behind adding it was to name port driving blocks with corresponding name's , for example not just "wait for port red", but "wait for noise" in case of selecting sound sensor on port red.

             After setting port(red in this case) to input mode, such blocks will be available in program editor

    Read more »

  • Light sensor as laser barrier, part 2: usage

    krzysztof krzeslak08/11/2019 at 07:37 0 comments


    Today I wanted to share with effect of usage light sensor with laser which I shared in previous log.

                                                                                Final effect

    Program/script which was used for taking this photo.This time I used high speed photography method, so photo was done in dark room, using high speed flash illumination, camera shutter was set to bulb mode. Program explanation: "trigger shutter" opens camera shutter(it's like pressing and holding shutter button on camera), then it waits for 300ms to make sure that shutter is open and still, then "wait for (!) port red" waits for negated signal on port red(so laser beam interrupt by falling strawberry in this case), after signal is detected there's delay which can be adjusted from control panel, after set amount of time flash(connected to port 1) is triggered , so actual photo is taken and shutter is released ending sequence
                                                 setup which was used, few attempts was needed ;)

  • Light sensor as laser barrier: part 1

    krzysztof krzeslak08/09/2019 at 18:12 0 comments


    Some time ago I had an idea that light sensor can be also used as light/laser barrier, as I had some laser module laying around, which i bought some time ago on Ebay so I decided to give a try l, it's still to be tested in action, but it's a good opportunity to share some photos from workshop ;)

                                                                                     final effect
                                                                        "clamp" 3d printing
                             for tripod mounts i use 3d printed "clamp" with pressed 1/8inch poliamide nut
                                                                    complete setup with light sensor
                      inside is just battery holder, (glued)switch and laser module, so it's really simple contruction
    machining step, case which i'm using for this and also for all sensors is "PP23" bought from distributor which i got near my living place (
                                                      stickers designed in gimp, to make it look nice ;)

    In future days I will try to make a some tests for it, generally use case is almost same as for reflection sensor, but sometimes I think it can be handier to use such laser barrier and I wanted to make use of those modules which i got lying around ;)

View all 13 project logs

Enjoy this project?



Attila Kovács wrote 09/11/2019 at 19:25 point

This is a great project. I'm on and off on a similar one and you just gave me some ideas how to better tackle my problems. For some reason I never thought to have all the sensors separate. I planned to ditch the screen and user interface and use a mobile app instead but your solution is much better then what I planned.

My current device:

  Are you sure? yes | no

krzysztof krzeslak wrote 09/11/2019 at 20:20 point

Hello Attila,

Thanks for sharing your controller pcb design looks impressive! What processor is powering it ? is it Atmega or something from ARM family ?

Also I see one thing that your controller has and my controller not, it's built-in battery, plus for it! I also had some thoughts to put some on-board battery, as having it can be handy, but in my case i'm running on 12V so it will be not so easy to pack it in such small space.

  Are you sure? yes | no

Attila Kovács wrote 09/12/2019 at 08:49 point

Hello Krzysztof,

It's an STM32F103, ARM Cortex-M3. I think I will exchange it with something more modern for the next iteration. I plan to keep the battery as it makes the device portable (f.e.: lightning photography). Using a microcontroller instead of a full blown microprocessor let's me get away with a single Li-ion battery cell.

  Are you sure? yes | no

krzysztof krzeslak wrote 09/12/2019 at 11:13 point

Yeah, keeping battery is definitely good idea, in my approach 12v supply is effect of that most of modules need such supply and some higher powers(valves, steppers, coils...), so I decided to go with single external power supply "quid pro quo" ;).

Regarding processor choice, it's pretty decent I think old or not, it's fine until it serves it's purpose, but yeah sometime you reach limit which can be overcome just by upgrading to higher/newer version.

Don't hesitate to share when you will finish new version :)

  Are you sure? yes | no

Attila Kovács wrote 09/12/2019 at 13:57 point

Yes, of course :)

  Are you sure? yes | no

Tyler Gerritsen wrote 07/31/2019 at 14:44 point

What an awesome design!  I haven't looked through all your documentation yet, but the 'Program Editor' really stands out.  Everything looks professional. 

When I go to your site and click 'Documentation', it doesn't take me anywhere.  Are you sharing the plans to build one?  

Do you plan to manufacture and sell?  You definitely could compete with the current market!

  Are you sure? yes | no

krzysztof krzeslak wrote 07/31/2019 at 22:44 point

Thanks a lot, it's always nice to hear such words! :) 

I'm also happy with this editor as i initially wasn't sure how it will perform, but it turned out that it works quite nice :) 

Regardind documentation, yeees good observation it's my weak point, it's always a little challenge for me to write documentation which also will be understandable, but currently working on this, also on placing all sources in Github, so soon it will be available, at least in some initial form. Currently just finished something which can be called "architecture diagram"(it can be found in updated project details) because I had feeling that it's not so easy for all to understand how all part of this project cooperate together, so I hope with diagram will be a bit easier and it's a good starting point for documentation;)

Regarding manufacturing and selling, i'm not felling confident about hitting commercial market, but i had such thoughts in my mind, but currently i'm just enjoying working on this as hobby project as there's a lot of thing which can be improved ;)

  Are you sure? yes | no

Tyler Gerritsen wrote 08/14/2019 at 18:59 point

I see you've been busy!  It's awesome to see your development continuing.  I just happen to have a home-built macro slider similar to what you've built, but my controller is very basic.  The idea of an open-source platform to control my macro slider AND high-speed flash is very appealing.

I think that it would be great to have all the documentation available online.  Keep it up!

Since you built a 'laser barrier' system, could I make a suggestion?  Can you set up two lasers so that the PixPi can calculate the speed and delay time?  Then you could give it a distance (maybe for the strawberry, distance from the second laser to the water).  Just an idea!

Keep it up!

  Are you sure? yes | no

krzysztof krzeslak wrote 08/15/2019 at 10:00 point

Hello Tyler, yeaah i'm trying to do both simultaneously add some project logs and also to keep project development going further, it's not so easy, but I was able to create some more detailed description of modules, check it out in project logs ,generally I plan to re-use this project logs as base for documentation, so It will be easier then.

Regarding slider driving modules, it's just what I've set priority now you can also read what is current status in this log which i mentioning goal is that with just using controller and stepper-driver module you should be able to run every slider powered with stepper easily, so it's should be definitely possible to drive your slider with it.

Now this is possible to catch "right moment" without knowing speed of bullet, just to sense passing bullet(or actually shoot with pneumatic gun module) and then with "trial and error method" adjust flash/photo delay using "VAR delay" block you can change it from control panel, so this is approach from "another side of equation" .

I considered such possibility in past, but i came to conclusion that it will be not exactly in "assumptions for project" way, which was to keep modules simple as possible... but back then i thought about doing it with single module and after you mentioned it I thought that maybe with using two sensor modules and then doing calculations on controller side... there will be just need to add new block for, I will keep it in mind as this can be interesting feature, thanks for hints ;)

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates