PDA

View Full Version : [Question(s)] Noob H-Bridge questions



Rudolph
11-29-2008, 01:54 AM
I'm pretty sure I know the answer to this one, but just to be certain... To speed control the motors attached to an h-bridge (specifically an L298HN*) I just PWM the enable pin(s), right?

The second thing bugging me; What's an intelligent-yet-simple way of adding a "balancer" between two motors being run off the same L298HN*? Looking at BEAM schematics I find h-bridge stuff that's got two pots for each side of each motor (8 pots total!). I know this is where things like optical wheel encoders come in but that feels like overkill for now. Should I just try it without first, then adjust the programming (aforementioned PWM) to compensate if necessary? It is possible that it won't matter, but the motors I have are fairly old and funky.

Thanks


* L298HN may be swapped for L293D (compatible). I've got the 298 already, but with its strange pin layout I may buy a DIP instead for simplicity.

jes1510
11-29-2008, 02:44 AM
You have a couple of options. First like you said you would pulse the enable pins with PWM after setting the direction pins. The second is to tie your enable pins high and pulse the direction pins with PWM.

I'm not sue what you mean by balancing. If you are concerned about keeping each wheel at a constant velocity then you need feedback from the wheels. Encoders are commonly used. If you are dead set against encoders then you can tie a couple of pots to an A/D port and use that to manually set a calibration value with your fingers. That will change though and you will probably wish you had used encoders. The final option would be to experiment a bit and find a different PWM value that gives you the results you want.

Rudolph
11-29-2008, 03:28 AM
Okay, so it doesn't really matter which input is pulsed. And yes, that's what I meant by balancing. At this point I don't need it to be extremely precise, nor do I want to spend much money, which is why I'm shying away from wheel encoders. Thank you kindly for the input!

This will be my first robot and is aiming for super-cheap. Five bucks worth of AVR brains plus a box of my old childhood Erector set (found it in my folks' garage yesterday!). I'll probably spring for a different h-bridge so I don't have to get a special board for the 298 (three bucks vs 20+). The expensive parts will be a pair of the Sharp IR distance sensors, and the AVR programmer.

If I can make this work then The Boss will authorize a budget increase for the next project :)

Adrenalynn
11-29-2008, 03:37 AM
Without some kind of effective trim, you're not going to have a 'bot worth much. You could build a wall-follower that trims by using the distance sensors to maintain a constant distance from the wall. Gonna look like it's been sampling the eggnog pretty heavily though... ;)

No0bert
11-29-2008, 08:06 AM
An acceleromator would solve your balancing problems

ScuD
11-29-2008, 08:15 AM
Pulsing the direction pins means the outputs give a complete voltage swing (complete forward to complete reverse) at high frequencies, since you're using PWM. This implies about twice as much stress on both your H-bridge and flyback diodes than when using the enable pins to PWM the outputs (from fully on to floating) so as a matter of getting some more prolonged use of your electronics, I suggest using the enable lines.

Manually offsetting your motors can be done in software either with pots, buttons, user interface,... just add or subtract an offset from your pwm values before entering them in the PWM registers.

Adrenalynn
11-29-2008, 01:47 PM
An acceleromator would solve your balancing problems

He means "trim" more than "balance".

Yes, you could accomplish it with two accelerometers, but why? The programming would be a PITA, and you're not getting wheel speed, but rather something more like Velocity Made Good - and in order to get that you're going to have to burn most of a fast microcontroller just to poll the accelerometers. If you're looking to make a balancing 'bot (like a Segue or similar), the solid-state-goodness of accelerometers is probably the only real way to go - in this case, it's going to be more expensive and more complicated than just counting the wheel revolutions...

Rudolph
11-29-2008, 06:15 PM
Indeed, "trim" is a more accurate word than "balance" for what I mean. It's not going to be a balancing bot, just a two-drive-wheels-and-a-caster thing. A "sampling the eggnog rolling gait" is okay for now, that's how people can tell it's a Rudolph bot, it'll walk like I do! LOL I will pay more attention to proper wheel encoders in a future project though (maybe not next, but a pair of sumo-bots for my son and I to play with will happen soon enough).

Good point Scud, hadn't thought about how modulating the direction pins could throw it between full forward to full reverse. Makes sense.

Thanks all for the knowledge!