motor when you brake. If you PWM the MOSFET, you
can adjust the braking strength that will be generated
to be proportional to the percentage of the “on” time
of the MOSFET.
Figure 1 shows a simple dynamic braking circuit.
This circuit uses an N-channel MOSFET; the diode D1
protects the MOSFET from reverse voltage — the
intrinsic diode of the MOSFET may be able to handle
the current, but I believe you can never be too careful.
The values of the resistors depend upon the MOSFET
you use, the PWM frequency you run at, and the
amount of current you expect to have to deal with
(in the case of the shunt resistor R1). In case you have
never worked with MOSFETs, I’ll give you a short primer
on the care and feeding of your microcontroller when
R2 limits the inrush current needed to charge the
Gate capacitor of the MOSFET to something that your
microcontroller will handle; typically 20 ma. R3 quickly
discharges the Gate capacitor when you have turned the
MOSFET off. The values of these resistors depends upon
the type of MOSFET that you are using. If you Google for
MOSFET driver circuits, you can quickly hone in on some
rules of thumb for sizing your resistors. For the casual
designer, there are some pretty wide specification
windows that will work just fine.
Notice one more thing about Figure 1. This brake
works best on a DC motor that turns in only one direction.
You will waste a lot of energy if you run this motor in
reverse. This circuit works fine (in a simplistic way) for a
motor that runs a hybrid car or a brushless DC motor;
both of these run their motor drivers in only one direction.
(Yes, a brushless motor will run backwards, but that is
because the field order is reversed, not the current
running in any winding.) Braking a motor that runs in
both directions is even more complex.
What I’m trying to say is that unless you are doing your
EE Masters Thesis on dynamic braking, I don’t recommend
trying to do dynamic braking on your robot. To make it
worth the effort, you’d need good motors, a robot that
has some real weight behind it, and a fast charging
Now to answer your second question: Why does your
DC motor get so hot when running locked anti-phase
speed control? The answer to this question is simple. No
matter what speed you are running, the locked anti-phase
motor has the same current running through it. With
sign-magnitude with slow speed, you have little current;
with high speed, you have more current running through it.
Locked anti-phase has both phases (forward and reverse)
running to it at all times. The resistance of wire means
that current causes losses in the wire due to the resistance
of the wire. Those power losses manifest as heat.
If your motor is not very efficient and takes a lot
of current to run fast, then it will heat up quickly when
running locked anti-phase. Locked anti-phase is great for
running efficient DC motors in applications where you want
Figure 1. Dynamic brake.
very fast reactions to speed changes and/or you want
tight control of the motor speed. Sign-amplitude is the
PWM of choice when you are using low efficiency motors
in an application where you don’t need fast response to
speed changes, and you are perhaps using a PID to control
Q. I have really enjoyed your column! It really is practical and tackles many problems robot builders face. I have used the PID algorithm successfully
many times for speed control of brushed DC motors at
relatively high speeds, but for lower speeds (1.5 radians
per second and less) and rapid motor reversals, I have had
a terribly hard time trying to get the motor to quickly and
smoothly reach the desired speed.
It’s most likely due to non-linearities such as the
motor’s static friction, etc. Do you know how I can fix this?
A. I have two suggestions, Matt. The first suggestion is to increase the resolution of your PID algorithm. If you are using eight bit numbers, go to 16. Or, if you
are using 16 bit numbers already, then check to see the
range of your sensor inputs. If your resolution is too crude,
then you will see jerky response to PID calculations at
slower speeds. If you aren’t using your “I” component, try
using it; I’ve seen PID algorithms smooth out with a light
touch of the Integral term.
My second recommendation is to use some form of
trapezoidal ramping function in your PID loop. Rather than
immediately giving your PID loop the new velocity, break
your velocity change into increments to slow your PID
response. I’ve found that this works exceedingly well when
you switch from one direction to another. In my columns
for November 2008 and again in April 2009, I showed a
PID algorithm that implements a smooth ramping function
for a PID algorithm. The November issue has code that you
can download from the SERVO Magazine website, as well.
I feel that the most likely fix will be my first one.
Especially if you experiment more with the Integral term.
Remember to NOT make that term too strong; a light touch
will smooth out most problems with slow speed transitions,
including those that have to deal with static friction. I’ve
used PID to “servo” low quality motors at pretty slow
speeds and found that it does work pretty well.
SERVO 10.2009 15