Feb 172014

As mentioned in an earlier post I have decided to use the Eggbot control board (EiBotBoard) to drive my drawbot. I’ve gotten the electronics up and running, mostly just plug it in, screw down the stepper motor wires, and plug in the pen lift servo motor. Here are some videos of the EiBotBoard in action.

Some commentary on why I am using the EiBotBoard. The EiBotBoard is a nicely integrated dual stepper motor, multi servo motor driver that accepts high level motion commands over USB from a serial console.

Description of the motors selected for the drawbot. A couple NEMA 17 stepper motors I had laying around in my parts box. They are 0.8 amp motors, well within the 1.25 amps the EiBotBoard can supply.

Motion demo of the EiBotBoard driving two steppers and a pen lift servo. The script that is running is posted below. I am using a cygwin command window to echo the commands to the USB virtual comm port. Keep in mind Windows enumerates the COM ports starting at 1 and cygwin enumerates /dev/ttySxx starting at 0. In the script below I am echoing to ttyS18 because Windows enumerated the COM port at COM19.

Finally more commentary on why I like using the EiBotBoard.

Commands running in a cygwin shell script. Script with comments below.
echo "v" > /dev/ttyS18
echo "sm,500,500,500" > /dev/ttyS18
echo "sc,4,6000" > /dev/ttyS18
echo "sc,5,26000" > /dev/ttyS18
sleep 1
echo "tp" > /dev/ttyS18
sleep 1
echo "tp" > /dev/ttyS18
sleep 1
echo "tp" > /dev/ttyS18
sleep 1
echo "tp" > /dev/ttyS18
sleep 1
echo "tp" > /dev/ttyS18
sleep 1
echo "em,3,3" > /dev/ttyS18
echo "sm,1000,2000,2000" > /dev/ttyS18
sleep 1
echo "sm,1000,-2000,2000" > /dev/ttyS18
sleep 1
echo "sm,1000,2000,-2000" > /dev/ttyS18
sleep 1
echo "sm,1000,-2000,2000" > /dev/ttyS18
sleep 1
echo "sm,1000,2000,-2000" > /dev/ttyS18
sleep 1
echo "sm,1000,-2000,2000" > /dev/ttyS18
sleep 1
echo "em,0,0" > /dev/ttyS18

Send the version command to the board, establishes communication with the board.
echo “v” > /dev/ttyS18

Move both steppers at 1/16 size steps (the default) for 500 steps each and take 1/2 second to move (500 msecs)
echo “sm,500,500,500” > /dev/ttyS18

Set the pen lift servo min and max values, 6000 and 26000, determined from experimenting with this servo
echo “sc,4,6000” > /dev/ttyS18
echo “sc,5,26000” > /dev/ttyS18

Each TP command toggles the pen position from up or down
echo “tp” > /dev/ttyS18

Set the stepper fraction to 1/4 sized steps.
echo “em,3,3” > /dev/ttyS18

Step the motors for sm, duration in msecs, number of steps motor1, number of steps motor2
echo “sm,1000,2000,2000” > /dev/ttyS18
echo “sm,1000,-2000,2000” > /dev/ttyS18
echo “sm,1000,2000,-2000” > /dev/ttyS18
echo “sm,1000,-2000,2000” > /dev/ttyS18
echo “sm,1000,2000,-2000” > /dev/ttyS18
echo “sm,1000,-2000,2000” > /dev/ttyS18

Disable the motor drivers to avoid over heating the motors.
echo “em,0,0” > /dev/ttyS18

Jan 312014

Ever since I saw a post about a drawbot on Hackaday I’ve been wanting to build my own.

A quick search of drawbot or plotterbot or polargraphic plotter will lead you to plenty of youtube videos and websites describing and demoing polargaphic style plotters.

I don’t expect to break any significantly new ground here. I’m planning on building a pretty standard two stepper motor, servo pen lift, monofilament on pulleys, weighted gondola polar plotter.

One thing I am doing that is possibly different, at least I haven’t seen it’s like yet, is I’m planning on using an Eggbot EiBotBoard for motion control.

