DPRG List

 [DPRG] Re: Controlling Motor Current Message index sorted by: [ date ] [ thread ] [ subject ] [ author ] Previous message: [DPRG] Re: Next message: [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" >To: "David P. Anderson" >Cc: "DPRG" >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: > > > > > > 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 > > ``` Previous message: [DPRG] Re: Next message: [DPRG] Re: Controlling Motor Current Message index sorted by: [ date ] [ thread ] [ subject ] [ author ] More information about the DPRG mailing list