PID Without a PhD, Finally

Embedded Systems Design (or whatever they call themselves) kept moving 
this around -- so I've revamped it, updated it, and posted it on the web.

Take a gander.  Please comment on anything you like/don't like.  I'm not 
sure if the way that I'm setting off the math is a Really Good Idea or a 
Really Bad Idea -- I'm trying to make it easy for the math-averse to skip 
over it, without breaking up the flow too much for folks who can read 
math without breaking stride.

http://wescottdesign.com/articles/pid/pidWithoutAPhd.pdf

-- 

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

On 04/14/2016 06:03 PM, Tim Wescott wrote:
> Embedded Systems Design (or whatever they call themselves) kept moving
> this around -- so I've revamped it, updated it, and posted it on the web.
>
> Take a gander.  Please comment on anything you like/don't like.  I'm not
> sure if the way that I'm setting off the math is a Really Good Idea or a
> Really Bad Idea -- I'm trying to make it easy for the math-averse to skip
> over it, without breaking up the flow too much for folks who can read
> math without breaking stride.
>
> http://wescottdesign.com/articles/pid/pidWithoutAPhd.pdf
>

I could have gotten the required PhD in the meantime...

Haha no just kidding that would be lame-o. Looks great! :)

You leave out math but include C code, I think that's defeating the
purpose.  If you can't explain it in non-technical words or a simple
picture... well, try harder :-)

You spend only one page on tuning, and give no examples of "If you see
this, try this" which is much more useful to the practical user.

You don't mention feed-forward terms at all.

In short, it looks much like all the other PID papers out there, and
wouldn't have helped me "get" PID back when I was trying to figure it
out.

The section on I - the last paragraph should go first, since the point
of the I term is to correct for long-term errors, and you don't even
mention it in the first paragraph.

The second paragraph in D should be first, and is probably the most
useful paragraph in the paper, if you don't already understand PID.

The other thing I always hated about PID papers is that they never gave
solid examples of the difference between controlling speed and
controlling position, or the more complicated case of
torque/speed/position nested PID loops for CNC control.

I'm reminded of a YouTube video about how NOT to weld - the guy would
intentionally do it wrong various ways so you could compare his results
with your results, so you could figure out what you were doing wrong and
how to fix it.  Something like that for PID would be more useful than
showing an ideal situation.

On 4/14/2016 6:03 PM, Tim Wescott wrote:
> Embedded Systems Design (or whatever they call themselves) kept moving
> this around -- so I've revamped it, updated it, and posted it on the web.
>
> Take a gander.  Please comment on anything you like/don't like.  I'm not
> sure if the way that I'm setting off the math is a Really Good Idea or a
> Really Bad Idea -- I'm trying to make it easy for the math-averse to skip
> over it, without breaking up the flow too much for folks who can read
> math without breaking stride.
>
> http://wescottdesign.com/articles/pid/pidWithoutAPhd.pdf

I don't know if color is something that will be preserved, but that 
bright green for links actually hurts for me to look at.  Hard to miss 
though.

The PDF page numbering is off 1 from the text page numbers.  I'm pretty 
sure there is a way to deal with that.

Page 2 (text page number) paragraph 2, "Some command is given to a 
controller, and the determines a drive signal to be applied to the 
plant."  Is "the" the word you want?

Page 4, equation 1, you might explain the basis of this equation.  I 
assume the voltage actually controls the torque.  Friction force is a 
result of velocity and the acceleration is from the excess force until 
the motor speeds up.  Contrasted to the equation for the frictionless 
platform.

