Shallow Thoughts : tags : electronics

PWM for LEDs and motors with a Raspberry Pi

I've written about how to drive small DC motors with an Arduino, in order to drive a little toy truck around. But an Arduino, while great at talking to hardware, isn't very powerful. It's easy to add simple sensors to the truck so it can stop before hitting the wall; but if I wanted to do anything complicated -- like, say, image processing with a camera -- the Arduino really isn't enough.

Enter Raspberry Pi. It isn't a super-fast processor either, but it's fast enough to run Linux, Python, and image processing packages like SimpleCV. A Raspberry-Pi driven truck would be a lot more powerful: in theory, I could make a little Mars Rover to drive around my backyard. If, that is, I could get the RPi driving the car's motors.

Raspberry Pi, sadly, has a lot of limitations as a robotics platform. It's picky about input voltages and power; it has no analog inputs, and only one serial port (which you probably want to use for a console if you're going to debug your robot reliably). But my biggest concern was that it has only one pulse-width modulation (PWM) output, while I needed two of them to control the car's two motors. It's theoretically possible to do software PWM on any pin -- but until recently, there were no libraries supporting that.

Until recently. I've been busy for the last month or two and haven't been doing much RPi experimenting. As I got back into it this week, I discovered something delightful: in the widely available python library RPi.GPIO, Software PWM is available starting with 0.5.2a.

Getting the right RPi.GPIO

Just what I'd been wanting! So I got an LED and resistor and plugged them into a breadboard. I ran a black wire from the RPi's pin 6, ground, to the short LED pin, and connected the long pin via the resistor to the RPi's pin 18 (GPIO 24) (see the RPi Low-level peripherals for the official GPIO pin diagrams).

With the LED wired up, I plugged in my serial cable, powered up the RPi with its Raspbian SD card, and connected to it with screen /dev/ttyUSB0 115200. I configured the network to work on my local net and typed sudo apt-get install python-rpi.gpio to get the latest version. It got 0.5.2a-1. Hooray!

I hurried to do a test:

pi@raspberrypi:~$ sudo python
Python 2.7.3 (default, Jan 13 2013, 11:20:46) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
>>> import RPi.GPIO as GPIO
>>> GPIO.setmode(GPIO.BCM)
>>> GPIO.setup(24, GPIO.OUT)
>>> led = GPIO.PWM(24, 100)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'PWM'

Whoops! But Raspbian said it was the right version ... I checked again with aptitude show python-rpi.gpio -- yep, 0.5.2a-1. Hmph!

After some poking around, I discovered that help(GPIO), after printing out an interminable list of exception classes, eventually gets to this:

    VERSION = '0.5.1a'

