09/12/2019 at 18:50 •
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:
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" 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:
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.
09/11/2019 at 16:32 •
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" ;)
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!!: https://hackaday.io/project/11224-mechaduino 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).
08/24/2019 at 18:09 •
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 :).
it's Python app sources which is running on controller.
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 (https://vocore.io)
- 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: https://vocore.io/v2.html
08/24/2019 at 14:02 •
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
Crashed bulb was hooked to mains AC, so needed to be extra careful here I used power strip with a switch, so every time I was getting close to it i just switched it off. So safety was biggest challenge here, other thing was easy, program was done in that way that it just turned on relay for short time and then camera was triggered, usually bulb was turned on for 100-200ms,but I used block which enabled me to change delay from control panel, so for each shoot I could change it.
Hmm so maybe let's try to shoot with bullet to it?
I also got some partially crashed bulbs with non broken filaments, so I thought maybe It will be good idea to, try to combine this and shoot with projectile to it while it filament was burning and this idea was not so good, as light from bulb was causing some motion blur, but I got one quite decent photo, which you can see above.
Some more from this session:
Shooting to colliding droplets with projectile
I was also done some photos of colliding droplets hit with projectile from pneumatic gun and generally it was not so hard as I thought, surprisingly what made the most difficulty this day was to make droplets colliding nicely, possibly this was due liquids properties which i used or shape dish or something, hard to say, but droplets was not so tall and nice, but anyway i was able to catch some photo which can be shown as example.
2 flashes connected to one port(through dividing cable), droplet module(port red) and pneumatic gun(port green)
I made some few more tries with catching photo of colliding droplets which are hit by projectile, setup was almost same as above(only container which hold liquid where drop is hitting was different, as I observed that it can make significant difference in first droplet "jump" height):
08/20/2019 at 19:41 •
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:
After setting port into "step" mode following block will become available:
08/18/2019 at 15:13 •
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.
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... :)
08/17/2019 at 19:01 •
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] ).
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 :)
08/13/2019 at 18:50 •
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)
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.
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)
Reasoning behind naming port's with color's was that it's easy to distinguish quickly in program editor which port is being used.
So what's under the hood of currently implemented module
valve: Aliexpress link , those are marketed as fish tank valve ;)
For bullets i use something which is called clamping screw, which i get at local hardware store, they are cheap, working very well and even looks like bullets: google search link
barrel is just piece of stainless 10mm pipe, glued with to threaded reduction piece.
Solenoid driver source: https://github.com/krzysztofkrzeslak/pixpi-solenoid-driver
08/11/2019 at 07:37 •
Today I wanted to share with effect of usage light sensor with laser which I shared in previous log.
08/09/2019 at 18:12 •
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 ;)
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 ;)