Page 6, paragraph 1, figure 5, you write "The magnet is attached to the 
stage", but the diagram calls it a "platform".  That is not hugely 
distracting, but if I know nothing about optical systems (which I don't) 
I might be thinking the "stage" is something different and start looking 
for what it means (I did).

Just for completeness, you might include the "position transducer" in 
your diagram.  I assume it measures the position of the platform rather 
than the magnet.

Page 6, paragraph 2, showing my ignorance I don't understand, "With this 
arrangement the force on the magnet is independent of the stage motion." 
  Doesn't a magnet moving in the coil create a current/voltage that 
interacts with the applied current/voltage?  Are we assuming the "good 
current-output amplifier" deals with this?

Page 6, equation 2, I don't see where Vp is defined.  It does not seem 
to be used anywhere else in the paper.

Page 8, equation 3, you define Th twice but don't say what units.  I 
assume it needs to be absolute temperature, Kelvin?  Two time constants 
are given, but no explanation for why two or what is different about 
them.  I don't know about others, but I have a hard time considering an 
equation I don't understand.  It keeps me from getting an understanding 
of how the controller would work.

I need to go now.  Please take this for what it is worth, free advice.

-- 

Rick

On Thu, 14 Apr 2016 19:09:26 -0400, DJ Delorie wrote:

> You leave out math but include C code, I think that's defeating the
> purpose.  If you can't explain it in non-technical words or a simple
> picture... well, try harder :-)
> 
> You spend only one page on tuning, and give no examples of "If you see
> this, try this" which is much more useful to the practical user.
> 
> You don't mention feed-forward terms at all.
> 
> In short, it looks much like all the other PID papers out there, and
> wouldn't have helped me "get" PID back when I was trying to figure it
> out.
> 
> The section on I - the last paragraph should go first, since the point
> of the I term is to correct for long-term errors, and you don't even
> mention it in the first paragraph.
> 
> The second paragraph in D should be first, and is probably the most
> useful paragraph in the paper, if you don't already understand PID.
> 
> The other thing I always hated about PID papers is that they never gave
> solid examples of the difference between controlling speed and
> controlling position, or the more complicated case of
> torque/speed/position nested PID loops for CNC control.
> 
> I'm reminded of a YouTube video about how NOT to weld - the guy would
> intentionally do it wrong various ways so you could compare his results
> with your results, so you could figure out what you were doing wrong and
> how to fix it.  Something like that for PID would be more useful than
> showing an ideal situation.

Good points.

The intended audience is writers of software for embedded processors, so 
the 'C' code may be easier to understand than English for some readers.  
This was implied when it was in its original context -- I think I'll at 
least put in an expanded forward.

-- 

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

On Friday, April 15, 2016 at 10:03:57 AM UTC+12, Tim Wescott wrote:
> Embedded Systems Design (or whatever they call themselves) kept moving 
> this around -- so I've revamped it, updated it, and posted it on the web.
> 
> Take a gander.  Please comment on anything you like/don't like.  I'm not 
> sure if the way that I'm setting off the math is a Really Good Idea or a 
> Really Bad Idea -- I'm trying to make it easy for the math-averse to skip 
> over it, without breaking up the flow too much for folks who can read 
> math without breaking stride.
> 
> http://wescottdesign.com/articles/pid/pidWithoutAPhd.pdf
> 
> -- 
> 
> Tim Wescott
> Wescott Design Services
> http://www.wescottdesign.com

One of the problems I find with digital control is tuning it. Unlike analogue where you have some pots you end up changing and re-compiling which is time-consuming. I end up have analogue pots and using the ADC to get a rough idea of values first. I suppose you can have a digital keypad with arrows.

The other thing is that you don't mention filtering on the derivative action. Also when you are looking for high bandwidth electr-mech systems like a hard disk, PID is not the best way. No mention on what limits bandwidth other than sampling interval - example - structural resonances.

On Thu, 14 Apr 2016 19:11:38 -0400, rickman wrote:

