Archive for the ‘General’ Category

LeapPad 2 on Ubuntu/Virtualbox

13 March 2016 1 comment

The developers over at LeapFrog have not supported Linux in the least – which sucks.  I found various articles on using VirtualBox, but none of them seemed to work.  At first, I hoped to get by without installing the software and connecting to a computer at all, but at some point the device got screwed up and would not boot without “a tuneup”.  I assume this repairs OS files that the kiddos somehow damaged by pulling the batteries during a filesystem write, or accidentally accomplished a boot-up key sequence that triggered the tuneup.

So here’s what I did to get it working on Ubuntu 14.04.

Rant first: I’m a little shocked at the technologies selected for the LeapPad – the hardware is actually pretty amazing for the price, but then they screwed everything over by selecting LAN over USB, Adobe Flash, and some other really bizarre software choices that practically guarantee a difficult time for most users, instead of a nice clean install and user experience.

This post partly borrows from some (IMO incomplete) UbuntuForums posts that talk about the same thing.

The instructions:

  • Install VirtualBox from Oracle’s website.
    • Download VirtualBox
    • Install using: sudo dpkg -i <filename>.deb
    • Download VirtualBox Extension Pack from the same page.
    • Install by clicking from the OS, or by running from the terminal: virtualbox Oracle_VM_VirtualBox_Extension_Pack-<VERSION>.vbox-extpack
    • Make sure users have access to the machine:
      • Some claim adding your user to the “vboxusers” group solves permissions issues – I simply run it as sudo.  Bad idea, I know, but when children’s hopes and dreams are on the line…
      • To be able to run as your own user instead of using sudo:
        sudo adduser USERNAME vboxusers
  • Download, import, and configure a free IE test virtual machine.
    • Download from
      • I used Win7 with IE10 – ymmv.  If you have a license of Windows, that would also be a good option.
    • Run VirtualBox (again, either as sudo or you must have added yourself to the vboxusers group).
    • Go to “File -> Import Appliance…”.  Navigate to the downloaded IE test virtual machine *.ova file and import it.  Run it through the normal settings.
    • Before running the virtual machine, we need to enable USB 2.0.
      • Right click on the virtual machine, and select “Settings -> USB”, and then click on USB 2.0.
      • Plug in your LeapPad and wait a few seconds for it to enumerate.
      • On the right hand side of the screen, click on the USB icon with the green “+” sign on it.  Find the LeapPad, and click on it to add a filter that forces it to pass through to the virtual machine.
  • Start the virtual machine, install the LeapFrog Connect software.
    • Open up IE once you’re in the machine and go to the LeapFrog Connect download page.  Select your device (I’m working on a LeapPad 2, so that’s download option I selected).
    • Install the software.  Pick the default settings.
      • When installing the Adobe Flash update, I HAD to install McAfee antivirus to get it to work – without it, the LeapFrog Connect software would not kick-start the Adobe Flash install, and would hang.
  • Remove McAfee and disable the firewall.
    • Go to “Control Panel -> Programs -> Uninstall Programs”, and select McAfee from the list.
    • Go to “Control Panel -> System and Security -> Windows Firewall”.  On the left, there’s a link that says “Turn Windows Firewall on or off”.  Turn OFF Windows Firewall for all locations, then press “OK”.
  • Run the LeapFrog connect software.
    • Once it’s all the way up, plug your LeapPad into the USB port and turn it on.
    • If your device doesn’t appear, right click on the USB icon at the bottom right of your VirtualBox window and select your LeapPad from the list:virtualbox_usb
    • IMPORTANT FOR TUNEUP: Watch this icon closely.  If the LeapPad appears to not be talking, right click on this icon and re-capture the USB device.  During the tuneup, it disconnected several times (5%, 35%, and 80%, IIRC) and as long as the USB device was reconnected before the process timed out, the progress bar would continue.
    • During normal operation, it seemed to just work fine – only during odd operations did it crap out on me and I’d have to watch it closely and reconnect.
  • We’re done – Take a snapshot so you can come back to it after the 90 day trial expires on the IE virtual machine.


Hope this saves someone else hours of time figuring it out while their child is bawling on their shoulder!


Categories: General


14 June 2012 21 comments


I’ve Made Some Special Modifications Myself

