DPRG
DPRG List  



[DPRG] PWM vs Chopper

Subject: [DPRG] PWM vs Chopper
From: Earl Bollinger earlwbollinger at comcast.net
Date: Sun Dec 28 20:57:01 CST 2003

In my opinion:
Using the famous and most esteemed "KISS" principle pretty much makes it
a hands down winner to use a voltage regulator(s) on the motors. 
On a CNC Mill where your using AC wall power to apply the voltages and
currents to stepping motors is fine as you have a known constant with
voltage and current that is fairly stable, but batteries tend to screw
it all up as they start out high, then go through a good normal level,
then start to drop off, the really drop off fast.
Plus using an ADC to read voltage drops across a shunt is fine, but the
fluctuations, EMI and RFI noise levels forces you to use a fast ADC and
make many readings, throwing out the worst readings and averaging those
left over to get a good value to work with. So now it's gotten
complicated again. 
When I look (oscilloscope) at all the noise coming off the power lines
on my bigger motors, I wonder how anything works at all.
To me it appears that most of the MCU's couldn't do all this and still
have a robot do something too.
So then tossing in complex math, special IC chips, ADC's, and maybe
co-processors is all fine and dandy, but a simple voltage regulator is a
lot easier when I think about it.



-----Original Message-----
>From: dprglist-admin at dprg.org [mailto:dprglist-admin at dprg.org] On Behalf
Of Kipton Moravec
Sent: Sunday, December 28, 2003 7:32 PM
To: rljordan at airmail.net
Cc: DPRG List
Subject: Re: [DPRG] PWM vs Chopper

It is not much more complicated than straight PWM but requires a few
more 
parts.  On the plus side you will probably not blow up your H-Bridge, 
because you will not get over current.

This is a national Application note that talks about it.

http://www.national.com/an/AN/AN-828.pdf

http://focus.ti.com/lit/an/slua141/slua141.pdf


I am still looking for the paper I based mine off of.  These should get
you 
started.

Kip


At 01:52 PM 12/28/03, you wrote:
>Kip,
>
>Can you handle a similiar but more fundamental thread?
>
> >Kip said:
> > I understand PWM regulates voltage,
> > and a chopper regulates current.
>
>*** Would you explain the baics of a "chopper" circuit?
>
>I thought that was what happens when you use PWM.
>PWM "chops" the Voltage to manage Power to the motor.
>P = E * I. I assume "I" (current) stays almost constant.
>The motor "agerages" the PWM voltage and the
>result is net voltage and therefore variable power.
>
>Is a chopper a current control circuit, that provides
>constant voltage?
>
>*** Do you have an easy example of a "chopepr" ciruit?
>
>Thanks
>Bob
>
>-----Original Message-----
>From: dprglist-admin at dprg.org [mailto:dprglist-admin at dprg.org]On Behalf
>Of Kipton Moravec
>Sent: Sunday, December 28, 2003 11:12 AM
>To: Chuck McManis
>Cc: DPRG List
>Subject: Re: [DPRG] Re: Controlling Motor Current
>
>
>I guess Pete sent the message directly to you and not to the list also.
I
>am curious to see his whole message.  Could he send it to the list, or
>could you send me a copy.  It helps me explain when I see where people
get
>confused.
>
>Most everybody I see used PWM to control motor speed versus a chopper.
I
>understand PWM regulates voltage, and a chopper regulates current. Most
>microcontrollers have PWM but not built-in circuits for chopping.
>
>Do you believe that in most robots, (balancing and otherwise) it is
better
>to use a chopper with a PID circuit versus controlling PWM?
>
>When you use a chopper do you used PWM with a low pass filter to set
the
>chopper level?  Or do you use a DAC?.
>
>Kip
>
>
>At 10:25 PM 12/27/03, you wrote:
> >Hi Pete,
> >
> >[This is a bit long and I didn't trim the included messages because
they
> >are needed for context.]
> >
> >You are correct, you cannot "push" current through a motor, all you
can do
> >is regulate that current.
> >
> >What Dave is doing is balancing his robot, so his motors aren't
operating
> >like your typical DC motor where you apply a voltage and out comes
some
> >rotational velocity relative to the mass, friction, etc etc. Instead
when
> >completely balanced the motor doesn't move at all!
> >
> >As the motor begins to turn (because the robot is falling over) the
system
> >needs to apply enough voltage, to create the appropriate current,
based on
> >how far and how fast the robot is falling over. You can think of it
as
> >counter-balancing torque.
> >
> >>Exactly how do you control the current flow/torque through a motor?
> >
> >So in this scenario if the motor is given a voltage "V" we can assume
it
> >will develop a current equal to "V/r" where "r" is the motor winding
> >resistance. Since the motor is not turning there is no back EMF to
worry
> >about. As the motor begins to accelerate and the balancing bot
travels
> >faster and faster, the torque calculation is going to need to take
this
> >into account. (Hence the wheel position and velocity inputs)
> >
> >>Everything I have been taught about motors is that current draw is
only a
> >>reaction to the applied torque on the motor and the applied voltage.
Also
> >>you can not control the torque of a motor because it is also a
reaction to
> >>the outside environment.  The only thing you can do is monitor the
>velocity
> >>and position of the motor and adjust the input voltage to compensate
for
> >>desired versus actual velocity and position errors.
> >
> >Sort of, in a DC configuration the current flowing through a motor
winding
> >is determined by the formula (Vf-Vb)/Rw or the forward voltage minus
the
> >back EMF voltage divided by the resistance of the windings. This
current
> >squared and multiplied by the will be the amount of power that is
going to
> >heating up the windings, and this current time (Vf-Vb) will be the
total
> >power the motor is consuming.
> >
> >This statement :
> >         "Also you can not control the torque of a motor
> >          because it is also a reaction to the outside
> >          environment."
> >
> >Needs some special treatment. If you attach a lever arm to a motor
and
> >prevent the end of the arm from moving, then you have effectively
> >"stalled" the motor. If you then vary the voltage across the motor
> >terminals, you will see a proportional variation in the torque
applied to
> >the  lever arm. You are "in control" of that torque at all times.
However
> >the follow up, and this is where I think you were heading, is that
you
> >can't always predict how applying that torque will affect the
*system* to
> >which the motor is connected. Which is true in an "open loop" system
where
> >you cannot monitor the reaction to the motor.
> >
> >Pete then wrote:
> > > Unless I am not understanding the physics of how a motor
> > > works, you can't stuff current into a motor.  It only draws
> > > what is needs in an effort to try to maintain a certain
> > > speed based on the applied voltage and externally applied
> > > torques to the motor.  It is my understanding that PID
> > > controls can only adjust the applied voltage to a motor.
> > > It can monitor the actual current draw (which will tell
> > > you the externaly applied torque on the motor), rotational
> > > velocity, and position, but it can't directly control the
> > > actual amount of current entering the motor unless a
> > > current limiting circuit is used.
> >
> >First we have to get a couple things out of the way, there are two
> >different problems that one might solve with a PID algorithm. The
first,
> >and the one you are alluding to, is to keep the rotational speed of a
> >wheel constant. This application is useful for causing a robot to
travel
> >as a specific speed, and if it is differentially steered, in a
straight
> >line. The second application is the "servo" application, in that
> >application you are attempting to hold a specific position rather
than a
> >specific speed. In the second case when you are "on target" the motor
> >doesn't turn at all.
> >
> >So your understanding of motors is a bit flawed. Here we go...
> >
> >If you are using PID to control the speed of a motor, when you apply
a
> >voltage to the motor, three things come into play. First is the
winding
> >resistance which determines net current flow, the second is the back
emf
> >which is a product of the motors RPM, and the third is the internal
> >resistance of the power supply.
> >
> >The first thing that happens is that the back emf is zero (motor not
yet
> >turning), so the current through the motor becomes Vf/Rw. Now at that
> >current Vf is reduced by (Vf/Ri) which is the internal resistance of
the
> >power supply. Generally people ignore that one (we couldn't in our
> >Battlebot but for small DC motors its ok to ignore).
> >
> >Now the motor applies a torque, which is a function of the motor
geometry
> >and magnetic flux density, to the output shaft. This shaft is
presumably
> >attached to a wheel which is attached to your robot. The torque
applied is
> >the "stall torque" because there is no back EMF yet.
> >
> >If the robot is against an immovable object, then the motor will
continue
> >to draw Vf/Rw amps of current until the battery dies, the driver
circuit
> >melts, the windings melt, or the object gets out of the way :-) So
lets
> >assume there is nothing in front of the robot.
> >
> >The torque the motor is applying results in a force being applied by
the
> >tire on the rim of the wheel in a direction that is tangential to the
> >contact point of the wheel and the surface it is resting on. Since
we're
> >assuming this torque is sufficient to move the robot, the robot
> >accelerates based on Newton's laws where a = f/m. The velocity of
this
> >robot becomes 'at' where t is the time that passes since you've
applied
> >your force.
> >
> >Now we assume that at time "t1" (can't do subscripts, sorry), the
velocity
> >of your accelerating robot crosses the "desired" velocity. It is at
this
> >time a PID algorithm begins to apply "back pressure" in the form of
an
> >error signal which is the difference of the measured velocity and the
> >desired velocity. This correction factor is reflected by summing it
with
> >the input your microprocessor is giving, and the result is that the
> >microprocessor "backs off the gas." It does this by reducing the PWM
duty
> >cycle, which changes the effective "Vf" seen by the motor, and the
> >resulting torque (Vf-Vb)/Rw. That reduces the force on the wheels,
and if
> >the system has natural "drag" in the form of friction, then it will
begin
> >to decelerate. Interestingly, if it doesn't have natural drag, or its
> >being pushed ('cuz its going down hill) then the PID algorithm will
want
> >to apply *negative* torque (aka brake/reverse the motor).
> >
> >So the interesting thing to note here is that the torque being
produced by
> >the motor was already going down because as the robot went faster
back EMF
> >increased. Had it reached a point where the back emf had reduced the
> >torque to the point that it could *not* accelerate the robot any more
then
> >the PID algorithm would sit that with its foot pressing the "pedal to
the
> >metal" and the robot would still not go fast enough. Anyone with a
Honda
> >civic driving over mountains has experienced this feeling :-).
> >
> >But assuming there is "head room", which is to say more than enough
torque
> >to continue accelerating the robot, then the job of the PID algorithm
is
> >to back off on the torque until it exactly matches the drag and thus
> >maintains an even speed.
> >
> >The bottom line is that by controlling Vf, the PID algorithm is
> >controlling the energy input into the system. By measuring the
response at
> >the "output" of the system (in this case the wheel velocity), and
assuming
> >that all processes within the system are linear, it can treat
everything
> >between the battery and the wheel as a "black box" that will response
> >linearly with a change of input.
> >
> >In the case of Dave's application he is all about the position of the
> >motor, rather than its rotational velocity. In his case, if the pile
of
> >electronics, batteries, and structure don't create a center of
gravity
> >that is exactly over the axle, his robot will fall over. When it
starts to
> >fall, the sensors detect that. To counter balance the fall, a voltage
is
> >applied to the wheel motors, this creates a current of magnitude
(Vf/Rw).
> >
> >Now Dave uses just enough torque to counter balance the tipping
motion,
> >that causes the wheels to turn just enough such that the center of
gravity
> >is now over the axle. At which point the motors have no current in
them
> >and are thus producing a torque of 0. By adjusting his feedback loop
he
> >can introduce an intentional error that causes the wheels to not
> >completely recover the fall, and that causes the robot to translate
> >laterally. In this case Dave doesn't care about how fast the wheels
are
> >turning, he just wants to be sure to put enough side force on the
ground
> >to keep the base under the center of gravity. That side force is
created
> >by the motors when they try to turn the wheels. The amount of force
is
> >linearly related to the amount of torque the motors are putting out,
which
> >is linearly related to the current, which is linearly related to the
input
> >voltage.
> >
> >Dave cares about current (and torque), not voltage. So the output of
his
> >control loop produces a "torque signal". His problem stemmed from the
fact
> >that when the batteries were discharging the system that converted
his
> >torque signal into a current didn't compensate. He "fixed" it by
making
> >the batteries never change voltage. An alternative fix would have
been to
> >control the current directly. This is what a "chopper" circuit does,
and
> >what my drawing showed as a software implementation of a constant
current
> >circuit.
> >
> >
> >--Chuck
> >At 05:40 PM 12/27/2003, you wrote:
> >>Chuck,
> >>
> >>I can't respond to the drgplist from my home computer, so I am
bouncing
>this
> >>directly to you.
> >>
> >>Exactly how do you control the current flow/torque through a motor?
> >>
> >>Everything I have been taught about motors is that current draw is
only a
> >>reaction to the applied torque on the motor and the applied voltage.
Also
> >>you can not control the torque of a motor because it is also a
reaction to
> >>the outside environment.  The only thing you can do is monitor the
>velocity
> >>and position of the motor and adjust the input voltage to compensate
for
> >>desired versus actual velocity and position errors.
> >>
> >>For the last several months, I have read posts from a lot of people
(from
> >>DRPG, PARTS, and SRS) that talk about controlling motor torque by
> >>controlling the current going into the motor.
> >>
> >>Unless I am not understanding the physics of how a motor works, you
can't
> >>stuff current into a motor.  It only draws what is needs in an
effort to
>try
> >>to maintain a certain speed based on the applied voltage and
externally
> >>applied torques to the motor.  It is my understanding that PID
controls
>can
> >>only adjust the applied voltage to a motor.  It can monitor the
actual
> >>current draw (which will tell you the externaly applied torque on
the
> >>motor), rotational velocity, and position, but it can't directly
control
>the
> >>actual amount of current entering the motor unless a current
limiting
> >>circuit is used.
> >>
> >>If I am wrong here, can you tell me how PID directly controls the
amount
> >>current entering a motor or the output torque, other than its
indirect
> >>control by controlling the input voltage and reaction to the
externally
> >>applied torques?
> >>
> >>Pete Miles
> >>
> >>
> >>----- Original Message -----
> >>From: "Chuck McManis" <cmcmanis at mcmanis.com>
> >>To: "David P. Anderson" <dpa at io.isem.smu.edu>
> >>Cc: "DPRG" <dprglist at dprg.org>
> >>Sent: Saturday, December 27, 2003 4:41 PM
> >>Subject: Re: [DPRG] Re:
> >>
> >>
> >> > Hi Dave,
> >> >
> >> > I took your ascii drawing and augmented it with a current
feedback
>system:
> >> > <http://www.mcmanis.com/chuck/robotics/balance.html>
> >> >
> >> > If you were to implement this on the 68HC11, I would expect it
would go
> >> > something like:
> >> >
> >> > #define IK ?? /* current loop "P" constant */
> >> >
> >> > void pwm(int torque) {
> >> >      int direction, magnitude, duty_cycle;
> >> >      int ms, i;
> >> >
> >> >      if (torque < 0) {
> >> >          direction = 1;
> >> >          magnitude = -torque;
> >> >      } else {
> >> >          direction = 0;
> >> >          magnitude = torque;
> >> >      }
> >> >      for (ms = 0; ms < 40; ms++) {
> >> >          i = get_current();
> >> >          duty_cycle = pwm_convert(magnitude + (i1 -
magnitude)*IK);
> >> >          SET_DUTY_CYCLE(duty_cycle)'
> >> >          msleep(1);
> >> >      }
> >> > }
> >> >
> >> > What this would do, is create another control loop within your
initial
> >>loop
> >> > that changes the pwm() function from shipping a constant value,
to
> >>actually
> >> > setting the "desired current through the motor" value. You would
>eliminate
> >> > the msleep(40) in the main loop because this would run for 40mS
by
>itself.
> >> >
> >> > The function pwm_convert() takes an absolute current value
desired, and
> >> > converts it into a PWM duty cycle necessary to achieve that
current.
>Under
> >> > ideal conditions the sensed current value and the actual current
value
> >>will
> >> > match and the duty_cycle will remain unchanged, however as the
sensed
> >> > current becomes less than the desired current (because of battery
sag)
>the
> >> > "P" term will start to increase the actual duty cycle sent to
>compensate.
> >> > Further, if you're batteries were REALLY full, then you would get
>_more_
> >> > current than you wanted and the P term would back off the duty
cycle to
> >> > compensate.
> >> >
> >> > What this has accomplished is to switch the system from
controlling the
> >> > motors through voltage, and thus indirectly the current, to one
that
> >> > controls the current directly and is thus immune to changes in
battery
> >>voltage.
> >> >
> >> > --Chuck
> >> >
> >> >
> >> > _______________________________________________
> >> > DPRGlist mailing list
> >> > DPRGlist at dprg.org
> >> > http://nimon.ncc.com/mailman/listinfo/dprglist
> >> >
> >
> >
> >_______________________________________________
> >DPRGlist mailing list
> >DPRGlist at dprg.org
> >http://nimon.ncc.com/mailman/listinfo/dprglist
>
>
>_______________________________________________
>DPRGlist mailing list
>DPRGlist at dprg.org
>http://nimon.ncc.com/mailman/listinfo/dprglist
>
>_______________________________________________
>DPRGlist mailing list
>DPRGlist at dprg.org
>http://nimon.ncc.com/mailman/listinfo/dprglist


_______________________________________________
DPRGlist mailing list
DPRGlist at dprg.org
http://nimon.ncc.com/mailman/listinfo/dprglist



More information about the DPRG mailing list