Home stretch! Nearly there! At this point, you should have LEDs mounted on a support bar, the Raspberry Pi (with HAT) in an enclosure, and have the strandtest code working.
Next we’ll add painting controls, mount the battery to the frame and optionally add a light diffuser.
Control Buttons
Everyone loves buttons! We’ll add a few to trigger the light painter, adjust speed and select images.
The controls should be near the handle. Since the Pi is kept close to the strip input, you’ll need six long wires or some ribbon cable to bridge the distance.
I used five tactile buttons soldered on a 1/4-size Perma Proto breadboard. Any sort of momentary buttons will do, if you already have some around.
Disregard the “+” label and join both outermost rails to ground.
On the four buttons in contact with the ground rails, it was necessary to clip away one pin using flush cutters. This should be the pin straight across from each button’s corresponding ribbon cable wire.
A sixth button (not shown here) can go on the Pi HAT for the halt function. I happened to use a smaller tactile button for that (shown on the prior page), but it’s all good.
|
|
For posterity, here’s the GPIO pin map again. Any of the green pins is fair game for each of the five buttons… |
…but here are the pin assignments normally used in the software:
pin_go = 22 pin_next = 17 pin_prev = 4 pin_faster = 23 pin_slower = 24
If you follow this pinout, then your painter will continue to work after any updates to our code; you won’t have to edit that part each time.
Diffuser
Slightly diffusing the light from the LEDs makes them photograph better. You get a wash of light over a small area rather than a single focused dot.
First Light
Now lets give it a test run!
Plug the LED strip and the Raspberry Pi into the USB battery bank and switch it on. While that boots, on your “main” computer, dig up a USB flash drive, format it as a Windows FAT32 filesystem, and drop a few JPEG, PNG or GIF images on there. These should go at the root level of the drive, not inside any folders.
Log in to the Raspberry Pi (either ssh over wireless, or plug in display and keyboard) and run the light painting script manually:
cd DotStarPiPainter sudo python DotStarPiPainter.py
Nothing will happen at first. Plug in the USB flash drive and you should see a message as it loads and does some processing on the first image. The LED strip will also give a simple indication as its working…red while loading, yellow while processing, green indicating success (ready). The position along the strip shows which image number is being loaded.
If that works, press the “go” button.
You should see the LEDs glimmer for a few seconds, though it won’t make any sense to the naked eye.
Try the faster & slower buttons. A blue light should move up and down the strip indicating the duration of the paint time; about 0.1 second at one end of the strip, 10 seconds at the opposite end. The default time is 2 seconds. Try longer and shorter durations and press the “go” button again.
Try the next & previous image buttons. If there’s multiple images on the USB drive, it’ll show the red-yellow-green sequence as a new image is loaded. Press the “go” button again.
No lights! No go!
First, confirm that the USB drive is detected and contains valid image files; you’ll see the DotStarPiPainter.py script printing messages as it works.
If images are loading but nothing’s displayed, refer to the troubleshooting steps on the Assembly Part 1 page.
I got some lights for a moment, but now it’s just stuck there!
This can happen if the LEDs draw a lot of current. Voltage from the battery bank dips and the Raspberry Pi locks up. We can fix this!
Reboot the system (unplug, re-plug USB), wait for it to boot, log in and then edit the DotStarPiPainter.py script.
cd DotStarPiPainter nano DotStarPiPainter.py
Look for the following line of code (around line 74, just before “INITIALIZATION”):
power_settings = (1450, 1550)
Those two numbers are the average and peak current (very approximate-ish) to deliver to the LEDs. Although the battery bank can provide more current than this, the voltage drops when it does so. We need to dial it back a bit. Try changing this to (1000, 1000), save the changes and re-run the script.
If it’s successful now, take note of the value(s) last used, then try something a little higher…like (1200, 1200). If it works, you can continue dialing it up in smaller increments. If it locks up again, reboot and dial down.
Another option, if you’ve got a second battery bank around: dedicate the larger/higher-current pack 100% to the LEDs and the second one fully to the Pi. The DotStar LEDs work fine with some voltage drop, colors should remain true even at 4V, whereas the Pi will start to have trouble. So if you give the LEDs their own big battery, you can push the current up quite a bit (e.g. (2100, 2600) or so)…the Raspberry Pi, on its own dedicated battery supply, will be totally unaffected by the heavy current draw. The Pi is perfectly happy on a smaller phone-charging battery bank (e.g. 500 mA) if that’s what you have onhand.
Set Up Auto-Start
If everything looks good, last step is just to run the DotStarPiPainter.py script automatically when the system boots. If it’s currently running, press Control+C to stop the program. Then enter:
sudo nano /etc/rc.local
Just before the final “exit 0” line (and after the “gpio-halt” line, if you’ve installed that), insert the following line:
python /home/pi/DotStarPiPainter/DotStarPiPainter.py
Now walk through a full power cycle to confirm everything’s set:
- Press the halt button.
- Wait at least 15 seconds.
- Unplug both USB cables.
System is now fully powered down. The USB battery bank will sleep automatically when there’s no load. Now let’s boot:
- Plug in both USB cables; LEDs to the high-current port, Pi to the other port.
- Wait 30-60 seconds for system to boot.
- Plug in a USB drive containing images. You should see the loading sequence on the LEDs.
- Press the “Go” button. LEDs should activate.
Does it work? Grand! You can remove the WiFi dongle now; it’s not needed during normal use.
If it doesn’t work (but did pass the “first light” test), it’s probably a typo in the rc.local file.