My current mode of transportation is a quasi-beat up, hot red Kymco ZX50 scooter.  Let’s face it – if it doesn’t look like much on the outside, you’d better make some special modifications yourself.  In comes Bluition.


The Run Down

Bluition is a bluetooth ignition device that allows me to control my scooter from my Android phone.  Here’s the run down:

  • My Droid 4 runs a program called Tasker.  Tasker is an AMAZING program that can run applications or other actions given specific events or states.  I’ve put instructions for it to call a specific Python script given a specific gesture is detected.
  • Python for Android provides a very simple scripting system.  It was amazing how few lines of code were needed to open up a Bluetooth connection and send commands to the bluetooth module on the scooter.
  • An RN-42 Bluetooth module from SparkFun receives the commands from the Android phone.  The commands include instructions to set GPIO pins high or low.
  • The RN-42 outputs are then connected to MOSFET drivers, which in turn drive mechanical relays.  Again, SparkFun parts.
  • The mechanical relays are connected into the scooter ignition, starter as well as a solenoid that pops opens the seat lid.
  • The solenoid was purchased from SparkFun also.  While it provides precious little force, I managed to eek just enough out of it to pop the scooter seat lid (which encloses the glove/helmet storage compartment) by connecting the solenoid plunger to the connector up through a bowden cable.
  • And foot bone is connected to the knee bone…

The setup was pretty simple and done dirt cheap – see the bill of materials below.  My favorite part was that I didn’t have to use a microcontroller.  As much as I love microcontrollers (my day job is firmware programming), it was nice for a change to be able to just focus on electronics and wiring.

This setup could be used for just about anything that just needs an on/off relay with the actual programming to a smart phone.  I’m sure if Han had one, he’d totally be scripting his droid to automatically control a mog feeder on the Falcon.

In the interest of time, I’m not going to fully comment how I made it.  If there’s enough interest (leave a note in the comments), I’ll draw up an Instructables tutorial on how to connect it and possibly even make pre-assembled kits.  Hopefully I’ll give you enough info below that if you have some experience you should be able to put it together without much trouble.


Bill of Materials

Let’s start with a BOM.  Links provided where available.  Some components were just lying around.  My SparkFun order for the parts I didn’t have was only $50, but the total is probably around $75-$100.



  • Socket wrench and set
  • Socket drivers
  • Pliers (regular and needle nose)
  • Wire cutters & strippers
  • Crimp tool
  • Soldering iron
  • A butane soldering iron was particularly handy when soldering on the scooter itself (but there are other ways)
  • Phillips and Flathead Screwdrivers
  • Allen wrench set
  • Power drill and bits, preferably with a step drill



All told, I spent about three full weekends on this.  Now that it’s all figured out, if I had a PCB already built and the wiring diagram it would probably only take a rainy Saturday to do.


Build Pictures

Here are a few pictures that I took throughout the build process.  I have more, but these are a decent overview.


Build Notes

A few notes about individual items.

The Scooter

The goal was to keep the original scooter electrical setup intact so I’m not screwed if (when?) the electronics get a bad spike, water shooting into the console, etc. and blow up.  I mostly succeeded – at least I know I could use the scooter without the Bluition module if necessary.

Over half of the scooter exterior had to be removed in order to get access to all the wiring needed.  Things that came off: The front, the handlebar covers (still hanging there by control cables and wires, but all screws & bolts were out), the seat, storage compartment, carrier rack, and seat latch.


The wiring was pretty straightforward, except for the ignition.  I’m no grease monkey, so this is my simple interpretation of the mechanic’s manual and various forum postings:  +12V gets connected, obviously.  But there was another connection that was grounded when the ignition switch was in the off position, then left floating when in the on position.

My (frail) understanding is that it grounds the Capacitor Discharge Igniter, which removes sparkability from the spark plugs and forces the engine to die.  If I didn’t connect this, I could start the scooter but the engine kept running when the ignition signal was removed.  You’ll notice there’s an extra relay in the pictures that looks like it was added haphazardly as an afterthought – bingo.

The starter was simple – there’s a starter switch on the handlebars.  Simply used tap splices, and connected both sides to a relay in parallel with the starter switch.

The solenoid relay just sucked power from the +12V rail.  Easy peasy.

I ran a Bluition power switch (sealed rocker) up to the handlebars so that, when not in use, the Bluition module wouldn’t suck the battery dry.

