DPRG
DPRG List  



[DPRG] PWM vs Chopper

Subject: [DPRG] PWM vs Chopper
From: rljordan rljordan at airmail.net
Date: Sun Dec 28 13:57:00 CST 2003

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


More information about the DPRG mailing list