Suitable controller for electrical drive

Peter Bencsik wrote:

Does the word "current" in  the above sentence refer to the present,
or to controlling the motor current?

How did you tune the response of the PI controller?


The I in PI is the function that is supposed to cause the actual
average speed to reach the setpoint speed, eventually, if the measured
variable for the controller is speed.


Motor current is roughly proportional to motor torque, so a motor
current controller is handy, if you want to control how torque ramps
up and down, in response to a speed error.  If you cascade the
setpoint of that controller to be from the output of a speed
controller you can have a pretty tunable response that compensated for
lots of variables, like battery voltage, motor temperature, etc.

John Popelish schrieb:

I meant the present controller implementation, currently we did not
monitor the motor current for control purposes.

Thanks for the hints, I will switch to a cascaded control based on motor
current and speed - this should do the job!

-pb

Peter Bencsik wrote:


You're leaving some stuff out:

* How are you driving the motor?
   - Voltage?
   - Current?
   - Continuous?
   - PWM?
* What variable are you trying to control (speed, I gather,
   but you should state it explicitly)?
* How are you sensing your system output?
   - Tachometer?
   - Shaft encoder?
   - GPS?

If you are trying to drive the thing at a constant speed then you should
be able to do quite well with a PI controller.  As long as the motor is
always driving the backlash goes away, you should be able to ignore it
unless the car is really creeping along.  Ditto with friction.

If you told me "I wanna control the speed of a DC motor driving a
(insert nearly anything here)" I would tell you that you want a PI or a
PID controller, with either a continuous or PWM'd voltage drive, for
simplicity.  If you are measuring velocity then a PI should do pretty
well; if you are measuring position and not differentiating it then
you'll probably need a PID or a PD.

Check my web page for articles -- PID Without a PhD should be helpful,
particularly if you are closing the loop with a microcontroller.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

In a general sense, The D component in a PID controller would allow you to
introduce an artificial friction factor, and consequently provide some
degree of dampening to any output oscillations. This could address the
'overshoot and stop' problem. Without additional data, a reliable solution
is difficult. It is possible that the controller is 'saturating', that is
going from one extreme to the other. An observation of the output control
variable might lead to a more conclusive solution. There are various methods
of data acquisition that might prove useful.

David  Corliss

Tim Wescott schrieb:

I am driving the motor by PWM and using a tachometer to get speed and
position.

The car should go on rather constant speed but very slow, so that it is
"creeping along". Thus, the control loop tends to produce periodical
stop-and-go cycles instead of a smooth movement. So, I would rather
accept a deviation from target speed than this oscillating behavior. On
the other hand I need a feedback controller in order to overcome the
situation that the car does not move at all at low battery speed.

So I am looking for a configuration that achieves the speed that is
closest to intended speed, while still being smooth.

Peter Bencsik wrote:

-snip-


Ahh.  You are probably running into problems with limit cycles due to
friction.  You want to read my article "Controlling Motors in the
Presence of Friction and Backlash" at
http://www.wescottdesign.com/articles/Friction/friction.html .  Your
problem could be used as an example in the article.  I suspect that
slowing your PWM down to a suitable range, or impressing a slow PWM on
your fast PWM, would go a long way to solving your problem.

Just as a side note: if I were designing your system I would probably
want to use a suitably high-resolution encoder instead of a tachometer.
  While encoders do have resolution issues at low speeds, they _don't_
have offset issues, which means that you can command an arbitrarily low
rate without having to worry about the mechanism going the wrong way or
stopping.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/