Seat Latch Solenoid

This was pretty tricky.  It boiled down to lubricating the Bowden cable well with silicone grease, and getting the Bowden cable entry and exists as parallel as possible with the path of the solenoid and latch.  On the solenoid side, I removed the spring and plastic washer and put a ball of solder on the cable to hold it in place.  The extra-hot butane soldering iron was helpful with this.

On the latch end, after trying many approaches I ended up just zipper tying the cable to the existing key-triggered cable.  I also zipper tied the solenoid to the chassis outside of the storage compartment area, and zipper tied the Bowden cable itself to places where it held the cable in locations that allowed parallel entry into the sleeve.

Bluition Installation

Running wire all over and getting all the signals wasn’t too bad.  Labeling the wires as I ran them helped a ton.  It was really nice using the tap splices over soldering.

The module itself was installed in the “glove box” console area.  I mounted each component onto a plastic sheet using foam tape, and then mounted the plastic sheet onto the inside of the console.  I had every intention of using Sugru to encapsulate the module, and I may still do so.  But until I know it’s going to work reliably I’ll hold off.

RN-42 Bluetooth Module

I was blown away at how cheap this sucker was – and it worked like a charm too!  Dead bug soldering was a bit of a pain, but not too bad.  I’ll post a schematic at a later date to show which wires went where, but just look at the data sheet – any of the PIO pins 7 or below can be used.  I couldn’t get PIO pins 8-11 to work – the datasheet says some modules don’t have these, and I can only assume this is one of them.  They can provide a few milliamps each, but they work just fine driving the MOSFET gates with a 120 ohm resistor in series.


Python Environment and Code

First, let’s talk about the environment.  BTW, it was WAY easier to get things working here than it was on my laptop in Ubuntu.  Here are the Android apps that I’ve used to make things happen:

  • Tasker– This program automates your smartphone in so many ways.  I set it up so that if I shook the phone in one of three axes, a Python script that performed a specific action occurred:
    • Front to Back Shake: Start the scooter
    • Up and Down Shake: Stop the scooter
    • Left to Right Shake: Open the seat lid
  • SL4A: Scripting Layer 4 Android is a program that provides a common layer for many different scripting languages so they can be ported to Android.  Python for Android is an interpreter used by SL4A.
  • Python for Android – Python interpreter used by SL4A to let us run the scripts.

Now for the fun part – code!  I was amazed at how simple it was in the Python for Android environment.  I think you will be too.  Before starting, make sure you’ve paired your Android phone with the RN-42 module through the “Settings -> Wireless and networks -> Bluetooth” menu.

Then, you can run scripts like the following that open up a Bluetooth connection, then enters command mode, then sends a GPIO command.  Easy peasy.  The following script is called

import android
import time

droid = android.Android()

# Over-the-air commands that modify the GPIO pin states on the RN-42 module.
IGN_ON = 'S&,1808\r' 
IGN_OFF = 'S&,1810\r'
SEAT_ON = 'S&,4040\r'
SEAT_OFF = 'S&,4000\r'
STRT_ON = 'S&,9080\r' 
STRT_OFF = 'S&,9000\r'
INIT_DDR = 'S@,D8D8\r'
print "Enabling Bluetooth..."
print "Connecting to scooter RN-42 module..."
# Change the X's in the following line to match your MAC address.
droid.bluetoothConnect('00001101-0000-1000-8000-00805F9B34FB', 'XX:XX:XX:XX:XX:XX')

print "Entering command mode..."
res = droid.bluetoothReadLine()
print res

print "Initializing PIO direction..."
res = droid.bluetoothReadLine()
print res

print "Sending ignition on command..."
res = droid.bluetoothReadLine()
print res

print "Sending starter on command..."
res = droid.bluetoothReadLine()
print res

print "Sending starter off command..."
res = droid.bluetoothReadLine()
print res 


Just write up a script with the basics of the above script in it, run it in SL4A, and it will toggle GPIO pins on the RN-42 module.  See the RN-42 user’s manual for more info on the GPIO commands, and the Python for Android documentation for more info on the Android API.


In Conclusion

In the altered words of Jack Handy:”If you ever get the chance to choose between regular heaven and Bluetooth heaven, choose Bluetooth heaven.  It may be a joke, but if not, mmmm boy!”


