New Application Note - High Resolution PWM

[dkinzer]

Tony has written an excellent application note describing some ways to use the PWM capabilities of the ZX.
High Resolution Pulse Width Modulation

[mikep]

Excellent job Tony.

[spamiam]

Thanks for the praise.

I spent more time writing and testing this than I expected, but it works quite well.

Here is some of my own criticism of my AppNote:

The major motivator for this work was my need to PWM drive a motor. I found this to be the most unsatisfying section of the AppNote!

I never reached any definite answers on the "best" way to PWM drive a motor. At less than 100% drive, the torque of the motor seems to suffer terribly. No matter what exact technique is used, this seems to be true.

Also, the stall speed of the motors seems to be rather high. Anything under about 10% just does not seem to work, and the torque at these low levels is essentially nil.

I have varied the PWM technique ( PWM of the "Enable" pin of an H-Bridge, or locked anti-phase PWM of the direction pins), and varied the PWM frequency.

My observations are that the stall speed is improved with LOWER PWM frequency (I expected the reverse), and PWM of the enable pin seems to give lower stall speeds too (I thought it was going to be the opposite as well based on reports about the merits of locked anti-phase).

But at low PWM frequency, the motor gets an objectionable induction whine, and with locked anti-phase, the H-bridge gets warmer than at higher frequencies (less efficient?)

So, I have settled on a switching frequency as low as I can go without objectionable induction whine (about 10KHz), and I am currently using locked anti-phase because I can set forward and reverse, and the speed by changing only one setting. It seems to work OK.

But, since the torque is poor no matter what I have done, I need a speed feedback technique to allow good motor speed control under variable loads. But this is the subject of another post (and another AppNote?)

-Tony

[GTBecker]

> ... about 10KHz...

No torque? Slow the PWM down. Try 14Hz, or whatever is slowest, and
move up from there. The inductance (or is it reluctance?) of the motor
is what you're fighting and, at 10KHz, it's probably winning. Lower PWM
rates bring lower stall speeds, and higher torque - and higher current
and heat dissipation.

I've never understood why small motor folks like ultrasonic PWM rates
unless it is to avoid hearing it. If the task is to turn the shaft
aggressively, you will find much better control with lower rates. You
can hammer a motor armature with narrow, high-current pulses with
low-rate antiphase PWM to rotate it extremely slowly with high torque.
Shaft speed control is linear, too, in antiphase. And, of course, you
can go just as fast.

Realize, though, that you are also permitting the motor to draw much
higher current at low PWM rates, and _continuously_ in antiphase, so it
will overheat quickly if the rate is too low for that motor.


Tom

[spamiam]

> ... about 10KHz...

No torque? Slow the PWM down.

Realize, though, that you are also permitting the motor to draw much
higher current at low PWM rates, and _continuously_ in antiphase, so it
will overheat quickly if the rate is too low for that motor.


Tom

Thanks for the feedback.

I did find that lower PWM frequency improved things. I took it down as far as 500 Hz. This caused less objectional niose in the motor. It did improve stall speed. I presume that this means that torque is improved.

I suppose I can go lower. I did not find the limit of diminishing returns on low PWM frequencies. I just stopped because I was getting noticeably worse heating of the H-Bridge. And my power supply does not have infinite current output. I was thinking that I might be limited in part by the powersupply (vs battery power which would eventually be the source)

I also stopped testing lower frequencies because all the sources I found suggested that high frequencies (e.g. 20KHz) were the "best".

I was thinking that my observations may be spurious. But after what you say, maybe they are on target.

I will test further. I may need to alter BOTH the pulse width and frequency for low speed operation....

-Tony

[GTBecker]

I may need to alter BOTH the pulse width and frequency for low speed operation.

Varying the pulse width of a fixed PWM rate is the main control mode, but one can legitimately continuously vary the frequency, too. I've never done that, but I do have a steerable platform that can switch between sign/mag and antiphase. I expected that such a facility might be handy, and it was, to the extent that I found I did not need sign/mag in that drive.


Tom

[mikep]

I did find that lower PWM frequency improved things. I took it down as far as 500 Hz. This caused less objectional niose in the motor. It did improve stall speed. I presume that this means that torque is improved.

I suppose I can go lower. I did not find the limit of diminishing returns on low PWM frequencies. I just stopped because I was getting noticeably worse heating of the H-Bridge. And my power supply does not have infinite current output. I was thinking that I might be limited in part by the powersupply (vs battery power which would eventually be the source)

I also stopped testing lower frequencies because all the sources I found suggested that high frequencies (e.g. 20KHz) were the "best".

I don't understand the high frequency thing either but then I have limited experience with motors. I found that a low frequency of 80Hz worked just fine for my motors. As I remember higher frequencies (>500 Hz) didn't have enough torque to start the motor and I got motor whine at frequencies < 40 Hz.

