What you need is SSH, the Secure Shell. SSH is a powerful tool which allows secure remote login over insecure networks. It provides an encrypted terminal session with strong authentication of both the server and client using public-key cryptography. This tutorial will cover the basics of SSH’s most useful features:

• Logging into a remote computer over a secure connection.
• Transferring files and directories between computers over a secure connection.
• Enabling public-key authentication.
• Passwordless authentication for use with scripts and cron jobs.

The following assumptions are made about the reader:

• You know what a terminal/command line/shell is and how to start a session.
• You have at least a basic familiarity with Linux/Mac command-line syntax.
• You’re on a private LAN with access to at least two Linux/Mac computers (or, you have a user account on a remote server that accepts SSH connections).

As always, comments, corrections, and suggestions for improvement are appreciated.

Installing OpenSSH

The Ubuntu (and MacOS X) flavor of SSH is called OpenSSH, a free, open-source implementation of the ssh protocol. It consists of two basic components, an openssh-client and an openssh-server. SSH clients communicate with SSH servers over encrypted network connections.

The openssh-client software should already be installed by default on Ubuntu. If you want to be able to accept SSH connections as well as request them, you’ll need the server software as well. The easiest way to ensure you have both is simply to run:

sudo apt-get install openssh-client openssh-server

Using SSH to Log into a Remote Computer

Once OpenSSH is installed, you can login to a remote SSH server by using the ssh command:

ssh remoteuser@remotebox

where remoteuser is the username of the remote account you’re trying to access, and remotebox is the remote server’s hostname or IP address.

For example, if you know that your Kubuntu desktop box (now running openssh-server) has a user account named joebanks and that the IP address of that computer on your private LAN is 192.168.0.12, you could login remotely to that account from your Linux/Mac laptop by typing:

ssh joebanks@192.168.0.12

Or, if you’ve got a web hosting account that allows shell access (e.g., DreamHost) with a domain name like cooldomain.com, your syntax might look like:

ssh joebanks@cooldomain.com

Now, the first time an SSH client encounters a new remote server, it will report that it’s never seen the machine before, by printing the following message:

The authenticity of host 'remotebox (192.168.0.12)' can't be established.
RSA key fingerprint is 53:b4:ad:c8:51:17:99:4b:c9:08:ac:c1:b6:05:71:9b.
Are you sure you want to continue connecting (yes/no)?

This is just an extra security measure to ensure that you’re actually connecting to the machine you think you are. If you type yes (the most common response), you’ll see the following:

Warning: Permanently added 'remotebox' (RSA) to the list of known hosts.

Subsequent login attempts to this machine will omit the warning message. You’ll then be asked for the remoteuser’s password:

remoteuser@remotebox's password:

And after correctly entering it, like magic, you’ll be logged into the remote machine, and instead of your local machine’s command prompt, you’ll see the following:

remoteuser@remotebox:~$

And, voila! You can execute commands on the remote machine just as you would on your local box. To close the connection to the remote server, type exit, or use Ctrl-D.

Copying Files

To transfer files and directories from your local machine to the remote server and vice-versa, you’ll use SSH’s “secure copy” command, or scp. To copy a single file from your local machine to the server, use the following syntax:

scp file.txt remoteuser@remotebox:/directory

