CHDK’s remote USB trigger functionality works by detecting when it receives power over USB.  This happens when two wires inside the USB mini-B cable are connected to power: the red wire gets 5 volts, and the black wire gets connected to ground.

So, I chose to find somewhere on the MakerBot’s electronics to hook up these power and ground wires such that the MakerBot could control when the red wire receives 5V.  The MakerBot uses RepRap Generation 3 electronics, and let me tell you, the gen 3 electronics documentation is fantastic!  Unfortunately, the docs for the main motherboard reveal that there are some free I2C headers for connecting serial devices, but no free general I/O pins.

Luckily, the extruder controller docs show two free digital pins, conveniently broken out with 5V and ground connections next to them.  These are digital pins D9 and D10.  According to the docs, they are intended for hooking up servo motors, but they would absolutely work for my purposes!

The layout for pins D9 and D10 goes (from left to right): I/O pin, 5V, ground.  Since I wanted the data pin itself to provide the 5V, I chose to make a cable using a 3-pin piece of female header, soldering the red wire connecting to the I/O pin (on the left) and the black wire connecting to the ground pin (on the right).  The center pin has no connection.  You can see my “super fancy” cable on the left.

I know this post isn’t particularly about code, so stay tuned for the next parts of this series:

• Part 1: Remote control camera with CHDK
• Part 2: Wiring it up! [YOU ARE HERE]
• Part 3: Updating the MakerBot Firmware
• Part 4: Updating ReplicatorG
• Part 5: Updating Skeinforge

It recently occurred to me that, since the MakerBot is such a hackable platform, I could probably make nice time-lapse videos by taking a picture of each layer.  The idea is to have the MakerBot pose the object after each layer, and trigger a camera to take a snapshot.

When discussing this idea with fellow HackPittsburgh member Matt Mets, he recommended I try out a Canon camera with the Canon Hack Development Kit (CHDK).  Making a quick stop on eBay, I soon had an SD300 in my hands, ready to be hacked!

I started by figuring out which firmware my SD300 was running, which told me which version of CHDK to download for my camera’s particular model/firmware combo.  Using an SD card reader, I copied the contents of the CHDK zip file onto my camera’s SD card and followed the instructions to make CHDK auto-load when the camera starts up.  I also changed my CHDK firmware settings to set “Disable LCD off” to “[Script]“, so the camera wouldn’t shut down on its own.

Once CHDK was loaded and configured, I followed the USB Remote Cable instructions from the CHDK wiki.  The basic idea is to set Enable Remote to on, and load a script that is ready to handle USB remote events.  The one on the wiki page didn’t work as-is for me, presumably because my camera has half-shoot (i.e. focus and charge flash) and full-shoot (take picture) settings.  Here is the result that worked for me:

As the script says, I now turn the camera on in record mode, disable the flash, and start the script.  After that, the camera will automatically take a photo whenever I plug in the USB to my computer.

Next steps for this:

• Hack a USB cable so a microcontroller can trigger the camera
• Figure out a way to mount the camera to the bot
• Hack the bot firmware (and maybe skeinforge and maybe ReplicatorG) to:
  • Pose the build platform
  • Trigger the camera

Googling for things like “open source face detector” doesn’t come up with much.  The landscape seems to be comprised of mostly expensive for-pay libraries written for Windows, abandoned research projects, and lots of research papers full of equations — but no code that I could get to run.

To make a long post short, it turns out that Intel’s OpenCV computer vision library comes with a face detector example that should work out of the box.  Better yet, there are now some decent Python bindings for OpenCV that come pre-packaged with OpenCV for Ubuntu and Debian.  You can install them with:

$ sudo apt-get install python-opencv


Now, it seems that most OpenCV face detector examples are meant to be run “live”, usually taking the image from a webcam and highlighting faces with a red box in real-time.  However, I have a large database of static images that I want to consider individually, and I simply want to save the face coordinates for later use, rather than altering the picture.

So, with a bit more Googling, I found a Python script that I could chop up and use for this purpose, and here is what I came up with:

An example run of the script looks something like this:

$ python face_detect.py marty_mcguire.jpg
[(50,36) -> (115,101)]


You can overlay that rectangle on an output image with ImageMagick’s “convert”:

$ convert marty_mcguire.jpg -stroke red -fill none -draw "rectangle 50,36 115,101" output.jpg


And the output might look something like this:

Pretty fun stuff!

When a recent Make blog article showed nearly step-by-step instructions for building a breadboard-friendly Arduino clone called the Boarduino, I felt compelled to order one and try to get it working with my new MacBook.

I ordered the DC Boarduino kit from LadyAda’s website, along with the USB TTL-232 cable that would connect to my laptop’s USB port. I also ordered the 9V power supply on the site to power the Boarduino.

I found building the Boarduino to be pretty easy (=ahem= with only one screwup on my part) thanks to LadyAda’s detailed instructions. It was the first soldering project I had done in awhile, so I am happy that it went so well.

I next looked to the Arduino OS X guide for the software download and installation instructions. I ended up grabbing version 11 of the Arduino software. After unpacking the .zip file from the site, I installed the FTDI driver and rebooted, then plugged in the Boarduino’s power and connected it to the laptop via USB.

Next, I double-clicked the Arduino application to start it, and nothing happened. After messing around with it on the command line for awhile, I determined that it didn’t like the version of Java I’m using (I have the 64-bit version of Java 6 as my default).

So, to run the Arduino software, I had to temporarily set my preferred Java version to 5.0 via the Java Preferences panel in /Applications/Utilities/Java/. Once I had changed my Java version, the Arduino app started right up with a double-click. Once I was done with the app, I could set my Java preferences back to Java 6.

In the Arduino app, I set it up to communicate with the Boarduino by selecting “Arduino NG or older w/ ATmega168″ under the Tools | Board menu. I then opened up the Blink test program under File | Sketchbook | Examples | Digital | Blink. To load the program onto the Boarduino, I pressed its reset button, then quickly clicked the “Upload to I/O Board” button on the interface.

The red LED on the Boarduino blinked rapidly as data was received, then it started blinking slowly as it ran the Blink program! Hooray!

I’m excited that it’s so easy to get something as powerful and versatile as the Boarduino up and running in just a couple of hours. I’m going to try and think of a couple of projects for it. Whatever I do, I’ll be sure to post about it here.

One thing I noticed early on was that pressing Tab to move around various interfaces, from Finder dialogs to web pages, would only tab to text entry fields. Coming from a primarily Windows background, I am used to tabbing my way to checkboxes, dropdowns, and buttons in my interfaces, so this crippled Tab navigation quickly became annoying.

Thanks to this blog post, I found the option to make Tab move through “All Controls” in System Preferences | Keyboard & Mouse | Keyboard Shortcuts

Another big issue I came up against is the weird Java support that comes with OS X. Because Apple releases their own versions of Java, we OS X users are kind of at their mercy with respect to what we can use and how we can configure it. You can install Java 6 from Apple’s download page, but Java 1.5 will still run by default.

Apple provides a “Java Preferences” configuration utility in /Applications/Utilities/Java/ which lets you change the default version of Java that will be used in browsers and when double-clicking to launch Java apps. However, this utility doesn’t change which version of Java will be found by command-line apps in the terminal, such as Apache Ant.

Another blog post to the rescue! It turns out that you can change your default version of Java for command line apps freely by changing the CurrentJDK and Current symlinks in /System/Library/Frameworks/JavaVM.framework/Versions/. For example:

    cd /System/Library/Frameworks/JavaVM.framework/Versions
    sudo ln -fhsv 1.6 CurrentJDK
    sudo ln -fhsv 1.6 Current

Hopefully this post will be able to help others (or at least my future self).

1. Updated rubygems to 1.1.1 with sudo gem update --system
2. Installed the 32-bit (x86, NOT x86_64) version of MySQL (community edition, of course) via the installer on the MySQL download page.
3. Installed the native MySQL driver for Ruby (this was tricky, see below)
4. Finished by installing Rails and its friends via gem install rails

Getting the speedier native MySQL driver for Ruby installed was tricky for two reasons. It seems that by default the installer attempts to compile for 4 architectures, so you have to set an environment variable and pass along a parameter to point to the installed copy of MySQL when calling gem:

sudo env ARCHFLAGS=”-arch i386” \
   gem install mysql -- \
   --with-mysql-config=/usr/local/mysql/bin/mysql_config

If you’ve never seen it before, the ‘–’ after ‘gem install mysql’ means that gem should pass along the next arguments to the programs it uses to build the driver.

The reason for installing the 32-bit version of MySQL (on your fancy 64-bit OS and machine!) is that the version of Ruby that ships with Leopard is apparently 32-bit only. Yikes.

I’ve noticed several little annoying details like this in getting other things to work “like I like” on OS X. I’ll probably end up posting more about them in the next couple of posts.

I know that “how to” posts of the form “I wanted to do X, but Y happened. Finally I fixed it by Z,” are pretty boring. Still, I hope they are useful for preserving the knowledge of how to work around these problems, both for myself and for others.

• Cheap beer seems to follow us around for some reason, but we drink it anyway.
• Google’s I/O Conference happened this week, and many interesting (though not life-changing) announcements were made, including
  • A new Google Earth API/Plugin which integrates with their existing Maps API and brings all of those KML files and third-party 3D models and data to the web.
  • Google AppEngine went ahead and let everyone in from the waitlist, announced new pricing competitive with Amazon’s EC2, and a new Memcache API which should allow for faster (and cheaper!) performance. There doesn’t seem to be any improvement to ease of development, however.
• Adobe has announced 3D hardware support in Flash 10, but it’s Windows-only at the moment. For a “universal” platform like Flash, what will come of this feature and other Flash 3D engines like Papervision3D?
• Loren has finally upgraded many of his projects to Rails 2.0, encountering a few challenges
• I’ve been exploring lots of Rails deployment options (such as Nginx, Mongrel, and Thin) but I’m most excited about using the new Passenger (a.k.a. mod_rails) plugin for Apache. Dreamhost seems pretty excited, too.
• Loren has upgraded his video-on-the-web service from Justin.TV to Stickam, and has been working on new ways of bringing video to his investment club, Ben Hur Investments. Look for them, soon!
• Embedding and remixing are becoming new themes for text, audio, and video on the web. We talk about several services their impacts including RSS, Yahoo! Pipes, and Twitter, and discuss how Loren is using these tools to create a new service to track the Atlanta web entrepreneur community.  We also talk a bit about Twitter’s recent service “brownouts”, and what they might mean for the community.

We’re still sticking with an under-the-radar, links-on-blogs format for sharing this podcast, so you may download this week’s episode here, or listen below:

Please leave us some feedback, either in the comments here or on Loren’s post for this episode. We look forward to hearing your thoughts!

My first instinct was to simply use svnadmin dump to dump out the contents of the whole shared repository, transfer that to the new machine, use svnadmin load to load the data into the new repository, and then delete out the projects that I did not want.

The first pass at this created a 2.5GB dump file, something which I did not want to send over the network! After poking around at the options for svnadmin dump, I found that I could shrink this down to about 1GB by using the --deltas flag, which saves space by dumping only the differences between each revision in the repository. 1GB was still pretty big, but we have a fast network, so it wasn’t that painful. I transferred it to the new server, created a new repository, and ran svnadmin load to load the dump into the repository.

All I had to do next was delete the directories from the repository that I didn’t want. I knew this would be a little tricky because I didn’t want to keep any code from those projects around, and simply running svn delete on each directory would have kept the other projects in the repository’s history.

As it turns out, you can’t just remove all traces of something from a Subversion repository. The reasons for this are many, but they simply haven’t gotten around to implementing svn oblitherate, yet. The current solution is to create a dump with svnadmin dump, and then process that file with a tool called svndumpfilter.

The docs for svndumpfilter are pretty straightforward, so I tried using it on the dump file I had already created, but no matter what I did I kept getting this error:

svndumpfilter: Unsupported dumpfile version: 3

What the docs (and error message) don’t tell you is that svndumpfilter only works on full dump files, and doesn’t support dump files made with the --deltas flag.

Long Story Short (Too Late)

In the end, what I wanted was simple, but not obvious. On the original server, I ran:

svnadmin dump /path/to/original/repository | \
    svndumpfilter include my_project \
               --drop-empty-revs \
               --renumber-revs > dump_file

I was then able to copy the resulting (much, much smaller!) dump file to the new machine, blow away and re-create the new repository, and load it with svnadmin load.

And now maybe you can learn from this example instead of having to figure it out yourself through trial-and-error!

We did this podcast with a little less preparation, so the topics wander a little bit more. Some things you can expect to hear:

• Justin.tv is great, but it may not be the be-all for live web video broadcasting because of the way it prevents you from embedding “episodes” and live chat in your own pages. Given alternatives like Ustream and Stickam, and thanks to the power of embeddable apps, like Backnoise, will it matter what Justin.tv does and doesn’t support?
• Features aside, content on Justin.tv is crazy! Loren and friends spent Saturday broadcasting themselves brewing beer, playing games, and getting rowdy all on Loren’s “come watch” page where their friends could play along via chat provided by Backnoise. Also, Marty missed the first game of the Pens vs. Red Wings game, but apparently could have caught it from Justin.tv!
• Google announced FriendConnect, with exciting demos and no other documentation to speak of. Is it vaporware? Is it evil?
• I talk in way too much detail about my experiences playing with the Google App Engine and its (lack of) support for the excellent Python web framework Django. Long story short: it’s great if you’re willing to write a bunch of infrastructure yourself, but lousy for banging out a weekend project.
• Also, there’s this new thing called the Dash, an always-connected GPS unit built on the OpenMoko Linux-based cell phone platform. They did a media blitz this week and Loren met them at startupriot just before it happened.

Please have a listen and give us some feedback! What’s interesting? What’s not? What would you like to hear us talk about? Or tell us we’re wrong about? Leave comment here or on Loren’s post for this entry.

As a first step into understanding this problem, my friend Loren and I have decided to try creating our own podcast. Namely, we recorded an episode of an as-yet-unnamed podcast which you can listen to here:

Using the free version of the Pamela Call Recorder for Skype, we recorded 3 15-minute segments to create a 45 minute podcast. During that time we talked about many things, from the ins and outs of getting started with podcasting tools to discussing the opportunities and challenges that come with putting oneself online “live” to the power that technology gives us to make meaningful artifacts from our lives. You can read Loren’s description of the podcast on his blog.

Give it a listen if you have a chance. You can listen via the embedded Flash player above, or you can download the ~10.8MB mp3 file here.

If you do listen, please leave us some feedback! I am interested to know your thoughts on the podcast itself, on what you’d like to see from a “podcast hub” site, on what information we talked about in the podcast you’d like to see made easily accessible (such as links or products that we mention), or parts you’d like to see excerpted (if any). Please remember that this is a rough “one-off” recording. After another episode or two we will want to try and choose a name and a general direction for the podcast before we go syndicating ourselves with RSS feeds, Atom feeds, and iTunes subscriptions.