After getting the PLL locked onto the signal from my ADXL202 tilt sensor and deriving separate left and right signals from it, I hooked it to the SN754410 H-bridge driver and wired up a motor salvaged from a toy car.
My goal is to control the motor’s direction using the H-bridge and its speed using pulse-width modulation (PWM)–the same signalling technique the sensor uses to indicate the magnitude of its tilt. I’d like the speed control to be proportional to the degree of tilt, so that a small tilt results in a slow correction from the motor, and a large tilt results in a faster correction.
With PWM speed control, the power to the motor is turning on and off at a fixed frequency, high enough to be irrelevant to the motor’s motion, but low enough not to cause problems with the induction of the motor’s windings. (Mine seems to be running at about 140Hz.) To make the motor go faster, leave the power on for a longer portion of each cycle before turning it off; to make it go slower, leave the power on for a shorter portion of each cycle.
In my first attempt, I wired the motor for locked antiphase driving. This control method constantly supplies power to the motor, but rapidly reverses its direction. To make the motor go faster forward, supply forward power for more of the time and reverse power for less of the time. This obviously consumes a tremendous amount of power, but also provides strong control over the motor’s behavior. It could be useful in getting a robot to stand still on a hillside, or hold its ground in a competitive setting without specifically trying to advance.
In my case, it just makes the motor vibrate. I suspect I’m not really supplying enough power to make it work, and the motor never does more than jerk a bit as I tilt the sensor toward its extremes. It was a nice idea–had it worked, it would have meant I could wire the sensor output directly into the motor driver’s input with no additional circuitry–but it just wasn’t meant to be.
For my second attempt, I used the left and right signals that I derive from the sensor and the phase-locked, 50% duty cycle signal, and wired them to the H-bridge inputs. Theoretically, this should have worked better than the locked antiphase control–with only one input active at a time, I should get more oomph out of the motor, and it might actually turn a bit instead of just jittering. Sadly, this still wasn’t the case. Apparently with this motor and only a 9V supply, 0-25% duty cycle isn’t enough to get it going, and certainly not enough go make it ramp up speed slowly with a slowly-increasing signal.
Those two methods were essentially freebies–all of the signals were available using parts I’d already wired onto the board. For my third attempt, I added a 74LS279 S-R latch, a logic device that remembers whether it has most recently been set (S) or reset (R) and holds its output accordingly.
I didn’t get very far in my experimentation before abandoning that line of pursuit as well. My thought was that I could use a master S-R latch to remember whether the motor was supposed to be turning forward or backward, and slave S-R latches to activate from the start of the duty cycle to the end of the “rightness,” or from the start of the “leftness” to the end of the duty cycle. This would change the effective duty cycle of the motor control from 0-25% to 0|50-75%.
The first complication was that my signal (sensor) and reference (PLL) don’t seem to be exactly in phase, or that the phase delay of negating one or the other is noticeable. When I view the derived left and right signals closely on my scope, I see a tiny spike at the start of each master duty cycle. Those spikes set and reset the forward-backward latch semi-randomly, preventing me from using this method without getting my phase timing more tightly calibrated than I want to have to rely on.
So just to test whether any part of the method was viable, I set up the left-tilted slave S-R latch to set (activate) as soon as the left signal is detected (remember, the earlier it is, the further left it’s tilted), and reset (deactivate) at the end of the master duty cycle. This gave a duty cycle of 50-75% for my S-R output, which I then fed into the H driver.
It was closer to what I wanted, at least; but not there yet. At 50% duty cycle, the motor is already running pretty fast for a small correction; and at 75% duty cycle, it’s perceptibly faster, but not as much so as I’d like. The real flaw is that even if this method worked, when it was nearly level, it’d oscillate between 50% forward and 50% backward. That’s a lot of action for a rig that’s already almost balanced.
I know, I know; the easy way to deal with this is to read the sensor with a PIC and set the motor behavior however I want in software. I’ll get there eventually. For now, though, I’m really hoping I can get this to work in discrete circuitry. Partly I’m interested in doing it for the experience (like building my own H-bridge board); partly I like thinking of this circuit as a low-level reflex, and doing it in software would make it feel more like a conscious action.
I’ll keep puzzling over more ways to do it in hardware–but I’m afraid it’s going to come down to inventing a linear pulse stretcher, which wasn’t on my calendar for January.