I stayed away from locked-antiphase because it generates extra heat and wastes energy. I exclusively use sign-magnitude instead. You might want to try that.

Also check out my motor controller and PWM controller projects for some helpful hinots and advice: http://home.austin.rr.com/perks/micros/Projects/.

[spamiam]

I exclusively use sign-magnitude instead. You might want to try that.

Do you mean by this that you PWM the enable signal based on the magnitude and set the direction signals based on the sign?

I have fouind that this keeps the H-bridge cooler, and I presume it improved efficiency.

The stall speed is iomproved as well, and I presume that this shows that torque is better.

I will try out "very" low PWM frequencies and see what happens. The "high resolution" PWM driver included in the AppNote makes this very easy.

As a matter of fact, I will use 2 pots: one for speed, and one for PWM frequency.

I ought to be able to measure the required duty factor of the pwm to obtain a certain torque, and vary the frequency to get a nice graph.

Now I just need to get the speed feedback working. (see a different post on this subject)

This will be a very neat little science project. Maybe I can get my son (age 12 and just decided he wants to be an aerospace engineer) to help out.

-Tony

[mikep]

Do you mean by this that you PWM the enable signal based on the magnitude and set the direction signals based on the sign?

I have fouind that this keeps the H-bridge cooler, and I presume it improved efficiency.

The stall speed is iomproved as well, and I presume that this shows that torque is better.

These are exactly the reasons why I prefer sign-magnitude PWM. I use three inputs into the motor controller:

1. Magnitude - PWM waveform from 0 (stop) to 255 (full speed)
2. Sign - 0 forwards, 1 backwards
3. Enable - 0 disabled, 1 enabled

My motor controller chip (and I suspect others) do not recommend putting PWM on the enable line. Instead you need some combinatorial logic to have the appropriate PWM on each pair of motor driver inputs. The sign bit tells you which input to use.

Again I recommend you reading my motor controller project write up (and the numerous other articles on the Internet about motor control). Larry Barello is an expert in this area.

As a matter of fact, I will use 2 pots: one for speed, and one for PWM frequency.

When you say pots I assume you mean "logical pot" as the ZX can do all of this for you.

[spamiam]

Mike,

I did read your wrtie up on the motor contriller, but I need to ponder all of what you said. There was quite a lot of info there.

I am using the SN754410 quad Half-Bridge. I am using them as two full bridges in parallel to improve power handling. (BTW, this seems to be a very nice H-Bridge IC)

The datasheet does not say to void PWM'ing the enable signal. In limited testing (not under any significant load), PWM'ing the enable seems to work OK.

I am sure I could devise some other PWM technique with logic circuits to drive the directional signals. But, again, I wanted to keep it as simple as possible. One XOR logic IC to simplify the locked antiphase is acceptable, but If I can simply PWM the enable signal, so much the better.

Did your datasheet(s) specifically say that one should not PWM the enable signal for your H-bridge?

Right now, for testing, they are real potentiometers that I will be using to set the Frequency and speed. Eventually it will determine these parameters for itself. The motors I have turn around 60 or 70 rpm, which makes the poor little robot really truck along. 1/3 or 1/2 speed might be better. I originally got these motors thinking that speed control was going to be easy. Now I see that it is somewhat more complicated, especially if I want to be able to maintain a constant speed across varying loads.

-Tony

[mikep]

I am using the SN754410 quad Half-Bridge. I am using them as two full bridges in parallel to improve power handling. (BTW, this seems to be a very nice H-Bridge IC)

The thermal shutdown and DIL packaging is good but it is missing current sensing which I feel is important for good motor control.

The datasheet does not say to void PWM'ing the enable signal. In limited testing (not under any significant load), PWM'ing the enable seems to work OK.

I am sure I could devise some other PWM technique with logic circuits to drive the directional signals. But, again, I wanted to keep it as simple as possible. One XOR logic IC to simplify the locked antiphase is acceptable, but If I can simply PWM the enable signal, so much the better.

Did your datasheet(s) specifically say that one should not PWM the enable signal for your H-bridge?

Although using PWM on enable does work and I originally had my circuit configured that way, there are several reasons for not using PWM on the enable lines:

1. Read this article from Larry Barello http://seattlerobotics.org/encoder/2000 ... ontrol.htm. Particularly interesting is the discussion on the two different ways of doing sign-magnitude PWM (we have mentioned both) and the four quadrant control theory. Although I have not tried this, I believe with 4 quadrant control you can use current sensing to determine the back-EMF and therefore speed of your motor. There is at least one motor driver board on the market that does this.
2. My controller (L6205) requires an external R-C on the enable pins to set the shutdown time when an overcurrent condition is detected. A PWM signal on this line can interfere with this timing so I simply leave the enable lines high while running the motor. I also connect the outputs of my current sensing circuit to pull down to ground the enable lines if the current goes too high (but still below the current limit of the driver chip). This avoids the age-old problem of "diving" for the off switch on a trapped robot before it burns out running at maximum current. On my robot is quite interesting to run it into the wall and then watch the over current sensing LEDs flicker as the motor controller automatically grounds the enable line without any input from the microcontroller. I like this hardware only solution as it reduces the dependence on the microcontroller in case of problems.
3. For my circuit I also found a problem that during power up that there would be a brief PWM signal from the PWM controller. This was a result of using SPI controlled potentiometers that always centered (half speed) on power up. With separate enable lines, these I/O pins on the microcontroller are grounded on reset and therefore the motors are inactive until the enable lines are set high by the microcontroller.

I acknowledge that the extra combinatorial logic and the current sensing/chopper make the circuit more complex but I learnt a great deal by doing this circuit and I think it is technically better than the simplistic solution. If I was doing it all again I would probably create an AVR-based 4-channel PWM controller with overcurrent control logic. This would be an interesting project

[spamiam]

I believe with 4 quadrant control you can use current sensing to determine the back-EMF

I am not positive, but I think that back-emf is able to be used under all circumstances, as long as you can get the motor to freewheel to a stop (not using braking).

If you can get it to free wheel, then you stop the PWM for a moment and let the motor freewheel, You then quickly measure the generated voltage, then restore PWM driving.

I think this is easily done by lowering the enable signal, them measure the voltage across the motor (differential ADC). I have not investigated the availability of differential ADC on the ZX paltform, nor have I USED it on a plain AVR.

-Tony

[spamiam]

I just tested very low PWM rates in both locked anti-phase and sign-magnitude techniques.

At low PWM's the locked anti-phase REALLY heated up the H-Bridge. Essentially instantly, so I shut that one down quick.

The S-M technique shows very good performance down to pretty low PWM's.

I did find increased heating of the H-Bridge below 50Hz, but at 50Hz, the power dissipation of the bridge seems pretty good, not "cool", but more than warm. The stall PWM is at about 6% PWM setting, and gives about 1/8th of full speed.

Pretty acceptable.

Now I need to get the speed/direction feedback working.

I may need a ZX24A-E soon.

For 4 motors, 2 channels, I will need 4 directional pins, 2 hardware-PWM pins, 8 speed sensor pins (maybe I can get away with just 4 if I only measure 1 motor on each side).

Plus other pins for other tasks, and I am running low on a 24 pin ZX-24.

-Tony

[mikep]

For 4 motors, 2 channels, I will need 4 directional pins, 2 hardware-PWM pins, 8 speed sensor pins (maybe I can get away with just 4 if I only measure 1 motor on each side).

I'm confused by your statement. Presumably you are using differential (skid) steering for a robot with 2 axles. If that is not the case then you can ignore the rest of this append.

My only experience is with a single axle robot and in that case I used independent PWM channels for each wheel so I could do varying turns from a simple slow turn all the way down to a "tank" turn with the two wheels turning in opposite directions.

I know that 4 wheel robots are much harder. How are you achieving turns with only two PWM channels? It would seem that you need 3 or 4 PWM channels. I know there is some research in this area on how best to simultaneously control all 4 motors to achieve smooth skid turns in a 4-wheel drive robot.

What are you using for speed sensors? Presumably you have quadrature encoders either on each motor or each wheel. I didn't get that far with experimentation on encoders and ZBasic myself.

[spamiam]

I'm confused by your statement. Presumably you are using differential (skid) steering for a robot with 2 axles. If that is not the case then you can ignore the rest of this append.

I do plan on differential steering.

I know that 4 wheel robots are much harder. How are you achieving turns with only two PWM channels? It would seem that you need 3 or 4 PWM channels. I know there is some research in this area on how best to simultaneously control all 4 motors to achieve smooth skid turns in a 4-wheel drive robot.

Well, this is what I plan on exploring. Right now, I will be driving the 4 motors with just 2 channels: left and right. But I may need to know what the traction is for each of the motors, and therefore may need to know the speed of each of the motors. I will start with ONE motor for design purposes, then 2. Then I will see if I need more info than that. If so, then I need to get the info on all 4.

What are you using for speed sensors? Presumably you have quadrature encoders either on each motor or each wheel. I didn't get that far with experimentation on encoders and ZBasic myself.

Well, these motors are pretty "cheap". No built-in encoders. I wish they did have them. I am working out an encoder design. I will be testing out techniques for Hall-Effect sensors. The magnetic technique is pretty robust and resistant to mud, foreign objects, etc. I just have to see how the details work out. I have used a single sensor with multiole magnets as a speed sensor with no directional info with excellent results in the past.

-Tony