Starting Woodworking

To further increase the diversity of topics on this blog, I’m going to talk about woodworking. I’ve been eager to try my hand at it for several years and I wasn’t able to find the space until recently when we moved out of our two bedroom apartment and into a home with a garage.

I have a tendency to over-commit when it comes to hobbies and so I’ve been purposefully trying to narrow my tooling focus to projects immediately in front of me. The first project I had in mind was a built-in bookshelf in our living room and I’ll write more about that project later. This post is more of a quick summary of how I navigated my initial burst of tooling up as a novice woodworker trying to adhere to a budget of less than $1000 over several months.

Circular Saw

I bought a Makita circular saw and have been very happy. The only complaint I’ve had applies to most circular saws on the market – zero dust and chip collection. There are kits you can buy to add a port for that and that’s something I’d like to look into later. I use this exclusively to break down plywood.

I’m going to make a custom guide very soon. Until recently I’ve been clamping down scrap pieces and accounting for the added width of the saw base manually and that’s getting old. I should have done this sooner.

Table Saw

This was one area where I wish I would have spent more money. I didn’t know how much deeper into the hobby I’d get after the first few projects and so I was wary of buying more than I needed. I ended up picking up a Ridgid R4510 portable table saw from HD using a HF coupon (only got 10% off though) If I could travel back in time, I’d tell myself to pay the extra few hundred for the R4512. Right now, I’m torn between making that upgrade immediately or waiting until I possibly can’t avoid the upgrade (something breaks?) or can justify spending the big dollars on professional table saw.

Some accessories that I’ve purchased are:

  • Bench Dog Push-Loc Push Stick - I really like this push stick. The only complaint I have is that the heel portion is a little shallow, though it’s never slipped off on me.
  • Gripper - I don’t use this as often as I thought I would. I’ve managed to keep my guard on for nearly all of my through cuts. I have never had to rip so narrow that I can’t get the push stick between the guard and the fence (<1.5″ on my saw). I do use this when making dados or rabbets, so it’s getting used and I’ve liked having it then.
  • Olshun Dado Stack + ZCI - I went with a 6″ stack instead of the 8″ and haven’t regretted the choice, yet. The stack came with a great case and I’ve not had a problem configuring it to get the width I need. The ZCI works good too, though now that I own a router I’ll probably make my own.
  • Fence Clamps - I’ve used these a few times on my sacrificial fence for making rabbets and been happy with them. They clamp.
  • Featherboard – This has worked ok, it’s too big though and the extra size isn’t that functional. I’d like a smaller one or one that’s length facilitates clamping.
  • 3M TEKK WorkTunes Hearing Protector – I should have bought these sooner, I’ve been wearing them more and more away from the saw and always when using the saw.

There have been other more random purchases but those are the things I use often enough or are non-standard enough that people may be considering them and aren’t sure.


A router was my first major tool purchase after the table saw. I didn’t stress too much over the first buy, especially having heard that it’s common once you get deeper to own more than one. I knew I wanted to get a fixed base and a plunge base in one go and that I wanted variable speed. For me, it came down to either a Porter Cable or a DeWalt. I went with the DeWalt because it was cheaper. I also picked up a few other things:

  • Edge Guide - I’ve used this a little, mainly experimented with using it to make some dados on some boards I had lying around. It seems to work good and I like that it has a micro-adjustment as that’s something I overlooked when buying. 
  • Set of Router Bits - A controversial choice, I think. I wasn’t sure which bits would get used initially and this seemed like an effective way to establish a baseline that I could use to determine where to focus my money. So far I’ve been happy and can see which are getting used more than others. So far my 1/4″ straight bit has gotten used the most. I’ve also used the 3/4″ rabbet’ing bit and the flush cutting bit.
  • Guide Bushings - Also happy with this purchase, though I wish they came with a case of some kind. I ended up just drilling some holes in a board with forstner bits and keeping them on that in a drawer.

I’ve used the router on a few things, mostly for dados and for routing some handles in some cases using a template. I’m very happy with the router so far.

Dust Collection

A more serious form of dust collection has been my latest endeavor. I got the HF 2-HP system because many people seemed satisfied with the value. It went together fine and seems to be doing a good job collecting. I still usually use my shop vac for the router, where having a high static pressure is nice. My table saw only has a 2 1/2″ port, so I made a cabinet with a hole in the top that it sits on and put a 4″ port in that. I then use a Y joint to pull from the bottom 4″ port and the built-in port. This is working nice, and the cabinet is much more convenient than the mobile stand I was using because it’s got some bottom storage and I can mount things on the sides.

What’s Next

I’m constantly researching for a table saw upgrade and for my first band saw. Craigslist hasn’t been too fruitful for me so far, at least for tools in my price and quality range. Right now for my first band saw I’ve got the Craftsman 14″ in my sights. Seems to be a good start and is in a price range I can justify. Also, I keep postponing buying an air compressor and brad nailer, despite having wished I had one at least twice.

So there you have it, that’s been the gist of my experience so far with choosing tools and accessories. I wanted to capture this, just in case there’s anyone else who’s thinking of going the same way I did.

Grandfather’s Power Supply Repair

My grandfather recently passed away and I was honored to inherit some of his electronics equipment. I could write a book about my grandfather and no blog post could do justice to how amazing his life nor how unquenchable his love of building and creating was. Included in what he left to me were several power supplies, one of which wasn’t working when I got it home:


It’s got a switch for changing between 14V and 28V and there’s a label indicating that it’s a 9A power supply he created in 1998. I decided it would be a pretty fitting task to repair it and so set about taking the thing apart. Here’s a picture with the casing off:


You can immediately see the transformer and rectifier as well as a very large smoothing capacitor. Alongside that there’s a board with the voltage regulation circuitry with the current sense resistor and trimpots for tuning the voltage to 14V and 28V. Along the bottom is a large heatsink where the power transistors are, which look like this:


I suspected these or the capacitor first. I don’t have much experience working on power supplies but figured they were the most likely culprits to fail. After some testing though, I started to suspect the voltage regular chip itself. A quick google for the chip got me the data sheet  and I was able to toss together a quick test circuit using parts I knew to be good.


This turned out to be the right track as I wasn’t able to get things working, so I was hopeful when I found a modern replacement for the chip for $0.60 and ordered one up. With that on the board and everything reattached the power supply was working again.



This was only one of the power supplies he left behind and I’m hoping to take some pictures of the others and their insides for a future post.

Bndtools Randomness

Over the past several weeks I’ve been tinkering with OSGi in my free time. My approach has been anything but systematic, rather, it’s been a sort of chaotic scrambling from one tool or problem to the next. I’ve got a loosely formed goal in mind, but I’ve been happy to take detours along the way. I started simply enough by downloading Karaf and getting some bundles deploying, tinkered with Camel and dove into building some simple case studies and test apps to get a feel for things. Eventually that work took me into Pax Exam and then Pax Runner, completely invaluable tools in learning the ropes of provisioning containers for specific purposes from the ground up.

Lately, I’ve been spending some playing with bndtools, an Eclipse plugin that kept popping up. The reason for my post is mainly to clear up some of the confusion that I myself had about how bndtools works and fits into the world of OSGi. First, I suggest you actually take one of the many tutorials that are out there. I’m not going to walk you through what others have already documented, rather, just point out some of the things that were critical to my understanding and accepting of bndtools into my development process.


I’ve actually gone from not minding Maven to hating Maven to liking Maven again. Despite the criticism it’s received it’s doing its job fantastically. At first, I thought that bndtools would require some duplication of my build (as an Ant build) or bundle metadata if I wanted to keep Maven alive in my project. Not true.  Because the bnd.bnd file is nothing more than a bnd configuration file, we can take full advantage of the UI and goodness that bndtools is providing and still use Maven. Bndtools is merely layering on some convention and Eclipse integration. Ant builds aren’t necessar, though using an Ant build can offer a little more flexibility than Maven can (i.e. sub-bundles). This made me happy as I was already using bnd as part of my Maven build. Most of what follows here is mentioned in this thread on the mailing list that I fortunately stumbled upon. The first step to getting things playing nicely is to update your maven-bundle-plugin configuration in your pom to reflect something like this:


This tells the plugin to read the bnd.bnd file for the configuration directly. Next, we need to update the project wide bnd settings and change some default directories:

bin: target/classes
src: src/main/java
target-dir: target/bndtools

