The “laser” is an LCD Projector (thanks Don!) pointed at the audience. I wrote a program in Processing using the Minim library for beat detection. By applying filters to the input audio, you can extract the beat in real time and use that to control a number of variables, such as timers, colours, sizes, rotations, etc. This however proved unsatisfactory. The “show” it produced looked random and uninspired. I then recorded the output to video, made loops out of the animations, and then used a video editor to try to figure out what looks good and why. I ended up treating the video loops like breakbeat drum loops, chopping and slicing them up, laying them over each other, and keeping everything tight by quantizing to the audio channel. I also used some video effects to create transitions. This was eventually presented as the “laser show”, and now I’ll go back to Processing and see if this type of manipulation can be automated.
In order for this to work, the room has to be filled with smoke. A projector is much to bright to look at, even if projecting nothing but black. The smoke takes the glare off the projector, and gives the beams some volume. Smoke is generated by a small “Halloween” smoke machine (thanks Agnes!)

I also built a chipKit powered “dowser” to flip a flag over the lens with a servo whenever nothing was being shown, but this was unnecessary in practice. Eventually this as to tie into the VGA cable, and whenever the RGB lines went low the flag would flip down covering the lens. There’s provisions for two dowser flags, and one VGA control line, so that two projectors can be used for the show, but only one will project at at a time.

There was going to be another projector used for this show, in sync with the main projector using VLC’s network-sync feature. However Kwartzlab’s wifi was saturated and I wasn’t able to get a stable connection. Next time I will use a wired network. In hindsight I think this would have detracted from the show, so no loss by not having it.

  Thanks Karl for the pictures!

Those who’ve been following the evolution of this library, will probably be familiar with the SwitchInput class. It was intended (among other things) to provide functions that would only be called when a physical switch was closed or opened. The EventHandler class is similar, except that the conditions upon which the event is triggered are configurable and the function isn’t limited to running a single loop when the event occurs. I actually considered re-writing the SwitchInput class to be more like this, but given that it might break programs that people had written with it, I opted not to. Perhaps I’ll create a replacement in the future. Like SwitchInput, EventHandler is drived from the Thread class, with the loop() function overwritten. In its place are two protected virtual functions: condition() and on_event().

The condition() Function:

This is the function that is used to determine when the event is to be triggered. Basically, while the EventHandler object is idle, this function will be called every time the object is invoked by a ThreadList object. If it returns true, the event will be triggered, but if it returns false, the handler will remain in an idle state (this is one of those cases where I wish C++ supported lambdas (but that may be the LISP programming I’ve been doing talking (it’s hard to tell, really))).

The on_event() Function:

Once the event has been triggered, instead of calling the condition() function, the on_event() function will be called in its place. This can be thought of as a conditional loop() function. The difference being that when it returns false the handler will return to an idle state and wait for the condition() function to return true again rather than destroying itself.

A Note about kill_flag:

With a regular Thread object, the loop() function is expected to watch the kill_flag value. When it is set to true, the loop() function is is expected to terminate gracefully. As a help, this functionality is already built into the EventHandler::loop() function. If the handler is in an idle state, it will automatically terminate itself on its next call, however it may be advisable to have the on_event() function watch for this value so that it can facilitate a graceful termination (although, this is not strictly required as the handler will be terminated when the function returns false).

While I don’t feel I’ve done anything particularly ground-breaking with this new release, I hope I’ve created an adequate framework for other Arduino developers who don’t want to re-invent the wheel. As usual, I’ve made all the code and documentation available for this version.

Happy Hacking!

Wiring Switches to the Arduino

The simplest and easiest way to connect a switch is to just wire a dry contact switch directly from the input pin to the ground pin taking advantage of the Arduino’s internal 20k pull up resistor. That way, when the switch is open, the input will read HIGH, and when it’s closed, the input will read LOW (although, this is a little counter-intuitive for most people).

NOTE: Pull-up resistors usually don’t work well for pin 13 because of the built-in LED (see below).

The next way is to supply your own pull-up resistor by wiring the switch the same way, but also running a resistor between the 5V power output pin and the input pin. I’m not sure why anyone would choose this option over the former, but you could if you really wanted to. The logic for reading this switch would be the same as in the previous case.

The last way is to supply a pull-down resistor. In this case, you hook your dry contact from input to the 5V supply, and your resistor from the input to the ground pin. In this case, the logic makes more sense, where a LOW input level is an open switch and a HIGH input level is a closed switch. This option works well with pin 13.

What SwitchInput Provides

Primarily, SwitchInput is intended to provide a layer of abstraction for a switch. Instead of thinking of a switch input in terms of HIGH and LOW logic levels, it allows you to think of the switch in terms of open and closed states, which is a little easier on the brain. The SwitchInput class has is_open() and is_closed() member functions that will return true when the switch is open or closed respectively (and false otherwise… obviously).

That’s hardly the best feature of the SwitchInput class however. Another handy feature of this class are the on_open() and on_close() functions. These are virtual member functions that are automatically called when the state of the switch changes, and can be overridden to perform tasks in an interrupt-like manner when these events occur.

As their names would imply, the on_open() function is called when the state of the switch transitions from closed to open, and the on_close() function is called when the switch changes from from open to closed.

That brings us to our third feature: automatic debounce filtering. This helps to clean up “dirty” input signals. With most switches, when you close or open them, they don’t transition cleanly from one state to another; the voltage tends to “jitter” back and forth. Without some kind of filtering, this would cause on_open() and on_close() to be called repeatedly for no reason, which needless to say, would be undesirable.

This feature operates transparently. When the voltage level of the input changes, the object will wait for a pre-determined number of milliseconds (50 by default) before doing anything. If at the end of this time period, the level is different from what it was at the beginning, the appropriate function (on_open() or on_close()) will be called. Otherwise, the input change will be treated as a spike and be ignored.

A Note about SwitchInput

This class is derived from the Thread class since it needs to do logic in the background for the debouncing and edge-detection. As such, it must be added to a ThreadList object (such as main_thread_list) just as any other Thread object would. Don’t expect your switch to work if you forget to do this.

Source and Documentation

As always, the most recent version of the source is available under the GNU General Public Licence on GitHub, and the documentation is available on my web site.

Happy Hacking.

EDIT 2010-11-11:
As of version 0.4, the SwitchInput class now has time_open() and time_closed() member functions which will return the time for which the switch has been open or closed (in milliseconds).

Anatomy of a Typical Arduino Program

In order to understand what this library does, it is important to first understand what a typical Arduino program looks like.

A typical Arduino program has two main functions. First there is a setup() function that is called once when the system is powered on. This is typically used for initializing variables, setting pins as input or output, starting up serial communication, etc. Once the setup() function completes, there is then a loop() function that just gets called again and again and again and again… until the system loses power or breaks down.

So What Does this Library Do Differently?

First of all, a program that uses this library has no main loop() function (well, it does, but it’s part of the library; it doesn’t have to be separately written).

Instead, the library provides a Thread class. This class can be derived from to provide the basic functionality for a single thread. Each Thread has its own loop() function which works in basically the same way as the loop() function we all know and love. The only major difference is that the loop() function in a Thread returns a boolean value (true if the loop needs to be called again or false if it doesn’t). When the Thread completes, it will automatically destroy itself freeing the memory it occupied to be used for other things.

ThreadList Objects

Once a Thread object is created, it then has to be added to a ThreadList object (through the add_thread() function). One of these is already created by the library. It’s called main_thread_list and it’s run in place of the main loop() function.

What a ThreadList does is call the loop() function from the first Thread in the list, then it calls the loop() function from the next one, and so on and so forth. Once they’ve all been called, it returns to the first Thread and starts over again. Whenever a Thread has completed its run, it is automatically removed from the ThreadList.

Tiered ThreadLists

An interesting thing about ThreadLists is that they are Threads in and of themselves. That way a tiered system can be crated where a lower-priority ThreadList object can be placed inside of a higher one. That way, the higher-priority ThreadList will call one loop() from each of the high-priority Threads, and then a loop() from the first Thread in the lower-priority list. It will then call the loop() function in all of the high-priority Threads again, and then the next one from the low-priority list… and so on.

The kill() Function

Rather than waiting for it to run its course, a Thread can be killed by calling its kill() function. There are two levels of “kill” that this function offers. The first (recommended) way is much more polite. It simply sets an internal variable called kill_flag to true telling the Thread that it should start finishing up. Its loop() function is expected to check for this and behave accordingly.

The second way of killing a Thread is to call kill(true). This will essentially kill the Thread outright without any warning. Do not use the delete keyword on a Thread! This will cause memory corruption.

Limitations

One of the major potential problems with this library is the fact that a single Thread that gets hung will lock the entire system up, since the next Thread can’t be called until the current one finishes its loop() function.

For this reason, it is unwise to use blocking functions such as delay(), because they will cause a delay in all the other threads as well. To help get around this, the Thread class has three functions that will not allow the loop() function for that Thread to be called again until a specified amount of time has passed. These functions are sleep(), sleep_milli() and sleep_micro(); which suspend the Thread for a set number of seconds, milliseconds and microseconds respectively.

The Thread class also provides pause() and resume() functions. As the names imply, the pause() function will suspend the Thread until the its resume() function is called. Obviously, the resume() function would have to be called by another (non-suspended) Thread, so care should be taken with these functions.

Where Can I Get It?

The library is available for download under the terms of version 3 the GNU General Public License on github here. The full documentation for the library can be read here.

Hopefully, this will be useful to someone other than me.

Happy Hacking.

EDIT:
I almost forgot to mention that this library also requires another simple library called newdel to enable the new and delete keywords. It’s available (public domain) here.

EDIT 2010-10-09:
Moved the project to github and updated the links.

EDIT 2012-07-01:
This library is now available under the Lesser General Public License (verion 3 or later).

The Arduino is a micro controller that can read inputs such as push buttons, switches, sensors and control output devices such as motors, lights, buzzers and much more.

