Sparkfun Robot Claw

I recently purchased an inexpensive robot "claw" from Sparkfun.  I was a little hesitant to purchase it at first because of the  mixed reviews in the comments on the Sparkfun product page.  Some people seemed really happy with the claw, but a few were reporting difficulties, primarily difficulties mounting the servo to the claw. 

But I decided, what the heck.  The claw’s only about $10, let’s try it and see what happens.   And I’m glad I did.  The claw has been pretty fun to play with so far.  It definitely makes for a more interesting Arduino/servo project than just watching the little round end of the servo rotate back and forth! :-) 

However, it *is* a little tough to get put together and working.  Like many of the comments over at Sparkfun point out, the Claw doesn’t *quite* fit the medium servo that Sparkfun sells.  It fits well enough to work, but not well enough to assemble easily. 

So to help out other people who are trying to use the Sparkfun claw, I disassembled my claw and put together the following little photo tour as a put it back together.  Enjoy!

Introducing – the Claw!


Shown here with a penny for size comparison is the claw as it looks right out of the box with no servo attached. 

The medium servo:


Also shown next to a penny is the medium servo from Sparkfun and all the hardware that comes with it.

Mounting the servo to the claw body:

The first step to assembling the claw is to mount the servo body to the main body of the claw.  The front face of the servo is going to mount to the back side of the claw, so that the servo drive shaft will poke out through the big oblong hole in the front of the claw.  There are two screw holes on either side of the big oblong hole.  Use the 2 long screws and a couple of the nuts  that came with the servo to secure the servo to the claw.  Leave the nuts very, very loose!  The serve should be loose enough that it can wiggle in and out about 1/4 inch or so.

This is what it should look like once you get the servo body attached to the claw body:


And here’s what it looks like from the back:


You’ll notice in this picture that the screw on the right is really loose, but the screw on the left is fairly tight.  After I took this picture, I actually had to loosen the screw on the left considerably before I was able get the rest of the claw put together.  You might also notice that the screws look like they’re wedged outward in a bit of a "V" shape.  That’s not an illusion.  The screw holes in the claw are a *little* too close together and don’t quite match width of the servo.  You *can* get the two to work together, but do expect a little bit of squeezing and cramming.

Attaching the control horn to the claw:

I’ve noticed in the comments on Sparkfun  that a lot of people are trying to attach the loose "finger" of the claw to the little round plastic disk that comes with the servo.   The size and shape of the disk certainly make it *look* like it should hook up to the claw, but none of the mounting holes in the disk will line up with the screw holes in the claw.  One option would be to poke or drill new holes in the disk, but I found that the long flat servo control horn actually fits quite well on the claw with two of the little pointy screws included with the servo. 

Here’s a picture of the control horn mounted on the claw:


Putting it all together:

