Archive | Learning to Arduino RSS for this section

DMP Photo Booth 1.0

Well, the day has come and gone. DMP Photo Booth’s final test on June 21st went off without issue, and DMP Photo Booth has left Beta and is now considered “production ready”. The initial 1.0 release can be found on GitHub.

The significance of June 21st is the very reason DMP Photo Booth was created; the 21st is the day of my wedding. My wife wanted a photo booth for the reception. We looked into renting a photo booth, but it turns out that they run around $1,000. I turned to open source. Some quick googling turned up some options, but they were all personal projects or out of date. Sure I could get somebody else’s project working, but what’s the fun in that? I decided that we didn’t need to rent one, or download one, I could build it!

In late 2013, I set to work in earnest. I had a couple of months of downtime in school, and since I’m not currently working it was the perfect time. I decided I had three main objectives for this project: get some arduino experience, get some GTK+ experience, and do this all as portably as possible. I had initially decided to mostly ignore GLib and focus on GTK, but slowly I grew to appreciate GLib for what it is: the standard library that C never had. First I used GModule to handle shared libraries in a portable manner. Next I decided to use GLib primitives to keep from having to deal with cross-platform type wonkiness. Next, having grown tired of dealing with return codes, I refactored the project to use GLib’s exception replacement: GError.

Lessons Learned

It’s not all roses and puppies though. There are certainly things I’d do differently. DMP Photo Booth is developed in an Object Oriented style, passing opaque structs with “method” functions that operate on them. Each component of the program are organized into their own source file with file scoped globals scattered throughout. Said globals are protected by mutexes to create a semblance of thread safety. That said, threading issues have been a major thorn in my side. Long story short: I regret this design choice. While I still feel that this is the correct way to structure C code, and that if globals are required, this is the correct way to handle them; I feel that I should have made more of an effort to limit side effects. Recently, I’ve spent some time doing functional programming, and if I could do it again I’d try to write in a more functional style. Fortunately for me, this is something that a little refactoring could help with.

Additionally, one thing I thought would be a major help is something that began to be a major thorn in my side: NetBeans. As the size of the project grew, NetBeans got slower and slower. It seemed that I spent more time fiddling with IDE settings than actually coding. Even worse is that the IDE-generated makefile is so convoluted that it’s extremely difficult to modify by hand in a satisfying way. I’ve always coded with and IDE so I wouldn’t have even considered not using one, but then I spent some time with Haskell. One of Haskell’s “problems” is that it doesn’t have good IDE support. It doesn’t seem like any IDE really handles it well, so most people use Emacs. Personally, I haven’t really warmed up to Emacs, but GEdit has syntax highlighting for Haskell and a built-in terminal for GHCI. GEdit also has syntax highlighting for C. Next time, I will seriously consider using a lighter-weight text editor for a C project. All this said, I think NetBeans for Java remains the way to go.

What’s Next

Like any program, version 1.0 is just one of many versions. There certainly remains a lot of work to do with DMP Photo Booth. Some major items you are likely to see whenever I get around to working on DMP Photo Booth some more:

Options Dialog

I think anybody who has seen it will agree: the options dialog in DMP Photo Booth is bad. It’s poorly organized, and kind of wonky. Personally, I modify settings using the .rc file, which is telling. This is certainly a high-priority improvement.

Functional Refactor

Like I said above, the code could use a pass to limit side effects. Funtions need to have their side effects limited, and globals need to be eliminated unless absolutely necessary. However, C is not a functional language. While one could argue that function pointers enable functional programming in C, this is a very pedantic argument. I won’t be going crazy with functional programming techniques. There will be no Monads, or for loops being turned into mappings of function pointers.

Optional Module API

An idea I’ve had on the back burner for a while is an optional module API. This would be used for very specific quality-of-life things. For instance, a module could provide a GTK widget to be shown in the options dialog. Any module that doesn’t want to implement any or all of the optional API can just ignore it. The module loading function will gracefully handle the dlsym failure, just treating it as it is: declining to implement the API. I have no plans to change the current existing API, so all you module developers can rest easy!

User Interface Module

It occurred to me that it might be good to have a UI module. This would provide the UI, and wouldn’t be tied to the trigger/printer/camera module start/stop system. This module would be loaded at startup and unloaded on shutdown. This would allow the Photo Booth to use different widget toolkits: QT, Curses, Cocoa, WinForms, or whatever else. Under this scheme, the current GTK+ interface would be abstracted into the reference UI Module.

Learning to Arduino: Push Button

Getting a little less abstract today, I’d like to talk about the Push Button. Sorry, that doesn’t have a fancy name. Try to contain your disappointment.

The push button is actually very simple in theory. Most push buttons have four contacts. Two of these contacts are connected at all times, and there is a normally open switch between the two “wires”.


When the button is pressed, the contact closes. The tricky part comes in the implementation.


You’d be yelling too if you’d spent as much time as I trying to figure this out.

A typical application of the Push Button, is in an arduino device. Arduinos have multiple digital pins that can be configured as inputs or outputs. Google Arduino Push Button Tutorial, and you’ll find several tutorials that suggest you implement something similar to this:


The thing that nobody is talking about: what is the voltage of the digital pin in input mode. This is the thing I’ve been spending the last few hours trying to figure out: how does this work? If the voltage is 0, nothing should happen when the button is not depressed. If the voltage is 5, then nothing should happen when the button is depressed. It turns out, according to my multimeter, that this pin is actually very slightly less than 0 Volts.

As you can see from my diagram, the digital pin is connected to the switch, and the opposite end is connected to a 10K Ohm resistor to ground. On the other side of the switch is 5 Volts. When the switch is open, electrons flow from ground (0 Volts) to the input pin (slightly less than 0 Volts) and digitalRead() returns LOW. When the Push Button is depressed, electrons flow from the input pin (slightly less than 0) to the 5 Volt pin, and digitalRead() returns HIGH.

All is again well in the world.

Introducing DMP Photo Booth

In June of 2014, I will be getting married. One problem: I am currently an unemployed student, and my fiancee Liz is also between jobs. Recent studies show that the average couple in this day and age spends an average of Twenty Four Bajillion Dollars on their wedding. Capital Bajillion. Italicised. Even were I still employed, this would pose a problem for me. Needless to say, we began looking for costs to cut. Liz really wants a photo booth, and I think it sounds fun. Unfortunatley photo booths run from $750-1000 to rent. The solution: DMP Photo Booth.

On Reinventing The Wheel

DMP Photo Booth wasn’t actually my first thought. That would be “well, there must be some open-source photo booth software we can use!” It turns out that there is. People like me who’ve had this issue and whipped something up for themselves. Some of these projects even have fancy websites. Unfortunately, none of these seem to have reached the level of maturity where you can just grab them and go. No, we’re talking old-school Linux status projects. If I’m going to have to put that much effort into making this work, I might as well roll my own. Besides, it will be good experience.


The photo booth must do the usual photo booth stuff; it should programatically take 3-4 pictures, arrange them in a vertical strip with a background picture, and print them on photo paper. This should all work with the user only having to press a button(not a key on the laptop, an actual button), and there should be some sort of indicator when the pictures are going to be taken.

Some reasearch turns up the existence of a Picture Transfer Protocol, or PTP, that has been “supported” by the major camera vendors since 2002 or so. PTP allows you to programatically control a digital camera, and should serve nicely. I own a printer that can print on photo paper; it seems likely that I will be able to use the operating system’s printing facilities to handle this. Finally, I will construct a button and indicator thingamabober using Arduino.


I have decided to go with a modular architecture. There will be four components: a Camera Module, a Printer Module, a Trigger Module, and the Core Application.


The Core Application will bring the GUI, tenatively planned to be implemented using GTK+3, and will interface with the component modules. The core expects the component modules to implement specific functions that will be called to handle their operation. The component modules will be dynamic libraries that can be swapped out at runtime.

Camera Module

The Camera Module will handle the operation of the camera. The Camera Module currently is expected to implement two functions:

int dmp_cm_capture(); int dmp_cm_download(char * location);

These two functions do what they say: the first takes a picture, and the second downloads the picture to the passed-in path. The reference Camera Module will use libgphoto2 to implement these functions, but this module exists to provide the capability to use any method. A module that uses some other PTP library, or some custom protocol, or a dummy module that uses a picture on the filesystem, or uses a scanner, or anything else can be swapped in at runtime and this will all be transparent to the Core.

Printer Module

Shockingly, the Printer Module will handle printing. The Printer Module is currently expected to implement one function:

int dmp_pm_print(char * to_print);