If you don’t know what an Eggbot is google it, watch a couple youtube videos, visit a few websites. It is a cool toy, and fundamentally nearly identical to a polar plotter. Basically an Eggbot is a spherical plotter. It should be a short step to a polar plotter. Certainly the hardware should be a drop in. The EiBotBoard has built in two axis coordinated stepper motor control, a pen lift servo control, and open source software for control and drawing conversion.

I plan on 3D printing the motor mounts and the pen gondola. Thingiverse has multiple models for motor mounts of various sizes and multiple different gondola styles. No real rocket science there. Download the models, update as needed for my motors and pen, and print them.

The interesting part is likely to the modification of the path generation to interface to the EiBotBoard. The Eggbot community has written a plugin for inkscape to wrap a flat vector drawing to a sphere and output the motion commands to the Eggbot EiBotBoard. It seems like a reasonable launching point to start with that plugin and modify it to convert line art to polar graphics and then drive the EiBotBoard on a polar plotter.

Often my blog posts are generated after the fact, after I’ve already completed the project, or done enough to figure out what I want to say or how the project is going to go down. In this case I’m blogging as I go. I haven’t started my polargraphic plotter project yet, other than a vague idea of what hardware I want to use and some of the mechanics that I think will work.

Next steps include picking parts and getting them ordered, picking some models and getting them downloaded and printed, downloading the Eggbot interface software and figuring out what’s going on there, then hook it all up and print, easy-peasy-pie.

I’ll keep you updated as I go.

Jan 302014

One of the cool things about buying a widget from Sparkfun, or Adafruit, or Pololu is that almost invariably there is some reference software posted with the product to get you off the ground immediately.

For the Sparkfun LED bargraph kit the reference code can be downloaded from the product page or directly from Sparkfun’s github repo.

The reference software comes with examples that demonstrate multiple ways of driving the LEDs. Here are a couple videos demonstrating the setup and Sparkfun’s demo code putting the bargraph breakout through it’s paces.

This is with no additional coding. Build the LED bargraph display, wire it up to the Arduino SPI, download the Sparkfun bargraph demo library, upload the example code, and sit back and watch the light show.

A different project I am working on needs a display with the feel of an analog VU style meter. I need to monitor a continuous variable and display feedback to a user of the variables relative value between it’s min and max. It was a short step from Sparkfun’s demo code to a display just like I need.

I wrote some quick demo code to read an analog input and map the read values to a set of LEDs on the bargraph display. I forked Sparkfun’s github repo for the bargraph kit and added my additional example code. You can pull the analog input to VU meter display demo from my github bargraph repo.

Here are some videos showing the setup and display of a read analog value in bar and dot modes.

This is exactly the style of display I was looking for and I think this package is going to work nicely.

Jan 282014

I’m in the middle of a project that would benefit from an analog style display. Something to visualize an approximate value, within a min and max range, simply and clearly.

I like to browse Sparkfun’s inventory when I’m looking for new or interesting widgets. They are hometown boys (at least if your hometown is Boulder, CO), they make a range of interesting products, and being local it is easy to order and pickup parts the same day. And it turns out Sparkfun makes a nice LED bargraph breakout kit that looks like just what I’m looking for.

Fully assembled the display is supposed to look like this
The kit consists of a carrier pcb, four 8 bit serial to parallel shift registers(74HC595), some current limiting resistor packs, decoupling caps, and three 10 position LED bargraph displays. The Sparkfun kit comes with a Green, Yellow, and Red bargraph.

The Green to Yellow to Red transitions follow the typical Ok, Warning, Danger pattern. A reasonable choice by Sparkfun given no insight into their customers final designs.

When I picked up the kit I had a different application in mind. Rather than the standard transition from ok to danger I wanted more of a VU meter or power level type of display. For my application a single color for all three bargraphs makes more sense. It turns out Sparkfun sells the LED bargraphs in Blue, which is what I wanted. Each of the four colors of bargraph, Green, Yellow, Red, and Blue, are drop in replacements for the ones in the kit so you can mix and match to get the color or color ordering you want.


Eventually I want to mount this display in an enclosure with the LEDS showing and the pcb hidden. If the board is built as you would expect, all of the components firmly seated against the PCB before soldering, the LEDs do not sit very high above the shift register ICs. That means when the display is mounted either the enclosure walls need to be thin or else the LEDs will be set back in the enclosure wall. It turns out the LED bargraphs come from the factory with pretty long legs, probably around 5 mm. If you solder the LED bargraphs with the legs just through the PCB the front of the LEDs will stand off of the PCB about 12-13 mm and a good 6-7 mm above the ICs. That should give plenty of space to mount the PCB and have the LEDs mount flush to the front of an enclosure.



The kit is easy to assemble and the instructions are complete and easy to follow. The resulting display has a nice look and is easily programmed to display a variety of patterns. The kit can be assembled in under an hour and assuming you have an Arduino laying around and some jumper wires you can be displaying blinky patterns in less than 15 minutes more.

Jan 162014

Download and install a build environment

The Sparkfun Redbot, Pololu 3pi, and Pololu Zumo robots are all based on the Atmel atmega328p processor. All three have a wealth of libraries and supporting software. All three support at least the two most popular methods of creating code for the AVR processors, Arduino and avr-gcc (Windows and Linux). The two Pololu robots also support the Atmel Studio build environment.

Downloading and installing the Arduino environment is pretty straight forward. Download for your environment, unzip or untar, run. Not much more to it than that.

Atmel has taken over the support of the avr-gcc tool chain and hosts the builds for Windows and Linux. Installing the tool chains for Windows and Linux are documented on the Atmel site.

Get the supporting libraries

All three robots have additional supporting libraries; Arduino style for the Redbot and Zumo, Arduino, Atmel Studio, and straight avr-gcc style for the 3pi. Both vendors, Sparkfun and Pololu, provide links to download their libraries. Pololu supplies prebuilt installers for different versions of their libraries. Both companies also provide source on Github; Redbot / Zumo / 3pi. For the Zumo you want both the Zumo Shield library for Arduino programming and the libpololu-avr library for direct avr-gcc programming.

I prefer to go straight to the source and download the libraries fresh from Github. All of the libraries provide a “Download Zip” link to download a compressed bundle straight to your desktop. After you have the downloaded bundle you can uncompress and install it. I prefer to use GIT directly, under Windows and Linux, and clone the repositories directly to my desktop. Whichever method you use you will eventually have copy of the libraries on your local machine.

To clone the repositories locally under Windows I use the git bash shell from git-scm, under Linux I use git. If git is not installed on your flavor of Linux use your distro’s package manager to download and install it.

Install the libraries

The Redbot and Zumo Arduino libraries need to be installed where the Arduino environment can see them. Arduino provides tutorials on installing 3rd party libraries so I wont repeat that information here. Pololu also provides ample documentation on installing their libraries, for all three environments, Atmel Studio, Arduino, and raw avr-gcc.

For the Pololu 3pi robot I am using raw avr-gcc. The steps I used to install the Pololu libpololu-avr library are:

1 ) Insure you have the avr-gcc tools installed

From a command line run avr-gcc –version
If the program is found move forward, if not, return to installing the avr-gcc tool suite.

2 ) Build the Pololu Library

The Pololu library make file by default builds all of the flavors of AVR libraries for all of the Pololu products that use the library. For the 3pi you only need support for the 168 and 328p libraries.

New 3pi robots are based on the Atmel AVR 328p processor. Older 3pi robots were based on the 168 processor. The example program makefiles still reference the 168 library. At this point it is easiest to keep both the 168 and 328 libraries. Over time it makes sense to migrate to the 328, if you have a newer 3pi robot, but for the sake of expediency build both libraries for now.

Edit the libpololu-avr/Makefile and remove the building and installing of unneeded libraries.


In a command window in the libpololu-avr directory make the libpololu libraries. Simply type make in the libpololu-avr directory. The build process should eventually yield two files called libpololu_atmega168.a and libpololu_atmega328p.a. These are the 168 and 328p libraries containing the functionality provided by the Pololu library.

3 ) Copy the libraries and include files

Next you need to make the libraries and required include files visible to avr-gcc. You can either modify the example make files as you create or re-use code to point to your local versions of the pololu libraries and include files or you can copy the library and include files to the avr-gcc default path. Pololu recommends copying the files into the avr-gcc path.

See the pololu/libpololu-avr/README.txt file:

