DPRG
DPRG List  



[DPRG] Re: Controlling Motor Current

Subject: [DPRG] Re: Controlling Motor Current
From: Chuck McManis cmcmanis at mcmanis.com
Date: Sat Dec 27 22:24:01 CST 2003

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
> >



More information about the DPRG mailing list