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

LightScribe is an innovative technology that uses a special disc drive, special media, and label-making software to burn labels directly onto CDs and DVDs. The labels are laser-etched, not printed, so there’s no ink, no smudging, and no peeling.

LightScribe lets you create one-of-a-kind designs with your own photos, text, and artwork. The days of hand-labeling or printing stickers for your CDs and DVDs are over.

This short tutorial will describe how to install and run LightScribe software on Ubuntu. These instructions are tailored specifically for Ku/Xu/Ubuntu 64-bit users, since the LightScribe software is designed for the 32-bit architecture. Where necessary, alterations for 32-bit users are included.

What You Need

Before downloading anything, make sure you have the necessary hardware and materials at hand, or you may have to make an emergency trip to your local big-box electronics store.

LightScribe hardware

LightScribe-enabled disc drives do double duty. The same laser that burns your data will also laser-etch your customized CD/DVD labels. LightScribe-enabled CD/DVD burners are ubiquitous these days. You may already have one.

Just look for the LightScribe logo on the drive bay door:

LightScribe media

LightScribe CDs and DVDs have a special coating that interacts with the laser in your LightScribe-enabled disc drive. You must use LightScribe CDs and DVDs in order to burn a label onto your discs.

LightScribe software

LightScribe software may have come packaged with your CD/DVD burner, and different flavors are available from a variety of vendors online. Unfortunately, they’re all for Windows. For Linux, we’ll be using basically two programs: (1) the LightScribe System Software, which handles the low-level system tasks like communicating with your disc drive, and; (2) the Lacie LightScribe Labeler for Linux, or 4L for short.

Installing the Software

1. Download the LightScribe System Software using the following command, or get the most current version from the LightScribe Downloads page. Open a terminal and paste the following code:

wget http://download.lightscribe.com/ls/lightscribe-1.12.37.1-linux-2.6-intel.deb

2. Download the Lacie LightScribe Labeler for Linux (4L).

from here:

wget http://principialabs.com/files/4l_1.0-r6_i386.deb

or here:

wget http://uploads.mitechie.com/lightscribe/4l_1.0-r6_i386.deb

3. Install the LightScribe System Software. Important: You must install this first, before installing 4L! Open a terminal and paste the following code, but be sure the package name matches the one you downloaded from the LightScribe website (e.g. lightscribe-1.12.37.1-linux-2.6-intel.deb). [Note: For 32-bit users, simply remove the --force-architecture switch from the command.]

sudo dpkg --force-architecture -i lightscribe-1.12.37.1-linux-2.6-intel.deb

4. Install 4L, the Lacie LightScribe Labeler for Linux. Important: You must install the LightScribe System Software first, or this won’t work! [Note: For 32-bit users, simply remove the --force-architecture switch from the command.]

sudo dpkg --force-architecture -i 4l_1.0-r6_i386.deb

Running the Lacie LightScribe Labeler

The graphical user interface to 4L is called 4L-gui and can be run from the command line. It must be run as the root user, like so:

sudo 4L-gui

This will launch the 4L GUI pictured above. The interface is fairly intuitive, but the basic procedure is:

1. Insert LightScribe media into your disc drive, label side down!
2. Select an image to burn onto the CD or DVD by using the “Import Image” button.
3. Adjust the image size and alignment as necessary using the scale slider.
4. Preview the finished product by pressing the “Print” button and then selecting “Preview.”
5. Press “Print” to burn the label to the disc. A full-size image should take about 20 minutes.
6. Remove the CD/DVD media and FLIP!
7. Use K3b (or your favorite burner program) to burn data on your new hella-cool custom disc!

Burn - Flip - Burn!

One final technical note: Unfortunately, the installation process above does not create a new item in your programs menu. If you’d like to create an item in your program menu for the LightScribe labeler, check out this thread on the Ubuntu Forums.

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

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

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

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

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

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

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

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

Ready to install the 28-pin socket.

Socket and headers soldered in.

Behold the AVR ATmega168 microcontroller.

Inserting the ATmega168.

Boarduino completed, powered up and ready to go.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Let me know if I’ve missed anybody!

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.

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 “MultipleServos” sketch, take note of the following three variables and make adjustments as necessary for your setup. See “Arduino Serial Servo Control” for more details regarding the minPulse and maxPulse variables.