Categories: General

FIX: Include error in Eclipse after upgrading GCC

Just writing a quick post today. I’ve had an error for quite a while that’s been bugging me, and I finally got around to figuring out how to fix it. It’s kind of like when your copilot gets fleas – it bugs you, but sometimes you just deal with it because of more pressing issues.

I was trying to work around a problem a while back that I though would be fixed by upgrading the version of AVR-GCC I was using. While I got the new version working (4.3.5), it had removed the old version (4.3.4) and for the past few months I’ve constantly had to ignore warnings about not being able to find include folders.

The error was something like:

"Include path not found" /usr/lib/gcc/avr {version specific etc...}

The fix is pretty simple.  I found the solution here, but I didn’t follow it exactly.  It asks you to delete the following file – I didn’t want to risk losing any workspace settings, so I modified it instead.

  1. Open up your workspace.
  2. Open the file:  ${workspace}/.metadata/.plugins/org.eclipse.cdt.make.core/${projectname}.sc
  3. Find all the references to your old library path.  I found three references near the top of the file – simply delete those lines.
  4. Restart Eclipse.
Categories: General, How-To Tags: , ,

Life Update and Checkerbot Follow Up

Wow, it’s been altogether too long since I’ve posted.  Fortunately, and this is important, I’ve been able to spend a lot of great, quality time with my family.  We recently had a great time at the Oregon Beach and at the A.C. Gilbert Children’s Museum since my return from interning at the Robotics Institute at Carnegie Mellon University. (No, really, I was there!)  I’d been away from the wife and kid (“kids” including the one due in September!) for about a month, and it was great to be back.

For just a paragraph or two, I’ve gotta spill some philosophy.  Even before you have a family, and especially after you start one, hopefully everything you’re doing is for their current or future benefit.  There is nothing that can replace the fulfillment of a loving family, and like all great things, it requires preparation.  An interesting point of fact that is that Sam Walton, someone who spent his whole life innovating and who founded the largest retail chain in the world Wal-Mart, determined that he failed in life.  His last three words, given on his death bed while surrounded by his family that he hardly knew, were “I blew it!”

No one’s perfect, it’s just important to be making progress rather than regress.  New goal in life for me: Don’t blow it.  I gotta make a little bit more effort in that area, and I’m thinking even just a random act of kindness or two a day for the people I love will help.  Now, go to your room and think about it for 10 minutes, then come back and read the rest of my post. ;)

Me standing next to Boss, winner of the 2007 DARPA Urban ChallengeI had an amazing time at the Robotics Institute.  That’s me next to Boss, the autonomous Chevy Tahoe that won the DARPA Urban Challenge a few years back.  It drove itself, without collision and following all normal traffic rules, through a 60 mile urban obstacle course.  It is one of the most famous robots alive.  Boss vs Brad: Brad loses.  Boss vs Millenium Falcon: I’d love to see that show up on Youtube…

I got to work with a great group of people on a really fun, agriculture related robotic project.  I’ll probably share more on that in the future, but it’s not for me to talk about yet ;).  Most of the people around me were working on the Google XPrize project, and it was awesome to see that and other jaw-dropping amazing projects in the bay I was in.

I’d like to share a follow up post on how the checker playing robot went.  It was pretty fun, albeit stressful.  We knew at the outset that the chances of successfully navigating this project was 3,720 to 1, but we decided the risk was worth it.  Plus, we figured we could call the support desk to help us get through any ID10T errors.

The robot was based on the new XMega AVR processor.  It has quite a few more features than the standard AVR chips, which also made it a bit more difficult to use.  I recommend AVR processors highly, but unless you need functionality only provided by the XMega series, I would recommend most beginners stick with AVR chips from the ATMega series.  This project, however, needed the higher processing power, the larger RAM, and the higher flexibility of peripheral hardware offered by the XMegas.

I don’t want to repeat too much of the description of the design and process that my lab partners and I went through to do this project – it’s already available on the project website here.  You can download the SolidWorks CAD, EagleCAD, C code, and other project files from there.