== Manual installation ==

If you have the source repository of the library instead of a binary
distribution, you will need to build the library (.a) files by running
"make" and also copy all the files in the "src" subfolder into the
"pololu" subfolder.

Next, copy libpololu_*.a into your avr-gcc "lib" subfolder.

Finally, copy the entire "pololu" subfolder into your avr-gcc
"include" subfolder.

You are now ready to use the Pololu AVR library.

Use the make show_prefix to discover the avr-gcc paths used in your install.


– Copy the library files, libpololu_atmega168.a and libpololu_atmega328p.a, into the avr-gcc lib directory.
– Copy the pololu directory, libpololu-avr/pololu, not just the files in pololu, the pololu directory and the contained files, into your avr-gcc include directory.
– Copy the contents, including any sub-directories, of the libpololu-avr/src directory, into the newly copied pololu directory in your avr-gcc/include path. In this case copy the “contents” of the src directory, not the src directory itself, into the avr-gcc/include/pololu directory.

Test your install and build the demo code

If all of the above worked you should be able to change into the libpololu-avr/examples_templates/3pi-demo-program and type make.


Now that you have a hex file you need to upload it to your robot.

I use avrdude directly from a command line. Using the Pololu AVR programmer the command looks like:


If everything worked cleanly you should have a fully functioning build and deployment environment ready to write new code.

Jan 092014

I’ve always been interested in competitive robotics. Two (or more) robots duking it out on the field of honor. Trying to solve a problem as fast or efficiently as possible, all the while trying to avoid, out score, or destroy the competitions robot.

Competitive robotics can generally be divided into to groups, direct combative and competitive problem solving. Both are a lot of fun, although combative can get pretty ugly, and expensive, in a hurry.

Competitive robotics puts a lot of pressure on developers and implementers to find optimal solutions in unstructured environments where other participants are actively trying to out score, block, or destroy your robot. You often need to come up with ad-hoc solutions in the middle of competitions to account for variations in the environment and to counter competitors robots.

Things we’ve had to overcome include changes in playing field surface, broken parts, changes in starting conditions, changes in competition rules that you don’t find out about until you get to the competition, and as always, differences in competitors robots that require you to adapt and modify your strategies on the fly.

In competitive robotics you push, pull, climb, and race to get the task at hand done before your competitor does. Changes in traction on different fields requires adapting your motion platform’s drive system. You can change your wheels, from slicks to diggers, or the other way round. Sometimes simply cleaning the tires, washing the dust and dirt off, improves traction enough to make a difference. Sometimes you need more. We’ve created studded tires by lacing plastic wire ties around the wheel and tire and cutting off the tails to leave the knobs pointing out. You do what you have to do to keep your robot moving and stop the competitors robot from moving.

Broken parts are always a bane. Hopefully you’ve built your robot to be maintainable. Motors die, drivers burn out, axles twist and break, screws fall out and pieces fall off. Broken parts require more an act of Nascar like pit crew skills than design changes. How fast can you swap out or adapt parts, under pressure in the middle of a competition, while maintaining a competitive robot. Sometimes you just work around the broken part, changing code to not use the broken functionality or adapting other sensors or actuators to try to work around the broken parts.

The four robot platforms I’m actively using are the

IFI Vex Robotics line,

Pololu’s Zumo Mini Sumo bot,

Pololu’s 3Pi,

and Sparkfun’s Redbot.

All of these platforms are extensible in various ways. Each of them have varying degrees of physical reconfigurability, with the VEX robot being the most physically reconfigurable, the Redbot next, then a toss up between the 3Pi and the Zumo (at the level of not much). All four platforms support adding sensors and of course full reprogrammability. The 3Pi, Zumo, and Redbot benefit from having the same microcontroller, the Atmel Atmega328p, and the same programming environment, Arduino or avr-gcc. The VEX controller is based on an ARM Cortex controller and uses the quite capable (but not free) RobotC development environment.

The VEX ARM processor arguably provides a much more powerful computing platform but is a more closed environment. The Redbot was designed to be modified with multiple sensor and actuator mount points and a fully open design. The 3Pi and Zumo have an open software development environment but suffer from a more closed hardware platform. Both the Zumo and 3Pi robots are able to be extended physically but not as simply as the Redbot or VEX robots.

The VEX robot, while powerful and benefiting from a reasonable line of accessories, is pretty much closed. The manufacturer, IFI, provides scant documentation on the VEX controller internals.

Each platform has different strengths and weaknesses.

The VEX line is expensive and relatively closed. The platform is physically very reconfigurable and being targeted at middle and high school students is pretty robust. The IFI provided sensors are mechanically robust and easy to interface. The downside of being targeted at students is the platform is not easily extended. IFI / RobotC provide few opportunities to step outside the bounds of the RobotC development environment. The upside is, it is harder for a student to get too far afield. The downside is, it is harder for a student to bring new innovations to the platform.

The Redbot line is fully open and extensible. The schematics, board layouts, and platform components are open and documented on Sparkfun’s website. The Redbot is probably the least robust physically. The Redbot is a great development platform but with an eye towards high extensibility and low cost it is probably at the highest risk of taking a catastrophic hit in a competition. That said the Redbot might be the best price to performance platform of the four. The Redbot’s size makes it too big to qualify for mini sumo competitions.

The 3Pi platform is hands down the best choice for line following competitions. It is pretty much designed to be fast and excel at line following. The 3Pi is low to the ground, is probably the fastest by far of the four robots mentioned here, and has a built in integrated line sensing array. The 3Pi platform provides for some extensibility. The 3Pi can be readily extended with sensors and other electronics but the motion platform is pretty fixed. Pololu sells a prototyping shield for adding sensors and other electronics. They also sell replacement motors with different gear ratios to achieve different speed to torque characteristics, but that is about it. Two wheel pivot steering with a caster is pretty much all you get. The 3Pi also requires a pretty clean and unobstructed field. The wheels are on the smaller side and not made for climbing or rough surfaces. If you are doing line following, maze solving, swarm bots, stuff that relies mostly on interesting software solutions and limited environmental interactions the 3Pi is the way to go.

The final robot I actively use is the Pololu Zumo. This bot is specifically a mini sumo pusher bot. Like the 3Pi, the Zumo is optimized for mini sumo competitions. Like the 3Pi the physical platform is not readily extended. The mini sumo rules limit the weight and footprint of the bot, so large physical changes to the bot are probably not in the cards anyhow. The Zumo allows for some sensor extension but the base platform with the sensor array consumes most of the available IO of the 328p microcontroller. Like the 3Pi the motors can be changed to achieve different gear ratios. Also similar to the 3Pi the Zumo relies on two motor slip skid steering. The Zumo is a tracked platform and has a pretty good grip but again like the 3Pi it requires a relatively smooth obstruction free playing field.

Each of these robots solves a different problem in a different way. For line following competitions and newer roboticists the 3Pi is the way to go. For mini sumo the Zumo is great platform. For the home hobbyist the Redbot is probably the best answer. For a more physically extensible and more powerful (and significantly more costly) platform the VEX line is the way to go.

In the end all of the robots are great solutions each with it’s individual strengths and weaknesses. Pick the one that best fits your style or target competition and go for it!

Here’s hoping to see your robot on the competition field.

Dec 312013

The Arduino Pro comes with a bootloader installed, meaning it is plug and play ready to work with the Arduino environment. All you need is a way to hook it up to upload new firmware.

The Pro is a stripped down version of the Arduino UNO. One of the stripped parts is the USB to serial programming interface. Programming the Pro requires either an ISP programmer or a USB to serial translator.

The Pro brings out the standard green to black FTDI cable programming header and Sparkfun recommends their FTDI programming cable (5V) for a plug and play experience. That is all well and good but a FTDI cable is pushing a cost of $20 USD (Sparkfun’s 5V and Adafruits 3.3V). You can buy FTDI breakout boards with the same pinout for a little less, around $15 USD (Sparkfun, Adafruit). That’s better than $20 but still more than twice the cost of other options.

If you are willing to wait for the shipping from China (or you order ahead) you can get a FTDI breakout for less than half the price of the Sparkfun or Adafruit breakouts. The iTeadStudio FOCA breakout has a couple of nice features over the Sparkfun and Adafruit breakouts, and one glaring hassle. First the good, the FOCA interfaces with either 5V or 3.3V systems with the flick of a switch. The FOCA also has an XBEE footprint allowing it to be used as a USB to XBEE interface (compare to Sparkfun’s USB to XBEE board at $25). All in all a pretty nice package for $6.50 USD (as of Dec 2013).

iTeadStudio FOCA

iTeadStudio FOCA

Now for the hassle part. The pinout of the FOCA is NOT a direct crossover to the “standard” green to black programming pinout on Sparfun’s and Adafruit’s FTDI cables, and of course the pinout on the Arduino Pro.

The pinout on the Pro is green to black being reset/dtr, TX, RX, power, cts, gnd.

Sparkfun Arduino Pro

Sparkfun Arduino Pro

The pinout on the FOCA is power, TX, RX, gnd, dtr/reset. Not a straight across plug and play.

FOCA Pinout

FOCA Pinout

Fortunately for half the price it is pretty easy to make an adapter cable. I happened to have a 6 pin to 6 pin inline cable with crimped on connectors which made it easy to move the pins around.

The pins are held in place by little plastic fingers that can be easily lifted back with the tip of an Xacto knife or dental pick, allowing each pin to be slid out of the connector and moved to a different position.


A quick shuffling of both ends of the connector, to move green to one end and black to the other end on the Pro side, and to line up power, gnd, TX, RX, and reset on the FOCA side and wa-la, a FTDI programmer for under $7.50.


Dec 292013

I picked up an Arduino Pro from Sparkfun during their cyber monday sale. The Pro is a stripped down version of an Arduino UNO for about half to a third the price. It is missing quite a few features so if you are just starting out a standard Arduino is probably a safer bet. If Arduinos are old hat the price point is pretty attractive, I picked mine up for just under $9 USD.

The Sparkfun Pro has a round footprint in the middle of the board that turns out to be meant for installation of a buzzer, specifically the Sparkfun 12mm Buzzer. This little buzzer drops right onto the board, but other than a comment from Sparkfunion Robert there is no documentation on how to mount or use the buzzer.

It turns out the Buzzer recommended is really a tiny speaker. A mag coil driving a tiny disk. The two pins connected to the mounting holes connect to the Arduino digital pins 4 and 5. It doesn’t seem to matter which direction you mount the buzzer. I happened to mount the buzzer with the words arbitrarily “up”, which resulted in the “+” side of the buzzer “down”. Down being connected to D4 and Up connected to D5.

Sparkfun Arduino Pro

Sparkfun Arduino Pro

Driving the buzzer is relatively simple, you just set one of the pins, D4 or D5, to an output, pinMode(4,OUTPUT) or pinMode(5,OUTPUT), and drive the other pin, 4 or 5, with a changing signal. The recommended buzzer is basically a speaker and so the input needs to be modulated to generate a sound.

The simplest code to generate a 1 second, 1 KHz tone is:

void setup()
tone(4, 1000, 1000);
void loop()

The built in Arduino example toneMelody can be easily modified to play out the buzzer.

First open the toneMelody example:

Arduino toneMelody

Arduino toneMelody

Modify the bolded lines and upload the sketch to the Pro:


#include "pitches.h"

// notes in the melody:
int melody[] = {

// note durations: 4 = quarter note, 8 = eighth note, etc.:
int noteDurations[] = {
4, 8, 8, 4,4,4,4,4 };

void setup() {

pinMode(5,OUTPUT); // set the "other" buzzer pin to an output

// iterate over the notes of the melody:
for (int thisNote = 0; thisNote < 8; thisNote++) { // to calculate the note duration, take one second // divided by the note type. //e.g. quarter note = 1000 / 4, eighth note = 1000/8, etc. int noteDuration = 1000/noteDurations[thisNote]; tone(4, melody[thisNote],noteDuration); // output the tone on the "+" pin

// to distinguish the notes, set a minimum time between them.
// the note's duration + 30% seems to work well:
int pauseBetweenNotes = noteDuration * 1.30;
// stop the tone playing:

noTone(4); // turn off the tone

void loop() {
// no need to repeat the melody.


The Arduino Pro buzzer playing the toneMelody example sounds like this: