| View previous topic :: View next topic |
| Author |
Message |
mjjun
Guest
|
 Posted: Tue Nov 18, 2008 9:37 pm Post subject: How to turn the PID parameters of the motor driver when the |
 |
|
In motion control, when we use the classic PID control, it's tedious to
turn the PID parameters. When the speed is low such as 500cnts/s or
1000cnts/s in the velocity model, the performance is much different from
the high speed. We can't have a overshoot following by steady state with no
or little vibration in the steady value. There is great vibration since we
can get little information from the encoder when the speed is low. So we
don't know how to turn the PID parameters enven how to evaluate what is
good performance when the speed is low. We're appreciate for any
suggestion. Thanks! |
|
| |
|
 Back to top |
linnix
Guest
|
| Posted: Tue Nov 18, 2008 9:37 pm Post subject: Re: How to turn the PID parameters of the motor driver when |
|
|
On Nov 18, 7:37 am, "mjjun" <mjjun1...@gmail.com> wrote:
| Quote: | In motion control, when we use the classic PID control, it's tedious to
turn the PID parameters. When the speed is low such as 500cnts/s or
1000cnts/s in the velocity model, the performance is much different from
the high speed. We can't have a overshoot following by steady state with no
or little vibration in the steady value. There is great vibration since we
can get little information from the encoder when the speed is low. So we
don't know how to turn the PID parameters enven how to evaluate what is
good performance when the speed is low. We're appreciate for any
suggestion. Thanks!
|
I assume you are trying to tune a 500 Hz (cycle/second) or 1KHz
motor. You start with finding the modes of the system, then drive it
with the proper equations. Reactive forces might change with speed,
but modes does not. |
|
| |
|
| Back to top |
Tim Wescott
Guest
|
| Posted: Tue Nov 18, 2008 11:30 pm Post subject: Re: How to turn the PID parameters of the motor driver when |
|
|
On Tue, 18 Nov 2008 09:37:51 -0600, mjjun wrote:
| Quote: | In motion control, when we use the classic PID control, it's tedious to
turn the PID parameters. When the speed is low such as 500cnts/s or
1000cnts/s in the velocity model, the performance is much different from
the high speed. We can't have a overshoot following by steady state with
no or little vibration in the steady value. There is great vibration
since we can get little information from the encoder when the speed is
low. So we don't know how to turn the PID parameters enven how to
evaluate what is good performance when the speed is low. We're
appreciate for any suggestion. Thanks!
|
Your problem isn't really in controlling the motor itself, it arises from
using the an encoder, whose output becomes insufficient as the speed gets
very low.
I'll tell you right now, if you don't happen to have the hardware in
place than you need and if you can't add it, then your options are
limited.
First, and conceptually easiest, change your sensor: add a tachometer to
your motor, get an encoder with many more counts, or use a resolver. You
probably don't have room or budget to do any of these or you would have
already, but it's nice to think about.
With the tachometer, feed it's output to and ADC, and there you are --
velocity feedback. You'll have to put some deadband around your position
error so you don't hunt around an integer increment of the encoder, but
that's life.
With the enhanced resolution encoder or the resolver, it's even easier --
just change your scaling, and there you are. Motor systems always have
oddball start-stop behavior because of friction, if you select an encoder
with a resolution well below the limits of this nastiness then you will
have done your best.
If your stuck with your mechanical plant, but you can hang timers on the
encoder inputs, then time the edges of the motor pulses to get the motor
speed. Your "vibration" is most likely jerkiness caused by inaccurate
speed estimates caused by encoder resolution, coupled with insufficient
filtering in your differentiator -- keying off of the phase transition
times will go a long way to alleviating this problem.
If you can't do _that_, then you're getting into some pretty difficult
territory. The best bit of control system wisdom that I ever heard from
a greybeard was "you can't make a silk purse out of a sow's ear". Bode
proved part of this theorem with his Sensitivity Integral, which says you
can't make the silk purse if your bandwidth is restricted; experience and
common sense tells you that any real system is going to have a bandwidth
that's restricted by the mechanical plant. If your mechanical plant is
so restricted that it's a sow's ear -- there you are.
So you can experiment with deadband and with changing your tuning
parameters as the motor speed changes, and you may be able to get
something that works well enough with what you have. But be careful,
because you may also end up with an overly-tuned system that only works
on your laboratory test example, and completely fails to work in the real
world.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html |
|
| |
|
| Back to top |
Neil
Guest
|
| Posted: Thu Nov 20, 2008 9:07 am Post subject: Re: How to turn the PID parameters of the motor driver when |
|
|
Tim Wescott wrote:
| Quote: | On Tue, 18 Nov 2008 09:37:51 -0600, mjjun wrote:
In motion control, when we use the classic PID control, it's tedious to
turn the PID parameters. When the speed is low such as 500cnts/s or
1000cnts/s in the velocity model, the performance is much different from
the high speed. We can't have a overshoot following by steady state with
no or little vibration in the steady value. There is great vibration
since we can get little information from the encoder when the speed is
low. So we don't know how to turn the PID parameters enven how to
evaluate what is good performance when the speed is low. We're
appreciate for any suggestion. Thanks!
Your problem isn't really in controlling the motor itself, it arises from
using the an encoder, whose output becomes insufficient as the speed gets
very low.
I'll tell you right now, if you don't happen to have the hardware in
place than you need and if you can't add it, then your options are
limited.
First, and conceptually easiest, change your sensor: add a tachometer to
your motor, get an encoder with many more counts, or use a resolver. You
probably don't have room or budget to do any of these or you would have
already, but it's nice to think about.
With the tachometer, feed it's output to and ADC, and there you are --
velocity feedback. You'll have to put some deadband around your position
error so you don't hunt around an integer increment of the encoder, but
that's life.
With the enhanced resolution encoder or the resolver, it's even easier --
just change your scaling, and there you are. Motor systems always have
oddball start-stop behavior because of friction, if you select an encoder
with a resolution well below the limits of this nastiness then you will
have done your best.
If your stuck with your mechanical plant, but you can hang timers on the
encoder inputs, then time the edges of the motor pulses to get the motor
speed. Your "vibration" is most likely jerkiness caused by inaccurate
speed estimates caused by encoder resolution, coupled with insufficient
filtering in your differentiator -- keying off of the phase transition
times will go a long way to alleviating this problem.
If you can't do _that_, then you're getting into some pretty difficult
territory. The best bit of control system wisdom that I ever heard from
a greybeard was "you can't make a silk purse out of a sow's ear". Bode
proved part of this theorem with his Sensitivity Integral, which says you
can't make the silk purse if your bandwidth is restricted; experience and
common sense tells you that any real system is going to have a bandwidth
that's restricted by the mechanical plant. If your mechanical plant is
so restricted that it's a sow's ear -- there you are.
So you can experiment with deadband and with changing your tuning
parameters as the motor speed changes, and you may be able to get
something that works well enough with what you have. But be careful,
because you may also end up with an overly-tuned system that only works
on your laboratory test example, and completely fails to work in the real
world.
|
Why not change from measuring counts per second to measuring seconds
per count, when the speed is slow. Then convert that to counts per
seconds and continue? |
|
| |
|
| Back to top |
mjjun
Guest
|
| Posted: Fri Nov 21, 2008 9:17 am Post subject: Re: How to turn the PID parameters of the motor driver when |
|
|
| Quote: | On Tue, 18 Nov 2008 09:37:51 -0600, mjjun wrote:
In motion control, when we use the classic PID control, it's tedious
to
turn the PID parameters. When the speed is low such as 500cnts/s or
1000cnts/s in the velocity model, the performance is much different
from
the high speed. We can't have a overshoot following by steady state
with
no or little vibration in the steady value. There is great vibration
since we can get little information from the encoder when the speed is
low. So we don't know how to turn the PID parameters enven how to
evaluate what is good performance when the speed is low. We're
appreciate for any suggestion. Thanks!
Your problem isn't really in controlling the motor itself, it arises from
using the an encoder, whose output becomes insufficient as the speed gets
very low.
I'll tell you right now, if you don't happen to have the hardware in
place than you need and if you can't add it, then your options are
limited.
First, and conceptually easiest, change your sensor: add a tachometer to
your motor, get an encoder with many more counts, or use a resolver. You
probably don't have room or budget to do any of these or you would have
already, but it's nice to think about.
With the tachometer, feed it's output to and ADC, and there you are --
velocity feedback. You'll have to put some deadband around your position
error so you don't hunt around an integer increment of the encoder, but
that's life.
With the enhanced resolution encoder or the resolver, it's even easier --
just change your scaling, and there you are. Motor systems always have
oddball start-stop behavior because of friction, if you select an encoder
with a resolution well below the limits of this nastiness then you will
have done your best.
If your stuck with your mechanical plant, but you can hang timers on the
encoder inputs, then time the edges of the motor pulses to get the motor
speed. Your "vibration" is most likely jerkiness caused by inaccurate
speed estimates caused by encoder resolution, coupled with insufficient
filtering in your differentiator -- keying off of the phase transition
times will go a long way to alleviating this problem.
If you can't do _that_, then you're getting into some pretty difficult
territory. The best bit of control system wisdom that I ever heard from
a greybeard was "you can't make a silk purse out of a sow's ear". Bode
proved part of this theorem with his Sensitivity Integral, which says you
can't make the silk purse if your bandwidth is restricted; experience and
common sense tells you that any real system is going to have a bandwidth
that's restricted by the mechanical plant. If your mechanical plant is
so restricted that it's a sow's ear -- there you are.
So you can experiment with deadband and with changing your tuning
parameters as the motor speed changes, and you may be able to get
something that works well enough with what you have. But be careful,
because you may also end up with an overly-tuned system that only works
on your laboratory test example, and completely fails to work in the real
world.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it
says.
See details at http://www.wescottdesign.com/actfes/actfes.html
Thank you very much for your good advise. We also want know what |
resolution of the encoder is appropriate to our application. Is there any
exact formula to compute? Thank you for your advise again! |
|
| |
|
| Back to top |
mjjun
Guest
|
| Posted: Fri Nov 21, 2008 9:17 am Post subject: Re: How to turn the PID parameters of the motor driver when |
|
|
| Quote: | Tim Wescott wrote:
On Tue, 18 Nov 2008 09:37:51 -0600, mjjun wrote:
In motion control, when we use the classic PID control, it's tedious
to
turn the PID parameters. When the speed is low such as 500cnts/s or
1000cnts/s in the velocity model, the performance is much different
from
the high speed. We can't have a overshoot following by steady state
with
no or little vibration in the steady value. There is great vibration
since we can get little information from the encoder when the speed
is
low. So we don't know how to turn the PID parameters enven how to
evaluate what is good performance when the speed is low. We're
appreciate for any suggestion. Thanks!
Your problem isn't really in controlling the motor itself, it arises
from
using the an encoder, whose output becomes insufficient as the speed
gets
very low.
I'll tell you right now, if you don't happen to have the hardware in
place than you need and if you can't add it, then your options are
limited.
First, and conceptually easiest, change your sensor: add a tachometer
to
your motor, get an encoder with many more counts, or use a resolver.
You
probably don't have room or budget to do any of these or you would have
already, but it's nice to think about.
With the tachometer, feed it's output to and ADC, and there you are --
velocity feedback. You'll have to put some deadband around your
position
error so you don't hunt around an integer increment of the encoder, but
that's life.
With the enhanced resolution encoder or the resolver, it's even easier
--
just change your scaling, and there you are. Motor systems always have
oddball start-stop behavior because of friction, if you select an
encoder
with a resolution well below the limits of this nastiness then you will
have done your best.
If your stuck with your mechanical plant, but you can hang timers on
the
encoder inputs, then time the edges of the motor pulses to get the
motor
speed. Your "vibration" is most likely jerkiness caused by inaccurate
speed estimates caused by encoder resolution, coupled with insufficient
filtering in your differentiator -- keying off of the phase transition
times will go a long way to alleviating this problem.
If you can't do _that_, then you're getting into some pretty difficult
territory. The best bit of control system wisdom that I ever heard
from
a greybeard was "you can't make a silk purse out of a sow's ear". Bode
proved part of this theorem with his Sensitivity Integral, which says
you
can't make the silk purse if your bandwidth is restricted; experience
and
common sense tells you that any real system is going to have a
bandwidth
that's restricted by the mechanical plant. If your mechanical plant is
so restricted that it's a sow's ear -- there you are.
So you can experiment with deadband and with changing your tuning
parameters as the motor speed changes, and you may be able to get
something that works well enough with what you have. But be careful,
because you may also end up with an overly-tuned system that only works
on your laboratory test example, and completely fails to work in the
real
world.
Why not change from measuring counts per second to measuring seconds
per count, when the speed is slow. Then convert that to counts per
seconds and continue?
|
Your ideal is good and novelty! But how can we achieve it as the present
encoder mostly measures by counts per second! Thank you for your advise! |
|
| |
|
| Back to top |
David Brown
Guest
|
| Posted: Fri Nov 21, 2008 9:17 am Post subject: Re: How to turn the PID parameters of the motor driver when |
|
|
mjjun wrote:
| Quote: | Neil wrote:
Why not change from measuring counts per second to measuring seconds
per count, when the speed is slow. Then convert that to counts per
seconds and continue?
Your ideal is good and novelty! But how can we achieve it as the
present encoder mostly measures by counts per second! Thank you for
your advise!
|
It's not exactly novel, but it is certainly a good idea. You need some
sort of timer triggered on the edges of your encoder inputs, and simply
time the length of the pulses. Just make sure you trigger on the same
edge of the same signal each time (encoder pulses make *look* square on
an oscilloscope, but they are never truly square). |
|
| |
|
| Back to top |
David Brown
Guest
|
| Posted: Fri Nov 21, 2008 9:17 am Post subject: Re: How to turn the PID parameters of the motor driver when |
|
|
Tim Wescott wrote:
<snip>
Could you please avoid using two hyphens as an em-dash in your posts?
After re-wrapping in later quotations, these have ended up at the start
of a line and then newsreaders will treat them as the start of a
signature, and snip half the post.
mvh.,
David |
|
| |
|
| Back to top |
Stef
Guest
|
| Posted: Fri Nov 21, 2008 9:17 am Post subject: Re: How to turn the PID parameters of the motor driver when |
|
|
In comp.arch.embedded,
David Brown <david.brown@hesbynett.removethisbit.no> wrote:
| Quote: | mjjun wrote:
Neil wrote:
Why not change from measuring counts per second to measuring seconds
per count, when the speed is slow. Then convert that to counts per
seconds and continue?
Your ideal is good and novelty! But how can we achieve it as the
present encoder mostly measures by counts per second! Thank you for
your advise!
It's not exactly novel, but it is certainly a good idea. You need some
sort of timer triggered on the edges of your encoder inputs, and simply
time the length of the pulses. Just make sure you trigger on the same
edge of the same signal each time (encoder pulses make *look* square on
an oscilloscope, but they are never truly square).
|
Not novel indeed and actually suggested by Tim in the post that was
replyed to:
Tim Wescott wrote:
| Quote: | speed. Your "vibration" is most likely jerkiness caused by inaccurate
speed estimates caused by encoder resolution, coupled with insufficient
filtering in your differentiator -- keying off of the phase transition
times will go a long way to alleviating this problem.
|
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)
"The move was on to 'Free the Lizard'"
-- Jim Hamerly and Tom Paquin (Open Sources, 1999 O'Reilly and Associates) |
|
| |
|
| Back to top |
CBFalconer
Guest
|
| Posted: Sat Nov 22, 2008 7:25 am Post subject: Re: How to turn the PID parameters of the motor driver when |
|
|
David Brown wrote:
| Quote: | mjjun wrote:
Neil wrote:
Why not change from measuring counts per second to measuring
seconds per count, when the speed is slow. Then convert that
to counts per seconds and continue?
Your ideal is good and novelty! But how can we achieve it as
the present encoder mostly measures by counts per second!
Thank you for your advise!
It's not exactly novel, but it is certainly a good idea. You
need some sort of timer triggered on the edges of your encoder
inputs, and simply time the length of the pulses. Just make
sure you trigger on the same edge of the same signal each time
(encoder pulses make *look* square on an oscilloscope, but they
are never truly square).
|
Instead of deciding on the method in advance, simply count both
timer ticks and events until one of the two exceeds a threshold,
then stop on the next occurence of the other. A division then
gives you the rate. That means two interrupts, and some common
code. Each can shut down the other, but startup launches both and
sets the thresholds.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section. |
|
| |
|
| Back to top |
CBFalconer
Guest
|
| Posted: Sat Nov 22, 2008 7:31 am Post subject: Re: How to turn the PID parameters of the motor driver when |
|
|
David Brown wrote:
| Quote: | Tim Wescott wrote:
snip
Could you please avoid using two hyphens as an em-dash in your
posts? After re-wrapping in later quotations, these have ended
up at the start of a line and then newsreaders will treat them
as the start of a signature, and snip half the post.
|
If your reader does that it is wrong. A sig marker is a line
containing ONLY "-- ". Nothing more (apart from the '\n'). If the
result of a rewrap there will be at least a quote marker before it.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section. |
|
| |
|
| Back to top |
David Brown
Guest
|
| Posted: Sun Nov 23, 2008 2:14 am Post subject: Re: How to turn the PID parameters of the motor driver when |
|
|
CBFalconer wrote:
| Quote: | David Brown wrote:
mjjun wrote:
Neil wrote:
Why not change from measuring counts per second to measuring
seconds per count, when the speed is slow. Then convert that
to counts per seconds and continue?
Your ideal is good and novelty! But how can we achieve it as
the present encoder mostly measures by counts per second!
Thank you for your advise!
It's not exactly novel, but it is certainly a good idea. You
need some sort of timer triggered on the edges of your encoder
inputs, and simply time the length of the pulses. Just make
sure you trigger on the same edge of the same signal each time
(encoder pulses make *look* square on an oscilloscope, but they
are never truly square).
Instead of deciding on the method in advance, simply count both
timer ticks and events until one of the two exceeds a threshold,
then stop on the next occurence of the other. A division then
gives you the rate. That means two interrupts, and some common
code. Each can shut down the other, but startup launches both and
sets the thresholds.
|
Yes, that's the way it is normally done if you have a wide enough range
of speeds. I started trying to explain that, but deleted my text
because it sounded too complicated for the OP (although your explanation
is simpler than my aborted attempt). |
|
| |
|
| Back to top |
David Brown
Guest
|
| Posted: Sun Nov 23, 2008 2:27 am Post subject: Re: How to turn the PID parameters of the motor driver when |
|
|
CBFalconer wrote:
| Quote: | David Brown wrote:
Tim Wescott wrote:
snip
Could you please avoid using two hyphens as an em-dash in your
posts? After re-wrapping in later quotations, these have ended
up at the start of a line and then newsreaders will treat them
as the start of a signature, and snip half the post.
If your reader does that it is wrong. A sig marker is a line
containing ONLY "-- ". Nothing more (apart from the '\n'). If the
result of a rewrap there will be at least a quote marker before it.
|
My newsreader (Thunderbird) is correct - it is reacting to lines that
contain only a "-- " in mjjun's earlier post (the one I replied to).
Try it out with your own newsreader.
It would appear to be mjjun's newsreader ("EmbeddedRelated.com usenet
HTML frontend") which is broken, and inserting the quote markers before
re-wrapping. Proper newsreaders can normally deal with such broken
quotation handling, but the wrapped sig marker seems to be a bigger
challenge. I realise that the "correct" reaction is to tell mjjun to
get a proper newsreader, rather than asking Tim to cramp his style and
avoid "--". |
|
| |
|
| Back to top |
pnachtwey
Guest
|
| Posted: Sun Nov 23, 2008 2:32 pm Post subject: Re: How to turn the PID parameters of the motor driver when |
|
|
On Nov 22, 12:14 pm, David Brown
<david.br...@hesbynett.removethisbit.no> wrote:
| Quote: | CBFalconer wrote:
David Brown wrote:
mjjun wrote:
Neil wrote:
Why not change from measuring counts per second to measuring
seconds per count, when the speed is slow. Then convert that
to counts per seconds and continue?
Your ideal is good and novelty! But how can we achieve it as
the present encoder mostly measures by counts per second!
Thank you for your advise!
It's not exactly novel, but it is certainly a good idea. You
need some sort of timer triggered on the edges of your encoder
inputs, and simply time the length of the pulses. Just make
sure you trigger on the same edge of the same signal each time
(encoder pulses make *look* square on an oscilloscope, but they
are never truly square).
Instead of deciding on the method in advance, simply count both
timer ticks and events until one of the two exceeds a threshold,
then stop on the next occurence of the other. A division then
gives you the rate. That means two interrupts, and some common
code. Each can shut down the other, but startup launches both and
sets the thresholds.
Yes, that's the way it is normally done if you have a wide enough range
of speeds. I started trying to explain that, but deleted my text
because it sounded too complicated for the OP (although your explanation
is simpler than my aborted attempt).
I think you still should have tried. It would convince the OP that |
increasing the resolution of his feedback is the way to go or at least
the first step. Companies like BEI make high resolution encoders that
can provide 500,000 counts per revolution.
Peter Nachtwey |
|
| |
|
| Back to top |
David Brown
Guest
|
| Posted: Mon Nov 24, 2008 3:57 am Post subject: Re: How to turn the PID parameters of the motor driver when |
|
|
pnachtwey wrote:
| Quote: | On Nov 22, 12:14 pm, David Brown
david.br...@hesbynett.removethisbit.no> wrote:
CBFalconer wrote:
David Brown wrote:
mjjun wrote:
Neil wrote:
Why not change from measuring counts per second to measuring
seconds per count, when the speed is slow. Then convert that
to counts per seconds and continue?
Your ideal is good and novelty! But how can we achieve it as
the present encoder mostly measures by counts per second!
Thank you for your advise!
It's not exactly novel, but it is certainly a good idea. You
need some sort of timer triggered on the edges of your encoder
inputs, and simply time the length of the pulses. Just make
sure you trigger on the same edge of the same signal each time
(encoder pulses make *look* square on an oscilloscope, but they
are never truly square).
Instead of deciding on the method in advance, simply count both
timer ticks and events until one of the two exceeds a threshold,
then stop on the next occurence of the other. A division then
gives you the rate. That means two interrupts, and some common
code. Each can shut down the other, but startup launches both and
sets the thresholds.
Yes, that's the way it is normally done if you have a wide enough range
of speeds. I started trying to explain that, but deleted my text
because it sounded too complicated for the OP (although your explanation
is simpler than my aborted attempt).
I think you still should have tried. It would convince the OP that
increasing the resolution of his feedback is the way to go or at least
the first step. Companies like BEI make high resolution encoders that
can provide 500,000 counts per revolution.
|
Actually, the resolution of the feedback is not necessarily relevant.
The *accuracy* of the feedback (i.e., the consistency of the positioning
of the encoder pulses at a given constant speed) is important - and
higher resolution encoders will have more accurate pulses. But the
resolution only affects the minimum sample time for your samples (and
thus the slowest speed you can measure in a given time interval). The
resolution of your sampling timers is more directly related to the
accuracy of the result.
But as I said, a higher resolution encoder will be more accurate, and is
therefore preferable. It may also let the OP use a simple
counts-per-time-interval measurement. |
|
| |
|
| Back to top |
|