This function prints the file at the path that is passed into the function. This module prevents the Core from needing to know how to print. The Core tells the Printer Module to print, and the Printer Module can figure out how to print in Linux, or Mac OSX, or how to print to a Game Boy Printer, or whatever. The Core doesn’t care.

Trigger Module

The Trigger Module is the module that knows how to operate the custom photo booth equipment. The Trigger Module currently is expected to implement two functions:

int dmp_tm_add_trigger_handler(void (*th)()); int dmp_tm_set_countdown(int current);

The first function adds a callback function that will be called by the Trigger Module when it detects that the button has been pressed. The second function updates the countdown indicator. Since some dealybopper that I made out of Arduino is basically the definition of non-portable, I decided to create a module for it. The reference implementation will be written for my equipment, but this module can be replaced with one that uses some other input device with minimal effort.

Moving Forward

DMP Photo Booth represents my first major open source project, and it has many moving parts. With this groundwork laid, I have broken the project down into more manageable chunks. I have four main components that each represent different challenges: GUI programming in the Core, poorly documented mystery libraries in the Camera Module, Learning to Arduino to finish the Trigger Module, and learning the Linux printing system for the Printer Module.

Rome wasn’t built in a day, but it was started in one. There will surely be many challenges and roadblocks on the way. Expect to hear all about them here!

Learning to Arduino: the LED

…and now for something a little more basic: the LED. Those little blinky lights that keep us up at night. What electronic device is complete without them?

The Basics

LED stands for Light Emitting Diode. Yep, like that. Luckily for us, we don’t need to muck about with I/V curves; we only need to know three things to set up our LEDs: the supply voltage, the LED voltage, and the LED current. These values should be provided on the packaging for your LED, on the vendor’s website, or on the datasheet.

Supply voltage

This is the voltage provided by your power source. If you’re using an Arduino, it will be 5 or 3.3 volts. If you’re using some other power source, it will be the value provided by your power source.

LED voltage

This is the voltage ‘consumed’ by the LED. Say you’re using one 2 volt LED, your supply voltage must be higher than 2. If you’re using two 2 volt LEDs, your supply voltage must be higher than 4. If your supply voltage does exceed the combined LED voltage, none of your LEDs will light up.

LED current

This is the safe operating current for your LED. If your current is low, the LED won’t light. If your current is high, your LED will burn out. It is really easy to destroy your LED, so don’t just do whatever and hope everything will be fine; it won’t be and you’ll be out $0.35.

Wiring it Up

So, you’ve got your supply voltage, LED voltage, and LED current, what now? In order to get our current down to the LED current, we need to use a resistor. In order to calculate what resistor to use, we need to use Ohm’s Law. Specifically we need to calculate the resistance by dividing:

R = (Supply voltage - LED voltage) / (LED current / 1000)

LED current will be given in units of miliamps, therefore we must divide it by 1000 to get the amount in amps. This formula will give you a value in Ohms. For example, I have an LED with a LED voltage of 2.2, and an LED current of 17 miliamps. I will be powering this using a digital output pin on my Arduino Uno, which outputs 5V. Doing the math:

(5 - 2.2) / (17 / 1000) = 164.706

What’s that; you don’t have a 164.706 Ohm resistor? That’s fine, just use one that is close. Pick one that’s a little high, rather than one that’s a little low; better to not have it light up than to burn out. I’m going to use a 180 Ohm resistor.

Now that we know what resistor to use, it’s time to hook it all up. You should wire it up like so:

Note that your LED will have two legs: one will be shorter than the other. The long leg should be hooked up to positive, the short leg should be hooked up to negative. If they are reversed, your LED will be reverse-biased, and won’t light up. This is another good way to potentially destroy your LED.

Open up NetBeans, which I’m assuming you configured for arduino, and create a new arduino project. We’re not doing anything fancy today, we just want our pin to output. Your implementation should look like this:

#include <Arduino.h> extern HardwareSerial Serial; int led = 13; void setup() { pinMode(led, OUTPUT); } void loop() { digitalWrite(13, HIGH); }

Upload your project and, assuming all is well, watch your LED light up!

That Sounds Like a Lot of Math…

Yep. Pretty much. Luckily there are calculators on the internet for figuring these things out. Here’s a nice one that I found while researching this blog post. Feel free to never figure this out on your own again.

Learning to Arduino: the Diode