where file.txt is the name of a file in the current directory of your local machine, remoteuser@remotebox is the username and hostname or IP address of the server (just like in the above ssh examples, and /directory is the directory path on the server where you want your file copied.

For example, if you want to copy the local file.txt to the /home/joebanks/docs directory on the server you logged into above, you’ll run the following command from a local terminal session:

scp file.txt joebanks@192.168.0.12:/home/joebanks/docs

You can be as verbose as you want with the local and remote filenames and directories, even changing the filename in the process, like so:

scp ~/docs/oldfile.txt joebanks@192.168.0.12:/home/joebanks/docs/newfile.txt

To copy a file from the server to your local machine, use the following syntax:

scp remoteuser@remotebox:file.txt /local/directory

where remoteuser@remotebox is the username and hostname or IP address of the server, file.txt is a file in the /home/remoteuser directory, and /local/directory is the local directory path into which the file will be copied.

Again, you can be as verbose as necessary, for example:

scp joebanks@192.168.0.12:~/docs/newfile.txt /home/joe/downloads

Copying Directories

To copy an entire directory (and all of its contents) from the local machine to the remote server, use the recursive -r switch, like so:

scp -r /local/directory remoteuser@remotebox:/remote/directory

where /local/directory is the path to the local directory you want copied, and /remote/directory is the remote directory into which you want the directory to be copied.

To copy an entire directory (and all of its contents) from the remote server to the local machine, use the following:

scp -r remoteuser@remotebox:/remote/directory /local/directory

where /remote/directory is the path to the remote directory you want copied, and /local/directory is the local directory into which you want the directory to be copied.

Stop Typing the Stupid IP Address All Day, Will You?

By now you’re no doubt getting sick of typing joebanks@192.168.0.12 or whatever. It sure would be nice to type something shorter. Let’s fix that.

OpenSSH uses a client configuration file, located at ~/.ssh/config, to simplify some of the tedious typing associated with logging into remote machines. To edit (or create) that file, we’ll use the nano text editor, but you can use vi, emacs, kate or whatever:

nano ~/.ssh/config

The simplest configuration file might look something like this:

Host volcano
  HostName 192.168.0.12

This associates the Host volcano with the HostName (or IP address) 192.168.0.12, so now to login you’ll only need to type:

ssh joebanks@volcano

That’s cool, but let’s get a little more lazy, shall we? How about this:

Host BigWoo
  HostName 192.168.0.12
  User joebanks

Now all we need to type is:

ssh BigWoo

Far out! You can add as much configuration data as you need to this Host, and as many different Hosts as you like. And this shorthand will also work with all the scp examples:

scp file.txt BigWoo:

To learn more visit the OpenSSH docs, or run man ssh_config.

Public-Key Authentication

To increase the security of your SSH session, or to set up passwordless authentication, you can enable SSH’s built-in public-key cryptography. Then, instead of entering the remoteuser’s password on each login attempt, SSH will initiate a challenge-and-response protocol which attempts to match an encrypted public key (stored on the server) with a protected private key (stored on the local machine). This completely eliminates the need to send sensitive information (like a password) over the network, encrypted or not.

To generate a public/private key pair on your local machine, open a terminal and type:

ssh-keygen -t dsa

You’ll see the following message:

Generating public/private dsa key pair.
Enter file in which to save the key (~/.ssh/id_dsa):

Hit Enter. This selects the default location. Next you’ll see:

Enter passphrase (empty for no passphrase):

Enter a secure passphrase, ideally something unique and unguessable. Unlike a password, a passphrase is usually a phrase or complete sentence, with spaces and punctuation if you like. The longer and more obscure the phrase, the stronger it is.

After typing a passphrase and hitting Enter, you’ll see:

Enter same passphrase again:

Enter the same passphrase again. And finally:

Your identification has been saved in ~/.ssh/id_dsa.
Your public key has been saved in ~/.ssh/id_dsa.pub.
The key fingerprint is:
42:ac:8a:81:31:81:e5:7b:d2:01:42:2d:64:32:0f:dd localuser@localbox

Now copy your public key, which is stored in the local file ~/.ssh/id_dsa.pub to the remote machine, by running the following command from a local terminal session:

ssh-copy-id -i ~/.ssh/id_dsa.pub remoteuser@remotebox

You’ll be prompted for the remoteuser’s password one last time, and then you’ll see the message:

Now try logging into the machine, with "ssh 'remoteuser@remotebox'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Once the ~/.ssh/authorized_keys file on the remote machine contains your public key, you’ll be prompted for your passphrase at each login attempt, rather than the remoteuser’s system password, like so:

Enter passphrase for key '~/.ssh/id_dsa':

Finally, it’s a good idea to change the permissions of the ~/.ssh directory and the ~/.ssh/id_dsa file on your local machine, to disable any outside access to your private key.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_dsa

Passwordless Authentication for Automated Tasks

You can use ssh and scp in shell scripts and cron jobs to automate repetitive tasks, such as remote backups of critical files. To do so, however, you’ll need to implement some sort of passwordless authentication scheme, so that scripts can run without human intervention.

Two methods are presented below, the first is the easiest to implement (and possibly the most prevalent), while the second is the most secure.

Method 1: Sans Passphrase

If you want your scripts to have access to the ssh command without requiring a password or passphrase, simply go through the steps outlined above for enabling public-key authentication, but instead of entering a passphrase when prompted, simply press Enter.

The ssh-keygen program will generate a public/private key pair for you that will allow password- and passphrase-less access to any remote server which has your public key stored in its authorized_keys file.

Is this secure? Well, no. And yes. It’s probably more secure than typing in the remoteuser’s password and sending it over the network. Sure it’s encrypted, but it could still be intercepted.

Public-key authentication sends no password or passphrase data over the network. The “challenge” sent by the server is encrypted with your public key, and can only be decrypted with your private key, which only you have.

However, as mentioned above, if someone gains access to your local computer, they’ll also have access to every remote server with your public key.

So, you’ll need to decide the level of security required. In my opinion, if you’re only communicating with machines on a private LAN, under your control, behind a router’s firewall, then this method is adequate. Others may disagree.

Method 2: Using ssh-agent and keychain

The “proper” and secure way to achieve passwordless authentication is by using the ssh-agent and keychain daemons to store your passphrase between terminal sessions, so you don’t need to type it every time.

Setup of this method is beyond the scope of this article, but the following tutorials will walk you through the entire process, as well as the theory behind it:

• OpenSSH key management, Part 1
• OpenSSH key management, Part 2

Go Forth and SSHify!

I hope this tutorial serves as a gentle introduction to the Secure Shell. For further reading and advanced topics, check out the references listed below, and browse the OpenSSH Documentation. Thanks for reading.

References

1. SSH Tutorial for Linux
2. SSH: Ubuntu Community Documentation
3. Secure Communications with OpenSSH
4. Getting Started with SSH
5. Indiana University Knowledge Base: SCP
6. Example Syntax for Secure Copy
7. Bash Reference Manual

Although the Arduino platform is ideal for standalone applications, it really comes to life when interfaced with a PC. Connect Arduino to a personal computer and you instantly add a ton of versatility and processing power to your project.

This tutorial will describe how to use Arduino to control a bank of four independent RC servos with your PC (or Mac, or *nix Box), using a USB cable and a modular Arduino-Python software stack.

The following discussion builds upon concepts presented in two previous articles, “Arduino Serial Servo Control” and “Joystick Control of a Servo.” As always, comments, critiques, or suggestions for improving or adapting this code are welcome and appreciated.

Project Outline

The primary goal for this project was to create a software stack that allows simple and flexible control of multiple servos from any type of Python script.

The solution has two basic components: (1) an Arduino sketch that waits for serial input from a connected PC, then moves each servo to its commanded position, and; (2) a Python module on the PC that opens the serial connection and formats the data packets expected by the Arduino.

Any other Python program written to sit on top of these two layers need not worry about the messy details of serial communication, but rather can just say something like, “Move servo #2 to 90 degrees.” Or, more precisely:

servo.move(2,90)

Easy, right? Let’s get started.

Part I: Smoke, Mirrors, and Hand-Waving

If you just want to get things up and running quickly, start here. These instructions will get your servos connected and obeying every whim of your PC in no time.

Hardware Setup

Hardware for this project consists of an Arduino module, four JR Sport ST47 standard servos, and a breadboard to create the circuit.

The servos each have three wires: Ground (brown), Power (red) and Control (yellow). Each of the Control wires will connect to a different digital pin on the Arduino board (pins 2 through 5 in our setup), and all of the Power and Ground wires will need to connect somehow to the 5V and Gnd pins.

The simplest way to accomplish this is to create a “bus” bar along one of the breadboard’s edges, as shown in the photo above. Simply route the Arduino’s 5V and Gnd to a convenient area on the breadboard, and connect all the servos.

Required Software: The Lower Layers

To get the effects seen in the video above, you’ll need at least the following two programs. Although this code is designed to control four servos, it also works as-is with fewer servos, and — with a few modifications — as many as twelve (or 48 with the Arduino Mega!).

Download the code:

Customize the code:

Depending on your computer system and Arduino hardware setup, you may need to make a few modifications to the code.

Arduino: In the “MultipleSerialServoContro” sketch, take note of the following variables and make adjustments as necessary for your setup. See “Arduino Serial Servo Control” for more details regarding the minPulse and maxPulse variables. (If you’ve got standard RC servos attached to pins 2-5, you probably won’t have to change anything.)

// Common servo setup values
int minPulse = 600;   // minimum servo position, us (microseconds)
int maxPulse = 2400;  // maximum servo position, us

// Attach each Servo object to a digital pin
servo1.attach(2, minPulse, maxPulse);
servo2.attach(3, minPulse, maxPulse);
servo3.attach(4, minPulse, maxPulse);
servo4.attach(5, minPulse, maxPulse);

Python: In the “servo.py” script, you’ll most likely need to change the value of the usbport variable, which tells Python how to find your Arduino (On Windows, it’ll be something like ‘COM5′. On a Mac, ‘/dev/tty.usbserial-xxxxx’. On Linux, ‘/dev/ttyUSB0′.). Try running ls /dev/tty* from a Mac or Linux terminal for a list of available ports. [ToDo: Modify the script to make this step unnecessary.]

Test the code:

Once your hardware is set up and the software is installed, you can test the system’s basic functionality from the Python interactive interpreter, like so:

~/path/to/servo.py$ python
>>> import servo
>>> servo.move(2,150)

The servo.move() method takes two arguments, both integers. The first is the servo number you wish to move, 1-4 (or whatever). The second is the commanded angular position of the servo horn, from 0-180 degrees. So, if you want to move Servo #3 fully clockwise (180 degrees), you’ll type servo.move(3,180). Cake, baby!

Optional Software: From Totally Geek to Totally Chic

The following scripts are designed to leverage the functionality of the servo.move() method for simple and readable code. Make sure these files reside in the same directory as “servo.py”.

• servodance.py: A cascading effect that feels like watching a quarter spiral down one of those funnel-shaped wishing wells.


• servorandom.py: The final servo sequence seen in the video, with individual servos moving to random positions and then waving “goodbye” in unison.


• servomarch.py: This one’s not in the video, but it’s a fun script to test individual and simultaneous movement of multiple servos. Just set the number of servos to march (default is 4), and send them off!


• multijoystick.py: Allows joystick control of four servos, with each joystick axis controlling a single servo. This script is the most complex, so try getting the first three working, then graduate to this one — it’s easier to troubleshoot problems that way.
  [Note: This script also requires installation of the pygame module.]

With any luck, you should now have everything up and running just like in the video!

NEW: Adding Servos

[Updated 12/23/09] If you’re using the new Arduino sketch, you can easily add servos to your project by making a few simple additions to the code. The beauty of this system is that servo.py can remain unchanged, and all of the higher-level Python scripts just need simple alterations to include whatever number of servos you decide to add. This segment will outline how to change the Arduino sketch; changes to the Python scripts will be up to you!

There are three places in the MultipleSerialServoControl sketch where you’ll need to make additions, if you want to control more than four servos. Each section of the code contains the comment “TO ADD SERVOS:” followed by a suggestion on what to add.

First, add a Servo object for each additional servo:

// Create a Servo object for each servo
Servo servo1;
Servo servo2;
Servo servo3;
Servo servo4;
// TO ADD SERVOS:
//   Servo servo5;
//   etc...

Second, assign a digital pin to each additional servo:

  // Attach each Servo object to a digital pin
  servo1.attach(2, minPulse, maxPulse);
  servo2.attach(3, minPulse, maxPulse);
  servo3.attach(4, minPulse, maxPulse);
  servo4.attach(5, minPulse, maxPulse);
  // TO ADD SERVOS:
  //   servo5.attach(YOUR_PIN, minPulse, maxPulse);
  //   etc...

Third, create a new switch case for each additional servo:

      // Assign new position to appropriate servo
      switch (servo) {
        case 1:
          servo1.write(pos);    // move servo1 to 'pos'
          break;
        case 2:
          servo2.write(pos);
          break;
        case 3:
          servo3.write(pos);
          break;
        case 4:
          servo4.write(pos);
          break;
   // TO ADD SERVOS:
   //     case 5:
   //       servo5.write(pos);
   //       break;
   // etc...
      }

After making changes, be sure to click the “Verify” button on your Arduino software to make sure there are no errors, then upload it to the board. Test your changes by calling the servo.move() method from the Python interpreter. That’s it!

Part II: Getting Down to Brass Tacks

Next, let’s take a look under the hood to see how it all works. If you’re the type that just wants to get things working and damn the details, STOP HERE. Otherwise, continue on, and I’ll do my best to explain how the code “do what it do.”

The Problem Set

Asynchronous serial communication is not perfect. Sometimes there are errors, dropped packets, confusion. Sometimes the mail does not get through. In both of the previous two serial/servo projects, the Arduino expected only one byte from the PC, and in both cases that byte represented a commanded servo position — and nothing more. If a byte was missed or skipped, it wasn’t a big deal, another one was sure to come along, and it was impossible to misinterpret.

This project presents a couple of new challenges. First, we are controlling more than one servo, so the Arduino needs more than one command element for each move. As we’ve seen above, it needs to know (at least) which servo to move, and how much to move it. Secondly, we have the problem of communication. This time, we’re sending two command elements for each move (servo number & position), and these elements are clearly not interchangable. That is, if we want to send servo.move(4,90), we need to make sure that Arduino knows that the ‘4′ means “Servo #4″ and the ‘90′ means “90 degrees.”

Tom Igoe’s article, “Interpreting Serial Data,” contains an excellent discussion of some of the problems involved in serial communication, and lists several issues that need to be addressed in every project, namely:

1. How many bytes am I sending? Am I receiving the same number?
2. Did I get the bytes in the right order?
3. Are my bytes part of a larger variable?
4. Is my data getting garbled in transit?

The Arduino’s Serial.read() function reads one byte of data at a time from its serial buffer. Think of the serial buffer as a mailbox. It’s a small (128 bytes) area of memory where incoming serial messages are stashed until the Arduino is ready to read them. Every character we send from the PC to Arduino is one byte. So, while we could send the Arduino something very unambiguous like, “Yeah, hi, Arduino, it’s the Linux Box again. What’s happening? If you could go ahead and move Servo #4 to the 90-degree position, that would be great. Thaaanks,” (163 bytes) it’s obviously better if we can come up with something a little more terse.

However, as we’ve seen, if we just send over the characters ‘4′, ‘9′, and ‘0′ — remember, each character is a byte — the Arduino might get confused. This problem is amplified when more commands start stacking up in the buffer. Let’s say now we command servo.move(2,180) and servo.move(3,120). Now the buffer should hold {4,9,0,2,1,8,0,3,1,2,0}, except–OOPS!–one of the bytes got dropped along the way, so now it holds {4,9,0,2,1,8,3,1,2,0}. “Wait, which servo did you want me to move?” You can clearly see a problem developing.

Solution: Data Packets and Start Bytes

Luckily, part of the solution is handled in the way Arduino communicates. Arduino uses ASCII encoding to represent alphanumeric characters. Each character sent over the wire is converted to the binary equivalent of a decimal value from 0 to 255. [See this conversion chart for specifics.]

So, for example, if we send over the character ‘A’, Arduino recognizes this as its decimal value, ‘65′. We won’t get too deep into this concept except to say that the implementation is great for our application, because as long as the values we’re sending are less than 255, they’ll fit neatly into one byte. Since the largest value we send is 180, we only have to send two bytes per command.

Now, if you’ve looked at the ASCII conversion chart, you’ll recognize that doing this every time you want to send a command would be a real pain. Also, trying to teach Python this chart would take up a lot of unnecessary code. Thankfully, this problem is already solved for us with Python’s chr() function. Wrap any decimal value from 0-255 in chr(), and you get back its ASCII equivalent. A few examples:

~$ python
>>> chr(65)
'A'
>>> chr(110)
'n'
>>> chr(13)
'r'
>>> chr(9)
't'

You get the idea, but notice that ASCII doesn’t just represent letters and numbers, but also symbols and other “control” or “non-printing” characters like line-feeds, returns, and tabs.

So, now if we want to send servo.move(4,90), we only need two bytes, the ASCII equivalents of ‘4′ and ‘90′, represented in Python as chr(4) and chr(90), and interpreted by the Arduino sketch as, once again, simply ‘4′ and ‘90′. Easy! [Seriously, if your brain explodes at this point, or you're bleeding from the ears, it's understandable. I don't like it any more than you do, but stick with me, it'll all work out neatly in the end.]

Packets, Headers, and Payloads

Okay, great, now instead of just digits in Arduino’s serial buffer, we have meaningful values. Part of the problem is solved, but we still haven’t addressed the issue of dropped or missing bytes. That is, how will the Arduino know that a ‘4′ is “Servo #4″ and not “4 degrees” when pulling values out of a crowded buffer like {4,90,2,180,3,0,1,110} ?

The answer is data packets. Very simply, instead of just sending a long string of numbers to Arduino, we’ll send a very specific ordered message, a packet of values, that is intended to be read and interpreted as a whole and in order, or else discarded completely.

Now, the structure of a packet can be as simple or as complex as we need it to be, as you might have noticed if you followed that last link. But all we really need is some means of ensuring that Arduino doesn’t confuse one value for another.

Essentially, our Python script needs to tell Arduino three things:

1. Here comes a new servo command.
2. Servo number to move.
3. Commanded servo position.

We’ve already been sending the last two elements, the servo number and position. Here, we’re adding a third element, which we’ll call the header or the start byte. Our header, like the rest of the data in our packet, will be just one byte long, and contain no real information other than the conceptual message, “I am a header.”

The order of this message is important. Every packet sent over the wire, or read from the serial buffer, will now have the following format:

(Header, Servo Number, Servo Position)

or, more tersely:

(startbyte, servo, angle)

What to use as a startbyte? Well, we’re only using the values from 0-180 as either our Servo Number or Servo Postion. Any value from 181 to 255 would be unique. We’ll use ‘255′ just to make it obvious. So, every packet will now look something like one of the following:

(255, 1, 90)
(255, 2, 180)
(255, 3, 0)

And the Arduino’s serial buffer would look something like:

{255,1,90,255,2,180,255,3,0}

Now, instead of reading byte after byte and hoping for the best, Arduino will wait until a minimum of three bytes arrive in the buffer, and then read the first byte to determine whether or not it is, in fact, a header (255). If it’s not, Arduino skips that value, and moves on to the next byte without touching the servos. When it finally sees a header, Arduino continues reading the next two bytes, in order, and assigning them to the Servo Number and the Servo Position, respectively. If either of those two values is ‘255′, Arduino assumes something is wrong, and skips everything until it reads a new header.

Side Note: Authoritarian Flow Control

“Now just a minute!” you’re saying. “If that is the case, then some of the commands Python sends to the Arduino will be totally ignored!” And you’re right. This method of serial flow control is definitely one-way, with no error-checking. Other methods, such as “call-and-response” or “handshaking” are much better at ensuring accuracy, since there’s a back-and-forth arrangement that can call for data to be re-sent in the event of dropped packets. But the two-way protocol this method requires is much slower.

We have to make an engineering decision. In our application, which is more important, accuracy or quick response? It depends on exactly how you are using the servos, but if you consider say, a joystick-controlled robot or RC vehicle application, then clearly an immediate response and quick visual feedback is preferable to perfect accuracy. If you command “turn right” with a joystick, and your vehicle doesn’t respond appropriately, you’ll just instinctively add more right stick input.

Perfect accuracy is not required.

Writing the Code

Very briefly, let’s look at how the above concepts are implemented in both the Python and Arduino software.

Python Implementation

Whenever we call the servo.move() method, the Python script servo.py handles the serial communication details using the pyserial module, and formats the arguments into the data packet outlined above. The bare-bones version looks like this:

#!/usr/bin/env python

import serial
usbport = '/dev/ttyUSB0'
ser = serial.Serial(usbport, 9600, timeout=1)

def move(servo, angle):
    if (0 <= angle <= 180):
        ser.write(chr(255))
        ser.write(chr(servo))
        ser.write(chr(angle))
    else:
        pass

Arduino Implementation

Arduino opens its own serial connection, waits for at least three bytes to fill the buffer, then starts reading:

/** MultipleSerialServoControl.pde (bare bones) **/

void setup() {
  // Open the serial connection, 9600 baud
  Serial.begin(9600);
} 

void loop() 
{ 
  // Wait for serial input (min 3 bytes in buffer)
  if (Serial.available() > 2) {
    // Read the first byte
    startbyte = Serial.read();
    // If it's really the startbyte (255) ...
    if (startbyte == 255) {
      // ... then get the next two bytes
      for (i=0;i<2;i++) {
        userInput[i] = Serial.read();
      }
      // First byte = servo to move?
      servo = userInput[0];
      // Second byte = which position?
      pos = userInput[1];
      // Packet error checking and recovery
      if (pos == 255) { servo = 255; }

If Arduino gets a complete packet with header, servo, and angle values, it assigns the new position to the appropriate servo. If the value of servo is not between 1 and 4 (or whatever maximum number of servos you specify), the loop exits without assigning any new values. That's it! The Arduino Servo library really makes servo control easy and painless.

      // Assign new position to appropriate servo
      switch (servo) {
        case 1:
          servo1.write(pos);    // move servo1 to 'pos'
          break;
        case 2:
          servo2.write(pos);
          break;
        case 3:
          servo3.write(pos);
          break;
        case 4:
          servo4.write(pos);
          break;
    }
  }

Whew! We're Done.

Well, if you've made it this far, congratulations: you're totally insane. I hope the above dissertation helps at least one person better grasp these concepts, since it took me across many web pages and into several late nights to find the answers. Good luck!

References

1. Tom Igoe, Making Things Talk: Practical Methods for Connecting Physical Objects
2. Tom Igoe, "Serial Communication"
3. Tom Igoe, "Interpreting Serial Data"
4. Society of Robots, "Actuators and Servos"
5. ITP Physical Computing, "Servo Lab"
6. ITP Physical Computing, "Serial Lab"

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“

Thanks to this tutorial on the Ubuntu Forums, getting the latest Skype up and running is a snap. Just paste the following code into a terminal. This snippet works on 64-bit Gusty (7.10), Feisty (7.04), and Edgy (6.10) installations.

cd; sudo apt-get install ia32-libs lib32asound2; cd ~/Desktop; wget -N boundlesssupremacy.com/Cappy/getlibs/getlibs-all.deb; wget -N -O skype-install.deb http://www.skype.com/go/getskype-linux-beta-ubuntu; sudo dpkg -i getlibs-all.deb; sudo dpkg -i --force-all skype-install.deb; sudo getlibs /usr/bin/skype; cd ~

Webcam Configuration

I have the Logitech QuickCam Pro 9000 webcam. Kopete was recognizing and using the camera right out of the box. Skype, however, wouldn’t show the webcam image in its configuration page. I thought I already had the necessary uvc driver installed, but apparently Skype didn’t agree. So, I tried this procedure from the Ubuntu documentation.

Install the prerequisites (Subversion and Video4Linux):

sudo apt-get install subversion libpt-plugins-v4l2 v4l2ucp libsdl1.2-dev

Get the latest build of the uvc driver using Subversion:

svn checkout svn://svn.berlios.de/linux-uvc/linux-uvc/trunk

Compile and install:

cd trunk

make

make install

Then I restarted the computer. It worked, but I’m still not sure why.

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:

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

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

Image credit: SpaceX

Typically, two separate chemical propellants are used, a fuel (such as liquid hydrogen or kerosene), and an oxidizer (such as liquid oxygen or nitrous oxide), which provides the oxygen to sustain a burning reaction. Rockets differ from similar propulsion systems such as gas turbine engines (jets) in that they carry both their fuel and oxidizer on board, thereby needing no intake oxygen to operate. Also, the performance possible with rockets make them ideal for vehicles such as spacecraft, which need to achieve large changes in momentum and high final velocities.

A rocket operates according to Newton’s third law of motion, which states, generally, that for every action there is an equal and opposite reaction. In a chemical rocket, the fuel and oxidizer are combined in a combustion chamber, where they are exposed to a source of ignition, causing a violent chemical reaction which produces hot, rapidly expanding gases. These gases are accelerated through a throat and nozzle, where they are ejected at very high velocity, thereby imparting a change of momentum to the vehicle.

For the purposes of this discussion, there are three major types of chemical rockets: solid propellant, liquid propellant, and hybrid propellant.

A solid propellant rocket, commonly called a “rocket motor,” is likely a composite propellant, with both the fuel and oxidizer pre-mixed together with a firm, rubber-like putty called the binder. This mixture is then formed into the shape of the engine casing itself, and contains an empty space or port down the center of the putty which serves as the combustion chamber. The Solid Rocket Boosters (SRBs) on the Space Shuttle are the most notable of this type of system, using aluminum powder as a fuel and ammonium perchlorate (NH4ClO4) as an oxidizer.

Liquid- and Solid-Propellant Rockets. Note the different combustion chambers and the significant increase in complexity required for a liquid system.

Hybrid Rocket with molded plexiglass fuel module (left) and N20 oxidizer canister (blue, right). (Image credit Hypertek.)

A liquid propellant rocket, commonly called a “rocket engine,” keeps its fuel and oxidizer in separate fuel tanks, then, through a series of pumps, valves and injectors, combines the propellants in a combustion chamber. Liquid systems tend to have better fuel efficiencies (in terms of impulse per unit weight) than solids, but are considerably more complex and thus more prone to failure. The Space Shuttle Main Engines (SSMEs) are the most recognizable implementation of a liquid propellant system.

Hybrid propellant rockets typically utilize a solid fuel and a liquid or gaseous oxidizer. Fuel in a hybrid can be almost anything combustible, but the most common is rubber or, specifically, Hydroxyl-terminated Polybutadiene (HTPB). While rubber may seem a strange choice for use as a rocket fuel, it is interesting to note that the binder used in the shuttle’s SRBs is, in fact, a polybutadiene. Hybrid oxidizers are similar in nature to liquid systems, although N20 (nitrous oxide) is commonly chosen for its ease of handling and storage. Hybrids are seen as being more versatile than solids due to their ability to throttle, stop and restart, and safer than liquids since the propellants are, separately, totally inert. Currently, however, little experimentation has been done with large-scale hybrids.

Most commercial hobby rockets use some form of solid propellant, either black powder or a HTPB-Ammonium Perchlorate composite. A few companies are now producing high-power hybrid motors for the hobby market which are considerably less expensive per flight than composites of comparable performance, but require a complex system of ground support equipment (GSE). The most well-known commercial application of a large hybrid motor is Scaled Composites’ suborbital rocket glider, SpaceShipOne.

Rocket Performance

When designing or selecting a rocket propulsion system for an aerospace vehicle, various performance parameters must be addressed. These include such concerns as final velocity desired, maximum acceleration, maximum altitude, payload and vehicle mass, and fuel mass budget and volume constraints, to name a few. In order to understand and compare the performance characteristics of different systems, the following principles must be discussed.

Force

In physics, a force acting on a body is that which causes the body to accelerate; that is, to change its velocity. The concept first appeared in Newton’s second law of motion of classical mechanics, and is usually expressed by the equation:

F = m a

where

F is the Force, measured in newtons (N),

m is the Mass, measured in kilograms (kg), and

a is the Acceleration, measured in metres per second squared (m/s²).

[Review SI Units of Weights and Measures.]

Thrust

Thrust is the force that propels a rocket. The diagram to the right shows a rocket’s combustion chamber with an opening, the throat and nozzle, through which the expanding gases can escape.

(Diagram credit Robert A. Braeunig.)

The thrust force is a product of the exhaust velocity (V_e) and the mass flow rate (q) of the ejected propellant, plus the difference between the atmospheric pressure (P_a) and the pressure of the exhaust gases (P_e). Exhaust pressure (P_e) is affected by the expansion ratio of the rocket nozzle, defined by dividing the area of the nozzle’s exit (A_e) by the area of the throat (A_t).

Thrust is therefore expressed by the equation:

F = q V_e + (P_e – P_a) A_e

A nozzle is said to be optimized for its operating environment when P_e = P_a. Assuming an optimized expansion ratio, the thrust equation can be reduced to its simplest form:

F = q V_e

where

F is the Thrust force, measured in newtons (N),

q is the Mass Flow Rate of the ejected propellant, (kg/s), and

V_e is the hot gas Exhaust Velocity relative to the moving vehicle, (m/s).

This looks very similar to the Force equation above (F = ma), and upon closer inspection it becomes clear that Thrust is simply the acceleration of a given mass of propellant out the back end of the vehicle which, in turn, pushes it forward.

The Thrust Curve

As a rocket motor fires, its instantaneous thrust can be measured and recorded over the duration of the burn. This data can then be plotted on a graph with thrust (in newtons or pounds) on the vertical scale and time (in seconds) on the horizontal scale. This graph is commonly referred to as a “thrust curve”, and is used as a visual means of comparing two different rocket motors. (See Fig. 1)

Typical thrust curve. (Credit ThrustCurve.org.)

You can see from the graph that the thrust spikes sharply at the beginning of the burn, and then gradually begins to taper off. This spike is the point of maximum thrust, and it occurs in this example at about 0.3 seconds into the burn.

Total Impulse

The area under the thrust curve is called the total impulse. It is the product of the thrust force integrated over the burn time, and is expressed by the equation:

or

I = F t (assuming constant thrust)

where

I is the Total Impulse, measured in newton-seconds (Ns),

F is the total Thrust, in newtons (N), and

t is the burn Time, in seconds (s).

Total impulse is the best means of comparing one rocket motor to another. It is proportional to the total energy released by all the propellant in a propulsion system. More total impulse means more velocity and altitude for vehicles of equal mass, or more payload for flights of similar altitude.

You’ll also see in Figure 1 the line of average thrust (F_avg). This number is useful in making approximations of burnout velocity and maximum altitude of a given vehicle, and is also used in the designation of motor types (see next section). Since no rocket motor has constant thrust throughout its burn time, average thrust is computed by dividing total impulse by burn time (F_avg = I / t).

Specific Impulse

Propellant efficiency of a rocket propulsion system is measured by specific impulse (I_sp). Put simply, specific impulse is the total impulse obtainable per unit weight of propellant. This means that the higher the I_sp, the less fuel mass required for a desired total impulse. Specific impulse is expressed by the equation:

I_sp = I / m_p g

where

I_sp is the Specific Impulse, measured in seconds (s),

I is the Total Impulse, in newton-seconds (Ns),

m_p is the Propellant Mass, (kg), and

g is the acceleration of Gravity at the surface of the earth, (roughly 9.81 m/s²).

The next section will describe how these terms are used in the designation and classification of commercial hobby rocket motors.

Rocket Motor Designation

Rocket motor manufacturers designate each of their motors with standardized letter and number codes which approximate total impulse and average thrust. This allows motors built by different manufacturers, possibly having different propellant types and weights, to be classified by their total impulse.

Each motor will have a code similar to the following:

C6-7

The first letter of the code indicates the Total Impulse category. In this case, the letter “C” indicates that this motor has a total impulse between 5.01 and 10.00 Ns. Each successive letter indicates twice the impulse of the previous category (e.g., a “D” motor has an upper limit of 20.00 Ns.)

The next number indicates the Average Thrust of the motor throughout its burn time. In our example, the number “6″ indicates that the average thrust of this motor is roughly 6 N. [Note: Motors of equal impulse will often have different average thrust values. Assuming equal total impulse (e.g. two "C" motors), a greater average thrust value will produce greater acceleration over a shorter burn time. This is helpful for getting heavy rockets off the pad and flying quickly.]

The number following the dash (-) is not always present, as it represents the Delay, in seconds, between motor burnout and the recovery system ejection charge. Here, the number “7″ indicates a seven-second delay between motor burnout and chute deployment. Longer delays allow a longer coast phase between burnout and apogee. [Note: Many high-power motors ("G" impulse and higher) will have no built-in delay, allowing the user to tailor the delay length to vehicle mass and predicted coast time, either with a modular delay charge or a flight computer. A motor with a -0 designation is intended for use as a first stage motor on vehicles with multiple stages.]

The following table lists standardized impulse categories by their alphabetic designator. Specific information on each motor type, including thrust curves, can be found at the NAR Certified Motors page.

Model Rocket Flight Profile

Diagram credit NASA Glenn Research Center.