> On 4/14/2016 6:03 PM, Tim Wescott wrote:
>> Embedded Systems Design (or whatever they call themselves) kept moving
>> this around -- so I've revamped it, updated it, and posted it on the
>> web.
>>
>> Take a gander.  Please comment on anything you like/don't like.  I'm
>> not sure if the way that I'm setting off the math is a Really Good Idea
>> or a Really Bad Idea -- I'm trying to make it easy for the math-averse
>> to skip over it, without breaking up the flow too much for folks who
>> can read math without breaking stride.
>>
>> http://wescottdesign.com/articles/pid/pidWithoutAPhd.pdf
> 
> I don't know if color is something that will be preserved, but that
> bright green for links actually hurts for me to look at.  Hard to miss
> though.
> 
> The PDF page numbering is off 1 from the text page numbers.  I'm pretty
> sure there is a way to deal with that.
> 
> Page 2 (text page number) paragraph 2, "Some command is given to a
> controller, and the determines a drive signal to be applied to the
> plant."  Is "the" the word you want?

No - I think I wanted "this".

> Page 4, equation 1, you might explain the basis of this equation.  I
> assume the voltage actually controls the torque.  Friction force is a
> result of velocity and the acceleration is from the excess force until
> the motor speeds up.  Contrasted to the equation for the frictionless
> platform.

Hmm.  I'm trying to keep the math stuff short -- people write entire 
white papers on the behavior of motors alone.  Maybe put all the math 
into a several-page appendix?

To unpack a bit, the difference between the applied voltage and the 
motor's back-emf, divided by the armature resistance, determine the 
motor's armature current.  Torque is armature current times the motor's 
torque constant, and acceleration is torque divided by the motor's moment 
of inertia.  All of that is rolled into the kv and the time constant, in 
this case.

