H-bridge braking -- DC Motor

I have an H-bridge with internal diodes for freewheeling on each igbt.
Braking can be accomplished the following ways: 1. Turning on both bottom fets.
2. Turning on both top fets. 3. Turning on one bottom fet, and letting the other bottom diode freewheel. This only provides braking in one direction though. 4. Turning on one top fet and letting the internal diode in the other top fet freewheel.
So I figured i'll try pulsing at 50/50 duty cycle the top and bottom fet on the same side of the bridge, with around 1uS deadtime to avoid shoot-through. ** I should expect half the braking force in both directions. However, i get NO braking in either direction. i.e. my motor is still very easy to move.
Why's that? i figured while the bottom fet is on, then the bootstrap cap on the top fet can charge up. So when I turn off the bottom fet, i can then turn on the top fet.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@yahoo.com wrote:

I'm not sure why it would break. "Breaking" really isn't breaking. A perm magnet electric motor is a generator. Spinning the motor produces current. "Breaking" is nothing more than putting a very high load on the generator making it harder to turn.
You need to supply a very high effective load on the motor, what you are doing, unless I misunderstand what you are describing, does not do this.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I meant that when the motor is stationary, you can spin it manually. if the bottom fets are turned on, it will be difficult to spin it manually. But like i said, i would expect 'half' the difficulty in moving it manually if i was pulsing both the top and bottom fet.
It's not imperative that i implement it this way, but i was just wondering.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Tue, Jul 12, 2005 at 06:43:54PM -0700, snipped-for-privacy@yahoo.com wrote:

You could use locked anti-phase drive where the motor polarity (direction) is PWM'd instead of the "enable" as in the usual sign-maginitude drive method. Locked anti-phase is efficient and you get braking by default as long as the bridge is enabled. With locked anti-phased, a 50% duty cycle stops the motor while >50% rotates the motor in one direction and <50% rotates the motor in the other. In the 50% duty cycle (stopped) case, you get the effect of good braking as the motor shaft tends to be held in place.
-Brian
--
Brian Dean
ATmega128 based MAVRIC controllers
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Brian Dean wrote:

anti-phase breaking has two basic problems, (1) is is not very efficient and (2) it is not unprecidented that a high current alternation will burn up the motor. We had this problem with a high performance TRW a few years back.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Wed, 13 Jul 2005 03:11:18 -0700, mlw wrote:

Actually Locked-antiphase _can_ be quite efficient as long as you dont expect the motor to be a low loss inductor at high frequency (its not) So if you use a external inductor, locked anti-phase is quite good.
Peter Wallace
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Peter Wallace wrote:

I've tried to explain to this group the advantage of an LC circuit between the PWM amplifier and motor, but alas they don't want to hear it.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I was thinking of trying that 50% anti-phase pwm method on these ST proto boards I have.
A few questions:
1. At 50%, I know the motor will be stationary, BUT will it also be difficult to manually move in either direction (as compared to it being easy and free to move if all fets were off)?
2. Say i'm cruising along at 75%, and all of a sudden I put it to 50%. Will the motor abruptly brake as if it hit a brick wall? Or will it casually coast to a stop?
3. If the answer to (2) is that it will not brake and instead coast, how then can I get some braking? Do I gradually ramp the duty cycle from 75% to 50%, then start decrementing, so as to gradually go in reverse?
Thanks! Mike
Brian Dean wrote:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Wed, Jul 13, 2005 at 01:51:25PM -0700, snipped-for-privacy@yahoo.com wrote:

Yes, it will be difficult to move.

Depends on a few things but with powerful motors and a strong power supply, you can actually lock up the wheels doing this. My robot here is driven by a pair of custom dual intelligent motor drivers which use the locked-antiphase method of drive:
http://www.bdmicro.com/rover/
I use a PID algorithm to target velocity - each wheel is independently controllable so all 4 have to match precisely in order to track a straight line, which it does extremely well. But, by varying the PID parameters, which I can do on-the-fly, I can change the control dynamics to be either gliding smooth, even graceful - to near instant starts and stops, and very crisp. The point is, this tight control is happening using locked antiphase drive which can assert strong control over the motor forcing it to behave as commanded, more so than the typical sign-magnitude method in which the motor is free-wheeling during the off component of the duty cycle. Not so with locked anti-phase.

You do get a form braking as a side-effect of locked anti-phase. It's easy to come to a sudden stop - just present the 50% duty cycle. To come to a smooth stop, you need to ramp the duty cycle down to 50% at a rate proportional to how smoothly you want to stop. On my above robot, I use PID loops to control this and change the PID parameters on the fly depending on whether I want smooth, gliding motion or crisp, choppy motion. Either is possible by simply changing the PID constants.
-Brian
--
Brian Dean
ATmega128 based MAVRIC controllers
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Brian, I've always thought of doing anti-phase in the next design, and your answers have me convinced it's the better way to go, than the conventional turn-on-bottom-fet, and pulse the top.
You mentioned that you have four PID loops for 4 different wheels -- all on one microcontroller?? Which micro is that? I use the PIC18F series right now, and I don't do PID. Rather, the braking pwm duty cycle is fixed, and so is the acceleration ramp and maximum pwm duty cycle for max velocity. (By the way, the project is a pedestrian sliding door controller, which runs a 90V DC brushed pm motor; rectified DC bus voltage is 140VDC.
Anyhow, i have a few questions about your PID loop. 1. At what rate do you call your PID loop? I figure it all depends on how often the encoder counts change. And also the motor time constant, as Edward Kern mentions, also figures into how often to call the PID loop, right?
2. What is a 'motor time constant'? Is it simply the reaction time that the motor starts acting once i pulse pwm into it?
3. I've done a bit of PID for temperature control, but always had a problem of some stubborn integral buildup, which took a while to settle down. And if i lowered my integral term, i'd never hit my target. perhaps some slow ramping of the target would have eliminated by difficulties in the past. Anyhow, my temperature PID control that followed the standard formula took a few too many seconds to stabilize. I figure there was no way I can do PID for motor control that requires it to be stabilized within a few hundred milliseconds, or is there?
Do you just follow the standard equation, where you factor only the error into your P and I terms? Or do you do some other unique stuff like factoring the derivative into the error? There seems to be many proprietary techniques that work well, and that's why they're proprietary. So far, i haven't gotten the standard Pterm + Iterm + Dterm equation to work good for me.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Thu, Jul 14, 2005 at 12:26:57PM -0700, snipped-for-privacy@yahoo.com wrote:

On these motor drivers I happened to include a microcontroller on-board which off-loads this work. Each board actually incorporates 2 h-bridges and the microcontroller handling this is an Atmel AVR ATmega8 processor.
The board I made uses RS485 for communication with the host controller and the ATmega8 accepts commands from that interface. The ATmega8 hands both h-bridges using direct PWM controlling both direction (PWM signal) and the 'enable' line. It also senses current using a pair of the on-board A/D converter channels. Additionally, motor feedback is done using quadrature decoding, so it is decoding a pair of those as well. It has 8K of code space and if I recall there was around 3K left over after implementing the dual PID control, dual quadrature decoding, and the RS485 network protocl (ROBIN: http://www.bdmicro.com/code/robin/).
The host controller sends commands to the motor driver for both motors at once, specifying the desired velocity. The motor driver carries those out, using the PID algorithm to drive the motors to the commanded velocity. The PID parameters can also be changed on-the-fly as I mentioned over the RS485 bus, changing the platform dynamics as desired.
However, on this robot:
http://www.bdmicro.com/darpa-gc/
This robot uses 6 independent PID loops all running on a single processor board: one of my MAVRIC-IIB's. On this controller, the PID loops even use floating point and the MAVRIC-IIB handles it all with processing cycles to spare.
http://www.bdmicro.com/mavric-iib

Right - this is totally dependent on how much feedback you are getting. In general, the more feedback you recieve the faster you can make actuator responses. Lots of feedback + fast processor = tight control. Sparse feedback or slow processor = sluggish control. It all comes down to how many actuator adjustments can you make within a given time. It only makes sense to make an actuator adjustment when you have new feedback.
I have decent resolution encoders on my rover robot mentioned previously. They are built-in to the motors themselves and generate 4550 single phase pulses per revolution of the output shaft (wheel). I am evalating the PID loop every time the velocity is updated which is every 20 ms (pulses are counted for 20 ms and the total at the end of that time is the velocity). With my encoders, this is enough time to accumulate a few pulses even at extremely slow speed - speed is well-controlled down to maybe .5 cm per second or so.
With higher resolution encoders, I could update the velocity information at an even higher rate but for this robot, this rate gives more than enough control.
But with slower encoders, you won't be able to meaningfully make actuator adjustments very fast and the control will be sluggish. High feedback rates are critical to tight control.

This relates the motor's inductance to the armiture resistance. I haven't worked on a system where I've had to specifically take this into account. I can certainly see where this will affect control though - anything that introduces lag or a phase shift will affect your ability to control it. There is no such thing as "instantaneous response" when dealing with motors, though. Which is, of course, why PID was invented :-)

For the motor driver I described above, there is no _explicit_ I term. However, the "P" term is not purely "P" either. The P and I terms are sort've melded dealt with together. Remember I said that the PID loop targets velocity. When designing the control algorithm, I make the assumption that the actuator response for the current iteration is going to be close to the one for the previous iteration. Thus, while I compute a "P" term, I use it as a delta to the previous control signal. For example, if the armiture is spinning and giving 50 encoder counts per unit time (20 ms), but the target velocity is 60 encoder counts per unit time, the "P" term would be Kp*(60-50) Kp*10. I would then add this to the power level output to the driver (after also combining with the D term, see below).
So you can see that it also provides a similar function as what the usual "I" term does (but not exactly). I don't really care that my overall average velocity matches the target over a long period of time, which a more traditional I term would do. For example, the Electric Company will guarantee that over a long period of time the average AC Hz of the power line will be 60 Hz (in the U.S.), but at any given time, it might not be that quite precisely. The "I" term can do that, among other things. But I don't care about that for this application.
All I care is that the speed matches as closely as possible the commanded target, but also accounts for changes in environment. For example, if the robot encounters an incline, my algorithm will automatically adjust and divert more power to the drive motors to maintain the target speed. That's the other thing the "I" term normally does - counteracts these types of external influences. But it happens to go a little fast at one point, I specifically _don't_ want the PID loop to average that out by slowing the system down in order to achieve the target average. I just want it to back off a little until the target is acheived and maintain that as closely as it can, which the above cumulatively applied P term does very well.
I do also use a more traditional D term which tends to dampen any overshoot when a strong P constant is used. I.e., the D term is the typical Kd * (rate of change of the error) and subtracts from the Kp*(target - actual) to produce the overall result. I.e., if the velocity is rapidly approaching the target velocity, the D term dampens the control output to slow the rate of change in order to minimize overshoot.
If I were targeting position instead of velocity, I'd do this differently, of course. In that case, an explicit I term and the more traditional use of the P term would surely produce better results.
But entire books are written on this stuff ... too much to fit into a usenet post.
-Brian
--
Brian Dean
ATmega128 based MAVRIC controllers
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
thanks for the feedback. I'm not using PID right now, and if it takes at least 1 1/2 seconds for the perfectly tuned PID methods to settle out, I think i dont really need it for when the door opens. You see, my door takes no more than 1 to 1.5 seconds to open, after which it brakes and slows down (sort of abruptly) so as not to bang into the side bumper when it fully opens. Even if I can get PID in, the customer wouldn't notice much of a difference in the gracefullness of the movement.
However, i can find a use for PID for closing the sliding door, where ANSI codes dictate that it must not close more than 1 foot/second. Even then, probably only P without the "ID" is enough in this case. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Then again, maybe a position pid controller (rather than velocity) would be the answer.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@yahoo.com wrote:

You need what's called "antiwindup control" to fix I term buildup. See any introductory controls textbook.
                    John Nagle                     Team Overbot
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@yahoo.com wrote:

Hi, To get an idea of the amount of braking that you might be able to get with this approach, short the motor leads together and spin the motor. This is effectively what you are trying to do with the H Bridge. A properly functioning H bridge will have a little higher losses than a dead short, so you will not get quite this much braking effect.
Alternately, a closed loop motor control can provide active braking or back drive to try to force the motor speed down the velocity curve you want.
Bob
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Something's not working with this single top/bottom fet pulsing. It might be something to do with the internals of the IRAMS (international rectifier) part i'm using. I figure for now, i'll just stick with the bottom fet(s) braking.
what i had expected was to get 50% of my maximum braking "hold" in either direction.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@yahoo.com wrote:

I think that with both bottom fets on and freewheeling diodes on each FET, you will get pretty close to the max braking in either direction that is possible. My reasoning on it is that with the motor acting as a generator, the positive side of the motor will forward bias one fet and be clamped within Igen * RDSon of ground. The negative side of the motor will push the drain of the other fet and the cathode of the freewheeling diode below ground, where the diode will begin to conduct and the negative swing will be clamped at -Vdiode_drop. Reversing the motor direction will swap the FET and diodes that are conducting, but the result will be the same.
The comments about the diodes needing to be rated for the current are dead on. Substantial currents can be generated here, mostly limited by the series resistance of the motor, or the destruction of something.
Good Luck, Bob
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@yahoo.com wrote:

Again, why would it "break?" As far as I can see there is no circuit across the motor terminals, thus no resistence to current production of the motor, thus no breaking.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
When a dc permag motor is turned, it produces a voltage proportional to its velocity; if a resistance is placed over it, that voltage divided by the total loop resistance results in a current which will produce a torque that opposes the velocity. However, the motor also has inductance, so what really happens is that when the resistance is applied, the current grows like it would in any RL circuit. The trouble is, in your scheme, current cannot flow continuously in *either* direction. Thus, if your switching period is less than the electrical time constant of the motor, it won't work right. Instead, when the bridge switches in the direction that allows current to flow, it will begin to, but when it then switches back, the motor will ring that energy into the bridge as emi and the current will go to zero.
The mode of braking you describe has other problems as well. It is not variable, ie. there is no gradual stopping. With a mosfet bridge, if you reduce the pwm duty cycle below the current motor speed, the motor will brake gradually and the power will actually flow back into your batteries. While saving that energy is more of a concern in an application like an electric car, keep in mind that were your plan to be made to work, nearly all the energy would go into your diodes, and if whatever you are stopping has enough momentum those diodes may lose their magic smoke.
-eck.
ps.
mlw, the combination of your inability or unwillingness to understand the question and your frequency of posting answers to it is astounding. consider the following corrections:
mlw wrote:

"braking" means slowing something down. "breaking" means destroying something. they have different meanings and thus are spelled differently.
also, i don't see how applying a stopping force electromagnetically is any less "real" than applying a stopping force frictionally.

the circuit consists of a closed mosfet and a diode and is indeed a very high effective load.

as peter wallace said, an understanding of math and electronics is essential.

were there no circuit the resistance would actually be infinite. however, there is a circuit, just as he described. indeed, current production in the motor is precisely how braking works.
snipped-for-privacy@yahoo.com wrote:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.