Only the first property is actually necessary, the others don’t hurt and I do prefer my build artifacts in the target directory. Finally, in the bnd.bnd file itself you’ll need to specify the Bundle-SymbolicName and the Bundle-Version options, like so:

Bundle-SymbolicName: com.example.api
Bundle-Version: 1.0.0-SNAPSHOT

There were a few places that suggested you could use ${pom.artifactId} and ${pom.version} here if you enabled sub-bundles (via -sub: *.bnd) Enabling sub-bundles did cause those placeholders to work for me, though I ended up losing half of the useful tabs available when editing the bnd.bnd file.

After these changes, things worked great!

Web Applications

I had a few WARs that I was building and was able to get those working by moving to WABs – very easily done by adding the following lines to the respective bnd.bnd files:

wab: src/main/webapp/
Web-ContextPath: webapp

Random Tips

Bndtools is under pretty active development and things are still coming together. Here are some things I ran into that may help point others in the right direction, though I don’t imagine they will apply for much longer.

  1. Your cnf directory shoudd be immediately under the workspace directory and alongside your project directories. Some errors I was seeing that are related to this are:
    • No workspace found from <some project>
  2. Project names should match their bundle names. Some errors I was seeing that are related to this are:
    • NullPointerException’s in BsnValidator (actually a bug, once fixed you’d get a ‘Bundle-SymbolicName is not valid for builder’ message)
  3. If when you’re adding a bundle to your local repository and you get an error about a failure to rename, you’re likely using an older version of bndlib. When you upgrade the version of bndtools be sure that you also recreate the cnf directory. I hadn’t expected the bndlib version in cnf to affect the dialogs and messages I was seeing in Eclipse, but they were. I had upgraded bndtools but not changed cnf and was still seeing this error (The root cause is that the temporary Jar wasn’t being closed before being move into the repository)

Building Bndtools

I did build my own bndtools while toying with things, just to see if upgrading would fix some of the bizarre issues I had been seeing. Eventually I narrowed the problems down to others (like location of cnf, or the project names being wrong) Here are some issues I saw when getting bndtools compiled:

  • When I first tried building with Ant I got an error about Repo too few arguments. I fixed this by double checking the URLs in the repositories.bnd, specifically the repository for the bnd sources. In mine, bndBuildNum was for an older build that was no longer available on the Hudson server.  I changed this to a newer build number. Pay attention to version numbers in the Hudson builds though, newer builds will require you to change bndlib-version-base and bndlib-version-ceiling. I eventually just cloned bnd and used the localRepo option. I’m guessing that the ${repo} macro needs some better error handling of situations where files are missing or URLs are bad? Not sure.
  • I again ran into the “rename failed” problem when building the bnd distribution. I fixed that by copying the newer bndlib I had just built into the cnf/repo/biz.aQute.bnd directory and running again.

That’s all I got for now… hope that wasn’t too much and/or too scrambled. Good luck!

Type for TypedQuery incompatible with query return type.

I was playing around with an OSGi/Hibernate sample application that was using Apache Aries to provide EntityManagers to bundles and ran into a weird issue when I began querying. Take the following code:

TypedQuery<User> query = em.createQuery("FROM User", User.class);
List<User> users = query.getResultList();

At runtime, createQuery would throw “Type specified for TypedQuery [] is incompatible with query return type [interface java.util.Map]” which was very confusing. After some digging, I discovered this code deep inside Hibernate (EntityType)

