Essay on PID Motor control

I posted an essay on PID Servomotor Control on my website, care to critique?

formatting link

Reply to
mlw
Loading thread data ...

As indicated in the begining of the text, it is not the appropriate place to learn about Laplace Transforms or Steady State Stability, but it is a very well written introductory text on PID control.

I didn't check the algorithm, but one note I'd make is to better display the code, using identation. Being really nitpick, different color for comments, but that's already too much.

Cheers

Padu

Reply to
Padu

One issue I have with heavily math based explanations is that the authors (And I have tended to be one as well) think that the math does most of the description. It is true, of course, that it does, but I find that if I am not "in deep" into the math of a specific problem, or have not used my "math skills" recently, it takes a lot of focus and thinking really understand and visualize it. More often than not, I'll find myself distracted.

PID is fundamentally simple math but with really complex behavior. (Isn't that always the way?) I wanted to be able to explain PID to a "highschool kid." This was my attempt.

I'll consider it, but I'm not sure I agree. If a few more people have the same aesthetic comment I probably will. It is just that I find colored text difficult to read.

As for the algorithm, it works pretty well. It does a fairly good job compensating for variability of sample intervals and the robot goes basically straight. I don't see any position error in the wheels, as I have run them for a couple hours and a couple chalk lines on the wheels kept in sync. It certainly works well within the margins of error inherent in a mobile robot.

Reply to
mlw

: > the code, using identation. Being really nitpick, different color for : > comments, but that's already too much.

: I'll consider it, but I'm not sure I agree. If a few more people have the : same aesthetic comment I probably will. It is just that I find colored text : difficult to read.

Since I generally print things to read, color doesn't make a different to me. On the other hand, a version to print without the sidebar would be appreciated. :-) Otherwise, it's lynx -dump and a pure-ascii version.

Reply to
Christopher X. Candreva

It's always good to see somebody adding robotics information to the web. I hope you'll continue.

I did have a suggestion. While I would not encourage you to go overboard on the math, I do think that a few simple, well-chosen equations might do a lot to clarify what you're doing, perhaps even more so than the code examples. Believe it or not, there are people who find syntax like "virtual ~PIDControl();" more opaque than a partial differential equation (well, maybe not a partial differential equation). So I don't think that you need to be any more reluctant about posting equations than you are about posting code.

Anyway, to see what I mean about using equations, consider the image at

formatting link
Now the equation uses calculus notation which I think that you could reasonably avoid. But if you look at the equation for a minute or so you might find yourself asking something like "why is the derivative term positive instead of negative". Well, the article I referenced does something a little non-standard. But the point is that the relationship between the P, I, and D terms is more apparent in the equation than it would be in code. That positive/negative sign issue would be totally swallowed up in code. In the equation it is available for inspection.

Finally I don't know who persuaded the software community that using a leading "m_" for all member variables was a good idea, but I've never cared for that convention. Reading code is hard enough without extra clutter thrown in. Of course, that's just my personal taste (not everyone likes Reggae music either). But just as an experiment some time, I propose that you do the following. Take a moderately dense, non-trivial class and do a global search and replace to remove the prefix. Then ask yourself which is easier to read.

Again, thank you for making your helpful addition to our collective robotics knowledge base.

Gary

Reply to
gwlucas

formatting link
Now that's an idea I'll consider. While I want to keep the ads and such so maybe I can get some money out of it, I can easily add a "Printer Friendly" link.

(That url will probably change if I add the printer friendly version.)

>
Reply to
mlw

For those people there are plenty of treatments of PID. I'm focusing on programmers that may or may not know the math, but are certainly more comfortable with abstract concepts.

I'm not reluctant to post the equations, it is just that there are so many PID descriptions heavily steeped in math that I wanted this one based only on the abstract concepts. I guess my feelings were that if you needed or wanted more math, you can back it up with something else, but if you are put off by the math, then you would be ale to read it.

Does that make sense?

Interestingly, for me at least, maybe I'm strange, I don't know, but I need more conceptual information. An equation does not impart the concepts as much as a graph or description.

For me, it is concepts first, reinforced with theory. Many people claim to learn with theory first, but my brain doesn't seem to work that way.

I think it is a great convention (obviously, I use it) because I know, without looking anywhere else, that any variable that starts with "m_" is part of my current object. If used consistently, it is a fantastic tool to avoid many coding problems, especially if you intend other people to read and use your code.

Perhaps C++ should have required "this->var" syntax, which does work, but there should be a way, either enforced by compiler or convention, to differentiate between "member" variables and local/global variables.

I also have some useful habits left over from my Windows programming days, namely incorporating the variable type into the variable name, like szName is a zero terminated string, pVar is a pointer to a var, etc. Not all of the "hungarian" notation, but a small subset of it.

Sorry, I have written and read too much code in my life to even bother. Do code reviews, QA code audits, and manage a several large software projects, you'll take back everything you said. The "m_" like "sz" or "p" or "n" or any naming convention for that matter does take time to get used too, but I find that variable names without this information are confusing because they don't carry enough information about themselves.

Take, for instance:

m_szId = 0;

What is that? Easy.. It is a zero terminated string that is a member variable of my current object. I'm setting it to zero so I know that it has no value. (A string set to 0 or NULL has no value). A simple naming convention makes that variable self documenting.

Now how about this:

id = 0;

What is it? Where is it? Why am I setting it to zero? Is "0" the "id?" Is "0" an uninitialized state?

My gripe with open source is that they tend not to use naming conventions and it is hard to get familiar with other people's code.

Reply to
mlw

"mlw" wrote

complete sense. you have already introduced the scope of your explanation. A good reference list or a "here's where to get more information" would suffice.

padu

Reply to
Padu

My commenting on a coding convention was a mistake because it diverted attention from the real intention of my post which was to thank you for your work and make a suggestion about adding a few equations to your text. Based on your reaction, perhaps I did not make my point clearly. I was not arguing for a mathematical treatment of PID... Those have their place but I, at least, am more comfortable with the non-mathematical treatment of a subject especially when I'm just getting started. I doubt many people would feel otherwise. So let me make one last attempt to clarify what I was saying. I'll do so with an example.

The Classical Greeks didn't have algebra. So everything they did in their geometry was stated in sentence form. You really have to admire how much they were able to accomplish with what must often have been an awkward way of expressing mathematical concepts. Consider the following statement: "the sum of the squares of the sides of a right triangle is equal to the sum of the hypotenuse." Now consider the alternative "a^2 + b^2 = c^2".

Now the algebraic statement makes no sense at all without the plain-text statement. But once you have the plain text in mind, it sure does make it easier to remember (and use).

Equations do not take the place of a good explanation. Actually, equations don't explain anything. What they do accomplish is to give us an exact formulation of an idea. They can also be manipulated and put into alternate forms that reveal nuances that might otherwise be non-obvious in a textual form. A non-calculus statement of the PID equation

PID = A * ProportionalError + B * IntegralError - C * DerivativeError

instantly reveals that there is a role for arbitrary coefficients mixed

in with real-world measurements. Seeing that, your reader might ask "Hmmm, I wonder where they come from?" In your article, it might have served as a seque to a discussion of tuning parameters.

So, the essence of my suggestion was simply that you consider two or three well-placed equations to clarify the relationships you describe in your text. I did not mean to suggest that you fundamentally alter your approach. Only to suggest that there were ways to reinforce it.

Gary

mlw wrote:

Reply to
gwlucas

What's really funny is that I don't know if any of my text books are still in print! (or where they are after the last couple moves) I wrote my first PID algorithm in the late 70s and while I learn something new every time I write a new one, I haven't needed a book or reference to do so in over 20 years.

If I knew I was going to live this long I would have take better care of my books :-)

Reply to
mlw

Perhaps, but "computer science" is a topic I really take seriously. My first teacher in the 70s was an ex-navy programmer, and she approached the subject as a math and a science. A math in that concepts are provable, and a science in that it is something you need to study and learn. Even back then, she as adamant that a "good" program is one that works, works efficiently, and can be understood by someone else.

I don't necessarily propose that everyone use the naming convention that I use, quite the contrary, but there should be some effort in the open source community to use one. a lot of the Open Source guys are very very bright but lack the discipline to make "good" (see above) code.

Actually, I like the verbal description better :-)

The PID initials are not quite enough, my implementation is basically this:

POW = (((E*E_GAIN) + (I*I_GAIN) + (D*D_GAIN)) * SCALE) + BIAS

POW = The calculated output power E = The current positional error D = The differential of the last error I = The integration of the error PE = The previous error SCALE = The "scale" of the calculation based on elapsed time since last BIAS = The offset to "zero" for POW plus acceleration

The actual algorithm is sort of an amalgam of PID and other control stuff. The SCALE factor is used to adjust the output calculation for a variable or indeterminate sample period. As long as it samples fast enough, it works. The BIAS allows for two things, first, systems that "stop" or zero output is not numerically zero, second, if you are accelerating, You can tweek the output power up or down in anticipation of a change in speed for the next sample.

However, this is all described clearly in the code :-)

Reply to
mlw

Pretty good I guess :)

Now about that web cam on the top of your robot ...

Developing any cool software for it perhaps like has been done with Evolution Robotics?

-- JC

Reply to
JGCASEY

When I get some time I will try. If I can get some money from the ads on my website, I'm going to buy an IR cross-hair laser LED and develop a visual ranging system.

Reply to
mlw

I thought the idea was to keep the hardware cost low?

What is the advantage of an IR cross-hair laser LED over a cheap red laser from a hardware shop with a line making lens?

-- JC

Reply to
JGCASEY

As with all code, a flowchart would be a bonus

Reply to
Dale T Stewart

LOL, well I would design and test the system with the precision parts, and then do the cost reduction.

Reply to
mlw

Really? I've *never* found flow charts useful, have you?

Reply to
mlw

What is the advantage of a cheap laser with a line making lens over a cheap laser with just the usual dot output? Isn't this going to be used as a rangefinder by finding the dot on a video frame? Or something more interesting?

Mitch

Reply to
Mitch Berkson

Ahhh, the benefit of a crosshair interesting, I'm thinking. The horizontal line is nothing more than an infinite number of dots and I can range find across a field of view.

I have a couple ideas about the vertical line that I can't articulate until I do some experimenting.

Reply to
mlw

Notes:

There's no filtering for the D term. Unless you have an encoder with a huge number of counts per rev, you'll have considerable quantization noise in the D term. Usually, you put a low-pass filter in to damp that noise, even though it costs you some lag.

The problems mentioned in "Warning ? Read This Before Operating!" are because the code doesn't have what's called "antiwindup". There are ways to keep the I term from building up improperly.

Some examples, with a motor and some graphs, would make it much clearer what's going on.

In the section on tuning, you have the integral and differential gains reversed, I think.

I recommend buying "Control System Design Guide", by George Ellis. Preferably the slim first edition, which was more concise than the second one. This is a practical guuide to motor control, not a control theory text.

John Nagle

Reply to
John Nagle

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.