H-bridge braking -- DC Motor

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.

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.

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
http://www.bdmicro.com/

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.

 
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

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.

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:

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
http://www.bdmicro.com/

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.

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
http://www.bdmicro.com/

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.

    You need what's called "antiwindup control" to fix I term buildup.
See any introductory controls textbook.

                    John Nagle
                    Team Overbot

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

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.

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

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.

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.

valemike@yahoo.com wrote: