Optional: Positional Encoder

Creating a uniformly-proportioned digital light painting — one that appears neither stretched nor compressed — is often a matter of trial, error and luck. One must experiment with speed settings on the control board or try a different walking speed. The human element means it will change from one photo to the next or even across the frame in a single picture. For really bulletproof pictures, we’d ideally like to show 144 lines per meter of motion, to match the pixel density of the NeoPixel strip.

There’s a technical solution to this, but be warned that it’s a costly and fussy option. Making this work requires more improvised McGuyver tech and craft than the rest of the project. Fortunately you can build the project without it and still have a lot of fun, then add it later if you want.

First, the light bar must be attached to some sort of wheeled motion base…bicycle, stroller, wheelchair, whatever you have access to. That’s the easy part. Then one must interface a positional encoder — an accurate motion counter – to a wheel. This isn’t like a bicycle speedometer where the speed can be extrapolated from a magnet once per turn…no, we need right now precision, an exact count.
The best tool for this is an optical rotary encoder, such as one of the Honeywell 600 series or Bourns EN series encoders. At the low end you might be lucky to find one for $35…but twice that is pretty typical. This is just for the component itself; mounting hardware is extra.
A mechanical rotary encoder (such as the one in the Adafruit shop) is not recommended for this. The resolution is coarse in comparison, the detents work against smooth rotation and the mechanical output requires debouncing. They’re great for control panels, but accurately measuring movement really demands an optical solution.

Whatever you choose, it must have excellent resolution. The NeoPixels on a 144 LEDs/meter strip are spaced just 7 millimeters apart. A coarse encoder that can read only a few pulses per revolution simply won’t cut it.

If you’re really crafty, it might be possible to gut an optical “chopper wheel” from an old ball mouse (remember those?) and drive it from a larger wheel with a belt or gear system.
Most of these encoders are the “quadrature” type: they output two square waves 90 degrees out of phase, and can be used to determine both position and direction. Our application only uses one output and always advances forward; it doesn’t distinguish direction. This lets us exploit a hardware feature of the Arduino microcontroller and saves a lot of code.

The encoder output must connect to digital pin #5 on the Arduino Uno. This pin can be used as an input to Timer 1, so the exact same code that normally relies on regular timer intervals now uses pulses from the wheel instead.

The encoder also requires a +5V and GND connection. One output is used (channel A or B), the other can be left unconnected.

To enable the encoder feature, un-comment this line in the code:
Download: file
#define ENCODERSTEPS 8 // # of steps needed to advance 1 line
You’ll probably need to change ENCODERSTEPS depending on your encoder’s shaft diameter, number of steps, and factoring in any sort of gear ratio you might have between your motion base’s wheels and the encoder. Estimate the number of steps covered over 7mm movement (the approximate distance between NeoPixels), then get some trial photographs to fine-tune the ENCODERSTEPS value.

When using the encoder feature, the speed dial will have no effect. It’s still used at startup for setting the image brightness, but isn’t involved in timing the image playback.
Here the light bar is mounted on the rear rack of a folding bicycle, which is then pushed (not ridden). The control board has a long ribbon cable and is strapped to the handlebar.

You do not need to go get a folding bicycle to do this! They’re pricey. Root around the house, see what you have around or can source at a secondhand store. Razor scooter? LEGO wheels? TV cart? Fisher Price “Corn Popper” toy?
The encoder selection and code adjustment are just a small part of the challenge. Physically interfacing the encoder to the wheel is the hard part…and a problem we unfortunately can’t help solve because every motion base will be differently improvised and manufactured. You may need to devise a custom bracket of some sort to hold the encoder to the wheel. Machining? 3D printing? Cable ties and LEGO Technic parts? You’ll have to decipher that for your particular wheel and encoder.
By sheer dumb luck the encoder I had on hand fit precisely in an unused mounting hole on my particular bike fenders, putting the encoder shaft (by sheer dumb luck the “round” variety, with no knob alignment notch) directly in contact (by sheer dumb luck) with the tire. This was like winning the geek lottery; don’t count on it happening. In all likelihood you will need to create a custom bracket or belt/gearing system of some sort.
The wavy animated effect was created by backing the bike’s rear tire up against a brick so it always starts in the same location, then taking several photographs of the same image. The slight variations in the path and tilt of the bicycle create a sort of rippling effect when these images are then stacked and animated in Photoshop.
This guide was first published on Dec 10, 2013. It was last updated on Dec 10, 2013. This page (Optional: Positional Encoder) was last updated on May 21, 2019.