> Page 6, paragraph 1, figure 5, you write "The magnet is attached to the
> stage", but the diagram calls it a "platform".  That is not hugely
> distracting, but if I know nothing about optical systems (which I don't)
> I might be thinking the "stage" is something different and start looking
> for what it means (I did).

You're right, the nomenclature should be consistent.  I don't know about 
other people, but this is incredibly difficult for me.  It's a subset of 
the "don't toss jargon around" rule.  (Sometimes, the multiple-language 
problem is a consequence of incomplete solutions to removing jargon, at 
least for me).

> Just for completeness, you might include the "position transducer" in
> your diagram.  I assume it measures the position of the platform rather
> than the magnet.

Good point.

> Page 6, paragraph 2, showing my ignorance I don't understand, "With this
> arrangement the force on the magnet is independent of the stage motion."
>   Doesn't a magnet moving in the coil create a current/voltage that
> interacts with the applied current/voltage?  Are we assuming the "good
> current-output amplifier" deals with this?

The good current-output amplifier, and the frictionless support of the 
platform, deals with this.

> Page 6, equation 2, I don't see where Vp is defined.  It does not seem
> to be used anywhere else in the paper.

Vp comes out of the position transducer that I left off of the drawing.  
Yup, need to change something!

> Page 8, equation 3, you define Th twice but don't say what units.  I
> assume it needs to be absolute temperature, Kelvin?  Two time constants
> are given, but no explanation for why two or what is different about
> them.  I don't know about others, but I have a hard time considering an
> equation I don't understand.  It keeps me from getting an understanding
> of how the controller would work.

Well, I pulled the time constants out of my ear.  Or my donkey (I _do 
not_ get that cliche :P ).  Or something.

Te temperature of the load (Th) is determined by both the driving input 
(Vd) and the ambient temperature (Ta).  Again, I need to think about 
making that more clear without making the math-averse reader run away 
screaming.

> I need to go now.  Please take this for what it is worth, free advice.

I appreciate your time and trouble you've taken to read the thing and 
write your comments.

-- 

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

On Thu, 14 Apr 2016 16:33:58 -0700, gyansorova wrote:

> On Friday, April 15, 2016 at 10:03:57 AM UTC+12, Tim Wescott wrote:
>> Embedded Systems Design (or whatever they call themselves) kept moving
>> this around -- so I've revamped it, updated it, and posted it on the
>> web.
>> 
>> Take a gander.  Please comment on anything you like/don't like.  I'm
>> not sure if the way that I'm setting off the math is a Really Good Idea
>> or a Really Bad Idea -- I'm trying to make it easy for the math-averse
>> to skip over it, without breaking up the flow too much for folks who
>> can read math without breaking stride.
>> 
>> http://wescottdesign.com/articles/pid/pidWithoutAPhd.pdf
>> 
>> --
>> 
>> Tim Wescott Wescott Design Services http://www.wescottdesign.com
> 
> One of the problems I find with digital control is tuning it. Unlike
> analogue where you have some pots you end up changing and re-compiling
> which is time-consuming. I end up have analogue pots and using the ADC
> to get a rough idea of values first. I suppose you can have a digital
> keypad with arrows.

For all the reasons you mention, nearly all of my systems end up with a 
header on the board someplace, attached to a simple menuing system that 
lets me twiddle gains from a terminal.  You can get USB to serial 
converters from SparkFun that talk to a UART at native 5V or 3.3V levels 
(depending on the flavor of the converter you get).

> The other thing is that you don't mention filtering on the derivative
> action. Also when you are looking for high bandwidth electr-mech systems
> like a hard disk, PID is not the best way. No mention on what limits
> bandwidth other than sampling interval - example - structural
> resonances.

Yea.  I state in there that the document pushes things as far as you can 
without doing the math -- trying to optimize the performance of something 
like a hard disk takes more than a bone-headed PID controller.

I left off filtering the derivative action originally because I had a 
5000 word limit.  I should consider how I can get it in there.  It 
borders on putting the math back in.

-- 

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

On Fri, 15 Apr 2016 03:37:58 +1000, Clifford Heath wrote:

> On 15/04/16 08:03, Tim Wescott wrote:
>> Embedded Systems Design (or whatever they call themselves) kept moving
>> this around -- so I've revamped it, updated it, and posted it on the
>> web.
>>
>> Take a gander.  Please comment on anything you like/don't like.  I'm
>> not sure if the way that I'm setting off the math is a Really Good Idea
>> or a Really Bad Idea -- I'm trying to make it easy for the math-averse
>> to skip over it, without breaking up the flow too much for folks who
>> can read math without breaking stride.
>>
>> http://wescottdesign.com/articles/pid/pidWithoutAPhd.pdf
> 
> Thanks - passed on to folk who might benefit.
> 
> One thing - in the text for Figure 5, you say "magnet is attached to the
> stage, which moves with an acceleration proportional to the coil
> current."
> 
> I've done exactly this with a large voice coil (4" diameter, 4" throw)
> with a constant *voltage*, and you get a *speed* proportional to the
> voltage, although the current quickly settles to a constant (-ish). I'm
> sure I don't need to explain why - but it might be worth mentioning back
> EMF at some point. It was a surprise to me, initially.
> 
> Clifford Heath.

I think maybe I should write a white paper on how motors work.  The 
principle of voice-coil motor behavior is pretty much the same as motors 
that turn in circles.

-- 

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

On Thu, 14 Apr 2016 17:03:53 -0500, Tim Wescott
<seemywebsite@myfooter.really> wrote:

>Embedded Systems Design (or whatever they call themselves) kept moving 
>this around -- so I've revamped it, updated it, and posted it on the web.
>
>Take a gander.  Please comment on anything you like/don't like.  I'm not 
>sure if the way that I'm setting off the math is a Really Good Idea or a 
>Really Bad Idea -- I'm trying to make it easy for the math-averse to skip 
>over it, without breaking up the flow too much for folks who can read 
>math without breaking stride.
>
>http://wescottdesign.com/articles/pid/pidWithoutAPhd.pdf

The boxed equations don't have any equals signs. I imagine that's
stuff that's understood, but maybe not for everyone.

-- 
John