So, what is a diode? A diode is an electrical component that allows current to flow in one direction, but not another. On an electrical diagram, a diode is represented by this symbol:

The physical diode may have a black band on it, this band corresponds with the band on the symbol. One use for a diode is to protect against the power source being hooked up backwards. Let’s look at an example.

In this diagram, the diode is hooked up backwards. This configuration is said to be reverse biased. In this configuration, ‘no’ current will flow across the circuit. In fact, if the current exceeds the diode’s Maximum Repetitive Reverse Voltage (VRRM), the diode will be damaged. This value can be found on the diode’s datasheet. When I say ‘no’ current flows in this configuration, I actually mean a negligable amount of current flows. More on this in a minute.

In this diagram, the diode is hooked up in the correct direction. This configuration is said to be forward biased. In this configuration, current will flow across the circuit. How much current? Well, according to Ohm’s Law:

1.5 Volts / 10000 Ohms = 0.15 Miliamps

But let’s check just to be sure… If we set our multimeter to amps, and we measure, we get… 0.1 Miliamps… …that doesn’t seem right…

Well, the bad news is that it is just one post into this series, and we’ve already come across an exception to Ohm’s Law. To figure out the current across a diode, we need to use the Shockley Ideal Diode Equation. Do yourself a favor: don’t waste your time trying to figure this out. Just use the Voltage/Amperage curve graphs provided on the datasheet for your diode and save yourself a headache.

Therefore, you will see a somewhat level amount of current flowing through your diode, then suddenly it will shoot up. If this happens, it’s time to consider that you need a different diode.

Learning to Arduino: Ohm’s Law

For a good six months now, I’ve been trying to “get into Arduino”. I’ve been doing this mostly by a) throwing money at it and b) just trying stuff. This has been going about as good as you’d imagine. Reflecting back on when I first tried getting into programming, I think about how much better I got at it when I stopped trying to learn C++ and started learning how to program. Similarly, I’ve been spinning my wheels trying to learn to Arduino, perhaps it’s time to learn how electronics work.

In the spirit of this, I’ll be writing this series of blog posts about this. These posts will serve as reference material for myself so I don’t have to google how a diode works, or whatever. Hopefully it’ll prove useful to others as well. I’m not claiming to be an expert. This is my understanding of things, as I go along. If I say something that’s not true, please let me know!


Volts refer to the difference in electric potential between two points.

Amperes, or Amps, refers to the flow of electrons between two points.

Ohms refers to the resistance to the flow of electrons that some substance has.

Some Context

As you may remember from chemistry class, an ion may be positively (if it has more protons than electrons) or negatively (if it has more electrons than protons) charged. Long story short; atoms and molocules do not want to be positively or negatively charged. They will shed or gain electrons until they have equalized their charge. This positive/negative charge differential creates the Volt. The process of electrons flowing from negative to positive creates the Amp. While in transit, the flow of electrons can be impeded depending on the substance they are traveling through. This process of impediment creates the Ohm.

Ohm’s Law

Ohm’s law states that the current through a conductor between two points is directly proportional to the potential difference across the two points. Two variables are said to be proportional if a change in one always results in a change in the other, and the two changes are always related by the use of a constant. In the case of Ohm’s Law, Amps (I) and Volts (V) are the variables, and Ohms (R) is the constant. The formula for Ohm’s Law is:

I = V / R

Basically, if we have two AA batteries (3 volts) connected through a 10,000 Ohm resistor, then 0.3 miliamps are flowing across the wire.

0.0003 = 3 / 10000

Using this, given two of the values, we can calculate the third. Given Amps and Ohms, we can determine Volts:

V = R * I

Given Amps and Volts, we can determine Ohms:

R = V / I

“No Resistance”

So, maybe you hooked a multimeter up to a piece of copper wire, and measured no resistance. Let’s plug that into the Ohm’s Law formula:

I = V / 0

See the problem? The good news is that in the real world, there is no such thing as “zero resistance”. Even the purest copper wire has some amount of resistance. If your multimeter says zero, just keep turning the knob to finer settings until you get some number greater than 0. If you don’t get there, just call it 0.0001 or somesuch really small number. It may not be exact, but it’ll be good enough. The real world isn’t binary, after all.

Meanwhile, fancy scientists wearing fancy labcoats are trying to create Superconductors with 0 resistance. We’ll let this be their problem.

%d bloggers like this: