I really like the idea of the Boarduino, because I found I was doing almost all of my prototyping on a breadboard, and it seemed like I was always trying to figure out new and different ways to anchor the big Arduino down.

To get the size down, Boarduino makes a couple of design changes, most notably the elimination of the female headers on the top of the board, in exchange for the male headers on the bottom, which then plug directly into a breadboard, rather than having a rat’s nest of jumper wires running from the Arduino to the board.

Boarduino also eliminates the USB port and the associated USB chip, much like the Arduino Mini. Instead, to program the board you need either a USB-TTL cable, which plugs into the six-pin header at the end of the board, or an FTDI breakout board like the MiniUSB.

Both the Arduino Mini and Boarduino are designed to plug into a breadboard. The main difference between the two is that the Mini uses a permanently-soldered surface-mount chip, whereas the Boarduino uses a 28-pin socket and DIP chip, so if you blow one, you just spend six bucks and pop in a new one, rather than buying a whole new Mini. In addition, the Arduino Mini lacks Boarduino’s 9V barrel jack and voltage regulator, so you have to design that circuit yourself. Plus, the Boarduino is simply cooler because you get to build it yourself!

The first step is getting your work area all set up, as shown in the image above. (The WES51 really ties the room together does it not?)

Check out the great solder joints done by the WES51. I used a small, stiff watercolor paintbrush and isopropyl alcohol to clean the rosin flux off the board and joints after soldering, leaving a nice, clean-looking board.

Power supply finished and tested, in this case with the USB-TTL cable.

Note that the Boarduino uses a 16MHz ceramic oscillator rather than a crystal. This is slightly less accurate, but only on a nanosecond scale, and not relevant for most projects.

Ready to install the 28-pin socket.

Socket and headers soldered in.

Behold the AVR ATmega168 microcontroller.

Inserting the ATmega168.

Boarduino completed, powered up and ready to go.

Can’t get enough of those close-up solder pix? Check out the rest of my Boarduino photos on Flickr.

My Weller WES51 arrived today (w00t!), and in celebration, I thought I’d compile a list of my favorite soldering tutorials around the web.

How to Solder Correctly: An excellent starting point, thanks to a detailed seven-minute video and lots of close-up images.

Soldering Tips (PDF, 284K): Ten pages of required reading by Tom Hammond, with advice on tool selection, tip tinning, component positioning, and solder types. Lots of great diagrams for all of us right-brained learners.

Basic Soldering Guide: From Everyday Practical Electronics magazine, discusses tool selection, soldering methods, and — perhaps more importantly — de-soldering!

Soldering Basics: This detailed tutorial from SparkFun.com includes several short videos and lots of pictures, then lets you really get your hands dirty with step-by-step instructions on soldering up a basic RS232 shifter board kit.

Surface-Mount Soldering: More and more components and ICs are shrinking in size and doing away with through-hole pinouts. Just go easy on the coffee and you too can solder SMDs!

Basic SMD Soldering: A whopping 8-part solder-a-thon from SparkFun. Starts with tools, moves into surface-mount soldering techniques, then takes it up a notch with hot-air rework — for when you mess up.

Solder Paste and a Toaster Oven: When you have a large batch of PCBs with surface-mount parts, it could be time to ditch the iron and warm up the oven.

Hacking up a Reflow Oven: More crazy antics from the kids at SparkFun. Take a shiny new $50 toaster oven, rip the guts out and throw in a microcontroller. Insert pasted PCBs. Bake for 4 minutes. Let cool and enjoy.

Solder Paste Stenciling: Before those suckers go in the oven, you gotta get the goop on somehow.

Stenciling and Reflowing: With your host, the ladyada herself, making it look easy.

Did he say “Reflow Skillet?”: No cash or time to build an oven? Shell out 29 bucks for a cheap electric skillet and be on your way to SMD heaven. Now these guys have really gone off the deep end.

Soldering Forum: Still not satisfied? Ask all your soldering-related questions on Curious Inventor’s forum.

Let me know if I’ve missed anybody!

Inspired by Armadillo Aerospace and their laptop-controlled Pixel rocket, I decided to figure out how to use an Arduino module to achieve wireless remote control of a flight vehicle.

Along the path to development, an achievable intermediate goal would be something like a wireless RC rover with a video camera, monitored and controlled with a laptop and joystick on a WiFi network.

Step one in the process is simple joystick control of a servo over a USB connection. This project builds upon the process documented in “Arduino Serial Servo Control.” I welcome any comments or suggestions for improving or adapting this code.

Hardware

The hardware setup is very simple, and is described in detail in the serial-servo article. The JR Sport ST47 standard servo is wired directly to Arduino’s 5V power and ground, and the servo’s control wire is connected to Digital pin #2. The Arduino module is connected to a PC (running Linux in our case) with a USB cable, and a standard USB joystick is also connected.

Software

The simple two-layer software stack includes a Python script for interpreting inputs from the joystick, and the Arduino sketch to await serial inputs from the Python script and pulse the servo.

Let’s start with the Python script. This code lives on the PC, and requires the pyserial and pygame modules to be installed, along with (obviously) Python’s standard library. The pygame module is primarily designed for graphics game creation, but it has a set of very straightforward methods for interpreting joysticks and other non-standard input devices. The pyserial module simply allows us to open a serial connection to the Arduino over a USB port.

The primary purpose of the Python script is to read and report on joystick inputs. A gaming joystick may have six different axes and a multitude of buttons. This script will sense inputs from each axis, and (if enabled) print the values of the stick positions.

Each joystick axis reports a range of decimal values between -1.0 and 1.0, with zero being the center position. This script converts those values (from the X-axis) into round numbers between zero and 180 and assigns that value as a servo position. Since the servo can travel through 180 degrees, each servo position value increments the servo horn by one degree, with the center at 90 degrees. The integers 0-180 are then converted to ASCII characters and sent over the serial connection to the Arduino.

#!/usr/bin/env python
#
# joystick-servo.py
#
# created 19 December 2007
# copyleft 2007 Brian D. Wendt
# http://principialabs.com/
#
# code adapted from:
# http://svn.lee.org/swarm/trunk/mothernode/python/multijoy.py
#
# NOTE: This script requires the following Python modules:
#  pyserial - http://pyserial.sourceforge.net/
#  pygame   - http://www.pygame.org/
# Win32 users may also need:
#  pywin32  - http://sourceforge.net/projects/pywin32/
#

import serial
import pygame

# allow multiple joysticks
joy = []

# Arduino USB port address (try "COM5" on Win32)
usbport = "/dev/ttyUSB0"

# define usb serial connection to Arduino
ser = serial.Serial(usbport, 9600)

# handle joystick event
def handleJoyEvent(e):
    if e.type == pygame.JOYAXISMOTION:
        axis = "unknown"
        if (e.dict['axis'] == 0):
            axis = "X"

        if (e.dict['axis'] == 1):
            axis = "Y"

        if (e.dict['axis'] == 2):
            axis = "Throttle"

        if (e.dict['axis'] == 3):
            axis = "Z"

        if (axis != "unknown"):
            str = "Axis: %s; Value: %f" % (axis, e.dict['value'])
            # uncomment to debug
            #output(str, e.dict['joy'])

            # Arduino joystick-servo hack
            if (axis == "X"):
                pos = e.dict['value']
                # convert joystick position to servo increment, 0-180
                move = round(pos * 90, 0)
                if (move < 0):
                    servo = int(90 - abs(move))
                else:
                    servo = int(move + 90)
                # convert position to ASCII character
                servoPosition = chr(servo)
                # and send to Arduino over serial connection
                ser.write(servoPosition)
                # uncomment to debug
                #print servo, servoPosition

    elif e.type == pygame.JOYBUTTONDOWN:
        str = "Button: %d" % (e.dict['button'])
        # uncomment to debug
        #output(str, e.dict['joy'])
        # Button 0 (trigger) to quit
        if (e.dict['button'] == 0):
            print "Bye!\n"
            ser.close()
            quit()
    else:
        pass

# print the joystick position
def output(line, stick):
    print "Joystick: %d; %s" % (stick, line)

# wait for joystick input
def joystickControl():
    while True:
        e = pygame.event.wait()
        if (e.type == pygame.JOYAXISMOTION or e.type == pygame.JOYBUTTONDOWN):
            handleJoyEvent(e)

# main method
def main():
    # initialize pygame
    pygame.joystick.init()
    pygame.display.init()
    if not pygame.joystick.get_count():
        print "\nPlease connect a joystick and run again.\n"
        quit()
    print "\n%d joystick(s) detected." % pygame.joystick.get_count()
    for i in range(pygame.joystick.get_count()):
        myjoy = pygame.joystick.Joystick(i)
        myjoy.init()
        joy.append(myjoy)
        print "Joystick %d: " % (i) + joy[i].get_name()
    print "Depress trigger (button 0) to quit.\n"

    # run joystick listener loop
    joystickControl()

# allow use as a module or standalone script
if __name__ == "__main__":
    main()

Now for the Arduino sketch. This code merely waits for serial input from the PC, does a little math on the decimal values of the transmitted ASCII characters, then pulses the servo to the corresponding position. If no new serial input is received from the PC (i.e., the joystick is not moved), then the Arduino will maintain the last known position of the servo horn with an identical pulsewidth every 20ms. As always, the minPulse and maxPulse values should be tweaked to work with your particular servo model.

/*
 * JoystickSerialServo
 * --------------
 * Servo control with a PC and Joystick
 *
 * Created 19 December 2007
 * copyleft 2007 Brian D. Wendt
 * http://principialabs.com/
 *
 * Adapted from code by Tom Igoe
 * http://itp.nyu.edu/physcomp/Labs/Servo
 */

/** Adjust these values for your servo and setup, if necessary **/
int servoPin     =  2;    // control pin for servo motor
int minPulse     =  600;  // minimum servo position
int maxPulse     =  2400; // maximum servo position
int refreshTime  =  20;   // time (ms) between pulses (50Hz)

/** The Arduino will calculate these values for you **/
int centerServo;         // center servo position
int pulseWidth;          // servo pulse width
int servoPosition;       // commanded servo position, 0-180 degrees
int pulseRange;          // max pulse - min pulse
long lastPulse   = 0;    // recorded time (ms) of the last pulse


void setup() {
  pinMode(servoPin, OUTPUT);  // Set servo pin as an output pin
  pulseRange  = maxPulse - minPulse;
  centerServo = maxPulse - ((pulseRange)/2);
  pulseWidth  = centerServo;   // Give the servo a starting point (or it floats)
  Serial.begin(9600);
}

void loop() {
  // wait for serial input
  if (Serial.available() > 0) {
    // read the incoming byte:
    servoPosition = Serial.read();

    // compute pulseWidth from servoPosition
    pulseWidth = minPulse + (servoPosition * (pulseRange/180));

    // stop servo pulse at min and max
    if (pulseWidth > maxPulse) { pulseWidth = maxPulse; }
    if (pulseWidth < minPulse) { pulseWidth = minPulse; }

    // debug
    //Serial.println(servoPosition);
  }

  // pulse the servo every 20 ms (refreshTime) with current pulseWidth
  // this will hold the servo's position if unchanged, or move it if changed
  if (millis() - lastPulse >= refreshTime) {
    digitalWrite(servoPin, HIGH);   // start the pulse
    delayMicroseconds(pulseWidth);  // pulse width
    digitalWrite(servoPin, LOW);    // stop the pulse
    lastPulse = millis();           // save the time of the last pulse
  }
}

This may not be the most elegant solution to the joystick servo control problem, but it does serve as a nice "Hello Servo" project, to let you see what's going on at the lower levels of input and output.

The next step in the process is to remove the USB cable to the Arduino, and control the servo by sending serial data over a WiFi or ZigBee network. Also, for a real remote robotics project, the code will need to be modified so that each joystick axis controls a separate servo, e.g. pitch, roll, yaw, and throttle. Stay tuned!

UGOBE is a small California robotics company that develops life-like animatronic creatures which they call “Life Forms.”

Their first creation is a cute, foot-long, green dinosaur-bot named Pleo. Pleo is an autonomous robot pet which incorporates a range of environment sensors, fluid mechanical movements, and a custom made “Life OS” AI operating system which allows all these elements to work together to simulate a living creature, reacting to and learning from its environment. Far out.

I really enjoyed these short videos, in which Caleb Chung, the toy-creation guru and UGOBE co-founder, gives a short tour of UGOBE Labs and talks about the development of Pleo. Looks like an awesome place to work!

Learn more about UGOBE at http://www.ugobe.com/.

One of the cool features of the Arduino platform is its ability to talk to other electronic devices using standard protocols. The big draw of physical computing, in my opinion, is the power it gives you to affect a limitless range of real-world objects with your PC, rather than just boring old monitors and printers.

This short tutorial will demonstrate one way to use Arduino to control a servo motor with a PC, using a USB cable and the Arduino’s serial library. It will in no way attempt to be an introduction to asynchronous serial communication, since such topics are better addressed elsewhere.

RC servos are comprised of a DC motor mechanically linked to a potentiometer. Pulse-width modulation (PWM) signals sent to the servo are translated into position commands by electronics inside the servo. When the servo is commanded to rotate, the DC motor is powered until the potentiometer reaches the value corresponding to the commanded position.

A standard RC servo has three wires: Ground (black or brown), Power (red) and Control (orange, yellow or white) and will move based on pulses sent over the control wire. The control pulses set the angle of the servo horn. The servo expects a pulse every 20 ms in order to gain correct information about the angle. The pulse width maps directly to the servo angle. Most servos will rotate 180°, and expect pulse widths between 1-2 ms or so.

Image credit: Society of Robots

This project uses a JR Sport ST47 Standard servo, which accepts an input voltage between 4.8 and 6 volts — perfect for the Arduino’s 5V output pin. Connect the servo’s brown and red wires to the Arduino’s Gnd and 5V POWER pins, respectively (colored orange in the diagram below), and connect the servo’s orange control wire to the Arduino’s digital pin #2 (on the green row in the diagram).

Image credit: Arduino.cc

Using the Arduino IDE, upload the following code to the board, which will allow you to control the position of the servo over a serial connection. Pay particular attention to the variables minPulse and maxPulse, as these define the min and max pulse widths for your servo. As mentioned earlier, most servos expect a pulse width between 1-2 ms, however, a range of 0.5 ms to 2.5 ms (500-2500μs) may be required, depending on your servo. Experiment as necessary.

/*
 * NewSerialServo
 * --------------
 * Servo control from the Serial port
 *
 * Alteration of the control interface to use < and > keys
 * to slew the servo horn left and right.  Works best with
 * the Linux/Mac terminal "screen" program.
 *
 * Created 10 December 2007
 * copyleft 2007 Brian D. Wendt
 * http://principialabs.com/
 *
 * Adapted from code by Tom Igoe
 * http://itp.nyu.edu/physcomp/Labs/Servo
 */

/** Adjust these values for your servo and setup, if necessary **/
int servoPin     =  2;    // control pin for servo motor
int minPulse     =  600;  // minimum servo position
int maxPulse     =  2400; // maximum servo position
int turnRate     =  100;  // servo turn rate increment (larger value, faster rate)
int refreshTime  =  20;   // time (ms) between pulses (50Hz)

/** The Arduino will calculate these values for you **/
int centerServo;         // center servo position
int pulseWidth;          // servo pulse width
int moveServo;           // raw user input
long lastPulse   = 0;    // recorded time (ms) of the last pulse


void setup() {
  pinMode(servoPin, OUTPUT);  // Set servo pin as an output pin
  centerServo = maxPulse - ((maxPulse - minPulse)/2);
  pulseWidth = centerServo;   // Give the servo a starting point (or it floats)
  Serial.begin(9600);
  Serial.println("      Arduino Serial Servo Control");
  Serial.println("Press < or > to move, spacebar to center");
  Serial.println();
}

void loop() {
  // wait for serial input
  if (Serial.available() > 0) {
    // read the incoming byte:
    moveServo = Serial.read();

    // ASCII '<' is 44, ASCII '>' is 46 (comma and period, really)
    if (moveServo == 44) { pulseWidth = pulseWidth - turnRate; }
    if (moveServo == 46) { pulseWidth = pulseWidth + turnRate; }
    if (moveServo == 32) { pulseWidth = centerServo; }

    // stop servo pulse at min and max
    if (pulseWidth > maxPulse) { pulseWidth = maxPulse; }
    if (pulseWidth < minPulse) { pulseWidth = minPulse; }

    // print pulseWidth back to the Serial Monitor (uncomment to debug)
    // Serial.print("Pulse Width: ");
    // Serial.print(pulseWidth);
    // Serial.println("us");   // microseconds
  }

  // pulse the servo every 20 ms (refreshTime) with current pulseWidth
  // this will hold the servo's position if unchanged, or move it if changed
  if (millis() - lastPulse >= refreshTime) {
    digitalWrite(servoPin, HIGH);   // start the pulse
    delayMicroseconds(pulseWidth);  // pulse width
    digitalWrite(servoPin, LOW);    // stop the pulse
    lastPulse = millis();           // save the time of the last pulse
  }
}

Once you’ve got the code uploaded, you’re ready to go! You can send and receive serial data using the Arudino IDE’s Serial Monitor, or you can use a Linux terminal (as in the video) with the screen command, like so:

screen /dev/ttyUSB0 9600

The first element of the screen command specifies the USB port, and the second the serial baud rate (9600). You may need to run ls /dev/tty* to find the correct USB port on your machine.

The theory behind this project can be extended to include a graphical user interface on the PC to control the servo motor, and maybe even the addition of an Ethernet connection for networked control.

Update: (10 Dec 2007) I wasn’t happy with the “Enter Servo Position (0-9):” interface shown in the video, so I revamped the code to allow left/right movements using the < and > keys. This new sketch is the one that is currently displayed here. Tod E. Kurt already has a good implementation of the 0-9 angular-position concept if you prefer it.

References

1. Wikipedia, “Servomechanism“
2. Society of Robots, “Actuators and Servos“
3. ITP Physical Computing, “Servo Lab“
4. ITP Physical Computing, “Serial Lab“
5. Tom Igoe, “Serial Communication“
6. Tom Igoe, “More on Serial Communication“

The digital pins on the Arduino board can be set (with code) to output either HIGH (5V) or LOW (0V) — essentially ON or OFF. This is great for applications like blinking LEDs or activating relays.

But what if we wanted an output voltage somewhere in between 0V and 5V? This might be useful in applications like controlling the speed of a DC motor, or “dimming” an LED.

Well, the digital pins cannot directly produce an analog voltage; as we’ve said, they’re either HIGH or LOW. But it turns out we can simulate these “in-between” voltages using a technique called Pulse Width Modulation, or PWM.

First off, don’t panic. PWM sounds complicated, but as we’ll see, the concept is very simple, and the implementation is even easier, especially on the Arduino.

Let’s say we want to make an LED shine with half of its normal intensity when supplied with 5 volts. Since we can’t use the Arduino’s digital pins to directly supply 2.5V, we’ll “pulse” the output pin on and off — really fast. You may have noticed this effect when you played with the Arduino’s “Blink” sketch. If you blink an LED fast enough — that is, if the delay between blinks is short enough — the LED will appear to be lit continuously, but just a little bit dimmer than it was originally.

It’s easy to visualize this concept using the graphs below. When you plot voltage over time, you can see that the pin is pulsing between HIGH and LOW at regular intervals. Since this on-off pulsing is happening so quickly, the connected LED will “see” the result as a 50% reduction in the normal voltage (in this example), and will glow at roughly half its normal intensity.

Image credit: Tom Igoe

We can vary the output voltage percentage (the “effective voltage”) by regulating — or “modulating” — the width of the pulse. For example, if we make the HIGH pulse 25% as “wide” (in time) as the LOW pulse, the LED will appear to glow with 25% intensity.

Image credit: Tom Igoe

“Okay, great,” you’re saying, “But how do I do this on the Arduino?” Well, there are a couple of ways. First, you could write a sketch that blinks the LED between HIGH and LOW really fast, as we discussed above. However, this approach requires the full attention of the Arduino all the time; that is, if you want the Arduino to do anything else, you’ll be interrupting the pulse loop.

Luckily, the Arduino designers have already solved this problem for us with three dedicated pins and the analogWrite() command.

Notice on the Arduino board there are three digital pins (9-11) which are labeled PWM. Devices (like LEDs) connected to these pins can employ continuous pulse width modulation using only the analogWrite() command like so:

/*
 * A simple PWM example
 */

int pin         =  11;     // LED connected to PWM pin 11
int pulsewidth  =  127;    // Any value between 0 and 255

void setup() {
  // None required for analogWrite!
}

void loop() {
  analogWrite(pin, pulsewidth);
}

The example above should cause the connected LED to glow at about 50% intensity (255/2 = 127ish). Play around with the value of the pulsewidth variable and note the changes in LED brightness.

Now, let’s take this concept one step further. What if we varied the effective voltage to the LED over time? If we could devise a way to “fade” the pulsewidth from zero to 255 and back again, then the LED would pulsate, as in the video above. Here’s the code for that, using three LEDs this time, connected to pins 9-11:

/*
 * Pulsating LEDs with Pulse Width Modulation
 */

int green   = 11;            // Digital pin 11 - Green LED
int red     = 10;            // Digital pin 10 - Red LED
int blue    = 9;             // Digital pin 9  - Blue LED
int time    = 5;             // define delay element
int pulsewidth;              // define pulsewidth (0-255)

void setup() {
  // None required for analogWrite!
}

void loop() {
  // slowly fade the LEDs to full brightness
  for (pulsewidth=0; pulsewidth <= 255; pulsewidth++){
    analogWrite(green, pulsewidth);
    analogWrite(red, pulsewidth);
    analogWrite(blue, pulsewidth);
    delay(time);
  }
  // slowly dim the LEDs
  for (pulsewidth=255; pulsewidth >= 0; pulsewidth--){
    analogWrite(green, pulsewidth);
    analogWrite(red, pulsewidth);
    analogWrite(blue, pulsewidth);
    delay(time);
  }
}

Cool, huh?

References

1. Tom Igoe, “Analog Output“
2. Sebastian Tomczak, “PWM and You: A Quick Primer“

This short tutorial will guide you through the installation of the Arduino development environment on Ubuntu. These instructions reference arduino-0010 and have been tested on Feisty and Gutsy, both 32-bit and 64-bit installations. Thanks to this post on the Ubuntu Forums for the basic setup.

(1) Install the necessary architecture-specific dependencies (the Java runtime and the AVR microcontroller tools):

sudo apt-get install sun-java5-bin sun-java5-jdk avr-libc gcc-avr librxtx-java

(2) Remove one conflicting package:

sudo apt-get remove brltty

(3) Configure Java to work with Arduino:

sudo update-alternatives --config java

You should see a dialog similar to this:

There are 5 alternatives which provide `java'.

  Selection    Alternative
-----------------------------------------------
          1    /usr/bin/gij-4.2
          2    /usr/lib/jvm/java-6-sun/jre/bin/java
 +        3    /usr/lib/j2se/1.4/bin/java
          4    /usr/lib/jvm/ia32-java-6-sun/jre/bin/java
*         5    /usr/lib/jvm/java-1.5.0-sun/jre/bin/java

Press enter to keep the default[*], or type selection number:

Locate the option containing “java-1.5.0-sun” and select it. This will make Sun’s Java v.1.5 the default on your system (the GNU version doesn’t support the Arduino environment).

(4) Download the latest release of the Arduino IDE software for Linux, and extract the compressed folder.

(5) Open the subdirectory arduino-0010/lib/ and rename the following files as shown (resolves conflicts with librxtx-java):

RXTXcomm.jar
librxtxSerial.so
  ---become---
RXTXcomm.jar.BAK
librxtxSerial.so.BAK

(6) Edit the arduino launcher file (arduino-0010/arduino) with a text editor and replace the contents with the following (resolves conflicts with librxtx-java):

#!/bin/sh

# Original: CLASSPATH=java/lib/rt.jar:lib:lib/build:lib/pde.jar:lib/core.jar:lib/antlr.jar:lib/oro.jar:lib/registry.jar:lib/mrj.jar:lib/RXTXcomm.jar
CLASSPATH=java/lib/rt.jar:lib:lib/build:lib/pde.jar:lib/core.jar:lib/antlr.jar:lib/oro.jar:lib/registry.jar:lib/mrj.jar:/usr/share/java/RXTXcomm.jar
export CLASSPATH

# put the directory where this file lives in the front of the path, because
# that directory also contains jikes, which we will need at runtime.
PATH=`pwd`/tools:${PATH}
export PATH

# put the directory with the native RXTX libs in the library path
# Original: LD_LIBRARY_PATH=`pwd`/lib:${LD_LIBRARY_PATH}
LD_LIBRARY_PATH=/usr/lib:${LD_LIBRARY_PATH}
export LD_LIBRARY_PATH

java processing.app.Base

(7) Launch the Arduino IDE by navigating to the arduino-0010 directory in a terminal and typing:

./arduino

(8) Learn! For more information about Arduino and learning electronics, see Ladyada’s (fabulous) Arduino Tutorial!

The design of the Wave Bubble comes from an MIT EE/CS masters thesis entitled “Social Defense Mechanisms: Tools for Reclaiming our Personal Space,” in which the author describes the tradition of designing and using electronic devices as social commentary, known as “Design Noir.”

In addition to providing a detailed description and circuit diagrams for builing the Wave Bubble, the thesis is also rife with intelligent commentary on the psycho-social implications of using electronic products and is quite an enjoyable read.

From the thesis:

Manufacture and use of Wave Bubble is not exempt from FCC regulations. Anyone who decides to build and use it is performing an act of civil disobedience.

I love it! More information and some great photos are available at ladyada.net.

The simplest model rocket launch controller is the Estes Electron Beam, which is powered by four AA batteries and comes with 17 feet of launch wire and micro clips for attaching an Estes igniter. This system is adequate for launching small models with a single black powder motor. However, for firing a cluster of motors, or for igniting composites, a battery with more amps is required. In addition, spectators of high-power launches will need to be farther away from the launch pad than 17 feet. Unfortunately, electrical resistance in a long launch wire negates some of the advantages of using a larger battery. This problem can be solved by using a relay switch located near the launch pad, allowing the main battery to sit as close to the motor igniters as possible, while the launch controller remains at a safe distance.

The LC-3 Electronic Relay

The LC-3 is the third iteration of Principia’s electronic Launch Control system. It is based on a similar design by Eric Ohmit, but differs primarily in that the controller is powered independently of the main battery. The full system (pictured below, left) consists of a Control Box, a Relay Box, a pair of connector cables to the battery and the igniters, clip whips for multiple igniters, and 100 feet of RJ-11 (telephone) cord to connect the control box with the relay. [Click any photo to enlarge.]

The Control Box (pictured above, right) incorporates a key-operated arm/safe switch, which ensures that only the designated range safety officer (RSO) can initiate a launch. In addition, the control box provides a green LED continuity indication, which tells the operator that the circuit is complete and that the battery and igniters have been properly connected. Continuity is confirmed by flipping the red “Continuity” switch to the ‘on’ position and noting the illumination of the green LED. The LC-3 is then armed with the key switch, which causes the red “Arm” LED to light, and a high-pitched piezo buzzer will sound, indicating to all spectators that the rocket is ready to fire. When both the green “Continuity” LED and the red “Arm” LED are illuminated, the red “Launch” button will become active and also illuminate, and the relay can then be engaged by depressing the button. If all goes well, the motor will light and the rocket will launch.

The Relay Box (pictured above, left) is the heart of the LC-3 system. On the front of the box is the RJ-11 port, which connects the relay to the Control Box via the 100′ telephone cable. The left end contains a removable (and therefore easily replaceable) 20A fuse, which protects the circuits from overload in the event that the igniter does not fire once the relay is activated. The top of the Relay Box has clearly-labeled banana jacks for connecting the cables to the 12V battery and the igniters.

A set of Clip Whips (pictured above, right) allows the LC-3 to be connected to up to four igniters simultaneously. Each pair of copper micro-alligator clips is color-coded for ease of use, and all four pairs return to one pair of conducting connectors, which are then clipped to the LC-3 igniter cable. Wire for the battery cables, igniter cables and clip whips is highly conductive copper “monster cable” speaker wire.

Building the LC-3

Designing and constructing your own launch control system is a fun and rewarding project that requires only a few inexpensive and readily-available parts, and will teach you a great deal about electronics and circuits. Natural follow-ons to this type of project include building microcontroller applications, printed circuit board design, and robotics.

The inside of the Relay Box (pictured above, left) may seem crowded, but has only four components. The first and most important is a simple 12V automotive electro-mechanical relay, which is fixed in the lower left corner of the metal enclosure with epoxy. (You can see the eight metal terminals sticking out of the top.) A relay is simply a switch which can be activated remotely by applying a voltage to it. (Note the wiring diagram for the relay tacked to the underside of the enclosure lid.) In our case, the Control Box sends 12V of current (provided by eight AA batteries) out to the relay, which causes the relay switch to close, completing the circuit between a big 12V motorcycle battery (which we have out at the launch pad) and the rocket motor igniters. The other three components in the Relay Box are (1) the piezo buzzer (black, circular, upper left); (2) the RJ-11 jack (off-white with four screw terminals, center), and; (3) the fuse holder (black, upper right). All components, including the relay, can be purchased at any Radio Shack for just a few bucks.

The inside of the Control Box (pictured above, right) is fairly clean in comparison (other than the abysmal soldering job), with the AA battery pack taking up most of the room. This photo provides a better view of the RJ-11 terminal, which has been epoxied to the side of the enclosure. The rectangular holes for the RJ-11 jacks were cut in both boxes by first drilling and then finishing with microsaws and files, available at any hobby shop. Note that the key switch had to be epoxied to the back of the faceplate to keep the housing from rotating when the key is turned. All components for a similar control box are available at Radio Shack, although more interesting switches, buttons and enclosures can be had online through vendors such as Digi-Key, Allied, and others.

Designing the Circuits

An electrical schematic for a relay controller similar to the LC-3 as well as tutorials for building basic and multipad launch controllers can be found in the INFOcentral section of Rocketry Online. [View a reference for reading circuit symbols and circuit diagrams.] Note on the schematic that the wires labeled 1-4, which travel between the Control Box and the Relay Box, are all contained in a single RJ-11 telephone cable, which has four separate wires/channels inside. The schematic only shows one 12V power source, while the LC-3 uses two separate sources, one inside the Control Box (the eight AAs), and one connected to the Relay Box (the motorcycle battery). It would be possible to use just the single big 12V, but this would require two extra channels in the 100′ launch wire, and may result in “relay buzz” when the Launch button is depressed. Relay buzz is caused by the relay switch opening and closing rapidly as the Launch button is held closed.

Bear in mind that the ohm values of the resistors are very important in this type of design, as it is the resistance in the circuit that keeps the igniter from firing before the relay is actuated. You’ll notice that there is a complete circuit from the big 12V, through the green continuity LEDs (in the relay box and the control box), through the 4.7k resistor, and out to the igniter, with the relay in its ‘open’ condition. This is how the continuity of the circuit is confirmed. When the relay closes, the current from the big 12V simply bypasses the two green LEDs and the resistor, and is sent unhindered to the igniters. Without sufficient resistance values, the igniter would fire as soon as it’s connected.

This design incorporates a safety test button in the relay box, a feature which ensures that the relay is actually open before you connect the igniter. The LC-3 does not have this safety button, but it is a good idea, since consistently creating an electrical short with a big motorcycle battery (which is what you’re doing when you send current to the igniter) is a great way to fuse a relay into the closed position. The 20A fuse in the LC-3 is designed to blow before this happens, but it’s nice to have confirmation before you connect the hot clips to a loaded composite rocket motor.

LC-3 Circuit Schematics

[UPDATE: 3/15/2008] For those who would like to build the LC-3 exactly as originally designed, I’ve posted the schematics and a nearly-complete parts list below. I’ve made my best effort to label the components on the schematics with the specific part numbers from the list below. Substitutions can be made, of course, but bear in mind the importance of resistor values — especially in the igniter continuity circuit. For simplicity’s sake, the Dialight 12V panel-mount LEDs I’ve included here have built-in current-limiting resistors. However, you should always use a multimeter to test actual Ohm values in the complete circuit before connecting it to an igniter. I’d strongly recommend reading the Estes Learning Guide for Model Rocket Launch Systems, and building a couple of test circuits before you go wiring up an LC-3 clone and connecting it to a live motor. Safety first, people! :)

Note: As published, there is one minor (or possibly major) difference between the LC-3 as pictured above and the schematics — there is no 90dB Piezo Pulse (Radio Shack 273-066) buzzer in the Relay Box (the Control Box still has one). If anyone’s interested, just leave a note below and I’ll explain how to incorporate this buzzer into the system. It’s a simple splice, but it involves changing an LED and resistor in the Control Box as well, to keep the same total resistance in the continuity circuit.

LC-3 Parts List

While most of the important parts for the LC-3 can be obtained at any Radio Shack, a few of the cool buttons, lights, and enclosures will have to be procured elsewhere. The best online resource for locating electronic parts is Octopart.com, which will find just about any obscure component you can think of, and provide a price list from several of the major online vendors. In the list below, all Radio Shack components have their part numbers included; to locate a part from their online store, simply Google “Radio Shack” and the part number. For all other components, I’ve included links to Octopart or the manufacturer’s data sheet.

For more information on this topic, see the Rocketry Online INFOcentral pages mentioned above, download the Estes Learning Guide for Model Rocket Launch Systems, and read G. Harry Stine’s Handbook of Model Rocketry, the definitive reference on the subject. Good luck!

Other Launch Controller Projects around the Web

1. UKRocketman’s 4-Channel Launch Controller for Hybrids/Liquids/Solids
2. Rocket Team Vatsaas Electronic Launch Controller
3. Kevin Cook’s “Awesome Model Rocket Launch Controller Project”
4. Time-Delayed Model-Rocket Launch Control
5. Matt Stum’s Relay Launch Controller
6. Eric Ohmit’s Launch Controller
7. How a Relay Launch Controller Works
8. Google Search: “electronic launch controller”

Initial Evaluation

Before beginning construction, we made a few ballpark calculations using (a free trial version of) RockSim, a Windows-based model rocket design tool, to verify that the addition of the camera wouldn’t adversely affect the model’s flight characteristics. To increase performance, we also swapped the specified D12 engine for a higher-impulse E9.

The images below show the results of this evaluation. You can see from the flight profile graph on the left that the predicted maximum altitude with the E9 motor is nearly 1000 feet. The stability diagram on the right shows the center of gravity (CG) position with the E9 engine, but without the addition of the video camera in the nose.

Although the CG was a little further aft than is desirable, we determined that the addition of the video camera and battery pack to the nose of the rocket would only improve stability, and that the E9 motor would help compensate for the loss of performance that the camera’s weight would create. Based on this preliminary analysis, we decided to go ahead with rocket construction, using an Estes E9-8 engine, the video PCB and a 2AAA battery pack.

Now that the build is complete and the camera is installed, we need to revisit these calculations with the actual mass measurements, to assure that we have an accurate picture of the flight profile before the first test flight.

Rocket Stability

Like the feathers of an arrow, the fins of a model rocket keep it flying straight and true. Air moving over the fins creates a lift force which helps to straighten out the rocket’s flight path when small perturbations like wind gusts or engine thrust asymmetry attempt to push it off course. The position of two imaginary points on the rocket body, the Center of Gravity (CG) and the Center of Pressure (CP), determine how stable the rocket flight will be.

As with any flight vehicle, forces on a rocket will cause it to pivot about its CG. The CG of the rocket is best determined when the model is prepped and ready to fly: that is, after the engine, recovery system and heat-resistant wadding are installed.

In the preliminary analysis, we used RockSim to estimate the CG position on the rocket’s fuselage based on the average masses of engines, parachutes, and modeling clay (in the nosecone, to move the CG forward). Now that the actual build is complete, we can determine the true flight CG by prepping the rocket for flight as described above, and balancing it.

Using this method, we determined that the CG of our model is 286mm from the aft end of the tailcone. This includes the installed E9-8 engine, the parachute and wadding, the video camera and 2AAA battery pack, along with some modeling clay in the very tip of the nosecone. The clay is necessary because the Canadian Arrow kit is undesirably tail-heavy by design.

Now, for a stable rocket flight, the CG needs to be at least one caliber (the diameter of the fuselage) forward of the CP. We know that the CG position can change depending on how we load the rocket (i.e., where we put the weight). The Center of Pressure, however, is dependent only on the design of the rocket. The rocket’s length and the shape, size and position of the fins determine the location of the CP. The CP can be determined longhand using the Barrowman Equations, or automagically by using a program like RockSim or SpaceCAD.

Since we didn’t alter the design of the rocket aerodynamically, the CP we found using RockSim in our preliminary analysis will still be correct. In our case, the CP is 208mm from the aft end of the tailcone. The fuselage diameter is 66mm, and the difference between CP and CG is 78mm — about 1.18 calibers stability. This isn’t ideal, but it is better than the marginal 0.95 that we came up with originally.

With these calculations we can be reasonably assured that our rocket won’t go spiralling off into oblivion on its first flight.

For more detailed information on this topic, consult the Rocket Stability page from NASA’s “Beginner’s Guide to Rockets.”

Rocket Performance

The performance of our rocket — acceleration, velocity, altitude — depends on the vehicle’s weight, aerodynamic drag, and the engine’s thrust and burn time. Because the biggest engine Estes makes is the E9, we figured we’d throw that sucker in and be good to go. The preliminary analysis showed no problems. But during the course of the build, our rocket got a little … uh … heavy.

The Estes Engine Chart (PDF 20K) recommends 283 grams as the maximum total liftoff weight for a model rocket using the E9-8 engine. Well, our little prima donna weighed in this afternoon at a hefty 363 grams. My first concern was that this fatty wouldn’t even get off the pad with an E9, but that turned out not to be the case.

The same chart lists maximum liftoff weights for the E9-6 and E9-4 at 340g and 425g respectively. All three E-impulse engines have the same propellant weight, the same total impulse, the same max thrust, and the same thrust duration. So why the difference in max recommended liftoff mass?

The answer, of course, is the ejection delay. Heavier rocket, shorter ejection delay. Why? Well, since the thrust curve of all three engines are identical, the boost phase for a given rocket riding all three engines should be identical. But it’s all about the coast phase. The time from engine burnout to apogee is (obviously) less for a heavier rocket than for a lighter one. So, my theory was that with the long-delay engines — the E9-8 and E9-6 — the ejection charge would occur way after apogee, with the vehicle velocity steadily increasing as it plummeted back to earth.

I needed to run some simulations.

Since it had been more than 30 days since I first downloaded RockSim, the trial period had expired and I was locked out of the software. Damn! But, not to worry, there is always Markworld!

Mark Sullivan has created a simple and effective HTML rocket altitude predictor that can be used for performance calculations. Just fill in some data fields about your rocket and engine type, and voila!

I ran three simulations, one for each E-impulse engine type, to determine max altitude, velocity and the point of parachute deployment. The results are as follows:

Estes E9-4

The E9-4 graph is characteristic of the perfect model rocket flight: a quick boost to apogee, velocity goes to zero, and the recovery system is deployed shortly afterward. (The three dots on the blue altitude curve mark engine burnout, apogee and ejection.) Maximum altitude is significantly lower than originally predicted — 136 meters (448 ft) — due to the increased mass of the finished rocket. The airframe glides at a constant velocity under the canopy to a soft touchdown rougly 29 seconds after liftoff at a gentle 6.2 m/s. Chute deployment occurs at a velocity of 3.15 m/s, creating a shock on the airframe of 1 g. Nice flight.

Estes E9-6

Notice that the boost profile and max altitude of the E9-6 are identical to that of the E9-4, since the thrust profile is the same. What differs is the time and velocity of the chute deployment. In this case, ejection occurs at 21.04 m/s, creating a shock of 10.38 g. That’s a big difference, and we’re endangering our rocket by creating unnecessary stress on the shock cord and recovery system.

Estes E9-8

We’ve got three of these engines sitting in the package and ready to fire. They’ll boost the rocket to apogee just as well as the other two E-impulse, but recovery stress borders on unacceptable. Descent velocity climbs to a whopping 33.25 m/s, creating a shock of 27.50 g! We might try these engines just for fun, but it’s clear that there is a significant danger of losing the vehicle.

So, we know now that our rocket is safe and ready to fly, and that the E-impulse engines should be sufficient to huck this hefty beast off the launchpad. But our choice of an 8-second ejection delay is unacceptable for the first flight test. We’ll pick up a pack of E9-4s before we head out to the range.

For more detailed information on model rocket performance, visit NASA’s Rocket Engine Performance page.

Next: Launch Day Videos