In other words, Rapsbian is fibbing: that package that Raspbian says is version 0.5.2a-1 is actually version 0.5.1a. (This is the sort of thing that makes Raspberry Pi such a joy to work with. Yes, that's sarcasm.)

Okay. Let's try removing that bogus Raspbian package and getting it from pypi instead:

apt-get remove python-rpi.gpio
pip install --upgrade RPi.GPIO

Then I tried the same test as before. Success! And now I was able to set the LED to half brightness:

led.start(50)

I was able to brighten and dim the LED at will:

led.ChangeDutyCycle(90)
led.ChangeDutyCycle(25)

I played with it a little while longer, then cleaned up:

led.stop()
GPIO.cleanup()

If you're experimenting with RPi.GPIO's PWM, you'll want to check out this useful 2-part tutorial:

• RPi.GPIO 0.5.2a now has software PWM – How to use it
• How to use soft PWM in RPi.GPIO 0.5.2a pt 2 – led dimming and motor speed control

What about motors?

So PWM works great for LEDs. But would it drive my little robotic car?

I unplugged my LED and wired up one of the SN754410 motor drivers circuits I'd wired up for the Arduino. And it worked just as well! I was able to control the motor speed using ChangeDutyCycle().

I'll write that up separately, but I do have one caveat: GPIO.cleanup(), for some reason, sets the pin output to HIGH. So if you have your car plugged in and sitting on the ground when you run cleanup(), it will take off at full speed. I recommend testing with the car on a stand and the wheels off the ground.

Update: the motor post is up now, at Driving two DC motors with a Raspberry Pi.

Tags: raspberry pi, hardware, electronics, robots
[ 20:00 May 04, 2013    More hardware | permalink to this entry | comments ]

Wiring up a surplus-store LCD display to an Arduino

Every now and then I think it might be handy to have some sort of display on the Arduino ... something a little more detailed than an LED that either blinks or doesn't.

Adafruit's 2-line LCD text display comes with a great Character LCD tutorial, but it's quite heavy, and includes a backlight I don't need. I wanted something more minimal.

The local surplus store always has lots of cheap LCDs, but they unfortunately tend to be unlabeled, so you can't tell which pin is which. But the other day I spied a very lightweight little display for $2.95 that actually had a label on it, so I grabbed it, figuring I'd be able to get the pinout from google. It said:

DENSITRON 2
617ASNG0441
0201 TAIWAN

Alas, googling produced no useful information for any of those numbers. Foiled again! It might as well have been unlabeled!

Wait -- let's not give up quite so quickly.

Adafruit's LCD Shield tutorial says most parallel displays have either 14 or 16 pins, while this one has 15. That's close, at least ... but comparing the two Ada tutorials, I could see that the pin assignments for the two displays were completely different even though both were 16-pin. I wasn't going to get pin assignments there.

Searching for just densitron 15-pin lcd found lots of displays that clearly weren't this one. But apparently a lot of them were similar to a display called an LM50. Perhaps mine used that pinout too.

So I tried it, and it worked with only a little experimentation. Here's the pinout:

LCD pin	Function	Arduino pin
1	Gnd	Gnd
2	+5 V	+5 V
3	Contrast	pot
4	RS	7
5	EN	8
6	RW	Gnd
7	D0
8	D1
9	D2
10	D3
11	D4	9
12	D5	10
13	D6	11
14	D7	12
15	(nonexistent backlight)

Or I can use the nice cable with the 8x2 connector that came with the display, which maps to these functions:

1 = Gnd	Contrast	RW	D0	D2	D4	D6
+5V	RS	EN	D1	D3	D5	D7

The Arduino LiquidCrystal library works just fine with it, using this initialization:

LiquidCrystal lcd(7, 8, 9, 10, 11, 12);

in the Liquid Crystal Arduino sketch.

Works great! I went back and grabbed another $3 display. So the moral is, even a complete hardware klutz shouldn't give up too easily: with the right web search terms and a little fiddling, you might just get it to work after all.

Tags: arduino, hardware, electronics
[ 19:25 Jun 11, 2011    More hardware | permalink to this entry | comments ]

An Arduino battery timer

I wrote in my OSCON report a few months back that I came home from the conference with an Arduino microcontroller kit and just enough knowledge and software to make LEDs blink. And so it sat, for a month or two, while I tried to come up with some reason I desperately needed a programmable LED blinker (and time to play with it).

But it turned out I actually did have a practical need for a customizable programmable gizmo. One of the problems with R/C combat flying is that you're so focused on keeping track of which plane is yours that it's tough to keep track of how long you've gone on the current battery. You don't want to fly a lithium-polymer battery until it gets so weak you notice the drop in power -- that's really bad for the battery. So you need a timer.

My transmitter (a JR 6102) has a built-in timer, but it's hard to use. As long as you remember to reset it when you turn on the transmitter, it displays minutes and seconds since reset. Great -- so all I need is somebody standing next to me who can read it to me. Looking away from the sky long enough to read the timer is likely to result in flying into a tree, or worse. (The new uber-fancy transmitters have programmable beeping timers. Much more sensible. Maybe some day.)

I could buy a kitchen timer that dings after a set interval, but what's the fun of that? Besides, I could use some extra smarts that kitchen timers don't have. Like audible codes for how long I've flown, so I can make my own decision when to land based on how much throttle I've been using.

Enter the Arduino. Those digital outputs that can make an LED blink work just dandy for powering a little piezo beeper, and it turns out the Atmel ATmega168 has a built-in clock, which you can read by calling millis().

So I wired up the beeper to pin 8 (keeping an LED on pin 13 for debugging) and typed up a trivial timer program, battimer.pde. It gives a couple of short beeps when you turn it on (that's so you know it's on if you can't see it), then gives a short beep at 9 minutes, a long one at 10, shorter one at 11, and thereafter gives (minutes MOD 10) beeps, i.e. two for 12, three for 13 and so forth. Fun and easy, and it works fine at the field once I worked out a way to carry it (it's in a camera bag hanging on my belt, with the beeper outside the bag so I can hear it).

Fun! It could use better codes, and a pause switch (for when I land, fiddle with something then go back up on the same battery). Of course, in the long run I don't actually want to devote my only Arduino kit to being a glorified stopwatch forever. I have further plans to address that, but that's for a later posting ...

Tags: hardware, arduino, electronics
[ 12:10 Oct 27, 2008    More tech/hardware | permalink to this entry | comments ]