So it wasn’t quite capable of playing checkers at the end of the term.  Our grades took a bit of a hit because of that, too, but it was great to try something new and the reason for this design is as follows:  We tried tackling this problem from a user’s point of view, which is something I believe is left out of academic and commercial projects all too often.  Who likes to play checkers?  Children and old men in the park.  Most other robots in the class were gantry or industrial robot arm based and relied on a laptop tether to function, which could never be practical when used by children or the elderly for safety, expense, and ease of use reasons.

Our robot weighed in under a pound and was, at least theoretically, easy to use and setup.  It used AA batteries and would be safe for anyone to use, and not expensive to replace if broken.

Now, if only it had worked :D.  The robot performs computer vision by reading images in from a UART based camera directly into the RAM of the XMega.  The XMega then determines where the checker pieces are at, calculates moves, and then goes out onto the board to execute those moves.  We fell just short of what was needed for full functionality in most areas due to lack of time and lack of experience with certain components.  As you’ll see in the video, poor motor control and localization was the primary point of failure.  Check the project website for a more detailed synopsis of what worked and what didn’t.

In this video, the robot has just captured an image and is moving from the image capture location to the checker board to make a move.  All decisions were autonomous, but the bot was stepped through its motions one step at a time and assisted when its localization or movements were out of place.

XMega Solution for Kubuntu

29 April 2010 5 comments

Howdy folks.  For any penguin heads out there trying to get an XMega development setup for Linux, I finally got it working, and didn’t even have to compile anything!

My setup is a SparkFun XMega breakout board ($25) and an AVRISP mkII programmer, which I bought from Mouser (~$35) specifically for the new PDI programming.  Seems Atmel ditched the venerable ICSP programming method with these new chips.  The AVRISP mkII can program over the new “Programming and Debugging Interface”, but can’t debug.  If you want to be able to debug over the PDI interface, go for the JTAGICE mkII or another programmer.

I’m running Kubuntu Linux 9.10.  This solution probably won’t be all that useful for that long, because I imagine (but haven’t checked so I don’t know for sure) that Kubuntu 10.04 will have these updated packages.  Regardless, some of the advice that follows will still be pertinent to some people.

So here’s what I’m going to do: Set up my Kubuntu 9.10 installation to be able to compile for XMegas using AVR-GCC, program XMegas using AVRDude, and use Eclipse as an IDE for all this.

Install AVR-GCC and AVRDude

Since the packages in the Kubuntu 9.10 repository aren’t up to date enough to work with the XMega, we’ve got to get them from somewhere else.  I default to the Debian repositories, which 9/10 times work with Kubuntu.  I’m not sure if there are other packages you need installed, because I started with a working standard AVR and GCC development environment already working.  If installing these packages complains about dependencies (beyond those in the list below), using “apt-get” to install them from the normal repository should be fine.

Download the following “squeeze” packages for your system from here:

NOTE: Just install these from the repository using apt-get if using Kubuntu version 10.04.

There’s a specific order you have to install these in – I can’t remember exactly what it is.  Right click on the files in Dolphin (or, as I prefer to use, Konqueror) and use the GDebi package installer to install these files graphically, or dpkg to install from the command line.  Once these are installed, you can compile and program your XMegas from the command line!

Install Eclipse and AVR Plugins

Eclipse has some features that I’ve heard are pretty nice.  Traditionally, I’ve used and really liked KATE (KDE Advanced Text Editor), and recently I’ve gotten hooked on VIM, but I’m not a bigot about things I haven’t tried.  So here’s me trying Eclipse for AVR programming.

First stop, install Eclipse.  You’ll want Eclipse CDT, which is geared towards C/C++ development instead of Java.  You can download it here.  Install it by extracting it, pretty much anywhere.  I installed it into my development tools folder – another standard place is the opt folder (/opt/eclipse).  Further instructions on this can be found on this UbuntuForums post.

Once Eclipse is installed, you’ll want to add the AVR plugin.  Follow these instructions.

Start a New AVR Project

To start a new AVR project for an XMega, follow these steps:

  1. Click “File -> New -> C Project”
  2. Enter a new project name, and under the “AVR Cross Target Application” select “Empty Project”.  AVR-GCC Toolchain should be selected on the right side.  Click “Next”.
  3. Click “Advanced settings…”
  4. Click the “AVR->AVRDude” option on the left.
    1. Under the “Programmer” tab, select your programmer.  If it’s not in the list, or the list is empty, click “New…” and select your programmer.  For me, it was “Atmel AVR ISP mkII”.  Click “OK”.
    2. The rest of the options under the tab should be left with defaults.
  5. Click the “AVR->Target Hardware” option in the left pane.
    1. Select your processor.  For me, the “ATXMega128A1”.
    2. Select the frequency your processor will run at.  For me, 32MHz.
  6. Click “C/C++ General->Indexer”, then click the link on the top right titled “Configure Workspace Settings”
    1. Check the “Index unused headers” option.
    2. Check the “Index source files not included in the build”.
    3. Check the “Allow heuristic resolution” option, then “OK”.
  7. Click “Next”.
  8. Select your MCU type and frequency (again, I know…)
  9. Click “Finish” to create the project!

Setup Auto Programming

I think there’s another way to make this happen, but I couldn’t figure out how to make it program the chip.  So I did the following as well:

  1. Click “Run->Run Configurations…”.
  2. In the “Name:” box, type “Program Chip”.
  3. In the “C/C++ Application:” box, type “/usr/bin/avrdude”.  Make sure the “Connect process input & output to a terminal” is checked.
  4. Under the “Arguments” tab, type the following: “-c avrispmkii -p x128a1 -P usb -e -U flash:w:Debug/<project-name>.hex”
  5. Click “OK”.

Now at this point clicking the “Run” button on the toolbar (or its shortcut, Ctrl-F11) will program the chip.  We’re not out of the woods yet, though.  By default, a program needs root privileges to access USB devices.  So when you hit Run, it will ask you to enter your password (which will, stupidly, appear in plain text).  To make the AVR-ISP mkII programmer available to mere mortal (non-root) users, do the following:

1.  Open a terminal.  Start a text editor as root to create the file “/etc/udev/rules.d/50-usbavrispmkII.rules”.  For example:

> sudo kate /etc/udev/rules.d/50-usbavrispmkII.rules

2.  Paste the following into the editor:

SYBSYSTEM=="usb", SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2104", GROUP="users", MODE="0666"

3.  Run the following command in the terminal:

> sudo udevadm control --reload-rules

Now there’s no need to enter the password!  To recap, to build without programming hit “Ctrl-B”.  To build and program, hit “Ctrl-F11”.

That’s about all I can think of for settings I use, but if I think of anything else I’ll update the post.

An update to the post:

I found a little item I forgot.  In order for Eclipse to output a hex file (needed for the above instructions to work), you need to go to the project properties -> Settings, then check “Generate HEX file for Flash memory”.  Hit the build button again, and behold the appearance of a hex file.


A very nice feature Eclipse has is that it hyperlinks variables,  functions, and defines when you hold the Ctrl button and click.  For files within your project, it works pretty nice, but usually you already know most of those well because you wrote them.  Step 6 above allows the  indexer to look through the AVR include folder as well.  This makes any standard definition of a port, register, enum, or struct (of which there are many) easy to find.

Also, you don’t have to manage your makefiles.  Eclipse will take care of all that for you, so you just have to worry about programming.  One thing I haven’t figured out yet is how to get it to get the equivalent of  “make clean && make all && make program” happen, which I typically use when doing AVR programming.  I periodically have to use the “Clean…” menu option when things start acting strange.

As a side, make sure to check out the XMega app notes on the Atmel website, and download both the PDF and the source code.  I’ve found myself primarily using their drivers, which has really sped up getting started with this chip (even though the drivers do have their limitations).

Happy programming!  I imagine this post will be the cause of a lot of late night hacking and Mtn Dew sales …

Hacking Tiny Servos

Thought I would blog about hacking the 9g servos from SparkFun and converting them to continuous rotation since I’m performing said hack for an upcoming project.  I’m sure there are more and better instructions on how to do this, but I’ve looked at tutorials before for larger servos and noticed these little guys are a bit different.

What I’m doing is changing a servo that normally has around 90-120 degrees of motion to have full 360 continuous rotation.  Instead of the servo reacting to the standard PWM signal as a position signal, it will now act as a velocity signal with full forward/stop/reverse control!  Best of all, when people tell you the servos on your YT-1300 look like a piece of junk, you can tell them you’ve made a few special modifications yourself.

Apology in advance for the images – I promise to never use my cell phone cam for blogging again!  It’s abysmally unfit for close up pictures of electronics.