Some things you can do with the Arduino are:
infrared limit switches
hijack a remote control
analog needle gauge
reflective infrared detector
buzz a buzzer
twirly knobs, we call pots
drive an LCD
If you are wondering “can I do this with an Arduino?”, why don’t you ask us?

We will have computers with Arduinos already set up to demonstrate some of their many uses. If attendees wish to bring there laptops in we will help them get the software running.
There will be a $20 fee to cover cost of materials. We are getting some new boards in for the event for people to try out.

When: Saturday February 27, 1-4 PM

Where: Kwartzlab 283 Duke St. W, Unit 106, Kitchener, ON

Cost: $20

RSVP to events@kwartzlab.ca

Hosts: Andrew Mackie and Bevan Lantz

I still have to support writing memory and registers, and complete the support for breakpoints. I also need to optimize the rather sloppy, inefficient code. Right now it takes up a fairly sizable chunk of the program memory. I also have ideas how I might shrink the Arduino stub down really, really small, by putting another PC-based layer between GDB and the Arduino stub.

Running with breakpoints enabled will, unfortunately, slow the system down considerably. This is because there is no (easy) way to stuff a breakpoint instruction into the AVR’s flash program memory. So, breakpoints are actually implemented by continuously single-stepping until you hit one.

And single-stepping itself is not free. The AVR has no internal mechanism for single-stepping. It’s implemented by forcing a hardware interrupt on one of the IO ports. Fortunately, it will let you choose which IO port to use, to hopefully avoid a conflict with your system’s requirements. Currently Analog Comparator (Port D:6,7), External Interrupt 0 (Port D:2) and External Interrupt 1 (Port D:3) can be used for single-stepping.

The following parts were used:

Basic Setup

The menu Tools –> Board –> Arduino Deumilanove w/ ATmega328 was selected.
The menu Tools –> Serial Post –> (appropriate port) was selected. Note the port needs to be selected each time a different Arduino is connected to USB. One automatically binds to COM3 and the other to COM4; there is most likely a setting somewhere to have these on the same COM port, but that would later preclude connecting both at the same time.

Testing the XBee

The shield and wireless module were assembled onto the Arduino. The jumpers on the XBee shield were put into the outward position. The Arduino was plugged into USB. The following sketch was uploaded:

Sketch: XBee_diagnostics

void setup()
{
    Serial.begin(9600);
}

void loop()
{
    Serial.println("+++");
    delay(2000);
    echo();
    Serial.println("ATID");
    echo();
}

void echo() {
    byte incomingByte;

    // see if there's incoming serial data:
    delay(50);
    while (Serial.available() > 0) {
        // read the oldest byte in the serial buffer:
        incomingByte = Serial.read();
        Serial.write(incomingByte);
        if(incomingByte != '\r') {
            Serial.write(' ');
        }
        delay(100);
    }
}

The Arduino was unplugged from USB, the jumpers switched to the inward position, then the serial monitor activated. The XBee should be responding with 234 as the ID (for Series 2).

Configuring

Use X-CTU to configure. Alternatively, any serial terminal will do. Note that the ATmega328 must be removed and the XBee shield pins placed in the outward position for this to work.

It may be preferred to configure the XBee module as part of a sketch and avoid removing the processor or finding a terminal program. The diagnostic sketch may be modified to with the following:

void loop()
{
    delay(2000);
    Serial.println("+++");
    delay(2000);
    echo();
    Serial.println("ATDL FFFF");
    echo();
    Serial.println("ATWR");
    echo();
    delay(10000);
}

After configuring, the Arduino was unplugged fro USB.

Transmitter

The jumpers on the XBee shield were put into the outward position. The Arduino was plugged into USB. The following sketch was uploaded:

Sketch: Send_physical_pixel

const int ledPin = 13;

void setup()
{
    Serial.begin(9600);
    pinMode(ledPin, OUTPUT);
}

void loop()
{
    digitalWrite(ledPin, HIGH);
    Serial.print('H');
    delay(1000);

    digitalWrite(ledPin, LOW);
    Serial.print('L');
    delay(1000);
}

The Arduino was unplugged from USB, the jumpers switched to the inward position. Then the Arduino was plugged into USB and the serial monitor activated. The serial monitor showed a string of HLHL… The LED was flashing at 0.5 Hz.

The Arduino was unplugged from USB, and the plugged this into the power adapter. The LED continued to flash at 0.5 Hz.

Receiver

Now for the second Arduino with XBee shield. The jumpers on the XBee shield were put into the outward position. The Arduino was plugged into USB and the following sketch Sketchbook –> Examples –> Communication –> PhysicalPixel was uploaded (unchanged).

The LED on the receiver is observed going on and off. However, not at regular 1 second intervals – the XBee sometimes groups the H and L sends together so these will be read at irregular intervals.

More Details

Note if you are in an area with ore XBee modules, then more configuration will be required to prevent all pairs from interfering with others.

Jumper meanings

When loading the Arduino while the XBee shield is attached, ensure the pins are in the USB position. Here’s a table of the explanation of jumper settings: