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.

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!

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“

The 1967 book How to Design, Build and Test Small Liquid-Fuel Rocket Engines can be read online, or you can download the entire file in zip format.

From the introduction:

The purpose of this publication is to provide the serious amateur builder with design information, fabrication procedures, test equipment requirements, and safe operating procedures for small liquid-fuel rocket engines.

Also, don’t forget the bible:

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”

An examination of the video and debris is currently underway, but the consensus is that the extreme cold (-15°C) caused the propellant grain to separate from the interior wall of the rocket motor case.

When the motor was ignited, the rising pressure in the combustion chamber forced the unburned portion of the propellant violently up and out of the case, destroying the engine mount and tailcone. The propellant grain was then ejected out the top of the airframe, cracking the base of the nosecone, and continued to sail roughly twenty meters into the air. All of this happened in an instant.

For more information on Estes engine design and catastrophic failure, see “How CATOs Happen.”

CATO Videos

Camera 3: Wide angle, handheld

Camera 2: Wide angle, fixed

Camera 1: Launchpad closeup, fixed (frame-by-frame)

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

It’s hard to believe how rewarding it can be making something this pointless! This is my version of “Hello World” on the Arduino. Instead of just flashing an LED on and off, this variation flashes a three-letter Morse code navaid identifier (something familiar to aviators).

The Arduino is a wonderful new open-source physical computing platform and programming environment. It is based on the Atmel ATmega8 microcontroller, and is cheap and easy to learn. Microcontrollers can be used in everything from automation and robotics to interactive art projects. Get the skinny at http://arduino.cc/.

Here’s a (silent) video of the Morse LED flasher. See if you can guess the identifier! (Try not to fall asleep watching the blinkety-blinks.)

The code (abridged):

/* LED morse code blink
 * ------------
 *
 * Blinks an LED connected to a digital pin.
 * Pin 13 on the Arduino board is used because
 * it has a resistor attached to it, needing only an LED
 *
 */

  int ledPin = 13;  // digital pin 13

  void setup()
  {
  pinMode(ledPin, OUTPUT);  // sets pin 13 as output
  }

  void loop()
  {
  // V
  digitalWrite(ledPin, HIGH); // dot
  delay(200);
  digitalWrite(ledPin, LOW);
  delay(100);

  digitalWrite(ledPin, HIGH); // dot
  delay(200);
  digitalWrite(ledPin, LOW);
  delay(100);

  digitalWrite(ledPin, HIGH); // dot
  delay(200);
  digitalWrite(ledPin, LOW);
  delay(100);

  digitalWrite(ledPin, HIGH); // dash
  delay(600);
  digitalWrite(ledPin, LOW);
  delay(800);

  // ...

  // you get the picture!

  delay(3000);  // wait 3sec before repeat

  }

The CVS “Single-Use” Camcorder

The Pure Digital One-Time Use Video Camcorder is marketed by CVS and Rite-Aid pharmacies as an inexpensive and user-friendly device for capturing family memories, vacation outings and the like. With only three buttons, it is simple enough for anyone to use. A 1.5-inch color LCD serves as a viewfinder, and allows you to watch a playback of the most recent clip. The camera’s firmware and data are stored on a Samsung 128MB non-volatile flash memory chip which holds roughly 20 minutes of digital video.

The palm-sized camera costs less than thirty bucks, but there’s a catch. When your 20 minutes are up, you take the camera back to CVS, where they charge you a $13 processing fee to download the video data and burn it onto a DVD for you. The camera’s memory is then cleared, but you don’t get to keep it; it gets sent back to the manufacturer for repackaging and resale. Well, with a little tinkering and some steady-handed soldering, we’ll make our own camera interface, turning this product into a compact, reliable and — best of all — reusable digital video platform.

Camera Hacking 101

Peeling off the sticker on the top end of the camera reveals its secret: a proprietary, card-edge connector that only fits the plug behind the counter at CVS. Luckily, it uses standard USB protocol to communicate, so interfacing with the camera is simply a matter of soldering a cable onto the correct contacts on the circuit board.

To disassemble the camcorder, first remove the battery cover from the rear of the case, then unlock the gray battery holder inside and remove it. Unpeeling the four corners of the sticker on the back of the case reveals four tiny Phillips-head screws. Remove them and snap off the back of the case to expose the printed circuit board (PCB).

Looking at the PCB, you’ll notice two more tiny black Phillips-head screws near the lower left and right edges of the board. Remove these to release the PCB from its standoff mounts. There is a small, four-pin connector on the lower left (underside) corner of the PCB that connects the circuit board to the batteries. Pull the board straight up from this corner, and it will come free of the case.

Now the tricky part: We’ll solder a USB cable to the PCB’s card-edge contacts so we can connect the camcorder to a PC.

Rigging the USB Interface

Find yourself an old USB cable (maybe from an unused USB mouse or other device you won’t miss) and snip off the far end of the cord. Strip the insulation to reveal four smaller wires (and possibly some metal mesh RF shielding), colored red, black, green and white.

If you can get your hands on a decent soldering iron with a fine-pointed tip, the following procedure will be much easier. The contacts on the PCB are very close together, and any solder that accidentally flows between contacts will foul the connection — or worse. You can see from the photos that an iron that’s too large (as mine was) can quickly make a mess of the job. Also, using needle-nose pliers or (preferably) a small hemostat to hold the wires to the PCB while soldering will make things go much more smoothly.

Notice that there are ten gold contacts on the PCB’s edge connector. With the connector facing you and the camera lens pointing at you, label the connectors 1-10 from left to right. Now, solder the wires to the circuit board’s edge connector in this order: red, black, green and white, to contacts 6 through 9 respectively. (If the computer indicates a problem later, try swapping the green and white wires.) Take your time.

Connecting the Camcorder to a PC

The forums at CameraHacking.com are the primary resource for the most current information on hacking the Pure Digital cameras. These bright folks have legally reverse-engineered the hardware and software in both still and video camera models, allowing them to be reused for a variety of applications. [For more detailed information on how all this was done, visit John Maushammer's website.]

As you might imagine, Pure Digital updates the firmware and security software in each new model of camera, and your workaround solution may vary slightly from this description, depending on your camera’s model number and firmware version. The following applies to Model 220, firmware version 33.04.

The camera’s model number can be found on the FCC sticker on the bottom of the camera case exterior. To discover your firmware version, re-connect the camcorder PCB to the battery pack and verify that the camera is turned off. Hold down the “Record” and “Delete” buttons, then press the power button to turn the camera on. This should bring up the camera’s Configuration Screen which looks something like:

FW-VERSION: 33.04
CAMERA ID: GD5060******
PCB VER: B1

If you haven’t already, shoot a few minutes of test footage. Make sure everything still works, and that you can save and play back a short video clip on the camera. Now plug the camera into your PC’s USB port. Windows should recognize the camera as a “Saturn”, and ask to install a driver. This message indicates that you have connected the USB wires correctly. Click “Cancel”, since you have no driver yet. (See CameraHacking.com for MacOS and Linux support.)

To convince Windows to interface with Saturn, we’ll need to download a hardware driver (just like any other device) and we’ll need Ops. You can scour CameraHacking.com to find these items, or you can simply use Ryan David’s One-Click Setup. This will install the most current driver and the Ops client automatically. Be sure and get the latest version from the download page.

Once all the software and drivers are installed, we’ll connect the camera to the PC with the USB cable and fire up the Ops client. Complete instructions for using Ops are available in the FAQ section of CameraHacking.com, but the basic procdeure is: Open Camera -> Unlock -> Download All Movies -> Close Camcorder. That’s it! [If you have problems unlocking your camera, you may want to check out this site.]

Playing the Videos

Videos from the Saturn camera are saved as .AVI files and are encoded using the open-source XviD codec, which, like DivX, is an imlementation of the MPEG-4 standard. In order to play these clips on a Windows PC, we’ll need to download this codec. Once we’ve installed the XviD codec, we will be able to play XviD videos using Windows Media Player or any other XviD-enabled player.

Building the Rocket

The model rocket we’ll use to fly the camcorder is the Estes X-Prize Canadian Arrow. The design is essentially a stretched version of the classic WWII German V-2 rocket, but our main concern is to find a kit with a nosecone diameter large enough to accommodate the video PCB. The Estes Fat Boy kit, while quite a bit shorter, would also serve our purposes. Since we are going to modify the kit slightly from it’s original configuration, we’ll use Rocksim design and simulation software to ensure our modifications won’t affect the flight characteristics of the rocket.

Next: Rocket Stability and Performance