Take the servo apart

The black circular piece with the shaft in it, next to the gears, is the potentiometer. Two stops are there, two more are on the case piece to the left of it.

Remove the sticky label (goo-be-gone is needed) and remove the screws.  You’ll likely need a jewelry screw driver.  Pull all three sections apart, remove the gears, and remove the white plastic cover over the potentiometer.  Easy peasy.

Cut out the stops

I’m running on memory, so feel free to correct me in comments if I’m wrong.  I recall this as the part that’s different from the standard sized servos.  There are stops on the potentiometer and you practically have to cut out half of the pot to get it to rotate properly.  This is because the pot shaft is used as the axis for the gears and external drive shaft.  Boo to the man that designed it this way, unless it made it significantly cheaper.  In that case, yay… but boo.

Warning: The plastic on the pot is EXTREMELY brittle.  If the pot case crumbles, your servo is trashed.

Proceeding onward.  You’ll see two plastic stops in the pot – cut it out in small pieces.  Once that’s gone, you’ve got to remove the potwiper.  The copper-colored middle terminal of the pot should come out with a little force at this point.  There are a couple of “C” shaped metal tabs that will come out with it.  Now cut the entire terminal off and leave the wire hanging for now.

On one of my servos, I cut it out without pulling the shaft out.  On another, the shaft hole cracked cand the whole shaft came out which made this easier – but I’ll have to report later as to whether it still works well or not.

You also need to cut out the springy piece.  You can’t remove it completely, it appears to be connected with the shaft itself, so you’ll need to cut it flush against the remaining metal flange.

The final stop that has to be cut is on the actual case, just inside the hole where the shaft exits the case.  Flush cutters make quick work of this, but an Xacto knife could probably work too.

Solder resistors in place of pot

With the middle terminal removed and cut off, solder resistors between the two terminals and then solder the middle terminal wire to the middle of the resistors.

So that the potentiometer has a reference point for its control loop, we need to solder resistors in place of the pot.  I used two 10K resistors, which will make the signal that would have centered the servo be the stop position.  Positions signals right from the signal will be forward, and positions left from the signal will be reverse.

Solder the two 10K resistors (surface mount or 1/8W or smaller should fit) in series between the two remaining posts.  Then solder the currently-floating middle terminal wire in between the two resistors.

Put the servo back together

Pretty straightforward.  Do step one in reverse.  The gears may feel like a puzzle, but there’s only one way they fit.  Lastly, be careful with the screws – they strip out pretty easy.

Shazaam!  Full control of a motor with great torque/gear ratio with only a half hour’s worth of effort.

Catch up…

13 April 2010 3 comments

Looks like it’s been a while since I’ve posted, but not to fear – my projects never cease.  In fact, they seem to spread faster than lice on Kashyyyk.  Here’s what I’m up to right now, and what’s coming up for those of you who have been following the ZephyrEye project.

First, here’s what I “have” to be working on right now.  I’ve enrolled in the ME414 “Mechatronics” class here at OSU, where interdisciplinary groups of three CS, ECE, and ME students have to put together a checker playing robot.  Seriously!  It has to autonomously play checkers not only against humans, but other robots.  At the expense of my other relatively boring classes, this one gets most of my spare time.  I’ll keep you posted on how it’s coming, as there’s some overlap with other projects – in particular, I’ll be using the XMega controller on this project and I’ll be posting some tips on how to get started (as I’m figuring it out, no less ;).

Back to the ZephyrEye.  I’m currently working on the project with a kit manufacturer and we’re making good progress.  No promises of any kind, but I’m currently estimating they will be on shelves by this summer.  Oh, the heaps of gold I could have made if only I hadn’t open sourced this project ;).  Can’t wait to start coding this sucker up, make sure and sign up for the Google Code project if you’re interested in helping out!

Hopefully my summer schedule lets me work on the project!  It’s getting full.  I’ve landed an exciting internship at the Robotics Institute of Carnegie Mellon University, so I’ll be racking up frequent flier miles going cross-country to Pittsburgh.  Exciting stuff, I get to work with and get to know some crazy smart people who design bleeding edge robots.  I’ll be looking for the secret to the universe in the bookshelves, for sure …

And, the missus and I are expecting baby #2 in September.  Yay!

Categories: General Tags: