In my earlier postings I mentioned that I have been using a PhotoTrigger unit to take some of my droplet photographs. It might be worthwhile spending just a couple of moments explaining why I have moved on from that unit to the complexity of the Arduino project.
First let me state that I have no criticism of the PhotoTrigger unit and I should point out that everything I am doing with the Arduino you can now do with a PhotoTrigger box and its add-on components ( or so I believe ).
But I do have a background in computing, some experience of programming – and I have held a soldering iron on a couple of occasions without burning myself! And building something from the base upwards did have a certain appeal. Perhaps a little like the attraction of mountaineering to some – the mountain is there, so why not climb it?
I also realised that I didn’t need to use the laser trigger that comes as part of the PhotoTrigger kit ( see my previous update ). Some basic maths, and the trial-and-error hunt that I alluded to before, would get me close to the required timings needed to trigger the valve and the strobe units.
However, what was more critical was that the basic PhotoTrigger unit didn’t have the functionality to trigger a solenoid valve. I needed some extra kit, and having read about the Arduino on-line and in some magazine articles, that seemed to be the route to take.
But everything I am doing here – and the bits I intend to add on in the future – can all be achieved by using the full range of the PhotoTrigger equipment – as well as a number of other similar units that are available out there. You just pay your money, you make your choice. And I took on the challenge of using the Arduino – and a soldering iron.
The Arduino unit that I am using is the Uno R3 microcontroller board.
But that board, on its own, does nothing. To come up with a working device I had to do some basic electronics, re-learn how to use that soldering iron and get immersed, once more, in some computer programming – or coding.
I also needed the help of some friends to help me with the additional electronics I would have to build. My knowledge in that area was almost zero and their input was invaluable. Without them I wouldn’t have made it ( in both senses of the expression! ).
But, with their support, I did put together an initial working system that would operate the valve and, as a second stage, trigger the strobe units. But the limitations of that first build soon became apparent. As I started to take photographs using the system I had built, I found myself time and time again altering those timings I talked about earlier – the length of time the valve would remain open, the delay between the two droplets and the timing for the strobes to be activated. And that was a tedious procedure.
The Arduino is programmed ( and can be powered ) via the USB port of another computer – lets call it the master computer. Without that ‘master’ computer, you can do very little with the Arduino. The program that will run on the Arduino is written on the master computer in a formal programming language. That program is then converted – ‘compiled’ in computer speak – into something the Arduino will understand and that compiled version is sent via the USB connection into the memory on the Arduino board.
If, whilst running the program, I wanted to alter any of the timings I would have to change the values embedded in the original program on the master computer, re-compile it and send this new version to the Arduino. It became apparent that this wasn’t the way to operate. What I needed was some method to interact with the running program and to be able to alter the timings without recourse to the master computer.
As an aside, the ability to break that umbilical USB connection between the Arduino and the master computer is also quite important. It would be a severe limitation of the Arduino set-up if you could only use it in this configuration. Indeed, once the program has been loaded onto the Arduino, the board is designed to be powered from a stand-alone power supply, or even a 9v battery, without the need for a master computer to be present. For that reason alone, I needed to find a method by which I could alter the timings as the program was running.
Each of these values – the separate timings I mentioned above – are stored as something called ‘variables’. Remember the horrors of algebra at school? “ x + y = z “ and all that? Well, x, y, and z are like the variables in my program; they are just names for numbers and I can assign to those variables the values of the timings that I want to use. And when the program needs to know the timing for some particular action, it reads the current value assigned to that variable. All I needed to do was to find a way of updating the variables in real time!
My first attempt involved a series of switches that would enable me to select the variable I wanted to change – and then use a rotary switch – rather like a volume control – to adjust the value as required. But there was a problem here: I had no idea how the value of the variable was changing as I rotated the control.
It was about this time that I discovered ‘shields’. Nothing to do with knights in armour or Star Trek. These shields are attachments to the basic Arduino board that add extra functionality. And my major discovery was the LCD Keypad Shield.
With some extra programming I could have the value of a selected variable displayed on the LCD screen. Furthermore, I could see value of that changing as I rotated that control knob. This was a major step forward – until I realised that it wasn’t the whole answer. In fact, it highlighted two further problems for me.
The first was that the rotary control was not going provide an accurate method of setting the value of a variable. The values produced from the control were – in non-technical terms – bouncing up and down. This was presumably a feature of the basic electronics in my circuit and no doubt someone with greater knowledge than myself could have solved this problem. But about that time I had something more pressing on my mind.
The electronic circuit that I was building was being driven by the Arduino. That necessitated a number of connections between my circuit and the Arduino: bits of wire, in reality, that linked certain inputs or outputs on the Arduino to the components on my circuit. But the LCD Keypad Shield also had to be connected to the Arduino – and that required several of my already allocated connections. Some rethinking was required – and it became obvious, very quickly, that if I were to continue using the LCD Shield, I would have to give up on my plan to use switches and rotary controls to select and re-assign variables. There were just not enough connections to go around.
But the LCD Shield that gave rise to this problem also solved it. It has built into it five push buttons and, by writing some additional code into the program, I could detect if any of these buttons had been pressed. I could use that button press to select one of my variables – a different variable for each button – and so I could do away with the switches I had initially allocated for that purpose. Furthermore, once a variable had been selected, I could use the same four buttons to update the value of that variable – doing away with the need for the rotary control.
I was making progress – but it seemed, at times, painfully slow!
I found the learning curve in respect of the Arduino quite steep. I had a book which set out the basics of the board and its programming language, plus the immense support of those friends who were helping me with the electronics. But none of them had an in-depth knowledge of the Arduino. As I said, progress was slow. Of course, most of what I have described above can be found online and there is an incredible amount of information to be found on the Arduino home site ( http://www.arduino.cc ). Just google ‘arduino’ and the door will open. But the difficulty I have with digging out knowledge online is that I fear you will only ever find a useful, meaningful answer if, in the first place, you know the exact language to use when framing your question. And part of the problem is, of course, you don’t know the words to use!
None of this was helped by the fact that neither the basic Arduino board nor the LCD Shield came with any accompanying documentation. The book I referred to earlier was a help, but it didn’t contain much in the way of in-depth information. Much of what I have found out has been by trying things – and I’m quite surprised that this hasn’t resulted in me damaging the board in any way. ( Well, not yet! )
Partly because of this lack of documentation, and partly because of the difficulty in finding relevant information amongst the mass of related writings on the internet, it took me a while to discover that the Arduino has another useful trick concealed up its sleeve. The program to control the solenoid valve and the strobe units had to be given some initial settings for the various timings. But when the program was terminated, normally by the crude action of removing the power to the board, the values that were currently held by the variables – bearing in mind that I may have changed them several times during the running of the program – would be lost. This means that when the program is run again the variables will revert back to those initial values as set up in the original program.
But I now realise that it is possible to store information on the board long term in something called an EEPROM ( sorry, I’m just showing off! ). This means that even if I turn the power off and then reload the program some time later that same information will be available for me to re-use.
And that’s where I am now: not only can I adjust the values of the various variables in real time, but I can instruct the program to store these values into memory on the Arduino board. And the next time that I run the program – be it hours or days later – I can pick up those values again and carry on from where I left off, last time around.
My next challenge? To get the programme to fire the camera as well as the valve and the strobe units.
Can it be that hard?