int pinArray[4] = {2, 3, 4, 5}; // digital pins for the servos
int minPulse = 600;             // minimum servo position
int maxPulse = 2400;            // maximum servo position

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. 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.


• multijoystick.py: Allows joystick control of the servos, with each joystick axis controlling a single servo. This code could the basis for a Wi-Fi RC vehicle of some kind.


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

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

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:

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

void setup() {
  // open serial connection
  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?
      servoPosition = userInput[1];
      // packet check
      if (servoPosition == 255) { servo = 255; }

If Arduino gets a complete packet with header, servo, and angle values, it calculates the correct pulseWidth for the commanded servo angle, and assigns that value to the appropriate servo. If the value of servo is not between 1 and 4, the loop exits without assigning any new values.

      // 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; }
      // assign new pulsewidth to appropriate servo
      switch (servo) {
        case 1:
          servo1[1] = pulseWidth;
          break;
        case 2:
          servo2[1] = pulseWidth;
          break;
        case 3:
          servo3[1] = pulseWidth;
          break;
        case 4:
          servo4[1] = pulseWidth;
          break;
      }
    }
  }

Finally, once each loop, whether it receives any serial data or not, Arduino checks to see if the servos need a pulse. To hold their current positions, RC servos expect a pulse at 50Hz (every 20ms), so Arduino keeps track of the lastPulse. If the timer is up, all servos get a pulse.

  // pulse each servo
  if (millis() - lastPulse >= refreshTime) {
    pulse(servo1[0], servo1[1]);
    pulse(servo2[0], servo2[1]);
    pulse(servo3[0], servo3[1]);
    pulse(servo4[0], servo4[1]);
    // save the time of the last pulse
    lastPulse = millis();
  }
}

// create the pulse
void pulse(int pin, int puls) {
    digitalWrite(pin, HIGH); // start the pulse
    delayMicroseconds(puls); // pulse width
    digitalWrite(pin, LOW);  // stop the pulse
}

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“

My first computer was an Apple IIc. I was thirteen years old and, at that age, it was one of the most beautiful things I had ever seen. It had a gorgeous, green-on-black display screen, 128KB of RAM, no hard disk, and a Slim-line internal 5.25″ floppy drive into which you loaded whatever version of Zork you were in the mood for, and fired it up. All software was written in Applesoft BASIC, and although there was no official term for it at the time, everything was open source.

A simple Ctrl-C (or some such keystroke) was all that was required to break the flow of whatever program you were running and take a peek under the hood. I wrote my first computer program on the IIc. There might have been limits to what that little machine could do, but there were no restrictions. If you could imagine it, you could build it, and if you didn’t know quite how to build it, you just found someone else’s program that did something close, and figured out how they had done it. The Apple IIc was more than a tool, it was a teacher.

In college I used PCs and Macs, none of which I owned, of course — it just wasn’t expected in those days — and I reluctantly deciphered the library’s Unix terminals for the sole purpose of emailing friends with Pine. Until my junior year, by which time I was accustomed to using the university’s computer labs for my paper-writing and other needs, I kept that old Apple IIc around, with a dot-matrix printer, just in case.

It wasn’t until after graduation that I could finally afford (almost) to purchase my own computer. After buying and returning a couple of defective laptop PCs from a big box electronics retailer, I finally decided to go back to Apple, and I sprung for a Powerbook G3. It was beautiful, and it was definitely a Mac, but something was missing.

By this time, of course, Apple had come a long way in user interface design. The G3 ran MacOS 8, so it wasn’t without flaws, but it was intuitive, easy to use, and gorgeous. Only it wasn’t mine. It was Apple’s. As long as what I wanted to do was what Apple wanted me to do, things were fine. But as soon as I started thinking out of the box … well, it just wasn’t right. It wasn’t the IIc.

A few years later, after doing the obligatory post-college drift for awhile, I went to flight school. By then the G3 was nearly obsolete, but there was no money for anything new, and anyway a computer wasn’t a requirement for my new pursuit. But one night, while grilling burgers in the muggy Florida evening, a friend of mine offered to give me an old Dell desktop, complete with keyboard and VGA monitor. “It doesn’t work,” he said. “It’ll turn on, but nothing shows up on the screen. Anyway, I just bought a new one, so if you want it, it’s yours.”

And there it was: my first project box. A discarded old beige tower that probably didn’t work anyway. There was little I could do to make it any less useful than it already was, so I took it. I felt no pressure, no fear. It wasn’t an appliance, it was junk, and I could experiment with it all I wanted. I gambled that a cheap video card was all it would need to be back in shape, and I was right.

But once I had ripped the insides apart, and learned all I could from it, the fun stopped. So I got it to run Windows 95 again, so what? There was no magic in running Microsoft Word. The project box sat idle.

And then I discovered Linux.

It was Red Hat Linux 7, to be exact, in CD format, from the back of a loaned copy of a For Dummies book, written by none other than Jon ‘maddog’ Hall himself. I wiped Windows from the hard disk and installed Linux for the first time.

The old Dell box was lacking a bit in the memory department, and it ran the Red Hat GUI a little slow, so I decided to configure it to boot to the command line. Suddenly there it was: the text interface on a black screen — the characters were white, but they might as well have been green, and that blinking cursor that awaited my command — I was back in my parents’ basement, on the IIc, thirteen years old. The World was inside that box, and it was mine to explore.

A few years, a new Windows laptop, and several project boxes later, I tried Ubuntu, a new flavor of Linux that showed promise as a truly useful, user-friendly OS. Again there was no pressure, no fear, just a learning curve — only as steep as I wanted it to be — and there was Linux, the teacher. I was hooked. My “project” box became my primary computer, and when its hardware became too outdated to warrant patching up, I built a high-end AMD64 box from the ground up, specifically to run Linux.

Now, that computer, running Kubuntu 7.10, is my primary electronic tool, and my laptop sits mostly idle. It’s as slick a system as anything I could ever want, and the best part is, I own it. I run it. I control it. And I understand it, because I built it. I use Linux for all the same reasons everyone else does: stability, security, freedom, exclusivity, variety — but mostly I use Linux because it’s like my old Apple IIc, and because it made me love computers again.

Hulu lets you watch full-length feature films like The Big Lebowski or The Usual Suspects, or recent television episodes of Family Guy or The Office. Plus there’s a fair number of canceled cult classics like Firefly.

Both shows and movies are interrupted with brief commercial breaks, but these can be –ahem– suppressed, and they are definitely less intrusive than those on regular commercial television. Content on Hulu is certainly limited, but they’re just getting started, and I must say, with respect to the movie selection, I’d be inclined to browse Hulu for decent flicks before I’ll suffer the crap from the Netflix “Watch Instantly” archive.

Probably the biggest selling point for me is the fact that the Hulu Flash player is completely browser- and platform-independent, so I can watch fullscreen TV, movies, and eventually HD content on my fast, new Linux box with the big LCD. I’m sick of having to go to my Windows laptop just to stream LOST on ABC.com or watch Netflix movies (which also require Internet Explorer–a double whammy!), because I get the “your OS/browser is not supported” message on Kubuntu.

Hulu also lets you embed full-length shows or movies right into a blog or website, and on top of that, the interface gives you the option of selecting a specific “clip” from a film or show to embed. So, for example, if you wanted a specific scene from the film Field of Dreams, you could have it:

Anyway, I’m sure there are a few bugs to tweak, and I’m always leery of anything with this kind of support from the “legacy” content providers, but so far it seems worth checking out, if only to see some old Airwolf reruns!

This excellent video from the TED Talks website deals with biomimicry, the concept of getting engineering inspiration from the natural world.

From the abstract: With 3.8 billion years of research and development on its side, nature has already solved problems that human designers and engineers still struggle with.

In this inspiring talk, Janine Benyus provides fascinating examples of biomimicry — the way humans mimic nature in the products we build and the systems we implement. And because the champion adapters in the natural world are, by definition, those that can survive without destroying the environment that sustains them, biomimicry can contribute to the long-term health of our planet.

The probability of an accident occurring in a homebuilt aircraft is high during its initial flight test phase. This is especially true if the builder-pilot has limited experience in the type of aircraft being flown. Often homebuilders put so much emphasis on completing the project that they forget to hone their flying skills during the construction period.

FAA Advisory Circular AC90-89A (PDF, 798K), the “Amateur-Built Aircraft and Flight Testing Handbook” is a 99-page document detailing the necessary preparation for and execution of a flight test program for your homebuilt aircraft.

The EAA provides assistance to builders and pilots embarking on this exciting and rewarding quest. Learn more at EAA.org.