DPRG
DPRG List  



[DPRG] PWM vs Chopper

Subject: [DPRG] PWM vs Chopper
From: Kipton Moravec kip at kdream.com
Date: Sun Dec 28 19:34:01 CST 2003

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



More information about the DPRG mailing list