Re: Essay on PID Motor control
- From: mlw <mlw@xxxxxxxxxxxxxx>
- Date: Tue, 24 Jan 2006 22:48:28 -0500
gwlucas@xxxxxxxxxxxxxxxxxxxxx wrote:
>
> 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).
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.
> So I don't think that you need to be any more reluctant about
> posting equations than you are about posting code.
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?
>
> Anyway, to see what I mean about using equations,
> consider the image at
>
> http://www.seattlerobotics.org/encoder/200108/Image70.gif
>
> 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.
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.
> 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.
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.
> 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.
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.
.
- Follow-Ups:
- Re: Essay on PID Motor control
- From: gwlucas@xxxxxxxxxxxxxxxxxxxxx
- Re: Essay on PID Motor control
- From: Padu
- Re: Essay on PID Motor control
- References:
- Essay on PID Motor control
- From: mlw
- Re: Essay on PID Motor control
- From: Padu
- Re: Essay on PID Motor control
- From: mlw
- Re: Essay on PID Motor control
- From: gwlucas@xxxxxxxxxxxxxxxxxxxxx
- Essay on PID Motor control
- Prev by Date: Mounting prototype circuit boards to steel chassis
- Next by Date: Re: Mounting prototype circuit boards to steel chassis
- Previous by thread: Re: Essay on PID Motor control
- Next by thread: Re: Essay on PID Motor control
- Index(es):
Relevant Pages
|
Loading