Now comes the hard part.  Putting the control horn (with attached claw "finger”) onto the servo drive shaft.  You’ll need to make sure the screws holding the servo are plenty loose at this point, and even so you’ll need to use plenty of hard squeezing and pushing to make it work.  But rest assured, it *will* go on if you keep trying.    Just make sure you have the gear teeth lined up correctly! 🙂

This is what it should look like once it’s all put together:


Attaching the servo to a breadboard:

What!? You mean we’re not done with obstacles?!  Well, actually… no.  There’s still a few more things we need to do to use the claw.  If you’re anything like me, the first thing you want to do now is hook the claw up to a breadboard.  The bad news is that the connector on the servo is just a *little* too deep for the standard break-away male headers that Sparkfun sells.  The short end of the headers just won’t go deep enough into the servo connector.  But, Sparkfun also sells some extra long breakaway male headers that will work just fine.  After you break away a three pin set of headers, the little plastic separator on the headers should push down, giving you plenty of room on both the breadboard side and servo side of the header.



Setting up a simple test circuit:

The logical next step is to setup a simple circuit to test our newly assembled claw.  Below is the breadboard and schematic views of a simple circuit I put together to test the claw:





This is a basic circuit that hooks the claw servo and two push buttons up to the Arduino.  Once built, copy the following code into a new Arduino Sketch:

// Controlling a servo position using two push buttons

#include <Servo.h> 
Servo myservo;  // create servo object to control a servo 

// constants 
int openButtonPin = 10;  
int closeButtonPin = 11; 
int servoPin = 9;
int openLimit = 0;  // can be set to limit the claw to its "safe" opening limit
int closeLimit = 170; // can be set to limit the claw to its "safe" closing limit
int stepInterval = 1;

int servoPos = 90;    // the current server position.  Change it to whatever position you want your claw to start out at.
int openButtonState = 0;   
int closeButtonState = 0;
void setup() 
  // open the serial console
  Serial.println("Begin Claw testing"); 
  // setup the input pins on the Arduino
  pinMode(openButtonPin, INPUT);
  pinMode(closeButtonPin, INPUT);
  // create the servo object
  myservo.attach(servoPin);  // attaches the servo to the servo object 
void loop() 
  // read the state of the buttons
  openButtonState = digitalRead(openButtonPin);
  closeButtonState = digitalRead(closeButtonPin);
  // if neither button is pushed or both buttons are pushed, do nothing
  if ( openButtonState == closeButtonState ) {
  // if the open button is pushed, open the claw by stepInterval
  if (openButtonState == HIGH) {
      servoPos = servoPos - stepInterval;
  // if the close button is pushed, close the claw by stepInterval
  if (closeButtonState == HIGH) {
    servoPos = servoPos + stepInterval;
  // make sure we don't try to open the claw further than it can go
  if (servoPos > openLimit) {
    servoPos = openLimit;
  // make sure we don't try to close the claw tighter than it can go
  if (servoPos < closeLimit) {
    servoPos = closeLimit;
  // sets the servo position according to the new value 
  // waits for the servo to get there
  // print the servo position to the serial console  

What this sketch will do is let you open the claw (by pushing one button), and close the claw (by pushing the other button).  While doing so, it’ll print the current claw position out to the Arduino serial monitor.  This is important, because the servo *isn’t* going to be able to move through it’s normal full range of motion while attached to the claw.  If you move the servo too far, it makes a continuous “humming” noise.  It’s quite annoying, and I do wonder if it’s bad for the servo to be constantly straining to open or close beyond what it’s really able to do.  That’s why the “Serial.println” statements are in there.  Use the position output in the serial monitor to figure out what’s the usable maximum open and close position are for your claw.  Then you can modify the “openLimit” and “closeLimit” variables at the top of the script to automatically stop the claw from trying to move to far.   Happy clawing!  Smile

Arduino Uno

Arduino Uno – First Impressions

I’ve decided to learn a little bit of electronics and possibly build a few robots with my sons. To that end I ordered an Ardunino Uno microcontroller, a breadboard, and some misc electronic parts.

I got the Uno, the breadboard and some breadboard jumper wires from Amazon in order to use a gift certificate I’ve had lying around forever. The rest of the stuff I ordered from Sparkfun, which is an electronics hobbiest store up in Boulder that seems to be pretty well regarded.

I got some LED’s, some resistors, a push button switch, a transistor, a diode, a servo, a light sensing resistor, and a pressure sensitive resistor. I also got a little aluminum robot claw type gripper that looked to cool to pass up. The servo I bought should mount up to the claw to move it, and I think I’m going to try to glue the pressure sensor to the claw to give it the ability to sense when it’s closing on something.

What the Arduino arrived, I was surprised at just how *small* it really is. For some reason it always looks bigger in the pictures I’ve seen on the net. Here’s a picture of it sitting on a dollar bill for size reference.

It was also very nicely, though minimally, packaged. No instructions of any sort though. IMHO, a quickstart guide that at least refers you to the website would have been a good idea.

I’ll probably take some pictures of the Sparkfun Claw soon. There are a lot of complaints in the Sparkfun comments about how difficult it is to mount the medium servo that’s recommend onto the Claw. I *think* I’ve pretty much got it worked out. I’ll take some pictures in the next few days and post some details on how I got it working. Maybe that’ll help a few other people.

My new venture (also, I’m BACK!)

I realized with some sadness today that it’s been over a year since I last posted on this blog.  😦  For some reason, my blogging interest tends to wax and wane over time.    Not a good thing really.

But in my defense, I *have* been pretty busy.  Aside from the usual things (raising 2 kids, my day job, etc), I’ve also recently been learning Java and how to program for the Android phone environment.   Damn, I never thought I’d say I’m learning Java.  :-).  Still can’t say I like the Java language, but I *do* like the Android framework.   In fact, I’ve just recently released my first application for Android.  It’s a customizable soundboard called ByO Board!

I do plan to start blogging again.   I’ve just overhauled the look of this blog (well, as much as I can overhaul it within the limits of the free WordPress plan) and I’ll hopefully be posting a few new things soon, probably on topics related to Android, but I’m sure some Emacs, Ruby, and IP Networking will slip in there as well. 🙂

Moving offscreen windows in MSWindows

Here’s an interesting tidbit.  How do you move a window that’s completely offscreen?

I run into this problem from time to time.  My work computer is a laptop.  When I’m in the office, I run it in dual monitor mode with my windows desktop extended across both my desktop LCD panel and the laptops built in LCD.   But of course when I’m away from my desk the laptop LCD is the only monitor.   You would think that Windows would be smart enough to automatically move all of the open windows around so that the ones that were on the no longer connected second monitor would be moved to the remaining monitor, but you’d be wrong.  This can cause an odd problem where the windows that were on the second monitor are no longer accessible!

The solution turns out to be this:

Right click on the task bar button for the application.  From the popup menu, click Move.  Then hit any one of the arrow keys on the keyboard.  That will cause the offscreen window to “snap” to the mouse cursor.  Now you can move it wherever you want!

Cygwin version of Ruby is currently broken

Apparently the version of Ruby in the current Cygwin Ruby package has a bug that breaks the latest version of Rails.

I decided to play round a little with Rails 2.0 the other day.  When I ran the “rails” command to create a new project, I got an error message about /dev/urandom (sorry, I should have written it down).   After doing a few google searches, I discovered it’s apparently a bug that’s been recently fixed in Ruby.  (see this bug report).   Unfortunately, the Cygwin package of Ruby still hasn’t been updated to the fixed version.

If you run Ruby under Cygwin, here’s a workaround until there’s an updated Cygwin Ruby package:

1) uninstall any gem’s you’ve installed (run “gem list –local” , then do a “gem uninstall” for each one.)

2) use the Cygwin setup application to uninstall the Cygwin version of Ruby.

3) while you’re in the Cygwin setup application, make sure you’ve installed the openssl-devel package.  If you don’t, Ruby will appear to compile correctly, but it’ll be missing crypto support that’s necessary for the latest versions of Rails.

4) download the latest stable snapshot release of the Ruby source.

5) untar the Ruby source to the directory of your choosing (I recommend /usr/local/src).

6) follow the instructions in the included README to install.   (./configure; make; make install)

7) Download the latest version of Ruby Gem

8) untar to the directory of your choosing (I still recommend /usr/local/src ).

9) follow the instructions in the included README to install ( ruby setup.rb)

10) use gem to reinstall any gems you need, like rails.

It actually takes a lot less time to do than it sounds like it would.  Hopefully there’ll be an updated Cygwin package soon, but until then, this is the best solution.   I did try to use the Ruby One-Click Installer for Windows, but using that under Cygwin is just an enormous pain in the ass.

More nails in the coffin of big, proprietary systems.

While I was going through the backlog of unread stuff in my feedreader, I came across two interesting items that I see as quasi-related. The first is a blog post from Allan Packer entitled “Are Proprietary Databased Doomed?”. In the post, Allan talks about a number of reasons why the big proprietary databases from vendors like Oracle, IBM, and Microsoft are doomed, which basically boils down to (IMHO) to 2 big things:

  • Proprietary databases are more expensive
  • Open source databases have gotten “good enough” to be feature equivalent to the more expensive databases for 80-90% of uses.

The second item that caught my eye was an article about the NYSE’s decision to replace it’s proprietary Unix server with commodity X86 servers running Linux.

What’s interesting to me about these two articles juxtaposed together is that, although they’re talking about two different product categories, databases in one case, operating systems in the other, the arguments in each case are virtually interchangeable. And in both cases, they paint a pretty bleak picture for the future of big, expensive, proprietary systems.

Network World’s clueless “electronic delivery”

Normally, I like Network World magazine, but I really have to laugh at the cluelessness revealed in this editorial about their new “electronic delivery” system.   At first I thought this was some kind of late April fools style joke, but they appear to be serious.   I’ll let their own words explain their “revolutionary” plan:

With iDemand, we send to you in background mode an entire issue of Network World as a PDF that automatically sizes itself to fit your screen when opened.

The way we deliver the PDF in the background is by asking you to install a small iDemand client. Besides saving you the trouble of downloading the PDF every week, the client lets you receive Network World breaking-news notices.

Err.. hello?  Didn’t push clients die with the ill fated (and stupid) Pointcast?  I’d love to know what kind of golf course deal suckered Network World’s management into wasting money on this idea, but it’s gonna fail miserably. Push clients suck. Nobody like them in the 90’s, nobody likes them now.

The truly sad thing is that Network World already *has* an electronic delivery system.   It’s called a web site.  And rather than waste money on this ridiculous push client, they really should spend some time cleaning up the design of their web site so that it doesn’t suck as much and so that you can actually *find* the articles from the print edition.

OpenMoko – $300 Linux powered touch screen phone?

Wired has a short article that looks at the upcoming OpenMoko Linux powered cell phone.  Unfortunately their coverage, like most of the coverage I’ve seen of the OpenMoko, is focused on comparing it to the iPhone.  IMHO that’s unfortunate.  As has been pointed out endlessly by the many rabid iPhone fans on the net, it’s unlikely that anyone, particularly OpenMoko, will create as seamless and slick an end user experience as the iPhone.  Probably true.  Apple’s good at that.

But the big limitation of the iPhone is that, unlike the BlackBerry and all the various Windows Mobile based smartphones, you can’t load your own apps on the iPhone.  That’s one of the reasons that I think the OpenMoko is really more of a competitor for the BlackBerry and the various other smartphones, rather than an “iPhone killer”.

I hope the folks behind the OpenMoko are smart enough to realize that in addition to the “geek” market, they should also be targeting the enterprise market.  With the right developer tools, and particularly if the OpenMoko becomes available in both the current form factor and a “ruggedized’ version, this could be an awesome platform for developing and deploying mobile enterprise applications.

As for the geek market… If the next version has 3G and a decent camera I’ll definitely be getting one.

Rails breakpoints broken?

Arghh… So I decided to do a bit of Rails programming today. While I was trying to figure out a small problem in my program, I decided to fire up the good old Rails breakpointer command only to get this error message:

Breakpoints are not currently working with Ruby 1.8.5

WTF? That’s it? No message about what the recommended alternative is? Gee guys that’s professional.

Luckily a few minutes searching on Google led me to a discussion of a reasonable alternative.

Hurray for Google searches! However, even thought it all worked out in the end, incidents like these cause me to wonder if people who claim that Ruby and Rails is still to immature might not be clueless luddites.

I won’t even start on discussing what a useless, outdated, spam-overrun waste of time the Rails Wiki has become….

Google ported Rails to JavaScript?

Apparently Google developer and blogger Steve Yegge has ported Rails to JavaScript.  I guess this this means we know what language Steve was referring to in his essay “The Next Big Language“.  This news also sheds some light on what Steve’s rather odd allegorical story “The Old Marshmallow Maze“.  It seems clear that the “floating platform” in the marshmallow maze story is his Javascript version of Rails.

I wonder if Google will release the source to this project?  I know I’d love to see it.  I like the idea of using the same language for both the client and server side.  And Javascript really isn’t a bad language.  Most people’s negative impression of Javascript stem  from the poor development environment available in the browser and the massive pain-in-the-ass that is the DOM.  Javascript is not the culprit, but it usually gets the blame.

But even if it is released publicly, will Javascript on Rails take off?  I don’t know.   There’s been at least one other attempt to create a Rails like framework in Javascript (TrimPath Junction) and  frankly, I’m not that impressed with the code sample listed on the TrimPath Junction web site.  Javascript just isn’t as concise and readable as Ruby.