private Class determineAssociatedEntityClass() {
  try {
    return ReflectHelper.classForName(getAssociatedEntityName());
  catch (ClassNotFoundException cnfe) {
    return java.util.Map.class;

Suddenly this is a common OSGi problem. ReflectHelper.classForName does what anybody familiar with OSGi class loading peculiarities would imagine – tries to use the TCCL and then falls back on Class.forName.  This took me some time to uncover and is fairly obscure given the error I was seeing and so I figured I’d write this post to help anybody else that runs into the same issue. You can avoid the problem a few ways:

  1. Export your model packages assuming DynamicImport-Package is enabled on whatever Hibernate bundle you’re using.
  2. Use non-TypedQuery createQuery (meh)

I’m still pretty new to this OSGi stuff so if there’s a better solution I’d love to hear about it… Hope this helps somebody!

Inherited Problems

When developers first begin learning object-orientated programming inheritance usually stands out more than any other language feature or practice. It’s introduction can come in many flavors, my favorite of which is the shape hierarchy. An abstract base class, Shape, has many derived concrete classes like Triangle, Circle, and Square. Shape itself has methods for calculating area, or perimeter that the derived classes can provide implementations for1. It’s one of many possible examples (another is the Animal hierarchy) that demonstrates how inheritance, coupled with other practices like polymorphism and encapsulation can create powerful models of behavior and data.

In my experience, the real value and purpose of inheritance begins to get cloudy after that first introduction. In fact, I personally have used inheritance incorrectly for most of my career. More often than not it’s used as a mechanism to reuse code. How many of us have written or seen classes like this:

  • AbstractEntity
  • AbstractController
  • AbstractService
  • AbstractRepository

I’ve written classes just like these, adding methods that can be overridden in derived classes (AbstractEntity.saved, etc..) and gone on my merry way, happy that I’m reusing code and providing extensible points in the code base, completely unaware that I’ve laid the foundation for a future problem. In fact, these can sometimes start as interfaces masquerading as abstract classes. When you apply inheritance to only reuse code, you’re not doing so in order to create a polymorphic hierarchy, where different instances in the hierarchy can be substituted for one another. In the shape hierarchy an instance of a Shape can be a Triangle or a Square and the two are interchangeable. A non-developer would agree the two are members of the same hierarchy. That is not always the case if you have an AbstractController or AbstractEntity who’s reason for existence is to provide a repository for reusable methods to derived classes. In other words, there’s no behavioral or classifiable relationship between the types in the hierarchy outside of them residing in the same layer or functional area of the application (Controllers, Domain, Services), there’s only an implementation-level relationship.

Now there’s a coupling nightmare in the works as code living in the base class begins to grow, instantly bestowing behavior to all derived classes that many times they need to augment because the behavior doesn’t apply or the logic for applying that behavior is subtly different. So more abstract classes are introduced in the middle of the hierarchy (AbstractPersonEntity, AbstractTaggedEntity. AbstractAdminController), so that we can keep things DRY. What happens when a particular derived class needs to reuse code from two of these inner abstract classes, say a taggable person? Nope, many modern OO languages disallow multiple inheritance2. Suddenly inheritance isn’t paying off at all.

Inheritance is one of the most abused patterns in object orientated programming. Many of us have used inheritance as a mechanism to keep things DRY and reuse code. Odds are, it was the wrong choice. What to do? Composition. If a particular behavior is common and needs to be reused, create a class that can be used. These classes always have a well defined interface and can have multiple implementations the rest of the system can take advantage of. A controller for editing people can use a repository that performs heavy auditing, an entity that can be tagged can defer to the reusable tagging code lying in a TagSet class. As this is applied throughout the code it becomes clearer how certain implementations are solving common problems, and if changes to one particular part of the system need to occur, they can be made in isolation much easier. Code re-used via composition benefits from a much narrower contract than large, complicated abstract base classes and it’s much easier to test and make changes to than if it were sitting among a dozen other concerns.

  1. My simplified shape example is also kind of awkward in that Shape as described isn’t providing behavior, though the example could be expanded upon so that it does in a reasonable way.
  2. Not to imply that I consider multiple inheritance a good solution.

DFRobot 4WD Encoders

My latest robotics platform is the DFRobot 4WD, a respectable step up from the Tamiya Tracked Chassis I was using before.. The second thing I bought after the platform itself was the standard Wheel Encoder Set that everyone probably buys when they get the chassis. This has proven to be a pretty valuable lesson in what to look for in encoders.

Installing them was pretty easy and didn’t pose any serious problems. On my pair the spacers that set them away from the gearbox were too short and so I trimmed down some spacers I already had. My real problems started when I tried using them… Basically, I don’t think they’re good for anything but very rudimentary feedback. They simply don’t have the resolution I would like, especially at lower speeds.

To squeeze more resolution out of them I made some encoder wheels with 16 divisions instead of 10. I used the program mentioned in this article and had Kinkos print them onto some transparencies for about $1.50. I tried a few different resolutions, including some very optimistic ones and 16 was the best. You can see that I doubled up two copies as that felt stronger and was sure to block out any imperfections each wheel had from the printing. Right now I’m happy enough as I’m using fast enough speeds so that I get enough ticks per cycle to produce feedback on. I’ve been considering ways to move the wheel to the motor shaft itself, before the gear reduction where it’ll be moving much more (maybe too much!), especially at lower speeds. Not sure it’s possible yet, as that will be a very tight fit. Anyway, though it may go without saying, don’t expect the world from these encoders and if you’re already considering a more serious solution you may just want to skip to that.

Kitchen Table Robotics

This past Christmas was an Arduino Christmas for me. I got a couple of Arduinos and some accessories and it’s taken off into quite an obsessive hobby, completely taking over my kitchen table (We live in a small apartment). Anybody who gets into electronics through the Arduino will probably decide to build some kind of robot at some point in their adventures. For me the goal was to provide some kind of structure to my electronics/microcontroller tinkering. Similarly, when I’d like to learn a new programming language or framework, I pick a project to implement. To test the waters I picked out the cheapest kit/parts I could find and dove into seeing what I could do with it.

Basic Platform

I started with the Tamiya Tracked Vehicle Chassis and the Tamiya Twin Motor Gearbox. Eventually I swapped out the motors for the higher voltage Solarbotics RM3 and picked up a couple of Tamiya Universal Plates to support the electronics and batteries.

A tracked chassis seemed easier to start with due to the differential drive. To learn as much as possible along the way I decided to build my own basic motor controller based on the SN74410. I then added some back-emf sensing after stumbling upon this post. The post explains the details, but basically on each motor there’s a pair of voltage dividers connected to an analog pad on the Arduino. Every 100ms the software stops the motors, pauses for 2ms so things can settle and then samples the voltage on that motor for 2ms more. That average is proportional to the physical speed of the motor and with some calibration we can match speeds of the motors, among other things.


My brother in law is addicted to RC helicopters so I consulted him on some LiPos. He suggested a receiver pack because my current requirements weren’t insane. I went with the Zippy FlightMax 2100mAh 2S which has worked great. For charging I got the Thunder AC6. I wasn’t interested in anything more serious until I was sure I’d get my moneys worth and so far it has worked great. Because I fried one of my voltage regulars due to a polarization mishap I grabbed a set of Anderson Powerpoles and attached those to the batteries and made a few utility cables. I’m very happy with them, though I wish they were a little smaller as they’re kind of big for my needs. Also, I used solid core hookup wire on power system and next time I’d use stranded for the extra flexibility, frequently disconnecting and connecting the battery is annoying with rigid wires. Also, I’m using the Pololu D24V6AHV to step the battery voltage down to 5V to drive the Arduino instead of using the on board linear regulator.

Tread Encoder

I attempted a simple encoder system using SparkFun’s SEN-09299. I mounted them under the second story of the chassis, hoping the beam would sneak through the tiny holes in the tread allowing me to see them tick by.

Unfortunately, this proof of concept didn’t produce a reliable square wave as the tread moved. I think there’s still merit to the idea though, especially if the photo interrupter could be mounted tighter to the tread so that the IR isn’t leaking around  the outside. I opted to just hold off until I could do a proper encoder on the motor’s shaft.

Pololu IMU

I’m a big fan of Pololu. They’ve got a ton of very useful stuff on their website with great documentation. It’s also nice that they’re nearby (Las Vegas, I’m in Southern California) so everything arrives quickly. I picked up their MinIMU-9 to toy around with, you can see the part mounted on the picture below.

With the help of their sample code I pieced together a feedback loop to maintain a heading. This was very successful as it would do a great good job of turning back to its original heading if bumped off course, for example. It’s a great little board, especially with the DCM library they link to on their site. I’ve since broken the MinIMU-9 and an ATMega328P out onto a separate, configurable board that’s running the DCM algorithm and can speak I2C. I’ll do a post on that later.

Final Product And Thoughts

Here are a few more pictures of the robot. It’s been dismantled now so that I could use the parts, as is the circle of robot life.

You may have noticed the IR detector on the servo in the front for obstacle detection. That’s just a tiny peak into the autonomous behavior I’m getting into now. More on that in a future post.

So yeah, that’s about all I got on this project, hehe. I’ve already bought my next platform, the DFRobot 4WD so there will be more to come on that. I’ve also gotten out of the motor controller business and am using an off the shelf one so that I can focus more on autonomous behavior. Making my own simplified/naive one was great fun though.