The cards have five blocks at the bottom, which are either black or white, representing 1 or 0. Using ones and zeroes allows us to create a binary encoding scheme, so with five positions we use 1, 2, 4, 8, 16 for the values and can represent any number from 1 to 31.

I started by grabbing the image of the sensors from the SparkFun product page and dropping them into Inkscape (sized appropriately) so I could design the barcode part of the card, and so I could design the mount for the sensors.

Once I had a 2D design in Inkscape I exported it as a DXF file and used the linear_extrude command in OpenSCAD to create a 3mm tall plate, and then added another plate. It wasn’t perfect, but it was fast. I started the 3D printer while I got to work soldering…

Sensors all soldered up, mounted to the plate with 3mm screws, and wired to an Arduino via a breadboard. All of this is still prototyping stage. It doesn’t look pretty, but it worked and it was enough to test things out and do a demo.

Here’s an example of some card templates. Can you determine what number is being passed by reading it in binary? Since we’ve got 5 positions we can have 31 different cards… If you needed 63 cards, you would need 6 positions (and one more sensor.) 127 cards? That would be 7 positions and two more sensors. Any more than that and you might consider using the SparkFun Line Follower Array which has 8 sensors on a single board.

The total time to create this prototype was just a few hours from starting a design in Inkscape to 3D printing a piece, soldering up and mounting the sensors, and writing the code. (I also wrote a simple Processing application which read the serial output from the Arduino to display the card data on screen.)

2015.03.29

When last we discussed rotary encoding, it was all experimental. Since the project (which will eventually be revealed) is complete, I figured I should share a bit more about the exploration and final solution.

I moved from printed paper disks to laser-cut disks. I cut some 3mm Baltic Birch plywood at Milwaukee Makerspace. They worked well, but since I was hoping to get more steps/resolution I continued with the paper prototypes as well.

The one in the photo above was a bit too fine… too many steps. The more steps the more precise the alignment has to be, and the more chance of errors.

The idea would be to use a wider disk and instead of it spinning between two pieces, it would have the encoding stripe on the edge, and the sensors would be on the outside of the disk. Back to the breadboard! The QRD1114s require a pair of resistors to work properly, so I wired it up and did a few tests and things seemed to work.

My first tests just involved sliding a piece of striped paper across the sensors, but I needed a real disk. I used the laser cutter at Brown Dog Gadgets to cut some disks from 1″ pink foam, and also from 1/4″ foamcore board. The pink foam actually ended up with concave sides due to the melting power of the laser, so I used the foamcore board pieces stacked up.

Math time! How long of a strip do we need to wrap around the disk? Well, you can determine the circumference of a circle if you know the radius or diameter. Hooray for math! Above is a letter size file that I could print on a laser printer to produce the stripes I needed. The thin line on the right side was used for alignment since I had to use multiple stripes to wrap around the disk.

Here’s a sneak peek of what the final disk looks like. There’s a few more steps before we got this far though, so I’ll continue the story next time.

2014.11.19

The Sharp GP2Y0A41SK0F is an infrared proximity sensor. You can grab them from SparkFun, Pololu, or many other vendors. (There’s a bunch of different models, but I’m using the GP2Y0A21YK right now. The GP2Y0A21YK appears to be roughly the same physical size.)

Since I’m using this sensor, I needed a way to mount it. As usual, I look around for a datasheet. Datasheets will often contain the technical drawings of a part. If you’re lucky, they’ll be vector based (Hello, Inventables!) but if not, you can still use them to determine the dimensions of things, or where mounting holes need to go.

Often I’ll pull a datasheet into Inkscape, put it on the bottom layer, lower its transparency, and draw on top of it. Sometimes that works, and sometimes you just need to pull out the calipers and take a few measurements. In an ideal world, all vendors would release technical drawings of their products in vector formats. (Well, at least in my ideal world.)

Oh, I should note than I want this sensor mounted on the inside of things. If you want it mounted on the outside, you really just need two holes for the mounts, and maybe one for the wires.

If you were wondering about that part with the notch, that’s to make the sensor level while mounting it inside, and the notch is for the wire connector.

One more note on the mounting holes. They are 3.2mm in diameter, which means using a 3mm screw would make sense, but I only had Imperial hardware handy. I also only had 6-32, which is 3.5052mm in diameter, and no 5-40 which is 3.175mm in diameter. No worries, since the sensor is plastic, a quick shave with an X-ACTO knife on the inside of the holes made them fit quite easily.

At some point I’ll need to test how multiple sensors react to each other in the same physical space… That should be interesting!

For an encoding disk I searched for a suitable SVG file and found this blog post, which just happened to have a link to a perl script (of course!) to generate encoding disks. A little Inkscape magic and I printed out a disk to test with.

I should note that my original plan was to use the Silhouette Cameo to cut the slots in the disk, but the paper version actually worked fine for testing. In the final piece we’ll probably use a piece of laser-cut acrylic.

With my encoding disk ready I hot glued it to a bolt and chucked it in the drill. This gave me an easy way to vary the speed and direction.

I grabbed the Encoder_Polling library and used the counter example and that was about it. I could now see if the disk was spinning and in which direction (by looking at the numbers increase or decrease.)

I really thought I’d need to mount the photo interrupters more precisely, but I pretty much left them hanging in mid-air supported by wires on a breadboard and it worked fine. (Maybe I just got lucky?) There’s a lot more code to write, but this was a good start.

Oh, if you want to learn way too much about reading rotary encoders with an Arduino, visit the Reading Rotary Encoders page and set aside a few hours…

2011.11.29

I first heard of Pachube shortly after it launched, and took a look at it, but didn’t really have any data to feed it. Then they started charging for the service, so I never pursued it, and then they got acquired by LogMeIn, and became free again, so I figured I’d check it out.

Take a look at the feed Environment for a constantly-updated view of my office. We’re tracking the temperature and the humidity, but I’d also like to add a photocell (light sensor) and occupancy sensor (PIR) at some point.

I dabbled in Processing code, but ended up going back to Perl after some instability. There’s still some issues with bad data I need to sort out. (See below.)

There’s not a lot of amazing code in place yet, as it’s all learn-as-I-go experimental, but that’s fine with me…

I mean, as it stands right now, I can quickly see the status of my office from anywhere in the world as long as I’ve got a mobile phone and an Internet connection. That alone should be worth something…